So I’m trying to understand the development process (especially between releases), and was curious:
I completely understand it’s impractical to list down all the changes that have happened under the hood, in the release notes. However, if I wanted to see the changes would that be on GitHub (whether it’s merged PRs, issues fixed, etc)?
Let me know if this is not the correct place for this post, thanks.
I’m seeing problems with 4.2 stable on my Matek H743 wing v2. I programmed the “arduplane_with_bl.hex” file using STM32CubeProgrammer and when it was done I unplugged the USB cable to the FC and plugged it back in. It gave a cheerful series of beeps but then gave a single continuous beep and MissionPlanner was unable to connect to it.
I updated the firmware to 4.2.0, a message appeared on the screen: Getting Param MAVFTP 1-1:@PARAM\param.pck. Please explain what this means. On the Matek 743 flight controller, this message disappears quickly, on another Durondal this message within a minute. This message has a normal event or there is a problem with the firmware?
I liked the new firmware functions, it is very convenient for quickly setting up the flight controller, for example, TRIMRC / SERVO SAVE, I really dreamed of having such a tune option. Thank you for your great work!
that is MissionPlanner fetching your parameters using the MAVFtp protocol. The MAVftp way of fetching parameters is approximately 10x faster than the old method (varies with type of link)
It is normal for this message to appear. If it stays up for a long time you may need to update to latest beta of MissionPlanner which fixes an issue with MAVftp
Hello! I am also experiencing issues with similarly configured rxrssi (rssi pin 103, voltage range set to 0.38 to 3.3). Looks like SBUS pin problem. Updated from 4.0.9 to 4.2.0. Board - chinese clone of Pixhawk (common 2.4.8). Before rxrssi was working flawlessly, after update 0 all the time. If you need another logs, tell me.
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!
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).