HL7800 intermittent KSUP:2 SIM NOT DETECTED

Hi,

I have an issue that seems to be plaguing some of my units, where occasionally they will no longer be able to detect their sim card and was looking to see if anyone would be able to troubleshoot the issue:

Normal operation for these devices is to wake up every 15 minutes to send data to the cloud through cellular and to go into lite hibernate in between. Now when the device wakes up, +KSUP: 0 is expected before sending commands signaling that the device is ready. The error will then occur afterwards where the modem will occasionally send in +KSUP:2 immediately afterwards which signifies that it can’t read the sim card.

Once this message is sent, it won’t be able to read the sim card until a reboot is issued at which point it will try, most likely succeed, and then fail a few hours later in the same pattern. At first I thought that this was a single unit with potentially a bad solder joint but now I am seeing more units with this behavior.

This leads me to my two questions:

  • What can I do to recover from +KSUP: 2, is there a way to enforce reading the sim card again?
  • What causes a +KSUP: 2? If I’m aware of the exact criteria that causes the HL7800 to respond with the messages I can try and figure out where the device is going awry.

Also if anyone has seen this behavior and has some input, I would be happy to try and troubleshoot it with them.

Thanks!

@Antoine

What firmware version are you using?

Regards

Matt

I am currently using version 4.4.14.0.

Antoine

@Antoine

So I would try using 4.6.9.3 as 4.4.14 is getting on a bit now and we have fixed a lot of things. You can find the latest versions on the source.
https://source.sierrawireless.com/resources/airprime/software/hl7800-firmware/hl78xx-firmware/#sthash.MdBJMFB3.dpbs

Regards

Matt

I had an issue with the 4.6.8.0 firmware which prevented me from being able to upgrade to it (HL7800 Downgrade instructions + NO CARRIER issue) where I was stuck getting NO CARRIER. I can try 4.6.9.3 but if it is still the case I won’t be able to upgrade to it.

Regards,

Antoine

Hi,

So the issue that I linked still occurs with version 4.6.9.4 where after sending a message, I I get NO CARRIER which translates to the connection being dropped [which happens on every transmission] and causes a slew of issues with the system later. I attached a picture of some of the logs to demonstrate, but I would be really happy to get insight into this issue as well. I can understand the sim not detected issue possibly being fixed in the newer versions, but I can’t use the newer version due to this issue.

Have you seen this anywhere before or would you have any input on how to best proceed?

@mlw Sorry, wasn’t sure if I should have tagged you to notify you as you did for me so figured may as well.

@Antoine

So a few questions.

  • Are you on M1 or NB1 for this (not that it will make a difference)?
  • Are you using PSM? You have said lite hibernate but there is no mention of the network state.
  • Do you check signal strength and registration status before trying to send data?
  • I presume that you are relying on the ktcpsnd command being told to get 2 bytes and then exit data mode rather than using something like DTR or the escape sequence?

Regards

Matt

Regards

Matt

@mlw
Sure, so here’s what we’re using right now:

  • We’re using M1
  • We try to use eDRX though depending on what sim card I use I do or don’t get it
  • We don’t check signal strength, but we do confirm registration status before starting the socket
  • That’s correct, we do wait for the close confirm from ktcpsnd to close the socket and this is where the NO CARRIER occurs in the newer firmware versions (> 4.4.14.0)

If there’s anything else that could help let me know!

Thanks,

Antoine

@Antoine

Not entirely sure why you are seeing that, I have just tested the command and it comes back no issues, check out the attached log file to see if you can spot any difference to what I am doing.
HL78_IP_connectivity_test_20211005-151122.log (2.4 KB)

Regards

Matt

@mlw

Looking through it everything looks pretty similar, with the main difference being that when I send the +KTCPSND=X,2 for disconnection that I get +CONNECT followed by +NO CARRIER whereas you get the OK.
I use mostly the same configuration for everything, with IPV4 as well for IP addressing.

I don’t suppose using a home network vs. roaming network could change things? I’m not sure what are the conditions for the NO CARRIER to be returned there?
I also don’t specify the “everywhere”, just +KCNXCFG=1,"GPRS,“IPV4V6”. Does that have any impact?

Would the state of different pins potentially affect the connection as well?

At this point I think I’ll likely have to test my application at as small a scale as possible and see if I still get the same issue.

Antoine

@Antoine

So the everywhere is just the APN my SIM uses, also its not going to make a difference the roaming/not roaming thing. You might want to look at DTR, its state and what you have at&d set to, it would be unusual but something to look at.

One thing it would be good to see is whether the socket is actually closed after you get the NO CARRIER with at+ktcpstat?.

Regards

Matt

@mlw
Sounds good, I’ll likely spend the next day or two boiling my application down to the bare LTE essentials and then try looking at the DTR and using ktcpstat. Will keep you updated if I find anything

@mlw
Alright, so I got a chance to simplify my project into a simple MQTT transmission from bootup, initialization, transmission, and disconnection. I’ve also checked the socket using KTCPSTAT? though this only yields an OK so I’m not sure what I should be seeing more as the documentation states that the function should just respond with OK:
image
Ad for the DTR, it seems to stay low and only goes high when going to sleep (which happens when my other chip is initializing, stays low once I start my MQTT process).
Could you recommend what information I should be seeing from the tcp socket state and how to get it? I checked my MQTT server logs and it receives the disconnect request and executes it fine, just like it did with version 4.4.14.0 however I still don’t have a trace of what could be causing the NO CARRIER

Thanks,

Antoine

@Antoine

My mistake, it should be at+ktcpstat, without the ? on the end. Below is an example I ran earlier when I had a socket open with my test server, it should show you a line for each socket you have running at the time.

at+ktcpstat
+KTCPSTAT: 1,3,-1,0,2

OK

Regards

Matt

@mlw I tested it on the socket itself and got similar [KTCPSTAT: 3, -1, 0, 0]. The module seems to believe that the socket is still open up until the transmission of the 2 bytes at which point the modem responds with NO CARRIER