Here's how I'm envisioning the entire device:

The battery will be at the bottom of the back side, with the ESP32 and CO2 sensor above it.

The e-ink screen connects to the center of the front side. Three buttons at the top can be used for interaction, the two at the back are for flashing. USB-C port at the side.

Progress shot for the day! Added cutouts and mounting holes, filled the front, modified trace widths, moved the charging LED to the edge, and fixed the battery polarity ().

While slapping on some labels, I noticed that the device doesn't have a name yet. If I call it "Aranot 4", they will sue me, right?

Placed an order for two testing boards at JLCPCB! Very exciting!

I added a solder jumper that can be cut to disable the LiPo charger, in case people want to power the device from some other source.

And I added through-hole pads for the voltage provided by the battery and for ground, to be able to measure power consumption more easily using a Power Profiler Kit II.

On a whim, I made the PCB yellow! Seemed fitting for a "CO2 Canary", which I guess is the name of the device now!

Now, I'm very curious to see whether the device will work! If not, I get to practice my hardware debugging skills, I guess…

Big thanks go out to everyone who has helped me up until this point! I learned so much working on this project so far!

@kicad is a lovely piece of software, I enjoyed using it a lot. Especially the "Design Rules Checker" gave me some confidence that I'm doing things correctly.

The PCBs should ship in a couple of days, I'll keep you updated!

Less than a week after placing the order, the boards have been manufactured, assembled, shipped, and are now in my hands!!

Happy with the look! For the "standard" assembly process, they add these little rails on the sides, which you can then break off.

This is the first time I've designed my own PCB! Now I'm really excited to see whether they'll work!

#electronics

The ESP shows up as a USB device, and I can flash the firmware on it! That's a good first sign that there's no fundamental problem with it! *relieved*

Good news: The e-ink display refreshes!

Bad news: It doesn't display what I want!

Maybe I just got pins wrong in the code? Gonna check after lunch!

I confirmed that, on my old hardware prototype, the display works with the Rust firmware I developed.

On my PCB, on the other hand, with minimal changes (pin changes), it's just snow.

I remember that I also had that problem when I first wired up the prototype, and the problem was a wrong "busy" pin, I think. So I still think it could be wrong pins? But I gotta investigate more.

@revk @twilliability

I *was* using a wrong "busy" pin! When I changed the pins in the firmware, I looked them up in an old version of the datasheet! Now it refreshes like it should! Also, I can power it using a LiPo! \o/

Next problem: The battery level indicator chip isn't reacting – when I speak to it using I2C, I get no response. I'll try to double-check the data sheet, to see if I wired it up correctly?

I was too curious about whether the CO2 sensor itself would work, and wired it up temporarily.

And it immediately did what it should, which makes me really happy! \o/ It really is a tiny CO2 sensor now!

(Yes, I breathed on it for testing in this photo! :P)

Yep, my mistake: I didn't number the pins of the chip correctly! SDA and SCL are pins 8 + 7, not 5 and 6! Not sure how I got that wrong, but it teaches me to double-check next time!

Luckily, the fuel gauge is the one component that's a bit optional – just nice to have!

Resoldering it on the board seems difficult, as it's so tiny! How would you approach that? I mean, I could try to cut the wrong traces, and solder teeny tiny wires to the chip? #electronics

Glued and soldered everything together. Now it feels like a real device! I'm super happy! Thanks again to everyone who has helped me to get this far!

The CO2 Canary is open hardware, you can find all source files here:

https://github.com/blinry/co2-canary

I'm planning to write detailed instructions on how to order the required parts, so that you can get one yourself!

#electronics

Spotted another hardware bug!

I put three buttons at the top of the device, but they didn't work correctly when I tried to assign software functions today…

Looked closer, and it turned out: Pads 1 and 2 in my footprint are always connected – I should've used pads 3 and 4!

So instead of buttons, I have… three things that click when you press them!

Doing some power consumption measurements (using the Power Profiler Kit 2)!

One CO2 measurement + full e-ink redraw takes ~0.08 mWh of energy. That means that on a 7.4 Wh lipo battery, the device could do ~92k of these refreshes!

Let's say we refresh every minute – that's a battery life of 64 days. Not bad as a first estimate!

I have some ideas for how to improve this:

- Refreshing the e-ink takes a while; maybe I could do partial refreshes, or use the ESP32-C6's low-power core during the refresh?
- If the CO2 level hasn't changed significantly, we don't necessarily need to redraw the screen! The current firmware already does this, and it improves runtime by *a lot*! A measurement without redraw only needs 0.013 mWh (one sixth)!

In the estimation, I've neglected one aspect, though: the energy consumption in deep sleep (while the device does nothing).

On my initial prototype using Feathers, the deep sleep current is ~93 uA.

On my custom PCB, using the same firmware, it's ~653 uA, and I'm not sure why!

It seems related to the e-ink display – if I detach it, I get the lower number!

Does anyone see what's going on? Here's the schematics for the ESP32 + e-ink Feathers of the prototype, and my own:

#electronics

Looking closely at the power consumption in deep sleep when the display attached, there's some irregular pattern going on!

This doesn't happen when the display is detached. So now it's a question of "through which path does power go through the display", I guess!

/cc @oseiler @hennichodernich

Fixing the hardware bugs on my CO2 sensor PCB today.

Turns out the high power consumption during deep sleep was due to the floating EINK_RES pin!

The ESP seems to have internal pullup resistors which it could activate, but it's not clear to me how to do that from Rust. So I'll just add an external pullup.