MDot stuck at SF8BW500 with ADR enabled.

[Ajay K]

During the last weekend we have been running tests using the ADR feature. It seems like the conduit sets the MDot to run at SF8BW500 DR and after which no matter what it doesn’t change the DR. There were times the MDot couldn’t even get to the Conduit or rather transmit messages to the MDot.

Now reading thru’ the ADR spec, it seems like the conduit requires atleast 6 uplink packets before it can determine what the DR/Spread factor to set for the mdot.

My questions is in this scenario where the MDot is unable to get to the conduit after it has been connected at a given data rate, should I be implementing any changes on my end to try changing the SF/DR such that it helps with the transmission like switching it to SF10BW125?

We could have a scenario even though the mdot is static in a given place all of a sudden lets say its blocked by say a large physical obstacle or something which prevents the transmission from getting to the conduit, now the conduit has no way of directing the MDot to switch its DR right? In this case what is suggested the mdot do to get the data out to the conduit?

Thanks,
Ajay

[Jason Reiss]

If ACK is enabled above 2 retries on the mdot, after two missed packets the device will restore max tx power. Then after 2 more missed packets it will lower the datarate.

This IS NOT detailed in the lorawan protocol specification, it is implemented in Semtech reference LoraWAN project. https://github.com/Lora-net/LoRaMac-node

If ACK is disabled the same will happen after 96 uplinks without a downlink. First after 64 uplinks a bit is set to request a downlink from the network server. Then if a reply is not heard in the next 32 packets the max power is restored or the datarate is lowered. This is then repeated until lowest datarate or downlink is received. The counter is reset with every downlink.

This IS detailed in the lorawan protocol specification. See ADR_ACK_LIMIT and ADR_ACK_DELAY.

Cheers!

[Jason Reiss]

Another option would be to lower the MaxDatarate setting used for ADR if you find DR4 unreliable in the deployment environment.

[Ajay K]

Thanks Jason for taking the time to respond. We have acks’ enabled both on the MDot and Conduit for our transmissions.

If ACK is enabled above 2 retries on the mdot, after two missed packets the device will restore max tx power. Then after 2 more missed packets it will lower the datarate.

In the above statement, by “it” you mean the conduit right? But for the conduit to lower the rate, it needs the mdot to communicate with it right? For example for the conduit to restore it to SF10 which is the lowest data rate in the US either because of an uplink or downlink occurs. Also with a Class A, a downlink will never occur unless an uplink occurs.

I just want to be clear as to in the specific scenario I just described at the beginning of the thread if the conduit can not lower the DR or increase it to max power since there is no communication between the mdot and conduit, should the mdot reduce the lowest DR on its own say SF10 as its default, until communication is restored at which point the ADR may set it back to a lower data rate/higher data rate?

Also btw, when the custom application we built starts up in the mdot, by default it sets the DR to SF10. Its the ADR which upped the DR to SF8BW500.

Thanks,
Ajay.

[Jason Reiss]

— But for the conduit to lower the rate, it needs the mdot to communicate with it right?

Since this is not possible, this is not what is happening. “It” can only be the device.

The lack of ACKs from the server is the indicator to the device that the packet is lost. At which point the device will raise the power and begin to lower the datarate to regain connectivity.

[Ajay K]

Thanks Jason, But that did not happen then. Then my initial concern that it was stuck at SF8BW500 and the device did not adjust the transmit power or lower the data rate. How do we address that at this point, if the device was expected to do that with Ack’s enabled and ADR enabled?

Thanks,
Ajay.

[Jason Reiss]

ACK is enabled above 2 retries

AT+ACK=8
or
setAck(8)

[Ajay K]

So in my application currently I have setAck(1), so I need to change it to 8 that is after 8 retries it will switch the data rate and/or transmit power? Just curious why pick 8?

Thanks,
Ajay

[Ajay K]

Also is there a delay between retries when Ack fails?

Thanks,
Ajay

[Ajay K]

Hi Jason,

Setting the Ack retry count to 8 didn’t help either. It just keeps retrying and doesn’t seem like it is scaling it back to SF_10. I am not sure how to attach a file here, so I could share the trace o/p of the mdot?

Thanks,
Ajay

[Jason Reiss]

Please open a support ticket and attach debug output files and configuration information to the ticket.

Thanks.

[Author]

Posts