Comments (4)
Confirmed uplinks currently use the same retry/back-off strategy as OTAA which is very slow. The specification doesn't require it to use the same strategy. I did it that way because I don't use confirmed uplinks and didn't want to spend time on it.
I think increasing power and/or spreading factor on retry is the opposite of what should be done, especially If the loss is due to congestion.
It is possible to change the back-off strategy to send the retries closer together and thus avoid the payload becoming stale. This already happens with re-transmission of unconfirmed data (redundant frames). Back-to-back re-transmission is allowed until a certain amount of off-time has been accumulated. The limit is set in ldl_region.c so it changes depending on the region. In EU this limit is set to one hour of off-time.
Confirmed retries could be improved by shifting to a similar system, but with a back-off algorithm that is faster than OTAA.
Regarding your proposed changes:
I would prefer any counter manipulation remain the responsibility of the MAC. I think special behaviour should be implemented as a mode the application can select, for example:
- retry with exponential back-off
- retry with exponentiall back-off and randomisation
- variation on the back-off interval
That sort of thing, with the default mode being something conservative.
As mentioned I think increasing the reach of the signal on retry is moving in the wrong direction.
from lora_device_lib.
Thanks for your comments.
New for me is the opinion, that a retry should not increase power/spreading factor. You are right, that in the case of congestion it does not help, rather the opposite. In my setup I send confirmed messages with nbTrans=3, so there is always a fast retry with the same settings. But if the location or other conditions change, we have to change the spreading factor. If we do not want to wait until ADR kicks in, some missed ACKs (to confirmed messages) is the right place.
In my test setup (with one bug fixed) it worked very well. After a location change I observed a switch from SF7 to SF9 and shortly thereafter to SF8. That is still running stable with that value.
regarding
-
I agree, that the retry with same counter should be the responsibility of the MAC. A retry with exponential back-off or other algorithm in addition to the existing nbTrans behaviour is a good idea.
-
If several retries with same SF fail, the SF should be increased, either controlled by MAC or application. The fact, that ADR is too slow in order to be able to react to changed transmission conditions was exactly the reason for my changes. On the other hand ADR works quite well in reducing the SF.
from lora_device_lib.
I've had another look at your proposed changes, I think I missed the point the first time around.
In the past the retransmission of failed confirmed uplinks was only controlled
by parameter nbTrans. The application could not trigger a proper retry, because
a repeated call to LDL_MAC_confirmedData() increases the frame counter, which
in turn is a problem, when not the confirmed uplink was lost, but the acknowledge
downlink.
The frame counter is required to increment if you want adrAckCounter to increment (see 1.0.3 section 4.3.1.1). If you want ADR to respond as fast as possible, you need to use confirmed service without retries.
I think the problem is that you want the server to resend an unacknowledged confirmed downlink.
Shouldn't this happen if the ACK bit is not set on the next frame?
LDL_MAC_resendLastConfirmedMessage() to trigger a retransmit of confirmed messsage
Your function assumes that the previous frame is still in the buffer. This is problematic because LDL by design does not guarantee the contents of the buffer and other service specific state once the service is complete.
LDL_MAC_lowerRateIncreasePower() to control transmit power and data rate
You don't have to use ADR. The spec encourages applications to turn it on/off as required. LDL has getter/setter functions for manipulating power and rate. At a glance, these functions work (or should work) regardless of the ADR setting.
from lora_device_lib.
Hello,
I use this topic to give feedback right away.
Meanwhile I updated my test environment to the current version (450ae80) and everything seems to work well. Thanks for your continuous improvements.
After your posting I restructured my code. I send confirmed messages with nbTrans=3 and rely on LDL's retry at first. If it fails I reduce the rate by one step and the next measurement will use the new rate. So I do not need to patch LDL and have the desired behaviour. I need the fast rate change, because my devices will run on places where SF7 is sufficient and also where I need SF8 or SF9.
from lora_device_lib.
Related Issues (20)
- OTAA not recieving JoinAccept HOT 2
- Radio interrupt not raised when message received in SF11 and SF12 HOT 3
- Proposal to remove diagnostic events from ldl_mac_response_type HOT 2
- Proposal to refactor LDL_DEBUG, LDL_ERROR, and LDL_INFO HOT 3
- Maximum sleep time due to LDL_MAC_ticksUntilNextEvent() values HOT 7
- Simplify function timerDelta()
- possible deprecated #define LDL_LITTLE_ENDIAN HOT 1
- preferred way to use DeviceTimeSync HOT 4
- Add a check for maximum message size on send HOT 2
- Increment devNonce on every join request HOT 6
- Not receiving Join Accept HOT 2
- LPTIM 16 bit ticker HOT 1
- ticksUntilNextEvent keeps returning UINT32_MAX HOT 2
- SX1262 support HOT 4
- Lora modules driver
- I am having trouble importing this library to arduino?
- OTAA join HOT 5
- Incorrect MIC generated LoRaWAN 1.1 retransmissions and command responses HOT 1
- Join timeout HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lora_device_lib.