Help with a wind meter project

Started by drsprite, March 01, 2021, 11:14:42 AM

drsprite

Hi all, I'm setting up a wind anemometer which will send a measurement packet every 2.5 seconds. I plan to power it off of an 18650 3.7-4.2v battery, a tp4056 charger and a 6v solar panel.

Right now I'm using an esp32 (nodemcu variant) and using the ULP co-processor to count the anemometer pulses while the esp sleeps. Then it wakes up, gets the co-processor reading, sends the packet using an RFM95W, then back to sleep. I have the esp32 using deep sleep, no bluetooth, no wifi, CPU is at 10mhz and removed the LEDs. It's working pretty ok unless I have 2 days without sun then the battery dies.

My series of questions:

1. Is Moteino a better choice for this type or project?
2. If I sleep the motino then I can't count pulses, right?
3. So I'd still need something else like an attiny85 to count pulses, right?
4. Or is the Moteino truly power efficient that I don't need an attiny85 and I don't need to sleep it?

Looking for guidance if possible

Felix

Sounds like your anemometer needs permanent power.
You need to sleep everything including sensors and anything that uses power, and only take readings before you transmit. Or find another anemometer that doesn't need permanent power.
Otherwise its not low power and you need a way to power your project permanently.
You could perhaps use the hardware interrupt pin 3 of the Moteino to count pulses in between wakes.

drsprite

It doesn't need power (I don't think). I connect 1 wire to an input pin and the other to ground, and as it spins it goes low. That's how it gets counted. If the Moteino is sleeping, is it still able to count interrupts?

Felix

Yes it wakes and hits the interrupt routine with every pulse. You just need to increment a volatile variable and go right back to sleep.
There is a pulse counting example in this sketch, but this sketch does not sleep.
So in loop() you just go back to sleep after your interrupt is complete. This is of course valid on a Moteino with RFM69. I believe it should last a lot longer than 2 days if properly put to sleep.

drsprite

Since this is a wind meter, that's constantly spinning (unless there's no wind), wouldn't that mean the mote would never sleep if the interrupt is always waking it? Could be bad for battery life?

Uncle Buzz

Not cheap, but maybe something like this counter chip at typically 10nA while counting (if I have read the datasheet correctly) could be a good companion to the moteino for this application.

drsprite

Interesting - I've never used one of these. I've got some reading to do on how to integrate it

Felix

Quote from: drsprite on March 01, 2021, 02:05:00 PM
Since this is a wind meter, that's constantly spinning (unless there's no wind), wouldn't that mean the mote would never sleep if the interrupt is always waking it? Could be bad for battery life?
I don't think so. What is the pulse frequency at the highest wind? Does the wind blow all the time?
The interrupt is very quick, just wakes + increments, then loop puts everything back to sleep.
Ultimately you have to measure. Or just use an external low power counter if the power savings are really worth the expense and extra code.

drsprite

Quote from: Felix on March 01, 2021, 04:00:04 PM
I don't think so. What is the pulse frequency at the highest wind? Does the wind blow all the time?
The interrupt is very quick, just wakes + increments, then loop puts everything back to sleep.
Ultimately you have to measure. Or just use an external low power counter if the power savings are really worth the expense and extra code.

Yeah the wind seems to always be blowing. Right now it counted 46 revolutions in 2.5 seconds (equating to 34mph). That's most certainly a gust... average seems to be somewhere from 10-20 counts within 2.5 seconds. Overnight would be less - maybe 0-5 counts every 2.5 seconds. I don't know how that would be a battery savings if I'm constantly waking the mote up though? I'd rather not an external counter unless it makes sense?

Felix

Ok ... you're waking it for a few microseconds to increase the count. Or just measure the wake to know for sure.
Then you wake it when its time to send the packet, that's a much bigger hit than a simple edge that triggers an interrupt.

Quote from: drsprite on March 01, 2021, 04:45:01 PM
I'd rather not an external counter unless it makes sense?
Yeah me neither, not without a real reason!

drsprite

Ok interesting. Sounds like it's not a big battery hit in this method

drsprite

Hope it's OK to re-start my own old topic, but I'm focusing back on this project after an extended hiatus (life got in the way). I'm playing around with the sleep function, and the ISR to count the pulses. However, I can't seem to reliably wake to send a packet. millis() isn't working while sleeping. So my question now is, how can I determine when 10, 30, 60 seconds has elapsed before transmitting the packet of counted pulses? Do I need an RTC or is there a way built in that I'm overlooking?

Felix

You can use the LowPower library sleep function for fixed periods of time, this uses the WDT timer and you can have a pretty good estimate how long you have slept. Ex:
LowPower.powerDown(SLEEP_30MS, ADC_OFF, BOD_OFF);

Also see the RFM69 ListenModeSleep example, this is useful if you want to sleep for longer periods of time. This uses the radio a module timer/interrupt to generate an interrupt and wake the MCU after a precise millisecond interval.

drsprite

The issue I'm facing is when the anemometer pulses and I wake to count that pulse, I have a separate routine to send the packet. So id like to increment a counter, then every 8 or 30 seconds wake to send the packet. The packet send isn't happening. I think the pulse counter is resetting the wdt? I'm not sure.

Felix

Ok I think you could do the following. You need to generate a hardware interrupt from the external source, through D3 for atmega328 based Moteinos, to wake it up from any kind of sleep. Then in that routine you increment the counter. Then when you wake and check your counter you can decide if you want to send a packet.