Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 9 of 9

Thread: Teensy 4.1 RC transmitter - TBS crossfire

  1. #1
    Junior Member
    Join Date
    Aug 2020
    Posts
    14

    Teensy 4.1 RC transmitter - TBS crossfire

    Hi all I am new here ,

    I am planning to build a RC transmitter using a teensy 4.1 and a TBS crossfire transmitter module (+using their receiver). Telemetry is very important for me!
    Maybe you can answer the things I don't know and give general advice or tips.

    Things I know:
    the TBS crossfire module communicates over ppm
    binding works without any external software just by using the internal menu of the module

    Things I don't know:
    which type of data do I send to the module eg. int's or whatever?
    do I need any drivers? I don't think so because the module "just" reads the ppm data...

    Thank you in advance!
    And sorry for my bad English - I am from Austria...
    Best regards

  2. #2
    Senior Member
    Join Date
    Mar 2016
    Posts
    217
    PPM, to me implies a fairly low data rate though my RC knowledge is >10 years old. From the TBS docs, I couldn't see how data is delivered by the receiver. If it is just a PPM signal then I wonder how much data throughput you will get. You essentially get N positions within a frame and you can express Log2 N bits worth of data. If there are 1024 pulse positions, you can send 10 bits per frame. Are they using 22.5 mS frames (common in RC gear)? Then it all depends on how much granularity you have for the pulse position within the frame. If you have around 20 microsecond granularity, then you can transmit 10 bits per frame which gives you an approximately 440 baud channel. Not terribly wide. Those numbers are all just guesses, by the way. You may have to test the real system to see how far you can push it. Also, channels are interleaved so there is a further reduction in the number of frames a given channel gets. I remember some (admittedly ancient) RC gear that delivered one frame per second per channel.

    Assuming you can get a reasonable data rate, you need to define a protocol. Header, length, data, sequence and crc. You can send ints or what ever units you want. If you have lots of channel capacity, you might consider sending the data in human readable form (ascii) for easy debugging.

    On the other hand, if you have a fairly narrow channel, you might want to do a lot of compression on it and just use a parity bit.

    Maybe there is a better encoding with higher data rates available. PPM was designed for resilience in a noisy environment.

    And, your English is fine. Better than some native speakers...

  3. #3
    what range do you need? How much data do you anticipate sending?

  4. #4
    Junior Member
    Join Date
    Aug 2020
    Posts
    14
    @PhilB
    Thank you so much for your explanations!

    I looked in their docs and found out that the receiver talks over crsf to the flight controller and the transmitter with crsf or ppm to the radio control. As much as I know is, that the transmitter module is an uC itself.

    I am a bit confused now because crsf is a protocol...

    But maybe the crsf is the protocol for the ppm communication?

    You said noisy environment? But isn't it not necessary for the internal communication (double negation) how much noise is out there?

    Thanks for your compliment!
    The most difficult part at speaking/writing English is that German sentences are structured differently.

    @KrisKasprzak
    I don't have much requirements, about 5 miles would be great. I don't know how much data I need to transmit, just about 16 channels to a racing quad. But I think that shouldn't be a big amount of data, but I should be fast...

    Thank you both for helping me
    Best regards!

  5. #5
    Senior Member
    Join Date
    Mar 2016
    Posts
    217
    Protocol is an overused word - I wouldn't get too worried about. You will have one that allows you to understand your data, it will be transmitted via another protocol and the low level radios may have yet another protocol. Your protocol may be as simple as the order in which different pieces of data are sent though I would consider creating a separate packet type for each data item you want to send.

    It looks like CRSF is a proprietary TBS protocol. You will need to understand how to hand your data to the transmitter and retrieve it from the receiver. In the end, it is just a bunch of bits to be sent/received. Is there an API document or similar? It should tell you how.

  6. #6
    Junior Member
    Join Date
    Aug 2020
    Posts
    14
    I am just confused because TBS says it's ppm or CRSF. But for me it seems like CRSF over ppm. That would make sense.
    I can't find much about CRSF. If I contact the company again, what should I ask?

  7. #7
    Senior Member
    Join Date
    Mar 2016
    Posts
    217
    I dunno, ask for sample code or an API.

  8. #8
    Junior Member
    Join Date
    Aug 2020
    Posts
    14
    Thanks, will do that!

  9. #9
    Junior Member
    Join Date
    Aug 2020
    Posts
    14
    Just got a reply from TBS - they gave me the whole protocol documentation!!!
    I am not allowed to publish it but I will publish the finished software for the Teensy 4.1
    Basically it's just UART not ppm.
    The UART runs at 416k BAUD.

    Thanks @PhilB for your kind help and explanations - I am sure that this thread will not be my last thread about this topic
    Best regards

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •