Boron / Xenon / Argon Carrier for Outdoor Applications

Social Project Share
#200

@jgskarda,

Thanks, I am glad you find this helpful. My plan is to continue to evolve this project as we get more learning on how to reliably deploy the Boron.

  1. There is not special circuitry required for the Boron to accept a solar panel. I use the Voltaic systems panels as I find them to be very durable and long service life is my main concern. I use the 3.5W / 6V panel and only had to add a large 400uF cap to the DC-In to help buffer temporary variations in solar intensity. @Rftop, @rwb and others have helped with the power configuration settings you put in software to get the most out of the panel.

  2. The big issue with the Boron is that its Real time clock stops working when it goes into the deepest sleep mode. So, if you want to use that sleep mode or use the Enable pin to power down the device, you need an external real time clock. Note, this also gives you one other helpful tool, it enables you to remotely power cycle the device.

Glad you are finding this useful. Going to take another turn of the crank with the carrier board based on @rickkas7 latest App note on watchdog timers:

Thanks,

Chip

#201

Thanks for the info @chipmc !

  1. You have a specific part number or digikey link for the 400 uF cap you use. This is as simple as wiring the solar panel to VIN/VUSB pins and GND and then adding the cap between the same pins? I’m about to order another set of boards or at least pads for it and may add this.

  2. In my application, the bulk of the time, the device wakes/sleeps every 5-20 minutes (just under the time where cellular renegotiation is required). It will occasionally sleep up to 4 hours. I also incorporated this Deep Reset into my PCB: Deep Reset Tutorial. @rickkas7, is the watchdog Timer just an alternative to the previous Deep Reset tutorial using a RTC instead of a GPIO pin or when would someone use this version over the prior? My guess is similar functionality but maybe a nicer by also having an RTC for deep sleeping?

#202

@jgskarda,

  1. I use one of these Panasonic electrolytic caps for the DC-In - EEE1EA471UAP
  1. Yes, exactly. The idea is that with an RTC on the Enable pin, you can use it for both low power “Enable” sleep and as a deep reset mechanism.

Thanks,

Chip

#203

@chipmc - Good stuff. I appreciate the link! Thanks! It’s much easier picking out a cap like this or really any components when you know someone who uses it with success already!

I already have the earlier version of Deep Reset tutorial already integrated into my PCB… and in a few days was placing another order of PCBAs. It’s tempting to switch to the RTC Enable circuit. I wish I would of found this earlier. :frowning: I need to spend more time on these forums than I do I always find a few great nuggets like this on here.

#204

@chipmc [quote=“chipmc, post:202, topic:48750”]
Yes, exactly. The idea is that with an RTC on the Enable pin, you can use it for both low power “Enable” sleep and as a deep reset mechanism.
[/quote]

I read through the document a few times… my understanding is the external RTC isn’t necessarily for Enable Sleep but rather allows for nRF52 MCU “Hibernate” type sleep. When it enters Hibernate sleep, at the specific time of day, it then wakes up due to an interrupt on D8 (Or whatever pin is wired as the interrupt). In this case, it allows us to leverage the lowest possible level of power “Hibernate” while keeping track of the RTC separate than the main Boron RTC since that stops during Hibernate.

I was thinking I could still use this short sleep durations and the the cellular modem would not have to renegotiate after a short sleep duration (<20 minutes). However, then the docs set me straight. “On cellular devices, the cellular modem is turned off in HIBERNATE mode. This reduces current consumption but increases the time to reconnect. Also, you should avoid any HIBERNATE period of less than 10 minutes on cellular devices.”

I understand it as the EN only really comes into play during a watchdog timeout which then pulls the EN pin low for 30 seconds. Not sure if I am understanding this right though? In any case, this external RTC/watchdog method seems like a better way to do it then the Deep reset tutorial.

That all said… looks like we gain a little but not too much between ultra low power sleep and Hibernate sleep. Per docs.particle.io:
“Since the difference in current consumption is so small between HIBERNATE and ULTRA_LOW_POWER, using ULTRA_LOW_POWER is a good alternative if you wish to wake based on time on Gen 3 devices. The difference is 106 uA vs. 127 uA on the Boron LTE, for example.” So for the purpose of this, I’d gain ~21 uA using this circuit over my current circuit.

Seems like the main advantage is maybe a more robust watchdog being external timer as well as saving 21 uA. Now the question for me… is it worth switching if I already have the PCB designed using the prior version. :slight_smile:

#205

@all,

Since @rickkas7 has published a new App Note on Watchdog Timers:

I thought it would be a good idea to adopt his design to replace the RTC and Watchdog elements of this design. This will simplify the board, align to Particle best practices and help improve the stability of the solution. I have respun the board and sent out for a few boards from OSHPark. Please take a look.

Screen Shot 2020-11-02 at 3.03.55 PM
Screen Shot 2020-11-02 at 3.03.55 PM1254×557 81.7 KB

Screen Shot 2020-11-02 at 3.03.42 PM
Screen Shot 2020-11-02 at 3.03.42 PM1277×555 78.9 KB

Screen Shot 2020-11-02 at 3.04.07 PM
Screen Shot 2020-11-02 at 3.04.07 PM870×310 4.75 KB

This implements the AB1805 watchdog without the supercap.

Hope you find this helpful.

Chip

2 Likes
Boron ON/OFF Switch
#206

@jgskarda,

Of course it depends on your particular use case. In my example, I need something that will go into the field for about 3 years and work reliably. For that reason, I am going to respin my board to adopt the approach that is in the App Note. I think this will be the most supported approach that reflects Particle best practices. As always, I will share my results here.

Thanks,

Chip

#207

@chipmc,

Yeah agreed. Pretty sure I’ll be making the switch. Sounds like this is what is in the tracker. Would you mind posting your updated Eagle Cad files to your GitHub repo as preliminary design or sharing separately? I’d like to review it in more detail and might save me some time. Thanks!

#208

Sure,

Here you go. Remember - still work in progress but any suggestions are welcome.

Chip

2 Likes
#209

Agree. Great to finally have a platform recommended solution.

I have a PCB on the way with a TPL5010 as in the App note, but designed before that note came out.

AB1805 looks like an awesome chip. The minimal config solution in the App note, I will likely use later. Without having looked at the crystal yet, I wonder if could be ditched for transport devices, as they tend to break there.

With the complexity of the full solution I think the Tracker SOM is a great way to test that to the max.

1 Like
#210

I also updated my PCB design but used the watchdog circuit from that App note. I just ordered another set of PCBAs for my own PCB with this. Since I was making changes, I also added the cap chipmc used for future Solar charging capability. We will see how long the new PCBA takes to arrive. In the meantime as I wait, I’ll be updating my sketch.

1 Like
#211

Finally found out why the 30s power down is the only safe way (no reliable way to reset modem+OS consistent over several OS releases, as it is not directly exposed and keeps changing). So I have to dump the board I already sent off and put in the AB1805.

1 Like
#212

@thrmttnw,

Sorry to hear you need to respin your board.

As discussed earlier in this thread, the TPL5010’s inability to be synchronized with the device’s sleep / wake cycle was an issue for me too. Also, bonus on the pin deprived Boron, you get the “Done” pin back since you “pet” via i2c.

Yes, I have found that while a power reset should be a last resort, it is often the only way to get back to the known good state.

Good luck!

2 Likes
#213

@chipmc - Overall, really nice board layout and I appreciate you sharing! Something to consider for your carrier board layout would be to utilize the PCB real-estate directly underneath the Boron on the PCB. The bulk of the components are small and easily can fit within this “white space” on the PCB. I think it would reduce your costs quite a bit for PCBA if you can keep it single sided for SMT parts. For example, in a different board, I tried to fit most items directly underneath the PCB on the top side of the board and not have anything underneath.

image
image399×511 51.6 KB

Or was there a driving reason that you placed several components on the underside of the PCB? Just a thought…

2 Likes
#214

@jgskarda,

Good point. Over time, the number of components on my carrier board has steadily gone down. I should take a look if, in the latest design, they will all fit on one side. Great suggestion

The good news is that my assembler, MacroFab, does not seem to charge a premium for having surface mount parts on both sides. Still, worth a look

Thanks,

Chip

1 Like
#215

Oh ok… yeah makes sense. I never priced out a 2 sided board before so wasn’t sure. How do you like MacroFab? I’ve been ordering from PCBWay and I’ve been happy so far. I’m coming in about $10-$15 per board (ordering 10 at a time) and roughly 3 weeks from placing the order to having them in hand. I’ve been soldering the headers and any other through hole components myself but everything else was assembled. I’m sure a lot of it is just personal preference. Mostly interested in the normal lead time from MacroFab. In the past I did OSH Park for PCB only and then PCBWay for assembled.

Particle.io Indoor Project Case
#216

@all,

I wanted to put a pin in this thread as I think I am going to wrap up development of these boards as I think they generally meet my needs. Not sure what the next step is - perhaps the B-SOM? If so, I will kick off a new thread.

Here is where I ended up on this board. I have had MacroFab produce over 200 of them so far and they are working quite well. The main changes since this thread started:

Here is the Github Repo with the latest EAGLE files: GitHub - chipmc/Particle-Boron-Carrier: New version with improved watchdog

And this is what the board ended up looking like:

IMG_5598 IMG_5599

Thank you all for your help and support on this project. I can’t wait to see what we collectively come up with next.

Thanks,

Chip

7 Likes
#217

Great job Chip. Thanks again for Sharing !

1 Like
#218

Great work Chip!! It’s amazing what you shared here with all of us.

1 Like
#219

Fantastic work @chipmc - very much appreciated in all the time you and the community put in to this. It helps us all! I’d be interested in a B-SOM version. I’m not an expert in PCB layout but happy to help in any way I can. I’ve been curious on when someone should transition from a Boron to B-SOM or what would drive someone to use a B-SOM over a Boron. If there is a specific # of devices or maybe functionality needed? As always, still lots for me to learn… but that’s what makes this fun right?

1 Like