OK, but what if we connected the RTC to the EN pin instead of the D8? That way, the Alarm would turn on the power for the device itself. For now, we can table this but it could be something to look at in the future.
So, proposal is to go with @rickkas7 RTC and library integrated into this board.
I think this is a nice application of this RTC and would work well for longterm or short term sleep with perhaps a jumper (A-com-B type), that allows the wakeup to either go via driver circuitry to EN or to a wakeup pin (perhaps also an IO to detect the watchdog “mode”)
Thank you for sharing this circuit. I am planning to use the MCP79410 on the carrier board in large part because of the great library you have provided.
I want to make sure I understand your circuit and I apologize if these are basic questions. Please let me know if I have this right.
This circuit will provide a reliable time source that can enable the Boron to go to DEEP sleep and resync its time when it wakes without having to connect to the Particle cloud.
This circuit is more about putting the Boron to sleep for extended periods (such as overnight) by controlling the Enable pin. If I was looking to have the device sleep for shorter periods, I could connect the multifunction pin to one of the GPIO pins on the Boron and wake using an alarm.
The Flipflop and the FETs are used to control the Enable pin and therefore must be powered by VBat so they - along with the clock - can function when power is off.
Yes, you are correct. There is no electrical reason you can’t use it to go to sleep for shorter periods. however the EN line powers down the modem and you will use significantly more power reconnecting to cellular than you would use SLEEP_NETWORK_STANDBY for sleep periods less than 15 minutes or so.
Since the 3V3 line is not powered when EN is low, the RTC and associated circuitry must be powered from Li+. Since that can be as high as 4.2V, the MOSFETs prevents high voltages from damaging the GPIO or applying a voltage higher than 3.3V on the EN line which has a pull-up to 3V3.
To power cycle your device, you could set an alarm for 10 seconds into the future and then bring D3 high. This would pull the EN line low and then the alarm interrupt would bring EN back high when the alarm goes off. Right?
All, I have redesigned the board to incorporate @rickkas7 's Real Time Clock circuitry and all the other great suggestions from this group. My plan is to get a small batch of these made at MacroFab (if I am brave / confident) or have one more run of boards from OSHPark if I am not.
Changes - New Features:
Physical switch to turn off everything on the board but the RTC battery backup for storage and transport
Turning on the switch enables the RTC which can manipulate the EN line to reduce power consumption and then wake the device at a preset time.
The Alarm functionality will also allow the device to “hard reset” or power cycle itself
Please look at the schematics and let me know if I have made any major mistakes.
I am not sure how to offer the RTC functionality if there is no LiPO battery. To be honest, I am not sure how important the RTC is if you are operating the Boron without a battery. Comments welcome here.
Once I am sure about the schematics, I will redo the layout.
I haven’t studied your schematics yet, but It looks like you might have The LiPo connector, C5, U4, and R9 within the keepout area for the Boron. I don’t know how hard a requirement that keepout area is, but you may want to consider it.
Thank you for taking a look. C5, U4 and R9 are on the underside of the board (red pads) while the Boron is on the top. The LiPO connector is the only potential issue but, I have tested this clearance on a previous iteration of the board (see pictures above in this thread) and we are good.
Please keep those questions and comments coming.
Also, wondering if I should take the FRAM off the board as it is a $2 chip and the Boron will eventually have its flash memory available for use.
I’m leaving the FRAM on my board for now since I have the code working well, even though I pay about $3 per chip (256Kb). I bought a reel of 100 of them though, so it’s a sunk cost for my prototypes. In the future, once the 2MB flash is exposed to us, I can simply depopulate the chip, or remove it completely from the design. I do like the fact that it doesn’t have destructive writes, so I am considering possible uses for that even once onboard flash is available for certificate and configuration storage.
Great question, especially since this thread dates back to March!
Here is what I had originally outlined:
Temp sensor in case I need to control LiPo charging
External watchdog timer - connect to either Enable or !RST
Single - button on / off so you can leave the battery and power plugged in
The ability for the device to power-cycle itself
ESD and fuse protection
Headers for i2c, SPI and IO
Big capacitor on DC-IN to support Solar Powered use case
I would say that all of these are met with one (small?) exception. The ability to power cycle the device is limited to use cases where the device has a LiPO battery installed. I am wondering if this is a big deal and, if so how best to accomplish this. I have toyed with some solutions but all came with cost and complexity that I felt was not worth the benefit. Comments welcome.
In addition to the original list, there are two big additions:
The ability to screw the Boron / Argon / Xenon down in case there is a concern that vibration might cause the device to come off the headers.
I added a Real Time Clock since the Gen 3 devices do not have one. This enables either Deep sleep (which I am not implementing here), Power - Off sleep using the Enable line (is implemented here) and using time functions while the device is not connected to the network.
Take a look and let me know what I could do to improve.
This all looks great, Chip. I don’t see any obvious errors in it. The one suggestion I have, and it’s really just based on personal preference, is to replace the TMP36 temperature sensor with a DS18B20Z+. It’s easy to interface to and much more accurate than AD conversion on the Boron.
I have a few questions. I appoligize in advance if they are stupid or silly.
Since you’ve added the MCP79410, what purpose does the TPL5010 serve?
Looking at @rickkas7’s Library, it appears to have a ton of useful features.
I’ve used TMP36/37’s to help decide when to disable Li-Po charging, but that only works when the Boron is awake obviously. In reality, there are only 4-6 hours a day that the enclosure temperatures can get too high, and that’s mainly a few months in each year.
It appears to me that with the MCP79410, a progressive or regressive Sleep/Shutdown schedule will be easier to implement. IE: Wake up a few times during the Hottest times of Summer Days even if you don’t need data, just to check the Temperature and disable charging if Req’d.
Would that be possible with the TPL5010 onboard ?
If the Boron is Shutdown via EN pin by the MCP79410 and a Motion Sensor is activated, how can that Interrupt be handled by the MCP ? I assume that’s only possible with the TPL and not using the MCP and EN pin?
Again, I’m sorry if these are stupid questions. I’m very interested in your Carrier Board even if it’s “Over My Head”.
Great questions and the whole purpose of posting all this here is to make sure I have thought all this through. Thanks for asking them.
Power: My devices are in remote spots and the watchdog timer is there to make sure - not matter what I screw up in the software, the device will be reset if unresponsive. The clock could do the same thing but, what if the i2c bus locks up or something happens that prevents the RTC alarm from being set? At least that is my rationale.
Temperature: With a watchdog set to 1 hour, the device will wake on that schedule. I figure that checking the temp is quick and easy but, to your point, every hour and every month is likely overkill. Note, if the RTC turns off the device with the EN pin, it switches off the watchdog as well.
External Interrupt: You are correct, shutting down the device with the EN pin prevents the device from servicing interrupts. I am thinking this is OK for two reasons: 1) The EN sleep will be for longer periods - overnight for example and 2) I have an idea for a super low power data collection device.
That was an important (and beneficial) aspect that I overlooked.
So, normal operation is to wake every hour and decide if starting the Modem and a Publish is necessary, then quickly trigger the TPL’s done pin.
We can also use the RTC as a fail-safe to allow much longer sleep times (actually Shutdown via EN pin) in the event that Battery Voltage has dropped too low. The only goal during the fail-safe Shutdown is to allow the Battery Voltage to recover, before resuming normal operations.
Another thought about the TPL5010 + MCP7941X (RTC) as an Alternate Use-Case:
I don’t have experience with the TPL5010, but I know the TPL5011 will reset the device if the DONE pin isn’t triggered within the time period set by the resistors. The Sleep Time also becomes the maximum AWAKE Time (unless you tickle the delay pin on purpose). It seems your board might allow us to alternatively use the RTC as the adjustable Sleep (Shutdown) Timer for everyday use. The TPL5010 would only reset the Boron after 1 hour of AWAKE time if something went terribly wrong and the Boron didn’t set the next RTC alarm over I2C ? The RTC would handle the normal Shutdown intervals and is infinitely adjustable on the fly.
IE: The MCP7941X (RTC) handles the WAKE Time, the Boron decides the next Sleep interval (or specific time/date) and resets the RTC for the next Wake time. The TPL watchdog becomes secondary to ensure a complete Power Cycle Restart if the Boron stays Awake longer than 1 hour (our Code crashed).
The MCP7941X features two independent alarms. Each alarm can be used to either
generate an interrupt at a specific time in the future, or to generate a periodic interrupt
every minute, hour, day, day of week, or month.
Please let me know if my above assumptions are incorrect.
Thanks Again Chip !
Just a question - you have the BATT-IN line being switched through the TPS22810 to LI+.
If this switch is unidirectional - how does the lipo charge?
secondly - this may have been covered already - if using an Argon/Xenon, the (potential) 6VDC from the panel (on VUSB after F1, is above the regulator limits - you will need a Zener diode to clamp the voltage - the TVS diode is great for surges but not to clamp a voltage to a set point over time.
Thank you for the suggestion. The DS18B20Z+ is a cool part (parasitic power!) and is more accurate than the TMP-36. I would be interested in getting more folks opinion but, here is the rationale for keeping the TMP-36:
This is the temperature inside the enclosure and is concerned with LiPO charging safety, accuracy is not a major concern.
While the ADC conversion is likely not very accurate, it does not require any drivers. I am assuming that the Maxim part would require the One-wire library. I am thinking that more libraries = more code complexity but I may not be thinking about this right. Also, the ACD process may have its own warts (power or latency?). Open to more on this.