Boron404x Reconnects to cellular/cloud after ULP Sleep even when I don't want it to

Whenever my Boron404x wakes from ULP sleep, even though Cellular is off prior to that, when Boron awakes, it reconnects to the cloud- as indicated by flashing green followed by flashing blue and then breathing white. I don't want this to happen as I am in the loop() portion of the program and only at certain iterations of that loop do I want to send the data to Thingspeak via its API.When I do want to send data, I do a Cellular.on and Cellular.connect() and send the data. Then I do a Cellular.disconnect and Cellular.off and wait using Cellular.isoff().
I have two separate ULP_sleep sections in the loop. Prior to invoking the first one, I power up a sensor and then go to sleep for 1 minute while sensor warms up. When Boron404x wakes up, I take a sensor reading but don't send it to the cloud for 9 out of 10 iterations of the loop.Next I go to ULP-sleep for 10 minutes and start the loop over again.
I've tried Mode AUTOMATIC, SEMI_AUTOMATIC and MANUAL (which bricked it until I went to safe mode and re-programmed it). This happens whether or not I have a Cellular.off() statement just ahead of the ULP sleep interval. Nothing seems to stop this from happening. The code that needs to execute after each ULP_sleeps is very short, but it gets extended for many seconds by the cellular connect time.So, it will adversely affect battery life. Also, I don't want to be connecting to the cell tower that often.
What I am I doing wrong? Thanks

That scenario should work, and what Tracker Edge does to do the short wake cycles. I also do this in the SleepHelper library.

It is possible that you need to Particle.disconnect(). You could take a look at the two repositories and see if there are any other differences.

Also you should enable logging

SerialLogHandler logHandler(LOG_LEVEL_ALL);

and monitor the messages.

In the worst cast, you'll need to use Serial1LogHandler and a USB to UART adapter (FT232) because on wake the important messages will be lost before USB serial reconnects, but there may be enough information before sleep.

Thanks Rick. Yes, I'll try the Particle disconnect. I was only sending TCP data to ThingSpeak, so wasn't publishing anything to Particle Cloud, but I see where that might affect it.
I have also tried to use Serial1 to capture my serial1.print () messages because its hard to keep the PC terminal monitor connected during ULP sleep, as the USB port shuts down and the terminal software needs to have the USB com port re-opened. I used the RX, TX pins (D10, D9) on the Boron404x, with a USB/UART cable. I have not been able to get anything to work with Serial1. Even when I scope the TX pin it is not sitting at 3.3V like it should, and no signals appear. After I get my above problem solved, I'll try again with Serial1, but I spent a lot of time already with no luck, and reverted to using the USB serial for messages.

Make sure you set the baud rate correctly when using Serial1, both on the Serial.begin(115200); statement, and also in your terminal program. It doesn't matter for USB CDC (Serial) but it does for Serial1.

If you are using Serial1LogHandler logHandler(115200, LOG_LEVEL_TRACE); you don't need the Serial1.begin(115200); statement.

It's definitely the way to debug sleep issues, because it's impossible to see the wake messages without it.

Hi Rick: Great! Adding Particle.disconnect() did the trick. During the setup() routine, which lasts for a few minutes and does some initialization, I had issued Particle.connect() - just to be able to re-flash it during development. So, I had to disconnect it for the loop part of the program where the low-power operation was needed.
Also, I was able to see messages on my scope when I added the Serial1LogHandler statement, so that is good too. Don't know why I couldn't get it to work with Serial1.begin() and Serial1.print() before, but I'll check it again now that I know the logging is working on Serial1.It probably has to do with the second message you sent me.

You're a life-saver !!
Thanks

1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.