Electron: Entering listening mode (flashing blue) by error

Thank you!

Exactly that’s in the code right now! in 95% it works fine,… I’ll give it a try!

Are you sure the cellular is beeing switched off? I remember to hear some interferences on my speakers after going into deep-sleep,…

regards

Deep Sleep does not turn off the cellular module.

hmm,… that’s not really satisfying :frowning:

I need the sensor to sleep a long time, if the river level doesn’t change too much the device shouldn’t go online for several hours and spare the battery for situations when the level is raising and send updates much more frequent.

Turning off anything not needed is essential for this application,…

I’ll post particle.io support team a mail and keep you posted.

thanks so far!

btw: do you have any other workaround beside keeping 2G on all the time?

regards

@mdma: can you take a look at this issue?

I already sent a mail to support, but neither there nor here I got a satisfying solution. My first prototype is ready to be installed - but it cant without this issue beeing solved,…

regards

Can you share the key parts of your code that are working with the cellular connection?

There is a known issue where the modem sometimes incorrectly reports that there is no sim card.

There is an option that’s carried over from the photon that allows you to connect without entering listening mode if there are no credentials (SIM card.)

Cellular.connect(WIFI_CONNECT_SKIP_LISTEN);

(We will change the name to NETWORK_CONNECT_SKIP_LISTEN in a future release to make it network neutral.)

I’m not sure why the modem stops thinking there is no sim card inserted, and I can’t say if it’s a transient condition that will subsequently fix itself.

@BDub knows the modem well.

1 Like

Thanks for your info,

it might not compile fine right away as I removed any unnecessary code. I’ll give WIFI_CONNECT_SKIP_LISTEN a try!

// This #include statement was automatically added by the Particle IDE.
#include "ThingSpeak/ThingSpeak.h"

STARTUP(System.enableFeature(FEATURE_RETAINED_MEMORY));
// STARTUP(cellular_credentials_set("custom.apn", "", "", NULL));
SYSTEM_MODE(SEMI_AUTOMATIC);

retained int lastDistance, reads = 0;

unsigned long myChannelNumber = 12345;
const char * myWriteAPIKey = "ABCDEFG";

FuelGauge fuel;

int distance = -1, percentage = -1;
float voltage = 0;

void setup() {
	Serial.begin(9600);
	Serial1.begin(9600);
}

void loop(void) {
	TCPClient client;

	Serial.printlnf("Good morning, this is my %d read today!", ++reads);
	Serial.println("Waiting for Sensor to settle,..");

	delay(200);
	// Dump Boot-Data to local console
	while (Serial1.available()) Serial.write(Serial1.read());
	Serial.println("");

			/* Read & evaluate sensor data using Serial1.read() */

	Serial.print("Connecting to network: ");

	Cellular.on();
	Cellular.connect();

	waitFor(Cellular.ready, 2 * 60 * 1000);

	if (Cellular.ready()) Serial.println("done");
	else Serial.println(" FAIL");

	ThingSpeak.begin(client);

	// If channel 6 has the value 1 connect to cloud and reset channel 6
	Serial.print("ThingSpeak firmwareUpgrade-Flag .. ");
	int fwUpgrade = ThingSpeak.readIntField(myChannelNumber, 6, myWriteAPIKey);
	Serial.printlnf("OK, Value: %d", fwUpgrade);

	if (fwUpgrade > 0) {
		ThingSpeak.setField(6, 0);
		Serial.print("Connecting to Particle Cloud: ");
		Particle.connect();
		waitFor(Particle.connected, 30 * 1000);

		if (Particle.connected()) Serial.println("done");
		else Serial.println("FAIL");
	}

	ThingSpeak.setField(1, distance);

	Serial.print("Publishing to ThingSpeak: ");
	if (ThingSpeak.writeFields(myChannelNumber, myWriteAPIKey)) Serial.println("done");
	else Serial.println("FAIL");

	Cellular.disconnect();
	Cellular.off();
	System.sleep(SLEEP_MODE_DEEP, 300);
}

@BDub knows the cellular modem very well - any thoughts on the code above?

What are you trying to accomplish here?

Do you want the Modem OFF for the lowest power consumption while sleeping? If so then you need to call Cellular.off() to turn the cellular modem OFF which will basically give you the lowest power consumption.

Thank you @RWB!
I updated the test-code. It compiles now without any error. I pushed it to a second electron.

cellular.off() was there and I’m quite sure it caused the same. That’s the reason I tried several other things like just cellular.disconnect,…

bests

@joky so are you saying it’s working fine for you now?

Have you measured the power consumption while in deep sleep + Cellular.off() ?

hi,

I run the code with cellular.off() since half an hour, none of the 2 electrons went to listening mode so far. Give me some hours to verify.

I reduced the sleep time of one electron so it might entering listening mode earlier,…

regards

so far - both electrons work fine. Both have approx 100 cycles now (unfortunately the backup RAM doesn’t work yet).
regards

1 Like

Hi,
the electron runs now since 4 days without any issue so far.
Thanks to the minimal power consumption a small 160x160mm solar panel it charges the battery even without direct sun :laughing:

regards

Voltage:

2 Likes

In spite of using Cellular.disconnect(), Cellular.off() (and vice-versa on setup()) as shown above, I notice an Electron (G350) with firmware 0.5.0-rc.2 going into listening mode. Over the period of 76 hours, this has happened twice. It is very unfortunate that listening mode waits for hours (the second time, I noticed after 3 hours before pressing reset).

Is there any known solution, or is there some kind of watchdog I can enable / use to overcome this? Listening mode for a few minutes wouldn’t bother me, but the fact that the Electron is then factually “offline” certainly does.

@jpmens In the latest firmware you do not need to call Cellular.off() because its done automatically in the latest firmware based on what I have read.

Could calling Cellular.off() in the new firmware be causing this issue.

I remember reading that upon waking from deep sleep the Electon will go back to what ever cellular state it was in before calling Deep Sleep.

That’s correct if my memory is correct after reading the latest firmware update fix list.

What is Listening mode?

I’ve been using System.Sleep for weeks now with network standby and its working perfectly so far when publishing to Ubidots every 30 mins and every 1 hour on 2 different Electrons.

1 Like

Sorry to bring this back to life after a couple months but I’m encountering the same issue. I just returned from the 30 minute drive required to reset my electron once it goes into “listening mode”. I sleep mind (w/o turning off cellular) for 15 minutes. It transmits every hour, so every 4th time it wakes up. I did it this way because if I sleep for more than 23 minutes, the connection goes stale and it has to re-handshake burning up data. I didn’t want that, and waking every 15 just to let the Electron ping the tower still gives me enough power savings.

This time it was a bit different though. I arrived to find it in listening mode as expected. I hit the reset button (a momentary switch that drops the reset pin to low) and it went right back into listening mode. I tried that a couple times, each time it dropped into listening mode from its initial breathing white. So I opened the enclosure and disconnected it completely from all power. Let it sit for a few seconds. Power back up via battery, and it breathed white for at least a minute. I hard set my mode to AUTOMATIC as the very first line in my setup(). So this time I push both the reset and mode buttons to manually put it into listening mode. Once it gets there, I reset it with the button, and now it finally, after all that, connects.

It seems to me that even if I’d have a nice external watchdog on the thing that it wouldn’t have helped, since just resetting with the pin/button didn’t help get it out of listening mode, although I do plan to add one (a hardware watchdog that is).

Does anyone have any advice on this? I don’t want to manage the cell connection to the particle cloud if I can help it, I just want it to work and be done for me. I can though I guess if I have to. I also don’t want to ever disconnect intentionally once booted. I want to maintain that connection (by allowing it to ping inside of 23 minutes) once I have it.

Thanks.

1 Like

I just encountered the same issue.
After reset the device came up immediately breathing white, no reconnection attempt at all.
Only after unplugging and replugging the LiPo revived the device.

@BDub, any thoughts. The last Particle post was March 11th where @mdma pinged already.

There is already a similar open issue, but this seems to be solvable via a reset, but here we can’t
https://github.com/spark/firmware/issues/687

And I’ve added an “escalation” issue to it
https://github.com/spark/firmware/issues/1025

2 Likes

I fired up my other Electron (hate to be using my kickstarter free data months for this but…) so I can mess with this and try to reproduce the drop to blue flashing “listen” mode. I did manage to get it to breath white as well, and it turns out this was my fault. There’s an interesting behavior and flow that I hadn’t anticipated but now is understandable.

I have a global object (I know, topic for another debate) so of course its definition lies above and outside setup(). The object comes from a library I forked for a particularly handy chip I’m using. The library had a crap infinite loop in its constructor if the chip doesn’t report as available. So on my local debug Electron that doesn’t have the chip, the Electron powered up and infinitely breathed white because of that endless loop in the library. It seems that the background calls that do the 3G connect and the Particle Cloud connect don’t begin to get called until the setup() function. So if you never get in there because you’re defining an object and its constructor never returns, you never connect. This isn’t going to be causing the dropout to the listen state which is the crux of this thread, so investigation there must continue, but it does explain my white-breathing behavior when I was messing with the chip before as I had suspected something electrical and removed the Electron from its board to try to isolate it. Turns out that isolation caused my breathing white. I’ve since made my code a lot more solid. My constructor is fixed and I’ve also changed my globals to just be pointers and I then instantiate the objects in setup() so I can’t be caught prior to getting there.

I am experiencing this problem now, too. I recently switched my code from using SLEEP_MODE_DEEP every hour to a shorter 15-minute duration sleep cycle to avoid handshakes and reduce data usage. Now my electron runs for about 10 hours before falling into this blinking blue state. I’m not using any Cellular functions.

Particle-CLI shows the device as online and listening, however when trying to flash OTA it always results in failure due to Time out, which makes me wonder if it is actually in listening mode