MAG AKM8975 being detected as HMC5883 with crazy sensor values

[bkacjios]

INAV/SPRACINGF3 1.8.0 Nov 1 2017 / 06:21:53 (912d131)

FC - https://www.amazon.com/gp/product/B01MS3X1BF
GPS - https://www.amazon.com/gp/product/B077DC7WDB

Behavior

So I just installed a UBLOX NEO-6M into my SP Racing F3 board, and am having a bit of an issue with the external magnetometer. On the GPS chip you can clearly see it's marked as an AKM 8975, yet in iNav only seems to be able to work with it when it's set to HMC5883.

I guess this would be fine if the sensor wasn't spewing out crazy values. I also checked that I'm getting 0 I2C errors as well, so you would think everything is working as it should.

I'm not really sure what to do now. This is my first time ever installing a GPS and using iNav, so I'm a little lost.

Update:

For whatever reason, the magnetometer works great in betaflight. The values seem reasonable and I'm able to calibrate it.

[shellixyz]

The AK8975 driver is not enabled for the SPRACINGF3 FC in version 1.8. Please try this using the right driver or AUTO: inav_1.8.0_SPRACINGF3.hex.

[bkacjios]

You sure? It looks like it's enabled to me in SPRACINGF3/target.h, plus I already compiled my own driver and didn't get anywhere with it.

Setting it to auto just makes it select HMC5883 as before, and manually setting it to AK8975 causes it to not detect it at all. I'm almost starting to think I have some weird mislabeled clone chip.

But here's my status and bootlog from the firmware you linked.

# version
# INAV/SPRACINGF3 1.8.0 Dec 25 2017 / 03:45:43 (912d1315)

# status
System Uptime: 7 seconds
Current Time: 2017-12-25T07:32:13.489+00:00
Voltage: 0 * 0.1V (1S battery - NOT PRESENT)
CPU Clock=72MHz, GYRO=MPU6050, ACC=MPU6050.n
STM32 system clocks:
  SYSCLK = 72 MHz
  HCLK   = 72 MHz
  PCLK1  = 36 MHz
  PCLK2  = 72 MHz
Sensor status: GYRO=OK, ACC=OK, MAG=UNAVAILABLE, BARO=NONE, RANGEFINDER=NONE, OPFLOW=NONE, GPS=OK
Stack size: 6144, Stack address: 0x10002000
I2C Errors: 0, config size: 3331, max available config: 4096
ADC channel usage:
   BATTERY : configured = ADC 1, used = ADC 1
      RSSI : configured = ADC 3, used = none
   CURRENT : configured = ADC 2, used = none
  AIRSPEED : configured = none, used = none
System load: 4, cycle time: 2005, PID rate: 498, RX rate: 49, System rate: 9

# bootlog
Time Evt            Description  Parameters
  41:  0          CONFIG_LOADED 
  41:  1       SYSTEM_INIT_DONE 
 543: 19   TIMER_CHANNEL_MAPPED  (0, 1, 0, 2)
 543: 19   TIMER_CHANNEL_MAPPED  (1, 2, 0, 2)
 543: 19   TIMER_CHANNEL_MAPPED  (2, 3, 0, 2)
 543: 19   TIMER_CHANNEL_MAPPED  (3, 4, 0, 2)
 543: 19   TIMER_CHANNEL_MAPPED  (4, 5, 0, 2)
 543: 19   TIMER_CHANNEL_MAPPED  (5, 6, 0, 2)
 543: 19   TIMER_CHANNEL_MAPPED  (6, 6, 1, 3)
 543: 19   TIMER_CHANNEL_MAPPED  (7, 6, 2, 3)
 543: 18  TIMER_CHANNEL_SKIPPED  (11, 6, 2, 3)
 543: 18  TIMER_CHANNEL_SKIPPED  (12, 6, 2, 3)
 543:  2          PWM_INIT_DONE 
 589:  9         GYRO_DETECTION  (2, 0, 0, 0)
 706: 10          ACC_DETECTION  (3, 0, 0, 0)
 706: 11         BARO_DETECTION  (0, 0, 0, 0)
 706: 20        PITOT_DETECTION  (0, 0, 0, 0)
 706: 12          MAG_DETECTION  (0, 0, 0, 0)
 706: 13  RANGEFINDER_DETECTION  (0, 0, 0, 0)
 706:  4       SENSOR_INIT_DONE 
1208:  5          GPS_INIT_DONE 
1208:  7    TELEMETRY_INIT_DONE 
1259:  8           SYSTEM_READY 

[shellixyz]

Odd. Indeed it was enabled in master but it has been disabled in the development branch. I don't know what is going on. Could be that the driver is broken and has been disabled for the next release. I can't test this myself since I do not own this magnetometer.

diff master..development -- target.h

-#define MAG
-#define USE_MAG_AK8975
+#define USE_MAG
+#define MAG_I2C_BUS             BUS_I2C1

[bkacjios]

Huh, weird. Either way, I don't think this chip is actually an AK8975 if it's being detected as a HMC5883. They have different i2c addresses, so there should be no way that it works and detects it when set to HMC5883, yet it does.

Also, I just checked and betaflight is detecting it as HMC5883 too.

# version
# Betaflight / SPRACINGF3 (SRF3) 3.3.0 Dec 25 2017 / 00:44:38 (be99725ee) MSP API: 1.37

# status
System Uptime: 168 seconds
Voltage: 0 * 0.1V (0S battery - NOT PRESENT)
CPU Clock=72MHz, GYRO=MPU6050, ACC=MPU6050.n, MAG=HMC5883
Stack size: 2048, Stack address: 0x10002000
I2C Errors: 3, config size: 2090, max available config: 4096
CPU:20%, cycle time: 547, GYRO rate: 1828, RX rate: 49, System rate: 9
Arming disable flags: RXLOSS CLI

After some calibrating in betaflight the values seem to be good as well.

I took pic while moving it around a bit.

[eeprommemory]

bkacjios i have the same gps but a m8n remove the chip with the numbers ground off and put in two links.
i have tested it and it works

[bkacjios]

Huh, interesting. I'll have to try this since I kinda gave up on this board. What is the purpose of that chip anyway?

[eeprommemory]

takes the gps data and the mag data and combines them into one signal for what maker FC board i don't know.

[AmbaCamba]

Hi, I have the same module as eeprommemory (NEO-M8N with compass - see picture above) and did not remove strange chip between AKM chip and I2c bus, FCC controller I am using is OMNIBUS F4V3. With independent program I found out that AKM8975 mag chip is emulating HMC5883 (or strange chip is doing i2c logical translation to HMC5883 registers) so that is why it is detected as HMC5883. Unfortunately emulation (translation) is not perfect (calibration does not work as HMC5883 and mode changes are not correctly implemented). So I modified source driver for HMC5883 not to use calibrating parameters and readout of data is now correct. Only problem that remain is that after calibration of compass in GUI you have to power down Flight controller because chip does not recognize command for exiting calibration mode and thus remain in undefined state (power down after calibration resolves the issue). The part of HMC5883 driver file which you have to modify is included. I suspect that problems with QMC5883 which is at HMC5883 I2c address can be solved on similar way. I agree that software mod is not the greatest thing , but it opens several dilemmas.
A - is it safer to have delicate hardware mod than software driver patch (hardware reliability is at stake).
B - Available hardware mutates so fast that it is increasingly difficult to buy "proper" hardware (description of both types are the same although hw modules are different) so it is hard to buy "correct" stuff. Proper hw modules sometimes (as HMC5883L ) are not any more in production "clones" are cheaper.
I think that it is good that people are investigating and publishing their findings and solutions so that everybody can solve his/hers problem to own satisfaction.

Driver part mod HMC5883:

static bool hmc5883lRead(magDev_t* magDev)
{
uint8_t buf[6];

bool ack = i2cRead(MAG_I2C_INSTANCE, MAG_ADDRESS, MAG_DATA_REGISTER, 6, buf);
if (!ack) {
    magDev->magADCRaw[X] = 0;
    magDev->magADCRaw[Y] = 0;
    magDev->magADCRaw[Z] = 0;
    return false;
}
// During calibration, magGain is 1.0, so the read returns normal non-calibrated values.
// After calibration is done, magGain is set to calculated gain values.
magDev->magADCRaw[X] = (int16_t)(buf[0] << 8 | buf[1]); // CHANGES !!!      * magGain[X];
magDev->magADCRaw[Z] = (int16_t)(buf[2] << 8 | buf[3]); //                      * magGain[Z];
magDev->magADCRaw[Y] = (int16_t)(buf[4] << 8 | buf[5]); //                      * magGain[Y];

return true;

}
Regards

[tootomthumb]

I have the same M8N GPS module as eeprommemory with the AK8975 chip attached to my Matek F405 OSD board and wasnt detecting any magnetometer at first. So I added a couple 2k pull-up resistors to SDA and SDL. The magnetometer was then being detected as an HMC5883 producing garbage results similar to bkacjios. Fortunately seeing your post I cut away that unknown chip and rewired as eeprommemory showed and bingo, INAV now detects an AK8975 and I get stable results.

AmbaCamba you should consider giving it a go because it means you dont have to live with hacked software or unusual calibration procedures.

Thanks to all of you guys and long live GOOGLE search!

[bkacjios]

What gauge wire did you use, and do you have any tips for doing that mod? I tried, but I didn't have any wire small enough, so I sorta gave up on it.

[tootomthumb]

Yeah eeprommemory makes it look easy, whereas I think I only got it done by luck!

Removing the chip was easy to start...I just cut the chip's arms with a fine wire cutter then used a soldering iron to clear the pads.

I laid down the first wire to re-connect SDA from the magnetometer to the output again using the wire I cut off from my 1/4 watt resistor I used for the pull-ups. Then I laid a tiny bit of electricians tape over the the top so I could then set down the next wire to link SDL back again. As I said it wasnt pretty!

I could only manage to solder those wires (which are as wide as the pad!) by cleaning the pads of all excess solder, then pre-tinning the wire and finally just heating the pad and wire together to get a join.

Frankly, given the fact my wire wasnt insulated, and I needed to use electricians tape, I should have used much finer wire by taking something like a 28awg multistrand wire and just using one of the strands!

I think eeprommemory used lacquered wire and if I had the inclination I would have found that somewhere by raiding an old motor or tiny transformer. But honestly, I don't know how he stripped the end to allow him to solder it. However he did it, it looks great.

The only reason I attempted it was because, like you, I had run out of options....

Tomorrow I'll try and get a picture and you can see how ugly my "solution" was!

[eeprommemory]

thinner the wire the easier it is to solder.
for photo purposes i used 0.24mm enamel coated wire good for photos not so good to work with (too stiff).
i normally use 0.16 enamel coated wire its gold colored and is real easy to work with but hard to take good photos.
old computer ribbons have 7 tinned 0.12mm strands i use this to repair broken flex ribbons it would be the best wire to use if it's you first time trying something like this.
put the first wire across then superglue it or nail polish it then put the second one over it and then glue it.
check with multi-meter.
clean board with nail polish remover with brush or if you can get some brake cleaner in a spray can it does an awesome job.
in Australia its called bendix brake cleaner or SCA brake cleaner (super cheap auto).

[stale]

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help.
This issue / pull request will be closed if no further activity occurs within two weeks.

[mattschinkel]

I did the hardware fix. It took me 5 min. I have not tested it outside, but the sensor page looks much better and I see changes as I move my drone around or put a magnet near it. I did have to re-calibrate my mag in iNav.

[robertha64]

I did same hardware mod, the worst part was tu put the 2 connections for SDA and SCL in place, however it is working now - without adding additional pullups resistors for I2C. I did find out the resistors are actually there - R3 and R4 (10kOhms both) but that stupid chip (I removed) did block them to outside bus.

Also the GPS power LED stop working for some reason after mod, but the GPS and Mag is fine (catch 10+ satelites in 30s on cold start)

One additional note - it is working for me on Omnibus F3 FC with iNav 1.8. Fpr some reason it did not work with iNav 1.9 or higher - looks like AK8975 mag is ommited for my target.

[robertha64]

[stale]

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help.
This issue / pull request will be closed if no further activity occurs within two weeks.

[stale]

Automatically closing as inactive.