XBee3 LTE-M/NB-IoT dropping connection

Question

Hello,

I have been developing some prototypes with the XBee3 Cellular versions and keep having an issue.
The devices stop sending data after about 10 to 12 hours or so. Sometimes a device will maintain connection for days.

I have some fairly simple micropython programs that read a sensor and send the data to our API endpoint using MQTT (using the 'simple' library). Everything runs in a loop and fires at the set intervals which are currently about 10 minutes. One of my devices goes to sleep after reading the sensor and the other stays alive for it's life (rain gauge counting tips).

I did program a hard reset (machine.reset()) so the devices reset after about 6 hours. I was hoping this would clear out any jam that may be occurring, but it hasn't worked. Has anyone experienced this?

Answer 1

I am also facing the same issue using Xbee3 NB-IoT module.

Where it stops working after an arbitrary amount of time, which varies between 2mins to 17hours.

I am using deep sleep in between the transmissions.

Even though I have programmed in a machine.soft_reset() in the code in case it fails to connect to the network/internet after 30 tries(2seconds interval), it does not seem to work. That means even if it is rebooting, it is not getting connected to the internet/network.

If anyone found any solution please do share.

Comments

Are you using Digi's MQTT "simple.mpy" library?

---

Yes.

In my case, sometimes, the module would not even connect to the network.
Sometimes even if I get AI=0, it would not connect to the server or give me a DNS error. Where 5mins ago it worked just fine.

---

So there is a few things you might be running into.  

There was an issue with the uBlox chip that would block the modem - there was a recall/bullentin that you should have seen.  The work around was to allow at least 30 seconds of time to pass from the connection establishment to disconnect.  Since mine was doing something simple, I was having the XBee wake up, do it's stuff, than back to sleep.  This occurred within 30s, but eventually the device would become unreachable.  Adding a 30s delay at the end of the program improved this.  

The second thing I learned is that you should be managing the cellular connection status within your program.  In other words, just don't send the device to sleep without first disconnecting from the network.  After doing this, I had more improvement.  The easiest thing to do is to put the modem into airplane mode before sending it to sleep.  I left a short delay between setting to airplane mode and sleep (I think about 5 seconds).  This delay just gives it time (in my mind at least...) to do it's thing.  Someone that knows more than me on the hardware front could tell you how long it takes for the modem to actually run through it's shutdown process.

So a few more questions for you: is your program hanging/freezing somewhere?  If so, which operation is it hanging on?  Or is it just waiting for a cellular network connection and gets stuck there in a loop waiting for a connection?  

Also, inside Micropython, there is a function to check the cellular network connection.  There is no need to utilize the AT commands via python for this.  I believe it is in the "Network" library.  

What I have been doing for our code is make the program check for a cell connection before doing anything else.  If there isn't one, it sits in a loop and waits for the connection.  If there is no connection after sometime, I have the module perform a soft reset.  If the issue persist, then the I have the module perform a hard reset.  The soft reset will retain the variable values, so you can use that as a counter to track connection attempts.  I typically just use a 5 or 10 second delay between checking for cellular connections.  When everything is running "normal" the cellular connection takes seconds to establish, so stopping to check for a cell connection doesn't cause too much of a delay.  

When using the simple MQTT library, make sure you check the connection to your MQTT server as well.  It contains a similar method for checking the server connection status.  If something sticks, try reseting the connection to the server.  Issue a disconnect, then a connect.

If you are hanging on the simple.connect() function, let me know.  There is a trick to get it to throw an error.  I don't know if the forum would allow a code snippet easily, so it might be easier to find another channel to show you (i.e. email, Git, etc.).

Answer 2

Are you certain that you are in fact doing the machine.reset()? Can you confirm this is indeed happening? If you don't have the ability to print, you could do something like toggle and save the state of a PIN so that it can be seen after reboot (for example ATD05 and then ATWR would set DIO 0 (pin 20) high and save this state so that it persists after reboot). Or you could write something to the file system.

Also can you confirm the MicroPython program is still running? Again if you don't have print capability, you can have the MicroPython program toggle one of the DIO pins periodically in a way that you can easily measure with a MultiMeter.

Is there anyway you can get the ATAI value? This would should give the current state of the modem.

Comments

Yes, I confirmed the Python code is still executing.  I used XCTU's recording tool and found it was hanging on the connect() function associated with the simple.py MQTT library.  It gets to the function and then just hangs there and doesn't do anything - it never threw an exception either.  Just stalled out.  I have since modified the library to get method/function to throw an exception which can be easily handled.  So far, everything is working fairly well and haven't seen any more failures and the devices are staying up.