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
while trying to find the root cause i rather accidentally noticed that setting the serial baudrate to 1 (=1200) actually produces correct telemetry output at 19200 baud, plus the issue really isn‘t limited to LTM telemetry, it occurs when using mavlink too.
so i‘m assuming some issue in AP_SerialManager‘s baudrate setting
while doing some more testing i found that the 1200 baud-issue is limited to UARTs 1 and 6 that use an individual APB2 clock divider, so likely an issue with 1200 baud being just beyond the limits of ChibiOS uart-driver’s BRR register.
ahh, interesting, thanks for looking into this!
We should probably add a note to the docs for LTM
What is the use case for this? I was think that maybe this could be an option for saving bandwidth on a low power Dragonlink receiver and thus increasing the range.
Due to total fire bans here I will be unable to test fly the 4.0.3 release myself in the next few days. I’d really appreciate logs from anyone who can fly the beta. I will not release the stable version until I have a good set of test logs.
marc, i‘m not sure if using LTM on the DL‘s radio modem option really adds any benefit as compared to using the emulated dragonlink mavlink option on the DL‘s „internal“ telemetry. it‘d be worth testing that though.
still i think that when using a micro- or nano-rx, the DL telemetry downlink will always be the weakest link in your setup, due to the compareably low transmitted power, plus using a directive antenna on your RC transmitter usually adds quite some inconvenience.
that‘s why transmitting LTM over your AV audio is a neat option, as it allows adding telemetry onto an existing link without range or bandwidth limitations.
the above linked converter allows to connect a small „dongle“ containig a FSK modem and an ESP8266 to your video receiver‘s audio output, and have your telemetry downlink broadcasted wirelessly over wifi/UDP for visualisation on whatever mavlink-compatible GCS you prefer, like QGC on an iphone for example.
Logfile: Anmelden – MagentaCLOUD
Everything works as usual. Nice flight (4.0.3beta1 , F405-Wing, ASW28).
1 Like
I see. Would you need an FSK modem at each end? Which ones work? Did you put up something on RCGroups?
there’s an ardupilot wiki page up on LTM now that’s quite comprehensive: https://ardupilot.org/plane/docs/common-ltm-telemetry.html?highlight=ltm
plus some more information on the TCM3105-type FSK modems on RCG: https://www.rcgroups.com/forums/showthread.php?2963807-FSK-Modem-in-RC-Obsolete-or-a-hidden-gem
https://www.rcgroups.com/forums/showthread.php?1157558-New-Audio-Modem-Protocol-For-FPV-Telemetry
you’d need one of those on each end if LTM over AV audio is what your going for.
basti.
Thx. The ICs are easy to get. Pity the PCBs are $4 each. I think it is a good idea for long range telemetry. Mavlink is great but such a bandwidth hog.