On 8/30/2015 12:15 AM, Steve Pope wrote:
> Mauritz Jameson  <mjames2393@gmail.com> wrote:
>
>>> It doesn't.  Only use Q notation if your boss has ordered you to
>>> do so, if anyone else starts quacking about Q notation tell
>>> them to go frub a duck.
>
>>> (There, got that off my chest.)
>
>> Ok :-)
>
>> So why is the Freescale PDF quacking that the data should be interpreted
>> as a Q2.12 number?
>
>> Since we're talking about directional vectors there's no additional
>> information in - for example - (-2,0,0) versus (-1,0,0)
>
> It seems this datasheet is saying that the accelerometer is measuring
> in units of G's, and that there are modes which set the end-to-end range
> of the measurement (2G's, 4G's, or 8G's) and so in fact the binary
> point is physical and not purely conceptual.
>
> So in the 4G range case there really are two bits to the left of the
> binary poiint.  And they also seem to consider rounding to a decimal
> number to be of value (it looks like, so one can report in
> milli-G's.

What he said...

-- 

Rick

Mauritz Jameson  <mjames2393@gmail.com> wrote:

>> It doesn't.  Only use Q notation if your boss has ordered you to
>> do so, if anyone else starts quacking about Q notation tell
>> them to go frub a duck.

>> (There, got that off my chest.)

>Ok :-)

>So why is the Freescale PDF quacking that the data should be interpreted
>as a Q2.12 number? 

>Since we're talking about directional vectors there's no additional
>information in - for example - (-2,0,0) versus (-1,0,0)

It seems this datasheet is saying that the accelerometer is measuring
in units of G's, and that there are modes which set the end-to-end range
of the measurement (2G's, 4G's, or 8G's) and so in fact the binary
point is physical and not purely conceptual.

So in the 4G range case there really are two bits to the left of the 
binary poiint.  And they also seem to consider rounding to a decimal
number to be of value (it looks like, so one can report in
milli-G's.

Steve

> It doesn't.  Only use Q notation if your boss has ordered you to
> do so, if anyone else starts quacking about Q notation tell
> them to go frub a duck.
> 
> 
> (There, got that off my chest.)


Ok :-)

So why is the Freescale PDF quacking that the data should be interpreted as a Q2.12 number? 

Since we're talking about directional vectors there's no additional information in - for example - (-2,0,0) versus (-1,0,0)

I'm sure I'm missing something here...so I'm hoping that somebody in this group can offer some insight to this?

Mauritz Jameson  <mjames2393@gmail.com> wrote:

>I do have one follow-up question.
>
>Since the acquired data is a vector (x,y,z) I don't understand why it
>has to be Q2.12. 

It doesn't.  Only use Q notation if your boss has ordered you to
do so, if anyone else starts quacking about Q notation tell
them to go frub a duck.


(There, got that off my chest.)


S.

I do have one follow-up question.

Since the acquired data is a vector (x,y,z) I don't understand why it has to be Q2.12. Why not just provide a normalized unit vector (length always 1) where each co-ordinate is in Q1.13 format for the direction?

Example:

Provide (-1,0,0) instead of (-2,0,0)

rickman <gnuarm@gmail.com> writes:

> On 8/27/2015 11:59 PM, Randy Yates wrote:
>> Mauritz Jameson <mjames2393@gmail.com> writes:
>>
>>>> This is not right either - the MSB won't be sign-extended. But I think
>>>> this would work:
>>>>
>>>>    double x = ((((int16_t)MSB << 8) | LSB) >> 2) / 4096.0;
>>>>
>>>
>>>
>>> Exactly! You have to shift 8 up to ensure sign extension when you
>>> later shift down by 2. So I guess you agree with me Randy :-)
>>
>> Yes, I do.
>
> Not exactly.  Randy's code converts MSB to a 16 bit quantity first,
> then shifts.  Mauritiz's code shifts then type casts as a 16 bit
> quantity. If MSB is an 8 bit quantity shifting before converting type
> will lose all the data giving a zero value.

Rick,

Yeah, I forgot I did that, and I hadn't thought through the consequences
of MSB being an 8-bit quantity. Good points.
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

> Not exactly.  Randy's code converts MSB to a 16 bit quantity first, then 
> shifts.  Mauritiz's code shifts then type casts as a 16 bit quantity. 
> If MSB is an 8 bit quantity shifting before converting type will lose 
> all the data giving a zero value.
> 
> -- 
> 
> Rick

You are right Rick. What I meant to do is this:

double x = (((((int16_t)MSB) << 8) | LSB) >> 2) / 4096.0;

On 8/27/2015 11:59 PM, Mauritz Jameson wrote:
>>
>> Wow, that is brain-damaged.
>
> Yeah, the description in the PDF is a bit awkward which is why I posted my question in this group (to get some clarification).

I think some people are stuck on the idea that all 16 bits read from the 
converter are data.  The description is not so awkward as far as I can 
tell.

-- 

Rick

On 8/27/2015 11:59 PM, Randy Yates wrote:
> Mauritz Jameson <mjames2393@gmail.com> writes:
>
>>> This is not right either - the MSB won't be sign-extended. But I think
>>> this would work:
>>>
>>>    double x = ((((int16_t)MSB << 8) | LSB) >> 2) / 4096.0;
>>>
>>
>>
>> Exactly! You have to shift 8 up to ensure sign extension when you
>> later shift down by 2. So I guess you agree with me Randy :-)
>
> Yes, I do.

Not exactly.  Randy's code converts MSB to a 16 bit quantity first, then 
shifts.  Mauritiz's code shifts then type casts as a 16 bit quantity. 
If MSB is an 8 bit quantity shifting before converting type will lose 
all the data giving a zero value.

-- 

Rick

On 8/27/2015 9:50 PM, Mauritz Jameson wrote:
>
>> OK, why the >>2?
>>
>> Seems to me that loses the two low order bits.
>> That, combined with the /4096, means 14 bits after the binary point,
>> only 12 of them actually get into x.
>>
>> -- glen
>
>
> The MSB byte has 8 bits of data where the most significant bit is the sign bit.
>
> The LSB byte has 6 bits of data where the most significant bit of those 6 bits is placed at bit 7 (counting from 0).
>
> So the logic behind the C-expression is:
>
> 1. Cast MSB to a 16-bit signed value and shift it up by 8
> 2. OR the LSB with the result of [1]
> 3. Now we have a 14-bit value where the 2 least significant bits are 0 (remember that the LSB only had 6 bits of data)
> 4. So shift the result of [2] down by 2
> 5. Typecast the result of [4] to a double
> 6. Divide by 4096.0 (since it's a Q2.12 value)
>
> Does it make sense?

Yes

-- 

Rick