-
Notifications
You must be signed in to change notification settings - Fork 10
Reorder mag return values from XZY order to XYZ. #7
Conversation
Looks fine to me. |
My apologies - I had made a comment but realized it e was due to my own misinterpretation of the code. I deleted the comment which may have been even more confusing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are the raw magnetometer values multiplied by 16 (line 180) ? This is not a change so has no bearing on the PR, but it is not clear to me why it is done.
I have the same question as @jerryneedell with regards the |
Of course I meant divide 😉 |
Not sure about the shifting I just ported the C code, obviously missing that crucial bit about Y & Z being swapped. |
Double checking the datasheet and C code... it looks like the MAG data doesn't need to be shifted. I'll try it out and submit the change it it makes sense. |
The driver needs a full once-over IMO, there seems to be plenty of things that are out of sync with the C++ version. When I wrote it I just needed something quick to do what I needed and didn't pay much attention to completeness. I don't have time now, though. |
The datasheet really isn't too clear. Unless I'm missing it somewhere, it does not show the actual bit layout for either the accel or the mag registers. Your left with just:
But on the first page, one of the features is "16 bit data output". So I would assume both the accel and mag data are 16 bit 2's complement. The Arduino library has some commented out code dealing with 12 bit values: Apologies for deviating from the original issue of the PR. |
interesting taht the Raspberry Pi library does treat the accel data as 12 bit (with the shift) but not the mag data : https://github.com/adafruit/Adafruit_Python_LSM303/blob/master/Adafruit_LSM303/LSM303.py#L81 I this is similar to the Arduino lib. edited to add - this is not the same as the Arduino -- since the shifts are commented out in the Arduino. |
This really is a strange sensor interface -- the Endianness of the accel and mag are not even the same.... yikes but both are shown as 2's compliment 16 bit values when read. That appears to be how Arduino treats them -- even though it does not cast the mag to int16. I Don't have one of these to test with, but I suggest removing the shifts from the mag conversion and leaving them out of the accel conversion. |
Gaaa! Its even worse -- the Arduino library referenced above is deprecated! https://github.com/adafruit/Adafruit_LSM303#warning-library-deprecated and the replacement does shift the accel data???? https://github.com/adafruit/Adafruit_LSM303DLHC/blob/master/Adafruit_LSM303_U.cpp#L124 |
ah -- but there is a factor of 16 difference in the "gain" applied by the CP driver from the "unified" Arduino Driver.
so the accel results are likely the same. So perhaps only the shifting of the mag data is really different. Also - the gains need to be looked at closely for the mag to see if they are compensating for the curly applied shift. I don't think they are and I expect that the CP mag data is off by a factor of 16. That won't impact the "compass" directions and I wonder if anyone actually looks at the raw mag data. |
hmmm -- looking at the example in the guide https://learn.adafruit.com/lsm303-accelerometer-slash-compass-breakout?view=all#circuitpython-and-python-usage-4-6 note that the magnitude of the magnetic field reported is only about 4 microtesla but the earth field should be much larger - more like 50 - 60 microtesla. close enough to a factor of 16 for me to be suspicious. If you have one of these sensors, it may be worth comparing the Arduino magnitude to the CP magnitude. |
Is this helpful? CircuitPython:
Arduino, from this sketch:
|
looks like a factor of 16 to me ;-) |
@@ -177,7 +177,8 @@ def raw_magnetic(self): | |||
""" | |||
self._read_bytes(self._mag_device, _REG_MAG_OUT_X_H_M, 6, self._BUFFER) | |||
raw_values = struct.unpack_from('>hhh', self._BUFFER[0:6]) | |||
return tuple([n >> 4 for n in raw_values]) | |||
values = tuple([n >> 4 for n in raw_values]) | |||
return (values[0], values[2], values[1]) | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given the discussion along with they PR I suggest that the shifts be removed and this simply use:
return (raw_values[0],raw_values[2],raw_values[1])
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or defer that to another issue/PR. We've kind of hijacked this one. The PR fixes what it was meant to fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fine with me -- I have no objection to merging this PR.
adding @microbuilder for more details |
Updating https://github.com/adafruit/Adafruit_CircuitPython_DotStar to 1.4.0 from 1.3.0: > Merge pull request adafruit/Adafruit_CircuitPython_DotStar#31 from kattni/example-update > Merge pull request adafruit/Adafruit_CircuitPython_DotStar#30 from adafruit/pi_bitbang_exception > Merge pull request adafruit/Adafruit_CircuitPython_DotStar#28 from siddacious/master > ignore the board module imports in .pylintrc Updating https://github.com/adafruit/Adafruit_CircuitPython_LSM303 to 1.2.1 from 1.2.0: > Merge pull request adafruit/Adafruit_CircuitPython_LSM303#7 from dastels/master > ignore the board module imports in .pylintrc > Merge pull request adafruit/Adafruit_CircuitPython_LSM303#6 from kattni/example-update
No description provided.