MAC commands passed as messages to port 0 must be processed by LMIC, … #22
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
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.
…same as options. Resolves issue mcci-catena#14
(cherry picked from commit 238113c, edited by hand to remove debug print improvements that are not yet merged here.)
Although the LMIC code parses MAC commands that are passed as options on other downlink commands, it doesn't parse MAC commands that are explicitly sent to port 0 (issue #14).
This patch-set corrects this problem. It also ensures that port-0 messages are not delivered to the application (as they're supposed to be consumed by the MAC).
In order to be able to properly use
conston input params, also correctedconvFreq()to take a pointer toconstinput parameter. This was merely clerical, asconvFreq()doesn't modify the referenced object.