New Airspeed sensor (MS5525) for ArduPlane 3.8

@223Wylde did you try ARSPD_BUS 0 ?

Yes, finally got it working on ARSPD_BUS 0, still have some issues though, it worked awesome at first, but now seems to drift from zero to about 6-8m/s after the initial calibration. Maybe I just have a bad sensor? Iā€™ll contact Jordi to see if he has any ideas, tried switching the tubes and keying-in manual offsets, nothing seems to help.

  • Jeff

@223Wylde Is the sensor exposed to sunlight? (And even if itā€™s not directly exposed can you notice a difference in reading by shading itā€™s installed location from light?)

Now you cough my attention (deficit)! haha. Ok, it seems like you might have an unusual situation that we should explore more to determine if the sensor is dying and why. Please send me all the data you can, logs, pictures, how you mount it, anything that could help us investigate this, please. If we are unable to solve it, we will replace it and test it ourselves.

-Jordi

Nope its not exposed to sunlight, the only thing unusual yesterday was we were getting light rain off an on so it was very humid. So, when I got home I disconnected the tubes and let everything dry out, and so far today its not drifting at all, it seems to calibrate ok, and holds within 0-2m/s, I left it powered up for about an hour, and it didnā€™t drift like before. So, maybe this was just due to extreme humidity?

Thanks,
Jeff

It is indeed very sensitive to humidity, Iā€™m not sure if compensates for humidity, but it should. Temperature, pressure, and humidity all affect pitot static measurements.

Ok, Iā€™ll keep a close eye on it during the next flights and let you know if I get any more unusual readings. It worked exceptionally well during the first 3 flights, accuracy was simply incredible, it matched the GPS ground speed exactly on calm days!

Also, it seems to eliminate throttle surging when flying flight lines, due to less noise I assume, which definitely leads to efficiency!

:heart_eyes: Awesome, please keep me posted.

Jordi, flew again today and sensor seems to be working fine, but airspeed vs ground speed is off by about 2-3m/s when flying cross-wind.

Previously, I tried to do an airspeed auto calibration, but it seemed to adjust the calibration ratio the wrong direction, it went from the default value of 1.99 down to 1.93.

I may have to try it again to see if it adjusts it down from the default, not sure if it matters which way the tubes are connected?

Just completed another airspeed calibration flight, results seem much better, it adjusted the airspeed ratio parameter from default of 1.99 down to 1.96, and now airspeed matches groundspeed on the crosswinds every time around.

Weather conditions were much better today, wind was from the southwest steady at 3m/s, I circled constantly for 8 minutes with a constant throttle setting and with the AUTO_CAL enabled. Temp was 80 deg F, and humidity was 70%, Iā€™m located in southern Minnesota, so we get fairly high humidity often.

The only thing Iā€™ve noticed thatā€™s unusual is about every other calibration on power up seems bad, the airspeed will show 4-5m/s with the cover still on the pitot tube. Then if I just reboot, it will typically be in the normal 0-2m/s the next time and will be fine, so not sure if the airspeed calibration on power up needs some tweaking?

Will fly some test flight lines later this week and will let you know how it goes, so far so good!

Hello 223Wylde,

If you have crosswinds, your airspeed will be affected a lot by the wind.
You can even calculate wind direction and speed with that, that is why your
data doesnā€™t match, so is very normal to have different ground speed from
airspeed. When flying real airplanes we have the same situation and
we learn how to compensate it.

1 Like

Hi 223Wylde,
Do you cover the pitot tube with a baloon while booting/arming. I always do this and I get good results. I am still using the old sensor and yet to try this new one.

Actually, flying crosswind is the only time airspeed should be very close to ground speed, flying downwind groundspeed is always higher than airspeed, upwind groundspeed will always be lower than airspeed. So when enabling the AUTO_CAL parameter, thatā€™s why you constantly have to fly level circles with a constant throttle setting, so the flight controller can compare the upwind leg to the downwind, and adjust the airspeed ratio accordingly, when it gets it right, the airspeed will be dead-on.

And yes, I always keep the pitot tube covered when booting up, you cannot have any air moving across the tube when it performs the self-calibration, Iā€™ve always had excellent results using the older sensor that way. So, this is why Iā€™m not sure whatā€™s causing the initial values (with cover on) to be 4-5m/s sometimes, and 0-2m/s other times.

  • Jeff

Ok, did a couple more flights today, the plane still flies around 3-4m/s slower than it reads airspeed, I think Iā€™m finally getting the problem cornered. The first sensor I tried always resulted in a -1,400 to -1,500 offset, and it typically ranges between 0-4m/s after powering up. It still stays within that range even if you run the preflight calibration after initial power up, I did that several times, and calibration offset changes slightly, but it stays pretty consistent. So, installed another new MS5525, and airspeed offset is very different, always around -110, but airspeed still drifts between 0-4m/s after a few minutes just like the first sensor.

So, I think the main issue is how the airspeed offset is calculated, when I manually reduced the airspeed offset on the second sensor from -110 to -100, the airspeed stays zeroed and only ranges from 0 to 0.1, never goes above that. Will try another test flight tomorrow to see if this solves the main problem which I believe is the self-calibration not zeroing-out the sensor close enough on power up.

@223Wylde I havenā€™t read the full history here, and Iā€™m unsure if you have auto tube order set, but I strongly suspect you donā€™t. If itā€™s not on auto tube order then negative airspeedā€™s rather then flipping the sign will be clamped at 0 m/s. So you can still be having problems or be wildly mis-calibrated but it would look like 0 m/s before you takeoff. Adjusting the offset by hand till you arenā€™t seeing spikes is an indication that you are moving into this region. Basically use caution as you preform that test as you might just be shifting values by more then expected till you encounter a serious problem.

5 m/s error in pressure reading on the ground would be an error of 0.7 m/s moving at 16 m/s, so the climb to 4 on the ground does not point at the source for the error of 4 in flight.

Iā€™ve tried it both ways, and Iā€™m seeing the least variance when setting the tube order to zero, and connecting the impact pressure tube to the top port. Either way, the main problem is, the airspeed readout always drifts upward from zero on the ground over time, which causes the plane to be flying that same amount of offset slower, I can tell its hanging on the edge of stall when in RTL, because when orbiting over me, the nose starts to bob a bit. I had the minimum airspeed set to 18m/s, and I know by observing the aircraft its actually flying approximately 14m/s, stall speed for the aircraft is 12m/s.

If I manually adjust the airspeed offset down to zero it out, the worst that will do is cause the aircraft to fly at a higher airspeed than readout which would be much safer.

I wanted to go back to the old airspeed sensor until I have time to help troubleshoot this, but I cannot get the older 4225 to work with the Pixhawk 2.1.

Basically what happens with auto tube order is we just always assign the absolute value of the reading as the current airspeed, when you set a tube order, whatever would indicate a negative airspeed is disregarded as 0.0.

For what itā€™s worth I can confirm 4525ā€™s work with a PH2.1.

Without knowing more about your setup itā€™s hard to say, but itā€™s very possible your getting fuselage interference. Have you validated this setup on the airframe in flight with an older sensor/firmware?

Yes, Iā€™ve flown hundreds of flights with the same airframe that Iā€™m currently testing this new sensor on with Pixhawk 1s and the older airspeed sensor, and its always been spot on once calibrated, so its not fuselage interference, I have the pitot tube and sensor mounted the exact same way, only differences are the new parameters and settings added to the firmware for the new sensor.

Not sure what calculations are performed during the self-calibration on power up, but Iā€™m guessing that algorithm needs to be adjusted slightly to zero-out this new sensor correctly, the offset seems to be off by about 10% each time.

Is there any documentation yet for settings using the 4525ā€™s and PH2.1?

4525 and PH2.1 does just work (at least on I2C2, and Iā€™m 95% sure it works on I2C1 as well). The ARSPD_TYPE needs to be set to 1 but other then that it should just work.

I flew another test flight yesterday with the MS5525, and as usual it was initially ranging from 1-5m/s after power up, this is with the pitot tube covered, I then ran a pre-flight calibration action 2 or 3 times, that helped reduce the range a little, but it was still ranging from 1-3m/s. So, I then wanted to test manually zeroing the sensor, so I reduced the offset from -95 to -85, after that, it was reading from 0.0 to 0.1 on the HUD. I flew a set of flightlines that were 90 degrees to winds aloft, and the wind was quite light, and the airspeed matched the groundspeed along the flightlines within 0-1m/s when cruising along the flightlines in both directions, and when returning to launch, I can tell airspeed was matching the MIN_AIRSPEED parameter which was set to 18m/s.

So, this method of manually zeroing the sensor works, you just have to adjust the offset until you get the airspeed to readout values just above zero.

I still think the self calibration algorithm needs to be adjusted for this sensor, its not the same as the older 4525, and once zeroed, its a far superior airspeed sensor.

Please let me know if thereā€™s anything else I can do to help get this issue resolved.