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/LoRaPHYCN470.h

94 lines
2.3 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 LoRaPHYCN470.h
*
* @brief Implements LoRaPHY for Chinese 470 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
*
*/
#ifndef MBED_OS_LORAPHY_CN470_H_
#define MBED_OS_LORAPHY_CN470_H_
#include "LoRaPHY.h"
// Definitions
/*!
* LoRaMac maximum number of channels
*/
#define CN470_MAX_NB_CHANNELS 96
/*!
* LoRaMac maximum number of bands
*/
#define CN470_MAX_NB_BANDS 1
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
#define CN470_CHANNEL_MASK_SIZE 6
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
class LoRaPHYCN470 : public LoRaPHY {
public:
Change LoRaWANTimer to a C++ class LoRaWANTimer is now called as LoRaWANTimeHandler class as this class handles both current time and timer functionalities. Some refactoring on how LoRa objects are created was needed: - LoRaWANTimeHandler object is created by LoRaWANStack and shares with LoRaMac and PHY. - LoRaPHY object is now member of LoRaWANStack class instead of static variable in source file.
2018-01-05 13:03:22 +00:00
LoRaPHYCN470(LoRaWANTimeHandler &lora_time);
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
virtual ~LoRaPHYCN470();
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
virtual bool rx_config(rx_config_params_t* config, int8_t* datarate );
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
virtual bool tx_config(tx_config_params_t* config, int8_t* tx_power,
lorawan_time_t* tx_toa);
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
virtual uint8_t link_ADR_request(adr_req_params_t* params, int8_t* dr_out,
int8_t* tx_power_out, uint8_t* nb_rep_out,
uint8_t* nb_bytes_parsed);
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
virtual uint8_t accept_rx_param_setup_req(rx_param_setup_req_t* params);
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
private:
/*!
* LoRaMAC channels
*/
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
channel_params_t channels[CN470_MAX_NB_CHANNELS];
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 bands
*/
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
band_t bands[CN470_MAX_NB_BANDS];
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
/*!
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
* LoRaMac channel mask
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
*/
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
uint16_t channel_mask[CN470_CHANNEL_MASK_SIZE];
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
/*!
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
* LoRaMac default channel mask
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
*/
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
uint16_t default_channel_mask[CN470_CHANNEL_MASK_SIZE];
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
};
#endif /* MBED_OS_LORAPHY_CN470_H_ */