- get_phy_params function was very heavy weight and needed to be refactored.
- switch-case clauses have been refactored to be functions now and the complexity of the usage has been improved a lot.
- There are no functional changes, this is internal only change
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
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.
Baseline is changed to use a single set of data structures that simplifies the
code in the LoRaWANStack and Mac layer. We are now following certian rules for naming
data structures.
- All structures visible outside their domain are prefixed as 'lorawan_'
- All mac structures are prefixed as 'loramac_'
- All subsystem or module strucutures carry their name in prefix, like 'mcps_'
PHY layer still have legacy camel case data structures which will be entertained
later while we will be simplifying PHY layer.
Test cases are also updated with the new data structure naming conventions.
One major difference from the previous baseline is the removal of static buffer
from mcps indication. And we do not copy data from stack buffer to rx_msg buffer.
This saves at least 512 bytes.
It may look like now that if we have received something but the user have not read
from the buffer, then the buffer will be overwritten and we will lose previous frame.
Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg
because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at
multiple locations. We inform the user about reception, if the user doesn't read and
the data gets overwritten, then so be it.
Channel planning was distributed over LoRaWANStack and LoRaMac previously.
We now centralize it by allocating the service to its own class.
Thus making the workflow consistent, i.e.,
Request for channel plan = Application->Interface->stack->Mac->ChannelPlan
Major change apart from adding the channel plan subsystem are the API changes
in LoRaMac class.
Martin Kojtal
Hasnain Virk
Antti Kauppila