Hey #electronics folks!
-
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.
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* 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)
-
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
-
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!
-
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!
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!
-
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!
-
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)! -
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:
-
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:
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!
-
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!
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.
-
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.
I'm also considering adding a light sensor (to save power at night, when nobody is looking at the display anyway) and a piezo buzzer (for making cute chirping noises
)!What else could I add? A temperature sensor?
-
undefined rag. Gustavino Bevilacqua ha condiviso questa discussione
