Hi,
recently my plane nose-dived from my desk onto the floor, impacting it with the pitot tube. 
I did some other configuration changes at the same time.
Now, I am getting the Airspeed 1 not healthy error when trying to arm. Before I tear everything apart and roll back the configuration, can a clogged/bent pitot tip cause the error as well?
The DLVR-type 9 chip is powered (LED lit up) and the cable connection didn’t change from last time I had it in the air (when it was working).
Airspeed not healthy on the ground typically indicates either sensor reporting “not healthy” or no data at all.
That pitot probe needs to be unclogged regardless of other issues or you are in for a fun takeoff.
With a florist’s wire, I was able to push the deformed plastic out from the inside. It took a bit of fiddling to find the hole. Time to print a pitot cover.
Let’s see if this actually solved my issue. I’m still puzzled how, while sitting stationary on the ground, it would know that the pitot tube was clogged. 
OK, while it was certainly important to unclog the pitot tube, this was not causing the error:
Is there some I2C debug mode, just to see if there is anything received from the sensor?
You should start with looking at your log, particulary ARSP messages.
The easiest way is to display the temperature of the airspeed sensor. If it is 0, then there is an I2C error. The I2C data or clock line may have been damaged ?
(Missionplanner: “Airspeed1_temperature”)
Rolf
OK thanks, I double- and triple-checked the wiring. I do have continuity from the pins on the FC all the way to the pins on the Mateksys AS-DLVR-I2C board (ARSPD_TYPE = 9).
Still, I am getting all zero on the airspeed1_temp on all three I2C busses. The correct one with the Speedybee F405 Wing is supposedly ARSPD_BUS = 0.
I’m a bit clueless now. 
ArduPlane V4.5.5-beta1 (f24dd1d7)
Have you ever replaced the connecting cable with another one? I once had a defective plug that drove me to hell until I figured it out.
Rolf
Can you post a diff of the working / not working params? If it worked before the crash and config changes, and stopped working afterwards, the issue should either be in those config changes or in the hardware.
… ARSPD_ENABLE,1 is set, yes?
I actually did order some micro JST connectors, so I would not have to use the solder pads on the FC side. Will take a while to arrive from China, thought.
I am starting to think that the airspeed reading, that I was seeing in the OSD, was actually not from the pitot sensor, but was the “magically calculated” airspeed. This was my first flight with AP. So I am not sure if there is a way to tell the difference from the OSD.
After that flight, I changed ARSPD_USE from 0 to 1, among other changes (see attached diff).
params.diff.txt (2.3 KB)
The best thing to do is to temporarily set LOG_DISARMED to 1 and use it to record a few minutes without having to arm and then post the log file (*.bin) here, then you can see more.
Rolf
I logged some time on the bench while connected via USB, but do not see anything from the airspeed sensor. The Airspeed 1 not healthy message comes right away. It looks as it is not enabled (in the build?). Am I not looking in the right place?
2024-07-14 09-29-27.tlog (215.3 KB)
Simon
Looks like the required drivers aren’t included in the default build for your board. You’ll need to build a custom firmware, either locally or via https://custom.ardupilot.org.
That one should work: Index of /builds/plane:SpeedyBeeF405WING:4938a6bb4228caf9209a37ae810b52c6108979df:e1fe72abd4a12456df7818f96c168b21
OMG! This did the trick! The build was missing support for my speed sensor. I would have never found that.
I will need to calibrate the sensor with this 3.5 m/s offset before setting ARSPD_USE to 1.
Thanks a million! 
Simon
