Older Versions signed V1 or V2 on the chip had a bug with only 1 MB usable.
Arduplane compiles two versions: Pixhawk 1 and Pixhawk 1-2MB: http://firmware.ardupilot.org/Plane/stable/
I have another one around but it is still with 3.9… I’ll dig further. Thnx!!
I have a 2.4.8 on V4.0.1 and those parameters are available. This is just sitting on the bench, I don’t know if the functionality actually works.
Thanks Dave!
I tried Randy’s procedure to check if this board was affected to no avail (I guess the NSH is no longer valid in ChibiOS).
I updated to v4.0.1 the other Pixhawk I have and the SCR_ENABLE is there, meaning I do things right and that the former Pixhwak I tried surely has the 1MB flash bug (interestingly, I bought that one recently… sellers probably have a stock of these).
Thanks for the hints, guys!
One of the best Flight controller ever released out in the market. Proud to own one.
Congratulations for the team!
I’ve just released plane 4.0.2beta1. This is a minor release with a few bug fixes and enhancements. Changes are:
- added new COMPASS_SCALE parameters and estimator to fix issue with compass in Here2 GPS
- fixed issue with millis wrap on boards with 16 bit system timer (MatekF405, MatekF765, speedybeef4 and KakuteF4)
- fixed i2c internal masks for several boards
- fixed scaling of Blheli32 RPM conversion
- changed to WFQ FrSky telemetry scheduler
- enable LED pin on MatekF765
- added params for Durandal battery monitor pins to param docs
- updated bootloaders to reduce change of line noise stopping boot
- fixed DMA error causing memory corruption in ChibiOS I2C driver
- fixed param conversion from plane 3.9.x to plane 4.0.x for rangefinders
- cope with UAVCAN GPS that doesn’t provide AUX messages (Here2 GPS)
- send temperatures for IMUs on mavlink
Happy flying!
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