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?
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…
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.
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
I think that the biggest drawback is cost / mb as peekay123 points out and for the phone example, this is also an issue of density.
However, for my little device, I have figured out how to carve up and use the 256k very efficiently and can store almost a year’s worth of hourly data. Since I am not buying a large amount of storage the cost issue is not as acute. Also, FRAM does not need a battery backup like NVSRAM. I have been using FRAM for a couple years now and am very happy with the results especially in outdoor uses where there are significant temperature swings.
Always open to new ideas, what technology technology do you use?
Chip, i have not used external memory chips in my projects yet, although from what i’ve learned in this thread that may change in future ones. currently i use sd cards if i want to save data. i like being able to move the data easily between devices. although now that i think about it there probably could be scripts to transfer the FRAM contents to other devices.
I started with MicroSD way back but there were two big limitations which caused me to switch to FRAM:
MicroSD cards draw up to 500mV briefly when writing. I was operating on a low (Solar) power budget so, I wanted a more energy efficient option.
The libraries for MicroSD were based on a FAT file system. I could append data to a file but I could not easily work with data directly. With Ram, you can segment the memory to store the state of the system, variables and data. With this approach, my device could lose power and restore automatically to the state where they left off. Not sure how to do this with MicroSD.
@chipmc, microSDs can draw a lot of current and I have found some still draw considerable current in standby as well. The biggest driver for microSD is the huge storage available. As for managing data, using the SDFat library with binary files allows for structured data storage (binary file) allowing you to work with data “directly”. Using SDFat requires careful consideration of where to store persistent data pointers, etc.
The main driver for using hardware FRAM, flash or eeprom for me is the mechanical resilience versus microSD. In industrial applications where vibrations are an issue, these are not optional. FRAM’s speed and zero write-wearing are only outweighed by the size limitation and their costs. I have started working with 512 and 1024 Mbyte SPI external flash chips using SPIFFS (SPI flash file system) and though it is limited in speed vs FRAM and SD, in most (if not all) applications, this is fine. I don’t have enough data to say if this approach is good or not just yet.
All, before I spend too much time hand tuning, I wanted to share what the general layout is looking like. The board is 3.75" x 1.35" and will cost $25 for three from OSHPark. Don’t order yet as I need to do all the electrical and design checks. I also want to use more pours for the power path. Still, from folks who have used this device more than I, is this a reasonable layout. Headers, connectors and power on one side and all the surface mount components on the other.
Now if I could only get the Particle Dev to compile for me…
@chipmc, some of the trace widths for power seem small (eg. D1, varistors). You might want more GND vias on the JST. Not sure why D1 is in the middle of the board vs next to the connector. Otherwise layout looks good.
I don’t have an Electron Board but this is just a suggestion to reduce the labor involved in connecting things together. I see you have an 18 pin connector for what I presume is an interface to some remote io circuitry. Whenever I connect to a remote circuit with several wires involved I use a double pin header which allows using a ribbon cable connector that is fast and easy to wire up as opposed to handling individual cables. I also always add redundancy by using a few extra lines and double up conductors on the power (gnd,V+) to reduce voltage drops.
Double row of pins to support a ribbon cable connection. I like this idea a lot but may wait for v2 when I have a better idea of what specific IO circuitry I will need. At this point was just looking to solder wires into the unpopulated header pins and start using the circuit.
I will definitely be beefing up the power traces and adding lines.
Thank you for taking a look. Especially the ribbon cable idea.
I have sent the first version to OSHPark and will keep you all posted on my testing. If all works, I will document the full bill of materials. I built this to be hand solderable however, let me know if you are interested in a finished board for purchase. If there is enough interest, I will create a Tindie listing.