The board passes all the tests in the automated test sketch (i2c bus, FRAM, RTC, User Switch, Temperature, Alarm functionality, RTC triggered Power down sleep)
I did make a mistake in the schematics above that cost me a FRAM chip. My Programmer (Sparkfun AVR Pocket Programmer) provides only 5V power which is above the absolute max the FRAM chip can stand (4V). So, I made a slight change to move the ATTINY Vcc on the output of the diode. That way, no matter what devices you may chose to put on the board, they will not see 5V.
I was able to load the TinyWireS library on the ATTINY and validate that it is showing up as an i2c device for the Boron. I have not yet started writing the new watchdog code with programmability but will work on this while the board is being manufactured.
I spent some time working on the IO connectors and came to a few realizations which I wanted to share:
Seeeeeeeed Studios Grove is not a standard JST socket - so they are out.
JST SRT series 1mm pitch connectors are remarkably robust and save a lot of space on the board.
There are a number of sources for JST SR/SH pre-crimped cables and kits so the fact that the crimping tool costs SEVENTEEN HUNDRED DOLLARS!!! is not as big a deal as I thought. I will share more on this in a separate thread.
Pre-made cables are easier to find in 4-pin and 6-pin configurations so I standardized on them.
Qwiic cables and board to board cables need to be “Reversed” I almost fried a new Sparkfun TOF board with this mistake.
There is absolutely no agreement on pinouts for standard headers (serial, SPI, Analog IO, i2c with interrupt pins) except for Grove (see above) and Qwiic. So, I put a Qwiic port on the board and followed their convention for the other headers. This means I had to put Vcc next to ground but I held my nose and did it for consistency.
Next steps:
I plan to send this board to MacroFab for a small run ~20 in the next day. These boards will be expensive $65 because it is low volume. I will then field these boards (assuming the Boron Solar fix works).
Once I validate the next batch, I will do a much larger run to bring the board costs down to about $30 and would be happy to include others in that run to help increase the volume and lower everyone’s costs. I am not trying to make money on carrier boards so, I am opening this for the mutual benefit of a larger run for the community.
I will share everything including the EAGLE files so you can take this project and make the changes that best suit your needs.
Please take a look and let me know if you have any comments. After this first production run, I think I might start a few new threads (higher volume community run, JST SR/SH Qwic cables, Watchdog Timer).
Thank you for taking a look. I do this work in the open because I benefit greatly from interaction with the community.
One thing, I still have one feature to test and will come back to this thread (likely on Friday) to share the final tested schematics. I may have an issue with the circuit I (mis?)implemented from @rickkas7 . Should have a final result on the "Enable Sleep" then.
BTW, having an external Real Time Clock means that the Boron sleep environment is more complicated than for the Electron. I am working through these issues in this post:
Also, I plan to kick off a separate thread on building the ultimate watchdog timer. Coming soon.
Thanks and please let me know if you have any questions.
OK, here is the latest mostly good some bad (since I spent a fair bit on a run of boards that will likely need to be scrapped).
Overall the board functions as expected passing all the tests but two.
I thought I could use an OR gate to support interrupts from both the RTC and the watchdog. This turned out not be be very easy as the RTC could “mask” the watchdog interrupts. I had hoped that Sleep 2.0 would fix things but the Boron does not have 5V tolerant pins like the Electron so I either need a dedicated 3.3V, a voltage divider or a MOSFET and none feel like a great solution. I will either have to dedicate another GPIO pin to the RTC or test some different approaches.
I will post an update once I have a proposed solution.
There are two issues with the board as it is currently laid out. One requires two traces to be cut and two “bodge” wires. The other issue can be “fixed” in software.
Still, I should have a revised layout ready by COB tomorrow.
Also, I ordered 20 of this first run from MacroFab so they are fully (except the throug hole headers) assembled. I would be willing to sell them at a significant discount if you wanted to start testing now. Send me a DM if interested.
Thank you for your patience. I have finally completed my testing and there are some changes to be made - I hope these are final.
After testing Stop Mode sleep and Standby Sleep (DEEP_SLEEP_MODE) I have proven to myself that the difference between the two in power savings between the two is too small to make the complexity of supporting both worthwhile. So, this carrier board will support Stop Mode sleep which maintains an internal (inaccurate) clock and does not force a reboot upon waking. This eliminated the OR Gate and a lot of complexity on the routing. It is also easier for the code as your place of execution and variables are saved.
The Real time clock will serve three functions in this design:
First - It will keep accurate time and help prevent drift when there is a lot of stop mode sleep
Second - It will be used to put the device into “Enable” sleep where the enable pin is pulled low and the carrier board power is brought to zero.
Finally, it will be use to “reboot” the device to clear errors in the devices on the carrier, the Particle device and the cellular / wifi module.
I have significantly simplified the power control circuitry, eliminating the flip-flop, the FETS and a bunch of related components. We now connect the RTC Multifunction Pin to the Enable pin so the RTC can control it directly. As a fail safe, there is a button that can pull the Enable pin high even when the device is in “Enable” sleep. Please take a look at the schematic below and let me know if I am missing anything.
Only thing I can see is that if its in enable sleep and you push the button to wake up - it may have to be held in until some code kicks in to reset the RTC?
@shanevanj, Yes, you have to hold it long enough for the device to connect (if it needs to) and make it through setup. I don’t see this being used often but, I know if I left this button off, I would be stuck with a device I could not wake.
BTW, I wanted to only have one switch which would wake the device no matter the sleep state. However, EVERY ONE of these little switches are Single Pole - even though they have four pins. Crazy!
I will do some testing at local parks with my modified boards and hope to get this carrier out the door soon. This gives me a week or to to find the right switch.
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).
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:
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?
