Cellular.connect blocking: fix expected?

I’m running my app using SYSTEM_MODE(SEMI_AUTOMATIC); and SYSTEM_THREAD(ENABLED);. I notice that when I call Cellular.connect() the next delay statement blocks for over 5 seconds. Is this planned to be fixed? I understand that connect() needs to do some work, so some time is going to be “stolen” by it, but I’d be shocked if that work actually took 5 seconds. I suspect it’s just delays waiting for the modem to do its thing and that could all be moved into a state machine or task that lets the app continue to run…

Let me ping someone that might be able to help, @ParticleD, or @mstanley are you able to assist?

Thanks! NB: this is on a Boron.

2G/3G or LTE?

delay() attempts to perform some background processing in order to keep the system responsive which is (apparently) backfiring in your case. I’m definitely curious what is causing the 5-second block and where that is coming from. In any case, I have a couple ideas to workaround in the meantime.

  1. Use HAL_Delay_Milliseconds() instead of delay() to not allow any background processing. Be careful with long delays as that can impact the overall system. Some events have to be run from the application thread and HAL_Delay_Milliseconds() won’t allow that.
  2. The background processing loop is only run by delay() from the main application thread. You can setup separate Timer() or Thread() instances to manage critical operations that can’t be blocked while leaving your main application thread to handle potentially blocking operations and processing the various event loops that delay() manages.
1 Like

@joel thanks for the reply! Those are good suggestions. Using separate threads makes sense but cap rapidly complicate the app with locks and semaphores…

How could I did in to figure out where it’s blocking?

I’m using an LTE Boron.

Hey Tve,

Good questions indeed. I suspect it may actually be the Cellular.connect() blocking for that period of time. I do know there are some known caveats with LTE at the moment, and would like to hear @BDub’s insight on this. He may be able to provide additional feedback into Cellular.connect() and its implications to the delay going on here.

I’ve run into a similar issue, I’m trying to prioritize mesh, but if I even touch the Cellular modem, the mesh is blocked.
Here’s my sudo code:
system_mode semi_auto
Mesh on
Mesh connect
Cellular on (if there’s no service, blocks here)

I’ve been trying to implement something to check the cellular connection signal before trying to connect to the cloud, but the cellular on function blocks… (looks like it automatically calls connect?)

“When turning on the Cellular module, it will go through a full re-connect to the Cellular network which will take anywhere from 30 to 60 seconds in most situations.”

: https://docs.particle.io/reference/device-os/firmware/boron/#on--2

I would love to have a bit more control, or see the cellular functions not block so that my code can check its status before trying to connect to the cloud.

@lpercifield if you have not already, you should use SYSTEM_THREAD(ENABLED). This will (for the most part) decouple the DeviceOS and user app threads.


Thanks for the advise!
I’m trying that now and seem to be running into issues getting the mesh to activate from the Boron gateway
Test 1 sudo code:
system_mode: semi-auto
system_thread: enabled

mesh on
mesh connect (Do I need to do this for the gateway?)

Results from above code: RGB led fast flashes green

Test 2 sudo code:
system_mode: semi-auto
system_thread: enabled

mesh on

Results from above code: RGB led breaths blue but xenon never connects to mesh

Test 3 sudo code:
system_mode: semi-auto
system_thread: enabled

cellular on
mesh on
mesh connect

Results from above code: RGB led fast flashes green

Can anyone confirm that a mesh network can be established using a Boron gateway if there is not cellular service?

I guess it should be “pseudo code”, right?

Yup, that is possible.

Without cell service I’d go with “Test 1” with Mesh.on() and Mesh.connect() on all devices - including the gateway.
If the flashing green never stops you should probably setup your mesh network afresh.