Superp

No worries. Yes, I received your mail & replied. Thanks for your help. On the positive side, we got better firmware! Grüße!

I have upgraded the firmware, power cycled, and ran the sensor in the famous "fresh air chamber" for 8x24 hours, logging the output. The sensor is still stuck somewhere around the 1200PPM mark. So, either it still is not calibrating, or it is, but there is a hardware problem. If anybody has a suggestion, I welcome it, because I see no other option than to return this sensor.

Just kidding, of course. Will test though.

Will test. Looking forward to receiving the beer.

Thanks very much, Michael, for your valuable help. The things is, I have been running this "A" sensor for over three months, and I never saw any sign of it re-calibrating. Not inside, not outside. It just reports values that are unrealistically high. I was pondering using some kind of container to position it outside (in "fresh air") without being subject to turbulence (and rain), to get it to auto-calibrate ("ASC"). And then you came up with the smart idea of using a waste bag. So, I did this: I took a new bin bag, opened it outside, waved it about several times, threw in the sensor on a long cable, sealed the bag shut, took it inside, connected it, and logged its reading for exactly 48 hours. I thought it might be interesting to share the result: The bag is still slightly puffed up, so hardly any air is escaping. The PPM in the bag must be much lower than what the sensor reports. But it is not calibrating, or the calibration does not have the desired effect. For now, I have no more ideas.

Hi Borg, Thanks for your answer. That Sensirion document is very interesting. Implementing an FRC trigger sounds like a really good idea, provided: It would be possible to supply an actual realistic reference value with it (rather than assuming PPM=400). It would also be possible to switch off (and back on) ASC. All this would be part of the API/bindings, not only Brickv. That's what I think. If I can help in any way, let me know (I can buy another CO2 Bricklet 😉) Some thoughts: Are we really, positively, sure ASC is enabled? Because "ASC is an optional feature and is deactivated by default" (Sensirion). Is it enabled at TF once after assembly? Or by the FW after each powerup? I could not find it in the FW. ASC works by assuming that the lowest concentration it measures equals exactly 400PPM (right?). I think it is fairly unlikely that indoor air reaches a CO2 concentration of 400PPM. @Michael_S The Sensirion doc seems to suggest choosing either ASC or FRC, depending on "conditions at the end user". I am wondering if ASC does not kick in because of turbulence. It is a challenge to find air that is both really fresh and not moving much. Air movement does greatly affect the PPM reading, I've noticed.

No, these are 0 (zero) for both Bricklets, and both have been reset. In my experience, even setting these to extreme values does not cause a difference this big. I tried that, repeatedly. The day before the experiment that produced the graph above, both sensors sat outside for eight hours. This did not seem to trigger a re-calibration. The documentation says: So you would expect 8 hours to be enough. Clearly I'm missing something. What is this "continuous measurement mode" ?

Hello, I have two CO2 Bricklet 2.0's: Bricklet A "blue": bought December 2021. I had no prior experience with a CO2 sensor, but I found the PPM on the high side, as mentioned in this topic. So, I bought another one: Bricklet B "green": bought February 2022. It appears to consistently produce a much lower reading. This week I had the time to mount both Bricklets side by side and log their readings. This is the result: Both Bricklets have been reset and disconnected/reconnected multiple times. Both have been mounted outside in "fresh air" for an entire day. This makes no difference. What am I doing wrong? Am I missing a step?

...but things are not that simple. The IBM437 encoding in Ruby (and some other languages) does not include code points 0..31 and 127, which traditionally were control characters like bell and tab. This means you can either: Build your own complete lookup table with 256 code points, duplicating the encoding already available on your system, but adding 0..31 and 127. Not dry. Use the encoding, and miss •, ○, ♫, →, ♥, ⌂ and other useful characters. Use the encoding, with a fallback table for 0..31 and 127. I opted to do 3. Commit here.

Ordered.

Genius. This saves me a lot of work. I completely missed that it is the character set of the IBM PC. In Ruby: 'test ½'.encode('cp437') => "test \xAB" 'test ½'.encode('cp437', :replace => '?') => "test \xAB" 'test ‹'.encode('cp437', :replace => '?') => "test ?" Thanks!

The OLED 128x64 Bricklet 2.0 has an embedded font. Code points 32 through 126 overlap with ASCII. Is there a table (somewhere) mapping UTF to the other codepoints, where there is a match? E.g. "½" => 171 ?

Dear Tinkerforge, can you give us an estimate date for when the HAT Zero Brick will be in stock again?

Unfortunately I have to retract what I wrote above. The Wifi extensions do not maintain a stable connection to the Mango router either. The longest time the connection survived was about 2.5 days; usually a reset is required daily. This is not workable. Unless a magic solution comes up, I will remove the extensions and Master Bricks from the project soon.

I guess you would like to know a bit more about the batteries 🚀 Pictured above is a Jupio Proline NP-F550. The plate accepts anything compatible with Sony NP-Fnnn series. These three are NP-F550, NP-F750, and NP-F970, all Jupio Proline (3350, 6700, 10050 mAh @ 7.2V): The 550 is great for handheld use. The 750 is somewhat heavy but still good for handheld use. The 970 is big, heavy and expensive. It makes a cube not so much portable, as autonomously powered. It can run 24 hours on a charge.

Sure. I build little cubes. The battery adapter plate is on the right, occupying one side of the cube. It looks a bit like a bay window. No battery. Rightmost the button to unlock/eject the battery. And this is the same cube, with a 3350mAh @ 7.2V battery attached. The display is switched to show DC Voltage: A USB powerbank works well, too. I have tried this; it is simple, it just works. This requires (almost) no changes to your design. When your experiment fails, you can still use the powerbank for many other purposes. I can only encourage you to do this. Taking your project with you on the road, or even just to all corners of the house, opens up many opportunities.

Indeed, a Pi with HAT Brick, GPS, CO2, AirQ, sound pressure, multi-touch, segment display. One module is an adapter plate for external power packs. You click in a power pack and off you go. I really like that. Took a few experiments to get it right. Thanks for the info on CO2. Grüße!

Michael, Your project and explanation inspired me to add a CO2 sensor to my project, and is has been very interesting so far. With Covid-19 even more so, as an indicator of how much of the air you breathe is actually second hand. I put the whole thing on the table at a meeting, for instance. Quite graphic. Other discoveries are how little the CO2 ppm differ between city and countryside. Or that when you're sleeping, CO2 is relatively low, it starts to rise as soon as you wake up. As a portable device, it is almost like a sixth sense. I find CO2 levels at the high side (rarely below 1000ppm, outside or in), so will be getting a second sensor to compare.

Well no, I would not say it is fixed, it's documented. This is costing me a bit.

Hello, For a Master Brick 3.1 (HW version 3.0.0, FW 2.5.1, Ruby bindings 2.1.29), it seems #get_usb_voltage always returns 0 (zero). The documentation says "Returns the USB voltage. Does not work with hardware version 2.1". I am asking because I have a stack powered via USB by a power pack.

Since a few days we have a GL.iNET Mango setup as a second AP with a separate SSID serving only Tinkerforge stacks on 2.4GHz. The main router powers the Mango from one of its USB ports. Connections for both stacks have been stable for a few days with this setup. So it is indeed the Wifi extensions not getting along with the big ASUS router.

Because the blog has no possibility to comment, I'll respond here. Thanks for blogging again in English. It is good to have some insight into the supply problems, and to read about your plans. Looking forward to working with Tinkerforge – people, software, and hardware – in 2022. And...thanks for your patience in providing support!

We'll setup an alternate AP to test this. I will get back to you after the Christmas weekend.

I can confirm FW 2.1.6 fixes this issue for Wifi Extension 2.0 in client mode (with the limitation described above).

2.5.1 Beta FW fixes this on my Master Bricks.