Superp

Cross reference: CO2 Bricklet 2.0 accuracy

Have you tried using a different cable?

I already ordered one earlier today. All looks fine, size is now 40x40mm. The documentation seems a bit inconsistent re onboard antenna?

Dear Tinkerforge, I am aware a GPS Bricklet 3.0 is in the pipeline. I am assuming V3 will support Galileo, and V2 will not be upgraded to support Galileo. Can you share with us: When V3 will become available, and How it will be different from V2? I have a little project incorporating a GPS, and at some point want to finalise the design and order the parts (using a GPS V2 for prototyping at the moment). Thanks for any info.

Hi Rik, Regardless of the programming language, my advice would be to use a callback. But the current documentation does not mention callbacks for this Bricklet and Java. The docs mention callbacks for Java and other devices (example: Accelerometer Bricklet 2.0), and for the NFC Bricklet and another language like Ruby. Maybe something is wrong with the documentation?

Thanks, will order some.

Dear Tinkerforge, The Outdoor Weather Bricklet has been out of stock for a while. For me, this is a vital Bricklet. Can you give us an estimate date for when it will be in stock again, or is it being phased out?

...and they are sold out again at Kiwi.

For anybody else who has HAT Brick based projects stalled because it is impossible to buy RPi's: Kiwi Electronics has Raspberry Pi 3 model A+ in stock since yesterday.

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.