Add RxDelay to LoRaWAN Configs

[lthiery]

Some users experience latency issues using Helium-hosted Router/Console and/or cell-based gateways. The default RX_DELAY of 1 second might be too tight. If a user could configure RX_DELAY, this would allow them to improve their change of receiving a downlink in time.

[jdgemm]

hi @lthiery can you confirm what the max range allowable would be on the miner side?

[michaeldjeffrey]

If there's a chance Miner's will drop packets on the ground if the delay is not what they're expecting, it would be nice for router to get notified somehow that something was wrong with the timestamp.

[lthiery]

If there's a chance Miner's will drop packets on the ground if the delay is not what they're expecting, it would be nice for router to get notified somehow that something was wrong with the timestamp.

I think it would be nice if the Miner/LightGateway responded with the packet forwarder's error message (or tx_ack with no error, or timeout on waiting for tx_ack). These all happen in case of an issue but are not responded back to OUI operator who requested the transmit:

 Value             | Definition
:-----------------:|---------------------------------------------------------------------
 NONE              | Packet has been programmed for downlink
 TOO_LATE          | Rejected because it was already too late to program this packet for downlink
 TOO_EARLY         | Rejected because downlink packet timestamp is too much in advance
 COLLISION_PACKET  | Rejected because there was already a packet programmed in requested timeframe
 COLLISION_BEACON  | Rejected because there was already a beacon planned in requested timeframe
 TX_FREQ           | Rejected because requested frequency is not supported by TX RF chain
 TX_POWER          | Rejected because requested power is not supported by gateway
 GPS_UNLOCKED      | Rejected because GPS is unlocked, so GPS timestamp cannot be used 

[lthiery]

hi @lthiery can you confirm what the max range allowable would be on the miner side?

I can't find a hard limit other than 255 seconds because that's how big the field is. I would suggest constraining it to 1-5 seconds so that we don't exceed the Join Delay.

[lthiery]

Also, generally recall that RX2 hangs off of RX1. As per the regional spec, for all regions:

RECEIVE_DELAY2 = (SHALL be RECEIVE_DELAY1 + 1s)

[buzzware]

TTN uses a default of 2 seconds, such should solve the problem I reported in #517. If it became configurable, likely every non-US user should be advised to set it to 2. Joins use 5 seconds. Why not make 2 seconds the default? Already joined nodes would carry on unaffected until they rejoined. New joins would include the new rxdelay value. It should dramatically reduce downlink problems and uplink retries and battery consumption and support issues without users doing anything.

[mkuyper]

I can't find a hard limit other than 255 seconds because that's how big the field is. I would suggest constraining it to 1-5 seconds so that we don't exceed the Join Delay.

LW1.0.4 6.2.6 Join-Accept frame:

The RXDelay field sets the downlink RX1 delay and follows the same convention as the Del field in the RXTimingSetupReq command.

[lthiery]

I can't find a hard limit other than 255 seconds because that's how big the field is. I would suggest constraining it to 1-5 seconds so that we don't exceed the Join Delay.

LW1.0.4 6.2.6 Join-Accept frame:

The RXDelay field sets the downlink RX1 delay and follows the same convention as the Del field in the RXTimingSetupReq command.

Thanks for that reference, @mkuyper

[pvolodin]

@buzzware @lthiery

Why not make 2 seconds the default?

Taking the Helium specific into account, I believe the default RECEIVE_DELAY1 value should be high enough, something like 5 sec used for JOIN_ACCEPT_DELAY1.

Higher delay hardly can cause any harm to anyone, but can save a lot of time for the less experienced ones.

Imagine someone (not very experienced) who owns a nomadic device like an asset tracker or just is going to test the coverage in a new (for him) territory with a device like Adeunis FTD. That person obviously knows nothing about the miners/gateways which will surround his node on its way and doesn't know how they are connected to the internet. So she or he tested the device in the office, got the great results, and is now expecting the even greater results in the fields. But actually she/he will lost her/his pallet or get no Helium coverage in the area as the fields are actually located somewhere at the Earth's end where cellular/internet connectivity is very poor, the delays are very high, and that (not very experienced) person was just unable to properly interpret the vague mention of some settings somewhere on Helium help page.

And if someone really needs the shorter delays - she or he probably knows what exactly he wants and is experienced enough to make right decisions. It shouldn't be hard for him to find the needed setting and change its value.

P.S. Regarding Adeuins FTD - that's a real life example ;-)

[dpezely]

Rx_Delay has been deployed to Staging with tag 2021.12.17.0

[buzzware]

The TTN default RxDelay is actually 5 seconds, not 2 mentioned above and elsewhere, and I have been decoding JoinAccept RxDelay wrong up until yesterday, giving spurious values. You can't just dump the packet into https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh This tool does it correctly https://github.com/buzzware/decrypt-join-accept