search

opendata-stuttgart / sensors-software

sourcecode for reading sensor data
567 stars 307 forks source link

Request: deep sleep for ESP8266 plus battery sensing for solar operation: #104

Open Adorfer opened 7 years ago

Adorfer commented 7 years ago

To run on solar i got this 25€ solar device with integrated charge controller.

i would like to have

s-l1600

ricki-z commented 7 years ago

ESP8266 deep sleep mode isn't possible. This mode will set all GPIO output pins to high. And this will reactivate the SDS011. So we would replace 50mA for the ESP in normal mode with 100mA for the running SDS011.

TheNitek commented 7 years ago

I wonder where this info comes from. According to most sources the GPIOs will be LOW during deep sleep, but some boards seem to leak power on them anyway (so the right hardware might solve it?). It might even be possible to choose the deep sleep state yourself: http://www.esp8266.com/viewtopic.php?f=23&t=13616&sid=5925605fdbc4e9ee47df70689e282c28&start=4 So there is still hope for a low power sensor 😉

Adorfer commented 7 years ago

for the benefit of solar operation i would put an cmos-inverters to overcome that (even the fact the increased BOM and setup, off course this would have to be a config options

Adorfer commented 7 years ago

PMS7003 is running even on 3.3V, drawing for itself 20-70mA (Peak) So in principle it should be possible to drive it just "enough" GPIOs, but better it would be off course to use the Reset pin off course. grafik

Adorfer commented 7 years ago

I wonder where this info comes from. According to most sources the GPIOs will be LOW during deep sleep, If i look at https://github.com/esp8266/Arduino/issues/2469#issuecomment-244295238 "in deepSleep the GPIOs maintain their state, yet the drive strength is 2uA"

So basically if there is a pullup of 10k, the processor will not hold/pull during sleep state, the impedance of the sensor for the reset/enable would have to be above (aprox) 150k. Which will off course not happen, so we need at least a simple driver.

ricki-z commented 7 years ago

Deep sleep is like a reset, so the software will restart at wakeup. He would have to change large parts of the software. The result will be a complete cycle of reading the config, measurements, reconnecting to wifi and transmitting data. There are many people using the sensor as part of a home automation. These people need a sensor that is always online. So we have two completely different needs. To the GPIO states: There were some tests with deep sleep mode. The result was an esp8266 in deep sleep and a running sds011. This may also be caused by the SoftSerial lib.

ricki-z commented 7 years ago

PMS7003 is operating at 5V. Only TTL levels are 3.3V. Operating on other power levels will lead to false measurements. The fan will run too slow, so a lower air volume as expected will flow through the sensor. Please read the specs.

Adorfer commented 7 years ago

[PMS7003 fan operation at 3.3V]

The fan will run too slow, so a lower air volume as expected will flow through the sensor.

Do you have example measuments of that or you just cite the other forum?

I have great difficulties in understanding why the airflow should affect the sensor value. (off course in changing conditions it will take longer to get to an accurate reading, but since the laser does not "consume" the particle, nor are the particles so few that you really have to stirr 'fast enough' to keep them 'well mixed'. Since the fanspeed is not stabilized and even changes largly between 4.9 to 5.1V on the fan-5V-rail, i very much assume, that the precision of the sensor does not depend upon an exact fan speed.

Adorfer commented 7 years ago

He would have to change large parts of the software.

Not using solar technology becaus "it requires software development": not the kind of argument i would subscribe to. If it's not possible with the current design concept, then we should look how to fork the project, in order not to spoil it for the users who are more in the "climate business" here and don't care about measuring particles outdoors near the street (where it's more likely to have accurate readings for pedestrians and cyclists, not the nice values of "balconies on the 3rd floor")

ricki-z commented 7 years ago

[PMS7003 fan operation at 3.3V] Which other forum? This is part of the sensor spec!!!!!! Read the spec, then write something like this. The Plantower sensors count particles. Lower air flow means lower particle count per time, means to low measurement. Yes, the fan speed is varying. But this is one of the sources for the consistency error of max. -/+ 10 percent. And again, read the specs.

Adorfer commented 7 years ago

I would at least give it a try, in order to compare the readings. I would suggest to mount 2 PMS7003 aside, one with 3.3 and one on the correct 5V rail. Nevertheless, what may be relevant: The sensor needs (at least) 30s of fan operation to come to consistant values, with a consumption of 0.5W. Assuming a 2.5W panel (10x20cm), fixed angle (0,5), partly wrong angled (0,5), switchregulator losses (0,5), 24h-overlap (0,3*). So we are looking at about 0,1W of constant possible output. This should make it possible to fire up the sensor every 20 minutes for one minute on a 24h basis at least in most months of the year.

Cinezaster commented 7 years ago

I found this information about gpio states and deepsleep. Might be of some help. https://www.mjt.me.uk/posts/esp8266-gpio-deep-sleep-and-reset/

Adorfer commented 7 years ago

So we learn that in idle basically all IOs are high impdance over the edge of usability. And some have a pull up of 10k, other one for 5k on the board.

there are (at least) 2 solutions a) get a ic2-io like PCF8574 to set power/reset to the sensor (and do not cut it's 3.3V during ESP sleep) b) put a pull down of e.g. 2k on the IO for the set/reset, so by in sleep the pin is pulled certainly down. and during operation you then could drive it up via the "power" of 6mA.

(and yes, the precise values would be subject of exhaustive testing.)

FeinBit commented 6 years ago

I have put the SDS011 and the DHT22 into a cheap (6 Euros at Pollin) outdoor case with a 3 Watt solar panel on top to keep the used 3,7V/4 Ah (former E-book-) accumulator even during winter time alive. So I am very interested in a somehow

10% ED operation mode ;-)
geoeffnet wand_sommer

ricki-z commented 6 years ago

We won't use the deep sleep mode. There are different problems with that.

Adorfer commented 6 years ago

as we might have now learnd that "deep sleep" is difficult field for this device, i would suggest the following behaviour for "maximum powersave possible without immense intense hardware":

"Solar mode" optional in setup

possible extensions:

  1. use RTC-Ram https://github.com/HarringayMakerSpace/IoT/tree/master/ESPDailyTask as state registier and an I2C port expander like PCF8574 for going to deep sleep while sensor is "warming up" (running fan, getting fresh air), to keep Enable-Pin up while sleeping, would possible reduce battery consumption by 50%.
  2. voltage sensor from adc to the battery-terminals (max 4,2v or 8,4v) via voltage divider. going back to sleep instantly if battery voltage is below safety threshold (2,9v or 5,8V), in order for the sun come up again.
Adorfer commented 6 years ago

Just for further reference, Andreas Spiess has put out a complete set of Youtube videos out, going through practically ALL challenges you have to overcome when going solar:

47 Power Saving with ESP8266 (Sleep Mode) Tutorial with some Tricks

https://www.youtube.com/watch?v=6SdyImetbp8 grafik

58 ESP8266 Sensor runs 17 days on a coin cell/transmits data to sparkfun.com and ubidots.com:

https://www.youtube.com/watch?v=IYuYTfO6iOs grafik

149 ESP32 Deep Sleep, RTC Memory, "Secret" LoLin Pins

https://www.youtube.com/watch?v=r75MrWIVIw4 grafik

142 Solar Power for the ESP8266, Arduino, etc.

https://www.youtube.com/watch?v=WdP4nVQX-j0 grafik

154 Solar Charger for Microcontrollers

https://www.youtube.com/watch?v=dBx-g1dkdDQ grafik

155 The 5 Best Solar ChargerBoards for Arduino and ESP8266

https://www.youtube.com/watch?v=ttyKZnVzic4 grafik

Adorfer commented 6 years ago

The main issue is: During deepsleep all I/O go "high impedance", this then lets the PMS go to full operation.

By effect you trade the powersafe of the ESP (from 120mA to about 1mA) against the PMS going up from 1mA to 100mA....

Untitled86 commented 6 years ago

I’m running my weather station at 20 micro amps (not milliamps) in “sleep” mode. That’s 3x better than the “deepsleep” of the ESP8266 if everything is working perfectly and you have nothing else connected.

I just connected a $1 RTC DS3231 (Amazon), and NPN Transistor, three resistors and RTCLib with a dash of extra code to use the alarm feature.

I’m using the Huzzah Feather, which draws a ton of current even in the ESP’s deepsleep because, bad design. This doesn’t matter though because I’m turning the whole board off via the Enable pin.

Here’s the setup...

1) Replace the 10k pull-up resistor on the huzzah’s Enable pin (R7) with a 240k. Sounds hard, it’s easy.

2) Wire a GPIO to the Collect on the NPN transistor.

3) Connect the Alarm pin to the Base pin of the NPN transistor. Then add a 240k resistor from that pin to VBUS (labeled USB pin on board). ...Resistor nessesary because alarm pin doesn’t source it’s own current.

4) Connect the Emit pin of the NPN transistor to the Enable pin on the Huzzah Feather. Add two 40K resistors (in parallel) to ground (or maybe just use one 20K but this is what I did).

Boom. This also allows the Huzzah Feather to charge my battery via the solar panel while it’s sleeping. I added a diode in-line on my solar panels V+ because it drew current (that’s connected to the pin labeled USB on the Huzzah Feather).

Note: This would have been way more simple except the RTC’s alarm pin goes high when I need it to go low :/ The NPN inverts this for me.

Adorfer commented 6 years ago

i would invite you to create some full documentation (perhaps with a smal drawing and a way how to programm the RTC. I would welcome this.

(Please note that such a modification will probably never proposed in the main tree, since even soldering wires onto existing pads is considered als "disqualification to be acceptable, violating the scope of the project")

adx-git commented 5 years ago

was there some progress during the past 15 month?

FeinBit commented 5 years ago

Sorry to say, not on my side ...

However, if I get the time to pick it up again, I will use a combination of AVR low power and ESP8266 or if possible, only an ESP 32 board. 

Easterly Greetings from chilly Germany :-)

Am 12.04.19 um 12:24 schrieb adx-git:

was there some progress during the past 15 month?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/opendata-stuttgart/sensors-software/issues/104#issuecomment-482523547, or mute the thread https://github.com/notifications/unsubscribe-auth/AdVR9vhlobInAZDNYMxn0RtJB5NNk4AMks5vgF7mgaJpZM4OYjM_.

nospam2000 commented 4 years ago

You might want to have a look at my branch https://github.com/nospam2000/sensors-software/tree/esp32powersave where I'm working on a powersave mode. Currently it is based on ESP8266 and the 'beta' development branch. In the end I want to add a Li-Ion accu and a solar charger to an ESP32.

The current state of the implementation is:

Each measurement cycle runs like this

  1. the SDS011 fan is activated for 15 seconds (warmup phase)
  2. the sensors are read once using the query command
  3. Wifi is activated (for around 10 seconds)
  4. the data is sent
  5. CPU, Wifi and SDS011 is deativated

I assume that the most power is consumed by the SDS011 fan (around 80mA?). Is it possible to reduce the warmup time further, e.g. to 5s or 10s?

Wifi is probably the next factor and it depends on the signal strength.

Currently I don't have appropriate hardware to do measurement, I need to built that.

A rough calculation:

Adorfer commented 4 years ago

when using ESP8266 and deep sleep: How do you keep the fan of the SDS from spinning?

ricki-z commented 4 years ago

The newer SDS011 are implementing the wake up correctly (wake up only on command). So the sleep mode should work now as expected. @nospam2000 normally the warm up time should be 30 seconds. As we don't have the maximum length for the pipe in most cases we don't need the complete time. But you also shouldn't go lower than 15 seconds as the used algorithm 'inside' the SDS011 needs some time to get stable values. And if you send only one value per 15 minutes: what about shorter events, like a heater that is starting?

nospam2000 commented 4 years ago

what about shorter events, like a heater that is starting?

Can you please explain what you mean with "shorter events".

I'm already using the shortest possible on-times. During the warmup phase of the SDS sensor the CPU and Wifi are in deep-sleep mode.

ricki-z commented 4 years ago

With a shorter event I mean some pollution that can be measured only for a shorter time than the 15 minutes of your measurement interval. I.e. a neighbor starting a barbeque. The first minutes the fire may produce more smoke. Or a cold motor that is starting in front of your house. As the motor gets warmer the pollution in decrease.

nospam2000 commented 4 years ago

shorter time than the 15 minutes of your measurement interval

Thanks, now I understood.

TL;DR: a higher sampling frequency only gives nicer looking graphs but doesn't add valuable information for statistics

The Shannon Abtasttheorem says have to choose a sampling interval according to the frequencies you want to measure. Frequency means here how fast/long up-/down-peaks occur.

I.e. a neighbor starting a barbeque. The first minutes the fire may produce more smoke.

When you measure the smoke from a distance of 3m you will see a sharp peak (high frequency). When you measure the same smoke from a distance of 50m you will measure the same event with a much more flat curve (lower frequency) because the smoke is fluxed with much more air before it reaches the sensor, the distance and fluxing acts like a low-pass filter (smoothing).

You will also see other fires in the 50m distance with the same flat curve and there are 50*50/(3*3) = 278 times more fires in the 50m range than in the 3m range so statistically the near fire is irrelevant and you would normally filter that out as a singular measurement error when just looking at the measured values.

This means with a higher sample frequency you only increase the detection of nearby sources. That only makes sense when you also increase the number of sensors, e.g. one sensor every 5m. Actually the meaningful sample frequency depends on the distance between the sensors.

Changing the sampling frequency dynamically depending on the values also gives you problem for statistical calculation.

nospam2000 commented 4 years ago 
* => (1800 mAh * 0.384) /  3 mA = **230 h  = 9 days**

I have now run a test with 4xEneloop 1.2V 1900 mAh NiMh Accus without a voltage converter. With a measurement cycle of 145s it was running for 48h, so it should run for 12 days with a cycle of 900s.

boza2000 commented 4 years ago

The newer SDS011 are implementing the wake up correctly (wake up only on command). So the sleep mode should work now as expected.

Hello, Can you please share how to recognize New from Old SDS011 sensors ? From which firmware version we have wake up working correctly (wake up only on command) ?

ricki-z commented 4 years ago

Our firmware is sending the start command anyway. So we don't need to recognize the SDS011 version. Only the manufacturer can tell you exactly the SDS011 version and date when the new version started.

matthias-Q commented 4 years ago

Hi, are there any updates on the state of the ESP PowerSave option? I've just built a solar powered version and it uses way to much energy @nospam2000 Is you code working for ESP32 or ESP8266? can you give us an update?

nospam2000 commented 4 years ago

@matthias-Q

I've just built a solar powered version

Cool! What kind of cell are you using?

@nospam2000 Is you code working for ESP32 or ESP8266? can you give us an update?

It is working with ESP8266, I never tried it with ESP32.

matthias-Q commented 4 years ago

20W 12V Solar Panel, LiFePO4 Battery (5000mAh), I just finished it this week and I am still testing it. So far it does not even survive one night :-( I tried to compile your fork (branch feinstaub-sensor-esp32powersave) with no success. Looks like some issues with EspSoftwareSerial. The version that is required is not available in platformio - newer versions won't work...

nospam2000 commented 4 years ago

I fixed the 2 build errors in https://github.com/nospam2000/sensors-software/tree/esp32powersave. You probably need to use Visual Studio Code + PlatformIO to compile it, because there the dependency resolution of libraries is much more controllable than in the Arduino IDE.

matthias-Q commented 4 years ago

Thanks, It builts now. Do I have to connect a pin to RST to ensure the reset? Never worked with the ESP8266 deep sleep before (only ESP32).

nospam2000 commented 4 years ago

Do I have to connect a pin to RST to ensure the reset?

Yes, you have to connect the RST pin to D0 pin.

See section "1 ESP8266 Deep Sleep with Timer Wake Up" on https://randomnerdtutorials.com/esp8266-deep-sleep-with-arduino-ide/

nospam2000 commented 4 years ago

20W 12V Solar Panel, LiFePO4 Battery (5000mAh)

I was reading a lot of infos about the right battery technology to use for solar power projects. With Li-Ion batteries (I'm not sure about LiFePO4) charging below 0 degrees can become really dangerous. That's why I would prefer NiMh.

I wrote a comment to one of the Andreas Spiess youtube videos about that topic with some links, but I don't find it at the moment.

matthias-Q commented 4 years ago

Looks like everything is working fine. I'll install it tomorrow on the solar panel, to see how long it will last. So it wakes up every 150s/3min - and is on for approx 30-40s.

I used LiFePo4 because its safer. It can also withstand lower temperatures. This link has been posted here before, but I followed pretty much the same approach: https://community.hiveeyes.org/t/versuchsaufbau-autonome-zelle-solar-feinstaub-wetter-vergleichsding/1373 (in Germany) The Charger used there includes an option for a heating pad and a thermistor. For now, I don't use both...

Thanks for you help. I'll keep an eye out if something fundamental changes on the main firmware (i.e. api connections),

nospam2000 commented 4 years ago

Thanks for you help. I'll keep an eye out if something fundamental changes on the main firmware (i.e. api connections),

I've now merged the main branch to my branch and it compiles, but there were so many changes and merge conflicts that it needs to tested from the ground up.