thanks Colin.
I checked the logs, and I’m seeing zero current (under 0.001 amps) with both your 4.2.0 log and your 4.1.7 log.
I also loaded the parameters from your 4.2.0 log onto a CubeOrange here with a standard yellow power brick and it did read current and voltage correctly.
I have reproduced the RSSI issue, and I have a fix here:
I’ll include this fix in 4.2.1
Thanks for reporting the issue!
Any thoughts on my previous error report a few posts back? After booting up it gives some cheerful sounding beeps then just sits there emitting a constant tone.
sorry for the slow reply.
I flew a plane with a MatekH743-Wing (v1) yesterday with no issue on 4.2.0.
I just loaded a H743-Wing v2 now via STM32CubeProgrammer from arduplane_with_bl.hex. Interestingly, on the first boot it did as you described, beeped and didn’t show up a port to connect to. Power cycled it again and it was fine.
One thing about the MatekH743-Wing is it stores parameters in the last 2 sectors of flash, so updating via DFU doesn’t wipe parameters. Can you try resetting parameters first then updating? Do that either by loading 4.1.7 and setting FORMAT_VERSION to 0 or by loading a different vehicle type (eg. copter).
Well that was interesting. I set FORMAT_VERSION to 1 while running 4.1.7, then upgraded the firmware via Mission Planner to 4.2. On the first boot it came up fine, so I loaded up my saved parameter file from 4.1.7 and wrote it to the hardware. A few warnings about readonly parameters but so far so good. I then power-cycled the board by unplugging the USB and plugging it back in, and when it started up again it gave the starting-up trill but then got stuck on the last note and just played a continuous tone.
I’ve just released plane 4.2.1beta1. This is a minor release on top of the 4.2 firmware. It has a number of bug fixes and safety improvements. The changes are:
fixed a bug in handling wrap in log download when 500 logs are on the microSD card
added FlyingMoonF407 and FlyingMoonF427 support
fixed RSSI input on the RCIN pin on CubeBlack and CubeOrange
fixed update of gyro FFT throttle tracking
removed unhealthy reporting on airspeed sensors with negative pressure as this commonly happens on VTOL takeoff
improved handling of large LOITER_TURNS mission items, expanding maximum to 2.5km
added fuel usage integration on Lutan EFI
refuse arming in AUTO when in a landing sequence due to a failsafe
account for sprung throttle (from RC_OPTIONS) in throttle suppression code
improved safety of in-flight compass learning
fixed automatic airspeed ratio calibration for 2nd airspeed sensor
increase safety of GUIDED → AUTO takeoff sequence used by QGC
added CAN_Dx_UC_ESC_OF parameter for ESC offset for bandwidth efficiency
The most important fixes are related to how QGC (which is often used on modern GCS style transmitters) does automatic takeoff with the “swipe right for takeoff” system. QGC does a sequence of a change to GUIDED mode, then arming, then change to AUTO mode. That sequence is dangerous if the current waypoint is not properly reset to a VTOL
takeoff. To fix this a number of changes were made to ensure that takeoff is done with a valid VTOL takeoff. The changes include handling of failsafe events (such as GCS or RC failsafe) part way through this takeoff sequence. If QRTL or RTL is engaged during this sequence then the vehicle will switch to QLAND.
One of the changes users may notice is the throttle suppression change for sprung throttles. The change is that if you clear the RC_OPTIONS bit “Arming check throttle for 0 input” then we now assume you have a sprung throttle, and the throttle will be at neutral (close to trim, which will should around 1500) when you arm. In that case when you arm in QLOITER or GUIDED mode then the VTOL motors stay at idle until the throttle stick goes above the throttle trim plus the dead zone. This will be most noticeable in QLOITER, as stabilization won’t start until you push up the throttle, whereas previously the motors would have started stabilizing as soon as you arm (as it saw 50% throttle input). The reason for the change is to ensure that when armed in GUIDED mode we don’t immediately go to an “is-flying” state due to raised throttle when you have a sprung throttle.
please tell us what flight controller you are using, and provide a telemetry log of it working with 4.1, and a telemetry log of it not working with 4.2
I don’t remember users reported this with H743-WING V2. In the past, some users reported that the V1 had stuck booting with 3.9/4.0. I haven’t heard much about this in recent one year. I usually do full chip erase before flashing in DFU mode with STM32CubeProg.
in both those logs the OSD is disabled as OSD_TYPE=0. For the DJI MSP OSD you must set OSD_TYPE=3
See the documentation here: MSP OSD — Plane documentation
I’ve just released plane 4.2.1 stable. This is a minor release with the following changes since 4.2.1beta1:
fixed handling of safety state on boards with no safety switch
fixed bug where a false positive could trigger quadplane landing disarm while land repositioning is active
For completeness, here are the changes from beta1 over the 4.2.0 release:
fixed a bug in handling wrap in log download when 500 logs are on the microSD card
added FlyingMoonF407 and FlyingMoonF427 support
fixed RSSI input on the RCIN pin on CubeBlack and CubeOrange
fixed update of gyro FFT throttle tracking
removed unhealthy reporting on airspeed sensors with negative pressure as this commonly happens on VTOL takeoff
improved handling of large LOITER_TURNS mission items, expanding maximum to 2.5km
added fuel usage integration on Lutan EFI
refuse arming in AUTO when in a landing sequence due to a failsafe
account for sprung throttle (from RC_OPTIONS) in throttle suppression code
improved safety of in-flight compass learning
fixed automatic airspeed ratio calibration for 2nd airspeed sensor
increase safety of GUIDED → AUTO takeoff sequence used by QGC
added CAN_Dx_UC_ESC_OF parameter for ESC offset for bandwidth efficiency
The most important fixes are related to how QGC (which is often used on modern GCS style transmitters) does automatic takeoff with the “swipe right for takeoff” system. QGC does a sequence of a change to GUIDED mode, then arming, then change to AUTO mode. That sequence is dangerous if the current waypoint is not properly reset to a VTOL takeoff. To fix this a number of changes were made to ensure that takeoff is done with a valid VTOL takeoff. The changes include handling of failsafe events (such as GCS or RC failsafe) part way through this takeoff sequence. If QRTL or RTL is engaged during this sequence then the vehicle will switch to QLAND.
One of the changes users may notice is the throttle suppression change for sprung throttles. The change is that if you clear the RC_OPTIONS bit “Arming check throttle for 0 input” then we now assume you have a sprung throttle, and the throttle will be at neutral (close to trim, which will should around 1500) when you arm. In that case when you arm in QLOITER or GUIDED mode then the VTOL motors stay at idle until the throttle stick goes above the throttle trim plus the dead zone. This will be most noticeable in QLOITER, as stabilization won’t start until you push up the throttle, whereas previously the motors would have started stabilizing as soon as you arm (as it saw 50% throttle input). The reason for the change is to ensure that when armed in GUIDED mode we don’t immediately go to an “is-flying” state due to raised throttle when you have a sprung throttle.
I’ve had one other report of that, and it was caused by Q_M_PWM_MIN and Q_M_PWM_MAX both being set to zero.
Please post a bin log while running a motor test with LOG_DISARMED=1 to help diagnose