Electron Carrier Board

All,

Just wanted to post an update on this project.

The version 2 board has survived a month now in the NC heat and despite temperatures up to 110ºF it has operated flawlessly. The watchdog has only reset the Electron once so, all seems to be good.

That said, I wanted to make one more tweak before going final on this project and making a larger production run. Here are the improvements for version 2.1 which was sent to OSHPark yesterday.

I added a user-defined push button switch. I will use this to turn the Particle RGB and D7 LEDS on an off but, it can be used for anything.
I enabled the “Kill” feature where the Electron could shut itself off completely. The only way to turn the Electron back on would be to physically push the power button.
I added a 5V buck converter to Vcc for the 2nd i2c port. Before this came from Vin. Now that it is separate, Vin can now be 3.9-12V enabling the use of 12V Solar Panels for power.
Both the Vcc and the 5V supplies have their own ESD protection and fuses

Here are the Schematics. Once I have tested the board, I will write it up and provide the EAGLE files and Bill of Materials. If anyone wants this sooner, send me a PM and I am happy to provide.

Thanks for all your help on this project.

Chip

4 Likes

@chipmc, gosh I like what you’ve done here! One thing I have been meaning to explore is the use of a Maxim DS2482 I2C to 1-Wire bus master to (reliably) use 1-wire devices. I have also had great success using 2MB SPI flash chips (eg M25P16 and larger) with SPIFFS which is a wear-leveling-aware file system library for NOR flash. I used these in lieu of microSD to avoid mechanical issues. My experience with FRAM is limited to SPI. I wish it wasn’t so darn expensive and was available in larger sizes.

I particularly like your power management chain. The only thing missing is a timed “wake from kill” power-on feature. Having a “deep freeze”, being one level of power savings better than deep sleep, would be a great option. Thanks for all the great work!

@peekay123,

Thank you for taking a look and the kind words. I only hope this project can be of help to more than just me.

There are two things I need to add to my “when I am not buried in current projects list”:

  • 1-Wire
  • Alternatives to FRAM. I know I am paying a premium but it just works so each project, the path of least resistance is…

Let me think about the timed “deep freeze” it is possible that I could use another ($0.50) watchdog timer to wake after “Kill” has ben asserted.

Also, it seems that the IO pins on the Electron do some random things when it is reset / powered up. May need to add a pull-down resistor to “Kill” - will see once I get back from OSH-Park. This is why I don’t just post the EAGLE files until I have had a chance to validate them myself.

Thank you for all your help as I get up to speed on the Particle platform.

Chip

2 Likes

@peekay123 @chipmc I’m needing to add in a watchdog circuit to a few of my projects so it’s nice to see that you’re testing a watchdog timer and it’s working as it’s supposed to.

I don’t understand the “Wake From Kill” Power ON feature @peekay123 is talking about? Doesn’t the single watchdog do this? Or are you talking about another Watchdog chip that can wake up over longer time gaps?

@Peekay123 What do you think is the ideal Watchdog setup for the Photon or Electron for a commercial product? I just need to make sure my product does not freeze up on a remotely located off grid install.

1 Like

@RWB,

I need to do some testing on this but I think it would be a second watchdog with an interval appropriate waking such as 8, 12 or 24 hours.

Thanks,

Chip

@RWB, a “wake on kill” is an external timed power-up from power-off (killed) mode. I have to do some research on what available and if the wake time can be programmed.

As for the watchdog, the IDEAL one is the STM32 internal WDT. However, it seems that using it is not ideal and I have to do some digging into this.

A possible alternative to a “pure” hardware watchdog is the use of an ATTiny85 connected over I2C or 1-wire to the Electron. The MCU could act as both a watchdog and a programmable wake-from-kill timer. It could also monitor a voltage or two to warn the Electron via a single interrupt line if a bad supply condition occurs. These 8-pin puppies are easy to work with and can be run very low power. An alternative is to use a low power PIC processor. Food for thought.

I like the idea of just using an external ATTiny85 considering that provides maximum flexibility along with the fact that the ATTiny85 has good support online. I assume that ATTiny85 also has built in reliable watchdog.

I wonder what is causing the built in Watchdog on the STM32 chips from being reliable? That’s the ideal zero cost solution I think :slight_smile:

I do remember @Bdub saying that it’s common practice for embedded designers to add an external backup watchdog even when the MCU has an internal watchdog circuit.

1 Like

@RWB, the Attiny IS the watchdog! The simplicity of the code, no RTOS, OTA, WiFi, etc. make it very reliable IMO, though not quite as reliable as a “true” hardware watchdog. I would consider them about the same. I can’t speak to the STM32 internal watchdog as I haven’t done the research to bring me up to date.

Yea, I get that :slight_smile:

A watchdog with programmable over I2C would be nice so you can easily adjust wake-up intervals.

1 Like

@peekay123 and @RWB,

OK, I have an idea and am willing to do some development and testing on the watchdog front. Please let me know what may be the most promising approach.

Objective (please let me know if I am missing something here):

  • Monitor the Particle device and reset general lockups
  • Monitor high value / high risk processes and reset if they don’t complete successfully

You can see how I am doing this in my current code. But there is an issue - my current setup has a set and fixed watchdog interval. I think the watchdog would be more effective if the interval was dynamic. Some examples:

  • when I water, I would set the interval to a little longer than the watering period
  • when sending a web hook, I would set the interval to just a few seconds
  • when interacting with i2c devices, I would set the interval to a few hundred milliseconds

Two approaches:

  • Use the current TPL5010 watchdog and an i2c controlled digital rheostat to change the interval as needed.
  • Implement the ATTINY approach and communicate over the i2c bus with a multi-master scheme (see here for how I do this) or directly using something like a serial connection.

What do you think?

Chip

@chipmc, I have a feeling that you are doing too much with the watchdog. Robust systems make use of a) stateful programming and b) exception handling. Creating a large or dependent/independent FSMs in your code will allow the program to respond best to exceptions. FSMs also provide a great way to create non-blocking code. Almost, if not all, controller-type applications use an FSM. With clearly defined states, exception handling becomes very clear.

FSMs can be used in your loop() code, in an ISR or a Software Timer if they are properly designed to be non-blocking. I honestly think FSMs are under-utilized by programmers.

The idea of a watchdog is to trigger a reset of the MCU (and thus the FSM running on it) to restore a safe state. You can use soft timers, millis() timers or hardware timers (SparkIntervalTimer) to create “exception watchdogs” such as a timeout in I2C communications or when you send a webhook. If under all exceptions you want to reset the MCU, then leveraging an external watchdog is ok. If, instead, you want to handle an exception (timeout, bad values, etc) within an FSM state then the aforementioned use of other timer resources is better. The trick is to design a good FSM by defining a solid set of states and sub-states. :wink:

2 Likes

I need to study more on how to properly write FSM code/programs. I keep hearing FSM's structure is the professional way code projects properly.

@chipmc I think keeping the watchdog timer simple as possible is best mainly because you just want it or need it to work when you need it.

I just setup a PWM fan speed controller on a Arduino UNO and used the built in 4 second watchdog timer which works perfectly fine. I wish the Photon & Electron had a built in watchdog feature that was just as reliable.

I would think using an Attiny chip as a watchdog would not be as reliable as a dedicated watchdog chip would be. I'm sure you can use either but I would feel better about the dedicated watchdog chip for the Photon and Electrons.

For plant watering, I just picked up 3 of the Chirp water alarm sensors for my wife so she can use them in her new indoor plants. They were cheap and simple so I'm interested in seeing how they work over time.

1 Like

Your words in Particle's (namely @mdma's and @will's) ears, since the STM32F has such a watchdog, but it was laid on ice for some reasons in earlier system iterations, but they this might not need to stay that way (as heard from devs ;-))

1 Like

Good news!

It’s a feature that I would say that every project could benefit from using.

@peekay123,

Thank you for the honest feedback. I have to admit I need to do some homework on FSMs (Finite State Machines) in order to get the full value of your comment. This is a good project for a learning experiment. Perhaps after I learn some more about this approach, I will not rely so heavily on watchdogs to ensure reliability.

Every time I post to this forum I learn something. Thanks again,

Chip

@chipmc, I’m learning lots also! I haven’t yet exploited UML for designing state machines. There are many tutorials available. There are also a lot of FSM design tools, some which produce Verilog (FPGA) code and others that produce C code. It is worth taking the time to learn about FSMs.

2 Likes

@chipmc, this looks like a great board! If/when you get to the point of being comfortable to let it out to others, I’ll definitely be in the mix for a few. I’d be most interested in a populated board, but would take a crack a learning to solder up SMT components if it came bare. I’ve been using the Asset Tracker to have a board that I can use for some projects even though I don’t have a gps need. My
needs tilt towards Solar power with a small lithium battery, and being able to use a few analog and digital pins, probably some I2C capability down the road.
J

@jimbol,

I have just built and deployed a second round of these boards. The longest running have been in the park for 90 days without issue despite some serious storms and heat. So, I do feel confident that these boards can last.

I plan to document the board so anyone who wants to can make one. However, I know that SMD soldering can be frustrating so, I am open to making some for sale. I need to figure out some things first like the cost of the bill of materials, some low volume assembly costs and the mechanics of selling hardware. The big question is whether there is much interest in this board.

I will document this project next week. Then I can post the documentation and gauge the level of interest. I can get you some boards regardless if that will help you out.

Chip

2 Likes

@chipmc Here is a place in Texas that does small run production and has a nice online BOM and board layout and cost calculator you can try to prevent yourself from having to build the boards yourself.

https://macrofab.com/

1 Like

@RWB,

Great minds think alike. Listen to their podcast each week. Hope the storm did not set them too far back as they are in Houston.

Question would be how many to make. Not in the hardware business so don’t need to turn a profit but, I don’t want to build a bunch of boards nobody wants either.

Chip