The Matek F765 web site shows it supports CTs7/Rts7: Uart7_CTS/RTS for ArduPilot Telem1 on Serial1. Is this implemented with the new 4.02? I’m unable to see any options to enable it.
Thanks,
it isn’t, and it should be, sorry. It is fixed in master, and I’ve put a fix in for 4.0.3. Thanks for letting me know!
Thanks Tridge, truly appreciate all the work you do with this.
How is work going no more than one compass on UAVCAN like 2 x Here2 gps units ?
Today I have calibrated with GPS Fix. Now Compass scale has collected a nonzero value
COMPASS_SCALE = 1,236598
ok, that should work, but it is a bit higher than expected
What is a new feature in the settings SERVO13_FUNCTION 120 for MATEK F765_WING
Dear developers! Please help deal with this issue, I can not sleep at night, thinking about this secret function.
According to latest master, it’s neopixel LED function. https://github.com/ArduPilot/ardupilot/blob/master/libraries/SRV_Channel/SRV_Channel.h
Thanks for the quick response. Now I can sleep at night, the secret function does not affect the quality of flight, and no animal will die from SERVO_FUNCTION13. This number 13 sometimes does terrible things.
1 Like
Today I have recalibrated again the compass of my HERE2 with GPS LOCK but this time by WIFI instead of USB cable. And there is an important difference:
By USB cable> COMPASS_SCALE = 1,236598
By WIFI > COMPASS_SCALE = 1,138366
This last time is a value closer to 1.17.
What can we think?
it is better. Just like the offsets, the estimate for scale factor is affected by the environment you calibrate in. The small error of 0.032 won’t make a significant difference, but you can adjust COMPASS_SCALE to be 1.17 if you like.
but you have commented that it is better that it be set automatically than manually set to 1.17
That is because if the value is significantly off from 1.17 then it affects the other values (offsets, diagonals, off-diagonals). The value of 1.17 is always correct on the Here2 GPS, but if you just manually correct from a value a long way off from 1.17 then you may be left with poor values for the other parameters.
OK, now I have understood. Thanks
What parameter would be more appropriate to modify to correct a very small Roll oscillation in QLOITER mode of one Quaplane?
Q_A_RAT_RLL_P or Q_P_POSXY_P?
it could be either or neither. You’d need to look at the log to find the cause.
@tridge likely not a plane-specific issue, but LTM telemetry doesn’t seem to work at 1200 baud. it does work well on 2400 bd though. will try to debug.
btw: here’s an LTM to MAVLink converter, allows using LTM with standard MAVLink type GCSes: LTM to MAVLink converter
cheers, basti.
Hi,
I just want to double check if the Matek F405-CTR AIO is compatible with the Arduplane FW.
Thanks
I’ve just released plane 4.0.3beta1. This is a minor release with a few bug fixes and enhancements. The changes are:
- prevent failsafe action from overriding a VTOL land
- fixed compass calibration failures with auto-rotation detection
- fixed errors on STM32H7 I2C (affects CubeOrange and Durandal)
- fixed a race condition in FrSky passthrough telemetry
- fixed DSM/Spektrum parsing for 22ms protocols
- added fixed yaw compass calibration method
- re-generated magnetic field tables
- ensure SERIAL0_PROTOCOL is mavlink on boot
The most important fix is for FrSky pass-through telemetry. Pass
through telemetry support had a race condition which could lead to the flight controller generating a fault and rebooting. Until you are running a firmware with the fix you should disable FrSky pass-through telemetry by changing SERIALn_PROTOCOL from 10 to 0 on the port where you have SPort enabled.
Test reports very welcome!
2 Likes
well this may explain the reboots on the bench every now and then
Frsky pass-through issue