Hi
I have install the airspeed sensor and made a flight to calibrate it as showed in the wiki (loiter for 5m with ARSPD_AUTOCAL = 1)
This is the graphic from that flight - First the loiter for calibration and without landing (wireless telemetry) i have disable the ARSPD_AUTOCAL, can someone tell me if it´s ok, and that i may use it?
Thanks
I like to go for longer than 5 minutes, myself.10 to 15 minutes is usually enough. You’ll know it’s done when that airspeed ratio parameter stops updating.
Thanks James
I also stop because the airspeed ratio stop updating after 5 minutes, and the final value is 2,7 (in the limits)
The only concern is because the readings are a little noisy. I don´t know if it´s safe to use the airspeed sensor with this readings.
Thanks again
What sensor are you using? Noise is a common issue with airspeed sensors, especially cheaper ones.
this one
Okay, that’s pretty much what I was expecting. I’ve worked with some of the 4525DO based sensors before, noise is common on them. I’ve seen fluctuations on the ground of up to 7mph, and noise in the air as well. As long as you gut-check it during flight by watching your as/gs and wind speed estimates through telemetry, you’ll be ok.
If you really want to cut down on the noise, I recommend the SDP3X sensor from Drotek. It’s an entirely different type of sensor, and it seems to perform much cleaner, especially at low speeds. However, it’s an $80usd package once you factor in shipping costs, so I can see why many people don’t use it.
Just order one to test 
mean time i´l try to isolate the cabling to see if the noise is RF related.
Thank´s for your help.
I’m using shielded cables only. For all signals, no matter what. Basically I2C is for communication of devices and components that are normally on 1 single PCB. It was never intended to be further away than a few centimetres. So using shielded cables is almost mandatory.
And don’t stop fighting electromagnetic interference with just the I2C cable. I’ve found that at least some sensors are sensitive to electrical noise.
I had a power cable within an inch or so of my sensor. My sensor worked great when I was testing using USB power, but the readings changed when I plugged in a battery and that cable became energized.
So, make sure there are no cables carrying power close to the body of the sensor (servo cables, feeds to ESCs, etc.).
And even with my changes, I had a big crash on Sunday due to a bad airspeed. My new checklist says
Calibrate sensor with cover in place
Remove cover from airspeed sensor
Verify detected airspeed is valid for conditions (close to zero with finger on pitot tube, appropriate for headwind with finger off)
Verify airspeed reacts properly to air flow (blow a bit of air in direction of pitot tube)
Only if all four of the above steps are successful, should you attempt to fly while using the airspeed sensor enabled for navigation.
I was watching an air disaster show on TV yesterday and noticed that one of the first takeoff roll checklist call outs after the application of throttle was “airspeed live”. People have learned to be skeptical about airspeed sensors for good reason.
RR
Totally agree. That’s exactly the procedure we are following for our preflight checks. We also do not fly if the airspeed doesn’t settle somewhere around 6 or 7 kmh (certainly below 10) with airspeed sensor covered and after calibration.
Thank´s Roger
And you consider that mine it´s a little noisy or normal?
I only have a couple of flights and for now it react´s fine.
To throw in my own two cents, I’ve yet to see a 4525DSO system maintain better than 5 MPH noise when covered. After all, that translates to just a handful of pascals, a miniscule pressure differential in the world of measurements with a diaphragm based sensor.
So if your noise on the ground when covered stays below 10 MPH, and the blow test checks out every time, and you’ve got good cross-overs between groundspeed and airspeed when turning, I don’t think there’s a better indication that its as good as it gets.
One word of caution: I wouldn’t count on the ratio calibration holding indefinitely. I’ve seen sensors start out fine with ~2 ARSPD_RATIO, and drift off over time to where a later calibration sees 3.5+
Just keep a watchful eye on its performance over time.
I don’t mind a bit of fuzz on the airspeed line. IMHO, the thing to watch for are the big spikes up and/or down. Most of the time, I don’t think a single sample matters that much…but if you get several samples that tell the FC you’re at a different speed, it could be bad.
If you get low readings and are flying close, you can hear the plane speed up. The real scary behavior is that Arduplane will sometimes attempt to dive to get above stall speed.
If you get high readings, the software will slow down. A few samples won’t let it get that slow, but there is a stall risk.
My crash on Sunday appears to be caused by this. I calibrated and removed the cover, but never checked the air speed…which was steady at ~16 m/s (about 60 km/h). Nice and stable and dead wrong!
When I did the auto takeoff, the throttle went full for about 1/2 second and then was reduced during the next 2-3 seconds to about 50%. The auto takeoff was set to climb at 20%. This led to a ugly stall.
The previous flight, where I foolishly left the pitot cover in place went fine (I realized my mistake only a few seconds after takeoff and flew in FBWA rather than auto after that point).
RR
And people call me crazy for not recommending airspeed sensors on all planes.
The AHRS_WIND_MAX parameter is under re-development and a fix to automatically disable airspeed use will be coming. Plane to use AHRS_WIND_MAX as documented by ChrisBird · Pull Request #10243 · ArduPilot/ardupilot · GitHub
I’ve had good luck with the SDP33 airspeed sensor that doesn’t require a pre-flight calibration to avoid exactly those problems.
Nate,
I probably started using an airspeed sensor too early in my journey, before I had enough experience. But, as long as I’m learning something, even minor disasters can be beneficial.
I’d certainly agree that anyone adding an airspeed sensor (and setting AIRSPEED_USE) before getting an airframe well tuned and before having significant experience with ArduPlane is asking for trouble.
The code change looks like a very good idea.
RR
