I am using a ADXL343 accelerometer in one of my designs and I am getting strange readings from the device. Just to be sure, I would like to confirm that I am formatting the data properly. (I get the readings through I2C and the chip identifier is read ok, so the bus is working properly)

I configure the device as explained in http://www.analog.com/media/en/technical-documentation/application-notes/AN-1077.pdf

DATA_FORMAT = 0x0B  // Full resolution and Range +-16g
POWER_CTL = 0x08    // Start to measure
INT_ENABLE = 0x80   // Enable data ready interrupt


Then I start polling the device doing burst readings to get the 6 data registers (DATAX0, DATAX1, DATAY0, DATAY1, DATAZ0 and DATAZ1). I store these values in an array of unsigned 16bits integers ( uint16_t data[] ). So data[] = { DATAX0, DATAX1, DATAY0, DATAY1, DATAZ0, DATAZ1 }

As explained in the application note the data is formatted as:

so, I guess I have to mask the 16bit word with 0x8FFF as follows:

int16_t accelerationRawX = (int16_t)(((data[1] << 8) | data[0]) & 0x8FFF);


Is this right? I do this because, when casting to signed int, the MCU only expects the MSB to be the sign bit, if I don't mask out D14, D13 and D12 they will be interpreted as regular bits.

Then, to get the final acceleration I multiply by the scale factor 3.9:

int16_t accelerationX = accelerationRawX * 3.9;


I am doing something wrong because the results I get don't makes much sense. I would expect to get a Z acceleration value close to 1000mg when the board is resting flat in the table, but I am getting much different result.

Also, I don't understand this table from the same AN:

How do they get the +1599 value? because 4095 * 3.9 is 15970.5..

Any advice or help will be appreciated!

• Are you configuring the chip in which data ouput mode (datasheet page 32) ? Can you put the init code ?You should refer to the datasheet here which has more extensive information: analog.com/media/en/technical-documentation/data-sheets/… – Damien Sep 26 '18 at 10:05
• Do you get constant but potentially wrong readings or are they somehow random? – Humpawumpa Sep 26 '18 at 10:13
• You can try ((int16_t)(((int16_t)data[1] << 8) | data[0]) & 0x8FFF). As you shift your bits before casting, the compiler might consider it as a 8bit char and thus discarding it. Some sample data of what you get would be useful. – Damien Sep 26 '18 at 10:20
• @Damien, I configure the device with the full resolution bit and with +-16g range, see the edited post. I will try the cast you suggest as soon as I arrive home. Thanks! – jap jap Sep 26 '18 at 11:52
• @Humpawumpa, the readings were not random but they were not very stable neither. The stability is not a big issue, I could filter the data, the worst thing is that the readings did not make much sense.. I will copy/paste some samples as soon as I can. Thank you! – jap jap Sep 26 '18 at 11:55