I assume you mean RCMAP and the ordering between TX modules? That certainly is an issue, and the user needs to be careful to use receivers with the same channel ordering.
The decoder locks onto one of them and only goes looking for the other receiver if the first one stops giving data.
The feature certainly could be better. I actually added it as the PH4-mini needs both serial and pulse input on separate pins to match the plug labels, but I thought I should enable it for all boards as there are some good use cases.
Cheers, Tridge
Today I updated a motorglider ASW-28 to 4.0.0beta1 (F405-Wing,M8N-GPS,external Compass,Frsky-Telemetry,WiFi-Telemtry). All works fine (Manual, FBWA, Cruise). Thanks to Tridge and everyone else involved in the development.
The best approach is to upgrade the firmware in-place, so that the automatic parameter conversion takes place. So load 3.9.11, load your old parameters, then load 4.0.0beta2 and during boot it will automatically convert your parameters.
We had 6 successful flights yesterday on beta2, and we would appreciate a quick glance at a log. I’m finding an error message of “invalid channel option (2)” on the logs. BlHeli ESC RPM is still reporting positive when reverse thrust is enabled. Stall prevention works well. I also think that Batt2 (supposed to be BLHeli by configuration) is not actually using the sum of the ESC currents because it matches Batt1. Cube Blue with mini carrier board, Here2 CAN, BlHeli ESC’s. https://we.tl/t-tUUN1tO1MU
The log shows you have RC1_OPTION=2. It is lucky that this is an invalid option, as option 2 is “flip” (for copters). Having that on channel 1 would make for some interesting flying!
I suspect your parameters became corrupt somehow. I suggest you check through them.
For example, you have RC8_OPTION=68. Is that deliberate?
uneventfull flights on plane4 beta, no difference to be expected compared to master though. that’s great!
@tridge while tinkering i ran into an issue with BLH_AUTO set to 1, using non-mulitrotor motors and BLH telemetry set active. it puts my board into an infinite watchdog reboot loop until i disconnect the telemetry wire or set motor mask manually.
as far as i understand the code, motor mask gets multirotor motors only, not throttle (left/right) on traditional fixed wing setups. i’m not sure this is intentional. if so, imho it should be documented or fixed to include SERVO_FUNCTION 70 , 73 and 74 too.
hope there’s something useful in there as the board won’t boot to runtime with repective settings active.
plus i stand corrected: BLH_AUTO param description refers to multirotor motors only indeed. intuitively i‘d suggest to have motor mask check for k_throttle(left/right) on plane / qplane builds too, but it‘s beyond my scope to tell if that causes problems in other places motor mask is used. however, setting BLH_AUTO to 1 without having multirotor motors specified shouldn‘t trigger wdg to kick in imho. on a sidenote, this only happens with the esc tlmtry wire connected and the esc powered, that‘s why i assumed it‘s rather related to esc tlmtry handling than a genuine motor mask issue.
thanks for looking into this!
did some more testing with debug enabled and it seems there‘s two issues:
1.: BLH_AUTO motor mask handling seems to not only check for multirotor motors defined in SERVOn_FUNCTION, but also if they‘re actually connected, powered and initialized. num_motors and motor_mask returns 0 otherwise.
2.: serial manager is unhappy with BLH_AUTO enabled && BLH telemetry active but motor_mask returning 0, this is what triggers resets. this likely happens whenever a trad fixed wing motor is used with BLH ESC but not pointed at using additional BLH_MASK bitmap while BLH_AUTO = 1.
i tried adding a check in serial manager for num_motors != 0 and it successfully prevents triggering wdg resets. not sure if it‘s a good approach worth PRing though…
