Some potential fixes for the lte modem (constantly returning camped for at!="fsm)

[HKhaan]

Please include the following information when submitting a bug report:

• The Pycom board you are using (e.g. WiPy 2.0, LoPy).
• G01
• The firmware version you are using. You can get it by executing the following
• custom esp-idf firmware.
  We have a custom esp-idf firmware that has lte modem code heavily inspired by the pycom lte modem code. One thing we noticed was this line
  

  pycom-micropython-sigfox/esp32/mods/modlte.c

  Line 288 in a37510c

  if ((pos = strstr(modlte_rsp.data, "+CEREG: 1,1")) || (pos = strstr(modlte_rsp.data, "+CEREG: 1,5"))) {

  
  same thing happens 5 lines above.
  it only checks 1,1 & 1,5. Looking at the sequans monarch documentation 2,1 2,5 3,1 and 3,5. also means it's connected. the if statement should be extended to check these values too.
  the first 1 means enable network urc. when it's 2 it's enable network urc + location information. for 3 it's enable network urc + location information + EMM. So essentially it's just a network with extra functionality. But it gets ignored by the library.

We also noticed that when you connect at location X and move your device to couple city further it doesn't connect for a very long time (sometimes it just doesn't connect at all). We don't know if it's true but we theorized about the modem caching some information. When we notice that the modem can't connect for a long time (returns camped on at!="fsm") we execute AT&F and restart the whole connection process (at&f puts the settings to factory settings). Maybe it could be usefull if the at&f command was also added on a method called factory_reset with an explanation of it helping out when you constantly get camped. We have seen other people having this same issue on forums while trying to find a solution.

[scottbasgaard]

@HKhaan super interesting what you found here and I believe it's related to the issues I've been experiencing all along.

It doesn't seem like there is much activity in this repo over the last year sadly though. I wonder what the plan is moving forward from Pycom here.

[scottbasgaard]

https://forum.pycom.io/topic/6493/fipy-lte-won-t-attach must be the same.

Going to try your suggested fix here @HKhaan but our team is having problems compiling on the new Apple Silicon chip so trying something else.

Will let you know how our tests go!

The other option is probably to just rewrite the is_attached command ourself with our own AT commands so we don't need to use the is_attached() method?

[HKhaan]

https://forum.pycom.io/topic/6493/fipy-lte-won-t-attach must be the same.

Going to try your suggested fix here @HKhaan but our team is having problems compiling on the new Apple Silicon chip so trying something else.

Will let you know how our tests go!

The other option is probably to just rewrite the is_attached command ourself with our own AT commands so we don't need to use the is_attached() method?

Another thing you should try is to update the modem.

We also had issues with caching on the lte modem. It sometimes caches the environment to connect faster next time. But I have had scenerios where it couldn't connect for a month straight (maybe corrupt cache?). Using the command "at&f" (factory reset) and restarting the whole lte connection process.

Since these two changes to our code. The lte modem has been super stable without any issue for couple months now.

[scottbasgaard]

@HKhaan thanks for the additional feedback.

We're still really struggling unfortunately and since this product line is going to be discontinued end of the year we're trying to figure out what to do next.

Basically everything "works" for a period of time before some point things go haywire and the units freeze. Just when we think things are working something goes wrong and the modem freezes.

If you have any tips I would love to have a quick chat to see if there's anything you can see we are totally missing here so just let me know.

All the best,
Scott

[scottbasgaard]

@HKhaan

Using the command "at&f" (factory reset) and restarting the whole lte connection process.

So basically AT&F followed by AT^RESET.

We still are really in a rabbit hole with 40 devices in the field that work and after some days / weeks get stuck and need to be manually restarted (cycling power) gets them back.

[scottbasgaard]

@ELundby45 this helped you as well?

[ELundby45]

@scottbasgaard It helped, but really the only way we have found to have any long term reliability was described here.

There have been several times I have observed the GPy be unable to attach to LTE repeatedly, even after power cycles. The only way I have found to recover from this is sending the AT&F.