Hi
I am working with the SparkFun Qwiic MicroPressure (Sensor https://www.sparkfun.com/products/16476 … 1708428362. ). I recently ordered 5 new sensors of this type and initially they worked great. I used them in atmospheric pressure and they provided the correct value but after 1 hour or so, they started to send wrong pressures and shortly afther that they started to send NAN.
The sensors are connected to 3.3 V and this error has occured on all 5 that I ordered. Some sensors could still be found on the I2C bus, even after they started sending NAN while some were gone completely.
The reason I ordered 5 new sensors in the first place is beacuse the ones I previously had showed this behaviour as well.
How are they wired up? Share a photo of your setup
this picture shows how the sensor is placed. The connections to the sensor are not color coded correctly. Red cable is eventuellt connected to ground and red connected to 3.3 V.
this picture shows what an empty slot looks like. The sensor is placed in the Middle hole with an small o-ring.
The sensor SDA and SCL connections enters an i2c bus were raperri pi is master and 2 arduino are slaves. The yellow cables are SCL and green SDA.
Those are very long i2c cables; try disabling the i2c pull up resistors by cutting the traces between the pads shown in your 1st photo
Do the power LEDs still come on?
Ive disabled the I2C resistors but still no luck.
Can the sensors be damaged when sampling to fast? I have at some point taken measurements without delays in void loop. Can the sensor be damaged when sampling at those rates? Im just grasping at straws that is why i am asking.
I have the same issue. New module received today. Worked for a few minutes and now only returns nan.
Please help!
Looking at the source code an NAN is returned when either the INTEGRITY_FLAG or the MATH_SAT_FLAG is set in the status byte. According to the datasheet :
INTEGRITY_FLAG: Indicates whether the checksum-based integrity check passed or failed; the memory error status bit is calculated only during the power-up sequence.
MATH_SAT_FLAG : internal math saturation has occurred
Given that the INTEGRITY_FLAG is calculated once during power-up, I would not expect this to be the root cause (as it would return NAN from the beginning) UNLESS that chip was reset ( e.g. power drop or reset)
The MATH_SAT_FLAG is not documented in the datasheet, but looking on the Internet there are different articles about “math saturation” :
Saturation arithmetic is a version of arithmetic in which all operations, such as addition and multiplication, are limited to a fixed range between a minimum and maximum value. If the result of an operation is greater than the maximum, it is set to the maximum; if it is below the minimum, it is clamped to the minimum. (https://en.wikipedia.org/wiki/Saturation_arithmetic)
The library uses :
-
minimumPSI, minimum range value of the sensor (in PSI). Default: 0
-
maximumPSI, maximum range value of the sensor (in pSI). Default: 25
You can change those as indicated in the sketch:
SparkFun_MicroPressure mpr(EOC_PIN, RST_PIN, MIN_PSI, MAX_PSI);
Also you could include a debug print in the library file SparkFun_MicroPressure.cpp, line 108: Serial.println(status,HEX);
Match Saturation is bit 0, and INTEGRITY_FLAG is bit 2.
Thanks for the reply.
To be clear the sensor worked for the first few minutes.
But now nothing can seem to make it work.
The status returned is 45.
And thus the nan.
BTW I am using the very basic code provided by SparkFun.
Could the sensor have failed after this short time?
Thanks again,
Gene
thanks. some questions :
Doesn’t the sensor work at all anymore, or does it still work but only for a few minutes ?
If not at all anymore, it could be broken.
If it works for a few minutes: what is the status ?
what happens if you pull reset on the sensor low for a second or so… does it revive?
Looking at the datasheet and source code, the library requests the information from the sensor and should get 4 bytes in return. The first byte is the status byte. In the current setup it will check the status byte and if something is wrong it will return a NAN, without reading the next three bytes. Maybe these are not sent in case of error, but if they are the library and sensor can get out of sync and it could be a reason for continued fail. I have made a small change to the cpp file that it first tries to read the 4 bytes and after that checks the status byte. Maybe test it…
SparkFun_MicroPressure.cpp (3.78 KB)
Thanks. I will try the code change.
I grounded the reset. While grounded it reads ff.
I accidently grounded EOC for a second. Now it reading 44.
It does not give any measurement value other than NAN of course because integrity flag is still set.
Will try the revised code and post in a little bit.
Thanks again,
Gene
108 MicroPressureSensor 45
118 MicroPressureSensor 936824
nan torr
-------------------------------------------------------------------code------------------
uint8_t status = _i2cPort->read();
Serial.printf(“%d MicroPressureSensor %x\n”,LINE, status);
//read 24-bit pressure (moved UP)
uint32_t reading = 0;
for(uint8_t i=0;i<3;i++)
{
reading |= _i2cPort->read();
if(i != 2) reading = reading<<8;
}
Serial.printf(“%d MicroPressureSensor %x\n”,LINE, reading);
//check memory integrity and math saturation bits
if((status & INTEGRITY_FLAG) || (status & MATH_SAT_FLAG))
{
return NAN;
}
Wow this is interesting and may help others: I commented out the status check and just returned the reading.
================================================
118 MicroPressureSensor 936c77
102.5324 kPa
108 MicroPressureSensor 45
118 MicroPressureSensor 937029
769.146 torr
108 MicroPressureSensor 45
118 MicroPressureSensor 936e64
30.2796 inHg
108 MicroPressureSensor 45
118 MicroPressureSensor 936cdc
1.011988 atm
108 MicroPressureSensor 45
118 MicroPressureSensor 937112
1.025511 bar
weird… but also interesting… try to reduce the increase the delay in the loop of the sketch. I am still concerned that INTEGRITY_FLAG is set. It could mean a power-up/reset is happening.
Also in the cpp file, line 100, increase delay(1) to delay(10). Just to see what happens.
Changed the delay to 10 and 100…no change.
Printed out status from the loop
101 status 64
103 status 64
101 status 64
103 status 64
101 status 64
103 status 64
101 status 64
103 status 45
30.2775 inHg
098 while((status&BUSY_FLAG) && (status!=0xFF))
099 {
100 delay(1);
101 Serial.printf(“%d status %x\n”,LINE,status);
102 status = readStatus();
103 Serial.printf(“%d status %x\n”,LINE,status);
104 }
thanks… I am surprised that in 0x64, the ‘4’ stays on (bit 2)… it would mean a memory integrity failure during power-on / reset. The fact that the ‘6’ turns into a ‘4’ is because the busy flag is dropping off, which looks like normal behavior to me.
Thanks for helping…
The question remaining for me is: “Is the sensor and I I should be asking for a replacement?”
The status section worked to begin with and now is not. Can I trust the part to not fail more in another way?
Do you know how to request a replacement?
Thanks again,
Gene
looks to me with all you tried it is broken. You need to contact the seller where you bought the sensor and ask for a replacement.
