Gravity I2C Oxygen Sensor (SKU SEN0322) high-order bit flips?
herb 2021-11-15 23:32:42 649 Views4 Replies So we recently got two of these sensors for a project and we've actually been really pleased with how easy they were to set up and use. There is only one problem, which is that occasionally we see really high readings returned in plain air (e.g. 48.7% oxygen instead of the normal 20.9%).
We have these hooked up to a Raspberry Pi Zero W and we're using the sample code from the library posted on the wiki (https://wiki.dfrobot.com/Gravity_I2C_Ox ... KU_SEN0322). These sensors are connected to the standard I2C pins 3 (SDA, green wire on the supplied connector) and 5 (SCL, blue wire) and we're using pin 4 (+5V, red wire) and pin 6 (GND, black wire) for the power supply. As far as I know these should all be correct, and like I said, for the most part, it's returning good values. Just every few minutes or so we get a value that is completely out of whack.
Looking at the sample code, it seems that the sensor returns 3 byte values, with the first byte taken as-is, the second and third are divded by 10 and 100 respectively, then they're all added up and multiplied by the calibration value in stored the sensor's register (0.208 in my case). This is all fine, but when I added some debugging print statements, I saw that while normally the first byte returns a value of around 100, sometimes when the high readings occur, it returns a value of around 228. That seems suspiciously like 2^7 = 128 got added to the real value. (For what it's worth, it seems like the second and third byte are unaffected by this - at least I haven't seen any really high values for those yet.)
I don't know if this is just some sort of noise in our setup, or what. If so, what can I do to reduce that? Since both sensors we have behave the same way, it's probably something to do with our Raspberry Pi setup, but I can't see what the problem might be. I can't imagine we got two broken sensors... ;]
I'd appreciate your help in trying to troubleshoot this. Thanks in advance!
We have these hooked up to a Raspberry Pi Zero W and we're using the sample code from the library posted on the wiki (https://wiki.dfrobot.com/Gravity_I2C_Ox ... KU_SEN0322). These sensors are connected to the standard I2C pins 3 (SDA, green wire on the supplied connector) and 5 (SCL, blue wire) and we're using pin 4 (+5V, red wire) and pin 6 (GND, black wire) for the power supply. As far as I know these should all be correct, and like I said, for the most part, it's returning good values. Just every few minutes or so we get a value that is completely out of whack.
Looking at the sample code, it seems that the sensor returns 3 byte values, with the first byte taken as-is, the second and third are divded by 10 and 100 respectively, then they're all added up and multiplied by the calibration value in stored the sensor's register (0.208 in my case). This is all fine, but when I added some debugging print statements, I saw that while normally the first byte returns a value of around 100, sometimes when the high readings occur, it returns a value of around 228. That seems suspiciously like 2^7 = 128 got added to the real value. (For what it's worth, it seems like the second and third byte are unaffected by this - at least I haven't seen any really high values for those yet.)
I don't know if this is just some sort of noise in our setup, or what. If so, what can I do to reduce that? Since both sensors we have behave the same way, it's probably something to do with our Raspberry Pi setup, but I can't see what the problem might be. I can't imagine we got two broken sensors... ;]
I'd appreciate your help in trying to troubleshoot this. Thanks in advance!
2021-11-16 07:16:42 OK, I no longer have any clue as to what's happening here! ;]
I pulled out my scope to look at the actual signal coming across and I managed to capture one where the value was off. Conveniently I have I2C decoding on this scope and I was therefore able to easily decode the data. At first it came across just fine as values of 0x61 0x03 0x02, with a calibration register value of 0xD6 which would mean that this value would decode to a value of 20.83% oxygen, perfectly fine! This screenshot SDS00001.png shows that (see data decoding at the bottom). https://imgur.com/G9PrLz0
However, when I tweaked the threshold settings for a clock signal a little bit (just below 320mV I believe), the value changed to 0xE1 0x03 0x02 (see SDS00002.png, again, data decoding at the bottom https://imgur.com/cxicd3g), which would equate to 48.22%, which is exactly what I saw in the terminal (see Terminal.png https://imgur.com/lYrXiM3)! Hunting around the signal I indeed found a runt clock pulse (SDS00009.png https://imgur.com/fXq9oNb).
So now I have a smoking gun, but no idea what to do about it. So I decide to try it out on a different Raspberry Pi Zero W. Swap out the sensor and SD card, boot up the other RPI, and... nothing! It can't even see the sensor address on the I2C bus. Hmm... `sudo i2cdetect -y 1` shows nothing. Weird! So I go into raspi-config to try and see if I2C is enabled, and I accidentally switch on SPI instead (for some reason I always get those confused). Then I try and re-enable I2C and the whole thing now hangs. I did a few other things (unfortunately I cannot remember precisely what
) and end up swapping back to the old RPI.
And wouldn't you know it, now it works perfectly fine! It's been reporting super-steady values for over an hour now, no more spikes! I have absolutely no idea what fixed it (nor why it didn't work on the other RPI). If anybody has some insights and/or theories about what might have happened here, I'd love to hear them! herb
I pulled out my scope to look at the actual signal coming across and I managed to capture one where the value was off. Conveniently I have I2C decoding on this scope and I was therefore able to easily decode the data. At first it came across just fine as values of 0x61 0x03 0x02, with a calibration register value of 0xD6 which would mean that this value would decode to a value of 20.83% oxygen, perfectly fine! This screenshot SDS00001.png shows that (see data decoding at the bottom). https://imgur.com/G9PrLz0
However, when I tweaked the threshold settings for a clock signal a little bit (just below 320mV I believe), the value changed to 0xE1 0x03 0x02 (see SDS00002.png, again, data decoding at the bottom https://imgur.com/cxicd3g), which would equate to 48.22%, which is exactly what I saw in the terminal (see Terminal.png https://imgur.com/lYrXiM3)! Hunting around the signal I indeed found a runt clock pulse (SDS00009.png https://imgur.com/fXq9oNb).
So now I have a smoking gun, but no idea what to do about it. So I decide to try it out on a different Raspberry Pi Zero W. Swap out the sensor and SD card, boot up the other RPI, and... nothing! It can't even see the sensor address on the I2C bus. Hmm... `sudo i2cdetect -y 1` shows nothing. Weird! So I go into raspi-config to try and see if I2C is enabled, and I accidentally switch on SPI instead (for some reason I always get those confused). Then I try and re-enable I2C and the whole thing now hangs. I did a few other things (unfortunately I cannot remember precisely what
) and end up swapping back to the old RPI.And wouldn't you know it, now it works perfectly fine! It's been reporting super-steady values for over an hour now, no more spikes! I have absolutely no idea what fixed it (nor why it didn't work on the other RPI). If anybody has some insights and/or theories about what might have happened here, I'd love to hear them!
herb 2021-11-16 03:07:56 I've now also tried twisting the wires together - red/green (+3.3V, SDA) and black/blue (GND, SCL) per suggestion from https://electronics.stackexchange.com/a/444350, but I'm still getting the spikes.
These spikes are relatively regular, occurring about every 10 minutes or so. I'm beginning to wonder if it's some regularly running process on the Raspberry Pi that's causing this, but so far I have no idea what that might be. I've checked crontabs, but no luck there so far. I also tried running `top` to see if I could catch anything unusual running while the spikes are happening, but no results there, either. herb
These spikes are relatively regular, occurring about every 10 minutes or so. I'm beginning to wonder if it's some regularly running process on the Raspberry Pi that's causing this, but so far I have no idea what that might be. I've checked crontabs, but no luck there so far. I also tried running `top` to see if I could catch anything unusual running while the spikes are happening, but no results there, either.
herb 2021-11-16 00:39:43 Here's a screenshot of the data I'm sending into Grafana - the dotted blue line is where I switched from 5V to 3.3V, you can see the values are much more stable (very nice!), but those dang spikes are still there. This is reading one value at a time. https://imgur.com/a/F44owjZ herb
herb 2021-11-16 00:27:05 I also just tried moving the positive power supply to pin 1 (3.3V), but I'm still getting those same spikes there. The normal readings show less fluctuations (reading a single value at a time), so that seems to have improved a little, but the spikes at 47/48% are still happening. 
herb
herb 