VTOL Airspeed issue

Im having a problem with an digital Matek ASPD-DLVR airspeed sensor and VTOL plane. During transition phase (from Qloiter to FBWB) GPS ground speed was able to reach 24 m/s but airspeed max was around 13 m/s. Winds were about 3-4 m/s max. Minimum airspeed required in order to complete transition on this airframe (VTBird) is about 17m/s. Airspeed sensor was covered during calibration - and cover was removed before arming the plane. Im not sure how to debug this further - is there anyone with previous experience to shed a light what could be the problem here?

Airspeed sensor params:

1	1	ARSPD2_USE	0	2
1	1	ARSPD_AUTOCAL	0	2
1	1	ARSPD_BUS	1	2
1	1	ARSPD_FBW_MAX	25	4
1	1	ARSPD_FBW_MIN	17	4
1	1	ARSPD_OFFSET	4.315738201141357422	9
1	1	ARSPD_OPTIONS	0	6
1	1	ARSPD_PIN	65	2
1	1	ARSPD_PRIMARY	0	2
1	1	ARSPD_PSI_RANGE	1.000000000000000000	9
1	1	ARSPD_RATIO	1.673727035522460938	9
1	1	ARSPD_SKIP_CAL	1	2
1	1	ARSPD_TUBE_ORDER	2	2
1	1	ARSPD_TYPE	8	2
1	1	ARSPD_USE	1	2

Airspeed, GPS speed and Baro/GPS altitudes on the flight log graph:

Another strange thing is that plane changes altitude before failing the transition (17 sec transition timeout configured in params).
Unexplainable Elevon movement (no RCIN):

Flight log attached (contains 2 transitions):

As a matter of fact!

I’m having the same issue on the same bird! The ground speed for me is consistently 7-9mph FASTER than what the airspeed sensor is saying. Here is what I think is going on:

  1. The data for me was collected on a day that had 1-4mph winds (rare here).
  2. I got a good 6 minutes of data while doing a lazy circle.
  3. I also have data doing a grid search which showed me near identical results.
  4. I am using a non analogue sensor which is VERY accurate (SDP3x from drotek.com)
  5. That airspeed sensor does not need to be zeroed for every flight, rather you calibrate it once and it’s forever accurate up to its rated maximum airspeed.
  6. I’ve used that airspeed sensor for almost 4 years now and in the past the airspeed ratio was typically in the 3.5-4.0 range (typical for an analogue sensor is 2.0-3.0).
  7. Look at the graph of airspeed vs ground speed and note that there is a 3.4 m/s difference between the two speeds. It’s very consistently like that, even on long straight tracks of flight.

  1. I have done the automatic airspeed calibration for 20 minutes doing circles and it will not budge from its current value of 3.90764.

  2. Using this information from the documents section HERE I hand calculated what airspeed ratio value would give me a near perfect airspeed reading, which came out to be 5.35168 which is WAY higher than in the past. So now I am past the high end of 4.0 for this species of airspeed sensor.

  3. So what I am thinking now is a bad location for the airspeed tube. If that is true for me then it will be true for your problem too!

  4. I use a 15x10 APC prop for my VTBird instead of the supplied 15x8 which might also be contributing to this problem.

Here is what my prop to airspeed sensor locations look like:


You can see that the static ports are about an inch forward of the props but that does not mean that the ports are unaffected by prop wash. I can’t model the prop wash so I don’t know for sure but maybe what is going on here is that the pitot tube needs to be much further forward for both of us.

Meanwhile I did a airspeed calibration flight that set ARSPD_RATIO to 4.0 - which I thought would mean that airspeed data cannot be trusted (ie out of normal range of 1.5-3.0 as per docs).

My prime suspect at the moment is possibly wrong ARSPD_PSI_RANGE value (which was set to 1.0 PSI). Matek ARSP-DVLR airspeed sensor spec says “pressure range 2500Pa” - which translates to 0.36 PSI actually.

I will do new calibration flight with new psi range parameter and we will see how it goes. Pitot tube position and prop wash is probably also an issue - just not sure how big one. I can see large airspeed fluctuations during hovering.

How is the situation now Andres. Can you clarify if it solved your problem? Thanks in advance @mainframe

Changing ARSPD_PSI_RANGE did not solve the problem. Pitot position and prop wash may be the root problem (pitot static pressure holes need to further in front from prop tips).

Just wondering… what’s your ARSPD type? CAN (8) or I2C (9)?
Edit… ok seen it…its CAN.

I use a cube orange and my ARSPD_PIN is set to 15. What’s your autopilot?

Sunday.