I have a BC66 that is regularly transmitting data packages (every hour) to a server via UDP. It is in my home, and it hasn’t moved for the past month or so. Initially all data packages were arriving at the server.
Since a few days, the packages are not arriving on the server any more. When I log into the dashboard of the network provider (1NCE), no network activity is seen for the BC66 between now and the moment that the data stopped appearing on the server (i.e. it’s not a server problem).
When I look at the logs of the BC66, everything seems fine. It wakes up from deep sleep, gets an IP address, opens a UDP socket (SEND OK), closes UDP socket, and goes back to deep sleep.
So it looks a lot like a network coverage issue, except it isn’t because:
the BC66 hasn’t moved since the packages have stopped coming through. So in the exact same geographical area the BC66 packages were coming through just fine before.
I have another BC66 and that is physically very close to this malfunctioning one, and the data from that one is coming through on the server just fine.
So I am curious, what factors could be playing a role here? How is something like this possible? To me it seems the network has just decided to ignore or blacklist this particular BC66
Any suggestions are much appreciated!
-> MCU waking up
# Wait for BC66 wake up --
Send interrupt to BC66 PSM_EINT pin
Wake up event!
+QATWAKEUPDY
AT+QSCLK=0
OK
# Wait for BC66 IP connection--
AT+CGPADDR?
+CGPADDR: 1, XX.XXX.XXX.X
IP opbtained!
# Create Socket --
+QIOPEN: 0,0
AT+QNBIOTRAI=1
OK
AT+QISENDEX=0,93,38363739393730333635313034342C3134383641412C3233303231373131303 433312C332E36332C36302E39342C32312E39392C39392E39397C3233303231373131333532302C3 32E36332C36312E36362C32312E37372C39392E3939
SEND OK
# Closing socket --
OK
CLOSE OK
# Wait for BC66 sleep --
AT+QSCLK=1
OK
Deep sleep event!
+QNBIOTEVENT: "ENTER DEEPSLEEP"
Time to sleep / wake [ms]: 646
-> MCU to sleep
thank you for the suggestion. I will try to do that. But could you maybe first give an indication of what you think the possible reasons for this could be? Could you maybe give a list of possible underlying causes, that we can then start eliminating from? Or this is there maybe a troubleshooting guide/script that I can work from?
You’re asking me to do the PING service, but why are you asking me that? What will the different outcomes of the PING service tell us?
The BC66 is able to get an IP address every time it wakes up (with AT+CGPADDR?). So it’s connected to the internet. Then what is the added value of doing a PING? The point of doing the PING is to see if the BC66 is connected to the internet, right? So how is it different from doing AT+CGPADDR?
What I’m trying to say is this: I would like to be able to understand and figure out what is going on myself, rather than sit back and simply follow your instructions and wait till it’s solved
It would be great if you could help me with that,
Many thanks!
I have seen similar things. I am using MQTT, and have 2 devices. It opens the connection and tries to connect to the broker. Sometimes its can’t on one but will on another. I thought it was a restriction on the broker, but I can write code to connect every time. I got a better antenna and that seemed to help, and if I do it after letting it sit for a while it will always come back. Maybe its the way its connecting that the broker thinks its already open with that IP
Hi @PeteD , I decided to post this question to the network operator that I’m using, 1NCE. They came back with the message outlined below. The dashboard of their website has a nice feature where you can press a button labelled “reset SIM connection”. I pressed that button, and that fixed the problem (at least the symptom of the problem, not the root of the problem). That is what the “connectivity reset” is referring to in the text below.
After checking the network events, we observed that there are multiple PDP contexts created. One was created on the 3rd of January, at 07:56:48, and another on the 1st of February, at 21:48:01. On the 13th of February, at 17:50:36, the active PDP context was deleted, and therefore no data delivery was possible from this time on.
Please let us know the commands that you are using to handle PDP contexts. As the 1NCE network is only able to handle one PDP context at a time (usually, the last one created), we assume that there could be an issue with the automatic handling of the PDP contexts by the device.
Therefore, we always suggest utilizing only one CID in the AT commands for Socket and PDP context management.
From the device’s point of view, the first PDP context is probably still active but not on the network side, which we explained above.
The connectivity reset has closed all ongoing PDP context sessions on the device’s side and triggered a Reattach, which caused the device to work again as intended.
We thank you for your cooperation!
So it comes down to the automatic handling of PDP contexts (I haven’t quite figured out yet how to do that though).
