Boron LTE Flashing Green for 2 days

Firmware Device OS
1

We recently had an issue where a customer’s Boron LTE unit suddenly stopped posting data. It had been working fine for months up to that point without exhibiting this issue. Battery was well charged (>4v). The unit collects data, posts to the cloud and then sleeps on a 30min cycle. They have 2 other units deployed in other locations and those have been working fine. They are all running DeviceOS 1.5.0.

It took us about 2 days to get out onsite to investigate and found that the unit was in a flashing green state. We believe it was likely in that state for the entire 2 days. A press of the reset button on the Boron and the unit immediately come up, collected its data, connected to the cloud, posted its data and went back to sleep.

Is there a DeviceOS timeout that can be set to keep it from hanging in the flashing green state forever? In the setup() function, I am making use of - Cellular.setListenTimeout(120); - which I thought would prevent this but perhaps it has another purpose and I have misunderstood.

Thanks,
Tim-D

1 Like
2

Particle needs to attend to this. I believe there are legitimate, ongoing issues with Boron reconnect. This seems similar to my recent threads:

3

Can a Particle engineer possibly address @Tim-D 's concerns? I have similar issues. It is getting ridiculous. I just setup a new Boron with phone app and it NEVER - hours later - connected. It’s still flashing green. Perfect cellular. In the same spot, I powered another Boron without the antenna, then added the antenna a minute later, and the same: FLASHING GREEN STILL, hours later.

Why does Particle seem not to care much about their flagship product being able to connect and successfully-eventually-reconnect to the internet?

@Tim-D My advise is use 1.3.1-rc1 - however even then I am having the issue I described above (second Boron).

4

I have had this happen before but the connection always hits the timeout. I do NOT have threading enabled and use semi-automatic mode:

  Log.info("Connecting to Particle Cloud...");
  Particle.connect(); 
  waitFor(Particle.connected, 2 * 60000);  //wait for connection to establish.  2 minutes.

  if (Particle.connected()) {
    Log.info("Connected!");                      
  } else {
    Log.error("Unable to connect to Particle Cloud!");
  }
5

Flashing green suggests Cellular.ready() state is never reached but would be a prerequisite for Particle.connected() to ever become true.

Can you flash this and post the output?

BTW, when using waitFor() you’d do the check whether it timed out or not like this

  if(waitFor(Particle.connected, 2 * 60000))  //wait for connection to establish.  2 minutes.
    Log.info("Connected!");                      
  else 
    Log.error("Unable to connect to Particle Cloud!");

Due to the fact that your device obviously hangs a step earlier you may want to break up the connection process into its substeps

  Cellular.on();
  Cellular.connect();
  if (waitFor(Cellular.ready, 300000)) // cell connections can take up to 5 minutes
    Log.info("Cell connection established");
  else {
    Log.error("No cell connection");
    return;
  }

  Particle.connect(); 
  ...
6

Thanks for the suggestion @ScruffR. I’ll have a look at breaking the connect process in to sub-steps waiting for cellular ready instead. As a part of the recovery from the timeout, so you recommend any any special steps to ai in recovery for next try (like calling Cellular.off())?

Thanks,
-Tim

7

To properly advise for a solution it would be interesting to learn where the actual issue comes from.
That’s where the boron-clouddebug firmware would come into play.

8

Hi @ScruffR,

Understand but I won’t be able to run that test code on the customer’s unit straight away. Running the test code on the test unit I have here will probably not give an accurate picture (cell signal is relatively good here). Cell signals are not ideal as the fielded units are rural and the AT&T coverage is weak. We’ve done our best to optimize the cell signal quality. I would hazard to guess that it is related to cell quality but could not explain why the system did not recover from flashing green state. On wake-up, I was calling Cellular.on() followed immediately by Particle.connect() then testing Particle.connected() until timeout (not using waitFor).

Since recovering the unit we’ve not had another failure since so this is a very elusive issue for us to test against.

-Tim

2 Likes
9

Hey Tim,

At a high level, Device OS should automatically timeout and attempt escalating restarts to recover a cellular connection if it has lost it.

Cellular.setListenTimeout() is a function that sets the timeout for listening mode (blinking blue mode) in seconds, so this would not have an impact on the duration that the device stays in blinking green before attempting a reconnect.

As ScruffR has indicated the best way for us to help at this point would be to review your device logs. Alternately, if you open a ticket with our support team and send your Device ID we can also help you explore the cellular signal strength to your device, as it may simply be having trouble establishing and maintaining a connection due to poor RF conditions.

Glad to hear that the issue hasn't reoccurred yet, but agreed that we'd like to get to the root cause to ensure this doesn't happen again.