Forfatter Mads Chr. Olesen

15 dec

0 Comments

Quick and dirty Lithium battery-powered Wemos D1 Mini

Af

The Wemos D1 Mini is an ESP8266 based prototyping board with WiFi connectivity and countless applications. It becomes even more useful in battery-powered applications, where with the proper setup, it can run low-powered for months at a time — or only hours if done incorrectly.

This is the quick and dirty guide to running a Wemos D1 Mini powered by Lithium-Ion batteries: We will be blatantly ignoring several design specifications, so double check everything before using in a critical project. Several things will vary, and since there is plenty of clones of the board some boards will work better than others.

Warning: Lithium-Ion batteries always command healthy respect, due to the energy they store! Do not use bad cells, and do not leave batteries unattended in places where a fire can develop, especially while charging. That being said, the setup given here should be as safe as most other Lithium-Ion battery projects.

Why run off a battery?

You chose a Wemos D1 because you want to do some WiFi connectivity. This narrows down the useful modes from the overwhelming large table of possibilities. The approach will be slightly different depending on why you want to run off a battery. There are 3 main usecases:

  • Periodically wake up on a timer, do some work, connect to WiFi, and go back to sleep. Here we can utilize the deep sleep mode of the ESP8266, and get lifetimes in months.
  • Wake up based on an external pin trigger, do some work, connect to WiFi, and go back to sleep. Here we can also utilize deep sleep, and get lifetimes in weeks/months.
  • React with low latency to an external pin, do some work, and go to sleep while still connected to WiFi. Here we can utilize light sleep, but only get lifetimes in hours/days.

Hardware setup

The hardware needed is:

  • Wemos D1 Mini
  • TP4056 module with “discharge protection”, most modules with more than one chip has this, but be careful!
  • Lithium-Ion battery, e.g. a 18650 cell, and probably a holder for the battery

What you don’t want is anything resembling a power bank or battery shield with a regulated output (5V or 3V). These are practically useless, simply a more expensive battery holder! Two reasons: poorly built (I have several where standby is prevented by pulling 100 mA through a resistor!), and you don’t want a switching mode power supply. The keyword here is “quiescent current”: an SMPS can easily consume 5-10 mA continuously, which could very likely be the majority of the current draw.

Wiring diagram.

Waking on a timer – deep sleep

Full code example for deep sleeping on a timer.

To start deep sleep for a specified period of time:

//Sleep for some time; when waking everything will be reset and setup() will run again
ESP.deepSleep(30 * MICROSECONDS_PER_SEC);

Note that you can’t safely sleep for more than approximately 3 hours. Power usage is approx 0.3–0.4mA when deep sleeping.

Keep in mind that after waking from the timer the chip will be reset, meaning no state is available, and WiFi will have to reconnect. Reconnecting to WiFi can be anything from 3–10 seconds or even longer, meaning that will be a delay before the program can resume.

Waking on an pin trigger (reset)

Full code example for deep sleeping waiting for a pin trigger.

The code is exactly the same as waking on a timer, with one exception:

//Sleep until RESET pin is triggered
ESP.deepSleep(0);

The chip will be effectively Cinderella’ed, sleeping until a RESET is triggered. Same caveats apply: waking up the program is restarted, and reconnecting to WiFi will be a delay.

Stay connected – low latency

Full code example for light sleeping connected to WiFi waiting for a pin trigger. Note that the button should be connected to D3 for this example, not RST.

The key parts are:

void setup() {
  ...
  WiFi.setSleepMode(WIFI_LIGHT_SLEEP, 3);  // Automatic Light Sleep
}

void loop() {
  ...
  delay(350); // Any value between 100--500 will work, higher value more power savings
    // but also slower wakeup!
}

Simply delaying will bring power savings — simple and easy!

When awake power consumption is around 75mA. Average power consumption when light sleeping with delay(200) is around 45 mA, with delay(350) and larger is around 30–40mA.

Measuring battery depletion

The ESP can measure it’s internal VCC supply voltage, and because the battery will start dropping below the rated 3.3V before it is depleted, this allows to get an warning when the battery starts to deplete.

ADC_MODE(ADC_VCC);

void loop() {
  if (ESP.getVcc() < 2800) {
    //Do something to warn of low battery
  }
}

In my experience the Vcc reading will drop below 2800 when the battery starts to be depleted.

ADC readings vs. battery voltage

Note that measuring the VCC while connected with USB is not possible, as the USB connection will pull up the battery and the 5V rail to 5V!

Calculating battery life

Here is a quick calculator for how long your Wemos D1 Mini can stay powered




Deep sleep


(conservatively assumes base load 1mA, 10 secs burst of 100mA for every wakeup), resulting in

-

Light sleep


-

Of course the consumption can be brought even lower: some chips are unused but partly connected and will have some leakage (LEDs, USB chip on the Wemos). Making it even leaner is outside the scope of quick and dirty.

Gemt under: Extern, HAL9k

04 okt

0 Comments

Olimex A20-OLinuXino-LIME2 – 8 years in service, 2 PSUs and 1 SD-card down

Af

4 years ago I posted a 4 year review of the Olimex LIME2. It seems that the lifetime of power supplies is approximately 4 years as now another power supply died, and this time also the SD-card was expiring. The LIME2 lives on however!

It was a bit hard to notice, because the battery pack of the LIME2 kept it running pretty well even with the poor power supply. So, better monitoring of the battery pack is also on the todo list.

Recovering the bad SD-card

Recovering the SD-card was relatively easy with minimal dataloss, when out of the LIME2:

$ sudo ddrescue /dev/mmcblk0 backup.img
# Put in a new SD-card
$ sudo dd if=backup.img of=/dev/mmcblk0 bs=16M

I have done this a couple of times with other SD-cards from Raspberry PIs, and though there is the potential for dataloss it is usually minimal. This time a few blocks were lost.

Upgrading Debian from Stretch to Bullseye

I took the opportunity to upgrade the Debian install while the system was offline anyway. Upgrading was generally painless, following the usual Debian method. I went through the Buster release just to be sure:

$ vim /etc/apt/sources.list
# replace all "stretch" with "buster" :%s/stretch/buster
$ apt update && apt upgrade && apt full-upgrade
$ reboot

$ vim /etc/apt/sources.list
# replace all "buster" with "bullseye" :%s/buster/bullseye
$ apt update && apt upgrade && apt full-upgrade
$ reboot

The only tricky part is booting the new kernel. Since that always fails for me on the first try, I always hookup the serial console. For future reference, this is how to hookup the serial console:

Pinout from left as labelled on the LIME2: TX, RX, GND

Now, of course the boot failed. I tried getting the flash-kernel package to work for my setup, but for historical reasons I have a separate boot partition. In the end I derived a simple bootscript from that package, that boots from p1 but loads the kernel, fdt and initrd from p2:

setenv bootargs  ${bootargs} console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait panic=10

#setenv fk_kvers '4.19.0-21-armmp-lpae'
setenv fk_kvers '5.10.0-18-armmp-lpae'
setenv fdtpath dtb-${fk_kvers}

load mmc 0:2 ${kernel_addr_r} /boot/vmlinuz-${fk_kvers}
load mmc 0:2 ${fdt_addr_r} /boot/${fdtpath}
load mmc 0:2 ${ramdisk_addr_r} /boot/initrd.img-${fk_kvers}
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

The script can be manually input over the serial terminal, and thereby tested out.

The only downside is it needs to be manually updated after each kernel upgrade. To activate the uboot bootscript:

$ mount /dev/mmcblk0p1 /mnt/
$ cd /mnt
# ensure boot.cmd is as above
$ mkimage -C none -A arm -T script -d boot.cmd boot.scr

Monitoring the LIME2 battery pack

After upgrading to a recent 5.X mainline Linux kernel the battery pack is exposed in the sysfs filesystem:

$ cat /sys/class/power_supply/axp20x-battery/voltage_now 
4070000 # 4.07 V
$ cat /sys/class/power_supply/axp20x-ac/voltage_now 
4933000 # 4.93 V

I setup a couple of alerting rules for these in my home monitoring setup, so hopefully the next time the LIME2 defeats a power supply I’ll get notified.

Conclusion

I can still warmly recommend the LIME2. It is still available, and even a bit cheaper nowadays at 40 EUR + VAT, and still a little workhorse that just keeps on going.

Gemt under: Extern, HAL9k

Tags: ,

29 aug

3 Comments

Grundfos Alpha 2 pumpe går i stykker og flimrer: reparer den med en kondensator til nogle få kr

Af

Som med så mange andre huse fulgte der en Grundfos Alpha 2 cirkulationspumpe med da vi købte et hus. Den pumpede og pumpede, indtil den var blevet 13 år gammel: så begyndte den at flimre når den skulle starte op. Det er jo som sådan en rimelig hæderlig levetid, men også lidt mistænkeligt at det ikke virkede til at være et mekanisk problem.

Flimmer, men ingen pumpning.

Symptomerne er:

  • Pumpen kan køre fint i længere tid
  • Ved længere tids stop kan den ikke starte; nogen gange starter den efter noget tid
  • Ved opvarmning starter pumpen, f.x. med en varmepistol

Det sidste punkt har gjort at der flere steder bliver spekuleret i at der er “kondens” i pumpen.

Det er dog ikke problemet. Problemet er en lille kondensator der holder strøm til lavspændingselektronikken:

47 uF 16 V kondensatoren er problemet.

I Hal9k eksperimenterede vi en smule for at verificere: hvis man køler den ned med f.x. sprit opstår problemet med det samme. Hvis man varmer den op starter pumpen med det samme.

For en udførlig vejledning i hvordan pumpen skilles ad og kondensatoren skiftes har Simon lavet en video:

Men hvad er kilden til problemet så? Kondensatoren får over tid en alt for stor indre modstand, og spændingstabet bliver for stort. Her et par målinger uden og med lidt sprit til ekstra afkøling:

En helt ny kondensator måler under 1 ohms modstand, altså 100 gange så lille indre modstand:

En ny kondensator kan findes ved at søge på “47 uf 16 v smd electrolytic capacitor”, f.x. TME.eu, eller endnu mere lokalt fra el-supply.dk.

Efter erstatning pumper pumpen lystigt.

Så hvad kan man lære af hele denne historie?
Grundfos laver mekanisk gode pumper, men sparer på deres elektronik. Det er trist at tænke på hvor mange pumper der mon er smidt ud lang tid før tid. Man kan nok ikke beskylde Grundfos for “planned obsolence” efter 13 år, men man kunne dog ønske at produktet fejlede i en mere brugbar konfiguration: f.x. at pumpen kører ved et minimum hvis elektronikken fejler.

Gemt under: Extern, HAL9k

Tags: ,

31 jan

0 Comments

Reparation af Aduro-tronic II

Af

Vi har en Aduro 1-2 brændeovn med Aduro-tronic, som vi generelt er rigtig glade for. Den har nu været i drift i 5 år, og har haft omkring 4500 optændinger. Generelt er designet rigtig fornuftigt, og med Aduro-tronic og Smart Response er det rigtig nemt at fyre korrekt. Den eneste anke må være at vi nu 2 gange har oplevet at Aduro-tronic stemplet har givet op:
Første gang købte jeg et nyt, men det viste sig at være ret nemt at reparere. Så da problemet opstod igen reparerede jeg bare det gamle stempel. Aduro-tronic er basalt set en utæt luftcylinder med en fjeder. Stemplet trykkes ind, fjederen bliver spændt og som luften langsomt trækker ud af cylinderen kører stemplet op igen. Hvor utæt cylinderen er justeres med den lille skrue, og dette sætter således tiden spjældet holdes åbent. Problemet opstår når aske, støv og lignende sætter sig inde i cylinderen, og over tid får foringen til at blive utæt. Derved er stemplet for utæt. Løsningen er simpel:
Tag forsigtigt fjederen af ved at trykke holderpladen ned og dreje den 90 grader.
Den øverste plade kan forsigtig tages ud. Jeg brugte en spidstang, og lidt vrikken fra side til side. Derefter kan selve stemplet med gummi-foring tages ud.
Rengør nu cylinderen, og smør stempel og cylinder med en lille smule silikone-spray der hjælper med at forsegle. Saml hele mekanikken igen, tryk stemplet ned og check at det nu bliver nede af sig selv. Når mekanikken igen er monteret på brændeovnen skal tiden nok indstilles forfra.

Gemt under: Extern, HAL9k

Tags:

25 mar

0 Comments

Sniffing Philips Hue Zigbee traffic with Wireshark

Af

I have a Philips Hue gateway at home that is connected to a number of Philips Hue lights, as well as some IKEA trådfri light bulbs, and a couple of OSRAM Lightify light strips. Most of the time the network works quite well, but some of the time a few of the lights become unreachable. I read a rumor online that the Hue lights and the other lights are actually on two different Zigbee networks. Of course, if only I had a way of sniffing the Zigbee traffic I could diagnose these problems. And thus began this quest.

USB TI CC2531 Zigbee sniffer dongle.

I started by buying a Zigbee sniffer, I found that the Texas Instruments CC2531 chip is widely used, and available in a cheap USB package. I purchased this USB CC2531 Zigbee sniffer, but others are probably equally good. After the dongle arrived I spent quite a while thinking that I need to replace the stock firmware, because of various old projects on GitHub (Sensniff, ccsniffpiper, etc.). Fortunately, you do not need to change the stock firmware. The best software package seems to be KillerBee which supports both sniffing and injection; however only sniffing with the CC2531. Installing KillerBee on Ubuntu is quite easy. You need to install scapy, and a few dependencies. The installation instructions are probably more up to date than this blog post.

Starting the sniffing is really easy, if you know the channel the Philips Hue is operating at. I think channel 11 is the default, but it is displayed in the Hue app, under info for the bridge:

sudo zbwireshark -c 11

This will launch a background process, and an instance of Wireshark that is monitoring the channel. At this point you can see the traffic; but everything is encrypted…

Encryption… Encryption everywhere!

A very incomplete intro to Zigbee encryption

Zigbee traffic can be encrypted with AES-128, which is a symmetric encryption scheme. This means the key to encrypt and decrypt is the same. There is a number of keys that can be used to encrypt a single packet payload:

  1. The Network Key, which is unique to this Zigbee network. This is what we will ultimately need to find. It is generated by the gateway, and shared by all the devices on the network. How does a new device join the network then? It uses the…
  2. The Key-Transport Key which is a pre-shared secret. Apparently there is a number of these, depending on the class of devices and type of network. These are apparently a well-kept secret or something, although widely available on the internet:
    1. “default global trust center link key” which is 5A:69:67:42:65:65:41:6C:6C:69:61:6E:63:65:30:39
    2. “light link master key” which is 9F:55:95:F1:02:57:C8:A4:69:CB:F4:2B:C9:3F:EE:31
    3. “light link commissioning key” which is 81:42:86:86:5D:C1:C8:B2:C8:CB:C5:2E:5D:65:D1:B8

You can add these keys to Wireshark, and the Zigbee dissector will then try to decrypt traffic using them. Go to Edit -> Preferences -> Protocols -> ZigBee and edit the pre-configured keys:

The Key-Transport Key is used whenever a new device joins the network with the sole purpose of encrypting the network key. So, to find the network key we need to know the Key-Transport Key, and observe the traffic when a device joins. So this is what I did: I found an IKEA Trådfri lightbulb and spent the frustrating time needed to get it to join the Philips Hue gateway (resetting the bulb, searching for new lights). Finally, it suceeded!

Hitting gold!

Now, by adding the transport key to the list of keys in Wireshark all the traffic on the network was able to be decrypted!

Decrypted traffic

The next step will be to analyze the traffic, and understand the routing. Very initial probes using zigbee-viewer indicates that there is indeed three distinct routings:

Zigbee routing.

Gemt under: Extern, HAL9k

Tags: