I am wondering if anybody has deployed LTE Boron to remote sites and had them reliably stay up for months on end, and if so, 1) what Device OS you were using and 2) any tips/tricks to make this happen, short of an external power switching watchdog circuit.
I ask amid extreme frustration as just this afternoon, yet a third Boron of mine hours away in the field has randomly disappeared, gone totally offline, and not reconnected for over 3 hours. This is on v1.5.0 with perfect power and great cellular signal.
Perhaps I am misunderstanding. Is this product not intended to be used for any industrial/remote monitoring/24-7 uptime purposes? Is it just a product for hobbyists? Am I looking in the wrong place and needing to buy a more robust 4G LTE Cat 1 Ethernet modem to get stable connection that won’t enter states of permanent disconnectivity until I drive hours to the site for a manual reset? The amount of time and money these Boron connection issues have been causing me is requiring me to take action, for my own mental health too.
I have given Particle chance after chance to get the Boron product to stability, but recent events have made me truly dying to know if anyone else is actually using the Boron successfully in a remote sensing environment.
I use v 1.4.4 or lower and have had good success until the cloud outage a couple of weeks ago. I’m starting to think it’s more of a hobby platform as well, even sites close to me aren’t acceptable, my customers are livid.
@RWB I already use the software watchdog. It has not resolved my issues. My 1.5.0 Boron with perfect cell and power which randomly died yesterday, has the internal watchdog set to system.reset() whenever 3 minutes have gone by without cellular. And I know fully that a cold power-cycling start was connecting in 1/6th in that time last I was there.
I could do a hardware watchdog if I had the electronics and printed circuit board expertise to make one, which completely eliminates the point of the Particle Boron product. If I had the expertise and time to do this, I wouldn’t be using the Boron in the first place. I would either be using the B-Series or interfacing with a cellular modem chip directly myself.
This is why I am so frustrated with the Particle Boron product and looking for alternatives if it can’t be stable and retain said stability with software updates which people generally trust.
Hi, I know it does not alleviate your frustration in any way, but there are efforts in the community, led by @chipmc in this case, to create a carrier that can help a lot in that area.
Thank you @gusgonnet. I was aware of chipmc’s thread. I have seen it before. It doesn’t contain a purchase link to a retail item. It is, like I alluded to above, a PCB design for people with skill, experience, and time to make their own custom printed integrated circuits.
If chipmc’s PCB design is necessary for a stable Particle Boron, and if the Particle Boron form factor and assembly has the value of being simple enough to not require custom electrical engineering, then the Particle Boron is an illogical choice for everyone: both for people with PCB/EE manufacturing skill (they would use something more bare bones in the first place), and for people without such skill (without the carrier board, the Boron is unsuitable for lack of long term stability).
What’s frustrating is the continue allure of the fact that I have had 3 Borons, all on 1.3.1-rc1, that have been loyal never failing months-long uploaders.
I’m psychologically damaged by reading the V2.0.0-rc1 release notes which effusively luxuriate on all the multiple, extensive-seeming, highly-optimizing-seeming, alleged cellular improvements that were made in this version.
This creates painful cognitive dissonance for me. If I downgrade to 1.3.1-rc1 for my deployment on Monday, will I be “missing out”? Then again, my experience has been of 1.3.1-rc1 working. Perhaps Stoicism is in order: whether or not Particle cost me hours of time and hundreds of dollars by subsequently ruining their cellular reconnect stability after working 1.3.1-rc1 is out of my control. The temptation of all the alleged benefits of 2.0.0 does not outweigh the pathetic comedy of errors or reality with 2.0.0, even minutes ago made known to me: I unplugged antenna from 2.0.0 Boron at 1:25pm, came back to flashing Cyan instead of expected flashing Green Boron at 2:06pm, reattached antenna, and now 25 minutes later, zero re-establishment of connection. And will wait longer too. We’ll see if it even ever reconnects. What sucks is that I need to deploy this on Monday. Transportation costs me $300, takes 7 hours, and I had to get a COVID test because of the interstate commerce.
I want a Particle engineer to read this and opine to me the benefits vs risks of using 1.3.1-rc1 vs. 2.0.0. Does Particle honestly release new versions of their flagship product without doing so much as a lick of testing to see whether the reconnection stability is totally ruined?
Downgrade to 1.3.1-rc1 if it’s proven stable for you.
Then test newer firmware more before deploying to your specific application.
You are using the software watchdog which is not as reliable as the Hardware Watchdog so I would switch over to using the built-in hardware watchdog if you don’t want to do an external watchdog. That would guarantee your cellular reconnections happen even if the software watchdog failed to reset your device.
Check out @chipmc 's code since he has a good amount of cellular devices out in the field the same as your wanting to do and he’s aiming for the same reliability that you are.
I agree on software and version. I will see if @chipmc has a hardware watchdog design I can either purchase or make with basic soldering/jumper wires (within my abilities). If it requires custom PCB ordering, it undermines the value of the Boron product as I explained above, forcing a choice between simplicity and stability.
But thanks for your input. Is anyone else using Boron LTE for stable, long-term, remote uploading?
Wow, are you telling me Particle’s ApplicationWatchdog() that I’ve been using is a fake top-layer thing and not using the MCU’s built-in registers? Wow, this is helpful. I guess I misunderstood “software watchdog” as “using the internal hardware MCU registers vs. an external supervisory circuit” as opposed to “not a watchdog at all, but a piece of OS-level code that will only run if every thing else is nice, defeating the whole point of a watchdog”.
Will this video enable me to set the same registers for the Boron? It’s a different MCU, no?
The video explains whats going on better than me but yes you are correct, you have been using a software watchdog and not the hardware watchdog which is better.
I’m not sure why they have not given us access to the hardware watchdog as the video shows you how to do but I’m sure there is a reason for it.
@RWB Thank you for this! I can’t believe that this isn’t common knowledge. Maybe I was the odd idiot and everyone else knew this, but I doubt it, because I’ve spent a significant amount of time on these forums and working with Particle Boron since May 2019, and I never until now knew that ApplicationWatchdog was fake news.
I write this as I try to get the azure integration properly functioning (particle plaftorm is currently wrapping my json object in a string) for an industrial use case and this thread is worrying the hell out of me.
I didn’t find that video until a few months ago but then again I had put the IOT stuff down for awhile as I dealt with the curve balls life threw at me over the last 9 months.
The Application watchdog is doing what I need it to do now and I haven’t needed to enable the Hardware watchdog yet but if i was doing a remote Boron setup I certainly would be using that hardware watchdog version.
Usually if you can reset the device it will eventually connect, so you just need a reliable way to make sure it resets if it gets hung up due to a long bout of cellular connection issues which will certainly happen over time.
I write this as I try to get the azure integration properly functioning (particle plaftorm is currently wrapping my json object in a string) for an industrial use case and this thread is worrying the hell out of me.
A search on HW watchdog may reveal that it has not been enough to secure reliability in the past for the Boron. In addition the Boron needs a 30s power down capability to be sure, like this example here:
@thrmttnw Thanks for sharing this. I had already read that thread and 1) concluded it didn’t help me, being unable to order custom PCBs and solder tiny SMD components, and 2) was unable to answer the following question:
Are you saying that a Boron power cycle must be at least 30 seconds for it to have a cleansing effect?
Regarding the hardware watchdog option which I was excited about above, I did read one post saying that it caused the Boron to reboot into DFU mode. Is that a misbehavior you are referring to?
Is there a way to stably and reliably use the hardware watchdog?
From posts and my own experience 10 seconds is too little, 15 second may be just about enough so 30 seconds to be sure as according to the link quoted.
No, I am referring to the fact that having a HW watchdog has saved many devices from most but not all disconnects. In some cases the longer power cycle has been needed at least for Boron to recover from "having trouble connecting to the cloud".
Just wanted to chime in here and say, if you do go the external watchdog route, don't use the Deep Reset Tutorial posted above if you want maximum reliability.
The EN pin has an inherent flaw, whereby it locks up the Boron if anything else that attaches to the boron can backfeed more than a minimal amount of power. Lots of sensors and circuits backfeed enough power to allow the Boron to be locked up this way.
I think @rickkas7 should post a warning on that tutorial and Particle should post a warning on its Boron data sheet. Knowing this could have saved me $10K and a week of my time!
We have around 100 Borons in the field (and 1000+ electrons) in remote locations all with external hardware watchdogs. I think you may be spinning out here -- If I were you, I would go back to the drawing board on your project and implement a proper hardware watchdog. Sorry if this is a painful message to hear.
@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.
