How to handle a LTE Connectivity loss

[SciWax]

Dear Pycom-Community,

yesterday I had an issue with my GPy. I send every 3 minutes Data via LTE-M. At some point, the GPy couldn't send data anymore, while it still told me, that my GPy is attached to the network and that a data connection is still there. Every time, before I send data, I check the connectivity:

print("Is LTE attached:")
print(lte.isattached())
print("Is LTE connected:")
print(lte.isconnected())

I've checked the site of the company, who provided the IoT SIM-Card and I could see, that my GPy was only attached to the network, but that there actually was no data connection.

I guess a LTE connectivity loss happened, mentioned here: https://docs.pycom.io/tutorials/networks/lte/

In the section under LTE connectivity loss, you can read the following:
If the connectivity is lost this will in general not be reflected when you check lte.isconnected().

Probably that happened for me. I contacted the SIM-Card provider though and they want to check, if something happened at their side. I will update the thread with their answer.

I've waited like 40 minutes for the modem to get a data connection again, but it didn't happen. Resets via the Reset Pin or the Reset button didn't help with the issue at all. After 40 minutes I did a power cycle, completely cutting off the power and afterwards, the GPy got a connection again and could transmit data, which is kinda concerning.

I thought about using lte.deinit() in this case and make a completely fresh start. Would this probably solve my issue? Any suggestion how to handle this situation to get a data connection going again?

Are there any plans to update lte.isconnected() to spot a LTE Connectivity loss every time it happens to react to that problem? @Gijs

Kind regards,

SciWax

[Gijs]

If the connectivity is lost this will in general not be reflected when you check lte.isconnected().

This is indeed true. when the modem is in data-connection state (PPP mode), we cannot send AT commands anymore. Thus, it is impossible to check in that sense. What you can do instead, is for example ping a known online host, and see if it responds to check the connectivity (and use this as your test_connection() function)

I've waited like 40 minutes for the modem to get a data connection again, but it didn't happen. Resets via the Reset Pin or the Reset button didn't help with the issue at all. After 40 minutes I did a power cycle, completely cutting off the power and afterwards, the GPy got a connection again and could transmit data, which is kinda concerning.

Yea unfortunately, the LTE modem is not connected to the reset circuitry, and only resets on a power cycle, so in that sense, this is expected behaviour.

I thought about using lte.deinit() in this case and make a completely fresh start. Would this probably solve my issue? Any suggestion how to handle this situation to get a data connection going again?

Depending on the state of the modem, this has the potential to solve your issue.

Let me know if that helps for you!

Gijs

[SciWax]

Thank you for the quick answer! My answers are under your inputs.

@Gijs said in How to handle a LTE Connectivity loss:

If the connectivity is lost this will in general not be reflected when you check lte.isconnected().

This is indeed true. when the modem is in data-connection state (PPP mode), we cannot send AT commands anymore. Thus, it is impossible to check in that sense. What you can do instead, is for example ping a known online host, and see if it responds to check the connectivity (and use this as your test_connection() function)

Thank you, that's worth implementing to see, if the Modem really is the issue here.

I've waited like 40 minutes for the modem to get a data connection again, but it didn't happen. Resets via the Reset Pin or the Reset button didn't help with the issue at all. After 40 minutes I did a power cycle, completely cutting off the power and afterwards, the GPy got a connection again and could transmit data, which is kinda concerning.

Yea unfortunately, the LTE modem is not connected to the reset circuitry, and only resets on a power cycle, so in that sense, this is expected behaviour.

So I can do nothing from the side of the GPy or the Arduino then to restart the modem? The Arduino also functions as a Watchdog for the GPy. I want to deploy the units in the field and manually resetting them, if the LTE connectivity drops is rather unfortunate. I hope that problem rarely happens then.

I thought about using lte.deinit() in this case and make a completely fresh start. Would this probably solve my issue? Any suggestion how to handle this situation to get a data connection going again?

Depending on the state of the modem, this has the potential to solve your issue.

Okay, I will only know, when it happens again though. I don't know, if I can force that issue artificially to test.

Let me know if that helps for you!

I will! Thank you for the suggestions.

Gijs

[SciWax]

I also have a Debug-File, which shows the error dumps, which happened during the whole data transmission test. Maybe something led up to it beforehand. I don't know, if that could be useful.

[Gijs]

@SciWax said in How to handle a LTE Connectivity loss:

So I can do nothing from the side of the GPy or the Arduino then to restart the modem? The Arduino also functions as a Watchdog for the GPy. I want to deploy the units in the field and manually resetting them, if the LTE connectivity drops is rather unfortunate. I hope that problem rarely happens then.

A right, you had the Arduino connected as well. From the Arduino, you should be able to power cycle the GPy in a disconnection state (through placing a mosfet on the Vin pin and driving it with the Arduino), which will also reset the LTE modem

Per the coredumps, I would like to redirect you here: https://docs.pycom.io/advance/coredump/. There can be lots of reasons for coredumps, but if you're always getting similar responses, it might be worth to do some checking

[SciWax]

Afterwards, I also changed the place of my antenna. Beforeand, it was lying under an USB-Cable, which provides power to the Arduino. The antenna was around 15 cm away from that cable. I do not know, if that maybe caused interference. Can I potentially protect my antenna with wrapping something around it, especially if alot of other electronic things surround it?

[SciWax]

@Gijs
Yeah, the MOSFET idea also came to my mind, but I was not sure, if the idea is appropriate. I will include that in my next PCB-Design. Thx for the suggestion!

[kjm]

You can indeed use lte.deinit() for a fresh start with a modem that thinks it's in a data state but has lost the connection. Then make a new lte which should allow you to reset it.

[SciWax]

@kjm
Thank you, that information helps alot. Getting closer to not moving my butt, if something bad happens to the GPy. :)

[SciWax]

I've mentioned, that I wanted to ask the SIM-Card provider, if anything happened on their end and this was the case. 2 days ago, they had network issues around the time, when my GPy lost its Data connection. They said, it only should have lasted a few minutes and that my device should have automatically come back afterwards.

I'm kinda glad, that that happened during my prototyping phase so I will take the appropriate measures now to realize a modem reset.

[SciWax]

@Gijs would you suggest to use the uping library for checking for a data connection or do I think too complicated? https://forum.micropython.org/viewtopic.php?t=5287

AT commands don't work, as far as I understood, because the GPy still thinks it has a data connection, because of lte.isconnected being true and in that state, the GPy doesn't allow to send an AT command to check the ping?

[Gijs]

Right, you are correct. Though the last time I used uping, it concurred with a memory leak somewhere and have not tried it since. AT commands indeed do not work, though you could opt to suspend the ppp session (lte.pppsuspend()) and use the AT+PING command, after which you lte.pppresume(). On the other hand, that could result in additional complications. Another solution would be to use socket.getaddrinfo(), which would query the DNS server to resolve a hostname. A downside here, is that I've heard of some caching done with these requests, so you might want to be careful there either (I do not think I have experienced this firsthand).

A last resort, would be to do a tcp request to a server and receive its response, that way, you know for sure there is a connection (if the socket does not error)

[SciWax]

@Gijs Thanks for the suggestions at this late time.
My Arduino counts the times a Code 200 wasn't received by the GPy. During a 3 minute intervall, the GPy has 9 chances for sending the latest 3 minute average and receiving the Code 200 in return. At this point, I think I will just do it like that: If the GPy fails 9 times, I can be probably sure, that something fishy is going on with the network. At this point, I will just power cycle the GPy via the MOSFET. After that powercycle, if lte.isconnected = True, the Arduino is allowed to send my measurement strings to the GPy again. I will just use another Pin for the state of lte.isconnected, for instance P11. The Arduino will read this Pin.

[SciWax]

I'm looking for the right MOSFET right now. I still have a IRL 540N lying around, but after looking for MOSFETs in this forum here, I found alot of people, who mentioned P Channel MOSFETs, which I probably need, when I want to use the VIN Pin to power off the GPy. Any suggestions for the right logic-level MOSFET for the GPy I can control with my 5V Arduino? I should also probably put a resistor in front of the Gate to not hurt the Arduino Pin?

Kind regards,

SciWax

[Gijs]

Hi,
I can indeed support that I would recommend the usage of a P-channel MOSFET there (generally, you would use a P-channel to switch on the VCC side, and N-channel to switch on the GND side. Note that the gate voltage operates in opposite)
Pull the gate up to VCC to stop the flow of current, and pull it down to GND to connect the two. I'd also use a small 100nF capacitor over the Gate-Drain to protect against switching transients

[SciWax]

Still looking for a logic level p-channel mosfet. :/

I've looked on digikey for a through hole one (I've put for instance "irl p-channel through hole mosfet" in the search bar). I only found obsolete ones, like the IRL5602L or IRLIB9343. Can anybody else recommend me a logic level p-channel mosfet, I can control with a 5V Arduino to control the VIN-Pin on my GPy? I think I'm using the wrong keywords, because I have a hard time finding anything with "IRL p-channel".

Sorry for bothering you, robert, but you are really knowledgeable about this stuff. Do you have an idea?
@robert-hh

[robert-hh]

@SciWax OK. Having had the same question, what do I have in my part boxes:
IRFR5305: Gate Threshold 2-4V, RdsOn 0.065Ohm, small package
IRFR9Z34N. Gate Threshol 2-4V, RdsOn 0.1 Ohm, TO220 Package
IRFD9024: Gate source Thresold 2-4V, RonOn 0.1 Ohm, 4 Pin DIL Package
Devices with higher RdsON:
ZVP2106A: Gate Threshold 1.5-3.5V, RdsON 5Ohm, TO92 Package
BS250

[SciWax]

Thank you! I really appreciate it. I will have a look into the datasheets of the mosfets you've mentioned! And thanks for putting together the additional information!

[robert-hh]

@SciWax I just gave the IRFR5305 and the IRFD9024 a test. At 5V GS voltage the On resistance was 0.1 and 0.3 Ohm. At 3.3 Vgs it was 12 and 120 Ohm, so less good. I also do not know, why the P-Fets with the low Gate Threshold seem only available in SMD packages.

You can also consider a moderate power PNP transistor like BD231, 2N5194 or BDX54 or the like. The have a higher Base current, but a low Emitter-Base threshold. The CE saturation voltage of 0.4 to 0.8 V does not matter in your case.

P.S.: The IRFR5305 is a real power monster, given its to92 sized package, with 31A max current. Looking at the package, the connecting pins seem to be the limiting factor.

[rcolistete]

What about the DMG3415U low power p-channel MOSFET ? Or the new one, DMP2045U. They cost about US$0.05/each if you buy 100-200 units.