Plane 4.3 stable release

yes I want 25mw while disarmed. and switch to 200mw and 1000mw with a 3position switch. the vtx support 25mw,200mw,600mw,1000mw.

vtx https://www.aliexpress.com/item/4000944862282.html

I need to see more than this. Need to see from the beginning until it starts alternating 400 and 1000

How about this?

1 Like

Ok the first problem is that the VTX is lying - in tramp it says it only supports a maximum power of 600mw. We won’t set anything above the maximum reported by the VTX. So try using 600 instead of 1000 for your 3-pos switch.

it works now for now. the OSD still flashing but I can’t the led statue changes on the VTX. I will try another VTX with tramp. thank you for doing all of that.

Hello @tridge ,
I just upgrade my QUADPLANE from FW 4.2.3 to 4.3.1 and almost crashed due to some issues.
Could you please take a look on my new post here:

Thank you very much for your help.
My best regards,

1 Like


I’ve just released plane 4.3.2beta1. This is a minor update with a few accumulated fixes since 4.3.1. The changes are:

  • ARKV6X support
  • MatekH743 supports 8 bi-directional dshot channels
  • Pixhawk1 boards support MS5607 baros
  • SpeedbyBee F405v3 support
  • DroneCAN Airspeed sensor support including hygrometer readings
  • Pre-arm warning if multiple UARTs with SERIALx_PROTOCOL = RCIN
  • Siyi gimbal support
  • Arm check warning loses duplicate “AHRS” prefix
  • AtomRCF405NAVI bootloader file name fixed
  • BRD_SAFETY_MASK fixed on boards with both FMU safety switch and IOMCU
  • Compass calibration continues even if a single compass’s cal fails
  • Gremsy gimbal driver sends autopilot info at lower rate to save bandwidth
  • Invensense 42605 and 42609 IMUs use anti-aliasing filter and notch filter
  • OSD stats screen fix
  • RC input on serial port uses first UART with SERIALx_PROTOCOL = 23 (was using last)
  • RunCam caching fix with enablement and setup on 3-pos switch
  • RTK CAN GPS fix when GPSs conneted to separate CAN ports on autopilot
  • fixed yaw rate for fixed wing autotune

Happy flying!

5 Likes

Thank you Andrew,it just simply keeps getting better and yours and the teams work is superb

1 Like


I’ve just released 4.3.2-beta2. This is a minor update over beta1. Changes since beta1 are:

  • improved uBlox M10 support
  • CubeOrange defaults to using 2nd IMU as primary
  • SIRF and SBP GPS disabled on BeastF7v2, MatekF405-STD, MAtekF405-Wing, omnibusf4pro
  • fixed loading of autotune gains during pilot testing
  • Fixed CAM_MIN_INTERVAL to cope with mission and pilot triggering
  • EKF3 fix when using EK3_RNG_USE_HGT/SPD params and rangefinder provides bad readings
  • Main loop slowdown after arming fixed (parameter logging was causing delays)
  • changed to ‘fast task’ scheme for critical loop updates
  • MAVLink commands received on private channels checked for valid target sysid
  • ModalAI camera support fixed (ODOMETRY message frame was consumed incorrectly)
  • Param reset after firmware load fixed on several boards
  • Siyi A8 gimbal support fixed
  • Windows builds move to compiling only 64-bit executables

Happy flying!

Many thanks to the following people who contributed code or documentation to this release:

6 Likes

Congratulaion @tridge and all developers,
I hope can test this new FW without any issues…
Regards

1 Like

Short (because of the frosty temperatures) flight on a still to be further parameterized aerobatic plane with H743 in FBWA and autotune went without any problems.

1 Like


A new stable plane version 4.3.2 has been released. This version includes a set of small bug fixes and improvements over 4.3.1.

Changes since 4.3.1 are:

  • improved uBlox M10 support
  • CubeOrange defaults to using 2nd IMU as primary
  • SIRF and SBP GPS disabled on BeastF7v2, MatekF405-STD, MAtekF405-Wing, omnibusf4pro
  • fixed loading of autotune gains during pilot testing
  • Fixed CAM_MIN_INTERVAL to cope with mission and pilot triggering
  • EKF3 fix when using EK3_RNG_USE_HGT/SPD params and rangefinder provides bad readings
  • Main loop slowdown after arming fixed (parameter logging was causing delays)
  • changed to ‘fast task’ scheme for critical loop updates
  • MAVLink commands received on private channels checked for valid target sysid
  • ModalAI camera support fixed (ODOMETRY message frame was consumed incorrectly)
  • Param reset after firmware load fixed on several boards
  • Siyi A8 gimbal support fixed
  • Windows builds move to compiling only 64-bit executables
  • ARKV6X support
  • MatekH743 supports 8 bi-directional dshot channels
  • Pixhawk1 boards support MS5607 baros
  • SpeedbyBee F405v3 support
  • DroneCAN Airspeed sensor support including hygrometer readings
  • Pre-arm warning if multiple UARTs with SERIALx_PROTOCOL = RCIN
  • Siyi gimbal support
  • Arm check warning loses duplicate “AHRS” prefix
  • AtomRCF405NAVI bootloader file name fixed
  • BRD_SAFETY_MASK fixed on boards with both FMU safety switch and IOMCU
  • Compass calibration continues even if a single compass’s cal fails
  • Gremsy gimbal driver sends autopilot info at lower rate to save bandwidth
  • Invensense 42605 and 42609 IMUs use anti-aliasing filter and notch filter
  • OSD stats screen fix
  • RC input on serial port uses first UART with SERIALx_PROTOCOL = 23 (was using last)
  • RunCam caching fix with enablement and setup on 3-pos switch
  • RTK CAN GPS fix when GPSs conneted to separate CAN ports on autopilot
  • fixed yaw rate for fixed wing autotune

Happy flying and hope everyone has a great holiday break!

Many thanks to the following people for contributing to this release:

5 Likes

Hi Andrew,
Upgraded to 4.3.2 stable. I have installed a CUAV skye airspeed sensor cant see any HYGRO_ params. Airspeed sensor works

the hygrometer data should show as MAVLink2 messages, not as parameters
The messages should show in the MissionPlanner MAVLink inspector

Thanks Andrew,

The question arose from the cuav skye airspeed sensor manual.

If you use AP4.30 or later firmware, you need to set the following parameters

  • HYGRO_TYPE = 1(thermometer)

That will be a CAN parameter within the Skye airspeed sensor, not an ArduPilot parameter.
You would need to use the DroneCAN GUI tool or the MissionPlanner DroneCAN UI to check that parameter


I’ve just released plane 4.3.3beta1. This is a minor release with some important fixes:

  • AIRLink LTE module enable pin added
  • CUAV Nora/Nora+ bdshot firmware (allows Bi-directional DShot)
  • CubeOrange, CubeYellow gets fast reset of ICM20602
  • PixPilot-V6 support
  • Attitude and Navigation controllers use real-time dt (better handles variable or slow main loop)
  • Analog rangefinder GPIO pin arming check fixed
  • Arming check of AHRS/EKF vs GPS location disabled if GPS disabled
  • Position Controller limit handling improved to avoid overshooting and hard landings
  • PSC_ANGLE_MAX param reduction causing WPNAV_ACCEL to be set too low fixed
  • Servo gimbal yaw jump to opposite side fixed
  • Siyi A8 gimbal driver’s record video feature fixed
  • SToRM32 serial gimbal driver actual angle reporting fixed (pitch and yaw angle signs were reversed)
  • Takeoff in Auto, Guided fixed when target altitude is current altitude
  • Takeoff in Auto handles baro drift before takeoff
  • Takeoff twitch due to velocity integrator init bug fixed
  • moved FTP MAVLink transfers to FTP thread and better control bandwidth
  • switch to QRTL if indide RTL radius when using Q_RTL_MODE=3 (approach)
  • check for 3 good frames for CRSF
  • allow for ELRS at 420kbaud
  • support MambaH743-v2
  • support MambaF405-2022B
  • fixed nullptr checks on new

Please report test results (good and bad) in this channel!

4 Likes

I flew this today on my SonicModell Binary running the QioTek Zealot H743 with ExpressLRS 3.0. This plane had previously been tuned, but might need re-tuning.

I used “shake to wake” auto takeoff. and manual landing. It was a short flight and it felt great, and I didn’t notice any problems. I thought you might find the log useful.

1 Like

@timtuxworth thanks very much for testing! much appreciated

1 Like

@tridge I wonder if you can help me to understand this log. I think it shows that the pitch controller is off, probably because the pitch estimates are inconsistent, which might be the cause of the pitch oscillation that shows up in my video footage (and also in the logs) as pretty violent bouncing. You can see it at around 18 seconds through to around 35 seconds into this video,

FYI: Elevator is SERVO7
Am I right about that, and if so - what do you think it means about the plane and/or ArduPilot configuration?