Feature lorawan 1 1 rebase #68
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…DOs in code) - MLME confirm handling refactored - Rejoin handling missing - new CF_LIST mechanism missing (+resets involved) - NVM handling missing Fixed automerge issue
BE to LE fixes, missing MLME types added LoRaWAN 1.1 Features added (Some LoRaPhy impl missing still + some TODOs in code) - MLME confirm handling refactored - Rejoin handling missing - new CF_LIST mechanism missing (+resets involved) - NVM handling missing Rejoin logic added
Although we always add a port field for Uplink traffic, the spec allows for fport field to be excluded. So there can be network server instances which would exclude fport field from downlinks. We are now adding handling for such situations.
After deriving JSEncKey we were wrongly clearing the AES context. We shouldn't clear the context until the function is done doing its job. That was why JSINtKey derivation was wrong which would result in MIC failures.
RekeyInd Mac command was being handled incorrectly. parse_mac_commnad_to_repeat() was missing handling for RekeyInd mac command. Plus it is a sticky mac command as the spec says that it needs to persist until we receive a RekeyConf mac command.
Yet another rebase issue. RX processing was supposed to happen after state setup and only once not twice.
LoRaWAN specification 1.1.0 is incorrect in handling of FOpts encrytpion. A CR was made by STMicroelectronics which correctly addresses the issue. We have taken that CR and implemented in our code base.
Rejoin requests and presence/absence of CFlist demand different handling. If a Rejoin request was sent we shall use RJCountX (0,1) instead of dev nonce for key derivation. If a Rejoin request is not of type 2, we reset mac, phy parameters alongwith frame counters. However, if it is type 2, we reset frame counters only. If cflist i present, we shall always apply it as it is. If it's not and rejoin type is not type 2, we restore default channels. Otherwise the local channels do not change.
In 1.1, NbTrans governs both unconfirmed and confirmed traffic. We cannot set number of retries ourselves. Based upon NbTrans received in linkADRReq command, we will retry. If NbTrans is 1, we will send only one message and if ack is not received we will generate TX error event. Its the NS now which controls how many retransmission a device can do without incrementing Frame counter. When we fail with TX error after not receiving an ack, we increment the frame counter. This is necessary as the NS will drop anything with the previous counter and it can happen that the NS may have sent an ack but we didn't receive it.
Double precision may introduce unwanted results and it's impact is massive on microcontrollers. So we change the precision from double to float. This change doesn't seem to enhance performance yet.
* While starting timer for rejoin request type 0, we should multiply max time with 1000 as the timer APIs take ms values as parameters. * RJCountX are incremented every time a Rejoin request is sent. For MIC calculation we need to take the previous RJCnt value in account. * Rejoin process should start against an event otherwise it will meddle with state machine and any ongoing traffic. * If a Type 1 rejoin is ongoing, we should not trigger a Type 0 rejoin. * Some bug fixes after Triage with Antti.
- Unittests updated to reflect LoRaWAN 1.1 changes
While post processing a transmission in case of no reception, we already take care of frame counters. We must not kick post processing step once again.
A rebase error perhaps. We need to attach Link Check request only once to the outgoing message.
_rx_ready boolean is not used anymore. We set/unset it using core util atomic flag set test.
99.9% white space changes
Reviewed and fixed potential doxygen format issues.
The Rx done/timeout event handler now checks if the radio is currently transmitting before putting the radio to sleep. This test returns true in class A rx window event handlers, so the radio is not not put to sleep. Now to accurately test if transmitting, a mod ongoing flag is set true on send and false on tx done/timeout.
- 2019 for new file - Added license where missing
- Added a bool return status to LoRaPHY::compute_*_win_params(...) methods. Currently, failed status returned if the rx slot type is invalid or rf frequency is invalid - Updated Class B implementation to check return status
Use close_rx_window callback to disable active class b window. This change protects against disabling the radio during class A transmit Move class B resume notification to one location in LoRaMac::set_tx_ongoing()
Ran asytle to fix line ending s
- Documented LoRaWANInterface beacon acquisition, and ping slot APIs - Existing GPS time set/get documentation was only in LoRaWANStack.h, so I copied their docs to LoRaWANInterface and lightly modified them to be a higher level description like the other documentation in this file. - Updated set_utc_time to handle millisecond precision gps time.
Fix compilation failures caused by lorawan api changes introduced by Class B support.
With class B now being available the device class test moved to the LoRaMac class which then queries the Class B interface for support. The Class B interface is not available here because the unit test stack class instantiates a LoRaMac stub class .
LoRaPHY::rx_config() is now used by all regions. All region specific implementations have been removed.
Fix compilation failures caused by lorawan api changes introduced by Class B support
astyle on unit test sources
Set IN865 beacon frequency to 866.55 MHz
Beacon time on air computation bandwidth param was hard coded to 500 KHz. Now it is read from the phy bandwidths table.
Return alternate RX1 if set
Code review requested changes
Picked the wrong diff a few times while resolving rebase conflicts.
paul-szczepanek-arm
force-pushed
the
feature-lorawan-1-1-rebase
branch
from
ffac237 to
939922e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary of changes
Impact of changes
Migration actions required
Documentation
Pull request type
Test results
Reviewers