Stable cellular reconnection newly ruined with Boron 2.0.0-rc1, and perhaps earlier

I have experienced that updating Device OS since 1.3.1-rc1 has resulted in Borons become totally unusable in a state of permanent disconnection. Particle has made a usable LTE IoT product in 1.3.1-rc1. Particle seems to have subsequently destroyed this product by making it impossible to have a Boron that will not enter a state of permanent disconnection where there is cell signal where there is intermittency to said signal like in virtually every place.

Anecdote #1: 8/1/2020

My trusted Boron 1.3.1-rc1 was performing FLAWLESSLY at “Site A”, three hours from my house, from September 2019 to June 2020. Last month, I was doing renovations at “Site A” and figured I’d place a new, fresh Boron with Device OS 1.5.2 (Warning: This was a HIGHLY stupid decision. I should not have trusted particle updates). This was “the June 2020 swap”.

Prior to the June 2020 swap, the 1.3.1-rc1 Boron would occasional disconnect due to legitimate cellular signal fluctuations, and it would ALWAYS faithfully reconnect. All in all, I bet I had about 95% uptime. Perfect.

The June 2020 swap to 1.5.2 significantly and noticeably killed uptime. It was only a few days until “The 8/1/20 Upgrade”, and admittedly 1.5.2 always did reconnect, but it was offline for MUCH more time. Same spot, same antenna, same everything except Boron unit and Device OS.

Then, on 8/1/20 during another renovation visit, I got the even stupider idea to update to V2.0.0-rc1. I was enticed by Particle’s self-advertised, alleged cellular improvements as part of said update. Oh the cruel irony.

After updating the new June 2020 previously-connecting Boron to 2.0.0-rc1, it would not connect. I left the site. I still have not had one single successful packet upload 2.5 days layer. The cloud API indicates a brief (few minute) connection a few hours later on 8/1, and then total disconnected death ever since.

Anecdote #2: 8/3/2020

I have a local test Boron on my deck, testing for a new deployment. It is V2.0.0-rc1 and is in good suburban cell reception (not really challenging the reconnect behavior). It was uploading for a few days.

Then, last night at 1am, it disconnected.

Then, this morning at 11am, it was still disconnected flashing green and never having once reconnected, despite perfect cell signal, for ten whole hours. It completely failed to reconnect. 10 hours of power and perfect cell signal, and no reconnect.

Then, at that moment at 11am this morning, I power cycled said flashing-green Boron. Within 30 seconds it connected to the cloud. (Proving that it is a Particle software issue, and not any hardware or external factor which is the cause).

Why is this happening? Does Particle offer me a usable product where I can upload IoT data over cellular?

To make matters more laughably worse, I cannot even downgrade to V1.3.1-rc1 on said Boron: Entire Boron platform for me is destroyed: cannot use Boron with older Device OS versions

Any help is appreciated.

I understand the frustration. I am using 1.5.2 on my customers Boron

gateway to Xenon mesh network. With some proactive code to monitor the condition of the current Particle cloud connection on all my devices I am able to avoid (so far) long term lockouts from the cloud when a device goes offline. This solution ain’t perfect. :roll_eyes:

(Please, from anyone, I need no further reminders of the deprecation of the mesh firmware. :wink:)

I am occasionally reseting devices or forcing a new session (Handshake) even though there is an apparent cloud connection. To do this, I am using the library DiagnosticsHelperRK to look at the condition of the present cloud connection. Here are some statements I use:

g_status = DiagnosticsHelper::getValue(DIAG_ID_CLOUD_CONNECTION_STATUS);             
//  **connected** = 2       connecting = ??????
g_errorCode = DiagnosticsHelper::getValue(DIAG_ID_CLOUD_CONNECTION_ERROR_CODE);      
//  error code = 0 (**no error**)   10(?????)   17(?????)

g_status should be “2” AND g_errorCode should be “0” for a good connection.

If the above status OR error code change and persist for a few minutes then I take action rather than wait for disconnection from the cloud server.

You are probably already using keepAlive() (in some form) and sending a ping periodically using Particle.publish(). When status or error code go bad, it may be these “pings” are not acknowledged by the cloud because they are not sent or heard. In this case, the apparent comm line might be disconnected and the device made offline after some timeout period.

Thanks robc for sharing that. I am inclined to believe - and please tell me if you agree - that your magic about the cloud connection is irrelevant to my situation, since I am experiencing utter inability for any cellular reconnection and no internet whatsoever, regardless of the cloud connection.

In other words: flash green = zero internet; flashing cyan = internet with cellular established, but no Particle cloud connection established.

I am actually not using Particle.publish. I am using MQTT to upload data and so I will be able to see activity whenever the cellular is connected, regardless of whether the Particle cloud connection happens on top of that.

So, am I right about your magic with the keepAlive only pertaining to the cloud connection (cyan light status) rather than the underlying internet connection (green)? If so, which I believe is the case, the only code that is relevant is the underlying Particle firmware interacting with the modem, which I have no control over.

I am also using the watchdog to do a reset after 3 minutes that Cellular.ready() still returns false.

Now, after thinking about it, I have not tried disconnecting and then reconnecting to clear up the bad comm line. So, when I get a chance, I will try Particle.disconnect() and then Particle.connect() in some fashion, to see if this helps rather than perform a reset or fns.

Today I have new testing experience which further proves my observations of the equally-laughable equally-disconcerting reality that Particle has gone backwards - far backwards - in the stability of their flagship product from 1.3.1-rc1.

I’m equally happy about 1.3.1-rc1 as enraged and infuriated about how much time and money has been wasted with 2.0.0 and perhaps earlier.

Test using the SAME Boron:

  1. 2.0.0 was connected with good cellular. Unplug antenna.

  2. It naturally stopped uploading. I came back an hour later. Reattached antenna.

  3. UTTER and seemingly permanent failure to ever reconnect/reupload automatically without power cycle. Simliar to my 10-hour-never-reconnect experience from above.

  4. Downgraded to 1.3.1-rc1 with the special necessary 1.5.2 which the Particle engineer was kind enough to let me know about in the other thread.

  5. Same thing: got it connected, unplugged cell, stopped uploading, came back in 20 minutes.

  6. INSTANT reconnection/resumption of uploading compared to 2.0.0.

Then I did the same thing again, except I let it disconnected for a whole hour with antenna removed, then came back again to non-uploading antenna-disconnected 1.3.1-rc1, and reconnected antenna, and likewise, INSTANT reconnection and uploading.

What a pathetic and deleterious disaster Particle Device OS updates have been post 1.3.1-rc1. Despite listing so much cellular improvements in their release notes, they have utterly destroyed and ruined their flagship product with poorly tested software products.

@avtolstoy saved the entire Particle company from being a useless disaster when he divulged to me a necessary secret, previously published nowhere, that allows one to successfully downgrade from garbage 2.0.0 to working 1.3.1-rc1.

Thankfully, because @avtolstoy was so nice to share this info with me in the other thread, it seems I can stick with Particle and have a working, excellent LTE IoT product. That is, strictly with 1.3.1-rc1, and I will never again in my life make the mistake of installing a new Particle update.

I will go to the therapist the next time Particle comes out with a Device OS update and have him or her help me rationally view the history at play. This will help me from falling into the temptation again of believing Particle’s cellular-improvement-bragging release notes which are none than deceptive Sirens (link) luring me into certain disaster.

1 Like

HI Paul, yes this is really frustrating, if you can believe we have like 50 particle to be used in our devices right now and I am using Firmware OS version 1.4.4, with that as well I have seen that the particle will disconnect from the cellular network and will never reconnect back. One of the devices was like offline from 4 days and it didn’t reconnect. Also please note with same firmware that we are running on top of the OS ,we do have some particle boron which reconnect in a disconnect event.I am not sure why this random behaviour. So far there is no conclusive decision on how I can fix this issue, few devices are on customer site and I have to physically go to make them reconnect.
Anyone from particle boron can help ? Product is bound to fail with these issues.

Please reach back to me if anyone has any solution on this.

1 Like

With issues like these it’s best to file a support ticket at

Hey there @Paul_M,

Thanks for sharing your experiences. Our objective is to make our Long Term Support release of Device OS (v2.x line) the most stable version of Device OS available, so if you’re experiencing issues with one of the release candidates (v2.0.0-rc.1), we are committed to ironing out the issue before the release is GA.

We have already tried to reproduce some of the issues you described (specifically, removing and reattaching the antenna with v2.0.0), and have not been successful in doing so yet. This means there may potentially be interactions with your specific user application that we need to explore further.

After talking with our support team, it sounds like they have been in contact with you about these issues and have provided some instructions to help capture device logging that we can use to better understanding what’s going on with your particular device. I understand that collecting logs is not always possible, especially for devices that are already deployed, so I’m glad that the issue is reproducible on the device that you have at your desk.

If we’re able to identify an issue in Device OS, we’ll include a fix before we release the 2.x line in GA.

For the benefit of others, thank you for highlighting this – downgrading from v2.x to v1.x lines is definitely possible, and instructions can be found in the release notes for each release candidate. The latest (for v2.0.0-rc.2) can be found here.

Note: Downgrading [Electron/Photon/P1] OTA or YModem transfer:
If you need to downgrade, you must downgrade to 1.2.1, then 0.7.0, then 0.6.3(Photon/P1), 0.6.4(Electron) to ensure that the bootloader downgrades automatically. When downgrading to older versions, downgrade to 1.2.1, then 0.7.0 first, then 0.6.3(Photon/P1), 0.6.4(Electron), then to an older version such as 0.5.5.

Note: Downgrading [LTE Boron and BSoM]:
If you need to downgrade, you must downgrade to 1.5.2 first. and let the device attempt a cellular network registration.

@will Hey there Will; first I tender merited recognition of Particle’s customer support tenacity. 5-stars on the human component. Grateful congratulations.

Correct, I currently can’t devote time to getting you logs.

Will, actually, my biggest problem with Particle is no longer these issues (I can get away with 1.3.1-rc1 + no external watchdog to trigger the leakage problem, and get good results).

Will, my biggest problem now is that Particle charges me $0.4/mb for LTE when the competitor charges $0.1/mb with an equal or better physical product.

Is Particle looking at revising their pricing?

You might want to look at their keep alive ping rate and then do the math on how much data that adds up to compared to Particles 23min keep alive.

1 Like