Some I2C MAG does not work

[McGiverGim]

I've a Omnibus F4 Pro (V3). Two months ago I added a Radiolink SE100 (M8N + HMC5983) to my quad. It worked perfectly but after some hours the hardware was dead, I don't know why. I bought another, the same model, but this does not work. Betaflight does not detect the MAG.

# status
System Uptime: 19 seconds
Current Time: 0000-01-01T00:00:00.000+00:00
Voltage: 0 * 0.1V (0S battery - NOT PRESENT)
CPU Clock=168MHz, GYRO=MPU6000, ACC=MPU6000, BARO=BMP280
SD card: Manufacturer 0x3, 15558144kB, 06/2017, v8.0, 'SC16G'
Filesystem: Ready
Stack size: 2048, Stack address: 0x10010000
I2C Errors: 0, config size: 1840, max available config: 16384
CPU:9%, cycle time: 125, GYRO rate: 8000, RX rate: 49, System rate: 9
Arming disable flags: RXLOSS CLI MSP

First, I thinked it will be a hardware issue, so I tried with iNav, and iNav detected it perfectly out of the box, so the hardware is working.
I Have observed that the board in the old version (that worked in Betaflight) and the new (that don't work) are slightly different being the same model.
Here you have the complete diff:

# diff

# version
# Betaflight / OMNIBUSF4SD (OBSD) 3.3.0 Nov  9 2017 / 18:53:40 (6f46ba7) MSP API: 1.37

# name
name migmul martian

# resources
resource MOTOR 5 NONE
resource MOTOR 6 NONE
resource SERIAL_TX 3 NONE
resource SERIAL_TX 11 A01
resource SERIAL_RX 3 NONE
resource SERIAL_RX 11 A08
resource I2C_SCL 2 B10
resource I2C_SDA 2 B11

# mixer

# servo

# servo mix


# feature
feature SOFTSERIAL
feature GPS
feature TELEMETRY
feature DYNAMIC_FILTER

# beeper

# map

# serial
serial 0 4160 115200 57600 0 115200
serial 5 2 115200 57600 0 115200
serial 30 16384 115200 57600 0 115200

# led

# color

# mode_color

# aux
aux 0 0 0 1950 2050
aux 1 1 1 1250 1350
aux 2 1 1 1450 1550
aux 3 1 1 1650 1850
aux 4 2 1 1350 1450
aux 5 3 1 1250 1350
aux 6 3 1 1650 1850
aux 7 6 1 1750 1850
aux 8 10 1 1250 1350
aux 9 11 1 1250 1350
aux 10 11 1 1650 1850
aux 11 13 1 1250 1350
aux 12 26 0 1950 2050
aux 13 28 1 1050 1150
aux 14 32 5 1950 2050
aux 15 33 4 950 1200
aux 16 34 4 1800 2050

# adjrange
adjrange 0 0 2 1950 2050 18 3

# rxrange

# vtx

# rxfail
rxfail 5 s 1500

# master
set gyro_notch1_hz = 0
set gyro_notch1_cutoff = 0
set gyro_notch2_hz = 0
set gyro_notch2_cutoff = 0
set mag_declination = -110
set max_check = 1950
set serialrx_provider = IBUS
set motor_pwm_protocol = MULTISHOT
set failsafe_delay = 3
set failsafe_off_delay = 20
set failsafe_throttle = 1200
set failsafe_procedure = AUTO-LAND
set bat_capacity = 1800
set vbat_detect_cell_voltage = 55
set ibata_scale = 333
set small_angle = 180
set disarm_kill_switch = OFF
set gps_provider = UBLOX
set gps_sbas_mode = EGNOS
set gps_auto_baud = ON
set deadband = 3
set yaw_deadband = 5
set pid_process_denom = 1
set osd_rssi_alarm = 0
set osd_cap_alarm = 1600
set osd_tim1 = 0
set osd_tim2 = 1793
set osd_vbat_pos = 2433
set osd_rssi_pos = 46
set osd_tim_1_pos = 54
set osd_tim_2_pos = 2455
set osd_flymode_pos = 2145
set osd_throttle_pos = 2424
set osd_vtx_channel_pos = 376
set osd_crosshairs = 2250
set osd_ah_sbar = 2250
set osd_ah_pos = 2250
set osd_current_pos = 2400
set osd_mah_drawn_pos = 2370
set osd_craft_name_pos = 2440
set osd_gps_speed_pos = 2264
set osd_gps_lon_pos = 2129
set osd_gps_lat_pos = 2097
set osd_gps_sats_pos = 2119
set osd_home_dir_pos = 2126
set osd_home_dist_pos = 2092
set osd_compass_bar_pos = 2154
set osd_altitude_pos = 2294
set osd_pid_roll_pos = 391
set osd_pid_pitch_pos = 455
set osd_pid_yaw_pos = 487
set osd_debug_pos = 391
set osd_power_pos = 321
set osd_pidrate_profile_pos = 344
set osd_avg_cell_voltage_pos = 76
set osd_pit_ang_pos = 257
set osd_rol_ang_pos = 289
set osd_battery_usage_pos = 302
set osd_disarmed_pos = 2411
set osd_nheading_pos = 106
set osd_nvario_pos = 1
set osd_esc_tmp_pos = 82
set osd_esc_rpm_pos = 83
set osd_stat_max_dist = ON
set osd_stat_min_batt = OFF
set osd_stat_min_rssi = OFF
set osd_stat_max_alt = ON
set osd_stat_endbatt = ON
set debug_mode = FFT
set vcd_video_system = 2

# profile
profile 0

set dterm_lowpass_type = PT1
set anti_gravity_gain = 2000
set setpoint_relax_ratio = 50
set dterm_setpoint_weight = 105
set p_pitch = 65
set d_pitch = 40
set p_roll = 50
set d_roll = 36
set p_yaw = 90

# rateprofile
rateprofile 0

set rc_expo = 40
set rc_expo_yaw = 10
set thr_mid = 40
set roll_srate = 65
set pitch_srate = 61
set yaw_srate = 60
set tpa_rate = 0

But I've tested with defaults too, only adding this:

resource I2C_SCL 2 B10
resource I2C_SDA 2 B11

Things that I've tested:

• Ask for help in slack (thanks to @jflyper for the effort) without luck. So I generate this issue to see if we can find more people with the same problem.
• Betaflight 3.1.7, 3.2.1 and master without luck.
• iNav -> WORKING
• Disable the i2c overclock, and modify the i2c timeout in the code, without luck
• Compare the iNav code with the Betaflight code but my knowledge is very limited, so I didn't see nothing.
  Maybe someone with more knowledge can compare the iNav and Betaflight code to see where the difference can be?

[jflyper]

I2C mag repeatedly come up as not working properly in various symptoms (including "it works on iNav"), but it is usually the case that only those with proper measurement apparatus (e.g., DSO, logic analyzers - LAs) really help trouble shooting the issue.

@McGiverGim Do you have an LA?

[McGiverGim]

No, sorry, I don't :(

[digitalentity]

Hm... Usually it's the other way arouind - hardware is reported working in Betaflight and not working in INAV 😄

In INAV it's usually an edge cases with marginal hardware quality. Some compass sensors will only work at lower I2C speeds (200 kHz). As far as I know Betaflight doesn't have the code to select low I2C speeds.

[McGiverGim]

Taking a look at the code, Betaflight works at 800 and 400, and iNav has 100 and 200 too, but I think by default it is configured to work at 400.

[jflyper]

You want to try 200?

I'm building for default 200 now. Or, you can do it yourself?

[McGiverGim]

I can try, for sure. If the changes in the code are minimum, you can told me where to change and what values you want to try and I can compile the code by myself, if it is easier for you. I don't want to give you a lot of work ;)

If I'm not wrong, is here?

betaflight/src/main/drivers/bus_i2c_stm32f10x.c

Lines 414 to 417 in 8b334e5

	if (pDev->overClock) {
	i2cInit.I2C_ClockSpeed = 800000; // 800khz Maximum speed tested on various boards without issues
	} else {
	i2cInit.I2C_ClockSpeed = 400000; // 400khz Operation according specs

[jflyper]

Yeap. That it, line 417. Change 400000 to whatever you want, 200000, 100000, ...

[McGiverGim]

I need to disable the overclock too I think?

betaflight/src/main/target/common_fc_pre.h

Lines 31 to 32 in 8b334e5

	#define I2C1_OVERCLOCK true
	#define I2C2_OVERCLOCK true

I will remove the if completelly and put to 200000 the value always.

[jflyper]

Good finding!

[McGiverGim]

Some advance:

• Removing the if and using 200000 always, MAG not detected, and the configurator shows one I2C error.
• Removing the if, and using 400000, THE MAG IS DETECTED!!!! but the configurator shows the I2C error counting constantly incrementing.
• Letting the if, and putting the overclock to false, to let it automatically to 400000, MAG not detected and no errors.
• Removing the if, and using 400000, and putting the overclock to false, MAG detected but the configurator shows the I2C error counting constantly incrementing.

So the constant overclock does not seem to work. Any other ideas to try? :)

[McGiverGim]

More info :)

Using 400000 and changing:

betaflight/src/main/drivers/bus_i2c_impl.h

Lines 25 to 27 in 8b334e5

	#define I2C_SHORT_TIMEOUT ((uint32_t)0x1000)
	#define I2C_LONG_TIMEOUT ((uint32_t)(10 * I2C_SHORT_TIMEOUT))
	#define I2C_DEFAULT_TIMEOUT I2C_SHORT_TIMEOUT

The default timeout to the long timeout... the MAG is detected and I've no errors. I need to test if it works, if the north is detected right, but is an advance :)

[McGiverGim]

Result of some tests: it does not seem to work. When I start the FC the configurator always point to the north, ignoring the position of the quad.

So the MAG is detected, there're no errors, but the data does not seem to be readed correctly.

EDIT: the MAG does not work because the calibration is not working. If I add some "random" values like

set magzero_x = -32
set magzero_y = 153
set magzero_z = 284

Then the mag is "working" (not too good because the random values are not the correct), but it works. Maybe a bug in the configurator or some problem with my changes. I will test more.

[McGiverGim]

After a lot of tests, now I think that the mag is faulty. With the changes, betaflight detects it, but the sensors tab of the mag always is 0, so I think they were not readed.
I've installed iNav, that detects the MAG out of the box... and the problem seems the same. It does not detect the values in the sensors tab.
So if nobody has another idea, I think that I need to buy another MAG :( and I will close this issue.
Sorry for the time spended by all trying to help me.

[jflyper]

😭

[McGiverGim]

I have bought another, the same model, pigheaded that I am... The thursday will be here and we will see what happens...

[catchra]

Hi please keep up the good work i have the same problem and would love to be able to use my mag but programing is beyond me.
The problem is still in the new ver. 3.2.2
and i can confirm that for me inav works with my neoM8N+HMC5883 with no problems but betaflight doesn't even if i use set mag_hardware = HMC5883

[mikeller]

@catchra: At least telling us what board you are using, or how you are connecting your I2C device, whould give us a chance to help you with your problem... ;-)

[catchra]

I am using the omnibus f4 v3 with sdcard on firmware 3.2.2
as for the mag it is connected to SCL/TX3 and SDA/RX3
on the ports tab i made no changes to uart3
on the configuration tab i turned on the mag
and in the CLI i used set mag_hardware = HMC5883 and than save
these are the same setting i used in Inav

in the betaflight flasher i am using OMNIBUSF4SD at version 3.2.2

in Inav flasher i am using OMNIBUSF4SD at version 1.6-ALPHA2
with show unstable set to on

[McGiverGim]

You must put this commands in cli:

resource I2C_SCL 2 B10
resource I2C_SDA 2 B11
save

[catchra]

Thank you that work

but this is the output from the CLI

Entering CLI Mode, type 'exit' to return, or 'help'

# resource I2C_SCL 2 B10

NOTE: B10 already assigned to SERIAL_TX 3.

Resource is set to B10

# resource I2C_SDA 2 B11

NOTE: B11 already assigned to SERIAL_RX 3.

Resource is set to B11

it did not work until i used the commands that you gave me.

[McGiverGim]

Yes, don't worry. They are warnings.

[McGiverGim]

To let more info about this problem, until I receive the new unit, I have found an iNav user with the same problem and the same product:

iNavFlight/inav#2299

One of the comments say that the MAG maybe is a QMC5883 and not a HMC5983L. The photo shows an "DA 5883 7002". Is there a way to know if is HMC or QMC?

[jflyper]

@McGiverGim The "DA 5883" looks like a QMC5883; there are numerous Chinese sites listing the DA chip as "HMC5883 alternative".

EDIT
Strange thing is that it could have been detected as HMC5883 even these don't have compatible address.

[McGiverGim]

So I have two problems:

• The first, Betaflight does not support it
• The second, it seems that is not a standard QMC5883, because iNav detects it as a HMC5883 and if a configure it as a QMC5883 it appears as unavailable.
  Maybe is a QMC5883 listening to the address of the HMC5883?

[jflyper]

I think the manufacturer is offering custom chips with non-standard I2C address; data sheet says

The default I2C address is 0D: 0001101
If other I2C address options are required, please contact factory.

http://img.filipeflop.com/files/download/Datasheet-QMC5883L-1.0%20.pdf

[jflyper]

Here's the whole story.
iNavFlight/inav#1903

[McGiverGim]

Thanks! I will try to compile inav using QMC and the address of HMC, to see if it works... Maybe this will be the only "customization".

[jflyper]

Data sheet mentions "OTP Load" immediately after POR and Soft Reset. I suspect I2C address is written in the OTP area...

[digitalentity]

Oh yeah, that QMC5883 chip appears to be a real pain the back. When it's on the default address - all is ok, but if manufacturer configures it for something different - funny things starts to happen.

[RipperDrone]

@asizon: Negative...

(I tried mag_hardware = QMC5883 instead of AUTO, but both failed)

[RipperDrone]

@andrejpodzimek Interesting, my Mark 4 build has a Turtle on board, and # of satellites received varies a lot, many times dropping below 6 during flight. Not trustworthy enough yet... :-o

It seems it is independent of WiFi being switched on or off - I always have it off during flight... GPS receiver sits in very back of the quad, might be partly obstructed by FPV antenna, plus noise intereference might come frome that as well...

[McGiverGim]

I had problems in the past with my rincam split too, but some GPS have a good filtering that help a lot. Now I have it working without too much problem. One with compass (hmc) and the other without (qmc). I'm happy with both results.

[mikeller]

@RipperDrone, @andrejpodzimek: Re the differences in I2C bus driver, I think one factor there is that in the past Betaflight has tried to support as fast as possible loop times for the few flight controller models (mostly early SPRACINGF3 / clones) that use an I2C attached gyro, whereas iNav where working support for (mostly I2C) compass devices is crucial, has taken a different approach.
I think now that support for F3 based boards has been dropped in Betaflight there are no supported flight controllers with a I2C gyro left, so we can definitely revisit this decision.
Also, not requiring a compass was one of the crucial design decisions in GPS rescue, and one that sets it apart from RTH functionality as implemented in iNav. I.e. there is no way to support any form of 'position hold' in GPS rescue, as there is no orientation data coming from GPS when the craft is not moving.

[jflyper]

We have to be careful about decreasing I2C bus speed, as HAL drivers may do busy waiting, resulting in larger jitter of loop time. Iirc, F4 (and F1) drivers does per byte interrupt, so this would not be a problem. HAL, we should investigate what it’s doing.

[McGiverGim]

If we finally go to dma interruptions in Betaflight the problem of jitter will be fixed?

[RipperDrone]

Sounds this might be an option. Anyway, dma interrupts have a lot other issues involved, as one could see with timer sensitive code parts like rpm bidir where timer interference and/or overlaid/duplicate assignments cause bugs. I feel that mag is not considered important in BF in general so putting these efforts for the mag to work only seems pointless. Going as far as to propose to drop mag support, to be consistent. If GPS Rescue is fabricated in a way to work completely independent of overlaid mag/compass information, why support it?

[jflyper]

If we finally go to dma interruptions in Betaflight the problem of jitter will be fixed?

I can only say probably. I2C DMA is very complicated, as I2C bus cycle is not a plain read (input) / write (output). Haven't seen F4 (and F1 and F3) library codes supporting DMA. HAL may have one. However, DMA is much less CPU intensive than what we currently do, thus friendly to jitter sensitive codes.

Going as far as to propose to drop mag support, to be consistent.

Lol. Why drop working code because of a non-working chip that we don't even know if the chip has a published spec?

[jonomakepeace]

I have a Beitian BN-880 with the HMC5883L with 4.1 MAMBA-F7 that also does not get detected despite proper configuration and pull-ups.

I'd like to try build with i2c clocked to the normal speed 400kbps and not overclocked. Are there any caveats here? I found the speed definition in bus_i2c_hal.c - still to find where overclock is set.

[ShanGlor]

Fake (labeled as) HMC5883s are actually QMC5883 and it has a different address and register from HMC. The correct address and register for QMC5883 are 0x0D and 0x1D respectively.

[ghost]

Fake (labeled as) HMC5883s are actually QMC5883 and it has a different address and register from HMC. The correct address and register for QMC5883 are 0x0D and 0x1D respectively.

Honeywell, the manufacturer of the HMC5883L and HMC5983 (same compass but with temperature compensation), discontinued these devices around 2016. However, they licensed the design to a Chinese company called QST Corporation.

QST Corporation produced two versions of the QMC5883L, version "A" and "B" with each device labelled "DA5883" and "DB5883" respectively.

The "DA5883" version "A" device behaves identically to the original HMC5883L and responds to the I2C address 0x1E, except that its status register doesn't work.

The "DB5883" version "B" is totally different device, behaves according to the QMC5883L datasheet and as you mention responds to the I2C address 0x0D.

Frustratingly, this information remains completely undocumented by QST. The fact that the status register doesn't work on the version "A" devices, means that they fail when used as a substitute for the original Honeywell magnetometers. Although it's possible to workaround the issue, by tweaking the firmware. The version "B" device has a completely different set of internal registers and any flight control firmware needs to handle this as a completely new and separate chip.

Unfortunately, there's much confusion as many "HMC5883L" breakout boards are being sold with this compass replaced by either "A" or "B" versions of the QMC5883L, neither of which work with standard HMC5883L code.

[RipperDrone]

Going as far as to propose to drop mag support, to be consistent.

Lol. Why drop working code because of a non-working chip that we don't even know if the chip has a published spec?

@jflyper u got me wrong here, lol. Dropping QMC type mag support for GPS rescue in BF should have been my more concise proposal. Not aware that ANY QMC type mag is currently working on BF, still it exists as a mag_hardware option.

[MoppelMat]

I have invested some time into this problem myself today.
I run a Mamba F722 FC that does not have designated I2C pads.
I used very valuable information from this thread and came to a solution for this FC and a BN880 GPS module.

I use the recommended RX3 and TX3 pads for I2C.

these are my CLI changes:

resources

resource SERIAL_TX 3 NONE
resource SERIAL_RX 3 NONE
resource I2C_SCL 2 B10
resource I2C_SDA 2 B11

master

set align_mag = CW270FLIP
set mag_bustype = I2C
set mag_i2c_device = 2
set mag_hardware = HMC5883

I have not noticed any magnetometer "wandering" yet, but the connection by usb takes longer sometimes...

[bizio996]

set align_mag = CW270FLIP
set mag_bustype = I2C
set mag_i2c_device = 2
set mag_hardware = HMC5883

thank you so lot!!! it also worked for me on my mamba f722 with gps + mag matek m8q.
only one problem remains for me, the gps takes a long time to hook the satellites

[mikeller]

@bizio996: This is a known issue that is being worked on: #9194

[blakepie3]

Hi @MoppelMat, you mention you're using the Mamba F722 FC, is that the mini or the full size?

I'm using the Mamba F722 mini FC and a Rush Tank Mini video transmitter. The Video and Smart Audio pads on the transmitter are going to TX3 and VTX respectively. Could those wires be moved to TX2/RX2 in order to free up TX3 for I2C? Then I wire up the SCL/SDA wires from the BN-880 to TX3? Where is RX3?

Thanks!

[kotikvadik]

I have a Mamba F405 mk2 flight controller with FURYF4OSD firmware. I have connected a GPS BN-880 module with a built-in HMC5883 magnetometer. However, in automatic mode in Betaflight, the magnetometer was not detected. Although INAV sees it perfectly. It turned out that the parameter mag_i2c_address = 1 by default. There is no description of the magnetometer parameters on Githab, but there is a description of similar parameters of the barometer. It states that the value of address 1...7 is not valid. Address value 0 automatically finds the device address. I set mag_i2c_address = 0 and the magnetometer was detected. Also I tried setting mag_i2c_address = 30, which corresponds to the HMC5883 address (0x1E) and the magnetometer is detected as well. If you know the model of the magnetometer, you can specify the specific model, in my case mag_hardware = HMC5883.
Another important point is I2C speed. The fact is that the HMC5883 has a maximum I2C frequency of 400 kHz, and in betaflight, by default, all I2Cs are overclocked (i2c1_overclock = ON). INAV has the ability to select the I2C speed, but in Betaflight, you need to set i2c1_overclock = OFF in the cli. In this case, the I2C number must be specified for a specific PC.
To calibrate the compass correctly, you need to rotate the quadcopter in turn in three coordinates at least 360 degrees in both directions.

[daleckystepan]

@kotikvadik Clock speed issue is already fixed. Also it will be possible to select speed you want. Check these PRs:
#10624
#10631
#10653

[RipperDrone]

wow, these are great findings - after 4 yrs BF's wonky HMC support gets fixed - genius! I fumbled around with darn HMC magneto and finally gave up - it was fine on INAV, never got it working on BF. Seems some of the legacy code GPS parameters were forgotten by some BF devs and no one remembered about the correct configuration options anymore. As easy as a setting of 0 means autodetect, contrary to the default 1 - kudos! :-)

[MoppelMat]

... As easy as a setting of 0 means autodetect, contrary to the default 1 - kudos! :-)
or 30 :)

[sdellava]

Hallo, I've succesfully configured my QMC5883L (config icon is light up) on a F745 (flywooF745nano board) but in the sensor page I can't see any variation in the graph. Is it a bug in the configurator or the mag is not comunicating ?

[sdellava]

Update: I've noted an error on the barometer value. After disabling the magnetometer the baro return to work correctly. So there must be a conflict between the two sensor.

This is the configuration:

resource I2C_SCL 1 B06
resource I2C_SCL 2 B10
resource I2C_SDA 1 B07
resource I2C_SDA 2 B11

mag_hardware = QMC5883
mag_bustype = I2C
mag_i2c_device = 2

baro_hardware = AUTO
baro_bustype = I2C
baro_spi_device = 0

[DHaacke]

@sdellava, what a lifesaver. Just noting what worked for me with a Mazel 5883. All that was needed in BF 4.3 RC3 was:

mag_hardware = QMC5883
mag_bustype = I2C
mag_i2c_device = 2

Well done, and thanks!

[elsp1991]

I also had a QMC5883 working on a mamba MK4 but I had to change it to mag_i2c_device = 1
I guess there is only one I2C channel exposed on the pads but you dont know which one it is so I iterate from 0 to 4 but was lucky already with 1

[kotikvadik]

Latest Betaflight Configurator 10.8 renamed parameter of I2C speed. Now it is i2c1_clockspeed_khz = 800 by default. You should set it to 400 kHz (i2c1_clockspeed_khz = 400).

[SanKin42]

I also have a Mamba F405 mk2 v2 flight controller with FURYF4OSD firmware . I have connected a GPS GEP-M8Q module with a built-in QMC5883L magnetometer. INAV sees it perfectly. But bf not work. I'm sure it's on magnetometer. I tried the setup mag_hardware = qmc5883 mag_i2c_address = 13 or mag_i2c_address = 12 i2c1_clockspeed_khz = 400. I tried all kinds of combinations and frequencies and they didn't work. bf version is 4.4.2