Cellular.command() Functionality

Hello,

I am working with the Cellular.command() function as used in this tutorial for Cellular Locationing. I am incorporating this locationing functionality into a larger project as a library. I am running into some issues with the function acting in a blocking fashion and taking too long. I currently have a watchdog timer which ensures the main loop() does not run longer than 2 seconds, but this Cellular.command() function seems to be blocking and exceeds the watchdog timer. There is little documentation as to the nature of Cellular.command() provided by Particle. Is it a synchronous or asynchronous command? If it is synchronous, what is the best way to get it running asynchronously? Would reducing the timeout, used as Cellular.command(cb, param, timeout, format), drastically decrease its performance success? Any further documentation on the nature of Cellular.command would help! Thank you!

It’s blocking for the call that you make, so how long depends on which command you are sending.

If you send at AT+COPS or AT+COPN it will be block for 2-3 minutes. Setting the timeout would make that shorter, but you also wouldn’t get the full results.

AT+ULOCCELL takes about 30 seconds. Some calls take milliseconds.

There is no way to make a non-blocking call.

1 Like

There is no way to make a non-blocking call.

True, generally, but if you must have such a thing asynchronously you would have to use System_Thread(ENABLED), make the call (and all calls that even remotely touch any networking code) in loop() and then put other timing critical code in another thread. Of course such a change can introduce some instability and complexity so again it comes back to how important that asynchronicity is to you.

Regardless, you'll have to increase the watchdog timer for such a thing. Fundamentally though, I would push back on your use case here and ask why you can't have blocking code. Is it just the watchdog issue? If so what adverse effects may occur increasing the watchdog? If there is another timing critical task that is truly timing critical you aren't likely to be getting your intended results anyways as the system firmware can be blocking for a bit between calls to loop in single threaded operation.

rickkas7's answer is the direct answer but we may be able to suggest other ways of architecting things to get whatever the true needed behavior is in your context.

Also, how long is your watchdog, assuming it’s a hardware watchdog timer? Making it less than 90-120 seconds will make it really hard to do a system firmware upgrade OTA because the device will be in safe mode and not tickling the watchdog. That won’t affect the ApplicationWatchdog as it won’t run in safe mode.

2 Likes

Because they said it was on loop() my assumption is that it must be the application watchdog, because there are plenty of scenarios where the system firmware would block for more than 2 seconds (including OTA of course but also bootup and initial connect). Again assuming they’re single threaded.

But I’ll echo that - I have the application watchdog set at around 5 minutes and my hardware watchdog at around 10 min just to really ensure stability during OTA updates. Especially if you do an OTA Application Firmware update followed by an automatic OTA system firmware update because of incompatibility…

The ApplicationWatchdog timer cannot be increased in our case, since the loop() controls the functionality of a physical device where timing is a safety concern and is critical. I was looking into threads, but as you mentioned there are numerous issues which may occur. I am currently looking into alternatives— seeing if I can use software timers to check in for a response instead of waiting for a response. Any alternatives and suggestions you could provide would be fantastic!

It is the ApplicationWatchdog timer which is set for 2 seconds.

Yeah I hear you. I would make sure to test the effects of OTA updates and other connectivity failure conditions very thoroughly on your current firmware if it is safety related for that 2 seconds. Consider also where an external watchdog might make sense.

I might suggest approaching this from another angle - cellular providers have location / triangulation data themselves that can be accessed in some cases. Look into options for getting the location data from outside the device and either a) sending it to the device as data or b) just using it server side if you don’t need it on the device. Also consider that if location is really helpful some external gps may be a more reliable choice.

1 Like