0

I use ADXL345(-+16g)

I know it is for 10bits then the range is -512 ~ 511.

But I turn ADXL345, I can get from about -255~ 255.

What is wrong?

The code is:

unsigned __int16 HLdata(unsigned __int16 H, unsigned __int16 L)
{
    unsigned __int16 h, l,ans;
    h = ((unsigned __int16)H << 8);
    l = (unsigned __int16)L & 0x00ff;
    ans = (h | l);
    return ans;
}

axt = HLdata(TempChar[11], TempChar[10]) & 0x03ff; //it is for using 10bits
ayt = HLdata(TempChar[13], TempChar[12]) & 0x03ff;
azt = HLdata(TempChar[15], TempChar[14]) & 0x03ff;
krlzlx
  • 5,752
  • 14
  • 47
  • 55
  • Did you check what is the range of values of TempChar[] that you're passing to your function? Are you seeing -512 ~ 511 range in the arguments passed to the function (through manual calculation using LS 8-bits of the two arguments) and seeing the range becomes -256 ~ 255 after your function returns? Or, is the range -256 ~ 255 in the TempChar[] itself to start with? – iVoid Jul 18 '18 at 09:34
  • hi, yes i checked TempCharp[] i saw the datasheet. and using 10-bits is written. i use 0ne bit for sign bit. and 9 bits are values. i dont why i can not see over 255.... i extract raw data. its full range is 0~1024(10bits). when i turn my sensor. the data(300~600) dose not appear.. – Jeremy Jeremy Jul 18 '18 at 11:46
  • It's still not clear from your reply whether you're getting 9-bit range or 10-bit range in TempChar[]. If you're getting 9-bit range in TempChar[] itself, there might be some problem in the way you're acquiring the data from the sensor to TempChar[]. Is it possible to read the sensor directly using a logic analyzer / oscilloscope? It's better to go step-by-step. Check the sensor output first, then sensor output into your device which reads from the sensor, then your code output. – iVoid Jul 18 '18 at 12:35
  • Orthogonal to this discussion, is it essential for you to have 10-bit range in your values? As most of the accelerometer related algorithms work on delta between values, the absolute range of the values you get shouldn't matter unless some kind of clipping (you get mostly 255 instead of varying values) happens. Are you facing any issue with your actual application due to this? – iVoid Jul 18 '18 at 12:38
  • thank you for giving me an answer. now i got the solution. it was short(8bit) type and when i changed(extend) short to __int (16bit). left side of extended bits were filled with ffff so i made it 0000(L & 0x00ff;). finally i got it!!!!!!!!!!!!!!!!! – Jeremy Jeremy Jul 31 '18 at 01:47

0 Answers0