Thread Tools
Nov 10, 2016, 06:41 PM
Thread OP

Spektrum Serial Telemetry Receiver (SPM4649T) Interfacing

I'm starting this thread as a means to discuss the documentation and interfacing protocol with the new Spektrum Serial Telemetry Rx (SPM4649T) linked below.
I'd like to keep this discussion on the topic of development to support this receiver. Any inquiries about the receiver on a more general level should be made in this post.

There are 3 documents to be referenced for this receiver, all which will be updated as the protocol is further developed. They can be found in this github repository

Spektrum Bi-Directional SRXL
This document describes the electrical/hardware specifications for interfacing with the receiver, as well as the software protocol for packetizing data.

This header file will contain 16 byte structs for all the sensor types that can be sent to the receiver using the Spektrum Bi-Directional SRXL protocol.

Spektrum Remote Receiver Interfacing
This document is mainly relevant because the SPM4649T currently sends receiver data in the same format as our existing remote receivers (aka Sat Rx's). This assures compatibility with existing flight controllers. Later on, we intend to implement a new protocol that will be included in the Spektrum Bi-Directional SRXL document.

Despite these documents being available, I'd like to post a summary of what is needed to support bi-directional data with the new receiver. For more details refer to the documents.

Telemetry will be bidirectional UART at 115200 baud rate. This means setting up the UART to operate on a single pin in half duplex. For STM32 FC's, this has to be done on the TX pin of the UART, not RX. This should be simple for F3’s since the RX and TX pins are interchangeable. On F4’s and I believe F1’s however, it can only be done on the TX pin. Receiver transmissions will alternate between phase 0 and phase 1 (Refer to Spektrum Remote Receiver Interfacing document to see how the phase bit is extracted from serial data). Once a phase 0 packet is received on the FC from the receiver, the FC should reply a telemetry packet right after processing the incoming rx packet. You’ll have to make sure this transmission doesn’t trigger the RX interrupt since it’s on the same line.

The telemetry packet sent out is as follows.
<0xA5><0x80><Length><16-byte telemetry packet><2 Byte CRC of payload>
The <Length> shall be 0x15 (length of the 16-byte telemetry packet + overhead).

Here is an example of the CRC function for a telemetry packet.

#define SRXL_POLY 0x1021
void sectionOfSomeTelemetrySendFunction(){

uint16_t crc = 0x0000;

for (uint8_t i = 0; i < 16; i++)
crc = srxlCrc16(crc, telemetry.packet.payloadData[i], SRXL_POLY);

telemetry.packet.crc = crc;

uint16_t srxlCrc16(uint16_t crc, uint8_t data, uint16_t poly)
crc = crc ^ data << 8;
for (int i = 0; i < 8; i++)
if (crc & 0x8000)
crc = crc << 1 ^ poly;
crc = crc << 1;
return crc;

The 16 byte telemetry packet (payload) will contain data in formats specified in the header file at the end of the “Specifications for Spektrum XBUS Telemetry Sensors” document.

Finally, the last thing to take into consideration is what the telemetry receiver expects to receive from the flight controller. The structs referred to here are part of the “spektrumTelemetrySensors.h” file.

The telemetry receiver will always send the following packet types back to the transmitter in the following order, and then start again from the beginning. Changing the order in which the flight controller sends packets won’t affect how quickly the receiver sends them. This order must be followed at this time. This may be changed in the future to give full control over packet priority to the flight controller.
STRU_TELE_QOS (Flight log) -> STRU_TELE_RPM(RPM/Volts/Temperature) - > “Any packet”

This means that the flight controller must abide by this pattern, and send these data packet types to the receiver in the same order.

On the current firmware, the receiver ignores any flight log data that the FC provides, and builds its own flight log instead. This will be changed in the future, so it would be good practice to include a flight log transmission that uses the correct packet ID, but leaves the rest of the values set to 0xFFFF.

This packet can include flight pack voltage, rpm, temperature, and RSSI. The receiver can capture all these values internally and use those, but if external values are provided through serial telemetry, it will use those instead (with the exception of RSSI).
For parameters in this struct that won’t be used, also set the value to 0xFFFF (For temperature, use 0x7FFF).

“Any Packet”
For this packet, you can use any of the data types included in the telemetry document. These can follow a cycle of its own (a sub cyle of the main 3 packet cycles?).
How these additional packets are prioritized depends entirely on the flight controller, and can be changed however desired (based on flight mode, whether armed or not, etc)

This should be enough info to get people implementing the protocol, but if there are any questions or if you feel like there are missing details in the documentation, questions can be answered by either me or Andy Kunz.


EDIT: Reorganized files and posted them on github. Struct file is now separate from XBUS document.
Last edited by MiguelAlvarez; Dec 16, 2016 at 03:36 PM. Reason: Reorganized files and posted them on github. Struct file is now separate from XBUS document.
Sign up now
to remove ads between posts
Nov 10, 2016, 06:42 PM
Thread OP
Nov 10, 2016, 07:11 PM
AndyKunz's Avatar
I would just like to point out one major difference between this telemetry method and what we have in the TM1000 and telemetry receivers (ARxxxxT family).

In the other receivers, there is an enumeration state at power-on during which the telemetry host (TM1000 or ARxxxxT) polls the bus. After that completes, ONLY those devices will be polled in the future.

With the SPM4649T, any telemetry device message can be sent at any time (hard timing requirements in the document). We take advantage of this with the new Text device, which we foresee as useful for FC vendors to display a message on the transmitter screen to help the customer walk through programming the FC using his stick inputs, for instance. Most of the time the FC will not be putting out messages on this ID, but when it does post them, they will likely be in a burst.

This new mode also means that the Auto-Config function may need to be executed multiple times in order to capture all devices, if a device ID is not transmitted during the 5-second Auto-Config window. The alternative is to have the FC do an auto-config mode from the other side, sending all the data for all devices multiple times during the 5 seconds. We don't foresee this to be a big deal.

Nov 11, 2016, 09:48 AM
Registered User
And you still could manually select your desired telemetry device.
The whole doc looks very promising. I especially like the text transmission. This could be very helpful for all kinds of FC or FBL systems.
Flybarless+SPM4649T= Forward programming or whatever you call it
Nov 11, 2016, 09:59 AM
AndyKunz's Avatar
No, that's still "stick programming" but made easier. Forward Programming is different.

Nov 11, 2016, 01:40 PM
Registered User
Hm. Sound like "Forward Programming" is Spektrum's Duke Nukem Forever.

Don't tell marketing new stuff which is not ready....

At least you can interactively program a FC. Maybe using 2 trims, one to select the various values, the other to increase/decrease them.
Nov 12, 2016, 02:44 AM
Registered User
Wooo! I can see its not listed above, but i would hope it works for my gen 2 black edition dx7 as well... And that its fairly as easy to bind through clean flight/betaflight. ��
Nov 12, 2016, 09:04 AM
AndyKunz's Avatar
The DX7G2 will be updated at the same time as all the other G2 transmitters. And because it's DSM2 and DSMX, it will continue to bind with all DSM2 and DSMX receivers.

Nov 12, 2016, 04:09 PM
Registered User
JulianGoesPro's Avatar
- please delete -
Nov 12, 2016, 04:13 PM
Registered User
JulianGoesPro's Avatar
Originally Posted by MiguelAlvarez
Spektrum Bi-Directional SRXL
Was about time we get Bi-Directional Protocols in our hobby... I am a bit sick of all those wires

Nov 12, 2016, 06:08 PM
Registered User
Single point of failure
Nov 12, 2016, 07:01 PM
Registered User
JulianGoesPro's Avatar
Originally Posted by Mukenukem
Single point of failure
haha, are you starting the "is it better to have one 10TB drive or 10 1TB drives to fit all backups" argument?
Nov 13, 2016, 03:47 AM
Registered User

Unfortuneatly Spektrum Telemetry licence is not GPL compatible

MiguelAlvarez, it's great that Spektrum are moving to opening up their telemetry protocol. Unfortunately the licence is not GPL compatible.

If Spektrum want their telemetry to be supported by GPL flight control software such as Betaflight, Cleanflight and iNav then it needs to be released under a GPL compatible licence.

Perhaps you could talk to the relevant people in Spektrum to do this.
Nov 13, 2016, 09:05 AM
AndyKunz's Avatar
And perhaps we already worked that out with our Legal department before we started sharing code with the Betaflight guys...

You CAN have multiple licenses for the same product for different groups.

Nov 13, 2016, 10:32 AM
Registered User
Originally Posted by JulianGoesPro
haha, are you starting the "is it better to have one 10TB drive or 10 1TB drives to fit all backups" argument?
I have a raid 1 at home and a single disk at work. The raid at home is synced to the single disk at work. Backup is just in one direction.

Quick Reply

Thread Tools