Rover-4.2.0-beta3 released for beta testing!

Rover-4.2.0-beta3 has been released for beta testing and can be installed using the ground station’s (MP’s, QGC’s) beta firmware link or it can be directly downloaded from

Changes vs -beta2 are in the release-notes and copied below.

  1. Minor Enhancements
    a) BATT_OPTIONS supports sending resting voltage (corrected for internal resistance) to the ground station
    b) KakuteH7-bdshot support
    c) MatekH743 uses a 32 bit timer to resolve occasional 68ms timing glitch
    d) RC input protocol text message sent to GCS (helps pilot awareness during RC handover)
  2. Bug fixes
    a) Balance bot stands in acro mode even with no GPS
    b) Battery remaining percentage fixed when using Sum battery
    c) DShot reversal bug with IOMCU based boards (see SERVO_BLH_RVMASK)
    d) DShot commands fixed (could cause random motor movements)
    e) GPS blending fix that could have resulted in the wrong GPS being used for a short time
    f) Param conversion bug (impacted airspeed enable)
    g) RC handover between IOMCU RC input and a secondary RC input on a serial port fixed
    h) QioTek Zealot H743 SLCAN port and relays fixed

Although we are only at -beta3, 4.2.0 is already looking quite stable and the next release will probably be a “release candidate”.

Any testing and feedback is greatly appreciated!

1 Like

with beta3 after a while I get an internal error 0x800.
It is a new rover using Matek H743-Mini and MatekH743-bdshot
I thought I try this beta3 to check, if BLHeli BDSHOT telemetry is working in the meantime… but no luck :slight_smile:

Here is a log with LOG_DISARMED=1. Just powered up and let it untouched until the WDT reboot occurs.

No luck. Sequentially I did this (test at home, no GPS lock):

  • Start with v4.00 stable (last stable with acro working).
  • Program v4.2 beta 3:
    31/03/2022 18:21:15 : RCOut: Brush:1-8 PWM:9-14
    31/03/2022 18:21:15 : Pixhawk1 004B0036 3436510A 32393637
    31/03/2022 18:21:15 : ChibiOS: 93e6e03d
    31/03/2022 18:21:15 : ArduRover V4.2.0-beta3 (32c42613)

    (message also heard)
  • Force arm. Altough tilting manually both in Manual and Acro, wheels turned correctly, it didn’t keep standing at all in both modes. Trying some parameters change (ATC_xx, BAL_xx) didn’t help.
  • Back to v4.00 stable. All was normal again.
  • Program v4.2 beta 3 again, just in case: no change.
  • Back to v4.00 stable. All was normal again.

v4.00 stable parameters.
v4.2 beta 3 parameters.
Not seen any significant difference, apart from new ones (OA_xx, PRX_xx, …).

I can’t remember exactly but I saw that message about pin 50 in the past, possibly with some version v4.1.x, but I didn’t try farther because of the problem in Acro.

EDIT: not exactly. Started with some beta v4.2.

Hi @Webillo,

Thanks very much for testing this.

Ok, so you’re saying that the balancebot doesn’t stand in any mode with 4.2.x?

If this is the case then I think there is some lower level issue perhaps with the brushed motor control because my balancebot definitely does work but it is using a PWM->brushed motor controller.

I confirm that the balance bot doesn’t stand in any mode with v4.2beta3 dated 20220330 (in adition message "Relay1 pin 50 invalid appears in MP hud and is heard), but the situation is different for previous v4.2betas.

I keep the .apj file for a v4.2beta dated 20220312. For it (test at home, no GPS lock (test on a different balance bot lower and with smaller wheels just in case (no change))):

  • in Acro wheels don’t obey to manual tilting, just as stables v4.1.x;
  • in Manual wheels movement obeys to hand manual tilting, but doesn’t stand at all, just as v4.2beta3;
  • message “Relay1 pin 50 invalid” appears in MP hud when arming and is heard.

In stable versions v4.1.x, Manual&Hold modes work, but in Acro wheels don’t obey to hand manual tilting, and left on ground it falls immediately.

Motors are DC with encoders. This is the controller (Pololu based on MAX14870, meant for Arduino (there is a similar one meant for Raspberry Pi)) and cabling (Pixhawk 6 AUXs, 2 MAINs):

  • Controller red/black thick (2): supply from 3S battery.
  • Controller yellow/green thick (2+2): to motors.
  • Controller white thin from AUXs (2, pins 50 and 51): M1DIR M2DIR.
  • Controller blue thin from MAIN’s (2): M1PWM M2PWM.
  • Pixhawk yellow/green on AUXs (4, pins 52 to 55): from encoders.

On all v4.1.x it worked on Manual and Hold, and on Acro wheels didn’t obey to hand manual tilting and it fell immediately when left on ground. No message “Relay1 pin 50 invalid”.

Perhaps the cause for message "Relay1 pin 50 invalid (appearing on v4.2betas, it seems to be coincident with apparently correct wheels movement with hand manual tilting in Manual or Acro, but falling immediately when left on ground) should be found and tested first. Parameters and configuration above have worked for years in v4.00 and previous.


Thanks for the report. I’ve added it to our 4.2 issues list and we do have a dshot fix coming in the next beta so if we are lucky this may resolve the issue.


I think the issue is related to the removal of the BRD_PWM_COUNT which was used to configure whether the AUX ports were used for GPIO or PWM.

The new method is to set the SERVOx_FUNCTION = -1 (GPIO) so could you try setting these two parameters?


Sorry about this, we neglected to include a mention of this change in the release notes.

hello, what version will be bdshot for matek f765-wing? I know about a lot of peripherals and few free processor pins, but still?

That’s it! Like night and day; thanks a lot. Now v4.2beta3 works in Manual, Acro and Hold very well (I’ll try Auto shortly), with no more “Relay1 pin 50 invalid” messages.

BTW1, as far as I know FC common general purpose I/O pins can be:

  • Output:
    • PWM with servo timing (servos, conventional ESC’s…)
    • PWM duty cycle (DC motors)
    • On/off signals (direction control, relays…)
  • Input (encoders, rpm).
  • Bidirectional (bdshot)

but not every pin can be anything, IOMCU pins can have more restrictions, and signals may be grouped.
Somewhere describing how those pin functions relate to parameters would be convenient.

BTW2, from always for Rover:

  • ACRO_TURN_RATE controls how the pilot’s input is converted to a desired turn rate in Acro mode. This parameter can be reduced to make turns in Acro mode more docile for the driver
  • ATC_STR_RAT_MAX is the maximum turn rate that the vehicle will ever attempt in any mode. This should normally be kept close to the vehicle’s performance limits so the vehicle remains agile

ACRO_TURN_RATE works in a balance bot in Acro, but in Manual I find steering always fast no matter how low I set ATC_STR_RAT_MAX. What can I try?

1 Like

On a simple encoders test at home, I cannot see WENC messages at all on a .bin file.
Examining what happened in v4.00 this is obtained from a .bin file one day before (balance bot going back and forth in Auto):

WENC distances and WENC messages.


It looks like we don’t have a -bdshot version for the MatekF765-wing (see here) and it is not listged as one of the boards that support it using the default firmware (see list here on the wiki)

@andyp1per should we add a -bdshot version for this board?

1 Like

That Matek board is EOL…

1 Like


Great news that the balance bot is mostly working.

I think the wheel encoder issue is very similar and that you will need to set:


Yes! I created a topic where a person promised to do this but apparently busy.

Please note that I found it impossible to prevent DMA sharing with I2C1. I don’t know whether this will impact performance or not but needs testing.

Thanks, I’ll be sure to test

That’s it! Thanks a lot.
This is the result of a home test, moreless 12m straight, turn left 180º and return: and APM Planner 2 can read the .bin log, but MP fails:

Then it keeps scanning forever. See this.

1 Like

I don’t understand how to make the firmware using this link, can you help me again