Cubecell stuck on SF7, ADR not working

#1

Hi all,

Having some major adr issues with the cubecell boards (dev board (AB01), capsule, OLED board).

Arduino programmer settings:
image

I have also changed the user channel mask to 0xFF00, so that I can connect to AU915 gateways.
It seems the device will get ‘stuck’ on SF7 when it is located further away from the gateways, and not change its SF to a higher setting. I’ve also observed that sometimes the node will only attempt to join at SF7 and only sometimes increase to SF10 to try a successful join attempt.

Here is a couple screenshots of a gateway sending downlinks that are trying to tell the node to increase its SF, its as if the node is completely ignoring them. I know it can receive down links as it was able to join the network and get session keys in the exact same location… Any tips on how to get ADR reliably working would be greatly appreciated.

image
image.png385×504 19.8 KB

image
image.png493×549 73.9 KB

image

If I can’t get ADR working, anyone know which line in the source code I could change to hard-code the SF to say SF10?

#2

bump
any tips?
bump

#3

Sorry. I did not see that the gateway tried to tell the node to increase SF. If you want to change SF to SF10, you can change DR_3 to DR_0 in the following file.

01
01.png1572×972 86.6 KB

At the same time, note that after changing SF to SF10, MaxPayload is 11.
02
02.png1642×967 101 KB

#4

Thanks for the advice Shaffer., your method allows me to hardcode the SF - however I really thought the Heltec modules would be somewhat ADR compliant which is one of the main features of LoRaWAN.

Has anyone else using the AU915Mhz frequency got ADR working?

#5

I’m US915, but the region should not matter.
If I’m not mistaken, the ADR data rate/spreading factor change support is close but I don’t believe it’s totally working.

If I recall the defined DEFAULT data rate and the data rate used for a successful join are both (in different spots in the code) overriding the data rate that is trying to be set when processing the SRV_MAC_LINK_ADR_REQ received from the network.

I have a fork of the repo where I do think it’s working although the network I’m using does not yet support network defined data rate changes. And some of my changes may not be for the best, and some may have influenced my understanding of the ADR support.

There is an outstanding question I have about processing a MAC response back to the network when such response plus user packet data would exceed the DR defined max. In the base version the packet is sent anyway, in my version the user data is not sent but I have implemented a return status back to the app layer.
I’m not sure the correct answer. In the first instance the spec is technically violated, in the second user data is lost though the app has an opportunity to resend.

There are other tweaks as well mostly around exceeding DR max packet size and a bunch more debug output messages. The top level readme and change log detail the changes,

NOTE: My forked repo is in no way sanctioned/approved/etc by Heltec. Use at your own peril.

#6

Thanks for that info leroyle, I’ll check out that fork and see if it makes a difference.

I have just a basic level of understanding of the ADR protocol, but I’m quite sure it is supported on the TTN network compliant gateways here in Australia, I know this because when I use different branded LoRaWAN devices, the SF changes dynamically during testing at shorter/longer distances.

By modifying the stock Heltec code I can join the network at a higher SF (SF10 for example), if I’m in the same room, the SF will then automatically decrease to SF7 (this is good, expected ADR behavior) - however, if I then move the node further away from the gateway, it will never automatically increase its SF, it will be stuck on SF7 forever. So it seems the heltec nodes have no problem automatically decreasing its SF, but will never increase its SF which is strange and very frustrating…

As you said, it looks like something is overriding the networks requested SF.

#7

ADR decreasing spreading automatically but not increasing it seems to rings a bell, like that’s part of the spec and it’s up to the device to increase it??,
I think I’ve seen that discussed somewhere, but where is fuzzy and I have no experience in using ADR in real life. I’ll see if I can find a reference and see if I was just reading sideways.

I’m playing in the Helium network space where ADR is not yet implemented.

I bit more poking around, re my fuzziness about not increasing SF.
As I understand it, and I’m open to correction,

  • the network suggested ADR changes should as you suggest increase/decrease depending on signal quality
  • the device side, if ADR is enabled and the device does not receive a downlink message from the network, either user data or MAC commands within a certain number of uplinks (I think 97 in Heltec default case) then the device runtime is to increase the SF(lower data rate), then wait for more uplinks to occur, then if still not response increase again(still lower data rate). This is the case I was thinking about when suggesting the SF changes would go one direction only.

I’ve done some testing with the device side ADR changes, but not with the network suggested ADR changes. Perhaps I’ll see if I can fake that out to see what might happen.