Power supply: Sanyo Eneloop really do stick out

I was playing around with creating a PWM for power saving (and getting a stable light output) from a LED chain in the past; see here for an article about that.

TPS61070/MCP1640: Cheap and very efficient StepUp ICs.

When trying different step up ICs I finally ended up with the TPS61070 and MCP1640 which are remarkably similar with their specs and pin configuration. Those turned out to be the most efficient step ups available for hobbyist DIY projects.

They tend to discharge the cells below 1V which is expected according to the data sheets. While this is no problem for a short time on two serial NiMH batteries, a longer time in that range surely degrades the cells. Even if a pair of batteries lasts for around a week with my LED chain now, this led to two of my Duracell brand NiMH cells being damaged by deep discharge. I had to bring them to the recycling facility.

Duracell LSD vs Sanyo Eneloop

I decided that I need new cells. I often read good things about Sanyo Eneloop batteries but as those reports were too excited I didn't believe they're real. Anyhow, they ended in my basket.

I bought 8 peaces for about 16€ at Amazon now.  They came precharged but I charged them all to be really full. And then I plugged the first pair into the battery holder to see how well they fare. Unfortunately I didn't write down when this was, but after more than a week a battery change was due. The cells were down to 0.8V and 0.4V each; still too deep discharged - but the cells charged just fine after that, taking a proper load of more than 2000mAh. With the Duracell batteries, the lower discharged cells only took a few hundred mAh of load until the gave their "fully charged" dV signal. Sometimes a refresh cycle helped, but the broken cells didn't recover their capacity anymore.

Now the second pair of Eneloops runs the LED chain for 10 days already and there's no end in sight yet! This is far longer than anything I reached before. 7 days was the usual time frame for my Duracells. They are Low SelfDischarge (LSD) type cells as well, but what a difference the Eneloop make! The Duracells claim 2400mAh capacity, the Eneloop only 1900, and still, they greatly outperform the Duracells! They also cope way better with deep discharge.

I plan two additions to the LED chain StepUp and PWM circuit to get rid of the deep discharge problem and prolong the runtime even more: Adding a Schmitt Trigger after the oscillator stage for less leakage - and placing a NCP303 1.8V as undervoltage lockout to put less stress on the batteries.

Flashing New Firmware to ESP-01 with Mac OS X

I had serious problems today flashing NodeMCU firmware on my new ESP-01 boards with my Windows XP virtual machine today. As I could communicate with the boards from Mc OS X directly, there is nothing wrong with the boards. But after spending some hours trying different USB-to-serial boards without success, I finally searched for a way to flash the firmware with Mac OS X directly as well.

ESP8266 with DHT22 as wireless
remote sensor. A TD6810 buck
delivers 3.3V from USB.

The solution was quite simple: esptool. Download the zip archive, unpack it, change into that directory and install it systemwide by typing in:

sudo python setup.py install

This will take care of all necessary dependencies like installing pySerial libraries and so on. After the installation finished, you can check whether the tool works correctly. Make sure to tie GPIO0 to GND and restart the board for getting into flash mode:

sudo esptool.py --port /dev/cu.SLAB_USBtoUART --baud 115200 read_mac

(adopt the port to your USB-to-serial interface)

This should return your MAC address:

Connecting...
MAC: 5c:cf:7f:**:**:**

Now you can download for example the latest nodeMCU firmware from the project site and flash it with this commandline:

sudo esptool.py --port /dev/cu.SLAB_USBtoUART --baud 115200 write_flash 0x00000 nodemcu_float_0.9.6-dev_20150704.bin

Adopt the device name to your USB-to-serial - and set the baud rate higher. With 115kbps the process will need nearly a minute:

Connecting...
Erasing flash...
Took 2.04s to erase flash block
Wrote 462848 bytes at 0x00000000 in 45.5 seconds (81.3 kbit/s)...

Now remove the GPIO0 pulldown to GND and work for example with ESPlorer to program a LUA script.

Power supply for ESP based Wifi Sensors

The power supply for example for the DHT22 sensors I'm currently using in my "Home Measurement Project" has a big influence on the accuracy of the readings. The graph was getting a bit "nervous" and unstable.

I removed the huge 1000µF electrolytic capacitors and added a few capacitors to the ESP board and the sensors: 100nF, 10µF, 100µF ceramic capacitors and one to two 100µF tantalum capacitors. This looks way better than before!

With those tantalum capacitors and 0.1+10µF ceramic capacitance the result was looking better when looked upon with the oscilloscope. But you can see bigger 10ms areas where the voltage significantly drops to below 2.9V.

Thus adding 100µF ceramic capacitor was helping a lot, looks way better already! But still the voltage drops to ~3.0V for those 10ms slots which is still not optimal.

The USB-to-serial-boards are nice for programming the ESP boards, but for permanent power supply, something more special is needed. I found a few RT9166A in my LDO drawer. They can deliver up to 500mA - but in the SOT23 case can only stand 0.25W of heat. 1W of heat on the other hand leads to a temperature rise of 250°K. With 500mA at 5V to 3.3V I was calculating with 0.85W of heat ... thus I added fat lines of solder tin so the dissipation would be improved at least. To my surprise, the RT9166A stays really cold!

The result is very satisfying. You ca see the transiants on load changes, but no sustained voltage drops on the plot! Thus it is a good idea to use a proper decoupling with capacitors for the sensors, the ESP board itself and use a proper power source!

Two sensors are running with TD6810 switching regulator and one with MCP1825S LDO. They all run stable and don't need the USB-to-serial-converter anymore.

Home Measurement: Switch to RRDtool

My mobile wifi ESP8266-sensors with DHT22 (and soon even with a barometric sensor ... ) are working very well for seeing what is going on in my flat. But MRTG has been developed for monitoring internet traffic. Thus negative values are not possible to be displayed. There is no easy solution to add that. So I needed to switch to RRDtool to fetch my data and plot the graphs. This needs a bit more thinking as you need to setup databases for each of your sensors and think about how often you want to sample the data, the allowed values, how far are averages stored, and so on.

As I still want to monitor my internet traffic as well, next to the "weather sensors" I need to setup a traffic counter manually as well. My solution looks like this:

First, I generate the databases.

Traffic:

rrdtool create /var/www/rrd/fritzbox.rrd -s 300 DS:in:DERIVE:600:0:6500000 DS:out:DERIVE:600:0:1300000 RRA:AVERAGE:0.5:1:576 RRA:AVERAGE:0.5:6:672 RRA:AVERAGE:0.5:24:732 RRA:AVERAGE:0.5:144:1460

Update 24.01.2023: The traffic is measured in Byte/s. For current internet speeds, GBit/s are no unrealistic values anymore, so at least 128.000.000MByte/s are plausible. Thus, the database needs different borders, as the above limits max out occasionally with a 100MBit/s connection already – it can transfer more than 6,5 MByte/s.

rrdtool create /var/www/rrd/fritzbox.rrd -s 300 DS:in:DERIVE:600:0:400000000 DS:out:DERIVE:600:0:400000000 RRA:AVERAGE:0.5:1:576 RRA:AVERAGE:0.5:6:672 RRA:AVERAGE:0.5:24:732 RRA:AVERAGE:0.5:144:1460

Which means: sample accepted every 5 minutes (300 seconds). The bandwidth is 50MBit down and 10 MBit up, added some Bytes for the theoretical headroom. Derive means that the difference to the last sample value should be stored; with a 0 sample for example after a reboot, traffic gets counted as 0 (instead of giving a huge spike as RRDtool assumes a wrap-around of the counter otherwise). The other values create entries for the daily, weekly, monthly and yearly averages.

For the DHT22 sensors, I create a database for each sensor in place so adding new ones or removing old ones is easy.

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

Now I need to adopt the scripts which read out the sensors to feed the data into their database.
Bash is not quite intuitive, unfortunately. Whitespaces around "=" can take you hours to spot as error! ;)

A few hours later, everything falls into place. This is the script which gathers the data and creates the graphics. For crontab, I needed to add it with a trailing call to "/bin/bash" in the crontab-entry as it was throwing syntax errors when I directly called it.
Source here: http://pastebin.com/hMeCzweT

The graphs are embedded in a very basic HTML webpage for now:

Source here: http://pastebin.com/Vu4m4w7K (more recent version: http://pastebin.com/hPjr4Ryq ).

Now I'm still finetuning all the scripts, graphs and websites. But it is doable, although a bit more complex, to plot the data with RRD instead of MRTG.

Short Charger Review: LiitoKala Lii-500

To save some space and because the old NiMH charger startet behaving strange I decided that its time for new charger. As I know what I'm doing I'm not afraid of a charger that handles LiIon and NiMH. If you don't know or care about the battery chemistry, as worst case a deep discharged LiIon could get charged (and that with a way too high current) and become unstable, so that this cell will become dangerous. Take care to not charge LiIons that are depleated below ~2.5V.

My choice was a LiitoKala Lii-500. It has four slots which can accept even 26650 LiIon batteries, and it supports NiMH batteries as well.

On AliExpress you can find it for even less than 20€, I bought mine here.

The device is quite a bit bigger than a two-cell-charger; still two independent chargers require more space.

The Lii-500 has another nice feature that might come in handy from time to time: It can act as power bank when batteries are inserted and no power is available. A USB plug on the back side offers 5V with up to 1A then. I didn't check it yet, but I think you need at least two inserted cells for that feature to work.

 But more technically speaking, the charger is built solid. The contacts are great and work even with longer protected 18650 cells (70mm+).
For a switching charger, the charging current is very stable. A proper CC-CV charging is applied, the charger completely stops charging when the battery has 4.22V. At lest for 24-48 hours; if you leave batteries longer than that in the charger, they get slowly charged more. After 5 days I had a battery at 4,20V while it should have dropped to 4,15V or less. So take the batteries out the chargers the day after they're full, or better even earlier. By default, the Lii-500 wants to charge with 500mA; it offers 300, 500, 700 and 1000mA as well.
Also a fast or a normal test mode is included. There the battery gets discharged and fully loaded once to measure the capacity of the cell. This take some more hours though. Discharging is done with 250mA when 300 or 500mA are chosen as charge current, and 500mA for higher charging rates. The capacity shown by the charger is very close to that I can measure with my setup.

NiMH batteries get a trickle charge. Charge termination will be triggered by dV detection and seems to work properly and stable for all the tests I did the last few weeks.

It is possible to charge LiIon and NiMH batteries at the same time (in different slots, of course ;) ). The Lii-500 detects the cell type based upon the voltage and decides from there if the NiMH or LiIon charging scheme will be applied. Below 0.6V a cell is not detected. Deeply discharged NiMH cells must be "jump started" otherwise therefore - or just don't abuse your cells this badly!

I'm very satisfied with this charger's performance and can recommend it.