FrSky telemetry (yaapu) working on F405, failing on BB Blue

iter · December 22, 2020, 2:43am

I have 4 airframes with working FrSky/yaapu telemetry. All 4 use STM32 UCs. I’m building a new setup around a Beaglebone Blue. Most of the functionality is working, but I’m failing to bring up yaapu telemetry. I built from plane4.0 branch, tag Arduplane-stable).

I’m using a 232 cable from Amazon. The cable is good (tested on F405). I have it plugged into UART01. UART01 and its corresponding port assignment to SERIAL2 (-D /dev/ttyO1) work. If I connect a GPS to UART01 and set SERIAL2_PROTOCOL,5, I get GPS data. When I’m trying to get yaapu telemetry on this port, I set SERIAL2_PROTOCOL to 10.

This is the trace I get. The receiver seems to be polling every 12 milliseconds, but BBBL responds only to id 0x00:

Here’s a zoom on the response:

For reference, here’s the same trace from an F405 WING, where yaapu telementry is working correctly, and the uC responds to many of the messages:

iter · December 30, 2020, 6:49am

On @tridge’s suggestion, I tried to disable the conditional checking that the serial send completes in 6.5ms (lines 205…208 below). I get a different trace now, but still nothing on Taranis. I traced only the half-duplex line this time. You can see AP respond to more queries. Second screenshot is a zoom-in on one of the queries and responses. I’m attaching a 10-second trace if anyone wants to look at the data in more detail: passthrough.zip (24.4 KB)

github.com

ArduPilot/ardupilot/blob/e6c5382a28a31c4fb09bb44c36a549c419138af3/libraries/AP_Frsky_Telem/AP_Frsky_SPort.cpp#L195-L208


/*
  check that we haven't been too slow in responding to the new
  UART data. If we respond too late then we will overwrite the next
  polling frame.
  SPort poll-to-poll period is 11.65ms, a frame takes 1.38ms
  but specs require we release the bus before 8ms leaving us with 6500us
 */
const uint64_t tend_us = port->receive_time_constraint_us(1);
const uint64_t now_us = AP_HAL::micros64();
const uint64_t tdelay_us = now_us - tend_us;
if (tdelay_us > 6500) {
    // we've been too slow in responding
    return;
}

juvinski · May 14, 2021, 1:49am

Hi @iter,

have you had any update on it ?

iter · May 14, 2021, 3:25am

No. I ended up using Mavlink to Passthrough with a separate board on the airframe with BBBl.