2 LoRaWAN Nodes went for a train ride through the Netherlands….

[PiAir]

I took the LoPy (and a Marvin node) with me on a 2,5 hour train ride through the Netherlands. The LoPy tried to send messages through TheThingsNetwork, the Marvin via KPN (commercial LoRaWAN network in the Netherlands).

Full post here

One question I have after the test is why the LoPy only transmitted using SPF7 while the Marvin often switched to SPF12. I will try to connect the LoPy to KPN also and run similar tests to see if it switches spreading factor in those cases.
Anyone know more about how a node decides what SPF to switch to? I don't see anything in the code for either of the nodes that would suggest switching.

[RobTuDelft]

What is Adaptive Data Rate (ADR)? Adaptive Data Rate is a method where the actual data rate is adjusted to ensure reliable packet delivery, optimal network performance, and scale for capacity. For example, nodes close to the gateway will use a higher data rate (shorter time on air) and a lower output power. Only nodes that are at the very edge of the link budget will use the lowest data rate and highest output power. The ADR method can accommodate changes in the network infrastructure and support varying path loss. To maximize both battery life of end ‐ devices and overall network capacity, the LoRa network infrastructure manages the data rate and RF output for each end ‐ device individually by implementing ADR

From here.

My LoPy does the same by the way on the KPN network, always SF7.

[jmarcelino]

@PiAir
The only mechanism for automatic switching is Adaptive Data Rate(ADR) however - as the page I linked to says - you should not use this for moving nodes because it uses a sample of the last 20 transmissions.

On a moving node by the time you have 20 samples the result will likely be wrong for the current location.

In any case you can enable this on the LoPy by setting adr=True in the LoRa() init.

In some modules you can set SF12 manually ( or any high SF > 9) but that's not encouraged (or allowed if we go by the latest draft) in the LoRaWAN spec for public networks and indeed TTN is planning to cut out nodes that do it - SF12 is really heavy and sucks the air(time) out of the network.

On the other hand some networks (which don't implement ADR) require it. It's a confusing situation, compounded by some issues in the TTN ADR implementation.

[PiAir]

I understand from this page that in LoRa.LORAWAN mode, only adr, public and tx_retries are used and that sf=7 by default, but also dat adr=false (so Adaptive Data Rate is off by default, why?). And so since my code (basically the default code from github) does not contain the initialisation, it makes sense that it sticks to SPF=7 (with ADR being off).

Next test: switch ADR to true and test again.

[jmarcelino]

ADR is off by default because:

1. ADR should only be enabled for static nodes
2. Many public networks still don't have working ADR

[PiAir]

@jmarcelino said in 2 LoRaWAN Nodes went for a train ride through the Netherlands….:

ADR is off by default because:

1. ADR should only be enabled for static nodes
2. Many public networks still don't have working ADR

OK, did not know that, and it does make sense if the rational is that the node would probably not be in range long enough for the gateway to tell it to change the SPF.
Apparently the Marvin does have ADR enabled by default (I didn't set it there either) and the KPN LoRaWAN network here in the Netherlands "tells" the node to change the SPF. So shouldn't we be able to set the SPF higher than 7 for moving nodes like the ones in my experiment? Because in this use-case, the node will miss a lot of gateways on route that would be in range if it used a higher SPF.

[PiAir]

@jmarcelino said in 2 LoRaWAN Nodes went for a train ride through the Netherlands….:

@PiAir
The only mechanism for automatic switching is Adaptive Data Rate(ADR) however - as the page I linked to says - you should not use this for moving nodes because it uses a sample of the last 20 transmissions.

On a moving node by the time you have 20 samples the result will likely be wrong for the current location.

In any case you can enable this on the LoPy by setting adr=True in the LoRa() init.

In some modules you can set SF12 manually ( or any high SF > 9) but that's not encouraged (or allowed if we go by the latest draft) in the LoRaWAN spec for public networks and indeed TTN is planning to cut out nodes that do it - SF12 is really heavy and sucks the air(time) out of the network.

On the other hand some networks (which don't implement ADR) require it. It's a confusing situation, compounded by some issues in the TTN ADR implementation.

Sorry, had not seen this earlier reply which answers the questions I asked a few minutes ago. :)

[PiAir]

This post is deleted!

[PiAir]

Correction to my previous comment, the default Marvin code contains the send_LoRa_Command("mac set adr on"); command.
So indeed it switches on ADR on purpose and not by default.