Electron: Entering listening mode (flashing blue) by error

Troubleshooting
1

Hi everyone,

I’d like to test-install my first electron project:
A ultrasonic distance sensor mounted on a waterproof case containing the electron and the battery. The battery will be recharged by an small solar panel. The device should monitor and report the level of a river.

To keep the device as long as possible online I turn the cellular off send the device to deep sleep mode (currently every 5 minutes). Instead of particle cloud I choose thinkspeak.

The device itself works quite well (as expected), but after approx 3-4 hours the device stops reporting data, the RGB LED is flashing blue like the “LISTENING MODE” (not breathing).

Did anyone else had the same symptoms?
If so, any ideas how to this issue might be solved?

all the bests!

2 Likes
2

Yes I did see this issue when I did the following:

Before my code in the loop ended I called cellular.off() and then deep sleep.

Then when the deep sleep woke back up it would not reconnect properly and I would see the dark blue led like you are.

Then I had to add this code to beginning of the loop to get the cellular reconnected to the network and then to the Particle cloud network.

I can’t remember exactly but here is the jist of it?

Cellular.on();
Cellular.connect();
Particle.connect();
Particle.connected();

Your main program code goes here.

Cellular.off(), // before going to sleep turn off Cellular.
deep sleep code.

My advice is to just use the deep sleep code without calling Cellular.off(); since it just works and the battery discharge current is still low which is what you want.

3

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

4

Deep Sleep does not turn off the cellular module.

5

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!

6

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

regards

7

@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

8

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
9

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);
}
10

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

11

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.

12

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

13

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

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

14

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

15

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

1 Like
16

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:

2016-03-15 15_41_31-Starten.png833×385 7.25 KB

2 Likes
17

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.

18

@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
19

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
20

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