Air side splitting for Teensy

[n-snyder]

I may be overlooking something in the code, but I would like to use one serial port off of the flight controller to communicate with both the FrSky receiver and the Sik radio in order to conserve a serial port on the flight controller. I have connected pin 1 to the receiver, and pins 9 and 10 to a flight controller. I would like to use pins 7 and 8 of the Teensy 3.1 to forward and receive Mavlink messages to the sik radio. Does this feature already exist or been done by someone in the community?

[zs6buj]

I will try to create an experimental version for you. Give me a day or two. I tried this in the early days and the mpus did not have enough horsepower, but the code is more streamlined now. There was also a dearth of UARTs, because the USB/flashing port held onto one of them.

[zs6buj]

Could you try V2.16.13 in my github source\experimental folder and let me know. Teensy 3.x only.

[n-snyder]

Thanks for the quick response! I will have the hardware available tomorrow to retest.

I had made a few hacks before you provided code, and tests had shown communication to partially work. Mavlink to GCS and FrSky S.Port telemetry worked as long as there were not sudden orientation changes in the FC. After a sudden orientation change, it appears that the buffer filled, and the delay was pretty big before the Teensy caught up.

If the problem persists after testing with your code changes, I will try again with a Teensy 4.0. I've already made the code changes for compatibility.

I have a few questions regarding the updates:

• Why are you using Ground mode? What necessary functions were missing when I was trying with air mode?
• What was the rationale for adding Rssi_Pacemaker and RSSI_Override to the code? Am I correct to disable these to trigger the FrSky receiver to declare no telemetry data when the buffer is full and a delay takes place?

[zs6buj]

@n-snyder:

All noted. I can't reply adequately right now. We are boarding a plane shortly and I'm not sure if we will have wifi on board Maybe. Otherwise I'll hopefully able to respond properly by Friday.

[n-snyder]

No worries, thanks.

[zs6buj]

Nate, regarding your questions :

In Air Mode, Frsky packets must be interleaved into the stream of sensor frames visible on the receiver SPort, so we must read and parse the SPort stream until we find our chosen DIY sensor frame, then inject our frame.

In Ground mode, we are talking to opentx running on the Taranis (or compatible) rc controller via a buffered UART which gets polled in a round robin fashion, so we may inject a frame anytime. We never need to read the S.Port on the Taranis et al in these circumstances, and data traffic is one way.

Regarding RSSI, yaapu's LUA script, or Flightdeck, expect to receive a regular RSSI frame, or they report "telemetry lost" . The minimum frequency appears to be around 1 Hz, or maybe a little less. Since we are receiving Mavlink RSSI frames into MAV2PT, sometimes across a delayed link and passing then through to the receiver S.Port, it sometimes happens that the RSSI frame arrives outside of the minimum time threshold and we hear the dreaded "telemetry lost" announcement. The rssi_pacemaker inside MAV2PT keeps track of the frequency of rssi frames, and repeats the most recent rssi frame if the minimum time threshold is about to be exceeded.

[zs6buj]

P.S. I'm keen to hear how well the Teensy 4.x works in this application. The Coretex M7 should be more than adequate. There is some code in MAV2PT to monitor buffer usage, but you might need to add some printf() debugging.

[n-snyder]

Eric, it has been a while. My github account has been suspended for a long time from an erroneous auto-detect infraction. Support tickets are taking a crazy long time now.

Today, we successfully tested the Teensy 4.0 functionality on the bench. We should be flying with it in the next two weeks. The libraries for the Teensy 4.x are pretty different from the Teensy 3.x. There are 3 changes that affect FrSky_Ports.h:

1. First the Teensy 4.0 is a 32-bit.
2. The UART nomenclature has changed LPUART1_CTRL.
3. The flag for inversion and half-duplex has changed.

The primary code change is at the end of the RP2040 block.

#if (defined TEENSY)
#  if (Target_Board == 2) // Teensy 4.x
    uartC3x = &LPUART1_CTRL;
    uint8_t formatCode = 0x0;
    if (frInvert)
    {
        formatCode += 0x30; // format code for rx and tx inversion
    }
#    if (defined Teensy_One_Wire)
    formatCode += 0x200; // format code for half-duplex
#    endif
    frSerial.begin(frBaud, formatCode);
#  else // Teensy 3.x
    frSerial.begin(frBaud); // tx pin hard wired
#    if (frPort_Serial == 1)
        // Manipulate UART registers for F.Port working
    uartC3 = &UART0_C3; // UART0 is Serial1
    if (frInvert)
    {                    // For S.Port not F.Port
        UART0_C3 = 0x10; // Invert Serial1 Tx levels
        UART0_S2 = 0x10; // Invert Serial1 Rx levels;
    }
#      if (defined Teensy_One_Wire) // default
    UART0_C1 = 0xA0; // Switch Serial1 to single wire (half-duplex) mode
    Log.printf("FrSky 1-wire half-duplex on Teensy3.x pin %d \n", fr_txPin);
#      else
    Log.printf(" and 2-wire full-duplex on Teensy3.x pins rx=%d  tx=%x\n", fr_rxPin, fr_txPin);
#      endif
    /*
        UART0_C3 |= 0x20;    // Switch F.Port into send mode
        UART0_C3 ^= 0x20;    // Switch F.Port into receive mode
        */

#    else
    uartC3 = &UART2_C3; // UART2 is Serial3
    if (frInvert)
    {
        UART2_C3 = 0x10; // Invert Serial1 Tx levels
        UART2_S2 = 0x10; // Invert Serial1 Rx levels;
    }
#     if (defined Teensy_One_Wire)
    UART2_C1 = 0xA0; // Switch Serial1 to single wire mode
    Log.printf(" and 1-wire half-duplex on Teensy3.x pin %d \n", fr_txPin);
#     else
    Log.printf(" and 2-wire full-duplex on Teensy3.x pins rx=%d  tx=%x\n", fr_rxPin, fr_txPin);
#     endif

#    endif

#  endif

#endif

[zs6buj]

Hey Nate

Thank you for solving the mysteries of the Teensy 4.0 UART registers. I definitely want to try this myself, but I'm still 11,000km from home. I guess I'll order a 4.0 if it's likely to be delivered here anytime soon. Did you test the responsiveness yet with Mavlink in and out?

[thatsnailguy]

Hi Eric,

I posted on AP discourse too in reference to Teensy 4 support. I finally found this post again that I thought I remembered had Teensy 4.0 working. So sorry to ping you twice.

Since Teensy 3x seems to be EOL, I am very interested in Teensy 4 support. Would this be a relatively simple implementation?