main: Add IIO buffering compass support #15
Conversation
|
Can you contact the linux-iio mailing-list to talk about the units and values reported by the driver? I couldn't find anything useful in Documentation/ABI/testing/sysfs-bus-iio |
In most IIO sensor types, _scale and _offset is added to the scan element base name, for example: in_accel has in_accel_scale and in_accel_offset For compasses, this is different. Instead of being named in_rot_from_north_magnetic_tilt_scale aand similar, the _scale and_offset attributes are named in_rot_scale and in_rot_offset. This commit adds a workaround to special-case the attribute naming for this type of sensor.
|
Sorry for the long delay. I've split up the commits as requested and fixed up the indentations errors. I also figured out that to get the actual value in degrees out of the compass all I had to do is to divide it by 10, and changed heading to int because I don't think fractions of degrees would be useful for anyone. |
|
I would actually prefer to keep heading as a float. Heading is a gdouble in geoclue: About the "divide by 10", that value should be in one of the sysfs files, see the "Find the scale" section in iio-buffer-utils.c |
|
It would make sense the scale would be in the sysfs files, but it's not... in_magn_scale and in_rot_scale both return 0.000001 if it helps I can ask why it's like this on the iio mailing list. |
|
That would be helpful, yes. |
|
Note that you'll also need to:
|
|
Merged with plenty of fixes from Zeeshan and myself. Will follow up on the couple of TODO items in other issues. |
|
👍 Thanks. Me and Matthias tested on the only hardware we had at hackfest and seems the value we were getting was out of scale (16xxxx something). Looking at the code, it seems we still need that to be fixed in the kernel? It's been a long time since I did any kernel programming but I could give it a go if I had the hardware. :( Oh and it seems you want geoclue to transform the magnetic to true heading. :) You found some formula somewhere to do that, right? |
|
@zeenix I found a Python implementation: https://github.com/cmweiss/geomag/blob/master/geomag/geomag/geomag.py It seems to use the magnetic model from NOAA: http://www.ngdc.noaa.gov/geomag/WMM/ |
|
@zeenix I also found a C implementation (which seems to be under public domain): http://www.ngdc.noaa.gov/geomag/WMM/soft.shtml |
|
@elad661 👍 Interesting! I'll look into them. The python code went quite above my head though. :) |
This (kinda) works on the thinkpad twist, with the only issue is the values returned from the compass are not even remotely accurate :)
The numbers returned from the compass are always larger than 360 (at least on my device), and they never show the correct heading.
(I initially thought calculating it manually from the magn_x and magn_y channels would work better for me, but it turns out they're less accurate and I was reading the numbers wrong)
I also tried using the scale value the sensor has, but that's even worse - the scale is 0.000001, which is very unhelpful... I think it is very likely that the hardware I have is just plainly bad, and that the code itself works as intended.