Why remove a bit from pressure sensor reading?

[StaffanMelin]

Hi Javier! A small question about the code in pressure.rs:

    fn read_io(i2c: &mut rppal::i2c::I2c) -> Result<i32, Box<dyn Error>> {
        let mut reg = [0u8; 3];
        let mut result;
        i2c.read(&mut reg)?;
        result = reg[0] as i32;
        result <<= 8;
        result |= reg[1] as i32;
        result <<= 8;
        result |= reg[2] as i32;
        if (reg[0] & 0x20) >> 5 == 0x1 {
            result = result - 4194304;
        }
        Ok(result)
    }

Why are you clearing that bit from reg[0]?

Cheers,

Staffan
SWEDEN

[jcard0na]

Hi Staffan,

I'm looking at this code late at night and it makes no sense to me. ( I wrote it a long while back... 😬 )

In principle, it should be converting an unsigned 12-bit value read from the ADC (MCP3221) into a signed pressure value.
But in practice I have no clue on what it is doing...

1. We should be reading two bytes, why 3? let mut reg = [0u8; 3]; 😳
2. The output should range from -2048 to 2047, not sure where that 4194304 comes from 😖
3. And testing the sixth bit of reg[0]... why?? reg[0] & 0x20 😱

I'll look at this tomorrow with clear eyes, and re-run the pressure tests. I sure hope I find a reasonable answer, because at this point I'm surprised the pressure sensor works at all! (At least the good news is that it does... 😅 )

Cheers,

[StaffanMelin]

Thanks! :)

And as you can see I do the same in my C++ code:

    ssize_t bytes = read(i2cfile, value, 3);
    pressure = (value[0] << 16) | (value[1] << 8) | value[2];

What we really get from the sensor over i2c is 3 bytes in the range of 52 000 (not blowing into the horn) to about 80 000 (blowing strongly). Sucking gives a value less than approx 52 000.

So what I do is basically subtracting 52 000 and scale the interval to a 0.0 - 1.0 float.

I spent several hours debugging my code as I first read it as a WORD (2 bytes), but when I blew strongly into the hax the return value definitely overflowed.

So 3 bytes it is, strange as it is a 12 bit ADC, right?

When I look at the MCP3221 datasheet it says it send four 0:s, the four highest bits, then the 8 lowest bits in the 2nd byte.

Similar code online: https://raspberrypi.stackexchange.com/questions/132322/solved-can-ioctlfile-i2c-smbus-args-be-used-to-read-mcp3221. Two bytes.

:)

Cheers,

Staffan

BTW The 4194304 is 01000000 00000000 00000000 binary.

[jcard0na]

OK, mystery solved, and it's a bit embarrassing...

I'm mistakenly reading 3 bytes when I should read just two.
I did not notice the problem because the MCP3221 supports continuous reading:

So instead of an error, in the third read we get the most significant byte one more time.
I modified the read_io test to confirm. Notice the repeated byte in the reg array...

pi@haxophone:/media/usb/dev/haxo-rs $ cargo test read_io -- --nocapture --ignored
    Finished test [unoptimized + debuginfo] target(s) in 0.40s
     Running unittests src/main.rs (target/debug/deps/haxo001-31e85edb2788c772)

running 1 test
Blow and draw on the mouthpiece...
reg: [7, 247, 7]
reg: [7, 240, 7]
pressure: 520199, min: 2147483647, max: 0
reg: [7, 241, 7]
pressure: 520455, min: 520199, max: 520199
reg: [7, 236, 7]
pressure: 519175, min: 520199, max: 520455
reg: [7, 242, 7]
pressure: 520711, min: 519175, max: 520455
reg: [7, 240, 7]
pressure: 480775, min: 512519, max: 747275
reg: [6, 178, 6]
pressure: 438790, min: 480775, max: 747275
reg: [6, 60, 6]
pressure: 408582, min: 438790, max: 747275
reg: [5, 228, 5]
pressure: 386053, min: 408582, max: 747275
reg: [5, 171, 5]
pressure: 371461, min: 386053, max: 747275
reg: [5, 127, 5]
pressure: 360197, min: 371461, max: 747275
reg: [5, 97, 5]
pressure: 352517, min: 360197, max: 747275
reg: [5, 64, 5]
pressure: 344069, min: 352517, max: 747275
reg: [5, 49, 5]
pressure: 340229, min: 344069, max: 747275
reg: [5, 42, 5]
pressure: 338437, min: 340229, max: 747275
reg: [5, 41, 5]

Things do work because of sheer luck 🍀: even with the extra byte, the result is mostly linear with pressure, and I used the 3-byte converted value to be the ground truth. I somehow made an "off-by-a-factor-of-two" error, if that even exists: the ADC returns 3 nibbles, not 3 bytes. Made that mistake early on, and never looked back!

I'll be committing a fix for this shortly. In the meantime, accept my apologies... 😓

[StaffanMelin]

No problem, at least I asked a meaningsful question! :) Thanks for fixing!

[jcard0na]

Fixed by db868ba

[StaffanMelin]

Great! This worked for my code too.