Datasheet mentions 3ms delays in i2c communication

[kevinjwalters]

The SCD-30 datasheet mentions 3ms delays in these two sections:

1.4.4 Get data ready status

Data ready command is used to determine if a measurement can be read from the sensor’s buffer. Whenever there is a measurement available from the internal buffer this command returns 1 and 0 otherwise. As soon as the measurement has been read by the return value changes to 0. Note that the read header should be send with a delay of > 3ms following the write sequence.

It is recommended to use data ready status byte before readout of the measurement values.

and

1.4.5 Read measurement

When new measurement data is available it can be read out with the following command. Note that the read header should be send with a delay of > 3ms following the write sequence. Make sure that the measurement is completed by reading the data ready status bit before read out.

I'm not seeing these in the current implementation, is there a reason to omit this delay? I think it means a delay between the separate (datasheet says "SCD30 does not support repeated start condition") i2c.write() and i2c.readinto() but would be useful if someone else could interpret that too.

[ladyada]

sure please submit a PR with that change

[caternuson]

Seems like it may be specific to getting the latest measurement? Not for just any I2C write/read operation. Not really sure what a "read header" means in this context. So maybe add that delay between the _send_command and readinto here: https://github.com/adafruit/Adafruit_CircuitPython_SCD30/blob/5f0ba951d4456cd1371d7b52066f7750bea582c4/adafruit_scd30.py#L233-L236

The repeated start comment does apply to any I2C xfer though. That's why _read_register has the two separate commands.

[kevinjwalters]

This has the 3ms pause but only for the equivalent of data_available: https://github.com/Sensirion/embedded-scd/blob/32ef7b7e4410b1ac3a87b758db0a0ca4e47be901/scd30/scd30.c#L116-L120

It also has some 20ms pauses after setting some parameters on the SCD-30.

[caternuson]

Interesting. It only applies for reading data ready apparently. That call to sensirion_i2c_delayed_read_cmd is not used anywhere else. When it comes to actually reading the measurement value, there is no delay: https://github.com/Sensirion/embedded-scd/blob/32ef7b7e4410b1ac3a87b758db0a0ca4e47be901/scd30/scd30.c#L83-L89

Could maybe add a delay parameter to the _read_register function that defaults to 0. But for the call here, specify a non-zero value (like 3ms): https://github.com/adafruit/Adafruit_CircuitPython_SCD30/blob/5f0ba951d4456cd1371d7b52066f7750bea582c4/adafruit_scd30.py#L112-L115

[kevinjwalters]

The equivalent library in Arduino-land has the delay (of 4ms) for the Read measurement

https://github.com/adafruit/Adafruit_SCD30/blob/24ee7a335f522df5dd74bcf4ae30beda8fc874d1/Adafruit_SCD30.cpp#L268-L326

but not for the Get data ready status

https://github.com/adafruit/Adafruit_SCD30/blob/24ee7a335f522df5dd74bcf4ae30beda8fc874d1/Adafruit_SCD30.cpp#L123-L125

https://github.com/adafruit/Adafruit_SCD30/blob/24ee7a335f522df5dd74bcf4ae30beda8fc874d1/Adafruit_SCD30.cpp#L345-L352

[caternuson]

Could be a misinterpretation of that datasheet description? The Sensirion source code should hopefully be a definitive reference.

[kevinjwalters]

I don't know if this is related but there's a curious issue mentioned on StackOverflow with i2c issues with Raspberry Pi 4 using Python: StackOverflow: how can I fix this runtime error when doing crc checking python 3 scd-30 co2 Sensor

[caternuson]

That 3ms delay is not in the older (Aug 2018) datasheet, which is what I think this library was originally using as a reference:

AUG 2018

But it does show up in the newer (May 2020) version. And I think the "read header" is the initial I2C write to send the register address.

MAY 2020

[kevinjwalters]

Did anyone get a chance to review the C equivalent library? I noted somethings in previous comment here: https://github.com/adafruit/Adafruit_CircuitPython_SCD30/issues/13#issuecomment-823392339

[ladyada]

nope, feel free to submit a PR there!