This topic may be better described as a combination of something problematic I’m seeing, and a question regarding operating the HL7800.
First for the problem; I have built an application built on a Bluetooth controller which communicates with the HL7800 and have it working fine in most instances. One unit however, while running the same application, will consistently get ‘NO CARRIER’ while in the process of closing a TCP connection which causes some issues. The only difference with this unit that I have observed is that the firmware on the modem is 4.6.8 compared to 4.4.14 on my other devices.
In order to confirm whether this is the root cause, I wanted to rollback the firmware to the same version, however when I performed the same process as I normally do (XModem upgrade), the firmware version stayed the same. My question is now how can I revert the firmware to do confirm whether a change in the modem version is indeed causing the issue?
Any help for both concerns is greatly appreciated,
Thanks!
EDIT: For whoever tackles this later, I’ve duplicated this on a second unit by upgrading it from 4.4.14 to 4.6.8 and see this issue happen again. Would there be changes in how it handles closing connections / sockets / something where NO CARRIER occurs? This creates an error code 922 following it which is tied to an invalid state of the session.
Sounds good, the direct method of changing the firmware worked great!
As for the logs; would I be able to send them to you directly? I’ve removed the sensitive aspects of it but I would like to preserve some of the log data.
As for a different TCP server, we don’t have one currently where we could operate in a similar manner.
Since we are alright with 4.4.14, we are alright moving forward but if you need anything for your own side just let me know and I can try to get you what I can.
I wanted to come back to this issue as the need to resolve it has grown. As I’ve recently learned that all modules that we will be receiving will have version 4.6.8.0 instead of the previously installed 4.4.14.0, and that we will need a firmware update to allow for IMSI switching in the future, I tried to tackle this a second time.
What I’m seeing still seems to show signs of problems with the modem returning +NO CARRIER during an attempt to close a TCP connection. I was wondering what could I supply to potentially help learn more on Sierra’s side what’s going on?
I attached two pictures of the disconnection process below, the first being a good disconnection from version 4.4.14.0, and the second being the issue I’m facing in 4.6.8.0. If there is more information I can provide which would help lead me to what’s changed just let me know as the issue happens consistently.
Any news regarding the +NO CARRIER issue?
I am getting the same response and it is causing some problems.
The problem is present with the latest 4.6.9.4 firmware.
thanks
I didn’t get an answer on this one, but had another issue which likely requires me to update (from 4.4.14.0 where I don’t see this issue) so ended up starting it to troubleshoot it on HL7800 intermittent KSUP:2 SIM NOT DETECTED - #13 by Antoine
Though to summarize, my MQTT server does receive the 2 bytes TCP data I sent and completes the disconnection [4.4.14.0 will return OK whereas 4.6.8.0 or 4.6.9.4 will return NO CARRIER]. The DTR remains low from start to finish of the MQTT transmission. I’ve tried the AT+TCPSTART? command however as per the HL7800 documentation, it just returns OK:
I am still hoping for a resolution on this issue as well, since it is preventing me from being able to upgrade modem firmware.
Running it before the disconnect request returns +KTCPSTAT: 3, -1, 0, 0 which seems fine according to the datasheet. This is what I am currently seeing:
So to clarify what you are looking for me to do: You want me to replace the KTCPSND=2,2 with the 2 disconnect bytes with a AT+KTCPSTART=<session_id> of the socket?
I just tried this and the modem will respond with +CONNECT and then after a little while respond with +OK.
Does KTCPSTART overwrite the previous socket id or will it only work if the socket was closed? If the socket was closed, nothing was shown to have closed as it was accessed a fraction of a second earlier.
Additionally my previous issue of SIM CARD NOT DETECTED occurring every so often also showed itself afterwards. I will likely update the other issue’s post accordingly.
I had replaced ktcpsnd with ktcpstart so in that last screenshot the app doesn’t try to disconnect. It connects, sends the message, and then when I normally send the ktcpsnd=2,2 to disconnect from the MQTT server (where I get the issue), I used the ktcpstart command.
I’m also seeing this also causes some confusion on the MQTT server side with some socket errors as the previous socket does not get closed.
To my understanding I still need to close the socket by sending that tcpsnd which was not included above, but that’s where the NO CARRIER gets returned
Everything we do currently uses KTCPCFG, KTCPCNX, and KTCPSND. I would rather not change the whole communication driver (as technically it is provided to us by a third party) and would rather understand why we are facing this issue so persistently across all of our devices when upgraded to 4.6, especially when it is working fine in 4.4.
The performance is like night and day so I was hoping to have some insight on what changed in that version to cause the NO CARRIER to be returned in the HL7800 firmware versus the preceding firmware
