Boron LTE Automatic Mode Reconnection Behavior

Firmware
1

I am a new user and absolutely in love with the Particle Boron product. I will be very disappointed if I can’t use it for my application.

I need to have it on 24/7 in a remote wilderness location with confirmed LTE Band 13 Verizon signal working on a Pycom GPy (Massachusetts, USA) but the signal might vacillate. My Boron NEEDS to be able to consistently reconnect if connection is lost.

Is this behavior part of automatic mode?
Is there anything I need to do to make sure my device when powered 24/7, will run 24/7?
Does the firmware restart the MCU if it crashes?
When will the hardware Watchdog be enabled?

Thank you in advance. Can’t wait for the Boron Sleep modes.

2

I don’t yet have specific experience with the Particle code & reconnection but from my general experience with such stuff I would strongly advise to take matters into your own hands.
The reason is that there invariably is a power/performance trade-off. When the signal is marginal it takes power to try to find a signal and try to reconnect. The radio will have to scan bands and possibly TX at full power over and over trying to connect (e.g. if it receives a weak tower signal but its own signal doesn’t reach the tower).
Neither the Device OS nor the radio firmware know how urgently you need to reconnect and how much power you are willing to spend on it. If your Boron anyway sleeps for some time and then wakes up to take some measurement and communicate you probably need to start and later stop the cellular connection anyway. Managing this yourself allows you to decide how much power you spend.

3

Thanks for the response. What would you recommend for the use case in which available power is infinite and not of concern, but signal potentially shaky and need to have as much 24/7 stability as possible.

Right now I am replacing my old Pycom for LTE upload with which I had many problems. I have a primary MCU (Teensy 3.6) handling my actual code, and the Boron will be used just for uploading.

Before I had a MOSFET switching on/off the Pycom but an advantage with the switch to Particle will be 24/7 uptime. The massively reduced power consumption enables me to do that. The remote programming and monitoring capability is definitely a win, as well as eliminating problems I was having switching on/off an external board.

Right now I have SEMI_AUTOMATIC mode running the following in setup():

Cellular.on(); //NECESSARY I found when in SEMI_AUTOMATIC
Cellular.connect(); //SAME
Particle.connect();

And in my main loop() I handle connection-lost events as follows():
delay(100);
If(connected) {
//Check if we have incoming serial RX packets and then upload
} else {
Cellular.on();
Cellular.connect();
Particle.connect();
delay(100);
}

In the event of intermittent signal, would this design endeavor to sustainably repair the connection? Has anyone deployed such an application with Boron who can weigh-in with their experience?

4

Oops, it looks like I incorrectly equated “remote wilderness” with power constraints. With infinite power I don’t have experience to draw on to make any recommendation :zipper_mouth_face:

Ok, what I would do is to first be lazy and test it out. It’s really a test of the u-blox firmware. You can see how it behaves and perhaps create a log (in memory or flash) about rsrp/rsrq every N minutes and see how it evolves. If that does not work to your satisfaction or if you don’t have the luxury of testing for a while then I’d build in a timeout such that if it is not connected for N minutes then I’d turn cellular off, wait a few secs and turn it on again. After all, at that point you have nothing to loose…

Hopefully some more knowledgable folks will chime in… :sunglasses:

5

Yes, I will run a 5-day solid test soon as I'm abroad, and will be pleased if it remains connected. This is the intended and very necessary behavior of course, since it is the non-meshed Boron's only way of accessing the cloud!

Is OK to remove the LTE antenna while Boron is connected, or could that damage the device?

I know the Pycom specs are clear that using LTE with antenna disconnected can damage the internal components. But I recently saw a thread on here (can't remember what it was) where someone was doing various benchmarking tests involving removal of antenna. That would be the best way for me to simulate loss and regaining of signal.

Thanks again for the help. Yes, hopefully longer-term Particle users can chime in. As a new customer, I am ecstatic about excellent these boards (and the whole platform). I wish I had never used Pycom. I would rather support Pycom, a nice European company, and I am infuriated that Particle appears to be based in the evil trash state of California. But their product so far is absolutely blowing me away. With MQTT I am able to live-stream sensor pulses over LTE at frequencies I couldn't even get the Pycom short-range dedicated LoRa radio to do!

Once I verify the hardware and software are 24/7/365 ready, and once Particle publishes hardware Cortex M4 sleep modes for the Boron, I will buy a ton of these boards and take an oath never to buy any different LTE IoT platform in my life.

Particle is just missing a few key ingredients to really shine like none other in the easy-to-program MCU with LTE market. I'm confident the platform will only get better.

6

Well then good luck! In the meantime I will enjoy the beauty and wonders of our state. Please don’t visit: no need to add to the trash :rofl:

7

The absence of the antenna shouldn't cause any harm, however uFL connectors are not meant for frequent disassembly. You may be better off with wrapping the antenna in a Faraday cage (e.g. grounded tinfoil).

Is Verizon running LTE Cat M1 in that location? LTE Cat M1 is not the same as "normal" LTE.

Could you name a few? Maybe some of them are in the pipeline already or may be taken up as feature request.

8

My understanding is that is the case, however I cannot say until I deploy. I would be shocked if the Pycom GPy would be able to connect to LTE there (it uses Verizon band 13 and a different modem than Boron), but not the Boron. I'll find out soon. I live 2+ hours away from deployment site.

Gladly, and thank you for the help. First of all, #1 I am in extreme need of sleep modes. This will allow me to use a separate MCU for the heavy duty real-time SD pulse logging work and use Boron's power-efficient LTE connection for data transmission while not wasting the ~17-20ma of resting do-nothing current while not uploading.

Practically identical in significance to "sleeping quiescent current" for low-power applications is "how many seconds on wake to re-establish the connection". Therefore, for Boron to be a real killer, I need it to #2 take advantage of the Cat M1 LTE PSM/EDRX modes (see here), enabling it to wake up and upload my minutely 132-byte binary packet hopefully in just 4 seconds or under, not your whole 10-15+ second reconnection deal. This would be absolutely game-changing and decrease power consumption enough to significantly simplify remote station power system design, in some cases for me perhaps completely removing the need for a solar panel/charging controller and allowing a single lead-acid battery run the whole winter. Minimizes cost and complexity across the board.

Third, #3, an Input Capture-based digital pulse frequency library exactly like Teensy's FreqMeasureMulti library would be so helpful it would probably allow me to not even need any separate controller. With the RTOS running on 64Mhz Boron, I could use a ported FreqMeasureMulti library to sample pulses and a separate SD card writing thread to attain 100% 6-byte-pulse logging rate with zero dropped pulses at 1,200Hz, which is my threshold requirement. Doing regular ISR interrupts won't cut it. The FreqMeasureMulti library on Teensy is a god-send but a little tricky to port given the low-level Input Capture MCU stuff. HOWEVER, it actually might not be that hard since it is already written for ARM Cortex M4 architecture common to Boron and Teensy boards (I haven't even figured out how to import external libraries in WebIDE yet, let alone try to port this library).

Fourth, #4, a way to underclock/adjust the MCU clock speed (as in the Teensyduino platform) would be incredibly valuable for low-power applications like mine. After profiling my real-time SD pulse frequency logging Teensy 3.6 main MCU (also does blocking I2C sensor calls on separate thread), I discovered I will never in a million years need more than 24Mhz to sustain my 1,200Hz pulses to SD card (6-bytes each) with 0% loss rate. I need more than 8Mhz but 16Mhz suffices, and 24Mhz just to be safe. I am wasting power running the Boron at 64Mhz.

Those four things would make this already-excellent product an unbeatable game changer for me from which I would never depart. Having a built-in DMA SD card reader - and/or some form of accessible SPI flash for data logging - would also be incredibly useful. My buffered SD writes to the Teensy 3.6 DMA-enabled built-in SDIO SD card with optimized SDFatSDIO library take only a handful of milliseconds or less, whereas (though I haven't yet tested) connecting an external SPI SD card to Boron will be at least an order of magnitude longer.

Thanks again for responding. What in my list above do you think will be possible?

1 Like
9

I don't know the Pycom GPy but if that was intended for 4G LTE it wouldn't connect to 4.5G LTE and since 4.5G LTE is exactly backward compatible to 4G LTE there'd no need to be shocked :wink:

10

As far as I can tell, the nRF5 uC doesn't support underclocking. I could be wrong... But it's not clear how much you'd gain vs. spending the "extra time" sleeping.

11

Thank you for your response, but can you clarify what you mean by "vs. spending the “extra time” sleeping."?

On the Boron, there are no implemented power-saving modes yet (see above), and calling "delay()" just idles the CPU/runs Particle.process in automatic mode, while using the exact same power consumption as if you were running actual code.

Is my understanding not accurate? Is there a way already to have the Boron "sleep" for certain periods and not use the full ~20ma idle power?

12

Sleep mode is not implemented in the current release. It’s in the process of being merged as far as I can tell from github. So I would expect it to be available soon…

1 Like
13

@Paul_M,

Now that sleep is released, have you tested your Boron outdoors? I am also very interested in the wilderness use case and am looking at moving to the Boron.

Chip

14

@chipmc
I haven’t even begun to test the new Sleep modes in my wilderness application because of the unflagging, catastrophic problems I am already having with Boron LTE connection stability, necessitating long drives out to the site to merely power-cycle the device which then reconnects … and then inevitably looses signal after some hours and fails to reconnect until another manual power cycle. Until I can get stable reconnection behavior the sleep modes are not even relevant. See the other thread I’ve been posting in for more detail.

15

@Paul_M,

I have over 40 sensors deployed in parks across North Carolina and they are working quite well on Solar power. However, they are based on the Electron. I plan to switch them out over time, but am going to wait until I can be confident in their stability.

One thing you may consider, I built a carrier board that can reset or even power cycle the Electron automatically / remotely so I never have to physically visit the devices.

Thanks, Chip

1 Like