Closed dduehren closed 2 years ago
Thanks for the report.
I fully agree that the documentation, resp interface is misleading and hard to understand.
data is ready if the last 11 bits are not 0. The upper 5 bits should be ignored entirely. Please see the pseudo code on how to use it.
uint16_t data_ready = read_word() & 0x07FF;
if (data_ready > 0) {...}
Of course "last bits" depends on whether your're looking it as big-endian or little-endian and if last means the highest order bits or the lowest order bits. It's really unclear. Should define b0 as the right-most bit, and say bits b10-b0 should have a value greater than 0 indicates data ready. Or give an example.
Yes "last bits" is a inaccurate term for CPUs. As for now just return what we get from the sensor. I will open a ticket to change that to provide a better interface for the user
DataReady interface is updated
In the process of debugging the FRC library error - previous issue, I implemented scd4x.getDataReadyStatus(dataRdy);
The .h file says * @param dataReady If last 11 bits are 0 data not ready, else data ready So I implemented this but it didn't work. Printing out the dataReady byte shows that a value of 0x8006 indicates valid data. When the FRC command failed, I would get results of 8000 and 0, but in both cases, the data was bad. I don't really know what to test for because I don't know if the 0x8006 is stable. Could some of the other bits change and still be valid? For now, I'm just checking for 11 zeroes after the leading bit because that's closest to what the documentation says but it's misleading.
Linus's Law, which states that “given enough eyeballs, all bugs are shallow. Cathedral and Bazaar