It is time to start to wind this thread down. I have just received 45 boards from MacroFab and will be deploying them to the parks starting today. The boards are testing well with the only manufacturing issue being incomplete coverage for a solder jumper which is easy to spot and fix when I solder on the headers. Please take a look. If I can get 20-30 out for a month or so, I will organize a larger buy (~100 which should bring the cost down below $40).
Please let me know what you think.
Here is the Github repo with the EAGLE files
The boards look great!
Now, please forgive me since I’m always unclear on what is included in the price (since I’m not familiar with the process) and I need to ask.
When you say:
$40 would be with the components mounted, or only the board, or something else?
Good question and sorry not to be clear. This price would be for the assembled board. The only part you would need to hand-solder would be the two headers the Particle device plugs into.
I just read through this forum! Wow… fantastic work and thank you for supporting the open source community! This was a fun read and I learned a bunch! I did have 1-2 quick basic or unrelated questions that I was hoping you could help me with.
- You mentioned being able to directly use a Solar panel for your Boron that you have deployed. Does this require any special circuitry for Borons or are you connecting the Solar Panel directly to VUSB PIN and using only the On Board PMIC for solar charging. Would you mind sharing a link to what you use for Solar Panels? I’ve been tempted to try https://voltaicsystems.com/ but using Solar with the Boron is new to me. Is this as simple as connecting it VIA USB port of the VUSB PIN? Is there a particular solar panel that you use that you find works best/properly matched to the needs of the Boron?
- If my application wakes/sleeps every 2-4 hours, is there still a benefit of having the external RTC? I currently connect to the cloud every 2-4 hours and call the Particle.syncTime() every time. Is there just too much variability in how accurate the on board sync time is vs using an external one?
Once again sure appreciate you sharing this and all of your knowledge! Great work!
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.
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.
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 for the info @chipmc !
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.
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?
@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. I need to spend more time on these forums than I do I always find a few great nuggets like this on here.
@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.
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.
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.
This implements the AB1805 watchdog without the supercap.
Hope you find this helpful.
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.
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!
Here you go. Remember - still work in progress but any suggestions are welcome.
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.
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.
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.
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.
@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.
Or was there a driving reason that you placed several components on the underside of the PCB? Just a thought…
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
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.