Tips for deploying reliable LTE Boron that stays up

@hwestbrook Thank you for sharing this. I think you’re right: there’s no way to use Particle Boron LTE for reliable, permanent remote monitoring without having an external supervisory circuit that will depower/repower the Boron after a period of time goes by that the Boron doesn’t send it any “I’m connected” pulses.

The question now for me is whether something as cheap and simple as the following $13 board from Amazon will be enough to accomplish this:

If so, it is pretty amazing that such a simple and cheap addition could have saved me so much time, money, and stress in my false reliance on Boron-only.

Something like that would probably work, as long as it is reliable. Cost doesn’t have a lot to do with reliability. More important is testing it under all the edge cases you can think of. Like “what if power goes out” or “what happens in a brownout” or “what happens if the boron gets stuck in a reset loop and triggers this watchdog”.

1 Like

I’ve use these Timer Relay Boards with Gen2 and Gen3. I have a post on this forum somewhere with a few details. I buy them in bulk for a few bucks…but you have to wait for the slow boat from China.

Previously, I used them for Electrons operating as private MESH GateWays which have “mains” power.
But it’s also a good fit for Solar Boron’s, you just have to change your power strategy to a 12V battery and Panel.
A good combo is this $28 Panel w/ Controller, plus a $15 12V SLA battery.

You can setup the Timer Relay to only restart it’s countdown when your final cloud endpoint (I use ThingSpeak) responds correctly. That way, it’s confirming you are actually getting the data to the endpoint, and not just connected to the Cloud. I typically use a separate webhook just for the WDT publish.

1 Like

If the external watchdog timer is connected to the RST pin, is that sufficient enough to cover all scenarios?

No, I believe at least two (likely 3 min) widespread Cloud Outages/Issues that required Boron LTE’s to be manually Power Cycled. Reset didn’t fix them.


Hey @Paul_M – thanks for taking the time to draft this note. Given your question, I wanted to spend a little bit of time providing a high level perspective on connectivity management and why we’re investing in LTS releases for Device OS.

What should be true

Let’s start with a statement – our goal is to provide automatic, reliable, and resilient Cloud connectivity management for all Particle devices. This means that:

  • Devices should not require manual reset to recover their cloud connection
  • Customers should rarely, if ever, need to manually manage connection health
    • If they need to do so, it should be done via tightly scoped Device OS APIs and not through brute force management of the cellular modem or MCU (which can interfere with Device OS and create separate, negative interactions of their own)

Where we are not delivering against these standards, it is imperative for us to provide high quality support to better understand the root cause of the issue so that it can be resolved. This is doubly true as we invest in Device OS 2.x, our first long term support release for Device OS.

The role of LTS (Device OS 2.x)

One of the biggest factors that has affected reliability of Particle devices is the hit or miss nature of historical individual Device OS releases. Because we have typically combined bug fixes and feature development into a single release branch, customers have reported varying levels of success with different versions of Device OS depending on what features they are using and whether/where regressions were introduced.

In the Spring, we announced our intention to build an LTS release branch for Device OS. Long Term Support (LTS) releases for Device OS are independent branches of Device OS that are feature-frozen in time. They do not receive updates with new features, API changes, or improvements that change the function or standard behavior of the device. You can learn more about LTS releases in our documentation, here.

The 2.0.0-rc.1 release that you referenced in your post is the first, alpha candidate for Device OS 2.0. We have frozen feature development for this release line and will continue to test, identify, diagnose, and resolve issues over the next several months until it reaches GA quality and delivers the most reliable development experience of any Device OS, including v1.3.1-rc.1 which you have had success with in the past.

What version of Device OS should I use?

Once LTS is released in General Availability, this question will have a very simple answer – we recommend that customers who value reliability over the latest and greatest features use the latest version of Device OS from our LTS release line (currently 2.x).

Right now, because we have only very recently released the first 2.x alpha release, it may not yet be the best for your production application. While we encourage you to test against this new release, you should only deploy it to remote devices when you are satisfied that it meets or exceeds the reliability of your existing Particle application.

In the meantime, we will continue to patch issues that we identify and will gladly continue to support customers on older versions of Device OS with issues that they discover.

1 Like

Mkr1500 and boron, different firmware and use cases, both got an attiny85 as a watchdog. A hardware watchdog should be standard on these, that it isn’t says alot abougwhere particle wants to be in the market.

We also track wtchdog resets, and report them back to our server to identify code issues and network issues. Its amazing how fewer xellulat issues we have i. Some areas now that rushhouris so light.

1 Like

@will Thanks Will, I appreciate this write-up and look forward to the future of your product. I can tell you that 1.3.1-rc1 delivered pretty well on your goal in terms of cellular. If you have your engineers literally take two Borons and compare cell reconnection with even 1.5.0, and certainly 2.0.0-rc1 but I have noticed even 1.5.0, you will see the issue for itself.

The LTS versioning is a good idea, but if Particle wants to sell to industrial high- reliability remote monitoring cellular clients, your two highest priorities MUST be:

  1. Enabling usage of the hardware watchdog by fixing the bugs that eventually locks the device in DFU mode; and
  2. Fixing the sometime-post-1.3.1-rc1 breaking of the reconnection behavior.

I have made recent threads on each of these with further detail.

As for myself, I am doing much better now having learned these painful, expensive lessons, and knowing to use the external circuit + older working OS version.

Thanks for the perspective, @Paul_M – if you can link me to the threads you’ve referenced I’ll append them to the internal conversation we’re having about this thread and the issues raised in it.

@will Sure thing:


This is 3.3v watchdog with grove input , works great

@magchecks Thanks for sharing this, except that seems to be solely a reset-pin-manipulating device with the need to connect an external relay to make it truly power switching. Do you know of any such 3.3v or 5v device which is like the U6030 above, which will actually power-switch the Boron?

I’m sorry for not adding, I also used an adafruit 3.3v relay and routed boron power thru NC

1 Like

Hey Heath, I’m not sure if it was painful for Paul to hear this, but it sure was a statement that can bring hope to other people that come to this thread. Thank you!

What’s painful is the rat-race I would have continued in if I hadn’t heard it, so thanks. You need an external total relay power switching (not Reset or EN pin modulating) hardware watchdog if you want stable remote LTE with Particle’s products. This is a very important lesson.

As for 3.3v-compatible out-of-the-box power-switching external watchdog, I found this:

It seems to be an incredible pain to program, but it does fit the bill.

And the U6030 is perfect for my 12v SLA-powered solar sites using LTE Boron.


I’m glad this thread has been brought up. Particle devices, especially those who rely on cellular connections, are often placed in remote locations that may be difficult to power cycle. I hope the Particle team offer a solution to this, especially for the commercial versions of the Boron like the B402.

1 Like

@Paul_M, I know PCB design and ordering might be new territory for you but I would encourage you to learn. If you are building an IoT device even for personal use you can sure clean up the design quite a bit using a PCB vs breadboards or proto boards. If you are producing any type of product you anticipate selling (sounds like you are) then I think a custom PCB is inevitable. The sooner you learn it the sooner you get over that hurdle. I was in the same place as you a year ago fearful of the unknown… I can’t do this… how do I learn this, etc. After taking a tutorial or two and leveraging open source I migrated from soldering a protoboard to designing and ordering a PCB. For my project, I downloaded the eagle cad files for the double featherwing from adafruit, added my sensors/hardware, hacked up one side of the featherwing and then ordered from @rickkas7 tutorial even gives you the schematic and board. If you wanted to use that design, you could download it from GitHub, upload the board to OSH Park and in about 3 weeks for maybe $10 have 3 boards in hand. With a little bit of time to learn Eagle you could also clean-up whatever existing sensor you connect to it. Overall, just wanted to give you a little encouragement… between open source designs, YouTube and a few hours or maybe a day of time spent to learn, I think you’d be pretty surprised how far you get to having your own PCB. As for the issue of power backfeeding the EN and locking up the Boron, maybe not the right design or approach but don’t be discouraged or let PCB design be a barrier for you and your project, It’s likely inevitable anyhow and you’ll be glad you took the time to learn. I definitely am.



@jgskarda I appreciate this advice. I’ve been hand-soldering protoboards. I am not selling anything at the moment, but it is probably worth the investment of time as you mention.

@Paul_M I use this guy on Fiver frequently for PCB design. He will work with you to understand your design and he gives you everything you need to order from (including a screenshot of what selections to check on your order) and he is patient and very knowledgeable.