Here is what I am thinking for a first carrier board. Before I lay out the board, I thought I would share the schematic and see if anyone has comments or suggestions. My plan will be to build a few, test them in the field for a month or so and then finalize the design. I will document and share everything.
Use case: This is a carrier for the Particle Electorn 3G for use outdoors. I want to be able to either power it from 5V @2A or with a Solar Panel. The device will remain on but will use sleep and sensor interrupts to save power while recording events. Data will be cached / stored locally on FRAM and reported on an hourly basis as long as there is data to send.
Requirements:
2 ic2 bus connections with one configurable to either 3.3V or 5V
The Power line, i2c lines and four digital lines will be ESD protected ( may need to add Earth ground)
Powered either by a 5V 2A wall wart or by a Solar panel
Easy connections to all A and B bank IO.
Push on - Push Off button for the LiPo battery making it easy to turn on and off when on battery power
256k FRAM module on board (you can choose to populate or not)
Kill line would allow the Electron to turn itself off if the power fails and the battery gets too low.
I would triple check your Kill Line logic to make sure the Electron does not go into an ON/OFF hiccup condition. I just mean make sure the pin you’re using for the Kill Line will hold it states when the Electron goes off and does not cause unwanted conditions.
From what I hear an external Watchdog circuit is a good idea, maybe one that needs a pulse every 12 or 24 hours since your unit will be sleeping a lot. This could prevent issues where you need to go out and physically disconnect the battery to reset both the modem & processor. Sometimes hitting REST is not enough, so the Watchdog ideally would cut the power input feed and not just hit hte RESET line on the Electron.
That said, your watchdog timer idea sounds like a good one. I will see what I can come up with and share the new design. I saw something like this on the current solar shield but, I want the Electron to sleep and not be turned off.
I have not read about FRAM being used that much in the current small electronic device market and i admit not knowing much about it so i spent some time reading what google offered up. what struck me is the destructive read process. most of the articles were 3 to 5 years old so the info was nowhere near current but i’m curious about possible downside to using FRAM in a device that will see quite a bit of read/write activity over it’s lifetime.
I think I can implement the watchdog timer fairly easily with a standard TI part: TPL5010.
It will work like this:
Connect the “wake” pin from the watchdog to an interrupt enabled pin on the Electron
The Electron will have a whopping 20ms to “kick the dog” using a “Done” line
If more than 20ms goes by, the watchdog will reset the Electron
The time between “wake” signals is set using resistor(s) and can be up to 2 hours.
I could have it cut power to the device instead of reset but, if it is OK with you, I would like to start with a simple reset as the power cutting will drive more circuitry and require testing to get the sequences and timing right. This way I could get this first board out and start getting some experience with long term stability while doing some testing on the power down / up timing.
As this may not be attractive for everyone, I will add a solder jumper to which can be soldered to enaable this watchdog functionality. I will also provide some sample code.
One question I have is whether I should attach the “Wake” pin to WKP or to another of the interrupt enabled pins (D1, D2, D3, D4, A0, A1, A3, A4, A6, A7)?
The Electron is pretty stable and I can run it for months and the only issue I have found is situations where the Electron will act like it’s sending data normally but the data is never received by Particle or Ubidots. I think this is a cellular network issue since it can happen even when not using Particle.Publish. The only way I have been able to reset this is to pull the battery and reinsert it to reset everything.
This is why I was suggesting to have a Watchdog to reset the main power supply (USB or Battery) every 24 hours to prevent any lockups. It’s like a daily reset for all known conditions I have seen that would require a manual physical reset situation to get the device back online.
I would also use the built in WatchDog timer to catch a processor lockup if it ever should happen.
Not sure if they make Watchdog timers that work on 24-hour gaps but I would think there is something like this out there.
Let me know what you think.
Also, I would just use the WKP pin to wake up the Electron since it’s already setup to do it. Keep it simple even though the other pins could be used also.
OK, very good to know. I also have had good luck with the internal watchdog timer for my other sensors so perhaps the external part was not needed.
How about this? The situation you describe above, where the Particle continues to function “normally” but does not connect could be solved without an external timer or watchdog circuit. All that would be needed is a pin to signal “hey, it is midnight, time for a reset”. Then a small circuit could cut first the external power and then the battery and bring them back battery first then external power.
Presuming the Electron is not locked up (which is what the internal watchdog is for), then this approach has a few advantages:
No external clock to set and enable alarms for
The Electron could take some steps to make this more graceful such as saving state data and disconnecting the cellular radio
As long as the internal watchdog does not fail to work it should be all that is needed.
@rickkas7 What code would we need to do a full Processor & Modem reset? I know hitting the RESET button does not cut power to the modem but that is what we’re trying to accomplish once every 24 hours or so.
OK, I think (hope) we are getting close. Since there have been a few revs, here is a recap:
Use case: This is a carrier for the Particle Electorn 3G for use outdoors. I want to be able to either power it from 5V @2A or with a Solar Panel. The device will remain on but will use sleep and sensor interrupts to save power while recording events. Data will be cached / stored locally on FRAM and reported on an hourly basis as long as there is data to send.
Requirements:
Two ic2 bus connections with one configurable to either 3.3V or 5V
The Power line, i2c lines and four digital lines will be ESD protected (I may need to add Earth ground)
Powered either by a 5V 2A wall wart or by a Solar panel
Easy connections to all A and B bank IO.
Push on - Push Off button for the LiPo battery making it easy to turn on and off when on battery power
256k FRAM module on board (you can choose to populate or not)
Kill line would allow the Electron to turn itself off if the power fails and the battery gets too low.
Hard Reset line to allow the Electron to power cycle itself turning off both DC and Battery power
I will need to play with the component values on the power switch to get the right timing and slew rates but, I believe this meets all the requirements.
So, please take a look. Will start laying out tomorrow - need to fail fast and all.
STM32 GPIO are 5v tolerant as INPUTS. They do not, however, output 5v. Pulling up GPIO lines (with the exception of I2C lines) to 5v will cause a current flow INTO the pin when set to HIGH since only 3.3v is output on the pin. I2C lines are run in open-drain mode, only pulling the output to GND so there is no conflict.
The Application Watchdog, implemented as a FreeRTOS mechanism, will not work if the processor locks up and thus the need for an external watchdog. There are watchdogs with longer refresh periods which may be more suitable (than 20ms),
Thank you for taking a look. I am new to this platform but the strength of this community is a very welcome change from the last platform I built on.
Good catch on D1 and C2 - since C2 is polarized it needs to be protected as well.
On the 5V pull up on the non-i2c pins, I have a 5V sensor with an open-drain interrupt so, my plan was to run pins C2 and C3 as open drain. However, now that I think about it, this arrangement would work pulled up to 3.3V as well and prevent the situation you raised.
I will need to do some more digging on the watchdog timer. Perhaps for the next rev. I had assumed that 20ms was enough time for the Electron to wake and raise the “done” flag but, I may need to do some more testing on the breadboard and make sure it works or, as you suggest, find a different part.
Thank you for taking the time to look at this design. It is rev 1 and I have a lot to learn about the Electron for extended outdoor deployments. I will keep improving this work and sharing what I learn.
The Watchdog you picked was able to work out to being kicked every 2 hours so it should be good enough for the job if you're not planning on sleeping for more than 2 hours at a time.
@peekay123 Also suggested the addition of the external watchdog so I would say add it and then you can test it now vs. later. It's important for your particular application because it can keep you from having to go out and physically mess with the unit once deployed.
If the built-in Watchdog can not be relied upon apon then the external watchdog chip can be.
What data are you colleting by the way? Is this a new version of the park project?
Good point, OK external Watchdog is back in. So much for Simple.
For now, I have car, bike, hiker, temp and humidity sensors. I will also be adding some basic air quality monitoring. The idea is to build a standard platform and then see where it takes me.
You are right, traveling 30 minutes to reset a sensor is not fun. Luckily (knock on wood) my current sensors have proven to be very reliable.
Thank you again for all the great input. I hope you can get some use out of this board once it is done.
Added Varisor protection to Vin and Vcc as they will be connected to external sensors
Added the watchdog timer back in
Removed the “Kill” feature as it can only turn off the device with only a manual button push to bring it back. Seemed like adding all the watchdog and reset stuff made that much less likely.
Next step, layout. Going to try to make the board as small (read cheap) as possible. I will assume that we will all use headers and not solder the Electron to the board since you may need to get at the SIM card someday. Will consider space under the Electron fair game.
Resetting the processor is easy; it’s reset by the RESET line (pulled low), either by the pin or the button (which is just connected to the pin). Also, System.reset() is usually effective, as is SLEEP_MODE_DEEP to force a processor reset.
Resetting the modem is a bit trickier to always get right, as it is not reset when the processor is, by design.
SLEEP_MODE_DEEP is usually effective in turning off the modem, but not 100% so. There are some caveats, especially with threading enabled, but if you do it carefully it almost always works.
AT+CFUN=16 usually works as well. Of course the modem has to be on and more or less functional, but it’s basically the same situation as SLEEP_MODE_DEEP but you have a bit more visibility into whether it worked or not, if you get the command response.
Cellular.off() is a good method. It issues the AT+CPWROFF and also turns off the modem in hardware. The only caveat here is that the call is asynchronous in threaded mode, and there’s no way to tell whether it’s completed yet, so it’s probably best to delay after Celluar.off for a few seconds before System.reset.
You can get the sim card in and out of an electron soldered to a device, even if it is soldered all the way to its spacers. You just need the right tool – I use a solid core 26 gauge wire with a hook on the end to do this because I haven’t found a plastic pick small enough…
You might check out what @pNrie has done here for more reference on electron outdoor boards: Anybody using a particle device with SDI-12 interface?. His connections for antenna and battery work well the battery connector is more rugged than the JST header.
On your concept for how this board is used – is the idea to make this board and then plug your other i2c sensors into it? I am guessing this board and those sensors will be ruggedized? What kind of enclosure are you planning on using?
Good to know, will try to keep that option open for folks.
I took a look at @pNrie is doing and was very impressed. For the next revision, I may also add solar and power management to the carrier board but want to try to use what the Electron comes with for a start. Agree on the battery and antenna connectors and may end of changing these as well.
My board is used outdoors in parks and I use standard i2c sensors. My plan is to add some reasonable level of protection against ESD and transient spikes without dramatically increasing the price. Some of my sensors have been in place for over two years so, I may be taking this protection stuff too far - we will see.
My battery powered Solar sensors are enclosed in a plastic NEMA box. The sensors which will be powered by an outlet will be in a grounded metal case.
Thanks for pointing out what the NRIE folks are doing, I will keep up with their progress.
RWB,
usually the manufacturers data is somewhat weighted in favor of whatever they are manufacturing.
but, like i said, i’m not familiar with the FRAM chip. i am surprised that if it is in fact superior in all ways why the FRAM chip is seemingly not used as much as other memory options. i would have thought they would have gained traction in the cellular phone market at least since longevity is not so much an issue there. are there any cellphones that use FRAM chips that you know of? this ~15 year old article seems just as valid today , http://www.eetimes.com/document.asp?doc_id=1135458
