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!
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.
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
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.
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
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?
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?
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?
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