How to test if Particle.connected() is really connected? Publish hangs application for many seconds

Troubleshooting
1

Hello Community,
I have noticed as others have that even while breathing cyan, my Boron is possibly not connected to Particle Cloud.
However, I am still able to Send/Receive UDP packets using AT commands. So, cellular network is still connected to APN. and AT+CGATT? is 1 too. Of course.

I can programatically do a Particle.diconnect() and then a Particle.connect() and be connected again to Particle Cloud. But it cost > 4K data to do that.

Also, when breathing cyan but not really connected and trying to Publish causes the application firmware to hang for many seconds…even with SystemThread enabled. That is the big real time issue.

Any thoughts from anyone?

2

It’s impossible to know if a device is really connected, because the cloud connection is UDP and there is always a possibility that the device has lost the ability to communicate between the time of the last publish or cloud ping and the moment you check. Or the moment between the time you checked and the next time you published.

The best alternative to move your publishes out of the main loop thread so they won’t block. This library does that:

2 Likes
3

Thank you. I’ll look that over.

4

Hello @rickkas7. Is there a particle server IP address and port to send UDP packets that would be like Particle.publish that can be known?

5

Device OS knows the cloud server IP address, but I don’t think it’s accessible to user firmware. The list of possible IP addresses is somewhat large and frequently changes.

It would be of limited use because the cloud servers do not respond to ICMP ping and only respond by UDP to valid DTLS packets.

6

Thank you for the information.

7

Hey Rick, would it be possible in your opinion to adapt the PublishQueueAsync library to store the event messages on SD card or perhaps use FRAM. I already use Retained RAM to extend the available RAM and think that my message size and average backlog means I need a lot more space than Retained RAM. I implemented an SD card stored buffer for publishing a while back but have noticed issues with blocking on new Device OS versions.

1 Like
8

Are you using a third party sim card? If so it sounds like a keepalive problem (aka the cloud ping mentioned above not getting called).

9

Hello @justicefreed_amper, I have noticed it with both sims. Certainly, much more with 3rd party and my question in this thread is mostly for 3rd Party.
I think you’re right on that.
The interesting thing is that there is still a Cellular connection. I can send and get UDP packets using AT commands.
It has stayed active without changing Keepalive for days. Very low data usage needed to stay Cellular connected.

10

KeepAlive only affects the Particle Cloud connection pings. It won’t affect other UDP connections, to my understanding. You (or the library you might use) would be responsible for any necessary keepalive for any other UDP connections you want to be persistent.

If you aren’t setting a keepalive on your third party SIMs that is absolutely the first step you need to take, as the symptoms are precisely what you described. Your data usage will go up. If you need an active particle cloud connection, that’s the only way you can do it on third party.