Samstag, 20. August 2016

Further improving powersaving with ESP8266 and LUA / NodeMCU

I already optimized my NodeMCU firmware - LUA code to send data and then go to sleep after less than 10 seconds. That now takes a bit more than 1.2 seconds. That was a great leap forward to run a mbile sensor on a single 14500 LiIon cell with 900mAh for over a month.

The first improvement was done by moving the DeepSleep call from the Close Connection handler within the "http-code" to the On Receive handler. This led to deep sleep at less than 50µA after about 1.2-1.6 seconds.

Going to sleep after reiception of the data has been
acknowledged by the server.

Today I tried to directly go to sleep after calling the send-command with the buffer of my data. This led to no data being sent at all - the sending is done asynchronously and the DeepSleep command just interrupts it before even being started.

The solution is a timer call. Maybe it's possible to shave off a few more ms, but I am sataisfied with the result so far.

Directly after the send-command add:
tmr.alarm(0,150,1,function() node.dsleep(deepsleep_time*1000) end)

So the ESP is going to sleep after 150ms after the send command. It works and successfully delivers the data to the server, so now the wakeup time is down to roundabout 0.6s. This means nearly doubling the runtime on a battery cell! (Another ~100ms are saved by using a ESP-01 with black PCB instead of ESP-12E, by the way.)

When calling deepsleep with a short timer after the send
command, the wakeup time becomes significantly shorter.

Samstag, 6. August 2016

Different response times with different ESP modules

While optimizing the ESP-based temperature and humidity sensors for my home I stumbled upon a weird issue: The different modules show different times to connect to Wifi and send the data. This was a real issue with tha battery driven sensor as there the data was always sent after roundabout 4 seconds. Looking with a 1R and the scope at it, it became clear that the connection/wake time is much longer, even more than 10 seconds.

ESP-12F on an adapter PCB.
A bit could be solved in software. Going to deepsleep after reiception has been confirmed (on:receive-handler) brought the wake-time down close to the self-timed values of the board. Using a static IP borught the self-measured time down to 0.3-0.4s, being really awake for about 1.2s. The timing code used on my other modules revealed something:

ESP-01 old version (512kByte flash, blue PCB): 9-61s
ESP-01 new version (1 MByte flash, black PCB): 3,1s
ESP-12E: 2.95-3.05s
ESP-12F: 4.1s

It doesn't matter at which distance the sensors are to the base station. The connection time is quite stable around those values, only the old ESP-01 boards really vary between those values, most of the times at 15s though. The modules use the same firmware and the same code (one variable differs between the sensors which is their name which gets sent).

It is clear that the first versions may have a different µC stepping and/or worse layout than the newer modules. But I would have expected the ESP-12F to outperform all other boards, which clearly isn't the case. Maybe someone knows the reason for this behaviour. Leave a comment if you do!

Samstag, 30. Juli 2016

ESP8266 NodeMCU / LUA - Reprogram with init.lua and deepsleep

Adding a snippet helps re-programming a ESP with
init.lua calling deep sleep without flashing the whole
firmware again..
If you name your main program init.lua on a ESP8266 with NodeMCU firmware and it uses deep sleep, you need to flash the whole firmware again to upload a new program version. But there is a nice workaround. When using Esplorer, you can put small scripts on the buttons called "Snippets". When connecting the USB-to-serial adapter, hitting "Open", you have a short time for pressing this snippet button and the commands will be executed.

This way it's not not necessary to re-flash the whole firmware, but just upload your new version and test on.

Click on the "Snippets" tab, choose the snippet you want to add on the left side, and add these two lines:

You can also rename the button with a text that suits the task.

Sonntag, 17. Juli 2016

Home logging: Power save with ESP based sensors

Until now, the ESP based sensors were running as a tiny web server. This means they're at full power all the time, 80mA average according to the data sheet. With soldering a tiny wire to a pin on the ESP-01-modules it is possible to let the ESP sleep for some time - at less than 100µA usually. This greatly reduces power consumption and even makes battery based wifi sensors possible. The ESP is awake for collecting and sending data for a few seconds and then sleeps a long time.

For using deepsleep, ESP-01 needs a wire from Pin 8 (GPIO16)
to RESET. Magnifier glasses help with this modification.

I had to rewrite my data fetching logic for that. Instead of calling the web servers on the ESP modules, the modules now collect the data, send it to the Raspberry Pi and go to sleep for five minutes - more or less, the timer is quite inaccurate. 300 seconds tend to result in 280s, plus some seconds for connecting to Wifi, reading the sensor and connecting and sending the data to the server. Thus the rrd databases must accept the data more frequently, I had to rebuild them:

 rrdtool create /var/www/rrd/bedroom.rrd -s 280 DS:temp:GAUGE:600:-40:100 DS:hum:GAUGE:600:0:120 RRA:AVERAGE:0.5:1:576 RRA:AVERAGE:0.5:6:672 RRA:AVERAGE:0.5:24:732 RRA:AVERAGE:0.5:144:1460

To receive the data on the RasPi, a python CGI scipt helps:

The LUA script has several optimizations already which help it running faster (creating the send string with a table and table.concat for example) and let the ESP sleep earlier again. One enhancement is to compile the needed modules (Si7021.lua to, delete the .lua afterwards). The main program can be compiled as well and renamed to init.lua for faster startup. A minor glitch in that program keeps the ESP awake unneccessary long - moving the deepsleep call from the on:disconnect handler to the on:receive one helps getting the wake-time down by several seconds.
For mobile ESPs until now the MCP1700 LDO behind a LiIon battery gives the besst performance. Without power LED and a Si7021 the quiescent current during deep sleep is down to ~45µA. A DHT22 worked well over weeks, but the quiescent current is way higher and it is really imprecise and slow.

Montag, 25. April 2016

Switching charger ICs - for higher charging rates

Next to LDO based charging ICs and usual desktop chargers there is a class of LiIon charging ICs that don't burn up energy, but efficiently put them into the LiIon batteries. Since I charge from USB and work with prototype board, there are only very few chips available that I can handle with conventional soldering.


These are CN3761 and EUP8202 which you can find cheap in low quantities on aliexpress. As I wondered how they behave compared to the more popular linear chargers like TP4056, LTC4054 and so on, I built a small board with each and tested their charging curves. Due to the necessary coils and shunt resistors as well as switching transistors, they need significantly more space.

Another advantage over the LDO based chargers is the higher current which these switching ICs can provide.

The charging curve of the CN3761 looks ok and shows that the IC has no problems using higher charging rates. During constant current phase the current drops significantly already, but a switch-over to constant voltage mode is clearly visible. It stops charging at ~1/5C.

This EUP8202 curve starts off at low charging rate. The spikes are from moving USB cables and only affect the CC charging phase.
This charger has some peculiarities: The circuit according to the data sheet isn't stable. I needed to add 47µF at Vcc and at the battery so the current set via shunt resistor is met.
Also a weird thing, but this is documented in the datasheet, is that the charger switches to "near end" at about 450mA charge current (1/3-1/4 of current set via shunt; 25µA on the LED which then is very dim) and then charges all the way up to just about 5mA before completely turning charging process off. This leads to a real full cell at 4.218V (no problem with that), and after disconnecting the voltage won't drop fast as usual. So it is safe to use, it switches off, but cells can be used already when the LED is dimmed.

These switching chargers are interesting as they allow for higher charging currents even in USB mode and don't produce much heat compared to the LDO based charging ICs.