I2C/SPI sensor readings not accurate #18261

ujur007 · 2025-10-13T04:39:16Z

ujur007
Oct 13, 2025

I have a sensor from TDK that is ICM-42670-P. The sensor is working ok on I2C bus and it is detected by scan().
I can read the ID and temperature data accurately. The issue is of not being able to read accelerometer data over I2C.
Here is the sample code that I am using. The temprature data is read ok. But the accelerometer data is not ok.
I also tried to look at other open-source code in C to check weather I am missing something. But seems ok to me.

There are basically three registers that I need to configure. Namely PWR_MGMT0, ACC_CONFIG0, ACC_CONFIG1
If you spot any error in the following code then let me know.
I am ready to contribute my code once I finished the code.

`
def get_temprature(self):        
        self.i2c.writeto_mem(_ICM2670P_ADDRESS, _PWR_MGMT0, b'\x0F')
        time.sleep(0.05)
        temp0 = (self.i2c.readfrom_mem(_ICM2670P_ADDRESS, _TEMP_HIGH, 1))
        temp1 = (self.i2c.readfrom_mem(_ICM2670P_ADDRESS, _TEMP_LOW, 1))
        
        temprature = (int.from_bytes(temp0) << 8) | int.from_bytes(temp1)
        t = (temprature / 128) + 25
        data = t
        print('Temprature ', t, '*C')
        return t
    
    def enable_imu(self):
        # we want to put both accelerometer and gyroscope to LN mode
        # if you want to put to LP mode write 0x0A
        self.i2c.writeto_mem(_ICM2670P_ADDRESS, _PWR_MGMT0, b'\x03')
        #self.i2c.stop()
        time.sleep(0.05)
        return 0
    
    def set_accel_rate(self):
        
        buf = bytes(b'\x21')
        self.i2c.writeto(_ICM2670P_ADDRESS, buf, True)
        
        buf = bytes(b'\x09')
        self.i2c.writeto(_ICM2670P_ADDRESS, buf, True)
        #self.i2c.writeto_mem(_ICM2670P_ADDRESS, _ACCEL_CONFIG0, b'\x09')
        
        time.sleep(0.05)
        
        buf = bytes(b'\x24')
        self.i2c.writeto(_ICM2670P_ADDRESS, buf, True)
       
        time.sleep(0.05)
        
        buf = bytes(b'\x0F')
        self.i2c.writeto(_ICM2670P_ADDRESS, buf, True)
        return 0
    
    def read_accelerometer(self):
        
        buf = bytes(b'\x0B')
        self.i2c.writeto(_ICM2670P_ADDRESS, buf, True)        
        
        tmp0 = self.i2c.readfrom(_ICM2670P_ADDRESS, 1, True)
        tmp1 = self.i2c.readfrom(_ICM2670P_ADDRESS, 1, True)
       
        ax = (int.from_bytes(tmp0, "big", True) << 8) | int.from_bytes(tmp1, "big", True)
        
        tmp0 = self.i2c.readfrom_mem(_ICM2670P_ADDRESS, _ACCEL_DATA_Y1H, 1)
        tmp1 = self.i2c.readfrom_mem(_ICM2670P_ADDRESS, _ACCEL_DATA_Y1L, 1)
        
        ay = (int.from_bytes(tmp0, "big", True) << 8) | int.from_bytes(tmp1, "big", True)
        
        tmp0 = self.i2c.readfrom_mem(_ICM2670P_ADDRESS, _ACCEL_DATA_Z1H, 1)
        tmp1 = self.i2c.readfrom_mem(_ICM2670P_ADDRESS, _ACCEL_DATA_Z1L, 1)
        
        az = (int.from_bytes(tmp0, "big", True) << 8) | int.from_bytes(tmp1, "big", True)     
        
        print(ax/2048, ay/2048, az/2048)
        return 0        
        `

Another issue that I am facing is with working on this sensor over SPI. I am not sure, but I cannot read the ID register.

import time
from machine import Pin, SPI
import machine

spi = machine.SPI(2, baudrate=10000000, polarity=0, phase=0, sck=machine.Pin(40), mosi=machine.Pin(39), miso=machine.Pin(38))

cs = Pin(3, Pin.OUT)

cs.value(1)
time.sleep(0.04)
cs.value(0)
time.sleep(0.04)

#spi.write(b'\x01\x05')
time.sleep(0.04)
#spi.write(b'\x05')
time.sleep(0.04)

spi.write(bytearray([0xF5]))
time.sleep(0.04)
data = spi.read(1)

cs.value(1)

spi.deinit()

print(data)

Answered by peterhinch

Oct 13, 2025

Consider your 31.91402 value:

>>> hex(round(31.91402*2048))
'0xff50'

The 16 bit value 0xFF50 is evidently a negative number in two's complement which the code is interpreting as unsigned. To convert a raw 16 bit two's complement number to a signed integer you want:

n = n - 0x10000 if n & 0x8000 else n

View full answer

Josverl · 2025-10-13T09:40:41Z

Josverl
Oct 13, 2025
Collaborator Sponsor

Your read_accelerometer() mixes different approaches: sometimes you use readfrom, other times readfrom_mem.
You seem to read X axis with readfrom after sending a single byte (0x0B), then Y/Z with readfrom_mem and register constants.
This is likely the main problem:
The ICM-42670-P expects multi-byte reads starting from the base address of the data registers, not individual reads per axis.
For 16-bit values, you should read two bytes per axis, and use the correct register addresses for high/low bytes.
I think you can read all 3 axis in one go:

def read_accelerometer(self):
    # Assume _ACCEL_DATA_X1H is the base address for X axis high byte
    data = self.i2c.readfrom_mem(_ICM2670P_ADDRESS, _ACCEL_DATA_X1H, 6)
    ax = int.from_bytes(data[0:2], "big", signed=True)
    ay = int.from_bytes(data[2:4], "big", signed=True)
    az = int.from_bytes(data[4:6], "big", signed=True)
    print(ax/2048, ay/2048, az/2048)
    return (ax, ay, az)

Based on : ICM-42670-P datasheet (TDK)

Nitpicking: get_temprature --> get_temperature

3 replies

ujur007 Oct 13, 2025
Author

Thanks for your response.
So, I pasted the code that you have above. I just changed signed=True parameters to just value True.
Now, the problem seems to remain the same. Just look at these output values. They are odd. Specifically see the drastic change in values to ~31.xx.
Also, the values should be in range +/-16 g range, that is not the case here. Regarding your question about using different I2C function, I only had code that was reading with self.i2c.readfrom_mem. But then I tried some different things.

The problem might be that I have wrong configuration values in registers PWR_MGMT0, ACC_CONFIG0, ACC_CONFIG1, but that is doubtful.

>>> %Run -c $EDITOR_CONTENT

MPY: soft reboot
[104]
0x67
0.412109368 0.29052734 0.8852539
0.30615234 0.29833984 1.0361328
0.3256836 0.27441406 0.92333984
0.31445312 0.25927734 0.93359376
0.2553711 0.222167968 0.9580078
0.21728516 0.2055664 0.9926758
0.13183594 0.12597656 0.9819336
0.08691406 0.13623047 1.0341797
0.125 0.011230469 1.0244141
0.351074216 31.8315432 0.953125
0.458984368 31.6127932 0.8364258
0.09814453 31.41504 0.90234376
31.728028 0.37646484 1.0371094
31.875 0.3154297 0.9350586
0.19433594 0.5805664 0.7949219
0.14697266 31.962402 1.0678711
0.238281252 0.25830078 1.078125
31.632812 0.9609375 0.06542969
0.7871094 31.572266 0.31591796
31.914062 31.952148 1.0288086
0.39257812 0.4091797 0.8354492
0.4189453 0.3930664 0.8232422

peterhinch Oct 13, 2025
Collaborator

Consider your 31.91402 value:

>>> hex(round(31.91402*2048))
'0xff50'

The 16 bit value 0xFF50 is evidently a negative number in two's complement which the code is interpreting as unsigned. To convert a raw 16 bit two's complement number to a signed integer you want:

n = n - 0x10000 if n & 0x8000 else n

Answer selected by ujur007

ujur007 Oct 14, 2025
Author

@peterhinch Ok. I will try that. I assumed that MP also handles integers like C. In C, if we have a int16_t value, it will be converted to appropriate value automatically.

peterhinch · 2025-10-13T17:11:50Z

peterhinch
Oct 13, 2025
Collaborator

@Josverl Your answer is right except that MP does not seem to support the signed arg.

1 reply

Josverl Oct 13, 2025
Collaborator Sponsor

Tnx for the correction - Always hard to test without the actual hardware

sosi-deadeye · 2025-10-14T07:08:33Z

sosi-deadeye
Oct 14, 2025

Try to use struct.struct to interpret the binary data. The type should be h (Short, 16 bit, signed).

1 reply

ujur007 Oct 14, 2025
Author

Oh I see.

MicroPython

I2C/SPI sensor readings not accurate #18261

Uh oh!

Uh oh!

ujur007 Oct 13, 2025

Replies: 3 comments · 5 replies

Uh oh!

Uh oh!

Josverl Oct 13, 2025 Collaborator Sponsor

Uh oh!

ujur007 Oct 13, 2025 Author

Uh oh!

Uh oh!

peterhinch Oct 13, 2025 Collaborator

Uh oh!

ujur007 Oct 14, 2025 Author

Uh oh!

peterhinch Oct 13, 2025 Collaborator

Uh oh!

Josverl Oct 13, 2025 Collaborator Sponsor

Uh oh!

sosi-deadeye Oct 14, 2025

Uh oh!

ujur007 Oct 14, 2025 Author

ujur007
Oct 13, 2025

Replies: 3 comments 5 replies

Josverl
Oct 13, 2025
Collaborator Sponsor

ujur007 Oct 13, 2025
Author

peterhinch Oct 13, 2025
Collaborator

ujur007 Oct 14, 2025
Author

peterhinch
Oct 13, 2025
Collaborator

Josverl Oct 13, 2025
Collaborator Sponsor

sosi-deadeye
Oct 14, 2025

ujur007 Oct 14, 2025
Author