Electron: Entering listening mode (flashing blue) by error

Troubleshooting
21

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.

22

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

23

I’ve had the “flashing blue” problem twice now with an electron in the field. (45 minutes round-trip to get to it.) Today (the second time), I could not fix the problem by any combination of power cycle, reset, safe mode, intentionally entering listening mode, etc.

If I plug in power without pushing any buttons, I get 5 or 6 pulses of white, then flashing blue.

If I reset while holding down mode until one purple flash (safe mode), I get 5 or 6 pulses of white, then flashing blue.

I can make it go into DFU mode, but I haven’t tried to upload firmware yet by USB.

My firmware runs in automatic mode. It always stays cellular connected, but disconnects from the cloud when it doesn’t expect to need to publish for a while. If it is disconnected, it also sleeps (never deep) with SLEEP_NETWORK_STANDBY. It wakes up once per minute (while still disconnected) to take a reading. If the reading has changed beyond a threshold, it connects to the cloud and publishes. It also connects to the cloud and publishes on the hour, 20 minutes past, and 40 minutes past (which satisfies the 23 minute keepalive), then disconnects and goes back to sleep.

I’ve now brought the device home, but have done nothing further with it so far. Unless someone is interested in some kind of debug info, I will re-upload the particle firmware, then my own firmware tonight (using DFU mode) and see if that brings it back to life.

Spontaneously entering “listening mode” seems like a serious issue that has been reproduced by multiple people. Has it been root-caused? Is there a fix forthcoming?

I just checked the github threads up above… I’ll try reseating the SIM card to see whether that helps. I’ve been publishing RSSI and QUAL along with my sensor data, and the last few updates before the unit rolled over had pretty poor signal strength (RSSI = -98 dB) while the average RSSI looks to be around -90 dB.

Thanks,

Jeff

24

Could temperature play any part in yours? I think it is in mine. I put a DS18B20 in there with my photon and the rest of everything and find that that the box itself gets extremely hot under even mild sun. When it gets hot, it stops transmitting, when the temps come down it finds its way again. The box I have is a great size and awesomely weather proof but has a clear face. I’m going to need to put some shielding around it to see if that helps. Because it does reconnect…eventually, I haven’t been going whole-hog trying to figure it out. I think I’ll be at that location in a week or so and if I can get the shielding prepared and on it then I’ll report back w/results of that.

25

Mine was likely flashing blue for 3 days… It stopped transmitting Sunday evening; I finally made my way out there to check it this morning (Thursday). There were no publishes in the interim.

It wasn’t particularly hot this morning when I was messing with it. (Plus there were multiple nights of silence.)

26

I’d think that it is a SIM contact problem.
Has your device got back online after your attempt to reseat them SIM?

You could gently bend up the contacts of the holder with a safety pin and/or give the braket holdin the SIM a push to put more pressure on the SIM.
Humidity might also play a role.

27

I have heard of the SIM cards melting when inside of enclosed enclosures in the summer when they were not shaded.

So this could be something that over time gets worse if the temp swings cause repeated stress on the card or plastic material it’s encased in.

28

Reseating the SIM fixed it.

The SIM is pretty snug… I’m surprised that it would have contact problems.

30

We are also facing the same BLUE-LIGHT flashing issue, this become bottleneck to ship my product to the customer, My customer is a grape farmer , and the device has to work autonomously. There is no body to press reset button. Once the device enters to listing mode, we have no data and no-communication to fix it remotely. Is there any reliable fix for this pragmatically ?

31

Hi,

Mine has been deployed for 6 months with no visits required. I will say that it’s not 100% in sending in its data at every set interval, but it’s still pretty good. Try adding this. It goes outside of any function. Above setup() is usually reasonable:

STARTUP(System.on(setup_update, listening_mode_handler));

You then need a function called listening_mode_handler (you could call it whatever you like and use that name in the STARTUP line instead). This is mine, quite possibly copied from some other author so I apologize for no proper attribution:

void listening_mode_handler(system_event_t event, int ms_passed) {
// 3 mins in setup mode, reset
if (ms_passed > 3*60000UL) {
System.reset();
}
}

I also made this the first line in my setup() although I’m not sure it’s required:
SYSTEM_MODE(AUTOMATIC);

The other thing that I will say is I’m fairly confident that temperature is a factor. In the summer, my enclosure would routinely get above 120F and that’s when I’d see skips in my data. I know this because I put a temp sensor in the box and added it to my data. Toward the end of each day when it would cool down, things would resume. It is now winter here, and I haven’t seen a skip in the data in many weeks, even months. My enclosure has a clear cover, and I will be shielding it with a piece of aluminum painted white for the coming summer. The above code did, in fact, prevent me from having to visit and push a button, even if I did miss some readings. Hope this helps.

32

Hello,
I apologize for bringing this old “solved” issue up again, but reseting the deployed system does not seem to me as a solution. You loose temporary data for sure (that is only one disadvantage). You might loose important input, while reseting.
Sorry once again, for this but the issue is far from being solved (imho, of course).
By the way, I am struggling with this jumping to listening mode still (Mar 2018) with second Electron already!

I invite you to continue looking for the constructive solution.

As for the electron firmware developers, I would ask you guys to add more info about the reason the firmware changed the mode. Like - timeout, some fault, other reason.

So, here: void listening_mode_handler(system_event_t event, int ms_passed)

event.modeChangeReason seems to me a candidate for a place to provide that info.

Regads

33

I've also seen this a few times over the last few days also during some testing.

I'm hoping when the Hardware watchdog starts working again with the coming firmware update that it will be able to reset the Electron when this condition happens.

34

@opalapps, did my assistance in the other thread also help this issue for you?

35

Yes, the thread you have mentioned duplicates the issue.
Sorry for the duplicate and thanks for your help.