SCD-30 breakout yells if you send too many requests

[cordelya]

I'm not posting a problem, per se. I think I've already figured out the problem and have a solution. Posting here in case others encounter the same issue. When I was still trying to figure this out, reading these forums wasn't terribly helpful because all of the threads I found regarding IO Errors concerned sensors not properly connected to the I2C bus.

The issue was: An SCD-30 breakout board, connected to I2C via Qwiic/QT cables and a Qwiic adapter, would initially work in a looping script, but would eventually start screaming.
Keywords: OSError, Remote I/O Error, adafruit_scd30, [Errno 121], data_available

The solution: I changed how I was testing for the conditions of "Is it time yet?" and "is the sensor ready?"

Initially, I was checking for both conditions in the same condition test. When I nest the "is the sensor ready?" test inside of the "Is it time yet?" test, the sensor is contacted *much* less frequently, and so it doesn't scream.

https://gitlab.com/cordelya/co2-sensor- ... 448971b0d8

[dastels]

There's also the "data ready" pin:

RDY - Data Ready Pin. High when data is ready for read-out, it helps if you want to avoid polling the I2C port to verify data is ready.

See the example code: https://learn.adafruit.com/adafruit-scd ... 3081085-20.

Dave

[cordelya]

I should have specified that I'm using Blinka/RasPi, and not the Arduino library.
I'm already using the equivalent of RDY.

Per the Circuitpython reference for the SCD-30 (https://circuitpython.readthedocs.io/pr ... t/api.html), the only way to check if the sensor is ready is to check the value of [sensor].data_available.

What wasn't working well is this:

once per loop, the time elapsed since last sensor reading is checked to see if it's been long enough ("long enough" presently set for 5 seconds) AND polls [sensor].data_available at the same time.
Polling [sensor].data_available once per loop (once per second or possibly more frequently) eventually results in the sensor refusing to respond to calls. Tested on two separate sensors.

Code: Select all

if {current time} - {last reading time} >= REFRESH_INTERVAL and [sensor].data_available:
    do foo

What is working well is this:

once per loop, the time elapsed since last sensor reading is checked to see if it's been long enough.
if yes, only then is [sensor].data_available polled

Code: Select all

if {current time} - { last reading time} >= REFRESH_INTERVAL:
    if [sensor].data_available:
        do foo