Recently, I have seen some opportunities to build devices for non-US customers. For European and Asian markets, the only option (using IoT protocols) is the BSOM / B5SOM form factor unless I want to buy the more expensive Tracker and Monitor devices which are a great value for what they do but have a lot of feature / function I would not need. This is my first assumption and please feel free to challenge it - and the premise of this project - if I am thinking about this wrong.
My idea is to start with the great example that @rickkas7 has created here:
and make the following changes:
Add the AB1805 Real Time Clock and Watchdog Timer (include ability to “power cycle” device)
Support this RTC with a super-cap and temperature compensated crystal to simplify the circuitry and improve accuracy in hot / cold outdoor environments
Add connectivity for SPI, Analog, Serial and i2c using standard JST-SR connectors
Add protection to circuits that will be external to the device
Determine if additional decoupling capacitance is needed on DC-In to improve Solar Charging
Add a “user button” and an “on-off” switch
Add a simple analog temperature / humidity sensor on the carrier board to monitor conditions inside the enclosure and determine if charging is allowed.
Other ideas (not sure if these will make the cut):
A connector for a “daughter card” for sensor specific circuitry
A magnetic sensor to support resetting the device without opening the enclosure
Comments / suggestion are welcome. If there is interest in this, please let me know. As always, I plan to do this interactively, will share all files and, when I get these manufactured, I will give folks a chance to pile on the order to reduce costs.
will this board work with any Particle BSOM/B5SOM so this board could “replace” the carrier you already have for Borons in North America?
In other words, will this board be almost a worldwide option with Particle cellular devices?
Yes, in the documentation, it states that while you cannot mix BSOM (NA) and B5SOM (Europe / Asia) in the same project, you can design the carrier board to accommodate both.
The big issue on this device is that you are putting more onto the carrier and will likely need some sort of FCC / CE certification. I will likely pursue this but would be happy to accept any help on this front when the time comes.
So, here is a first pass on the schematics. Almost all IO pins are broken out but, please take a look and let me know if this would be general purpose enough to meet most folks needs.
Still do to:
build the equivalent functionality as the Enable pin so you can power cycle the whole board with the RTC / Watchdog.
Add the protection circuits for the external IO pins (Fuses, Varisistors and the like).
Thanks for sharing that @chipmc !
Are you envisioning that the AM1805 will control the 3V7 power net? If so, you’ll have to implement it in such a way that the system is default enabled, so in case where the RTC goes belly-up or its supercap drains out, the system can still recover.
P-MOSFETs controlling the DC-In and LiPO positive lines
simple slide switch controlling the FETs so when it is off, the whole board is off - this is for storage and to make it easy for untrained operators to power cycle the device. Open to a better idea here.
Enable pin pulled high so default on
The RTC could pull Enable low for a “deep power cycle”
I need to work through the interaction of the power switch and the enable line.
By using a superCap, we don’t need a separate buck converter connected to the LiPO bypassing the high-side switches. The AB1805 battery backup power consumption is 330nA. The Seiko MS421R-IV03E has a capacity of 1,500,000 nAh. This battery will provide about 6 months of backup time. (1,500,000 / 330) / 24 / 30 = 6.3 months.
Quick question on capacity.....you'll want to take a look at the performance curve for the backup battery, with your minimum operating voltage in mind. The rated capacity might be when discharging through some Voltage range that wont be entirely useful for your application ?
Will the HW Watchdog be able to Force a Reboot/Cycle Power this effectively also ?
How long of a time period can/will you disconnect all voltage sources during a Required Reboot Event ?
I'm thinking about external capacitance from sensors that could provide a feedback voltage.
Oh man, great point on the discharge curve for the SuperCap. Looking at the data sheet, I realized that piece of information is missing. More homework required here - thank you very much for pointing this out.
It seems that the AB1805 needs at least 1.6V for battery backup to preserve the the time. Need to ask about the capacity of the superCap from 3.3V down to that value.
One other thing I realized by looking at the data sheet is that I will need to add a resistor in series as the internal resistance of the superCap is 400ohms but the AB1805 needs 1.5k.
Data sheets! - who would have thought they could be this important!
On the watchdog, I am quite happy with the way the current setup on the Boron carrier board works:
Watchdog resets using the reset pin on the Boron
Power cycle is triggered by a function call to the watchdog.
One reason I like this is that I believe there could be an issue with the Cellular modem if power is removed abruptly:
Putting the power cycle as a function gives me the chance to make sure the cellular modem is off before power cycling.
Does this make sense? This TAN004 is specific to the SARA R410 - perhaps this is not as important for the BSOM / B5SOM modems.
Thank you again for taking a look here - very helpful!
I see, so the RTC will only be used for deep power cycle or to hold the EN pin low for a given duration, not to "kill" power for a given duration. This would mean that if the RTC fails, the device can still remain enabled. I like this approach as it feels a bit safer than to just completely kill power to the whole device for extended periods of time.
BTW, the PMIC (BQ24195) on the Boron allows one to put the unit in shipping mode wherein the LiPo is disconnected from the system. It consumes around 15uA in this state. But the only way to bring back the unit is to plug in an external power source.
Thanks again for taking a look at this. I think I have an approach that will work based on my experience with the Boron carrier. I would be interested in your thoughts:
The AB1805 can power cycle the BSOM using the deepPowerCycle API call in @rickkas7’s library
The AB1805 can also perform a pin reset of the BSOM if it is not pet on time.
There is physical switch to turn off the device for storage and transport. I chose this over an API call to make it easier for the end users to operate.
Clock time is maintained using a super-cap so I don’t need a buck regulator for the RTC as in the Particle reference design.
Question: did I implement the VUSB and VBUS interaction correctly? My intention is that the DC-IN and BATT at switched but I don’t think I can do this with VUSB - does this make sense or should I move VUSB back before the P-MOSFET so it can be switched as well?
@all,
This is my first pass at the schematics. Please let me know if you have any comments / suggestions or would like any additional feature / function. Otherwise, I am going to try to lay this puppy out. I wish Chat GPT could help me with this…
@chipmc - Are you still progressing this open collaboration for a BSOM carrier board? Has the design continued to progress? Have you ordered a first set of boards yet?
I am considering a P2 and maybe eventually a BSOM carrier board. In any case, I’d like to reference some of the same design principles you have here.
I have started to lay out the board but have some work to do yet.
What is concerning me is the volumes required to justify the FCC cert as I don’t think this carrier board can pass with an “unintentional radiator” approach given the need to implement the power / battery management on the carrier. Certifications are not cheap and I was hoping some other folks might be interested so I could reduce production costs and amortize the certification costs over a larger run.
Let’s talk and see what makes sense. Also, happy to hear from anyone else interested in this project.
Chip, I may have some ideas on funding the Certifications for an open source project. It would be related to my recent post in the brainstorming category for Data Collection of Wells, pump stations, etc. Simple I/O stuff, but reading split core CT's (off-board) would be an added benefit, even if a daughter board was required.
I'm just guessing at budgets... but is $15k-25k in the ballpark for FCC?
Can we have a phone call tomorrow to discuss if this would be a good match/sister project for your cellular carrier board to fund the Certifications ?
Yet, they are named Dev boards so this plan may not scale well.
However, it allows selling in european, which was one of the premises of the original carrier.
That probably won't work as a certification work-around. When you purchase a Muon, the M-SoM and the carrier board are separate units that you plug together yourself. If you sell a product with the parts already assembled, it would trigger the need for end-user certification of the entire assembly.
