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

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).

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.

@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. :)

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.

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).

@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.

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