Electron Carrier Board


Have you tested using the TMP36 directly feeding an analog input on the electron (as shown in your schematic)? I’ve tried to do this, and given up as I cannot get reliable readings because the output impedance of the TMP36 is too high for the ST microcontroller, which needs to charge a significant internal capacitance when sampling an analog input. A voltage follower op-amp buffer might solve the problem, but you’ll need to find one that works with a single-ended supply over the voltage (temperature) range that you care about. Even with the op-amp, I’ve had mixed results and ultimately gave up.

A 1-wire temp sensor was recommended as an alternative.


Yes, have tested on the breadboard and on the v1 carrier with the SMD version of the TMP-36. I am using pin A0 and have not had any issues.



I have created a fresh post with the code needed to implement the watchdog timer. Please take a look and I hope it is helpful.



1 Like

Would this be appropriate in an automotive application?

I have a project where I need a sealed electron. Powering it from a solar panel only would be ideal.

Can you tell me more about the solar input? What are the voltage limits?


Thanks for taking a look. I think this may work in an automative application but, you would need to make sure that the components you select for the carrier board are automotive grade or can handle your temperate requirements (I think the Particle can only go to 140F as well).

As for being sealed, that is my use case and (knock on wood) it is working very well so far.

Solar is an area I have a fair bit of experience with as it is how I run all my current sensors. However, I am relatively new to the Particle platform and would defer to @RWB and others on this. Here is what I have done in this carrier:

  • It is designed to accommodate up to a 10W 6V Solar panel
  • It has a large input cap which should help manage the variations of power from a panel with real world changes in light intensity.
  • I have added ESD/Lightning and short circuit protection to the Solar and DC-In lines as Solar Panels are often mounted high and have long cables.

If this design does not provide proper results, I may use the Solar Power Manager Module I have already designed and tested. My first preference is to use the Electron’s on-board power management.

Here is what still needs to be done (all software)

  • Implement a better barely charge monitoring routine that can change the behavior of the device if battery charge drops too low
  • Implement sleep and wake functions and tie them into the sensor and watchdog timer interrupts
  • Change the behaviors of the device based on time of day (low energy operation at night)
  • Look at power cycling the device on a schedule to ensure proper operation and battery management

I plan to work on the software using some of @RWB 's suggestions in the coming month or two. Happy to share progress. At least one of my installations will be Solar so this is on my list.

I hope this helps. Please let me know if you have more questions.


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.



@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!


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.



@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


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.



@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?


@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:


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.


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,