-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial accelerometer calibration #38
Comments
All sensors need calibration. The accel and gyro in particular need offset
calibration. So lay flat and motionless and collect data. Average the data
and subtract such that the readings in this condition show 0 0 1 for the
accel and 0 0 0 dps for the gyro. The residual is the offset bias that
needs to be subtracted from all subsequent data.
…On Sun, Jan 6, 2019 at 12:06 PM Civilduino ***@***.***> wrote:
Hello Kris!
First of all thank you for your great work and for sharing knowledge so
other can learn!
I am new with the MPU-6050 and I am trying to understand the auto
calibration process that you have implemented. If I understand correctly,
all is based on ideal situations, e.g. the sensor is located with one axis
(z axis) along the gravity vector and other axis having 0g, the sensor have
ideal performance characteristics and is temperature is stable, among
others.
Then if we believe that we positioned the sensor in the ideal position, we
then adjust the measurements by adding offsets to match the ideal case. Is
this what you are doing? is this the same as this
https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/examples/IMU_Zero/IMU_Zero.ino
Can this be called calibration? I am really confuse if it is necessary to
calibrate MEMS accelerometers or if they are adjusted from factory. Could
you please elaborate more on this topic of calibration and what the sensor
is given from factory?
Thank you once again!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#38>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qiUR96b13YKULFQC--AfxK7ug06aks5vAldJgaJpZM4ZylVk>
.
|
I agree that all sensors need calibration. However, this is not a "real" calibration but an offset correction. This method assumes that the surface where the sensor lies is perfectly aligned with the gravity vector and therefore the offset from the readings are subtracted to match the "reality". However, it is extremely difficult to have an ideal surface aligned to the gravity vector. So the true angle with respect to gravity is hard to obtain unless you have expensive equipment or do a more proper calibration. A method of calibration is explained in this paper https://ieeexplore.ieee.org/document/6015525 |
Again, if all you have is an accelerometer you will be very limited in the
accuracy and kinds of orientation estimation you can do. But why not use a
9 DoF sensor and get accurate absolute orientation estimates in all
orientations?
…On Mon, Jan 7, 2019 at 12:42 PM Civilduino ***@***.***> wrote:
I agree that all sensors need calibration. However, this is not a "real"
calibration but an offset correction. This method assumes that the surface
where the sensor lies is perfectly aligned with the gravity vector and
therefore the offset from the readings are subtracted to match the
"reality".
However, it is extremely difficult to have an ideal surface aligned to the
gravity vector. So the true angle with respect to gravity is hard to obtain
unless you have expensive equipment or do a more proper calibration.
A method of calibration is explained in this paper
https://ieeexplore.ieee.org/document/6015525
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qkoUULYF6asvTdpsq0M1NGD6SNX6ks5vA7E_gaJpZM4ZylVk>
.
|
To build on what @Civilduino mentioned, I would also suggest the following approach to gyroscope and acceleration calibration https://github.com/Kyle-ak/imu_tk which I found pretty nice as it did not require much resources in terms of equipment. :) |
Hi Kris, Any communication would be greatly appreciated. |
Huh? Which vendor? Setup for what exactly?
…On Fri, Jul 2, 2021 at 1:09 PM Mike Collins ***@***.***> wrote:
Hi Kris,
Did the vendor ever release some pseudo-code to do an initial setup ?
O am i so late to the game, that it was a pay-to-learn thing initially ?
Any communication would be greatly appreciated.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKSNZDGCZUDQQX4CTVLTVYMHHANCNFSM4GOKKVSA>
.
|
The vendor of mpu6050, TDK I think. Setup for initial calibration / zero-ization (lol) I used your code here and converted/modified to my language of preference (TCL) I'm curious, should i be reading the values from the "normal" registers after this "calibration" ? |
If you want the accel and gyro data then, yes, you need to read it from the
accel and gyro data registers and then properly scale it to get
acceleration in gs or m/s^2 and rotation rate in degrees per sec, etc.
…On Sat, Jul 3, 2021 at 10:44 AM Mike Collins ***@***.***> wrote:
The vendor of mpu6050, TDK I think.
Setup for initial calibration / zero-ization (lol)
I used your code here and converted/modified to my language of preference
(TCL)
I'm curious, should i be reading the values from the "normal" registers
after this "calibration" ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKTY2UE5BQLP7RIWFTLTV5EAZANCNFSM4GOKKVSA>
.
|
Hmmmm, yep am doing so. |
Yes, 0, 0, 1000 mg to within +/- 5 millig or so. And 0, 0, 0 millidegree
per sec to within 10 mdps or so.
How are you using the calibration offsets? These have to be subtracted from
the data, of course....
…On Sat, Jul 3, 2021 at 12:51 PM Mike Collins ***@***.***> wrote:
Hmmmm, yep am doing so.
I calibrate/zeroize, from a standing position, no movement, using the
procedure you created, recoded into TCL,.
And then when i reused my original code reading from the regular registers
I'm still not getting a value (even adjusted) to what i expect.
I would assume that i should have (x:0 y:0 z:1), after calib, when not
moving ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKXU766LRHG7GWGPDFTTV5S33ANCNFSM4GOKKVSA>
.
|
lol, well i believe i am subtracting correctly, lol I had my procedure to perform the calibration, but didn't know it had to be loaded back into the sensor, and rather than try to figure all that out, i used your calib procedure. I only reused mine to get the calibrated values into my own variables. |
Loading the value into sensors offsets, don't cause it to provide more calib/zeroized values ? Hmmm I would've thought that was the whole point, of doing that. |
This is not rocket science. You calculate the offset biases, then these are
either stored in the sketch (or equivalent) or written to the offset bias
registers (but these are volatile, so need to be reloaded at every power
on).
So it is easy to check what the average uncalibrated values are when the
sensor is motionless and flat. It is easy to cmpare the offet biases you
calculate with the average uncalibrated values. So easy to check if
everything is happening as you expect/program.
…On Sat, Jul 3, 2021 at 1:03 PM Mike Collins ***@***.***> wrote:
lol, well i believe i am subtracting correctly, lol
I had my procedure to perform the calibration, but didn't know it had to
be loaded back into the sensor, and rather than try to figure all that out,
i used your calib procedure.
I only reused mine to get the calibrated values into my own variables.
I would rather store the value that you create, and just haven't studied
it out enough, yet, to figure out where they are, and capture them, into my
variables.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKUESXNECVMPI5BQJNLTV5UHLANCNFSM4GOKKVSA>
.
|
Not understanding your question here...
…On Sat, Jul 3, 2021 at 1:05 PM Mike Collins ***@***.***> wrote:
Loading the value into sensors offsets, don't cause it to provide more
calib/zeroized values ?
Hmmm I would've thought that was the whole point, of doing that.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKX6W3CSPX5RCRLUIRTTV5UR3ANCNFSM4GOKKVSA>
.
|
Maybe i'm assuming to much. Is it just a torage location tat is just commonly acceible, or does it actually affect the values the sensor provides ? |
Yea this turned into a whole mouthful for me, smh, lol, sorry. |
You can choose to load the offset bias registers with your calibration
data. In this case, the raw data should include the offset bias. But in my
experience, this doesn;t work well for the accel, so I usually just do this
manually.
On Sat, Jul 3, 2021 at 1:19 PM Mike Collins ***@***.***>
wrote:
… Not understanding your question here...
… <#m_-5220157750711000405_>
On Sat, Jul 3, 2021 at 1:05 PM Mike Collins *@*.***> wrote: Loading the
value into sensors offsets, don't cause it to provide more calib/zeroized
values ? Hmmm I would've thought that was the whole point, of doing that. —
You are receiving this because you commented. Reply to this email directly,
view it on GitHub <#38 (comment)
<#38 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKX6W3CSPX5RCRLUIRTTV5UR3ANCNFSM4GOKKVSA
.
Maybe i'm assuming to much.
I wass thinking the point of storing that in the sensor, somehow adjusted
the values the sensor provides when it is read (from the register).
Is it just a torage location tat is just commonly acceible, or does it
actually affect the values the sensor provides ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKTIPS3EBOX77SKAIP3TV5WG5ANCNFSM4GOKKVSA>
.
|
So in my usage, i'm pretty sure i'm only interested in the accel values ( just movement). |
Don't need to read the gyro then
…On Sat, Jul 3, 2021 at 1:25 PM Mike Collins ***@***.***> wrote:
So in my usage, i'm pretty sure i'm only interested in the accel values (
just movement).
Are those the only registers i need to be reading or do i need gyro as
well and do all the same calculations every time ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKQCHNVAZMIEICVQEDTTV5W5BANCNFSM4GOKKVSA>
.
|
This is my first experience using a motion sensor.
Ok |
Ok |
They shouldn't jump wildly. Maybe your sensor is crap. I would guess a
super cheapo breakout from China or EBay...Probably a fake MPU6050 too...
On Sat, Jul 3, 2021 at 1:31 PM Mike Collins ***@***.***>
wrote:
… This is my first experience using a motion sensor.
I had no idea the values jumped so wildly.
That's when i started searchng about how to calm that down, and got into
this whole calibration discussion, lol.
Probably to be expected.
Don't need to read the gyro then
… <#m_6404295785107076203_>
On Sat, Jul 3, 2021 at 1:25 PM Mike Collins *@*.***> wrote: So in my
usage, i'm pretty sure i'm only interested in the accel values ( just
movement). Are those the only registers i need to be reading or do i need
gyro as well and do all the same calculations every time ? — You are
receiving this because you commented. Reply to this email directly, view it
on GitHub <#38 (comment)
<#38 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKQCHNVAZMIEICVQEDTTV5W5BANCNFSM4GOKKVSA
.
Ok
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKTHMOVLUXGKVM3GLEDTV5XSDANCNFSM4GOKKVSA>
.
|
Ahhh crud. Yea sitting still, the values may jump from positive to negative, its just ridiculous. |
As I mentioned, if you calibrate the accel by subtracting off the offset
bias (average of values while sitting still) you should see 0, 0, 1000
milligs with a jitter of +/- 10 millig, +/- 20 at the most. Said
differently, the uncalibrated jitter should be +/- 10 - 20 millig. If you
average the readings for ~1 second or so and calculate the standard
deviation (use Excel), the deviations shouldn't be more than ~10 -
20 millig. If you do this (and you should) what values do you get for the
average and standard deviation for each axis?
On Sat, Jul 3, 2021 at 1:46 PM Mike Collins ***@***.***>
wrote:
… They shouldn't jump wildly. Maybe your sensor is crap. I would guess a
super cheapo breakout from China or EBay...Probably a fake MPU6050 too...
On Sat, Jul 3, 2021 at 1:31 PM Mike Collins *@*.
*> wrote: … <#m_4641202338694893310_> This is my first experience using a
motion sensor. I had no idea the values jumped so wildly. That's when i
started searchng about how to calm that down, and got into this whole
calibration discussion, lol. Probably to be expected. Don't need to read
the gyro then … <#m_6404295785107076203_> On Sat, Jul 3, 2021 at 1:25 PM
Mike Collins @.*> wrote: So in my usage, i'm pretty sure i'm only
interested in the accel values ( just movement). Are those the only
registers i need to be reading or do i need gyro as well and do all the
same calculations every time ? — You are receiving this because you
commented. Reply to this email directly, view it on GitHub <#38
<#38> (comment) <#38 (comment)
<#38 (comment)>>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKQCHNVAZMIEICVQEDTTV5W5BANCNFSM4GOKKVSA
. Ok — You are receiving this because you commented. Reply to this email
directly, view it on GitHub <#38 (comment)
<#38 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKTHMOVLUXGKVM3GLEDTV5XSDANCNFSM4GOKKVSA
.
Ahhh crud.
Yea sitting still, the values may jump from positive to negative, its just
ridiculous.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKR37XRKPFU2M2CFZH3TV5ZKJANCNFSM4GOKKVSA>
.
|
lol, i don't have great vision, and that craps written so small, i'm not even sure there is something wworthwhile written on it. The other name of the whole sensor is GY-521, are you familiar with that ? |
lol, "great minds, or fools never differ" ,lol, i was just looking at doing a simple deviation but wasn't getting a very good handle on it., yet. I've reverted to reading the raw values to try and figure this out / understand. last thing i was trying was smoothing out the value some, looks like it jumps more than half the maximum +/- value of 32768. Good or bad thing is have more than 1 of the sensors, so i can swap out if they seem to be crappy. I already swapped 1 out first because i thought it was defective reading so wild. |
sounds like you are not doing the 2-s complement conversion properly?
On Sat, Jul 3, 2021 at 2:10 PM Mike Collins ***@***.***>
wrote:
… As I mentioned, if you calibrate the accel by subtracting off the offset
bias (average of values while sitting still) you should see 0, 0, 1000
milligs with a jitter of +/- 10 millig, +/- 20 at the most. Said
differently, the uncalibrated jitter should be +/- 10 - 20 millig. If you
average the readings for ~1 second or so and calculate the standard
deviation (use Excel), the deviations shouldn't be more than ~10 - 20
millig. If you do this (and you should) what values do you get for the
average and standard deviation for each axis? On Sat, Jul 3, 2021 at 1:46
PM Mike Collins *@*.***> wrote:
… <#m_4503423486452604556_>
They shouldn't jump wildly. Maybe your sensor is crap. I would guess a
super cheapo breakout from China or EBay...Probably a fake MPU6050 too...
On Sat, Jul 3, 2021 at 1:31 PM Mike Collins *@*. *> wrote: …
<#m_4641202338694893310_> This is my first experience using a motion
sensor. I had no idea the values jumped so wildly. That's when i started
searchng about how to calm that down, and got into this whole calibration
discussion, lol. Probably to be expected. Don't need to read the gyro then
… <#m_6404295785107076203_> On Sat, Jul 3, 2021 at 1:25 PM Mike Collins @.*>
wrote: So in my usage, i'm pretty sure i'm only interested in the accel
values ( just movement). Are those the only registers i need to be reading
or do i need gyro as well and do all the same calculations every time ? —
You are receiving this because you commented. Reply to this email directly,
view it on GitHub <#38 <#38> <
#38 <#38>> (comment) <#38
<#38> (comment) <#38 (comment)
<#38 (comment)>>>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKQCHNVAZMIEICVQEDTTV5W5BANCNFSM4GOKKVSA
. Ok — You are receiving this because you commented. Reply to this email
directly, view it on GitHub <#38
<#38> (comment) <#38 (comment)
<#38 (comment)>>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKTHMOVLUXGKVM3GLEDTV5XSDANCNFSM4GOKKVSA
. Ahhh crud. Yea sitting still, the values may jump from positive to
negative, its just ridiculous. — You are receiving this because you
commented. Reply to this email directly, view it on GitHub <#38 (comment)
<#38 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKR37XRKPFU2M2CFZH3TV5ZKJANCNFSM4GOKKVSA
.
lol, "great minds, or fools never differ" ,lol, i was just looking at
doing a simple deviation but wasn't getting a very good handle on it., yet.
I've reverted to reading the raw values to try and figure this out /
understand.
last thing i was trying was smoothing out the value some, looks like it
jumps more than half the maximum +/- value of 32768.
Is that ridiculous, or just fairly normal, i have no frame of refernce.
Good or bad thing is have more than 1 of the sensors, so i can swap out if
they seem to be crappy.
Problem is i got them all off Ebay, so they all probably crappy.
I already swapped 1 out first because i thought it was defective reading
so wild.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKR7PI75FWMA6HKJYI3TV54E3ANCNFSM4GOKKVSA>
.
|
So thats an intersting comment about the reading time. I couldn't find even great refernce to what is good sampling time. I did find 1 routine "suggestion" to read 1100 samples every 100ms (or something like that, then thwout the first 100, and calcutlate the rest. Hasn't helped :( |
Set the sample rate to 200 Hz, the LP filter to 42 Hz and the full scale
range to 2 g. Forget about calibration for now...
What is the average and standard deviation of the three axes when the
sensor lies motionless and flat?
…On Sat, Jul 3, 2021 at 2:15 PM Mike Collins ***@***.***> wrote:
So thats an intersting comment about the reading time.
I couldn't find even great refernce to what is good sampling time.
I did find 1 routine "suggestion" to read 1100 samples every 100ms (or
something like that, then thwout the first 100, and calcutlate the rest.
Hasn't helped :(
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKS3PGTQDMBTCXBHPULTV54W7ANCNFSM4GOKKVSA>
.
|
2s compliment, is that reading the *OUT_H and then left shifting ? Or is there another calculation i missed in there ? |
so what does 200 hz turn into with TCL delays ? Are you familiar with TCL ? I had not done anything with LP filter, before getting closer to your calib. And why does full-scale range seem to be backwards for me, lol ? |
The raw sensor data is two bytes per axis which needs to be combined to
make a signed 16-bit integer, i.e., stored as 2's complement.
So a signed value that fluctuates a bit about zero will look like wild
swings in the data if not handled properly.
On Sat, Jul 3, 2021 at 2:27 PM Mike Collins ***@***.***>
wrote:
… sounds like you are not doing the 2-s complement conversion properly? On
Sat, Jul 3, 2021 at 2:10 PM Mike Collins *@*.
*> wrote: … <#m_6879422066615639933_> As I mentioned, if you calibrate the
accel by subtracting off the offset bias (average of values while sitting
still) you should see 0, 0, 1000 milligs with a jitter of +/- 10 millig,
+/- 20 at the most. Said differently, the uncalibrated jitter should be +/-
10 - 20 millig. If you average the readings for ~1 second or so and
calculate the standard deviation (use Excel), the deviations shouldn't be
more than ~10 - 20 millig. If you do this (and you should) what values do
you get for the average and standard deviation for each axis? On Sat, Jul
3, 2021 at 1:46 PM Mike Collins @.*> wrote: … <#m_4503423486452604556_>
They shouldn't jump wildly. Maybe your sensor is crap. I would guess a
super cheapo breakout from China or EBay...Probably a fake MPU6050 too...
On Sat, Jul 3, 2021 at 1:31 PM Mike Collins *@*. *> wrote: …
<#m_4641202338694893310_> This is my first experience using a motion
sensor. I had no idea the values jumped so wildly. That's when i started
searchng about how to calm that down, and got into this whole calibration
discussion, lol. Probably to be expected. Don't need to read the gyro then
… <#m_6404295785107076203_> On Sat, Jul 3, 2021 at 1:25 PM Mike Collins @.*>
wrote: So in my usage, i'm pretty sure i'm only interested in the accel
values ( just movement). Are those the only registers i need to be reading
or do i need gyro as well and do all the same calculations every time ? —
You are receiving this because you commented. Reply to this email directly,
view it on GitHub <#38 <#38> <
#38 <#38>> < #38
<#38> <#38
<#38>>> (comment) <#38
<#38> <#38
<#38>> (comment) <#38
<#38> (comment) <#38 (comment)
<#38 (comment)>>>>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKQCHNVAZMIEICVQEDTTV5W5BANCNFSM4GOKKVSA
. Ok — You are receiving this because you commented. Reply to this email
directly, view it on GitHub <#38
<#38> <#38
<#38>> (comment) <#38
<#38> (comment) <#38 (comment)
<#38 (comment)>>>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKTHMOVLUXGKVM3GLEDTV5XSDANCNFSM4GOKKVSA
. Ahhh crud. Yea sitting still, the values may jump from positive to
negative, its just ridiculous. — You are receiving this because you
commented. Reply to this email directly, view it on GitHub <#38
<#38> (comment) <#38 (comment)
<#38 (comment)>>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKR37XRKPFU2M2CFZH3TV5ZKJANCNFSM4GOKKVSA
. lol, "great minds, or fools never differ" ,lol, i was just looking at
doing a simple deviation but wasn't getting a very good handle on it., yet.
I've reverted to reading the raw values to try and figure this out /
understand. last thing i was trying was smoothing out the value some, looks
like it jumps more than half the maximum +/- value of 32768. Is that
ridiculous, or just fairly normal, i have no frame of refernce. Good or bad
thing is have more than 1 of the sensors, so i can swap out if they seem to
be crappy. Problem is i got them all off Ebay, so they all probably crappy.
I already swapped 1 out first because i thought it was defective reading so
wild. — You are receiving this because you commented. Reply to this email
directly, view it on GitHub <#38 (comment)
<#38 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKR7PI75FWMA6HKJYI3TV54E3ANCNFSM4GOKKVSA
.
2s compliment, is that reading the *OUT_H and then left shifting ?
Or is there another calculation i missed in there ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKWMY3GYSL7JDZ2C7RTTV56CLANCNFSM4GOKKVSA>
.
|
Yea i think i finally understood that too, and have it in 1 of my read functions. I can see when i move my sensor through the range of motion i want to deal with, it goes from a postive in 1 direction and negative the other.
|
|
Hi Kris. You will notice some of the variable names are basically the same as in your library, so won't be hard to see what some values are. After you asked about std deviation, i went looking for a TCL package thst provided some of those functions. And they are captured in the TCL "array" named after the axis. Since i hadn't got this to work, sort of after main recoding, i'm only testing with 1 axis at this poiunt, dealing with all 3 when just 1 doesn't work, just seems silly, to me. ` gyro_bias is array: inList is dict: inList is dict: inList is dict: accel_bias is array: gyro_bias is array: accel_bias is array: gyro_bias is array: wdata is array: cmd="twowire writeregbyte twowire5 0x13 0xc0" mask_bit is array: accel_bias_reg is array: Ax is array: |
Ax(min) =65182.0
This is not properly cast in 2's complement.
65182 is 0xFE9E, which is a very small negative number.
…On Mon, Jul 5, 2021 at 10:56 AM Mike Collins ***@***.***> wrote:
Hi Kris.
Well i had to backup a little bit and add some additional debuging info
capture, and here's what i have.
You will notice some of the variable names are basically the same as in
your library, so won't be hard to see what some values are.
After you asked about std deviation, i went looking for a TCL package thst
provided some of those functions. And they are captured in the TCL "array"
named after the axis. Since i hadn't got this to work, sort of after main
recoding, i'm only testing with 1 axis at this poiunt, dealing with all 3
when just 1 doesn't work, just seems silly, to me.
`
cmd="twowire writeregbyte twowire5 0x6B 0x80"
cmd="twowire writeregbyte twowire5 0x6B 0x01"
cmd="twowire writeregbyte twowire5 0x6C 0x00"
cmd="twowire writeregbyte twowire5 0x38 0x00"
cmd="twowire writeregbyte twowire5 0x23 0x00"
cmd="twowire writeregbyte twowire5 0x6B 0x00"
cmd="twowire writeregbyte twowire5 0x24 0x00"
cmd="twowire writeregbyte twowire5 0x6A 0x00"
cmd="twowire writeregbyte twowire5 0x6A 0x0C"
cmd="twowire writeregbyte twowire5 0x1A 0x01"
cmd="twowire writeregbyte twowire5 0x19 0x00"
cmd="twowire writeregbyte twowire5 0x1B 0x00"
cmd="twowire writeregbyte twowire5 0x1C 0x00"
cmd="twowire writeregbyte twowire5 0x6A 0x40"
cmd="twowire writeregbyte twowire5 0x23 0x78"
cmd="twowire writeregbyte twowire5 0x23 0x00"
fifo_count="1024"
packet_count="85"
accel_bias is array:
accel_bias(0) =5542251
accel_bias(1) =5566359
accel_bias(2) =5465702
gyro_bias is array:
gyro_bias(0) =5513694
gyro_bias(1) =1404804
gyro_bias(2) =5546861
inList is dict:
mean min max count stdev sampvar popstdev popvar
inList is dict:
mean min max count stdev sampvar popstdev popvar
inList is dict:
mean min max count stdev sampvar popstdev popvar
accel_bias is array:
accel_bias(0) =65202
accel_bias(1) =65486
accel_bias(2) =64302
gyro_bias is array:
gyro_bias(0) =64866
gyro_bias(1) =16527
gyro_bias(2) =65257
accel_bias is array:
accel_bias(0) =65202
accel_bias(1) =65486
accel_bias(2) =47918
gyro_bias is array:
gyro_bias(0) =64866
gyro_bias(1) =16527
gyro_bias(2) =65257
wdata is array:
wdata(0) =192
wdata(1) =167
wdata(2) =239
wdata(3) =220
wdata(4) =192
wdata(5) =69
cmd="twowire writeregbyte twowire5 0x13 0xc0"
cmd="twowire writeregbyte twowire5 0x14 0xa7"
cmd="twowire writeregbyte twowire5 0x15 0xef"
cmd="twowire writeregbyte twowire5 0x16 0xdc"
cmd="twowire writeregbyte twowire5 0x17 0xc0"
cmd="twowire writeregbyte twowire5 0x18 0x45"
accel_bias_reg is array:
accel_bias_reg(0) =-1100
accel_bias_reg(1) =-355
accel_bias_reg(2) =1990
mask_bit is array:
mask_bit(0) =0x0
mask_bit(1) =0x01
accel_bias_reg is array:
accel_bias_reg(0) =-9250
accel_bias_reg(1) =-8540
accel_bias_reg(2) =-3999
Ax is array:
Ax(bias) =5542251
Ax(breg) =-9250
Ax(calb) =3
Ax(count) =85
Ax(data) ={65202.95294117647 65182.0 65229.0 85 10.867060191188253
118.09299719890848 10.802947182139594 116.70366782009779}
Ax(dbias) =65202
Ax(max) =65229.0
Ax(mean) =65202.95294117647
Ax(min) =65182.0
Ax(popstdev) =10.802947182139594
Ax(popvar) =116.70366782009779
Ax(sampvar) =118.09299719890848
Ax(stdev) =10.867060191188253
`
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKSYM6P77TN7XXSFKNDTWHW4VANCNFSM4GOKKVSA>
.
|
That's very possible. |
~ -60 milligs or something like this at 2 g FS, typical and easily
corrected offset bias....
On Mon, Jul 5, 2021 at 11:21 AM Mike Collins ***@***.***>
wrote:
… Ax(min) =65182.0 This is not properly cast in 2's complement. 65182 is
0xFE9E, which is a very small negative number.
… <#m_-4677973895798972836_>
On Mon, Jul 5, 2021 at 10:56 AM Mike Collins *@*.***> wrote: Hi Kris.
Well i had to backup a little bit and add some additional debuging info
capture, and here's what i have. You will notice some of the variable names
are basically the same as in your library, so won't be hard to see what
some values are. After you asked about std deviation, i went looking for a
TCL package thst provided some of those functions. And they are captured in
the TCL "array" named after the axis. Since i hadn't got this to work, sort
of after main recoding, i'm only testing with 1 axis at this poiunt,
dealing with all 3 when just 1 doesn't work, just seems silly, to me. cmd="twowire
writeregbyte twowire5 0x6B 0x80" cmd="twowire writeregbyte twowire5 0x6B
0x01" cmd="twowire writeregbyte twowire5 0x6C 0x00" cmd="twowire
writeregbyte twowire5 0x38 0x00" cmd="twowire writeregbyte twowire5 0x23
0x00" cmd="twowire writeregbyte twowire5 0x6B 0x00" cmd="twowire
writeregbyte twowire5 0x24 0x00" cmd="twowire writeregbyte twowire5 0x6A
0x00" cmd="twowire writeregbyte twowire5 0x6A 0x0C" cmd="twowire
writeregbyte twowire5 0x1A 0x01" cmd="twowire writeregbyte twowire5 0x19
0x00" cmd="twowire writeregbyte twowire5 0x1B 0x00" cmd="twowire
writeregbyte twowire5 0x1C 0x00" cmd="twowire writeregbyte twowire5 0x6A
0x40" cmd="twowire writeregbyte twowire5 0x23 0x78" cmd="twowire
writeregbyte twowire5 0x23 0x00" fifo_count="1024" packet_count="85"
accel_bias is array: accel_bias(0) =5542251 accel_bias(1) =5566359
accel_bias(2) =5465702 gyro_bias is array: gyro_bias(0) =5513694
gyro_bias(1) =1404804 gyro_bias(2) =5546861 inList is dict: mean min max
count stdev sampvar popstdev popvar inList is dict: mean min max count
stdev sampvar popstdev popvar inList is dict: mean min max count stdev
sampvar popstdev popvar accel_bias is array: accel_bias(0) =65202
accel_bias(1) =65486 accel_bias(2) =64302 gyro_bias is array: gyro_bias(0)
=64866 gyro_bias(1) =16527 gyro_bias(2) =65257 accel_bias is array:
accel_bias(0) =65202 accel_bias(1) =65486 accel_bias(2) =47918 gyro_bias is
array: gyro_bias(0) =64866 gyro_bias(1) =16527 gyro_bias(2) =65257 wdata is
array: wdata(0) =192 wdata(1) =167 wdata(2) =239 wdata(3) =220 wdata(4)
=192 wdata(5) =69 cmd="twowire writeregbyte twowire5 0x13 0xc0"
cmd="twowire writeregbyte twowire5 0x14 0xa7" cmd="twowire writeregbyte
twowire5 0x15 0xef" cmd="twowire writeregbyte twowire5 0x16 0xdc"
cmd="twowire writeregbyte twowire5 0x17 0xc0" cmd="twowire writeregbyte
twowire5 0x18 0x45" accel_bias_reg is array: accel_bias_reg(0) =-1100
accel_bias_reg(1) =-355 accel_bias_reg(2) =1990 mask_bit is array:
mask_bit(0) =0x0 mask_bit(1) =0x01 accel_bias_reg is array:
accel_bias_reg(0) =-9250 accel_bias_reg(1) =-8540 accel_bias_reg(2) =-3999
Ax is array: Ax(bias) =5542251 Ax(breg) =-9250 Ax(calb) =3 Ax(count) =85
Ax(data) ={65202.95294117647 65182.0 65229.0 85 10.867060191188253
118.09299719890848 10.802947182139594 116.70366782009779} Ax(dbias) =65202
Ax(max) =65229.0 Ax(mean) =65202.95294117647 Ax(min) =65182.0 Ax(popstdev)
=10.802947182139594 Ax(popvar) =116.70366782009779 Ax(sampvar)
=118.09299719890848 Ax(stdev) =10.867060191188253 — You are receiving
this because you commented. Reply to this email directly, view it on GitHub
<#38 (comment)
<#38 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKSYM6P77TN7XXSFKNDTWHW4VANCNFSM4GOKKVSA
.
That's very possible.
The raw value that i initially see is something like -1012 ( or something
like that)
I guess "small" is relative, and i would hope its something close to zero.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKTLRH6RVMFN7CG636TTWHZY3ANCNFSM4GOKKVSA>
.
|
Hmmmm, so when do the values get changed to +/- 32768 ? I mean it's so close right now ? |
In C++ (no idea what TCL is) one converts two 8-bit bytes into one signed
16-bit integer like this:
uint8_t rawData[2] = {0, 0};
readData(rawData); // function to read data
int16_t output = (int16_t) ( (int16_t) rawData[1] << 8) | rawData[0];
This takes advantage of a trick or built in functionality of C++ in that
the compiler knows that a 16-bit integer (int16_t) is signed so does the
proper conversion.
The old school way to do this is to form the uint16_t combination of the
rawData and then test for a 1 in the 15th bit position. So:
if(output & 0x8000)
{
output = ~output + 1;
output = - output;
}
so that 0xFFFF would become -1, the smallest negative value for 16-bit
signed data. . 0x7FFF would be +32767, the maximum positive value for
16-bit signed data.
https://www.exploringbinary.com/twos-complement-converter/
google twos complement conversion
On Mon, Jul 5, 2021 at 3:20 PM Mike Collins ***@***.***>
wrote:
… ~ -60 milligs or something like this at 2 g FS, typical and easily
corrected offset bias.... On Mon, Jul 5, 2021 at 11:21 AM Mike Collins *@*
.
*> wrote: … <#m_-8435496152261155125_> Ax(min) =65182.0 This is not
properly cast in 2's complement. 65182 is 0xFE9E, which is a very small
negative number. … <#m_-4677973895798972836_> On Mon, Jul 5, 2021 at 10:56
AM Mike Collins @.*> wrote: Hi Kris. Well i had to backup a little bit
and add some additional debuging info capture, and here's what i have. You
will notice some of the variable names are basically the same as in your
library, so won't be hard to see what some values are. After you asked
about std deviation, i went looking for a TCL package thst provided some of
those functions. And they are captured in the TCL "array" named after the
axis. Since i hadn't got this to work, sort of after main recoding, i'm
only testing with 1 axis at this poiunt, dealing with all 3 when just 1
doesn't work, just seems silly, to me. cmd="twowire writeregbyte twowire5
0x6B 0x80" cmd="twowire writeregbyte twowire5 0x6B 0x01" cmd="twowire
writeregbyte twowire5 0x6C 0x00" cmd="twowire writeregbyte twowire5 0x38
0x00" cmd="twowire writeregbyte twowire5 0x23 0x00" cmd="twowire
writeregbyte twowire5 0x6B 0x00" cmd="twowire writeregbyte twowire5 0x24
0x00" cmd="twowire writeregbyte twowire5 0x6A 0x00" cmd="twowire
writeregbyte twowire5 0x6A 0x0C" cmd="twowire writeregbyte twowire5 0x1A
0x01" cmd="twowire writeregbyte twowire5 0x19 0x00" cmd="twowire
writeregbyte twowire5 0x1B 0x00" cmd="twowire writeregbyte twowire5 0x1C
0x00" cmd="twowire writeregbyte twowire5 0x6A 0x40" cmd="twowire
writeregbyte twowire5 0x23 0x78" cmd="twowire writeregbyte twowire5 0x23
0x00" fifo_count="1024" packet_count="85" accel_bias is array:
accel_bias(0) =5542251 accel_bias(1) =5566359 accel_bias(2) =5465702
gyro_bias is array: gyro_bias(0) =5513694 gyro_bias(1) =1404804
gyro_bias(2) =5546861 inList is dict: mean min max count stdev sampvar
popstdev popvar inList is dict: mean min max count stdev sampvar popstdev
popvar inList is dict: mean min max count stdev sampvar popstdev popvar
accel_bias is array: accel_bias(0) =65202 accel_bias(1) =65486
accel_bias(2) =64302 gyro_bias is array: gyro_bias(0) =64866 gyro_bias(1)
=16527 gyro_bias(2) =65257 accel_bias is array: accel_bias(0) =65202
accel_bias(1) =65486 accel_bias(2) =47918 gyro_bias is array: gyro_bias(0)
=64866 gyro_bias(1) =16527 gyro_bias(2) =65257 wdata is array: wdata(0)
=192 wdata(1) =167 wdata(2) =239 wdata(3) =220 wdata(4) =192 wdata(5) =69
cmd="twowire writeregbyte twowire5 0x13 0xc0" cmd="twowire writeregbyte
twowire5 0x14 0xa7" cmd="twowire writeregbyte twowire5 0x15 0xef"
cmd="twowire writeregbyte twowire5 0x16 0xdc" cmd="twowire writeregbyte
twowire5 0x17 0xc0" cmd="twowire writeregbyte twowire5 0x18 0x45"
accel_bias_reg is array: accel_bias_reg(0) =-1100 accel_bias_reg(1) =-355
accel_bias_reg(2) =1990 mask_bit is array: mask_bit(0) =0x0 mask_bit(1)
=0x01 accel_bias_reg is array: accel_bias_reg(0) =-9250 accel_bias_reg(1)
=-8540 accel_bias_reg(2) =-3999 Ax is array: Ax(bias) =5542251 Ax(breg)
=-9250 Ax(calb) =3 Ax(count) =85 Ax(data) ={65202.95294117647 65182.0
65229.0 85 10.867060191188253 118.09299719890848 10.802947182139594
116.70366782009779} Ax(dbias) =65202 Ax(max) =65229.0 Ax(mean)
=65202.95294117647 Ax(min) =65182.0 Ax(popstdev) =10.802947182139594
Ax(popvar) =116.70366782009779 Ax(sampvar) =118.09299719890848 Ax(stdev)
=10.867060191188253 — You are receiving this because you commented. Reply
to this email directly, view it on GitHub <#38
<#38> (comment) <#38 (comment)
<#38 (comment)>>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKSYM6P77TN7XXSFKNDTWHW4VANCNFSM4GOKKVSA
. That's very possible. The raw value that i initially see is something
like -1012 ( or something like that) I guess "small" is relative, and i
would hope its something close to zero. — You are receiving this because
you commented. Reply to this email directly, view it on GitHub <#38
(comment)
<#38 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKTLRH6RVMFN7CG636TTWHZY3ANCNFSM4GOKKVSA
.
Hmmmm, so when do the values get changed to +/- 32768 ?
I mean it's so close right now ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKR73WNUHMX4AUMC27LTWIV3FANCNFSM4GOKKVSA>
.
|
Yep, i showed you that earlier in the thread.
|
Does this manage twos complement conversion correctly?
On Mon, Jul 5, 2021 at 6:12 PM Mike Collins ***@***.***>
wrote:
… In C++ (no idea what TCL is) one converts two 8-bit bytes into one signed
16-bit integer like this: uint8_t rawData[2] = {0, 0}; readData(rawData);
// function to read data int16_t output = (int16_t) ( (int16_t) rawData[1]
<< 8) | rawData[0]; This takes advantage of a trick or built in
functionality of C++ in that the compiler knows that a 16-bit integer
(int16_t) is signed so does the proper conversion. The old school way to do
this is to form the uint16_t combination of the rawData and then test for a
1 in the 15th bit position. So: if(output & 0x8000) { output = ~output + 1;
output = - output; } so that 0xFFFF would become -1, the smallest negative
value for 16-bit signed data. . 0x7FFF would be +32767, the maximum
positive value for 16-bit signed data.
https://www.exploringbinary.com/twos-complement-converter/ google twos
complement conversion On Mon, Jul 5, 2021 at 3:20 PM Mike Collins *@*.***>
wrote:
… <#m_-8533214321366424106_>
~ -60 milligs or something like this at 2 g FS, typical and easily
corrected offset bias.... On Mon, Jul 5, 2021 at 11:21 AM Mike Collins *@*
. *> wrote: … <#m_-8435496152261155125_> Ax(min) =65182.0 This is not
properly cast in 2's complement. 65182 is 0xFE9E, which is a very small
negative number. … <#m_-4677973895798972836_> On Mon, Jul 5, 2021 at 10:56
AM Mike Collins @.*> wrote: Hi Kris. Well i had to backup a little bit
and add some additional debuging info capture, and here's what i have. You
will notice some of the variable names are basically the same as in your
library, so won't be hard to see what some values are. After you asked
about std deviation, i went looking for a TCL package thst provided some of
those functions. And they are captured in the TCL "array" named after the
axis. Since i hadn't got this to work, sort of after main recoding, i'm
only testing with 1 axis at this poiunt, dealing with all 3 when just 1
doesn't work, just seems silly, to me. cmd="twowire writeregbyte twowire5
0x6B 0x80" cmd="twowire writeregbyte twowire5 0x6B 0x01" cmd="twowire
writeregbyte twowire5 0x6C 0x00" cmd="twowire writeregbyte twowire5 0x38
0x00" cmd="twowire writeregbyte twowire5 0x23 0x00" cmd="twowire
writeregbyte twowire5 0x6B 0x00" cmd="twowire writeregbyte twowire5 0x24
0x00" cmd="twowire writeregbyte twowire5 0x6A 0x00" cmd="twowire
writeregbyte twowire5 0x6A 0x0C" cmd="twowire writeregbyte twowire5 0x1A
0x01" cmd="twowire writeregbyte twowire5 0x19 0x00" cmd="twowire
writeregbyte twowire5 0x1B 0x00" cmd="twowire writeregbyte twowire5 0x1C
0x00" cmd="twowire writeregbyte twowire5 0x6A 0x40" cmd="twowire
writeregbyte twowire5 0x23 0x78" cmd="twowire writeregbyte twowire5 0x23
0x00" fifo_count="1024" packet_count="85" accel_bias is array:
accel_bias(0) =5542251 accel_bias(1) =5566359 accel_bias(2) =5465702
gyro_bias is array: gyro_bias(0) =5513694 gyro_bias(1) =1404804
gyro_bias(2) =5546861 inList is dict: mean min max count stdev sampvar
popstdev popvar inList is dict: mean min max count stdev sampvar popstdev
popvar inList is dict: mean min max count stdev sampvar popstdev popvar
accel_bias is array: accel_bias(0) =65202 accel_bias(1) =65486
accel_bias(2) =64302 gyro_bias is array: gyro_bias(0) =64866 gyro_bias(1)
=16527 gyro_bias(2) =65257 accel_bias is array: accel_bias(0) =65202
accel_bias(1) =65486 accel_bias(2) =47918 gyro_bias is array: gyro_bias(0)
=64866 gyro_bias(1) =16527 gyro_bias(2) =65257 wdata is array: wdata(0)
=192 wdata(1) =167 wdata(2) =239 wdata(3) =220 wdata(4) =192 wdata(5) =69
cmd="twowire writeregbyte twowire5 0x13 0xc0" cmd="twowire writeregbyte
twowire5 0x14 0xa7" cmd="twowire writeregbyte twowire5 0x15 0xef"
cmd="twowire writeregbyte twowire5 0x16 0xdc" cmd="twowire writeregbyte
twowire5 0x17 0xc0" cmd="twowire writeregbyte twowire5 0x18 0x45"
accel_bias_reg is array: accel_bias_reg(0) =-1100 accel_bias_reg(1) =-355
accel_bias_reg(2) =1990 mask_bit is array: mask_bit(0) =0x0 mask_bit(1)
=0x01 accel_bias_reg is array: accel_bias_reg(0) =-9250 accel_bias_reg(1)
=-8540 accel_bias_reg(2) =-3999 Ax is array: Ax(bias) =5542251 Ax(breg)
=-9250 Ax(calb) =3 Ax(count) =85 Ax(data) ={65202.95294117647 65182.0
65229.0 85 10.867060191188253 118.09299719890848 10.802947182139594
116.70366782009779} Ax(dbias) =65202 Ax(max) =65229.0 Ax(mean)
=65202.95294117647 Ax(min) =65182.0 Ax(popstdev) =10.802947182139594
Ax(popvar) =116.70366782009779 Ax(sampvar) =118.09299719890848 Ax(stdev)
=10.867060191188253 — You are receiving this because you commented. Reply
to this email directly, view it on GitHub <#38
<#38> <#38
<#38>> (comment) <#38
<#38> (comment) <#38 (comment)
<#38 (comment)>>>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKSYM6P77TN7XXSFKNDTWHW4VANCNFSM4GOKKVSA
. That's very possible. The raw value that i initially see is something
like -1012 ( or something like that) I guess "small" is relative, and i
would hope its something close to zero. — You are receiving this because
you commented. Reply to this email directly, view it on GitHub <#38
<#38> (comment) <#38 (comment)
<#38 (comment)>>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKTLRH6RVMFN7CG636TTWHZY3ANCNFSM4GOKKVSA
. Hmmmm, so when do the values get changed to +/- 32768 ? I mean it's so
close right now ? — You are receiving this because you commented. Reply to
this email directly, view it on GitHub <#38 (comment)
<#38 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKR73WNUHMX4AUMC27LTWIV3FANCNFSM4GOKKVSA
.
Yep, i showed you that earlier in the thread.
#concatenate higher and lower value
set value [expr {($high << 8) | $low}]
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKQ3NUGO6G2ZU4UJQTDTWJKA3ANCNFSM4GOKKVSA>
.
|
Far as i know. i mean its the same functionality, left shifting 8 bits, and then OR'ing the other bits in their normal positions. |
Nope...likely does not handle two's complement properly. Suggest you check,
and if not, do it manually.
On Mon, Jul 5, 2021 at 7:30 PM Mike Collins ***@***.***>
wrote:
… Does this manage twos complement conversion correctly? On Mon, Jul 5, 2021
at 6:12 PM Mike Collins *@*.
*> wrote: … <#m_3261014820833263279_> In C++ (no idea what TCL is) one
converts two 8-bit bytes into one signed 16-bit integer like this: uint8_t
rawData[2] = {0, 0}; readData(rawData); // function to read data int16_t
output = (int16_t) ( (int16_t) rawData[1] << 8) | rawData[0]; This takes
advantage of a trick or built in functionality of C++ in that the compiler
knows that a 16-bit integer (int16_t) is signed so does the proper
conversion. The old school way to do this is to form the uint16_t
combination of the rawData and then test for a 1 in the 15th bit position.
So: if(output & 0x8000) { output = ~output + 1; output = - output; } so
that 0xFFFF would become -1, the smallest negative value for 16-bit signed
data. . 0x7FFF would be +32767, the maximum positive value for 16-bit
signed data. https://www.exploringbinary.com/twos-complement-converter/
<https://www.exploringbinary.com/twos-complement-converter/> google twos
complement conversion On Mon, Jul 5, 2021 at 3:20 PM Mike Collins @.*>
wrote: … <#m_-8533214321366424106_> ~ -60 milligs or something like this at
2 g FS, typical and easily corrected offset bias.... On Mon, Jul 5, 2021 at
11:21 AM Mike Collins *@* . *> wrote: … <#m_-8435496152261155125_>
Ax(min) =65182.0 This is not properly cast in 2's complement. 65182 is
0xFE9E, which is a very small negative number. … <#m_-4677973895798972836_>
On Mon, Jul 5, 2021 at 10:56 AM Mike Collins @.*> wrote: Hi Kris. Well i
had to backup a little bit and add some additional debuging info capture,
and here's what i have. You will notice some of the variable names are
basically the same as in your library, so won't be hard to see what some
values are. After you asked about std deviation, i went looking for a TCL
package thst provided some of those functions. And they are captured in the
TCL "array" named after the axis. Since i hadn't got this to work, sort of
after main recoding, i'm only testing with 1 axis at this poiunt, dealing
with all 3 when just 1 doesn't work, just seems silly, to me. cmd="twowire
writeregbyte twowire5 0x6B 0x80" cmd="twowire writeregbyte twowire5 0x6B
0x01" cmd="twowire writeregbyte twowire5 0x6C 0x00" cmd="twowire
writeregbyte twowire5 0x38 0x00" cmd="twowire writeregbyte twowire5 0x23
0x00" cmd="twowire writeregbyte twowire5 0x6B 0x00" cmd="twowire
writeregbyte twowire5 0x24 0x00" cmd="twowire writeregbyte twowire5 0x6A
0x00" cmd="twowire writeregbyte twowire5 0x6A 0x0C" cmd="twowire
writeregbyte twowire5 0x1A 0x01" cmd="twowire writeregbyte twowire5 0x19
0x00" cmd="twowire writeregbyte twowire5 0x1B 0x00" cmd="twowire
writeregbyte twowire5 0x1C 0x00" cmd="twowire writeregbyte twowire5 0x6A
0x40" cmd="twowire writeregbyte twowire5 0x23 0x78" cmd="twowire
writeregbyte twowire5 0x23 0x00" fifo_count="1024" packet_count="85"
accel_bias is array: accel_bias(0) =5542251 accel_bias(1) =5566359
accel_bias(2) =5465702 gyro_bias is array: gyro_bias(0) =5513694
gyro_bias(1) =1404804 gyro_bias(2) =5546861 inList is dict: mean min max
count stdev sampvar popstdev popvar inList is dict: mean min max count
stdev sampvar popstdev popvar inList is dict: mean min max count stdev
sampvar popstdev popvar accel_bias is array: accel_bias(0) =65202
accel_bias(1) =65486 accel_bias(2) =64302 gyro_bias is array: gyro_bias(0)
=64866 gyro_bias(1) =16527 gyro_bias(2) =65257 accel_bias is array:
accel_bias(0) =65202 accel_bias(1) =65486 accel_bias(2) =47918 gyro_bias is
array: gyro_bias(0) =64866 gyro_bias(1) =16527 gyro_bias(2) =65257 wdata is
array: wdata(0) =192 wdata(1) =167 wdata(2) =239 wdata(3) =220 wdata(4)
=192 wdata(5) =69 cmd="twowire writeregbyte twowire5 0x13 0xc0"
cmd="twowire writeregbyte twowire5 0x14 0xa7" cmd="twowire writeregbyte
twowire5 0x15 0xef" cmd="twowire writeregbyte twowire5 0x16 0xdc"
cmd="twowire writeregbyte twowire5 0x17 0xc0" cmd="twowire writeregbyte
twowire5 0x18 0x45" accel_bias_reg is array: accel_bias_reg(0) =-1100
accel_bias_reg(1) =-355 accel_bias_reg(2) =1990 mask_bit is array:
mask_bit(0) =0x0 mask_bit(1) =0x01 accel_bias_reg is array:
accel_bias_reg(0) =-9250 accel_bias_reg(1) =-8540 accel_bias_reg(2) =-3999
Ax is array: Ax(bias) =5542251 Ax(breg) =-9250 Ax(calb) =3 Ax(count) =85
Ax(data) ={65202.95294117647 65182.0 65229.0 85 10.867060191188253
118.09299719890848 10.802947182139594 116.70366782009779} Ax(dbias) =65202
Ax(max) =65229.0 Ax(mean) =65202.95294117647 Ax(min) =65182.0 Ax(popstdev)
=10.802947182139594 Ax(popvar) =116.70366782009779 Ax(sampvar)
=118.09299719890848 Ax(stdev) =10.867060191188253 — You are receiving this
because you commented. Reply to this email directly, view it on GitHub <
#38 <#38> <#38
<#38>> <#38
<#38> <#38
<#38>>> (comment) <#38
<#38> <#38
<#38>> (comment) <#38
<#38> (comment) <#38 (comment)
<#38 (comment)>>>>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKSYM6P77TN7XXSFKNDTWHW4VANCNFSM4GOKKVSA
. That's very possible. The raw value that i initially see is something
like -1012 ( or something like that) I guess "small" is relative, and i
would hope its something close to zero. — You are receiving this because
you commented. Reply to this email directly, view it on GitHub <#38
<#38> <#38
<#38>> (comment) <#38
<#38> (comment) <#38 (comment)
<#38 (comment)>>>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKTLRH6RVMFN7CG636TTWHZY3ANCNFSM4GOKKVSA
. Hmmmm, so when do the values get changed to +/- 32768 ? I mean it's so
close right now ? — You are receiving this because you commented. Reply to
this email directly, view it on GitHub <#38
<#38> (comment) <#38 (comment)
<#38 (comment)>>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKR73WNUHMX4AUMC27LTWIV3FANCNFSM4GOKKVSA
. Yep, i showed you that earlier in the thread. #concatenate higher and
lower value set value [expr {($high << 8) | $low}] — You are receiving this
because you commented. Reply to this email directly, view it on GitHub <#38
(comment)
<#38 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKQ3NUGO6G2ZU4UJQTDTWJKA3ANCNFSM4GOKKVSA
.
Far as i know.
I don't use it ALL the time, but never had any problem, when i did.
i mean its the same functionality, left shifting 8 bits, and then OR'ing
the other bits in their normal positions.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKSJLFNUUJ7YMJAQLP3TWJTDJANCNFSM4GOKKVSA>
.
|
Really Kris ? TCL is a major scripting language, you think they wouldn't support that capability ? Thanks. |
You can assume, or just check that it works. But you are right, if you
can't be bothered to simply verify then you should ask someone else for
help.
On Mon, Jul 5, 2021 at 8:56 PM Mike Collins ***@***.***>
wrote:
… Nope...likely does not handle two's complement properly. Suggest you
check, and if not, do it manually. On Mon, Jul 5, 2021 at 7:30 PM Mike
Collins *@*.***> wrote:
… <#m_2126317938110217686_>
Does this manage twos complement conversion correctly? On Mon, Jul 5, 2021
at 6:12 PM Mike Collins *@*. *> wrote: … <#m_3261014820833263279_> In C++
(no idea what TCL is) one converts two 8-bit bytes into one signed 16-bit
integer like this: uint8_t rawData[2] = {0, 0}; readData(rawData); //
function to read data int16_t output = (int16_t) ( (int16_t) rawData[1] <<
8) | rawData[0]; This takes advantage of a trick or built in functionality
of C++ in that the compiler knows that a 16-bit integer (int16_t) is signed
so does the proper conversion. The old school way to do this is to form the
uint16_t combination of the rawData and then test for a 1 in the 15th bit
position. So: if(output & 0x8000) { output = ~output + 1; output = -
output; } so that 0xFFFF would become -1, the smallest negative value for
16-bit signed data. . 0x7FFF would be +32767, the maximum positive value
for 16-bit signed data.
https://www.exploringbinary.com/twos-complement-converter/
<https://www.exploringbinary.com/twos-complement-converter/>
https://www.exploringbinary.com/twos-complement-converter/
<https://www.exploringbinary.com/twos-complement-converter/> google twos
complement conversion On Mon, Jul 5, 2021 at 3:20 PM Mike Collins @.*>
wrote: … <#m_-8533214321366424106_> ~ -60 milligs or something like this at
2 g FS, typical and easily corrected offset bias.... On Mon, Jul 5, 2021 at
11:21 AM Mike Collins *@* . *> wrote: … <#m_-8435496152261155125_>
Ax(min) =65182.0 This is not properly cast in 2's complement. 65182 is
0xFE9E, which is a very small negative number. … <#m_-4677973895798972836_>
On Mon, Jul 5, 2021 at 10:56 AM Mike Collins @.*> wrote: Hi Kris. Well i
had to backup a little bit and add some additional debuging info capture,
and here's what i have. You will notice some of the variable names are
basically the same as in your library, so won't be hard to see what some
values are. After you asked about std deviation, i went looking for a TCL
package thst provided some of those functions. And they are captured in the
TCL "array" named after the axis. Since i hadn't got this to work, sort of
after main recoding, i'm only testing with 1 axis at this poiunt, dealing
with all 3 when just 1 doesn't work, just seems silly, to me. cmd="twowire
writeregbyte twowire5 0x6B 0x80" cmd="twowire writeregbyte twowire5 0x6B
0x01" cmd="twowire writeregbyte twowire5 0x6C 0x00" cmd="twowire
writeregbyte twowire5 0x38 0x00" cmd="twowire writeregbyte twowire5 0x23
0x00" cmd="twowire writeregbyte twowire5 0x6B 0x00" cmd="twowire
writeregbyte twowire5 0x24 0x00" cmd="twowire writeregbyte twowire5 0x6A
0x00" cmd="twowire writeregbyte twowire5 0x6A 0x0C" cmd="twowire
writeregbyte twowire5 0x1A 0x01" cmd="twowire writeregbyte twowire5 0x19
0x00" cmd="twowire writeregbyte twowire5 0x1B 0x00" cmd="twowire
writeregbyte twowire5 0x1C 0x00" cmd="twowire writeregbyte twowire5 0x6A
0x40" cmd="twowire writeregbyte twowire5 0x23 0x78" cmd="twowire
writeregbyte twowire5 0x23 0x00" fifo_count="1024" packet_count="85"
accel_bias is array: accel_bias(0) =5542251 accel_bias(1) =5566359
accel_bias(2) =5465702 gyro_bias is array: gyro_bias(0) =5513694
gyro_bias(1) =1404804 gyro_bias(2) =5546861 inList is dict: mean min max
count stdev sampvar popstdev popvar inList is dict: mean min max count
stdev sampvar popstdev popvar inList is dict: mean min max count stdev
sampvar popstdev popvar accel_bias is array: accel_bias(0) =65202
accel_bias(1) =65486 accel_bias(2) =64302 gyro_bias is array: gyro_bias(0)
=64866 gyro_bias(1) =16527 gyro_bias(2) =65257 accel_bias is array:
accel_bias(0) =65202 accel_bias(1) =65486 accel_bias(2) =47918 gyro_bias is
array: gyro_bias(0) =64866 gyro_bias(1) =16527 gyro_bias(2) =65257 wdata is
array: wdata(0) =192 wdata(1) =167 wdata(2) =239 wdata(3) =220 wdata(4)
=192 wdata(5) =69 cmd="twowire writeregbyte twowire5 0x13 0xc0"
cmd="twowire writeregbyte twowire5 0x14 0xa7" cmd="twowire writeregbyte
twowire5 0x15 0xef" cmd="twowire writeregbyte twowire5 0x16 0xdc"
cmd="twowire writeregbyte twowire5 0x17 0xc0" cmd="twowire writeregbyte
twowire5 0x18 0x45" accel_bias_reg is array: accel_bias_reg(0) =-1100
accel_bias_reg(1) =-355 accel_bias_reg(2) =1990 mask_bit is array:
mask_bit(0) =0x0 mask_bit(1) =0x01 accel_bias_reg is array:
accel_bias_reg(0) =-9250 accel_bias_reg(1) =-8540 accel_bias_reg(2) =-3999
Ax is array: Ax(bias) =5542251 Ax(breg) =-9250 Ax(calb) =3 Ax(count) =85
Ax(data) ={65202.95294117647 65182.0 65229.0 85 10.867060191188253
118.09299719890848 10.802947182139594 116.70366782009779} Ax(dbias) =65202
Ax(max) =65229.0 Ax(mean) =65202.95294117647 Ax(min) =65182.0 Ax(popstdev)
=10.802947182139594 Ax(popvar) =116.70366782009779 Ax(sampvar)
=118.09299719890848 Ax(stdev) =10.867060191188253 — You are receiving this
because you commented. Reply to this email directly, view it on GitHub <
#38 <#38> <#38
<#38>> <#38
<#38> <#38
<#38>>> <#38
<#38> <#38
<#38>> <#38
<#38> <#38
<#38>>>> (comment) <#38
<#38> <#38
<#38>> <#38
<#38> <#38
<#38>>> (comment) <#38
<#38> <#38
<#38>> (comment) <#38
<#38> (comment) <#38 (comment)
<#38 (comment)>>>>>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKSYM6P77TN7XXSFKNDTWHW4VANCNFSM4GOKKVSA
. That's very possible. The raw value that i initially see is something
like -1012 ( or something like that) I guess "small" is relative, and i
would hope its something close to zero. — You are receiving this because
you commented. Reply to this email directly, view it on GitHub <#38
<#38> <#38
<#38>> <#38
<#38> <#38
<#38>>> (comment) <#38
<#38> <#38
<#38>> (comment) <#38
<#38> (comment) <#38 (comment)
<#38 (comment)>>>>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKTLRH6RVMFN7CG636TTWHZY3ANCNFSM4GOKKVSA
. Hmmmm, so when do the values get changed to +/- 32768 ? I mean it's so
close right now ? — You are receiving this because you commented. Reply to
this email directly, view it on GitHub <#38
<#38> <#38
<#38>> (comment) <#38
<#38> (comment) <#38 (comment)
<#38 (comment)>>>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKR73WNUHMX4AUMC27LTWIV3FANCNFSM4GOKKVSA
. Yep, i showed you that earlier in the thread. #concatenate higher and
lower value set value [expr {($high << 8) | $low}] — You are receiving this
because you commented. Reply to this email directly, view it on GitHub <
#38 <#38> (comment) <#38
(comment)
<#38 (comment)>>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKQ3NUGO6G2ZU4UJQTDTWJKA3ANCNFSM4GOKKVSA
. Far as i know. I don't use it ALL the time, but never had any problem,
when i did. i mean its the same functionality, left shifting 8 bits, and
then OR'ing the other bits in their normal positions. — You are receiving
this because you commented. Reply to this email directly, view it on GitHub
<#38 (comment)
<#38 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTDLKSJLFNUUJ7YMJAQLP3TWJTDJANCNFSM4GOKKVSA
.
Really Kris ?
TCL is a major scripting language, you think they wouldn't support that
capability ?
Its fine if you don't want to assist me.
I'll just continue to look around.
Thanks.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKWJ45PJKG6AZFO43BDTWJ5HJANCNFSM4GOKKVSA>
.
|
Hello Kris!
First of all thank you for your great work and for sharing knowledge so other can learn!
I am new with the MPU-6050 and I am trying to understand the auto calibration process that you have implemented. If I understand correctly, all is based on ideal situations, e.g. the sensor is located with one axis (z axis) along the gravity vector and other axis having 0g, the sensor have ideal performance characteristics and is temperature is stable, among others.
Then if we believe that we positioned the sensor in the ideal position, we then adjust the measurements by adding offsets to match the ideal case. Is this what you are doing? is this the same as this https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/examples/IMU_Zero/IMU_Zero.ino
Can this be called calibration? I am really confuse if it is necessary to calibrate MEMS accelerometers or if they are adjusted from factory. Could you please elaborate more on this topic of calibration and what the sensor is given from factory?
Thank you once again!
The text was updated successfully, but these errors were encountered: