FrSky D-type telemetry broken for Pixhawk v2 since v1.1.2

[spinorkit]

Bug Report

FrSky D-type telemetry is broken for my PixHawk v2 in PX4 version 1.7.2 (current stable and also dev). It works if I go back to v1.1.2 and use an extras.txt file with: frsky_telemetry start -d /dev/ttyS6

It fails to work both with and without the extras.txt file.

[spinorkit]

I wired up a FTDI console and this is the output for an uncalibrated system with v1.1.2 with the telemetry working: sercon: Registering CDC/ACM serial driver sercon: Successfully registered the CDC/ACM serial driver [i] microSD mounted: /fs/microsd param: selected parameter default file /fs/mtd_params [param] Loaded: /fs/mtd_params rgbled on I2C bus 1 at 0x55 (bus: 100 KHz, max: 100 KHz) 1: SYS_USE_IO: match 2100: + SYS_AUTOSTART: match px4io: CRCs match dataman: Power on restart, data manager file '/fs/microsd/dataman' size is 103090 bytes MS5611_SPI on SPI bus 1 at 3 (11000 KHz) bst: no devices found adc init done ver hwcmp match: PX4FMU_V2 HMC5883_I2C on I2C bus 1 at 0x1e (bus: 100 KHz, max: 400 KHz) hmc5883: no device on bus 1 mpu6000: driver start failed MPU6000 on SPI bus 1 at 4 (1000 KHz) L3GD20 on SPI bus 1 at 1 (11000 KHz) LSM303D on SPI bus 1 at 2 (11000 KHz) Airspeed on I2C bus 1 at 0x28 (bus: 100 KHz, max: 100 KHz) px4io default PWM output device mavlink_if0: mode: 0, data rate: 1200 B/s on /dev/ttyS1 @ 57600B mavlink_if0: offboard mission init: ERROR ver hwcmp match: PX4FMU_V2 sdlog2: log buffer size: 12288 bytes [i] FIXED WING [i] Mixer: /etc/mixers/easystar.main.mix on /dev/pwm_output0 [i] Mixer: /etc/mixers/pass.aux.mix on /dev/pwm_output1

[i] Addons script: /fs/microsd/etc/extras.txt gps: module found: UBX ver hwcmp match: PX4FMU_V2 px4flow [174:100] px4flow: scanning I2C buses for device.. mavlink_if1: mode: 5, data rate: 800000 B/s on /dev/ttyACM0 @ 57600B INFO filter ref off: baro_alt: -198.4133

NuttShell (NSH) nsh> telem> SENSOR FAILSAFE! RETURN TO LAND IMMEDIATELY commander_low_prio: settings saved. mavlink_if0: Disabling hardware flow control telem> PREFLIGHT FAIL: MAG #0 UNCALIBRATED telem> PREFLIGHT FAIL: MAG #1 UNCALIBRATED telem> PREFLIGHT FAIL: ACCEL #0 UNCALIBRATED telem> PREFLIGHT FAIL: ACCEL #1 UNCALIBRATED telem> PREFLIGHT FAIL: GYRO #0 UNCALIBRATED telem> PREFLIGHT FAIL: GYRO #1 UNCALIBRATED telem> AIRSPEED WARNING: WIND OR CALIBRATION ISSUE

---

Here is the output from v1.7.2dev. At the end I tried manually starting the telemetry. It said it was already running, but my transmitter still does not appear to be receiving telemetry.

INFO [driversboardspx4fmu-v2] Ver 0x8 : Rev 0 V2 [boot] Fault Log info File No 4 Length 3177 flags:0x01 state:1 [boot] Fault Log is Armed sercon: Registering CDC/ACM serial driver sercon: Successfully registered the CDC/ACM serial driver HW arch: PX4FMU_V2 HW type: V2 HW version: 0x00090008 HW revision: 0x00000000 FW git-hash: 370da895731294dc58d160b217603a528c3fde0a FW version: 1.7.2 0 (17236480) OS: NuttX OS version: Release 7.22.0 (118882559) OS git-hash: b18053574bf41712cef93e31bf178518f451a350 Build datetime: Dec 26 2017 21:08:33 Build uri: localhost Toolchain: GNU GCC, 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496] MFGUID: 353434393233470a001e002a MCU: STM32F42x, rev. Y

WARNING WARNING WARNING! Revision Y has a silicon errata: This device can only utilize a maximum of 1MB flash safely! https://pixhawk.org/help/errata

UID: 1E002A:3233470A:35343439 [i] microSD mounted: /fs/microsd [hardfault_log] Fault Log is Armed INFO [param] selected parameter default file /fs/mtd_params rgbled on I2C bus 1 at 0x55 (bus: 100 KHz, max: 100 KHz) nsh: rgbled_pwm: command not found MS5611_SPI on SPI bus 4 at 3 (20000 KHz) WARN [ms5611] no device on bus 4 MS5611_SPI on SPI bus 1 at 3 (20000 KHz) nsh: bst: command not found HMC5883_I2C on I2C bus 1 at 0x1e (bus: 100 KHz, max: 400 KHz) WARN [lis3mdl] no device on bus 2 WARN [hmc5883] no device on bus 2 (type: 1) WARN [mpu6000] no device on bus 3 MPU6000 on SPI bus 1 at 4 (1000 KHz) INFO [mpu6000] accel cutoff set to 30.00 Hz INFO [mpu6000] gyro cutoff set to 30.00 Hz WARN [mpu6000] no device on bus 5 WARN [mpu9250] probe failed! 104 WARN [mpu9250] no device on bus 3 WARN [mpu9250] probe failed! 255 WARN [mpu9250] no device on bus 4 L3GD20 on SPI bus 1 at 1 (11000 KHz) LSM303D on SPI bus 1 at 2 (11000 KHz) WARN [sdp3x_airspeed] not started on bus 1 WARN [sdp3x_airspeed] not started on bus 2 WARN [ms5525_airspeed] not started on bus 1 Airspeed on I2C bus 1 at 0x28 (bus: 100 KHz, max: 100 KHz) nsh: ets_airspeed: command not found nsh: ets_airspeed: command not found INFO [load_mon] stack check enabled ERROR [param] Parameter UAVCAN_ENABLE not found INFO [px4io] default PWM output device INFO [mavlink] mode: Normal, data rate: 1200 B/s on /dev/ttyS1 @ 57600B INFO [mavlink] mode: OSD, data rate: 1000 B/s on /dev/ttyS2 @ 57600B ERROR [param] Parameter UAVCAN_ENABLE not found px4flow [210:100] WARN [px4flow] scanning I2C buses for device.. INFO [mavlink] mode: Config, data rate: 800000 B/s on /dev/ttyACM0 @ 57600B INFO [logger] logger started (mode=all) INFO [init] Mixer: /etc/mixers/AETRFG.main.mix on /dev/pwm_output0 INFO [init] Mixer: /etc/mixers/pass.aux.mix on /dev/pwm_output1

Addons script: /fs/microsd/etc/extras.txt

NuttShell (NSH) nsh> INFO [lib__ecl] EKF aligned, (pressure height, IMU buf: 22, OBS buf: 14)

nsh> frsky_telemetry start -d /dev/ttyS6 ERROR [frsky_telemetry] frsky_telemetry already running nsh>

[spinorkit]

I checked the telemetry output (Serial 5) on the PixHawk with v1.7.2 using a scope and there is serial data at about 9600 baud on it (I don't currently have a convenient way to connect it to an FTDI input). So I guess the format must have changed since v1.1.2?

[LorenzMeier]

We did change the format. The updated documentation is here: https://docs.px4.io/en/peripherals/frsky_telemetry.html

[spinorkit]

Oh, thanks. That explains it I'm using the standard FrSky support built into ersky9x.

[spinorkit]

I think that using a scope to look at the serial data is not useful, since there are bursts of 9600 baud serial data every ~100ms irrespective of whether a working version is used or not.

I also think the problem is not due to the format change, since I set up a build environment and changed the D-type format back to the way it was when it was working. With this change the telemetry is still broken.

I have narrowed down the breaking change to between v1.2.0 (21 Feb 2016) and v1.3.0RC2 (6 May 2016). When I run v1.2.0 without and extras.txt file and start the telemetry manually via the console I get the message: "sending FrSky D type telemetry" while with v1.3.0RC2 and later this message does not appear in the console.

I suspect the breaking change is that in v1.2.0 frksky_telemetry.c the line } else if (status >= 0) { meant that it would go into D type mode by default if no bytes were read, which is the case when connected to e.g. my D8RII-plus receiver.

In the v1.7.2 code it never gets out of the initial scanning loop.

[spinorkit]

After adding an optional command line option to force the telemetry type to either SPORT or DTYPE, DTYPE Frsky telemetry in v1.7.2 is now working for me.

[LorenzMeier]

Would you be motivated to change that to a parameter or, which would be preferred, dig into why the auto-detection is not working?

[LorenzMeier]

I'm closing this for now and hope to get a pull request from you. Thanks!

[spinorkit]

The autodetection is not working for D-type telemetry because it relies on serial data coming out of the receiver into the PixHawk and there is none (I have connected the wire anyway). I chose the command line option because I did not want to break anything and I have no clue what Frsky system was used when the frsky_parse_host() function in frsky_data.c was written. I thought only the X receivers would output serial (two-way link to tx). An alternative would be to run a SPORT detection only in the loop and time it out after a while and drop into D-type mode if SPORT input was not detected. However, the command line option is harmless and I still seem to need the extras.txt file anyway to start the telemetry in v1.7.2 (stable with my fix).

[LorenzMeier]

Your proposal seems to make sense (timing out). What I'd like to have is an option in QGroundControl to enable a specific peripheral e.g. on TELEM2 and not force users to fiddle with the SD card.

That way users could configure everything through the app and would not need to know if they have SPORT or D-type.