Post Go back to editing

ADXL345: measurements differ between SPI 3-wire, I2C and SPI 4-wire

Hello,

Is it expected that measurements would differ slightly depending on the interface used? In testing a driver I'm developing, the measurements when connected using 3-wire SPI or I2C are more or less identical, but when connected using 4-wire SPI, all three axes read lower (X and Y are approx 2-3 LSBs lower, Z-axis is about 5 LSBs lower). Tracing the initialization/configuration of the chip using a logic analyzer, all settings are identical, except of course for the 3-wire SPI bit in DATA_FORMAT (0x31). I believe I've also ruled out the MCU's interpretation of the data as being at fault as the data can be seen different when looking at the LA capture. The module the chip is mounted to is Adafruit's product ID 1231, powered by a 3.3v MCU (Parallax P8X32A). In all three tests, the module is oriented such that it (and thus the chip package) is facing upwards. X and Y read approximately 0g, while Z reads approximately +1g

Regards

  • Hi  , 

    the sensor output should not change when switching from one protocol to another. Any change the board moved when switching connections? 

    Regards,

    Pablo. 

  • Hello Pablo,

    Thanks for your reply. No, the module stays motionless, in the same orientation. In fact, all wiring even remains the same. The only difference is which interface the software initializes the chip with. Is there a chance you'd be willing and able to attempt to duplicate this (assuming you haven't already)? I'm considering also buying a second unit to compare to this one.

    Regards,

    Jesse

  • Hi Jesse, 

    I dont have the means at this moment to switch protocol without modifying the HW (plug and unplug cables), it will take me a couple of days but I will get it done. 

    Out of curiosity, what is the ODR setting and the I2C and SPI clock frequency? The datasheet says for I2C: "Due to communication speed limitations, the maximum output data rate when using 400 kHz I2C is 800 Hz" ... "Operation at an output data rate above the recommended maxi-mum may
    result in undesirable effect on the acceleration data, including missing samples or additional noise." 

    Could this be the reason why SPI 4 wire reads lower ? I am not sure why SPI 3-wire read a hire value but something I would make sure is to pull up/down SDO with a 10kOhm resistor. 

    I hope it helps, 

    Pablo. 

  • Hi Jesse, 

    I just run a test for 4-wire SPI and I2C at 100Hz ODR and I do not see the issue you describe. See the image below: 

    I do not have an interface to test 3-wire SPI but this results I think show no difference at all, just variation typical from noise. 

    I hope this helps, 

    Pablo.  

  • Pablo,

    Thanks for putting in this time and effort - greatly appreciated! I will need to look into this more in-depth, it seems. I must've missed something.

    Cheers,

    Jesse

  • Hi Jesse, 

    no problem, let me know if I can help with anything else. Did you check if this was the problem? 

    Out of curiosity, what is the ODR setting and the I2C and SPI clock frequency? The datasheet says for I2C: "Due to communication speed limitations, the maximum output data rate when using 400 kHz I2C is 800 Hz" ... "Operation at an output data rate above the recommended maxi-mum may
    result in undesirable effect on the acceleration data, including missing samples or additional noise." 

    Regards, 

    Pablo. 

  • Hi Pablo,

    If you're referring to sensor ODR vs bus speed, yes; I tried slower ODRs to no avail. The P8X32A is a bit unique in that it has no hardware peripherals (UART/USART, etc), so to implement protocols like I2C or SPI, typically one of the 8 cores is dedicated to bit-bang (or in some cases, hardware assist by one of the counters) the interface. I've never ran into an issue like this with one of the existing I2C and SPI engines, so never considered it to be a possible cause, but I think I must concede, after seeing your data that there must be an issue with one of them somewhere (unless I truly do have a defective module or chip, but that seems unlikely).

    Cheers,

    Jesse