on my LoRaONE i have realized that the used Spreading Factor is beeing automatically increased by the device over time.
It starts with SF7 when i boot it and it gradually increases over time SF 8, 9, …
There are no ADR MAC commands from the network side. The radio signal is very good and constant (RSSI:-22 SNR:9.75 ESP:-22.4373), so no need to use any other SF than 7.
Does anyone have an idea where the used SF is controlled? Is this an RN2483 internal functionality?
thanks,
marc
Are you using LoRaBee.send instead and not LoRaBee.sendReqAck, using the latter would show the behaviour over time as you descibe.
I am using the code from the LoRaWAN tutorial on the sodaq website with the difference, that i enabled confirmed uplink.
switch (LoRaBee.sendReqAck(1, testPayload, 5, 3)) //switch (LoRaBee.send(1, testPayload, 5))
I can see that the confirmation messages from the network are being sent and the reported RSSI values are between -20 and -30 dBm always (i have a gateway just besides the sodaq module). So no need to increase the SF.
I am using ABP with ADR set to ‘false’.
LoRaBee.initABP(loraSerial, devAddr, appSKey, nwkSKey, false)
I can give it another try with ADR = true. Even though i don’t think it would be very logical since ADR = False means not to change the SF at all.
I noticed the same thing. I am using the pre-loaded SodaqOne-UniversalTracker firmware with OTAA without any modifications. It started with SF7, after a while it switched to SF8, SF9 and now SF10. I did not enable acknowledgements.
See my latest log entries:
I changed the config to use ADR.
LoRaBee.initABP(loraSerial, devAddr, appSKey, nwkSKey, true)
The increase of the SF over time is still happening. Also now i can see that if the sodaqONE is increasing the SF, the network is trying to move it back to SF7 (DataRate = 5). You can see that there is MAC commands happening after the change to SF8.
The device confirms MAC ADR command but does not actually change the SF back to 7. See below.
Maybe if anyone from the sodaq team could provide some feedback?
On how we could continue some troubleshooting a) on the automatic increase of SF we see and b) on the issue we see that the device is not reacting to MAC ADR commands.
These two issues are critical, if one wants to go and use such a device for production purposes.
Further details of the commands available on RN2483 can be found here:
I have a suspicion that the device is not receiving those down-link messages, or more specifically the ADR acknowledgement.
The device is increasing the spread factor [SF] which results in a decreased data rate [DR]. [See section 7.1.3 of the LoRaWAN specification.]
In section 4.3.1.1 of the LoRaWAN specification:
If no reply is received within the next ADR_ACK_DELAY uplinks (i.e., after a total of ADR_ACK_LIMIT + ADR_ACK_DELAY), the end-device may try to regain connectivity by switching to the next lower data rate that provides a longer radio range.
My initial theory is that the device may be entering sleep mode before the acknowledgment received. I haven’t looked at the code though.
It’s not that. Even with unconfirmed messages (no ACK) the spread factor increases over time on the Sodaq One. I looked at the source code and the sf is never set. So I suspect the default behavior of the RN2483 is to increase the spread factor, even if there is no acknowledgement or ADR configured.
I think the firmware needs to be modified to include mac set dr 0 (for SF7) in the initialization to avoid the unwanted increase of the spread factor.
There are two separate types of acknowledgment, ACK [for message acknowledgement] and ADRACKReq. [See section 4.3.1.]
So even in the case of unconfirmed data messages, if the ADR bit is set, the device will expect a MAC command response [see section 5 for details].
I believe the increase in spreading factor is due to the device not receiving the expected MAC command responses and then using the optional behaviour specified in section 4.3.1.1.
The specification can be found here:
https://www.lora-alliance.org/portals/0/specs/LoRaWAN%20Specification%201R0.pdf
If you are able to load a modified version of the tracker, you can test this theory by commenting out line 840 of SodaqOneTracker.ino
LoRaBee.sleep();
This will stop the RN2483 module from entering sleep mode, the wakeUp() command should still work fine. This should keep the RN2483 awake regardless of the state that the main MCU is in. However, if you want to keep the MCU awake as well, then uncomment the #define DEBUG definition on line 48.
Gentlemen,
I found the following (under the circumstances that I don’t receive data from the gateway) with ADR = on:
Non- confirmed messages (LoRaBee.send(1, data, 3)), the powidx and DR are NOT changing during consecutive sends
Confirmed messages (LoRaBee.sendAck(1, data, 3)), the powidx and DR are changing during consecutive sends
I could verify this on ThingPark and I also used “getMacParam(“dr”);” and getMacParam(“pwridx”) on the 2483 confirming this.
I was expecting that the 2483 would adapt the DR and PWRIDX in both cases. Why seems this not be the case?
Axel