Didier Stevens

Monday 25 July 2022

Quickpost: Standby Power Consumption Of My USB Chargers (120V vs 230V)

Filed under: Hardware,Quickpost — Didier Stevens @ 16:11

I did not explicitly specify in my post “Quickpost: Standby Power Consumption Of My USB Chargers” that I did my tests here in Flanders, Belgium and thus that the mains electricity is 230V 50Hz.

I wondered what the results would be in other parts of the world, like the USA. To answer this question, I redid my tests with the USB chargers powered by an AC power supply that delivers electricity at 120V and 60Hz.

The devices I tested are:

  1. Apple A1357
  2. Apple A2347
  3. Anker A2053

The no-brand USB charger was not tested, as the input specs specify 220V – 240V.

I connected each one to the AC power supply (120V 60Hz) and used a powermeter (GPM 8310, resolution 0,1 µW) to measure the standby power consumption over 24 hours.

This is the result:

Model24 hours (Wh)1 hour (Wh)1 year (Wh)
Apple A13572,04250,0851745,5125
Apple A23470,54730,0228199,7718
Anker A20533,75270,15641369,7360

24 hours is the measured data, the “1 hour” and “1 year” columns are calculated based on the 24 hours data.

And here is the summary for 120V and 230V:

Model1 hour (Wh, 120V 60Hz)1 hour (Wh, 230V 50Hz)
Apple A13570,08510,1202
Apple A23470,02280,0530
Anker A20530,15640,2114

It’s clear that my USB chargers consume less standby power at 120V 60Hz than at 230V 50Hz.

Quickpost info

Tuesday 12 July 2022

Quickpost: Standby Power Consumption Of My USB Chargers

Filed under: Hardware,Quickpost — Didier Stevens @ 0:00

I did some tests with my USB chargers: how much power do they consume when plugged into a power socket without charging any device (standby)?

The devices I tested are:

  1. Apple A1357
  2. Apple A2347
  3. Anker A2053
  4. No-brand: Chacon EMP604USB

I connected each one to a powermeter and let it measure the standby power consumption for 24 hours.

This is the result:

Model24 hours (Wh)1 hour (Wh)1 year (Wh)
Apple A13572,88470,12021052,9155
Apple A23471,27230,0530464,3895
Anker A20535,07340,21141851,7910
No-brand: Chacon EMP604USB5,64730,23532061,2645

24 hours is the measured data, the “1 hour” and “1 year” columns are calculated based on the 24 hours data.

The no-brand USB charger consumes the most: around 2 kWh per year, which is still less than a switched off Philips Hue lamp.

Using the same cost as for the Philips Hue lamp, that no-brand charger costs me around €1 if I would leave it plugged in for a whole year without letting it charge anything.

Quickpost info

Sunday 3 April 2022

Power Consumption Of A Philips Hue lamp In Off State

Filed under: Hardware,technology — Didier Stevens @ 17:25

A Philips Hue lamp is a LED lamp that can be controlled wirelessly. It always draws power for its control circuitry, also when the LED is turned off.

I wondered how much power it consumes in the off state. Doing some research, I found a couple of forums where people asked the same question, and getting answers that is was very little, varying from 0,01 A to 0,02 A.

I got similar results for the current when I measured this:

Figure 1: Switched off Philips Hue drawing 0,0175 A (varying easily with 25%)

But I wanted a more precise answer, and not only the current. I am more interested in the power (Watt) consumption. As our domestic electricity meters measure real power over a period of time.

Thus I measured the power consumption of a 1100 Lumen color Philips Hue lamp that I had switched of via the smartphone app over a period of 10 days.

Figure 2: Test setup

And these are the numbers I got after 10 days:

Figure 3: After 10 days of operation in the off state

0,07756 kWh over a period of 10 days, that’s 0,32316 W. Notice that the display indicates KWh, but that should be kWh (lowercase k for kilo).

Extrapolating to a whole year, that’s 2,831 kWh. Which in my case, correspond to a cost of €1,50 (roughly speaking) per lamp per year.

With online numbers claiming the current to be between 0,01 A and 0,02 A, at first I expected the power consumption to be higher. But the power factor is quite low (around 0,10), explaining a lower power consumption.

Update 2022/09/01: I redid the test for one day (24 hours) using a more precise powermeter (GPM 8310) and measured 8,9188 Wh for 24 hours, or 0,3713 W.

Monday 2 November 2020

Quickpost: Portable Power

Filed under: Hardware,Quickpost — Didier Stevens @ 0:00

I did some tests to generate electricity (230V AC) with a portable 12V battery (well, it’s 10 Kg).

I have a 12V VRLA battery with a capacity of 35,000 mAh. That’s 12V times 35 Ah = 420 Wh. Or equivalent to a 116,667 mAh (420,000 mWh / 3.6 V) USB powerbank.

Charging this 12V battery with a 12V battery charger connected to a 230V power outlet takes almost 7 hours (6:57) and requires 0.49 kWh. That is measured with a plug-in electricity meter with a .00 kWh precision. And I’m working under the assumption that the power requirement of the electricity meter is so small that it can be neglected.

Then I use this fully charged battery to power a 230V 150W halogen lamp via a 12V DC to 230V AC power inverter (modified sine wave).

It runs for 2 hours (2 tests: 2:01 and 2:03) and consumes 0.30 kWh.

Of the 0.49 kWh energy I put into my system, I get 0.30 kWh out of the system. That’s 61%, or a bit better than half of the energy I put into the system.

The main phases where I expect the energy losses are occurring, is in 230V AC to 12V DC conversion and electrical to chemical energy conversion (charging); and chemical to electrical conversion and 12V DC to 230V AC conversion (discharging). I believe the highest energy loss to occur in the power inverter.

And with energy loss, I mean energy that is converted into forms that are not directly useful to me, like heat.

Remark that the halogen lamp test stopped after 2 hours, because the power inverter stopped converting. The battery voltage was 11.5 V then, and I could still draw 1 A at 11.5 V for an hour (I stopped that test after 1 hour).

Next I’m going to try out a 12V to 5V adapter and power some USB devices.

Monday 28 September 2020

Quickpost: USB Passive Load

Filed under: Hardware,Quickpost — Didier Stevens @ 0:00

I just received a USB passive load. It’s basically 2 resistors connected to the USB power wires in parallel, each with a switch in series:

It can draw approximately 1, 2 or 3 amps (depending on switch positions) from a 5 volt USB source.

The resistors can dissipate 10 Watts, and will become very hot.

The resistor for 1 amp (4,7 ohms, tolerance 5%) maxed-out my FLIR One thermal camera (> 150 °C), but I could measure around 220°C (that’s close to 451°F) with another thermal imaging camera.

The second resistor (2 amps: 2,2 ohms, tolerance 5%) maxed-out that other thermal camera too: this one got hotter than 280°C.

I’m referring to 451°F, because presumably, that’s the temperature to ignite paper. Something I’ll have to test out in safe conditions.

I also measured the resistors, and they are well within tolerance:

Here is a short thermal imaging video of the first resistor heating up:

Quickpost info

Sunday 2 August 2020

Videos: Defective USB Cable

Filed under: Hardware,video — Didier Stevens @ 0:00

When I had issues with my portapack, it took me some time to remark that these issues only happened with a particular USB cable.

The SDR would work fine, and then when I would try to record or playback, the screen would turn dark.

You can see this in the following video:

What is happening, is that this particular USB cable is electrically defective: the voltage drop is too large, due to the abnormally high resistance of the cable. The portapack doesn’t receive enough power, and starts to malfunction.

In the following 2 videos, I perform various tests with that defective cable:

Videos on my video blog (with some info on the devices I used):

Wednesday 2 October 2019

Shark Jack Capture File

Filed under: Hardware,Networking — Didier Stevens @ 0:00

I have a new toy: a “Shark Jack“. It’s a small device sold by Hak5 that performs a nmap scan (-sP) when plugged into a network port (that’s the default “payload”).

In this blog post, I’m sharing the network capture of a scan performed in this “test environment”:

The device (small black box, almost square) between the Shark Jack (SJ) and the router is my “Packet Squirrel”: a simple network capture device.

A couple of observations:

  1. The SJ was tested with its original firmware (1.0.0)
  2. The SJ will randomize its MAC address
  3. The SJ performs 2 full DHCP handshakes prior to the nmap scan
  4. The SJ listens on port 53 (tcp and udp) using dnsmasq (observed while scanning)

Example of different MAC addresses after before and after reboot:

root@shark:~# ifconfig
eth0 Link encap:Ethernet HWaddr 2E:AF:43:F2:3E:22
inet addr: Bcast: Mask:


root@shark:~# ifconfig
eth0 Link encap:Ethernet HWaddr 86:72:96:71:C3:3C
inet addr: Bcast: Mask:


And it can get quite hot while charging, as can be observed in this thermal image:

shark_jack_capture.zip (https)
MD5: 9E5C1187D64A6EC7284C06464E791F01
SHA256: 5153F5C7B559BEC1539B0395F97C5852064D7ED9309B837F11A9381EA6ED4C88

Monday 3 December 2018

Quickpost: Developing for ESP32 with the Arduino IDE

Filed under: Hardware,Quickpost,WiFi — Didier Stevens @ 0:00

I have a couple of ESP32’s that can also be programmed with the Arduino IDE, provided the necessary board manager is installed:

After starting the IDE

I open the preferences:

And add the board manager URL for the ESP32 (https://dl.espressif.com/dl/package_esp32_index.json):

And via the Tools menu I launch the Boards Manager:

And install the ESP32 board manager:

And then I can select the right board (ESP32 Dev Module):

Then I can connect my ESP32 board to my Windows machine, and it will complain about missing drivers:

I install the CP210x drivers:

Then I can select the right port in the Tools menu:

And now everything is ready to program my ESP32. I will start with the WiFiScan example:

Which can then be compiled and uploaded to the ESP32 board:

Once it is uploaded and running, I can connect to the ESP32 board via the serial monitor:



Tuesday 19 September 2017

Quickpost: Creating A Simple Flow Graph With GNU Radio Companion

Filed under: Hardware,Quickpost — Didier Stevens @ 0:00

If you installed GNU Radio and want to know how to create the Flow Graph I used to test my SDR, follow along:

Start GNU Radio Companion, and create a new WX GUI file:

You will see 2 blocks, Options and Variable:

Notice that the ID is “top_block” (that’s the default), and that the Generate Options is “WX GUI” (QT GUI is the default).

Variable is a block that defines a variable for the sample rate: samp_rate. By default, it’s 32k (32000), but that’s too small.

For my RTL-SDR, I will use 2 MHz (2000000 Hz). Double click the Variable block, change the value and click OK:

Now we will add a block that represents our SDR as a source of data. Go to the right menu and select “RTL-SDR Source” (you can click the search button on the toolbar to search for this block).

Drag this block into the flow graph:

Notice that the title of this block is in red: that’s to indicate that there is an error with this block (it’s not connected). We will fix that soon.

Next select the “WX GUI Waterfall Sink” block:

Drag this block into the flow graph:

Hover with your mouse over the blue port of block “RTL-SDR Source”, the word “out” will appear:

Click on the blue port:

Now hover with your mouse over the blue port of block “WX GUI Waterfall Sink”, the word “in” will appear:

Click on the blue port:

An arrow connects the 2 ports, and the titles turn black (no errors).

The default frequency of block “RTL-SDR Source” is 100 MHz. I will tune this to a local FM radio station at 100.6 MHz. Double click the “RTL-SDR Source” block, and edit the Ch0 Frequency: 100.6e6 is 100600000 or 100.6 MHz (e6 is the exponent notation for 1000000, 6 zeroes).

We can now save the flow graph. A flow graph has to be saved before it can be executed, if it is not saved, GNU Radio Companion will display a save dialog box when you execute the flow graph.

The extension for flow graph files is .grc:

A .grc file is an XML file:

Now we can execute the flow graph by clicking on the Play button:

When everything works fine, you should see output like this:

The green bands represent the signals of broadcast stations, and in the terminal you can see that a top_block.py program was generated and executed, and that GNU Radio is able to connect to the SDR device and get data.

GNU Radio Companion creates the top_block.py program (the name comes from the ID in the Options block), and executes it with GNU Radio:

If GNU Radio is not able to get data from your SDR device, it will generate null values: the waterfall plot will be uniform blue, and the terminal will report errors:

You can stop the Python program from running by clicking the stop button:

If there are errors in your flow graph, you will not be able to click the play button. Click the error button to get more info:



Quickpost info

Monday 18 September 2017

Quickpost: GNU Radio On Windows

Filed under: Hardware,Quickpost — Didier Stevens @ 20:43

I’ve been using GNU Radio & GNU Radio Companion with the GNU Radio Live SDR Environment, but now I’ve switched to GNU Radio on Windows (I’ve seen posts that it’s stable now).

The installation was easy, I downloaded the GNURadio x64 binaries and proceeded with a default install:

Next, install drivers for my HackRF One and RTL-SDR with Zadig.

Zadig can auto-update:

When I plug in my HackRF One, no driver is installed automatically (Windows 10), I use Zadig to install a WinUSB driver:

The same for my RTL-SDR, although the name of the device is “Bulk-In, Interface (Interface 0)”. A driver was automatically installed after connecting it (RTL2832UUSB), but I need WinUSB here too:

If you don’t see your device listed, make sure that all devices are listed:

Now I can use GNU Radio on my Windows machine. I start GNU Radio Companion, and get a one time warning about xterm missing, that I can ignore:

A quick flow graph connecting my RTL-SDR (tuned to a local FM station) to a waterfall plot shows my SDR is working (the terminal output confirms that too):

If GNU Radio is not receiving I/Q data from your SDR, the waterfall plot will be pure blue, and you will see a message attesting to that in the terminal.


Quickpost info

« Previous PageNext Page »

Blog at WordPress.com.