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.