Speedybee F405 wing i2c ASP5033-CAN connection

Hi All,

I have a Speedybee F405 Wing, and I tried to connect to a Qio-Tek ASP5033 Airspeed sensor and compass via i2c port. I plugged it in, and the compass is probably fine. I cannot get the airspeed working. I set the airspeed type to 15. ARSPD_USE = 1, and I have tried ARSPD_BUS=0,1,2 .

The airspeed sensor does not work. Can you please let me know why and how to fix this?

I have tried this with Plane 4.3 as well from Speedybee webpage. It does not make a difference.


I am able to get the sensor to work with Matek H743 WLITE with the CAN interface after significant parameter changes. Is that sensor Qio-Tek ASP5033 Airspeed sensor and compass designed for CAN only? It has I2C port too. Therefore, it should work for I2C. I can only get compass and not airspeed with I2C.

Hello @testertest,

I have the same problem as you that the airspeed isn’t recognized when using I2C. Also I don’t have any CAN. Did you finally solve the problem?

I’d tested the QioTek ASP5033 DroneCAN Airspeed and Compass Module with the compass working correctly but the airspeed sensor not. It isn’t directly recognized as a device.

I thought the same as you, that connecting the device with I2C, only is the compass available. But I connected the device to an Arduino and I found two I2C addresses.

The addresses found are:
Compass: 0x0D
Airspeed: 0x6D

I am using the flight controller MatekF405-TE, not the Speedybee F405, and I didn’t know if the firmware installed has the driver needed for the airspeed sensor, but I found that it was available, and also in the driver code there was the same I2C address I found before.

Address of the firmware installed, arduplane 4.4.4:
Firmware Plane stable-4.4.4 MatekF405-TE

Address of the driver code:
ASP5033 Driver Code

Also the needed configuration seemed correctly, with the airspeed type to 15 and the connected bus to 0

To discard different problems I started to make different tests:
1- The first one was to power supply all with a battery, getting the result that only the compass was working and available.
2- The second one was powering the module with another battery and power up the flight controller with another battery after few seconds when the module started to blink the led. In this case the compass and airspeed was available and working.

3- The third test was to power up the module and the flight controller at same time, but I got the same results on the first test, with only the compass working and available.
4- I made another test like the second one, in this case, after the compass and airspeed was working and available, I powered down and powered up again the FC but without powering down the module. In this case, after doing that, the compass was the only working and available.

I don’t know how to solve the problem, as connecting first the module and await a time before connecting the FC is not a solution. I don’t know if is a problem of the driver at initialization or the firmware of the module.

Hello @Qiotek,

I found you in another post about the same module. Do you know how to solve the problem with the module?

I’ve been doing more tests. Now I analyzed with a logic analyzer the I2C bus.

First I wanted to known if there are any device with the same address as the module, 0x6D, and I started to analyze the I2C transmission without the module connected. I searched for the address and I only found three coincidences about that, where was the driver searching for the device without acknowledgment as the device wasn’t connected. Also there were three more coincidences with the 0X6C address that is the alternative. With that, there isn’t any address conflict.

The second test that I done, with the logic analyzer, was to connect the module and only be in the case where only the compass was working and available. I thaught that in this case that the results will be the same as before with the driver searching for the module without acknowledgment. For my surprise, there was a constant communication, but in mission planner where no airspeed data and it was not listed as a device.

The third test was to connect the module and do the same as the third test in the last post, to be the compass and the airspeed working and available. The results in the logic analyzer where very similar as the second test.

Here I share the results I obtained with the analyzer if someone wants to analyze:

The program that I used to obtain the data from the logic analyzer was Logic 2 with the version 2.2.13



I’m sorry for missing your post and the ASP5033 Drone CAN module cannot be connected to FC using IIC port directly, and the IIC port on the board a reserved port default.

If you prefer to use the IIC port, PLS connecting APS5033 Drone CAN sensor board to a FC with a CAN port first, you need to use the Drone CAN GUI tool or MP Drone CAN / UAVCAN UI, select f103-Qiotekperih board, then change the Drone CAN peripheral board’s parameter ARSPD_TYPE ==0 ( peripheral board’s parameter not the FC’s), disable the f103 chip driver the ASP5033 sensor when it boot.

The above is the key, haha.

@Chri @testertest

Hello @Qiotek,

Thanks for this information! I don’t know if when you say “disable the f103 chip driver” is another step or is the consequence of changing the ARSPD_TYPE parameter from the peripheral board to 0. In case that I need to disable the f103 chip, how do I need to do that?



you need to use the Drone CAN GUI tool or MP Drone CAN / UAVCAN UI, In the DroneCAN UI or MP, you can see a list of DroneCAN peripheral devices, then select f103-Qiotekperih board, and change the f103 peripheral board’s parameter ARSPD_TYPE ==0 ( peripheral board’s parameter not the FC’s), disable the f103 chip.

Hello @Qiotek ,

Yes, this is what I did. I used the program Drone CAN GUI together with the CAN Bus of a pixhawk where I connected the device. I modified the parameter ARSPD_TYPE to zero (From the device using Drone CAN GUI program) and considering that this also will disable the f103 chip.

After doing that, when I power up the flight controller using a battery and the device connected via I2C, this is directly recognized.

Also, seems that the device is working correctly but after a few seconds later I found some problems. Another I2C device connected to the same bus starts to send data with errors, more concretely, the barometer soldered at the same flight controller.

I attach here some captures where can be seen some of the incorrect values from the barometer. Also because of these values, there is a high error in the altitude values.

Another problem that I found is that after a few seconds, the device compass stops sending more values remaining with the last value received. Also the airspeed stops sending more values and in that case, the last value received is very high, for example 350, and after a minute starts to send again more values in that case values within normality, like between 0 and 6.

Without the device connected the barometer not send any value with errors, only getting altitude values around zero for the long time I was testing. Also I connected other I2C devices, getting the same results obtained without connecting any device, without errors. In that case, the devices used were an HMC5883L compass and another QMC5883 compass with a GPS.

Finally, I tested the device with the airspeed disabled, with the parameter ARSPD_TYPE of mission planner to zero. In that case, as normal, I don’t get any airspeed values but I’m having the same problems as before.



It might has a sensor with the same address on your FC IIC bus.

Hello @Qiotek ,

No, the only other device that is connected at the I2C bus is a barometer that has the address 0x76. The compass and airspeed addresses from the device are 0x0D and 0x6D respectively.

When I used another device to test the I2C bus, I used a QMC5883 compass with a GPS, it has the 0x0D address, the same as the device. In that case, there was no problem, and also I didn’t connect these two devices at same time.

Is there a way to change the addresses or are they permanently fixed?




I tested the device connecting it directly to an ESP32 via I2C, using an Arduino code.

I only found a library for the QMC5883 compass and not for the airspeed, reason for which I only get data from the compass. The results where the same obtained when the device was connected to the flight controller using ardupilot. First I obtain new values from the sensor and after a minute I only receive the same results even moving the device in all axes. Also, all time there are moments where no data is received or there are bursts without data.

I attach here the obtained logs from the compass.

Devices Logs

I think that there is a component, the HA58831A31, that is not soldered correctly but I’m not sure because it’s a QFN IC and it’s hard to see. This is the compass component and it’s the same used by the GPS device with compass.

I will contact the manufacturer directly about this.