Reverse-Engineering a low-cost USB CO₂ monitor

Details

Contrasted with, f.e. CO, monitoring CO₂ seems to be tricky. Most devices in a reasonable price range will only give you a qualitative output: "good"-"bad"-"worse". And even getting this rather restricted kind of data into a computer for logging (and eventually: actions of the home automation system) leads to device prices at ~120€ and well above.

Recently a friend tipped me off to a device (also on amazon.de) that is almost cheap (80€) and actually gives you a CO₂ readout in ppm! Now all I need is to whack at it to get the data into a computer.

Project Logs

Collapse logs

All your base are belong to us
Henryk Plötz • 05/14/2015 at 15:27 • 11 comments
So now that we have figured out all the puzzle pieces (do we?) we can go over to the last project phase and actually build something that extracts data from the sensor on its own initiative and feeds it into something with a purpose.
Setting: Ubuntu 14.04 LTS, Linux 3.13.0-52-generic, Python 2.7.6. As we recall from one of the earliest logs we can initiate data transmission by issuing a HID SET_REPORT on the USB device. Luckily, Linux offers a very simple API to do just that by way of the hidraw device node we were using at the very beginning. Since we're not interested in any security (which the protocol doesn't offer anyway) we'll just use a static key.
```
with file("/dev/hidraw0","a+b") as co2:
	# Key retrieved from /dev/random, guaranteed to be random ;)
	key = [0xc4, 0xc6, 0xc0, 0x92, 0x40, 0x23, 0xdc, 0x96]
	co2.write( "\x00" + "".join(chr(e) for e in key) )
	while True:
		data = co2.read(8)
		print " ".join("%02X" % e for e in data)
```
If we run that code (after fixing permissions, we'll get to the part later) we get … nothing. Bummer.
Read more »
How are you, gentlemen
Henryk Plötz • 04/26/2015 at 18:40 • 0 comments

Now that I've had my breakthrough I can leisurely stroll around the rest of the code for completeness sake. This should show me how and what data is being sent to the device to initiate data reporting.
Read more »
It's you
Henryk Plötz • 04/25/2015 at 01:01 • 0 comments
Loading a new file into IDA for the second time was easier. Again, I had to prepare it with
```
upx -d HIDApi.dll
```
and this time all functions were already nicely labeled for me. And again I spent a lot of time being stupid, starting here:
Read more »
Main screen turn on
Henryk Plötz • 04/25/2015 at 00:00 • 0 comments

So, looking at the transmitted data wasn't that successful in figuring out the protocol. My normal approach now would be to 'spoof' the other side of the communication channel and see how the device under test changes behaviour. In this case I would've written a short piece of Python to send out this initial SET_REPORT packet and then vary contents and look at how the device responds differently. But that's some boring work I've done several times before with other devices, so I'd wanted to try something new and this would be the perfect chance. I've never reverse-engineered anything by looking at a disassembly, so let's dive in!
Read more »
What
Henryk Plötz • 04/24/2015 at 22:13 • 0 comments

In past projects I've had raging successes by just looking at the raw data, XORing stuff together, and maybe squinting my eyes a little. Spoiler: Not so this time. I'll walk you through the steps anyway.
Read more »
Somebody set up us the bomb
Henryk Plötz • 04/17/2015 at 02:05 • 1 comment

Luckily reverse engineering funky binary protocols is one of my specialities, so, let's see …
Data seems to arrive in 8-byte packets always. Indeed, this appears to be a property of what they did with the HID spec (more on that in a moment). The timing between 8-byte packets is irregular. In each packet there seem to be two groups of 4 byte each. The second byte of each group is always the same.
Getting more data by re-starting the Windows software makes things more confusing: The second byte of each group is still constant, but different now. It's numerically close though, so, time-based? This sucks.
Read more »

We get signal

Henryk Plötz • 04/17/2015 at 01:27 • 0 comments

Indeed, immediately after running the Windows software in a VM with the device connected I was getting a live data log of the CO₂ concentration! This screenshot shows me breathing into the vicinity of the sensor:

Ok, time to disconnect the device from the virtual machine and look at the data on my Linux box. Since it's enumerated as a HID, there's /dev/hidrawX device node that would receive the raw data sent by the device.

# hd < /dev/hidraw0
00000000  be 9b 28 69 d0 a5 34 ba  cb 9b 90 68 4c a5 34 aa  |..(i..4....hL.4.|
00000010  5f 9b 8e 68 de a5 34 c2  f3 9b b0 68 5c a5 34 82  |_..h..4....h\.4.|
00000020  f2 9b b8 69 5c a5 34 8a  e2 9b c1 69 55 a5 34 3a  |...i\.4....iU.4:|
00000030  52 9b c9 69 75 a5 34 d2  aa 9b 30 69 27 a5 34 42  |R..iu.4...0i'.4B|
00000040  38 9b 20 69 89 a5 34 6a  8e 9b 28 69 d0 a5 34 ca  |8. i..4j..(i..4.|
00000050  cb 9b 90 68 4c a5 34 aa  57 9b 8e 68 de a5 34 ba  |...hL.4.W..h..4.|
00000060  fb 9b b0 68 5c a5 34 8a  fa 9b b8 69 5c a5 34 92  |...h\.4....i\.4.|
00000070  35 9b 81 69 5d a5 34 52  d5 9b a9 69 72 a5 34 72  |5..i].4R...ir.4r|
00000080  aa 9b 30 69 27 a5 34 42  00 9b 20 69 89 a5 34 72  |..0i'.4B.. i..4r|
00000090  8e 9b 28 69 d0 a5 34 ca  c3 9b 90 68 4c a5 34 a2  |..(i..4....hL.4.|
000000a0  57 9b 8e 68 de a5 34 ba  fb 9b b0 68 5c a5 34 8a  |W..h..4....h\.4.|
000000b0  fa 9b b8 69 5c a5 34 92  12 9b c1 69 54 a5 34 2a  |...i\.4....iT.4*|

Yeah \o/, there's data! Bummer, it's doesn't look at all like the protocol I was promised. But there does seem to be a structure to it, so there's hope, I guess.

War was beginning
Henryk Plötz • 04/17/2015 at 01:11 • 0 comments

First thing I noticed after unpacking: While the included manual only talks about the USB connection in terms of providing power, the thing actually enumerates on the bus as a HID with vendor/product ID 04d9:a052.
When researching this VID/PID combination, I found that the device appears to be sold in other markets, with different brand markings: http://habrahabr.ru/company/masterkit/blog/248403/. I don't speak any Russian, and Google Translate is rather weak here, but from the pictures it seems that someone was using an identically looking device to monitor some brewing process. And that there's software that reads the data from USB.
Doing a Google image search for co2 meters and selecting a product photo that matches the physical appearance (with yet another different branding) lead me to this American company which had not only the Windows software to connect to the meter for download, but also a PDF documenting the protocol. Well, this should be a breeze …

View all 8 project logs

Discussions

ian.kirker wrote 03/02/2020 at 16:03

Thank you for putting this together!

I've just been porting the code to Golang, and I was wondering: did you ever figure out what any of the other data types might be? Or whether they're anything relevant at all? I figured they might be either voltage/electrical data or air pressure, but if so, none of them seem to correspond directly to any obvious unit and I don't have enough data to trendline with other sources yet.

Are you sure? yes | no

heine wrote 01/08/2017 at 20:21

I created a small python class to use this sensor. It's Python2 and 3 compatible. The idea is to keep it simple and use it together with other sensors.

You can find it at https://github.com/heinemml/CO2Meter

Are you sure? yes | no

Yann Büchau wrote 08/04/2016 at 15:29

I am working on a project for convenient plug'n'play co2 data logging and visualization:

https://github.com/nobodyinperson/co2monitor

It includes a python module to communicate with the device based on your amazing code.

The device is detected automatically by udev and a logging service is then started (systemd integration present but not mandatory).

There are easy-to-install debian packages available.

Thank you very much for your work on reverse-engineering the protocol!!

Are you sure? yes | no

Victor Shmoylov wrote 04/20/2016 at 18:33

Thanks for your work and your project!
It helped me not to give up when I was trying to figure out how this device works.
As a result, I've developed a C language library (also reverse-engineered how they generate encoding key): https://github.com/vshmoylov/libholtekco2

Are you sure? yes | no

martin wrote 11/06/2015 at 09:36

Impressive Work! I created a Nodejs Plugin for the CO2 Monitor based on your project.
https://github.com/maddindeiss/co2monitor

Are you sure? yes | no

dimka.rs wrote 05/03/2015 at 12:15

Impressive work done!
I have the same sensor and I am using this software to log it under linux:

https://github.com/dmage/co2mon

Are you sure? yes | no

zakqwy wrote 04/19/2015 at 03:52

Cool project! How does the sensor work? What sort of CO2 detection tech can they cram into an 80€ product?

Are you sure? yes | no

Henryk Plötz wrote 04/25/2015 at 01:06

According to the data sheet it's NDIR: Non-dispersive infrared: https://en.wikipedia.org/wiki/Nondispersive_infrared_sensor

The Russian post I linked to in my first project log seems to discuss this further and has close-up photos of the sensor.

Are you sure? yes | no

Reverse-Engineering a low-cost USB CO₂ monitor

Details

Project Logs

Collapse logs

All your base are belong to us

How are you, gentlemen

It's you

Main screen turn on

What

Somebody set up us the bomb

We get signal

War was beginning

Discussions

Similar Projects

Early Diagnosis of Life Threatening Diseases

Lowpower Serial Data Logger 1 Megabit

PINTUS

usb oscilloscope data logging

Reverse-Engineering a low-cost USB CO₂ monitor

Become a Hackaday.io member

Just one more thing

Details

Project Logs Collapse logs

Enjoy this project?

Discussions

Become a Hackaday.io Member

Similar Projects

Does this project spark your interest?

Report project as inappropriate

Send message

Remove Member

Project Logs

Collapse logs