I have an application that will be battery-powered and needs very low power consumption. It only pings the cloud once a day to send data to save power. The device however does need to wake up frequently (between once every 10 seconds up to 10 times per second) based on an external interrupt.
It looks like the Particle board will not work for our situation:
It says "Particle Device OS is not intended to handle very short sleep cycles. Practically speaking, the minimum is about 10 seconds."
Is there no way to sleep quickly in between pulses? Is there too much overhead in the OS?
I just wanted to make sure I'm not missing anything.
There is no way to sleep for a period of less than 1 second. If you are not connecting to cellular, you may be able to sleep for a few seconds instead of greater than 10 seconds, but it will still be unpredictable.
If you are relying on counting interrupts, such as with a rain gauge, you're better off using a small MCU as the counter and waking the Particle device less frequently.
I am using a Particle Boron connected to a rain gauge sensor and getting very good results.
In my setup, I have a Boron, a 2000mAH battery, a 1.9W solar panel and it connects every hour to report without any issues. It could easily last a month on battery as I found out when some pinhead stole the solar panel.
The rain gauge I use is a tipping bucket sensor that collects rain in a little bucket that represents 0.1" of rainfall per tip. This type of sensor can be quite accurate (if you keep it clean) and the tipping bucket prevents rapid interrupts.
@rickkas7 is right about more rapid interrupts and I use the approach he suggested for these applications with microcontroller on the sensor board. Particle's new Asset OTA capability makes this approach even more attractive.
Happy to share more details if you are interested.
Looking back at the thread, not sure why I thought you had a rain gauge. I am working on a magnetometer project as well and can understand how complex that logic can be. Good luck with your project!
Hi, It has been a while. I'm glad there is still discussion about power from solar. I've been powering electrons & variants for several years by small solar panel for water monitoring but now have to move to the Boron. I'm hoping I can use most of my electron programming for the Boron but I'm not sure. Can I get more detail on your setup, so I can steal your ideas and benefit from your experience. thanks, john
Sure, happy to share and I would appreciate any feedback you might have on how I could do better. I am working on a major re-write of this codebase but it is not as mature as this one. This code simply counts events from a hardware interrupt and reports every hour. It also goes to great lengths to connect and to keep from getting locked up which is why it is a little long. In my current rewrite, I am breaking this big monolithic main file into smaller classes that are more discrete and, hopefully, more maintainable.
I also developed the carrier board for this device here on the forum. If you need any help on the hardware front, please take a look at this thread or feel free to ask questions:
Again, I appreciate any advice / comments / suggestions your might have. When my new modular codebase is ready for prime time, I will share it here as well.
Read through the thread about carrier board development. Looks like a nice unit with great features. I was on the verge of developing a Boron carrier board with many of the same features to replace the Electrons I've been using for remote water monitoring. But given that I'd be facing a steep learning curve on board development and production, I was wondering if you have any for sale. I'd be willing to do some testing using solar charging under harsh winter conditions with poor cell coverage in northern Minnesota and give you feed back if you have a couple you could sell me. let me know. Thanks, john
Sure, I have some on-hand and am preparing another production run. Send me a DM and we can connect. I sell these at my cost in the hopes of getting just the feedback you mentioned.