LTE-M Reconnect after LoS

[ibiglari]

Hi,

I am using Thingy 91 in Australia, and I have linked Asset Tracker v2 with overlay-lwm2m.conf to communicate with my own LwM2M server, which is running an instance of Leshan server. Thingy 91 has no problem communicating with my server in both passive and active mode, as long as the cellular link is stable. I took it for a drive, but when I got home, I realised it had stopped sending data to my server as soon as I had entered my underground parking, even though the LED would dutifully blink green and teal every two minutes, just like you'd expect it to behave in active mode. When I connected to it via LTE Monitor I realised the LTE link is disconnected and Thingy 91 cannot reconnect. Recycling the power easily resolved the problem, so I decided to simulate LoS by wrapping it in aluminium foil. Once again, connection was lost and could not be established until either the power was recycled, or I'd issue AT+CFUNC=0 followed by AT+CFUN=1 via LTE Monitor.

My question is, what is the expected behaviour of the modem in case of LoS? Does it not try to reconnect by itself? Does the software have to monitor link connection and recycle the power on the modem if it is unable to establish a link?

I am using nRF Connect SDK v2.0.0, with modem firmware 1.3.2.

Steps tp reproduce:

1. Compile Asset Tracker v2 with overlay-lwm2m.conf (modified to connect to your own LwM2M server).
2. Change /50009/0/0 (Passive Mode RID) to false via the server as soon as Thingy 91 registers with it.
3. Wait a few minutes and see data coming in.
4. Wrap Thingy 91 in aluminium foil for at least 5 minutes to make sure it experiences LoS for at least one ping.
5. Unwrap Thingy 91, plug it into LTE monitor, and monitor modem status

Kind Regards,
Iman

[Achim Kraus]

That's a lot of information, so I'm not sure, if my experience matches this case. Hope, I don't mix up more, than I help.

I was faced a similar behavior just using a UDP socket for CoAP with my own DTLS CID implementation (eclipse/tinydtls), see How to recover a nRF9160 from sporadic ENETDOWN .

if the mobile network gets lost, and data tried to sent, you get a ENETDOWN error. If so, you need to close the socket (seems to apply to UDP as well) and wait until the network is back (callback with LTE_LC_EVT_NW_REG_STATUS). Then open the socket again.

That gets a little more complicated, if PSM is enabled and active. Then you may first wait for the LTE_LC_EVT_NW_REG_STATUS callback after starting to send data. If that times out, i switch into flight mode, and try it about 5 minutes later and double that time on every retry. After a couple (e.g. 2h) I reboot my device in order prevent it from stick in some bugs.

That works for me now quiet well, a 2 weeks test with some areas without connectivity have all been mastered and the thingy always connected back.

[Achim Kraus]

Maybe, if you're interested, if that approach would help also in your case, try out Zephyr - coaps client / tinydtls CID. if that works before your garage, and stops working in the garage, you will see, if it reconnects afterwards.

Good luck.

[ibiglari]

Will try to over the weekend... Just got a big project off my back... Had a quick look at the repo and well done!