With 4.0, simply recalibrate your compass
3.6 latest beta will allow you to set the scale factor to 1.17 manually for this improvement.
And for the record… there is no “issue” with the hardware, we simply have a scale factor that differs from what would be ideal for ardupilot.
We will not be changing this, as that would make it too difficult for those who are not on CAN, and those using PX4.
This new scale factor auto adjustment makes the latest versions of Ardupilot work very well with the Here2 gps, and obviously we love any improvement to how magnetometers work 
Thanks to Tridge, Randy, and the team for adding this important improvement to ardupilot!
1 Like
so we can run 2 x Here2 on the can ?
and more than 3 compass
Hi Phillip and Tridge,
Hence, is it safe for us to fly with the Here2 on older versions of ArduPlane (without the COMPASS_SCALE option)? What symptoms do we expect to see in such a situation? I currently use the old Here GPS on 3.9.8, but plan to upgrade to the Here2.
Many thanks 
With plane 4.0.x you will see higher than expected compass innovations in the log, and in the EKF status report. It will not usually be high enough to cause a significant navigation problem.
We have yet to see a case where the higher innovation issues caused a real navigation error, but we have seen cases where the innovations were well above the 0.5 warning level which causes a warning to be displayed on the GCS.
It was an investigations of these warnings that first alerted us to the issue with the scale factor on the Here2.
Cheers, Tridge
1 Like
When something like this comes out, it’s not just for the fun of it.
We used the wrong number in coding the Here2 hardware, there are no if’s or buts about it… it’s a bug…
It’s not going to cause more problems now that it’s been discovered than before when we were blissfully unaware…
However, now that it’s known, running the correct scale factor in ardupilot for the Here2 will give you much better performance on the compass, and it’s highly recommend.
So much so, that it gets its own Service bulletin on CubePilot.
It’s well worth upgrading
1 Like
I’d like to parrot this question of, “Is it safe to use the Here2 on fw versions older than 4.0.x?”
My case also happens to be on 3.9.8, and I’m running a (slightly) modified version of it so “just upgrade to be safe” isn’t as easy of an option. In any case, I’d like to wait until 4.0.x is a bit more proven before I move my systems to it.
It’s worth noting that I’ve done many flights on 3.9.8 with the Here2 and the only issue I’ve ever seen is a “Bad GPS Health” message, which has never had an effect on navigation. I haven’t seen a single compass issue as long as the calibration is done properly.
I’m not asking “what would be ideal,” I know the ideal option is to upgrade the firmware. What I’m asking is this: Do I need to ground all of planes with a Here2 and 3.9.8 until I can update them?
no, you don’t need to ground planes. The issue is not nearly severe enough to warrant grounding.
I’d also note that you do have the option of setting EK2_MAG_EF_LIM=0 (or EK3_MAG_EF_LIM=0 if running EKF3). That has the effect of disabling the earth frame compass limiting feature that has the dependency on the correct scaling of the compass. That feature does make handling of compasses considerably more robust to motor interference which is why it is enabled by default, but if you can’t update and you are suffering from high compass innovations due to the incorrect scaling of the Here2 compass then you could use those settings to resolve the issue.
The EKn_MAG_EF_LIM option was introduced in the 3.9.9 release. If you set it to zero then the behaviour will revert to what was used before 3.9.9. That behaviour did not have a dependency on the correct compass scaling, but was also less robust.
Cheers, Tridge
2 Likes
plane 4.0.2beta1
anyone come across their OSD not changing screens
it works fine under 4.0.1 soon as i update it stops
that is odd. There have been no changes to the OSD code between 4.0.1 and 4.0.2.
Can anyone else reproduce?
yes i cant work it out i make no changes to the prams just firmware from 4.0.1 to 4.0.2beta1 it stops reboot the go back to 4.0.1 and it works 
was there any changes to telemetry packet scheduler on mavlink ?
I can’t reproduce it. Just updated a MatekF405-Wing from ArduPlane V4.0.0 beta1 to V4.0.2 beta1. Switching between OSD screens and update of OSD-datas works perfectly.
yes, I merged the WFQ scheduler for FrSky telem. I can’t see how that affects the OSD screen switch though.
Do you have FrSky telem enabled? Can you send me a tlog of 4.0.2 running, with attempts to switch screens?
ok have done
i did notice in the osd screen STREAM FROZEN warring after been ruining for some time
i am using https://github.com/night-ghost/minimosd-extra mavlink v946
ahh, ok, I had assumed you were using the built in SPI OSD.
How is screen switching done with minimosd? I assume it’s on a RC channel? Which channel for your setup?
just std minim Osd RC channel CH6
The only idea I have is if this is related to the change to FrSky telem. To test this idea I’ve built you two firmwares here:
http://uav.tridgell.net/yak54/
one firmware has the new WFQ change to FrSky telem, the other doesn’t. Can you please test both and confirm if one has the issue and the other doesn’t?
1 Like
I’ve just released plane 4.0.2beta2. This is a minor change over beta1. Changes are:
- fixed error on AHRS level trim in preflight calibration
- fixed handling of SB without BUSY on I2Cv1 devices
- update bootloaders to be more robust to unexpected data
If I get some good reports in and no new issues in the next few days then I expect to release 4.0.2, hopefully by the end of the week.
Happy flying!
OK i did some test on 2 planes
tested without WFQ on each plane after 3 mins stop working
tested with WFQ on each plane after 3 mins stop working
so went 4.0.1 works till i turn it off after 15 min
so i went back to 4.0.1.beta2 after 3 min stopped
then i seen flashing in OSD STREAM FROZEN where GPS data shows that is odd
so i was just about to turn it off i unplug USB cable then it started to work again
so it looks like when USB cable and mission planer is plug in and running it was stopping mavlink messages to tele2 port
Thank you for taking the time to help
thanks! so that rules out the WFQ patches. So we’re going to need to try a bunch of intermediate builds to try to find which patch broke this for you. I have looked through all the patches and I can’t see one that is a candidate.
Are you setup to build your own fw, or shall I generate a bunch of builds and get you to test each one in turn? I could generate 10 firmwares for example.