Main Site Documentation

Geomagnetic Sensor Recommendations


I am in the process of selecting a sensor for monitoring heading (digital compass) with built in tilt compensation. I have been looking at the BMX055 by Bosch and the ICM-20948 by TDK InvenSense. Has anyone use either of these before or any other similar IC’s? My primary concern is interpreting sensor data…any guidance is appreciated.


I’ve worked with a few types from basic cheap magnetic sensors to expensive Honeywell sensors. You need to consider a calibration of the metal around the sensor, often called a hard iron calibration. Without this, any material that is affected by magnetism such as steel around the sensor will have an effect on the heading as it rotates in the earths magnetic field.
If the sensor you have has a true gyro output, it will give you a heading from 0 to 359.9 and the BMX055 doesn’t appear to do this. It only has rate outputs and magnetic values that you would have to calculate the heading yourself.


BNO055 is a 9 dof sensor so does have a 3 axis mag and outputs heading.


Possibly Dave means that the BMX055/BNO055 (I think the only difference is SPI vs UART output) does not output a single number (degrees related to North) for a heading, it outputs the raw data for each axis which all has to be combined to get a viable direction? It does mention in the data sheet that it outputs fused axis data though…i.e. the heading. I am pretty confused by the below section:

Is there no tilt compensation in the Compass mode since only x and y mag data is used? If that is the case then I would need the raw data anyways as my device will be randomly/unpredictably tilted at fairly large angles.


It outputs heading as 0 - 359.9


Is that only x and y axes or is it transforming z in as well? The wording is unclear to me. Will that 0-360 output take into account if the device is tilted? Otherwise the heading would be wrong if the device isn’t flat.


Yes it is tilt compensated.


That is fantastic. @Justin do you have a link to the driver posted on the old GHI? I think you were referring to this post but the CodeShare link is dead.

Also, the datasheet mentions all devices come pre calibrated. However, in the above link you posted code storing calibration data to STM flash…does it have to be calibrated each power cycle?


You calibrate the sensor by waving it around in a figure 8. You can then save the calibration offsets and reload them into the sensor on power up so you dont need to calibrate using the figure 8.

So yes, on power up you need to calibrate by doing a figure 8 or loading then saved calibration offsets.


Thank you! I will probably have a few more questions in ~2 weeks when the board arrives (:


Yes, looking at the BNO055 it has a register for heading so once calibrated, it should be fine but calibrating a figure of 8 in a large metal mass (car, ROV etc) may be a problem. Hand phone is easy :wink:


My device will be small so calibration won’t be a problem. I am quite pleased to learn that the BNO055 outputs a tilt-compensated heading register. When I first read the data sheet, I thought it only gave the angular rates and so forth. That is actually the main reason I made this post was to learn how to form an algorithm for the raw data output. On that note, it would still be nice to know how to do the calculations myself.

@Justin did you test the BNO055 via I2C or UART? I was thinking UART because I love the SerialPort class / have had much less trouble than with i2C interfaces.


eye two see (needed 10 chars)


It took me a minute to understand what you mean!! Strange how both ways sound the same but the eyes are a big part of understanding things!!


@Justin Did you use the recommended external 32kHz crystal for best performance or the BNO’s internal crystal?

Is there any reason why I should use i2C over UART with this sensor?


I populate said Xtal but i have never enabled it in software as the output has always been good enough for me without it.

UARTs are limited so i2c saves pins for other goodies.


plus managing the state machine for UART string handling is more effort than i2c