OTAA Long Range Join

End Devices (Nodes)
1

Hi there,

over the last month i learned a lot about LoRa and LoRaWAN. About all kind of specifications and rules.
Im using a TTIG and two seperate TheThingsUno´s to collect enviromental Data like Temp/Humidity/Soil Mositure.

For my Thesis one last thing is to perform some kind of Distance Test so that i can provide information about the different SF´s and Ranges.

Before i can ask my question i need to provide a bit of background:

When im setting up my Nodes (standart QuickStart config) im sending with SF7 and 125BW. My TTIG and the Gateway of the university get the Data. The university GW is about 1,2 km far away… and still recieves the Signal with sf7 (Its stationed on a high building). So for my Testing i thought i can ride to some locations in variable distance to see if the node can send Data to the gateway. First i did not set the ADR bit. I did this now and at home it works perfectly. If i set the Default SF to 9 or 10 it will automatically set the SF to 7 after about 64 Messages. But if i set the Default SF to 11 or 12 it wont join. The otaa wont work. Ive read a lot of topics that the RN Chip has some kind of problem with joins on sf 11/12 caused by the receiving windows.

So my question is:

What is the best way to test the distance coverage? Should i let the node join the network via otaa, drive a bit farer away and wait till the adr adapts the new SF? Or should i set the Default SF to 10 and see if the Node joins the network from the new (more distance) position?

Can i change the amount of Uplinks needed for adr to take action?
How does the Node function if i join the network on 10 and drive further away… The node wont reach a Gateway anymore. Does the ttn.reset perform a “internal” ADR controlled by the node itself? Reading the specification of LoRaWAN it should. How much “failed” uplinks does it need to perform a “intern” ADR correction?

If you have any further question let me know. I understand its maybe kinda hard to understand my questions and they are sounding a bit confusing but i hope you can get my question right :slight_smile:

Thank you

2

Range tests and coverage mapping are often done with ABP and without ADR.

While OTAA and ADR mechanisms are good for deployed nodes that have a chance to form a join session and where adapting to long term changes in gateway coverage, for your kind of test you want to more quickly find out “can it work from here”.

So for example you might configure uplinks alternating between a fast and slow SF, and just turn it on to transmit a few packets from a given location.

Then look on the data feed and see if even just your uplinks are getting through, even without any downlinks in the reverse direction being received, or not, which might be due to some issue with slow SF reception and not simply range.

1 Like
3

@cslorabox

so you mean i should implement ABP. Go to a specific location and set the SF to lets say… 9. If no GW receives it i need to recompile and upload to SF 10 and try it one more time… and so on. Did i understand that right?

4

Approximately. I might just make the firmware alternate between two SF’s on its own.

Or just use only the slow one, but keep the packets small and infrequent and only enable it for a few packets at a time.

Do keep in mind the frame count rollback issue…

5

Thanks. I just tested it and it works… so what do you mean with Frame count rollback.

Do you mean if i reset the node all over again and again that the gw might keep track of the Frame Count and wont accept the packages?

6

Not the gateway, gateway’s don’t really do much of anything.

But yes, the network will, as that is required by the LoRaWAN specification.

However there is a checkbox in the node’s information on the network to disable the check for debug purposes.

7

Yep i tested it with and without the checkbox and everything worked. without the checkbox im able to change the sf rapidly (with recompiling). With the check it wont show up in TTN. Thank you very much. That way i can finish my thesis :slight_smile:

8

There’s even an official (and may I say: confusing) name for that: Blind ADR.

Unless you wait for the uplink counter to be larger than the last value that TTN knows, or unless you click “Reset frame counters” each time you upload a new version. You could also automate that, using ttnctl devices set my-device-id --fcnt-up 0 --fcnt-down 0.