Frsky telemetry and spektrum receivers - RC Groups
Thread Tools
Nov 06, 2017, 08:02 PM
Registered User
Discussion

Frsky telemetry and spektrum receivers


So, in the ever continuing discussion about compatibility between big brands and the new (and sometimes better) Chinese radio gear coming out, I haven't seen this question posed: Can I plug FrSky, Quanum, etc. telemetry add ons (altitude, GPS, airspeed, etc.) into a Spektrum receiver?? I'm not willing to chance using an potentially non-compatible receiver with a Spektrum Tx but add ons are a different story.....do they work? What do I need to receive and decode the data? Can this be done during flying or can I only download and check the information on a laptop or similar after the flight?
Sign up now
to remove ads between posts
Nov 06, 2017, 08:11 PM
Sagitta Fanboy
No.

There's no compatibility between telemetry systems aside from some 3rd party sensors which support multiple protocols via software configuration or adapter units.
Nov 06, 2017, 08:13 PM
AndyKunz's Avatar
I can't answer that directly, but we published the interface specification for Spektrum radios with the hope that people would experiment and know what they're doing when they do.

If they're not compatible, it's because they chose not to be. Others have chosen differently and are riding the compatibility train to the bank with us.

Andy
Nov 06, 2017, 09:04 PM
Sagitta Fanboy
Quote:
Originally Posted by AndyKunz
I can't answer that directly, but we published the interface specification for Spektrum radios with the hope that people would experiment and know what they're doing when they do.

If they're not compatible, it's because they chose not to be. Others have chosen differently and are riding the compatibility train to the bank with us.

Andy
Andy, FrSky's certainly been riding their system to the bank, having what's probably the fastest growing system and enjoying 3rd party support that might be surprising to some (S.Port is probably the second best supported sensor bus and certainly in the quad arena S.Port is far better supported than X-Bus).

FrSky chose a very different and far more flexible bus design. Rather than having the transmitter firmware dictate what messages and data are valid, frSky chose to define a basic set of sensors and let sensor manufacturers design their own set and either contribute support in OpenTX, or write LUA scrips for support. This has allowed rapid deployment of the capability to control LRS systems like Crossfire TBS, to program and monitor FC's directly from the TX, to offer VTX control and to offer receiver programming directly from the TX.

This isn't to say Spektrum's approach is bad. You've chosen to control the user experience and work with other vendors to add support within your normal release cycle. The walled garden approach has its advantages, especially in providing customer support. But you do pay a price in flexibility and the ability to rapidly bring new capability to market.
Nov 07, 2017, 03:55 AM
Registered User
Kambalunga's Avatar
However, it doesn't change the fact that I2C (X-BUS) is easier to handle than S.PORT. I2C is an industry standard, S. PORT is something proprietary. XBUS is also better documented or show me the original Frsky S.PORT documentation and I don't mean some reverse engineered manuals.
Spektrum Telemetry Specs.
Open source means to participate and not only to demand.
Spektrum Telemetry, make DIY sensors !
Nov 07, 2017, 04:16 AM
Registered User
I2C uses 4 wires... S.PORT uses 3 wires which is a bit more standard in RC connectors. The MAIN issue i have with I2C is that multiple sensors in one chip required multiple I2C master addresses, which is not supported in many chips. That is what the telemetry for Spektrum is partially supported in Powerbox System, where all other brands have all the telemetry data. With a single Arduino chip you can send every sensor ID you want for FrSky.

Yes S.PORT uses Single wire Bus Master inverted TTL levels UART BUT at a standard baud rate. Many chips support Hardware TTL inversion already and a Single Wire Bus Master system is used by MANY MANY RC systems already. Almost every program card uses that method, ECU terminals do to.

So not a bad choice from FrSky although non inverted TTL would be much easier for the little hobby chips
Nov 07, 2017, 05:00 AM
Registered User
Kambalunga's Avatar
Quote:
Originally Posted by Tadango
I2C uses 4 wires... S.PORT uses 3 wires which is a bit more standard in RC connectors. The MAIN issue i have with I2C is that multiple sensors in one chip required multiple I2C master addresses, which is not supported in many chips.
You mixup multi slave with multimaster.
Sensors are slave and TM or RX is the I2C-Master.
Sure SPORT has one wire less. Some times is less more. In this chase more problems. Causes more protocol overhang.
Limits the data throughput and is neither backward nor upward compatible. Your datarate rate is fixed.

Quote:
That is what the telemetry for Spektrum is partially supported in Powerbox System, where all other brands have all the telemetry data. With a single Arduino chip you can send every sensor ID you want for FrSky.
Again Spektrum sensors are I2C slaves and it's possible that a sensor is a multislave. An example is GPS or ECU sensor.
Something that ATmegas, ATXmegas, ARMs, PICs and other MCUs can do.

Quote:
Yes S.PORT uses Single wire Bus Master inverted TTL levels UART BUT at a standard baud rate. Many chips support Hardware TTL inversion already and a Single Wire Bus Master system is used by MANY MANY RC systems already. Almost every program card uses that method, ECU terminals do to.
As example the Arduinos don't support hardware TTL inversion.
Quote:
So not a bad choice from FrSky although non inverted TTL would be much easier for the little hobby chips
But also not a good choice.
Last edited by Kambalunga; Nov 07, 2017 at 05:09 AM.
Nov 07, 2017, 06:12 AM
Registered User
Quote:
Originally Posted by Kambalunga
You mixup multi slave with multimaster.
Eeh.. yes i did


Quote:
Originally Posted by Kambalunga
Again Spektrum sensors are I2C slaves and it's possible that a sensor is a multislave. An example is GPS or ECU sensor.
Something that ATmegas, ATXmegas, ARMs, PICs and other MCUs can do.
That will always be a limitation by the MCU used. PowerBox chips cannot handle multiple I2C slave addresses by hardware. Many standard libraries cannot do it also.

Quote:
Originally Posted by Kambalunga
As example the Arduinos don't support hardware TTL inversion.

But also not a good choice.
True, that is were SoftwareSerial comes in handy, but it is less then optimal. Works just fine for DIY projects
Nov 07, 2017, 06:39 AM
Registered User
Kambalunga's Avatar
Quote:
Originally Posted by Tadango

That will always be a limitation by the MCU used. PowerBox chips cannot handle multiple I2C slave addresses by hardware. Many standard libraries cannot do it also.
What PowerBoX chips?
Multislave with Atmel MCUs is really not rocket science.
No need for special libraries.
Just a little brainwork and not even that any more.

Code:
 /* Ardunino as an I2C Slave   12-01-2013
  * Example for a Ardunino emulate multiple I2C slaves.
  * SETUP:
  * Arduino analog input 5 - I2C SCL
  * Arduino analog input 4 - I2C SDA
  *
  *  The TM1000 works with 3.3V logic level! Pullups are the master job (TM1000). 
  *  3.3V Arduinios are the better choice. 
  */

 #include <WireMW.h>//A sligth modified non blocking Wire libary.


 byte tmpSpektrumData1[] = {0x18,0x00,0xff,0x00,0xff,0x00,0x01,0x02,0xff,0x02,0x02,0x03,0x00,0x08,0x00,0x00};//1.I2C adress,then 0x0, then data Current
 byte tmpSpektrumData2[] = {0x20,0x00,0x01,0xff,0x00,0x0f,0x01,0xf6,0x00,0xad,0x02,0x23,0x03,0x65,0x22,0x32};// 1.I2C adress,then 0x0, then data Powerbox-Sensor
 byte tmpSpektrumData3[] = {0x34,0x00,0xff,0x00,0xff,0x00,0xff,0x00,0x00,0x00,0x00,0x00,0xff,0x00,0x00,0x00};//Data string 1.I2C adress,then 0x0, Capactysensor 0x34
 
 
 int greenLEDPin = 12;
 int redLEDPin = 13;

 byte i2cAdress1 = tmpSpektrumData1[0];
 byte i2cAdress2 = tmpSpektrumData2[0];
 byte i2cAdress3 = tmpSpektrumData3[0];

 void setup()
{

   Wire.begin(i2cAdress1);  // Initialize I2C lib & setup slave's I2C addresses. 
  
 
  TWAMR = 0xFE ;// Set the bit mask XOR value from Adress 1 to 3
         
   Wire.onRequest(requestEvent);//Register the function requestData this is called when the TM1000 requests data from this slave devices. 
     pinMode(greenLEDPin, OUTPUT);
    pinMode(redLEDPin, OUTPUT);
   digitalWrite(redLEDPin, LOW);
 }

 void loop()

 {
 
 
  digitalWrite(greenLEDPin, HIGH);
  delay(100);
  digitalWrite(greenLEDPin, LOW);
  delay(100);
  
  
 }

 void requestEvent()//Called after the TM1000 requests data from this multi slave device.

 {
  uint8_t Called_Adress =(TWDR >> 1);// The called adress from the I2C master (TM1000)
     
 digitalWrite(redLEDPin, HIGH); // Shown that an event are catched, it's a test function only  
 
 if (Called_Adress == i2cAdress1)//If x == 0x18 then send tmpSpektrumdata1 from 0x18
 { 
  Wire.write(tmpSpektrumData1, 16);//Wire.write(byteData, length) send the arrary tmpSpektrumData1 to the TM1000
 }   

 if (Called_Adress == i2cAdress2)//If x == 0x20 then send tmpSpektrumdata2 adress 0x20
 { 
  Wire.write(tmpSpektrumData2, 16);//Wire.write(byteData, length) send the arrary tmpSpektrumData2 to the TM1000
 }

 
 if (Called_Adress == i2cAdress3)//If x == 0x34 then send tmpSpektrumdata6 from 0x34
 { 
  Wire.write(tmpSpektrumData3, 16);//Wire.write(byteData, length) send the arrary tmpSpektrumData3 to the TM1000
 }   

 }
Quote:
True, that is were SoftwareSerial comes in handy, but it is less then optimal. Works just fine for DIY projects
and limit your max possible data rate.
Nov 07, 2017, 07:16 AM
Registered User
Quote:
Originally Posted by Kambalunga
What PowerBoX chips?
Multislave with Atmel MCUs is really not rocket science.
No need for special libraries.
Just a little brainwork and not even that any more.

Code:
 /* Ardunino as an I2C Slave   12-01-2013
  * Example for a Ardunino emulate multiple I2C slaves.
  * SETUP:
  * Arduino analog input 5 - I2C SCL
  * Arduino analog input 4 - I2C SDA
  *
  *  The TM1000 works with 3.3V logic level! Pullups are the master job (TM1000). 
  *  3.3V Arduinios are the better choice. 
  */

 #include <WireMW.h>//A sligth modified non blocking Wire libary.


 byte tmpSpektrumData1[] = {0x18,0x00,0xff,0x00,0xff,0x00,0x01,0x02,0xff,0x02,0x02,0x03,0x00,0x08,0x00,0x00};//1.I2C adress,then 0x0, then data Current
 byte tmpSpektrumData2[] = {0x20,0x00,0x01,0xff,0x00,0x0f,0x01,0xf6,0x00,0xad,0x02,0x23,0x03,0x65,0x22,0x32};// 1.I2C adress,then 0x0, then data Powerbox-Sensor
 byte tmpSpektrumData3[] = {0x34,0x00,0xff,0x00,0xff,0x00,0xff,0x00,0x00,0x00,0x00,0x00,0xff,0x00,0x00,0x00};//Data string 1.I2C adress,then 0x0, Capactysensor 0x34
 
 
 int greenLEDPin = 12;
 int redLEDPin = 13;

 byte i2cAdress1 = tmpSpektrumData1[0];
 byte i2cAdress2 = tmpSpektrumData2[0];
 byte i2cAdress3 = tmpSpektrumData3[0];

 void setup()
{

   Wire.begin(i2cAdress1);  // Initialize I2C lib & setup slave's I2C addresses. 
  
 
  TWAMR = 0xFE ;// Set the bit mask XOR value from Adress 1 to 3
         
   Wire.onRequest(requestEvent);//Register the function requestData this is called when the TM1000 requests data from this slave devices. 
     pinMode(greenLEDPin, OUTPUT);
    pinMode(redLEDPin, OUTPUT);
   digitalWrite(redLEDPin, LOW);
 }

 void loop()

 {
 
 
  digitalWrite(greenLEDPin, HIGH);
  delay(100);
  digitalWrite(greenLEDPin, LOW);
  delay(100);
  
  
 }

 void requestEvent()//Called after the TM1000 requests data from this multi slave device.

 {
  uint8_t Called_Adress =(TWDR >> 1);// The called adress from the I2C master (TM1000)
     
 digitalWrite(redLEDPin, HIGH); // Shown that an event are catched, it's a test function only  
 
 if (Called_Adress == i2cAdress1)//If x == 0x18 then send tmpSpektrumdata1 from 0x18
 { 
  Wire.write(tmpSpektrumData1, 16);//Wire.write(byteData, length) send the arrary tmpSpektrumData1 to the TM1000
 }   

 if (Called_Adress == i2cAdress2)//If x == 0x20 then send tmpSpektrumdata2 adress 0x20
 { 
  Wire.write(tmpSpektrumData2, 16);//Wire.write(byteData, length) send the arrary tmpSpektrumData2 to the TM1000
 }

 
 if (Called_Adress == i2cAdress3)//If x == 0x34 then send tmpSpektrumdata6 from 0x34
 { 
  Wire.write(tmpSpektrumData3, 16);//Wire.write(byteData, length) send the arrary tmpSpektrumData3 to the TM1000
 }   

 }

and limit your max possible data rate.
I don't know what chips they use but the programmer explained the limited Spektrum telemetry due 1 I2C address limit.

Data rate has been incredible with SoftwareSerial I don't see any limit there....
Nov 07, 2017, 09:27 AM
Registered User
Kambalunga's Avatar
Quote:
Originally Posted by Tadango
I don't know what chips they use but the programmer explained the limited Spektrum telemetry due 1 I2C address limit.
First what typ of powerbox mean you?
There is no 1 I2C adress limit. Maybe read the Spektrum telemetry docu first.

Quote:
Data rate has been incredible with SoftwareSerial I don't see any limit there....
When 57600bps is fast enough for you. The XBUS data rate of 100000bps or 400000bps is compared with this warp speed!
Last edited by Kambalunga; Nov 07, 2017 at 09:32 AM.
Nov 07, 2017, 11:50 AM
Registered User
Quote:
Originally Posted by Kambalunga
First what typ of powerbox mean you?
There is no 1 I2C adress limit. Maybe read the Spektrum telemetry docu first.
I mean every Powerbox product (https://www.powerbox-systems.com). I know the Spektrum protocol and have created sensors myself. Many libraries are limited to 1 I2C address when using hardware I2C. Arduino has the same limitation.....
Nov 07, 2017, 11:57 AM
AndyKunz's Avatar
Library limitations are why I run on the bare metal.

Andy
Nov 07, 2017, 12:12 PM
Registered User
Kambalunga's Avatar
Same here. In addition, He can't distinguish between sensor internal bus and external bus. That's what makes him fail.
Nov 09, 2017, 01:27 PM
Registered User
So, to dumb it back down to my level, FrSky and others (speaking analogously, of course) have gone the LINUX route whereas Spektrum has gone the OS route.......


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
New Product FD802 Tiny Frsky 8CH Telemetry RSSI Receiver Compatible FRSKY ACCST X9D(Plus)DJT/DFT/ galkre Radios 2 Jan 03, 2017 05:31 PM
Help! How to easily setup voltage telemetry on FRSky DHT DIY Kit and D4R-II receiver? Atleee Radios 1 Oct 16, 2012 11:40 AM
Poll Should FrSky make Futaba FASST telemetry receivers before futaba! ScottSails Radios 1 May 16, 2012 12:18 AM
Discussion FrSky 6 channel Receiver with Telemetry! Fly2High Hand Launch 9 Nov 13, 2010 03:44 PM