Electron Carrier Board



Right, at this point, if the initialization failed the system would reboot until it succeeded. Putting the finite state machine aside for a minute, what should the behavior be? If the soil moisture sensor fails to initialize, then how will the system know whether to water? I need to think about this as I know the current approach is not optimal.




I think this has been a very useful exercise and one I plan to use in other projects. There are a few particular benefits:

  1. When troubleshooting, if you know the state of the machine, you can narrow your search for the problem to a specific piece of code where the problem will be.
  2. The exercise of creating the state diagram forced me to think about exactly what I wanted the code to do and provided structure that made coding easier. I simply wrote the code for each state once the overall flow was set
  3. When I want to add more functionality, it can be done cleanly as a new state or a modification of an existing state. This should keep the code from getting too complex over time.

I think it has been worth it and I suspect this will be even more true over time.



To FSM or not to FSM (Finite State Machines discussion)
To FSM or not to FSM (Finite State Machines discussion)

@chipmc, glad to hear your impressions!

As for the ERROR state, I believe you need to now think about the user experience, whether it’s your own or for a product owner. If the water sensor has failed, ideally the user is made aware of this, either visually (flashing LED with color or blinking codes or a small OLED) or digitally via SMS, email, etc.

Hardware faults, whether temporary (a reset fixes the problem) or permanent (true hardware failure) is one of THE sources of concerns in commercial and industrial systems. Other failure modes include intermittent or unreliable values. All this to say that you need to think about how a sensor/device can fail, what the likelihood of that failure is (MTBF), how you could recover from the failure (power off/power on, reset, etc) and what is feasible for your product. Then, design your hardware and software accordingly. Your board already has some great resiliency protection for the Electron.

In the case of the soil moisture sensor, besides rebooting, your only other option for recovery may be powering the sensor off then on using a MOSFET or other power control device. If that doesn’t work, then put the system in a safe mode (turn off the water) and enunciate the error to the user, perhaps on a daily interval, until the unit is attended to.

I doubt MTBF is available for that moisture sensor so you will need to assume. In the end, if you design the product to be user serviceable then you could offer replacement parts ($$). Or offer a whole-unit swap (again $$). In either case, the user needs to know of the failure.


chip, i’m guessing if there was a error state you would want to know so if you had a method for tabulating errors, and decide after a set number of errors there should be a notice sent, like after 5 reset sequences, then the owner of the system would know something was amiss. my concern was that there was no notification process in place for multiple resets.


By formatting, I meant a method of laying out your code into a structure. As you said most people are already doing this in some fashion without knowing it.

I was getting the impression from his post that he was a bit confused / frustrated on what exactly to do so that it was correctly laid out.

It’s good to hear that he finds it beneficial and worth the time invested. We are programming mini computers here so I guess we shouldn’t expect everything to be simple and easy to understand the first time around.

I’m learning by following along and it’s interesting.


@RWB, @chipmc, you may want to read through this five part series on FSMs. I haven’t had time to look at their state chart drawing tool (Yakindu) yet. :wink:

To FSM or not to FSM (Finite State Machines discussion)
Delay in sensing temperature locks up Photon


Thank you for the link. I like the way that this tool links the state diagram to code-generation. I will see if I can get a copy and give it a try.




The overall concept of FSM makes sense to me but I can also say that I can relate to this guys comment at the bottom of that article :slight_smile:


excellent observations!

Couple more:
4) when transitioning from state X to state Y you can publish an event or log a message, so you know exactly when (and perhaps why) a transition is triggered.

  1. if you use an FSM library, like this one ported from Arduino, you have access to state enter and exit functions that can be useful to set things up while entering/leaving a state. It also tells you how much time the FSM has been in that state,

  2. when you start coding with FSMs in mind you don’t really know what you are doing but you try it and most probably you’ll stick with it since you’ll like it so much

  3. if your code has a variable called state or status then is very probable that you are using an FSM but you did not know.

  4. the two links I had fun reading and finally got me into using FSMs:

this one:

and this one:

I’d say try one once and see, you won’t regret :wink:

To FSM or not to FSM (Finite State Machines discussion)

@gusgonnet, great comments and links! I’m a big proponent of FSM’s especially when working with FPGA design. Maybe it’s worth starting a new topic with just this FSM stuff.

To FSM or not to FSM (Finite State Machines discussion)

good idea, done!



I have finished documenting this carrier board and publishing it on HAckster.io. You can see it here: https://www.hackster.io/chipmc/particle-electron-carrier-for-outdoor-iot-applications-40ed52

Hope this is helpful.



Traffic data for the parks seems like a great idea and very useful to them.

How did you approach them about doing this? What has their feedback been about this new data resource?


Hi @chipmc,
I’m going to get a board or two, is there a resource you know of that will make and populate these?
I’m not sure I’m up to the task of the SMT assembly



Great news. I can help you with the assembly or get a friend of mine to do it. Because I am doing these one at a time, it takes me about an hour to assemble and test a board. Send me a DM and we can see if we can agree to a fair deal.




@peekay123 and @Suprazz, do you happen to have any sample code you wouldn’t mind sharing with me for SPIFFS beyond what’s in https://github.com/Suprazz/downloadFile?

I have Micron SPI NAND flash which says its interface is the same as for SPI NOR; maybe that’s already the answer to my problem described below but I am hopeful that I can use SPIFFS or another Particle-ported SPI Flash library. Do you think I stand a chance at getting SPIFFS (or anything) to work on SPI NAND with my Electron? I really like the idea of using embedded FRAM, flash, EEPROM for mechanical resilience as you’ve pointed out before, @peekay123, but need something in the 100+ MB range.

Following this thread and your response to my post a few weeks ago here, I have tried heading down that route but can’t yet get anything other than “Flash init error”. I set my chip select pin in the application.ino using if (flash.begin(D2)) as I’m not using the default CS; all other SPI defaults remain (SCK => A3, MISO => A4, MOSI => A5 for my Electron).

Thanks in advance for any pointers you’re able to offer!


@supscientist, there are key differences between NAND and NOR flash devices. SPIFFS clearly states that it is designed for NOR type flash. However, you can test with the Micron device to see if it works. What device are you proposing to test (part number). Did you modify the Adafruit_TinyFlash.h file with the correct size and IDs? The “flash init” error is specifically related to the Adafruit_TinyFlash code so you need to focus there.


Thanks so much for your help, @peekay123. Just went down the rabbit hole of trying to update particle-cli at its suggestion and lost an hour trying to troubleshoot that, but we’re back! Though it appears I have to compile in the cloud twice using Particle Dev in order to get a new .bin file… I may post about that elsewhere shortly.

Yes, I have seen that SPIFFS is meant for NOR so this might not be a wise approach on my part I’m just really hoping I can find some sort of truly embedded large storage (~1 Gb or bigger) solution.

The part is a Micron MT29F1G01ABAFDSF and I have set Adafruit_TinyFlash.h defines to

#ifndef CHIP_BYTES
    #define CHIP_BYTES       64L * 2176L // 64 pages * 2176 bytes
#ifndef MAN_ID
#define MAN_ID 0x2C
#ifndef DEV_ID
#define DEV_ID 0x14 
#define PAGE_SIZE 2176
#define CMD_ID           0x9F

following the datasheet

I can now get through that flash.begin(D2) call so, at the very least, I’m reading the MAN_ID and DEV_ID. I’m now getting to errno -10010 in test_spiffs() which I see is a SPIFFS_ERR_BAD_DESCRIPTOR. Can’t get past that but I’m trying to play with the CMD_* options in Adafruit_TinyFlash.h. I’m beginning to more deeply appreciate some of the NOR vs. NAND flash differences now as well; maybe I should switch to NOR… Anyway, thanks again, @peekay123!


You should read the SPIFFS docs. The author clearly states the library is not designed for large storage (ie > 128MB) since it is designed for small, resource constrained systems. Besides, performance is greatly affected by the storage size.
For storage that large, you will need to consider a microSD but with a robust locking socket.


Yes, I know, maybe I shouldn’t have used the word “large” which is relative and perhaps meaningless in this context. I have read them. 1 Gb = 128 MB so I thought I’d be fine but maybe the NAND vs. NOR differences will get me here. Micron also sells a 1 Gb serial NOR chip which has a command set closer to what I see in SPIFFS so I’ll test that next just hoped I could kludge it together with NAND & SPIFFS.

It’s a shame that with so many great hardware options there isn’t a software option for larger SPI flash yet! Oh well. Thanks for the really quick and insightful responses.