ARMmbed
/
mbed-os
mirror of https://github.com/ARMmbed/mbed-os.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
mbed-os/features/lorawan/lorastack/phy/LoRaPHYEU433.cpp

322 lines
9.2 KiB
C++
Raw Normal View History

Adding PHY layer for LoRaWAN LoRaPHY is the abstract class for the LoRa PHY layer which governs the LoRaRadio and provides some common functionality to all regional implementations. We support 10 regions and every region comes loaded with default parameters. These parameters can be changed by the Mac layer or explicitely by the stack controller layer using APIs provided. This layer in essence detaches Mac completely from PHY and provides more modular approach to the entire system. Apart from class structure, the internal functionality is directly deduced from semtech reference implementation that's why most of the internal data structures are used on 'as is' basis. In addition to that, the PHY layer provides APIs to control the LoRaRadio layer, i.e., the lora radio driver, ensuring that the radio is accessed from a single entry point. A seperate data structure file is added which is common to PHY layers only.
2017-11-27 11:58:15 +00:00
/**
* @file LoRaPHYEU433.cpp
*
* @brief Implements LoRaPHY for European 433 MHz band
*
* \code
* ______ _
* / _____) _ | |
* ( (____ _____ ____ _| |_ _____ ____| |__
* \____ \| ___ | (_ _) ___ |/ ___) _ \
* _____) ) ____| | | || |_| ____( (___| | | |
* (______/|_____)_|_|_| \__)_____)\____)_| |_|
* (C)2013 Semtech
* ___ _____ _ ___ _ _____ ___ ___ ___ ___
* / __|_ _/_\ / __| |/ / __/ _ \| _ \/ __| __|
* \__ \ | |/ _ \ (__| ' <| _| (_) | / (__| _|
* |___/ |_/_/ \_\___|_|\_\_| \___/|_|_\\___|___|
* embedded.connectivity.solutions===============
*
* \endcode
*
*
* License: Revised BSD License, see LICENSE.TXT file include in the project
*
* Maintainer: Miguel Luis ( Semtech ), Gregory Cristian ( Semtech ) and Daniel Jaeckle ( STACKFORCE )
*
* Copyright (c) 2017, Arm Limited and affiliates.
* SPDX-License-Identifier: BSD-3-Clause
*
*/
#include "LoRaPHYEU433.h"
#include "lora_phy_ds.h"
/*!
* Number of default channels
*/
#define EU433_NUMB_DEFAULT_CHANNELS 3
/*!
* Number of channels to apply for the CF list
*/
#define EU433_NUMB_CHANNELS_CF_LIST 5
/*!
* Minimal datarate that can be used by the node
*/
#define EU433_TX_MIN_DATARATE DR_0
/*!
* Maximal datarate that can be used by the node
*/
#define EU433_TX_MAX_DATARATE DR_7
/*!
* Minimal datarate that can be used by the node
*/
#define EU433_RX_MIN_DATARATE DR_0
/*!
* Maximal datarate that can be used by the node
*/
#define EU433_RX_MAX_DATARATE DR_7
/*!
* Default datarate used by the node
*/
#define EU433_DEFAULT_DATARATE DR_0
Major PHY layer modifications The PHY layer had a lot of duplicated code in various geographic regions. In this commit we have tried to concentrate all common functionaliy into one single class which LoRaPHY that provides three kind of methods: i) Non virtual base methods which are there for upper layer use, e.g., providing access to driver or generic PHY layer functionality which needs to be exposed to upper layers. ii) Virtual methods (no hard limit on implementation) that can be overriden in derived classes. Some PHY implementations will need that as they may come with very peculiar channel schemes, e.g., dynamic channel schemes in US bands. iii) Protected methods which are only available for the derived PHYs We have adopted a mechanism for the dervied PHYs to announce their differenmtiating parameters in their constructors by filling up a data structure known as lora_phy_params_t which exists at base level. Access modifier for this data structure is protected so it can only be used by the base or derived classes, i.e., no exposure to upper layers. For extra functionality and differentiating controls, a derived PHY can override any virual method as necessary. In addition to that we have adopted the Mbed-OS style guide and have changed data structures and code to reflect that. Some data structures are removed. * Algorithm to get alternate DR is modified. Current scheme, works as multiples of 6 as EU and EU like PHYs provide 6 datarates. We make sure that we try a datarate at least once. If nuber of join retries is a multiple of 6, we may try multiple times on each data rate. * Most of the PHYs with dynamic channel plans, always override the above mentioned algorithm as the rules governing this algorithm do not hild in their case. * band_t data structure is enhanced with lower band frequency and higher band frequency. That enables us to validate frequency based upon the band and hence we can have a single function for all PHYs to validate frequency. * In some PHYs, there were some extra channel masks were defined which were not being used. Hence removed. * EIRP table corrected in some PHYs based upon spec. * PHY functions in response to Mac commands are renamed to reflect what they exactly do. for example accept_rx_param_setup_req() because that's what they do. they can either accept the mac command or reject it.# Please enter the commit message for your changes.
2018-01-16 14:58:18 +00:00
#define EU433_DEFAULT_MAX_DATARATE DR_5
Adding PHY layer for LoRaWAN LoRaPHY is the abstract class for the LoRa PHY layer which governs the LoRaRadio and provides some common functionality to all regional implementations. We support 10 regions and every region comes loaded with default parameters. These parameters can be changed by the Mac layer or explicitely by the stack controller layer using APIs provided. This layer in essence detaches Mac completely from PHY and provides more modular approach to the entire system. Apart from class structure, the internal functionality is directly deduced from semtech reference implementation that's why most of the internal data structures are used on 'as is' basis. In addition to that, the PHY layer provides APIs to control the LoRaRadio layer, i.e., the lora radio driver, ensuring that the radio is accessed from a single entry point. A seperate data structure file is added which is common to PHY layers only.
2017-11-27 11:58:15 +00:00
/*!
* Minimal Rx1 receive datarate offset
*/
#define EU433_MIN_RX1_DR_OFFSET 0
/*!
* Maximal Rx1 receive datarate offset
*/
#define EU433_MAX_RX1_DR_OFFSET 5
/*!
* Default Rx1 receive datarate offset
*/
#define EU433_DEFAULT_RX1_DR_OFFSET 0
/*!
* Minimal Tx output power that can be used by the node
*/
#define EU433_MIN_TX_POWER TX_POWER_5
/*!
* Maximal Tx output power that can be used by the node
*/
#define EU433_MAX_TX_POWER TX_POWER_0
/*!
* Default Tx output power used by the node
*/
#define EU433_DEFAULT_TX_POWER TX_POWER_0
/*!
* Default Max EIRP
*/
#define EU433_DEFAULT_MAX_EIRP 12.15f
/*!
* Default antenna gain
*/
#define EU433_DEFAULT_ANTENNA_GAIN 2.15f
/*!
* ADR Ack limit
*/
#define EU433_ADR_ACK_LIMIT 64
/*!
* ADR Ack delay
*/
#define EU433_ADR_ACK_DELAY 32
/*!
* Enabled or disabled the duty cycle
*/
#define EU433_DUTY_CYCLE_ENABLED 1
/*!
* Maximum RX window duration
*/
#define EU433_MAX_RX_WINDOW 3000
/*!
* Receive delay 1
*/
#define EU433_RECEIVE_DELAY1 1000
/*!
* Receive delay 2
*/
#define EU433_RECEIVE_DELAY2 2000
/*!
* Join accept delay 1
*/
#define EU433_JOIN_ACCEPT_DELAY1 5000
/*!
* Join accept delay 2
*/
#define EU433_JOIN_ACCEPT_DELAY2 6000
/*!
* Maximum frame counter gap
*/
#define EU433_MAX_FCNT_GAP 16384
/*!
* Ack timeout
*/
#define EU433_ACKTIMEOUT 2000
/*!
* Random ack timeout limits
*/
#define EU433_ACK_TIMEOUT_RND 1000
/*!
* Verification of default datarate
*/
#if ( EU433_DEFAULT_DATARATE > DR_5 )
#error "A default DR higher than DR_5 may lead to connectivity loss."
#endif
/*!
* Second reception window channel frequency definition.
*/
#define EU433_RX_WND_2_FREQ 434665000
/*!
* Second reception window channel datarate definition.
*/
#define EU433_RX_WND_2_DR DR_0
/*!
* Band 0 definition
Architecture rework, bug fixing & missing features MAC layer is now a class rather than being a blob. In addition to that Mac commands are now being handled in a seperate subsystem (a class of its own). In future we will do the same with othe sublayers of MAC like MLME, MCPS etc. The drive behind this exercise is to make MAC and supporting layers into an object oriented system. Major bug fixes include: - last join time inclusion in band parameters - disabling rx2 window if we missed the slot already - MLME uplink schdule hook - nbRep according to spec - maintaining datarate after successful joining - suppressing MLME requests if MAC is in TX_DELAYED state - Uplink dwell time verification Some missing features are implemented. Details are as follows. Support for LinkCheckRequet: An application API is added, add_link_check_request() to delegate a request for Link Check Request MAC command. * Application provides a callback function that needs to be called on reception of link check response. * Mac command is piggybacked with data frames. This API makes the sticky MAC command stick with the application payloads until/unless the application un-sticks the said mac command using remove_link_check_request() API. Handling fPending bit: If in the Downlink, we get the fPending bit set in fctrl octet, we attempt to send an empty message back to Network Server to open additional Receive windows. This operation is independent of the application. An RX_DONE event is queued bedore generating the said empty message. Specification does not mention what can be the type of that empty message. We have decided it to be of CONFIRMED type as it gives us an added benefit of retries if the corresponding RX slots are missed. Radio event callbacks as Mbed callbacks: radio_events_t structure has been carrying C-style callbacks which was inherited from the legacy code. These callbacks has now been changed to Mbed Callbacks that makes sure that we can be object oriented from now on.
2017-12-15 10:30:40 +00:00
* { DutyCycle, TxMaxPower, LastJoinTxDoneTime, LastTxDoneTime, TimeOff }
Adding PHY layer for LoRaWAN LoRaPHY is the abstract class for the LoRa PHY layer which governs the LoRaRadio and provides some common functionality to all regional implementations. We support 10 regions and every region comes loaded with default parameters. These parameters can be changed by the Mac layer or explicitely by the stack controller layer using APIs provided. This layer in essence detaches Mac completely from PHY and provides more modular approach to the entire system. Apart from class structure, the internal functionality is directly deduced from semtech reference implementation that's why most of the internal data structures are used on 'as is' basis. In addition to that, the PHY layer provides APIs to control the LoRaRadio layer, i.e., the lora radio driver, ensuring that the radio is accessed from a single entry point. A seperate data structure file is added which is common to PHY layers only.
2017-11-27 11:58:15 +00:00
*/
Major PHY layer modifications The PHY layer had a lot of duplicated code in various geographic regions. In this commit we have tried to concentrate all common functionaliy into one single class which LoRaPHY that provides three kind of methods: i) Non virtual base methods which are there for upper layer use, e.g., providing access to driver or generic PHY layer functionality which needs to be exposed to upper layers. ii) Virtual methods (no hard limit on implementation) that can be overriden in derived classes. Some PHY implementations will need that as they may come with very peculiar channel schemes, e.g., dynamic channel schemes in US bands. iii) Protected methods which are only available for the derived PHYs We have adopted a mechanism for the dervied PHYs to announce their differenmtiating parameters in their constructors by filling up a data structure known as lora_phy_params_t which exists at base level. Access modifier for this data structure is protected so it can only be used by the base or derived classes, i.e., no exposure to upper layers. For extra functionality and differentiating controls, a derived PHY can override any virual method as necessary. In addition to that we have adopted the Mbed-OS style guide and have changed data structures and code to reflect that. Some data structures are removed. * Algorithm to get alternate DR is modified. Current scheme, works as multiples of 6 as EU and EU like PHYs provide 6 datarates. We make sure that we try a datarate at least once. If nuber of join retries is a multiple of 6, we may try multiple times on each data rate. * Most of the PHYs with dynamic channel plans, always override the above mentioned algorithm as the rules governing this algorithm do not hild in their case. * band_t data structure is enhanced with lower band frequency and higher band frequency. That enables us to validate frequency based upon the band and hence we can have a single function for all PHYs to validate frequency. * In some PHYs, there were some extra channel masks were defined which were not being used. Hence removed. * EIRP table corrected in some PHYs based upon spec. * PHY functions in response to Mac commands are renamed to reflect what they exactly do. for example accept_rx_param_setup_req() because that's what they do. they can either accept the mac command or reject it.# Please enter the commit message for your changes.
2018-01-16 14:58:18 +00:00
static const band_t EU433_BAND0 = {100, EU433_MAX_TX_POWER, 0, 0, 0, 433175000, 434665000}; // 1.0 %
Adding PHY layer for LoRaWAN LoRaPHY is the abstract class for the LoRa PHY layer which governs the LoRaRadio and provides some common functionality to all regional implementations. We support 10 regions and every region comes loaded with default parameters. These parameters can be changed by the Mac layer or explicitely by the stack controller layer using APIs provided. This layer in essence detaches Mac completely from PHY and provides more modular approach to the entire system. Apart from class structure, the internal functionality is directly deduced from semtech reference implementation that's why most of the internal data structures are used on 'as is' basis. In addition to that, the PHY layer provides APIs to control the LoRaRadio layer, i.e., the lora radio driver, ensuring that the radio is accessed from a single entry point. A seperate data structure file is added which is common to PHY layers only.
2017-11-27 11:58:15 +00:00
/*!
* LoRaMac default channel 1
* Channel = { Frequency [Hz], RX1 Frequency [Hz], { ( ( DrMax << 4 ) | DrMin ) }, Band }
*/
lorawan: fix astyle coding style
2018-10-30 15:10:03 +00:00
static const channel_params_t EU433_LC1 = {433175000, 0, { ((DR_5 << 4) | DR_0) }, 0};
Adding PHY layer for LoRaWAN LoRaPHY is the abstract class for the LoRa PHY layer which governs the LoRaRadio and provides some common functionality to all regional implementations. We support 10 regions and every region comes loaded with default parameters. These parameters can be changed by the Mac layer or explicitely by the stack controller layer using APIs provided. This layer in essence detaches Mac completely from PHY and provides more modular approach to the entire system. Apart from class structure, the internal functionality is directly deduced from semtech reference implementation that's why most of the internal data structures are used on 'as is' basis. In addition to that, the PHY layer provides APIs to control the LoRaRadio layer, i.e., the lora radio driver, ensuring that the radio is accessed from a single entry point. A seperate data structure file is added which is common to PHY layers only.
2017-11-27 11:58:15 +00:00
/*!
* LoRaMac default channel 2
* Channel = { Frequency [Hz], RX1 Frequency [Hz], { ( ( DrMax << 4 ) | DrMin ) }, Band }
*/
lorawan: fix astyle coding style
2018-10-30 15:10:03 +00:00
static const channel_params_t EU433_LC2 = {433375000, 0, { ((DR_5 << 4) | DR_0) }, 0};
Adding PHY layer for LoRaWAN LoRaPHY is the abstract class for the LoRa PHY layer which governs the LoRaRadio and provides some common functionality to all regional implementations. We support 10 regions and every region comes loaded with default parameters. These parameters can be changed by the Mac layer or explicitely by the stack controller layer using APIs provided. This layer in essence detaches Mac completely from PHY and provides more modular approach to the entire system. Apart from class structure, the internal functionality is directly deduced from semtech reference implementation that's why most of the internal data structures are used on 'as is' basis. In addition to that, the PHY layer provides APIs to control the LoRaRadio layer, i.e., the lora radio driver, ensuring that the radio is accessed from a single entry point. A seperate data structure file is added which is common to PHY layers only.
2017-11-27 11:58:15 +00:00
/*!
* LoRaMac default channel 3
* Channel = { Frequency [Hz], RX1 Frequency [Hz], { ( ( DrMax << 4 ) | DrMin ) }, Band }
*/
lorawan: fix astyle coding style
2018-10-30 15:10:03 +00:00
static const channel_params_t EU433_LC3 = {433575000, 0, { ((DR_5 << 4) | DR_0) }, 0};
Adding PHY layer for LoRaWAN LoRaPHY is the abstract class for the LoRa PHY layer which governs the LoRaRadio and provides some common functionality to all regional implementations. We support 10 regions and every region comes loaded with default parameters. These parameters can be changed by the Mac layer or explicitely by the stack controller layer using APIs provided. This layer in essence detaches Mac completely from PHY and provides more modular approach to the entire system. Apart from class structure, the internal functionality is directly deduced from semtech reference implementation that's why most of the internal data structures are used on 'as is' basis. In addition to that, the PHY layer provides APIs to control the LoRaRadio layer, i.e., the lora radio driver, ensuring that the radio is accessed from a single entry point. A seperate data structure file is added which is common to PHY layers only.
2017-11-27 11:58:15 +00:00
/*!
* LoRaMac channels which are allowed for the join procedure
*/
Major PHY layer modifications The PHY layer had a lot of duplicated code in various geographic regions. In this commit we have tried to concentrate all common functionaliy into one single class which LoRaPHY that provides three kind of methods: i) Non virtual base methods which are there for upper layer use, e.g., providing access to driver or generic PHY layer functionality which needs to be exposed to upper layers. ii) Virtual methods (no hard limit on implementation) that can be overriden in derived classes. Some PHY implementations will need that as they may come with very peculiar channel schemes, e.g., dynamic channel schemes in US bands. iii) Protected methods which are only available for the derived PHYs We have adopted a mechanism for the dervied PHYs to announce their differenmtiating parameters in their constructors by filling up a data structure known as lora_phy_params_t which exists at base level. Access modifier for this data structure is protected so it can only be used by the base or derived classes, i.e., no exposure to upper layers. For extra functionality and differentiating controls, a derived PHY can override any virual method as necessary. In addition to that we have adopted the Mbed-OS style guide and have changed data structures and code to reflect that. Some data structures are removed. * Algorithm to get alternate DR is modified. Current scheme, works as multiples of 6 as EU and EU like PHYs provide 6 datarates. We make sure that we try a datarate at least once. If nuber of join retries is a multiple of 6, we may try multiple times on each data rate. * Most of the PHYs with dynamic channel plans, always override the above mentioned algorithm as the rules governing this algorithm do not hild in their case. * band_t data structure is enhanced with lower band frequency and higher band frequency. That enables us to validate frequency based upon the band and hence we can have a single function for all PHYs to validate frequency. * In some PHYs, there were some extra channel masks were defined which were not being used. Hence removed. * EIRP table corrected in some PHYs based upon spec. * PHY functions in response to Mac commands are renamed to reflect what they exactly do. for example accept_rx_param_setup_req() because that's what they do. they can either accept the mac command or reject it.# Please enter the commit message for your changes.
2018-01-16 14:58:18 +00:00
#define EU433_JOIN_CHANNELS (uint16_t) (LC(1) | LC(2) | LC(3))
Adding PHY layer for LoRaWAN LoRaPHY is the abstract class for the LoRa PHY layer which governs the LoRaRadio and provides some common functionality to all regional implementations. We support 10 regions and every region comes loaded with default parameters. These parameters can be changed by the Mac layer or explicitely by the stack controller layer using APIs provided. This layer in essence detaches Mac completely from PHY and provides more modular approach to the entire system. Apart from class structure, the internal functionality is directly deduced from semtech reference implementation that's why most of the internal data structures are used on 'as is' basis. In addition to that, the PHY layer provides APIs to control the LoRaRadio layer, i.e., the lora radio driver, ensuring that the radio is accessed from a single entry point. A seperate data structure file is added which is common to PHY layers only.
2017-11-27 11:58:15 +00:00
/*!
* Data rates table definition
*/
Major PHY layer modifications The PHY layer had a lot of duplicated code in various geographic regions. In this commit we have tried to concentrate all common functionaliy into one single class which LoRaPHY that provides three kind of methods: i) Non virtual base methods which are there for upper layer use, e.g., providing access to driver or generic PHY layer functionality which needs to be exposed to upper layers. ii) Virtual methods (no hard limit on implementation) that can be overriden in derived classes. Some PHY implementations will need that as they may come with very peculiar channel schemes, e.g., dynamic channel schemes in US bands. iii) Protected methods which are only available for the derived PHYs We have adopted a mechanism for the dervied PHYs to announce their differenmtiating parameters in their constructors by filling up a data structure known as lora_phy_params_t which exists at base level. Access modifier for this data structure is protected so it can only be used by the base or derived classes, i.e., no exposure to upper layers. For extra functionality and differentiating controls, a derived PHY can override any virual method as necessary. In addition to that we have adopted the Mbed-OS style guide and have changed data structures and code to reflect that. Some data structures are removed. * Algorithm to get alternate DR is modified. Current scheme, works as multiples of 6 as EU and EU like PHYs provide 6 datarates. We make sure that we try a datarate at least once. If nuber of join retries is a multiple of 6, we may try multiple times on each data rate. * Most of the PHYs with dynamic channel plans, always override the above mentioned algorithm as the rules governing this algorithm do not hild in their case. * band_t data structure is enhanced with lower band frequency and higher band frequency. That enables us to validate frequency based upon the band and hence we can have a single function for all PHYs to validate frequency. * In some PHYs, there were some extra channel masks were defined which were not being used. Hence removed. * EIRP table corrected in some PHYs based upon spec. * PHY functions in response to Mac commands are renamed to reflect what they exactly do. for example accept_rx_param_setup_req() because that's what they do. they can either accept the mac command or reject it.# Please enter the commit message for your changes.
2018-01-16 14:58:18 +00:00
static const uint8_t datarates_EU433[] = {12, 11, 10, 9, 8, 7, 7, 50};
Adding PHY layer for LoRaWAN LoRaPHY is the abstract class for the LoRa PHY layer which governs the LoRaRadio and provides some common functionality to all regional implementations. We support 10 regions and every region comes loaded with default parameters. These parameters can be changed by the Mac layer or explicitely by the stack controller layer using APIs provided. This layer in essence detaches Mac completely from PHY and provides more modular approach to the entire system. Apart from class structure, the internal functionality is directly deduced from semtech reference implementation that's why most of the internal data structures are used on 'as is' basis. In addition to that, the PHY layer provides APIs to control the LoRaRadio layer, i.e., the lora radio driver, ensuring that the radio is accessed from a single entry point. A seperate data structure file is added which is common to PHY layers only.
2017-11-27 11:58:15 +00:00
/*!
* Bandwidths table definition in Hz
*/
Major PHY layer modifications The PHY layer had a lot of duplicated code in various geographic regions. In this commit we have tried to concentrate all common functionaliy into one single class which LoRaPHY that provides three kind of methods: i) Non virtual base methods which are there for upper layer use, e.g., providing access to driver or generic PHY layer functionality which needs to be exposed to upper layers. ii) Virtual methods (no hard limit on implementation) that can be overriden in derived classes. Some PHY implementations will need that as they may come with very peculiar channel schemes, e.g., dynamic channel schemes in US bands. iii) Protected methods which are only available for the derived PHYs We have adopted a mechanism for the dervied PHYs to announce their differenmtiating parameters in their constructors by filling up a data structure known as lora_phy_params_t which exists at base level. Access modifier for this data structure is protected so it can only be used by the base or derived classes, i.e., no exposure to upper layers. For extra functionality and differentiating controls, a derived PHY can override any virual method as necessary. In addition to that we have adopted the Mbed-OS style guide and have changed data structures and code to reflect that. Some data structures are removed. * Algorithm to get alternate DR is modified. Current scheme, works as multiples of 6 as EU and EU like PHYs provide 6 datarates. We make sure that we try a datarate at least once. If nuber of join retries is a multiple of 6, we may try multiple times on each data rate. * Most of the PHYs with dynamic channel plans, always override the above mentioned algorithm as the rules governing this algorithm do not hild in their case. * band_t data structure is enhanced with lower band frequency and higher band frequency. That enables us to validate frequency based upon the band and hence we can have a single function for all PHYs to validate frequency. * In some PHYs, there were some extra channel masks were defined which were not being used. Hence removed. * EIRP table corrected in some PHYs based upon spec. * PHY functions in response to Mac commands are renamed to reflect what they exactly do. for example accept_rx_param_setup_req() because that's what they do. they can either accept the mac command or reject it.# Please enter the commit message for your changes.
2018-01-16 14:58:18 +00:00
static const uint32_t bandwidths_EU433[] = {125000, 125000, 125000, 125000, 125000, 125000, 250000, 0};
Adding PHY layer for LoRaWAN LoRaPHY is the abstract class for the LoRa PHY layer which governs the LoRaRadio and provides some common functionality to all regional implementations. We support 10 regions and every region comes loaded with default parameters. These parameters can be changed by the Mac layer or explicitely by the stack controller layer using APIs provided. This layer in essence detaches Mac completely from PHY and provides more modular approach to the entire system. Apart from class structure, the internal functionality is directly deduced from semtech reference implementation that's why most of the internal data structures are used on 'as is' basis. In addition to that, the PHY layer provides APIs to control the LoRaRadio layer, i.e., the lora radio driver, ensuring that the radio is accessed from a single entry point. A seperate data structure file is added which is common to PHY layers only.
2017-11-27 11:58:15 +00:00
/*!
* Maximum payload with respect to the datarate index. Cannot operate with repeater.
*/
Major PHY layer modifications The PHY layer had a lot of duplicated code in various geographic regions. In this commit we have tried to concentrate all common functionaliy into one single class which LoRaPHY that provides three kind of methods: i) Non virtual base methods which are there for upper layer use, e.g., providing access to driver or generic PHY layer functionality which needs to be exposed to upper layers. ii) Virtual methods (no hard limit on implementation) that can be overriden in derived classes. Some PHY implementations will need that as they may come with very peculiar channel schemes, e.g., dynamic channel schemes in US bands. iii) Protected methods which are only available for the derived PHYs We have adopted a mechanism for the dervied PHYs to announce their differenmtiating parameters in their constructors by filling up a data structure known as lora_phy_params_t which exists at base level. Access modifier for this data structure is protected so it can only be used by the base or derived classes, i.e., no exposure to upper layers. For extra functionality and differentiating controls, a derived PHY can override any virual method as necessary. In addition to that we have adopted the Mbed-OS style guide and have changed data structures and code to reflect that. Some data structures are removed. * Algorithm to get alternate DR is modified. Current scheme, works as multiples of 6 as EU and EU like PHYs provide 6 datarates. We make sure that we try a datarate at least once. If nuber of join retries is a multiple of 6, we may try multiple times on each data rate. * Most of the PHYs with dynamic channel plans, always override the above mentioned algorithm as the rules governing this algorithm do not hild in their case. * band_t data structure is enhanced with lower band frequency and higher band frequency. That enables us to validate frequency based upon the band and hence we can have a single function for all PHYs to validate frequency. * In some PHYs, there were some extra channel masks were defined which were not being used. Hence removed. * EIRP table corrected in some PHYs based upon spec. * PHY functions in response to Mac commands are renamed to reflect what they exactly do. for example accept_rx_param_setup_req() because that's what they do. they can either accept the mac command or reject it.# Please enter the commit message for your changes.
2018-01-16 14:58:18 +00:00
static const uint8_t max_payloads_EU433[] = {51, 51, 51, 115, 242, 242, 242, 242};
Adding PHY layer for LoRaWAN LoRaPHY is the abstract class for the LoRa PHY layer which governs the LoRaRadio and provides some common functionality to all regional implementations. We support 10 regions and every region comes loaded with default parameters. These parameters can be changed by the Mac layer or explicitely by the stack controller layer using APIs provided. This layer in essence detaches Mac completely from PHY and provides more modular approach to the entire system. Apart from class structure, the internal functionality is directly deduced from semtech reference implementation that's why most of the internal data structures are used on 'as is' basis. In addition to that, the PHY layer provides APIs to control the LoRaRadio layer, i.e., the lora radio driver, ensuring that the radio is accessed from a single entry point. A seperate data structure file is added which is common to PHY layers only.
2017-11-27 11:58:15 +00:00
/*!
* Maximum payload with respect to the datarate index. Can operate with repeater.
*/
Major PHY layer modifications The PHY layer had a lot of duplicated code in various geographic regions. In this commit we have tried to concentrate all common functionaliy into one single class which LoRaPHY that provides three kind of methods: i) Non virtual base methods which are there for upper layer use, e.g., providing access to driver or generic PHY layer functionality which needs to be exposed to upper layers. ii) Virtual methods (no hard limit on implementation) that can be overriden in derived classes. Some PHY implementations will need that as they may come with very peculiar channel schemes, e.g., dynamic channel schemes in US bands. iii) Protected methods which are only available for the derived PHYs We have adopted a mechanism for the dervied PHYs to announce their differenmtiating parameters in their constructors by filling up a data structure known as lora_phy_params_t which exists at base level. Access modifier for this data structure is protected so it can only be used by the base or derived classes, i.e., no exposure to upper layers. For extra functionality and differentiating controls, a derived PHY can override any virual method as necessary. In addition to that we have adopted the Mbed-OS style guide and have changed data structures and code to reflect that. Some data structures are removed. * Algorithm to get alternate DR is modified. Current scheme, works as multiples of 6 as EU and EU like PHYs provide 6 datarates. We make sure that we try a datarate at least once. If nuber of join retries is a multiple of 6, we may try multiple times on each data rate. * Most of the PHYs with dynamic channel plans, always override the above mentioned algorithm as the rules governing this algorithm do not hild in their case. * band_t data structure is enhanced with lower band frequency and higher band frequency. That enables us to validate frequency based upon the band and hence we can have a single function for all PHYs to validate frequency. * In some PHYs, there were some extra channel masks were defined which were not being used. Hence removed. * EIRP table corrected in some PHYs based upon spec. * PHY functions in response to Mac commands are renamed to reflect what they exactly do. for example accept_rx_param_setup_req() because that's what they do. they can either accept the mac command or reject it.# Please enter the commit message for your changes.
2018-01-16 14:58:18 +00:00
static const uint8_t max_payloads_with_repeater_EU433[] = {51, 51, 51, 115, 222, 222, 222, 222};
Adding PHY layer for LoRaWAN LoRaPHY is the abstract class for the LoRa PHY layer which governs the LoRaRadio and provides some common functionality to all regional implementations. We support 10 regions and every region comes loaded with default parameters. These parameters can be changed by the Mac layer or explicitely by the stack controller layer using APIs provided. This layer in essence detaches Mac completely from PHY and provides more modular approach to the entire system. Apart from class structure, the internal functionality is directly deduced from semtech reference implementation that's why most of the internal data structures are used on 'as is' basis. In addition to that, the PHY layer provides APIs to control the LoRaRadio layer, i.e., the lora radio driver, ensuring that the radio is accessed from a single entry point. A seperate data structure file is added which is common to PHY layers only.
2017-11-27 11:58:15 +00:00
Lora: Add initialize() method to set LoRaWANTimeHandler class for phy Instead of giving LoRaWANTimeHandler object as parameter for constructor, object is now given via own initialize() method. This change is needed for future refactoring where application can give own PHY object for LoRa stack.
2018-07-02 10:28:05 +00:00
LoRaPHYEU433::LoRaPHYEU433()
Adding PHY layer for LoRaWAN LoRaPHY is the abstract class for the LoRa PHY layer which governs the LoRaRadio and provides some common functionality to all regional implementations. We support 10 regions and every region comes loaded with default parameters. These parameters can be changed by the Mac layer or explicitely by the stack controller layer using APIs provided. This layer in essence detaches Mac completely from PHY and provides more modular approach to the entire system. Apart from class structure, the internal functionality is directly deduced from semtech reference implementation that's why most of the internal data structures are used on 'as is' basis. In addition to that, the PHY layer provides APIs to control the LoRaRadio layer, i.e., the lora radio driver, ensuring that the radio is accessed from a single entry point. A seperate data structure file is added which is common to PHY layers only.
2017-11-27 11:58:15 +00:00
{
Major PHY layer modifications The PHY layer had a lot of duplicated code in various geographic regions. In this commit we have tried to concentrate all common functionaliy into one single class which LoRaPHY that provides three kind of methods: i) Non virtual base methods which are there for upper layer use, e.g., providing access to driver or generic PHY layer functionality which needs to be exposed to upper layers. ii) Virtual methods (no hard limit on implementation) that can be overriden in derived classes. Some PHY implementations will need that as they may come with very peculiar channel schemes, e.g., dynamic channel schemes in US bands. iii) Protected methods which are only available for the derived PHYs We have adopted a mechanism for the dervied PHYs to announce their differenmtiating parameters in their constructors by filling up a data structure known as lora_phy_params_t which exists at base level. Access modifier for this data structure is protected so it can only be used by the base or derived classes, i.e., no exposure to upper layers. For extra functionality and differentiating controls, a derived PHY can override any virual method as necessary. In addition to that we have adopted the Mbed-OS style guide and have changed data structures and code to reflect that. Some data structures are removed. * Algorithm to get alternate DR is modified. Current scheme, works as multiples of 6 as EU and EU like PHYs provide 6 datarates. We make sure that we try a datarate at least once. If nuber of join retries is a multiple of 6, we may try multiple times on each data rate. * Most of the PHYs with dynamic channel plans, always override the above mentioned algorithm as the rules governing this algorithm do not hild in their case. * band_t data structure is enhanced with lower band frequency and higher band frequency. That enables us to validate frequency based upon the band and hence we can have a single function for all PHYs to validate frequency. * In some PHYs, there were some extra channel masks were defined which were not being used. Hence removed. * EIRP table corrected in some PHYs based upon spec. * PHY functions in response to Mac commands are renamed to reflect what they exactly do. for example accept_rx_param_setup_req() because that's what they do. they can either accept the mac command or reject it.# Please enter the commit message for your changes.
2018-01-16 14:58:18 +00:00
bands[0] = EU433_BAND0;
// Channels
channels[0] = EU433_LC1;
Initializing band for default channels We went through an exercise of adding band information to any new channel being added. Default channels were looked over. This commits duly adds missing band information to default channels.
2018-05-03 15:08:22 +00:00
channels[0].band = 0;
channels[1] = EU433_LC2;
channels[1].band = 0;
channels[2] = EU433_LC3;
channels[2].band = 0;
Major PHY layer modifications The PHY layer had a lot of duplicated code in various geographic regions. In this commit we have tried to concentrate all common functionaliy into one single class which LoRaPHY that provides three kind of methods: i) Non virtual base methods which are there for upper layer use, e.g., providing access to driver or generic PHY layer functionality which needs to be exposed to upper layers. ii) Virtual methods (no hard limit on implementation) that can be overriden in derived classes. Some PHY implementations will need that as they may come with very peculiar channel schemes, e.g., dynamic channel schemes in US bands. iii) Protected methods which are only available for the derived PHYs We have adopted a mechanism for the dervied PHYs to announce their differenmtiating parameters in their constructors by filling up a data structure known as lora_phy_params_t which exists at base level. Access modifier for this data structure is protected so it can only be used by the base or derived classes, i.e., no exposure to upper layers. For extra functionality and differentiating controls, a derived PHY can override any virual method as necessary. In addition to that we have adopted the Mbed-OS style guide and have changed data structures and code to reflect that. Some data structures are removed. * Algorithm to get alternate DR is modified. Current scheme, works as multiples of 6 as EU and EU like PHYs provide 6 datarates. We make sure that we try a datarate at least once. If nuber of join retries is a multiple of 6, we may try multiple times on each data rate. * Most of the PHYs with dynamic channel plans, always override the above mentioned algorithm as the rules governing this algorithm do not hild in their case. * band_t data structure is enhanced with lower band frequency and higher band frequency. That enables us to validate frequency based upon the band and hence we can have a single function for all PHYs to validate frequency. * In some PHYs, there were some extra channel masks were defined which were not being used. Hence removed. * EIRP table corrected in some PHYs based upon spec. * PHY functions in response to Mac commands are renamed to reflect what they exactly do. for example accept_rx_param_setup_req() because that's what they do. they can either accept the mac command or reject it.# Please enter the commit message for your changes.
2018-01-16 14:58:18 +00:00
// Initialize the channels default mask
A few Cosmetics & methods for mask manipulation LoRaMacChannelPlan class provides APIs which are not usable for PHY layer implementations who do not support custom channel plans. So we had some code in APIs which was explicitely using magic numbers for the channel mask. Although it turned out to be not a bug as a layer down we were checking for custom channel support. However, we now check for custom channel support before going deep into PHY layer that will make the code run faster and we have done some cosmetics to the code for readability. Channel mask is manipulated with inline methods
2018-02-12 14:10:37 +00:00
default_channel_mask[0] = LC(1) + LC(2) + LC(3);
Major PHY layer modifications The PHY layer had a lot of duplicated code in various geographic regions. In this commit we have tried to concentrate all common functionaliy into one single class which LoRaPHY that provides three kind of methods: i) Non virtual base methods which are there for upper layer use, e.g., providing access to driver or generic PHY layer functionality which needs to be exposed to upper layers. ii) Virtual methods (no hard limit on implementation) that can be overriden in derived classes. Some PHY implementations will need that as they may come with very peculiar channel schemes, e.g., dynamic channel schemes in US bands. iii) Protected methods which are only available for the derived PHYs We have adopted a mechanism for the dervied PHYs to announce their differenmtiating parameters in their constructors by filling up a data structure known as lora_phy_params_t which exists at base level. Access modifier for this data structure is protected so it can only be used by the base or derived classes, i.e., no exposure to upper layers. For extra functionality and differentiating controls, a derived PHY can override any virual method as necessary. In addition to that we have adopted the Mbed-OS style guide and have changed data structures and code to reflect that. Some data structures are removed. * Algorithm to get alternate DR is modified. Current scheme, works as multiples of 6 as EU and EU like PHYs provide 6 datarates. We make sure that we try a datarate at least once. If nuber of join retries is a multiple of 6, we may try multiple times on each data rate. * Most of the PHYs with dynamic channel plans, always override the above mentioned algorithm as the rules governing this algorithm do not hild in their case. * band_t data structure is enhanced with lower band frequency and higher band frequency. That enables us to validate frequency based upon the band and hence we can have a single function for all PHYs to validate frequency. * In some PHYs, there were some extra channel masks were defined which were not being used. Hence removed. * EIRP table corrected in some PHYs based upon spec. * PHY functions in response to Mac commands are renamed to reflect what they exactly do. for example accept_rx_param_setup_req() because that's what they do. they can either accept the mac command or reject it.# Please enter the commit message for your changes.
2018-01-16 14:58:18 +00:00
// Update the channels mask
A few Cosmetics & methods for mask manipulation LoRaMacChannelPlan class provides APIs which are not usable for PHY layer implementations who do not support custom channel plans. So we had some code in APIs which was explicitely using magic numbers for the channel mask. Although it turned out to be not a bug as a layer down we were checking for custom channel support. However, we now check for custom channel support before going deep into PHY layer that will make the code run faster and we have done some cosmetics to the code for readability. Channel mask is manipulated with inline methods
2018-02-12 14:10:37 +00:00
copy_channel_mask(channel_mask, default_channel_mask, EU433_CHANNEL_MASK_SIZE);
Major PHY layer modifications The PHY layer had a lot of duplicated code in various geographic regions. In this commit we have tried to concentrate all common functionaliy into one single class which LoRaPHY that provides three kind of methods: i) Non virtual base methods which are there for upper layer use, e.g., providing access to driver or generic PHY layer functionality which needs to be exposed to upper layers. ii) Virtual methods (no hard limit on implementation) that can be overriden in derived classes. Some PHY implementations will need that as they may come with very peculiar channel schemes, e.g., dynamic channel schemes in US bands. iii) Protected methods which are only available for the derived PHYs We have adopted a mechanism for the dervied PHYs to announce their differenmtiating parameters in their constructors by filling up a data structure known as lora_phy_params_t which exists at base level. Access modifier for this data structure is protected so it can only be used by the base or derived classes, i.e., no exposure to upper layers. For extra functionality and differentiating controls, a derived PHY can override any virual method as necessary. In addition to that we have adopted the Mbed-OS style guide and have changed data structures and code to reflect that. Some data structures are removed. * Algorithm to get alternate DR is modified. Current scheme, works as multiples of 6 as EU and EU like PHYs provide 6 datarates. We make sure that we try a datarate at least once. If nuber of join retries is a multiple of 6, we may try multiple times on each data rate. * Most of the PHYs with dynamic channel plans, always override the above mentioned algorithm as the rules governing this algorithm do not hild in their case. * band_t data structure is enhanced with lower band frequency and higher band frequency. That enables us to validate frequency based upon the band and hence we can have a single function for all PHYs to validate frequency. * In some PHYs, there were some extra channel masks were defined which were not being used. Hence removed. * EIRP table corrected in some PHYs based upon spec. * PHY functions in response to Mac commands are renamed to reflect what they exactly do. for example accept_rx_param_setup_req() because that's what they do. they can either accept the mac command or reject it.# Please enter the commit message for your changes.
2018-01-16 14:58:18 +00:00
// set default channels
phy_params.channels.channel_list = channels;
phy_params.channels.channel_list_size = EU433_MAX_NB_CHANNELS;
A few Cosmetics & methods for mask manipulation LoRaMacChannelPlan class provides APIs which are not usable for PHY layer implementations who do not support custom channel plans. So we had some code in APIs which was explicitely using magic numbers for the channel mask. Although it turned out to be not a bug as a layer down we were checking for custom channel support. However, we now check for custom channel support before going deep into PHY layer that will make the code run faster and we have done some cosmetics to the code for readability. Channel mask is manipulated with inline methods
2018-02-12 14:10:37 +00:00
phy_params.channels.mask = channel_mask;
phy_params.channels.default_mask = default_channel_mask;
phy_params.channels.mask_size = EU433_CHANNEL_MASK_SIZE;
Major PHY layer modifications The PHY layer had a lot of duplicated code in various geographic regions. In this commit we have tried to concentrate all common functionaliy into one single class which LoRaPHY that provides three kind of methods: i) Non virtual base methods which are there for upper layer use, e.g., providing access to driver or generic PHY layer functionality which needs to be exposed to upper layers. ii) Virtual methods (no hard limit on implementation) that can be overriden in derived classes. Some PHY implementations will need that as they may come with very peculiar channel schemes, e.g., dynamic channel schemes in US bands. iii) Protected methods which are only available for the derived PHYs We have adopted a mechanism for the dervied PHYs to announce their differenmtiating parameters in their constructors by filling up a data structure known as lora_phy_params_t which exists at base level. Access modifier for this data structure is protected so it can only be used by the base or derived classes, i.e., no exposure to upper layers. For extra functionality and differentiating controls, a derived PHY can override any virual method as necessary. In addition to that we have adopted the Mbed-OS style guide and have changed data structures and code to reflect that. Some data structures are removed. * Algorithm to get alternate DR is modified. Current scheme, works as multiples of 6 as EU and EU like PHYs provide 6 datarates. We make sure that we try a datarate at least once. If nuber of join retries is a multiple of 6, we may try multiple times on each data rate. * Most of the PHYs with dynamic channel plans, always override the above mentioned algorithm as the rules governing this algorithm do not hild in their case. * band_t data structure is enhanced with lower band frequency and higher band frequency. That enables us to validate frequency based upon the band and hence we can have a single function for all PHYs to validate frequency. * In some PHYs, there were some extra channel masks were defined which were not being used. Hence removed. * EIRP table corrected in some PHYs based upon spec. * PHY functions in response to Mac commands are renamed to reflect what they exactly do. for example accept_rx_param_setup_req() because that's what they do. they can either accept the mac command or reject it.# Please enter the commit message for your changes.
2018-01-16 14:58:18 +00:00
// set bands for EU433 spectrum
phy_params.bands.table = bands;
phy_params.bands.size = EU433_MAX_NB_BANDS;
// set bandwidths available in EU433 spectrum
phy_params.bandwidths.table = (void *) bandwidths_EU433;
phy_params.bandwidths.size = 8;
// set data rates available in EU433 spectrum
phy_params.datarates.table = (void *) datarates_EU433;
phy_params.datarates.size = 8;
// set payload sizes with respect to data rates
phy_params.payloads.table = (void *) max_payloads_EU433;
phy_params.payloads.size = 8;
phy_params.payloads_with_repeater.table = (void *) max_payloads_with_repeater_EU433;
Fix initialization of phy_params.payloads_with_repeater.size
2018-03-08 10:46:54 +00:00
phy_params.payloads_with_repeater.size = 8;
Major PHY layer modifications The PHY layer had a lot of duplicated code in various geographic regions. In this commit we have tried to concentrate all common functionaliy into one single class which LoRaPHY that provides three kind of methods: i) Non virtual base methods which are there for upper layer use, e.g., providing access to driver or generic PHY layer functionality which needs to be exposed to upper layers. ii) Virtual methods (no hard limit on implementation) that can be overriden in derived classes. Some PHY implementations will need that as they may come with very peculiar channel schemes, e.g., dynamic channel schemes in US bands. iii) Protected methods which are only available for the derived PHYs We have adopted a mechanism for the dervied PHYs to announce their differenmtiating parameters in their constructors by filling up a data structure known as lora_phy_params_t which exists at base level. Access modifier for this data structure is protected so it can only be used by the base or derived classes, i.e., no exposure to upper layers. For extra functionality and differentiating controls, a derived PHY can override any virual method as necessary. In addition to that we have adopted the Mbed-OS style guide and have changed data structures and code to reflect that. Some data structures are removed. * Algorithm to get alternate DR is modified. Current scheme, works as multiples of 6 as EU and EU like PHYs provide 6 datarates. We make sure that we try a datarate at least once. If nuber of join retries is a multiple of 6, we may try multiple times on each data rate. * Most of the PHYs with dynamic channel plans, always override the above mentioned algorithm as the rules governing this algorithm do not hild in their case. * band_t data structure is enhanced with lower band frequency and higher band frequency. That enables us to validate frequency based upon the band and hence we can have a single function for all PHYs to validate frequency. * In some PHYs, there were some extra channel masks were defined which were not being used. Hence removed. * EIRP table corrected in some PHYs based upon spec. * PHY functions in response to Mac commands are renamed to reflect what they exactly do. for example accept_rx_param_setup_req() because that's what they do. they can either accept the mac command or reject it.# Please enter the commit message for your changes.
2018-01-16 14:58:18 +00:00
// dwell time setting
phy_params.ul_dwell_time_setting = 0;
phy_params.dl_dwell_time_setting = 0;
// set initial and default parameters
phy_params.duty_cycle_enabled = EU433_DUTY_CYCLE_ENABLED;
phy_params.accept_tx_param_setup_req = false;
phy_params.fsk_supported = true;
phy_params.cflist_supported = true;
phy_params.dl_channel_req_supported = true;
phy_params.custom_channelplans_supported = true;
phy_params.default_channel_cnt = EU433_NUMB_DEFAULT_CHANNELS;
phy_params.max_channel_cnt = EU433_MAX_NB_CHANNELS;
phy_params.cflist_channel_cnt = EU433_NUMB_CHANNELS_CF_LIST;
phy_params.min_tx_datarate = EU433_TX_MIN_DATARATE;
phy_params.max_tx_datarate = EU433_TX_MAX_DATARATE;
phy_params.min_rx_datarate = EU433_RX_MIN_DATARATE;
phy_params.max_rx_datarate = EU433_RX_MAX_DATARATE;
phy_params.default_datarate = EU433_DEFAULT_DATARATE;
phy_params.default_max_datarate = EU433_DEFAULT_MAX_DATARATE;
phy_params.min_rx1_dr_offset = EU433_MIN_RX1_DR_OFFSET;
phy_params.max_rx1_dr_offset = EU433_MAX_RX1_DR_OFFSET;
phy_params.default_rx1_dr_offset = EU433_DEFAULT_RX1_DR_OFFSET;
phy_params.min_tx_power = EU433_MIN_TX_POWER;
phy_params.max_tx_power = EU433_MAX_TX_POWER;
phy_params.default_tx_power = EU433_DEFAULT_TX_POWER;
phy_params.default_max_eirp = EU433_DEFAULT_MAX_EIRP;
phy_params.default_antenna_gain = EU433_DEFAULT_ANTENNA_GAIN;
phy_params.adr_ack_limit = EU433_ADR_ACK_LIMIT;
phy_params.adr_ack_delay = EU433_ADR_ACK_DELAY;
phy_params.max_rx_window = EU433_MAX_RX_WINDOW;
phy_params.recv_delay1 = EU433_RECEIVE_DELAY1;
phy_params.recv_delay2 = EU433_RECEIVE_DELAY2;
phy_params.join_channel_mask = EU433_JOIN_CHANNELS;
phy_params.join_accept_delay1 = EU433_JOIN_ACCEPT_DELAY1;
phy_params.join_accept_delay2 = EU433_JOIN_ACCEPT_DELAY2;
phy_params.max_fcnt_gap = EU433_MAX_FCNT_GAP;
phy_params.ack_timeout = EU433_ACKTIMEOUT;
phy_params.ack_timeout_rnd = EU433_ACK_TIMEOUT_RND;
phy_params.rx_window2_datarate = EU433_RX_WND_2_DR;
phy_params.rx_window2_frequency = EU433_RX_WND_2_FREQ;
Adding PHY layer for LoRaWAN LoRaPHY is the abstract class for the LoRa PHY layer which governs the LoRaRadio and provides some common functionality to all regional implementations. We support 10 regions and every region comes loaded with default parameters. These parameters can be changed by the Mac layer or explicitely by the stack controller layer using APIs provided. This layer in essence detaches Mac completely from PHY and provides more modular approach to the entire system. Apart from class structure, the internal functionality is directly deduced from semtech reference implementation that's why most of the internal data structures are used on 'as is' basis. In addition to that, the PHY layer provides APIs to control the LoRaRadio layer, i.e., the lora radio driver, ensuring that the radio is accessed from a single entry point. A seperate data structure file is added which is common to PHY layers only.
2017-11-27 11:58:15 +00:00
}
LoRaPHYEU433::~LoRaPHYEU433()
{
}