OTAA device rejoins every 10 minutes


#1

I have a class C device in the US band. It was initially able to join the server without issue, but is currently trying to rejoin every 10 minutes.

The device uses mac version 1.0.2; the server is set to the same.

Per a thread I found I profiled a join request via MQTT:

– ACK –
{“mac”:“647fdafffe0057f4”,“time”:“2019-03-15T17:56:32Z”,“latitude”:48.1111,“longitude”:-123.1111,“altitude”:41,“rxPacketsReceived”:2,“rxPacketsReceivedOK”:0,“txPacketsReceived”:0,“txPacketsEmitted”:0,“customData”:{“ip”:“24.108.19.87”}}

– RX –
{“rxInfo”:{“mac”:“647fdafffe0057f4”,“timestamp”:2849382233,“frequency”:903000000,“channel”:64,“rfChain”:0,“crcStatus”:1,“codeRate”:“4/5”,“rssi”:-79,“loRaSNR”:10.5,“size”:23,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:8,“bandwidth”:500},“board”:0,“antenna”:0},“phyPayload”:“AMD6e2xqotYFy5A33iVJbwjtsUEcPoE=”}

– TX –
{“token”:49260,“txInfo”:{“mac”:“XXX”,“immediately”:false,“timestamp”:2854382233,“frequency”:923300000,“power”:20,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:7,“bandwidth”:500},“codeRate”:“4/5”,“iPol”:true,“board”:0,“antenna”:0},“phyPayload”:“IENvoBkJY9cnV/d+99nqbEc=”}

– RX –
{“rxInfo”:{“mac”:“XXX”,“timestamp”:2855180851,“frequency”:903000000,“channel”:64,“rfChain”:0,“crcStatus”:1,“codeRate”:“4/5”,“rssi”:-77,“loRaSNR”:10.8,“size”:22,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:8,“bandwidth”:500},“board”:0,“antenna”:0},“phyPayload”:“QEdUMACAAAACmA+w8R9Ue1t7hKPFVg==”}

– TX –
{“token”:15030,“txInfo”:{“mac”:“XXX”,“immediately”:false,“timestamp”:2856180851,“frequency”:923300000,“power”:20,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:7,“bandwidth”:500},“codeRate”:“4/5”,“iPol”:true,“board”:0,“antenna”:0},“phyPayload”:“YEdUMACMAAADAP//AQUIaOKMCAHshYI6”}

– ACK –
{“mac”:“XXX”,“time”:“2019-03-15T17:57:02Z”,“latitude”:48.1111,“longitude”:-123.1111,“altitude”:38,“rxPacketsReceived”:3,“rxPacketsReceivedOK”:2,“txPacketsReceived”:2,“txPacketsEmitted”:2,“customData”:{“ip”:“1.2.3.4”}}

Has anyone arrived at a definitive answer to this issue?

Thanks in advance,
Jeff


#2

If the node isn’t hearing the join accepts (or for some reason is rejecting them) that would be understandable. Is it nearby? Does it work if you switch it to ABP?

Your MQTT capture is mixing what matters in with periodic status messages that don’t, and even in the ones that might be join / accept traffic, you’d have to base64 decode and pull apart the packets to tell.

Watching the live lorawan frames in the loraserver page for the node may be simpler, unless you want to write code to interpret the MQTT feed in a custom way.


#3

Thanks for your reply.

The device does not exhibit the same behaviour on TTN.

RE: ABP - good idea - I’ll try ABP as a diagnostic. The gateway is literally 3 feet from the device, so I doubt proximity is an issue.

The application that the device integrates with does perform some controls via downlink - these seem to work flawlessly.


#4

You may have the node too close to the gateway. When its on TTN are you using the same gateway and the same separation?

The gateway will most likely transmit with higher power than the Node, so the Node’s receiver is likely to overload before the gateway’s receiver. This could explain what you are experiencing.

Try moving the node to an adjoining room, the wall and extra separation will reduce signal strength.


#5

Thanks Tony.

I hadn’t considered that it’s too close, but the unit is in the same spot when using TTN. I will look into whether or not moving it affects anything, however.

Thanks for the help!


#6

FYI, everyone (and thanks @Tony and @cstratton), we appear to have found the source of the issue. We adjusted the class C downlink timeout to 10 seconds and the device OTAA requests have stabilized.

Cheers!


OTAA Class C device