4 ms·

This was an issue we had in one of the previous versions of the kit. Since then we have improved the hardware (now at version 4.2) as well as fixed it in the fi

This was an issue we had in one of the previous versions of the kit. Since then we have improved the hardware (now at version 4.2) as well as fixed it in the firmware. If you still have issues, please contact me through the link on my profile.

_zoltan_ 3y ago
the above linked GitHub issue is still open.
- rgovostes 3y ago
  The above linked GitHub issue has been closed for over 6 months, and aside from that was posted to the wrong project rather than to an official AirGradient channel.
  - ahaucnx 3y ago
    This has been analysed extensively on our forum and the root cause was a bug in the software serial Arduino library as well as a slightly wrong command send from our library. Details [1] [1] https://forum.airgradient.com/t/co2-reading-of-3-constantly/605/6 https://forum.airgradient.com/t/co2-reading-of-3-constantly/...
    - mtlmtlmtlmtl 3y ago
      Arduino library eh? Would definitely recommend getting away from that as soon as possible. When I worked with avr controllers we eventually ended up writing all of our own library code because it was still faster than trying to debug these strange heisenbugs caused by gnarly bugs in the libraries. I specifically remember softserial was very problematic, and actually reading the code convinced me to dump it. Might be fixed now, but there's timing code in there that could easily break on a compiler update because it's still written in C++ and has handcounted delays based on counting instructions in compiler output. Now, maybe they recheck those on every single release of avr-gcc to make sure the count didn't change, but why rely on that? We're talking about the same maintainers here who kept conditionally compiled ASM code to manually push and pop the stack in every function because some absolutely ancient MacOS 9(or something like that) version of GCC somehow didn't emit those instructions. That was still there in 2015, hopefully they removed it since then... It also sets interrupts. I don't like library code doing this at all. I wanted complete control over that so I always know what interrupts might occur. And even worse it uses a circular buffer for storing data but IIRC offers no method of detecting a full buffer. Which led to a lot of "fun" debugging. Arduino libraries are fine for simple prototyping, but they're not high quality enough for writing reliable microcontroller code.
      - rgovostes 3y ago
        Is there a library that you do recommend using for serial comms?

_zoltan_ 3y ago

the above linked GitHub issue is still open.

rgovostes 3y ago
The above linked GitHub issue has been closed for over 6 months, and aside from that was posted to the wrong project rather than to an official AirGradient channel.
- ahaucnx 3y ago
  This has been analysed extensively on our forum and the root cause was a bug in the software serial Arduino library as well as a slightly wrong command send from our library. Details [1] [1] https://forum.airgradient.com/t/co2-reading-of-3-constantly/605/6 https://forum.airgradient.com/t/co2-reading-of-3-constantly/...
  - mtlmtlmtlmtl 3y ago
    Arduino library eh? Would definitely recommend getting away from that as soon as possible. When I worked with avr controllers we eventually ended up writing all of our own library code because it was still faster than trying to debug these strange heisenbugs caused by gnarly bugs in the libraries. I specifically remember softserial was very problematic, and actually reading the code convinced me to dump it. Might be fixed now, but there's timing code in there that could easily break on a compiler update because it's still written in C++ and has handcounted delays based on counting instructions in compiler output. Now, maybe they recheck those on every single release of avr-gcc to make sure the count didn't change, but why rely on that? We're talking about the same maintainers here who kept conditionally compiled ASM code to manually push and pop the stack in every function because some absolutely ancient MacOS 9(or something like that) version of GCC somehow didn't emit those instructions. That was still there in 2015, hopefully they removed it since then... It also sets interrupts. I don't like library code doing this at all. I wanted complete control over that so I always know what interrupts might occur. And even worse it uses a circular buffer for storing data but IIRC offers no method of detecting a full buffer. Which led to a lot of "fun" debugging. Arduino libraries are fine for simple prototyping, but they're not high quality enough for writing reliable microcontroller code.
    - rgovostes 3y ago
      Is there a library that you do recommend using for serial comms?