LoRaWAN: Reduced priority for automatic uplinks & higher data rate usage for connection establishment #7601
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
|
@kivaisan Please review. |
kivaisan
approved these changes
Jul 26, 2018
|
@kivaisan Please review again. I have added two more commits to the PR. |
added 3 commits
July 27, 2018 15:04
In the case when an automatic uplink was queued and the user do have something send, we should give priority to user data instead od automatic uplink message.
The stack was trying to connect with default data rates which happened to be the lowest data rates in a specific region. In the beginning device and NS do not have agreed upon tx rx parameters and there can be synchronization issues. When we use lower datarates, we may end up having a minute and a half long transmissions that hnot only blocks the channel for a long time but also reduce the chance of proper synch between device and NS. That's why we have decided to begin with higher data rates and gradually decrease datarate if we do not hear from the network server.
DR7 is used for FSK in AS932 region. As a default max DR, we should use a LoRa modulation compatible data rate. Ofcourse if a device wishes to use FSK, it can set DR7 using set_data_rate() API and turning off ADR, or an NS can configure a new channel for the device utilizing DR7.
hasnainvirk
changed the title
hasnainvirk
force-pushed
the
abp_auto_fix
branch
from
900522e
to
57393bc
Compare
added 3 commits
July 30, 2018 15:25
If an ack is not received after maximum retries, we need to mark an error which was missing from the post processing sequence.
We had a bug especially in the reception path. Our recv window opening delays were being calculated on the premise that the radio has to capture 5 preamble symbols out of 8 transmitted by the base station. However, in PHY layer while setting radio rc settings, we were setting preamble length to be 8. Preamble length register needs to be configured differently for Uplink and Downlink. For uplink, we wish to transmit 8 preamble symbols whereas in the reception path we need to receive 5 preamble symbols at least out of 8. Alongwith that the maximum range of timing error may vary from platform to platform as it is based upon the crystal in the chip. We have now made these parameters configurable and have loaded them with the most optimal defaults.
hasnainvirk
force-pushed
the
abp_auto_fix
branch
from
57393bc
to
c7f3585
Compare
|
@SeppoTakalo Can you please review this ? |
SeppoTakalo
approved these changes
Aug 1, 2018
|
Code looks OK, but I don't know the domain enough to tell whether it is correct, but I assume this was tested already. |
|
@AnttiKauppila Can you please review this ? Have been in pipeline for a long time now. |
|
@kjbracey-arm Can you please review ? |
0xc0170
approved these changes
Aug 6, 2018
|
/morph build |
Build : SUCCESSBuild number : 2744 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 2376 |
Test : SUCCESSBuild number : 2469 |
|
/morph mbed2-build |
pan-
pushed a commit
to pan-/mbed
that referenced
this pull request
Aug 22, 2018
LoRaWAN: Reduced priority for automatic uplinks & higher data rate usage for connection establishment
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.
Description
This PR handles two issues:
i) User transmissions should have priority over automatic uplinks.
The stack schedules an event for the automatic uplink when needed and the control goes back to
application, if the user stays silent and there is nothing else to do, the automatic uplink goes out as
planned, otherwise user transmission gets priority and automatic uplink gets cancelled.
ii) We should use higher data rates to begin with as they result in smaller transmission times which
doesn't block the channel too long. Plus it also helps getting in synch with the network server faster
which is crucial to set network delays in order to open receive windows.
In addition to that a bug is fixed in post processing of CONFIRMED messages.
As receive timing error and preamle lengths are constants but could be configurable, we have made them configurable and loaded most optimal values as defaults.
Changes in the API and usage is internal to the stack.
Pull request type