lorawan_tx keeps talking to deceased

[tobiasdam]

lorawan_tx keeps sending messages on a joined connection, after the lorawan containers on the gateway are stopped. Is this intended behaviour?

[hruotsalainen]

Yes this is intended behaviour for non-acknowledged messages. LoRaWAN device gauges link state by mac commands every now and then, which means that if gateway dies, there will be automatically ~50-100 packet loss before lorawan_tx figures out the link is dead.

[tobiasdam]

using ack messages every now and then could be useful to evaluate if the connection is still alive

[hruotsalainen]

Acks should work. Another (better?) option would be LinkCheckReq LoRaWAN mac command, which is introduced in 1.0.3 exactly for this purpose.

[tobiasdam]

is our lmic library able to do that?

[hruotsalainen]

Apparently it can be set via LMIC_setLinkCheckMode function. I'll investigate

[hruotsalainen]

Turns out this is already enabled, but because of:

enum { LINK_CHECK_CONT = 12 , // continue with this after reported dead link LINK_CHECK_DEAD = 24 , // after this UP frames and no response from NWK assume link is dead LINK_CHECK_INIT = -12 , // UP frame count until we inc datarate LINK_CHECK_OFF =-128 }; // link check disabled

in lmic.h, the link will be announced dead first after several packets.

[hruotsalainen]

For private gateway deployments we could increase LINK_CHECK_INIT and decrease LINK_CHECK_DEAD to arrive faster to a conclusion about link status

[tobiasdam]

I tested this feature, but I don't think it is working as intended

074519967 Debug: LINK_DEAD
Scheduling a lorabridge_data string...
String copied to LMIC buffer
String sent to LoRaWAN TX
Timestamp: Fri Sep 16 09:48:53 2022
LMIC: Updating TX parameters
LMIC: Frequency: 868500001
LMIC: TX Power: 14
LMIC: Airtime: 48590
LMIC: globalDutyAvail: 0
074578090 Debug: EV_TXSTART
Frequency: 868500000
074578091 HAL: Sending ...
Frequency: 868500000
074584622 HAL: Receiving ...
074584622 HAL: Wait until 074584623 ms
Frequency: 869525000
074585622 HAL: Receiving ...
074585622 HAL: Wait until 074585623 ms
074585788 Debug: REJOIN_FAILED
LMIC: Updating TX parameters
LMIC: Frequency: 867700000
LMIC: TX Power: 14
LMIC: Airtime: 45771
LMIC: globalDutyAvail: 0
074587659 Debug: EV_TXSTART
Frequency: 867700000
074587660 HAL: Sending ...
Frequency: 867700000
074590080 HAL: Receiving ...
074590080 HAL: Wait until 074590081 ms
Frequency: 869525000
074591105 HAL: Receiving ...
074591105 HAL: Wait until 074591106 ms
074594757 Debug: TXCOMPLETE
Scheduling a lorabridge_data string...

After some time, there is a LINK_DEAD message, but data is sent anyway (even after REJOIN_FAILED)

[hruotsalainen]

@tobiasdam Thank you for testing the feature. Did you change the link_check limits too?

[tobiasdam]

no, I just tested it as is

[tobiasdam]

for documentation purposes: the connection is resumed with a LINK_ALIVE event