Taranis telemetry questions;

General Help and support for the Taranis Radio.
Post Reply
Anker
Posts: 7
Joined: Mon Jul 28, 2014 7:00 am
Country: -

Taranis telemetry questions;

Post by Anker »

Today, I fly Graupner HoTT. - I am considering to switch to OpenTX.

A few questions:
Is the telemetry somehow interactive ? with Graupner, I can tune PID's - load and save mission plans, waypoints , and change other values of the flight controller using HoTT telemetry.
Is it possible to use OpenTX's telemetry /custom screens in a similar way ?

Can the telemetry custom screens be filled with any text that the flight controller provide ?

User avatar
dvogonen
Posts: 453
Joined: Tue Jan 31, 2012 9:38 pm
Country: Sweden
Location: Stockholm

Re: Sv: Taranis telemetry questions;

Post by dvogonen »

Graupner HoTT uses an open telemetry protocol and work is ongoing in several controller projects to integrate both PID settings directly from the transmitter and free telemetry data like text etc. This is naturally a huge deal since it makes it possible to both query and set controller configuration during flight.

FrSky uses a closed telemetry format, which blocks implementation of these features.

At the moment Graupner HoTT offers more functionality than OpenTX in this area and the gap is growing.
User avatar
jhsa
Posts: 19480
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: Taranis telemetry questions;

Post by jhsa »

hmmm, I can see the open source comunity start to turn their heads towards Graupner. They were clever. The problem is still the price of the equipment?
do they sell modules? If not, can the TX firmware be changed?

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: Re : Taranis telemetry questions;

Post by Kilrah »

The Graupner protocol isn't more open than FrSky's, some major guys like mikrokopter had access to it in about the same way we do with frsky, but then the open source implementations were made by the community via reverse engineering.
Don't forget the Graupner system has been around for about 3 years longer and yet these things are just starting.

Frsky protocol allows for bidirectional communication too, BUT as it's the beginning it has never been used by any device yet so there is no defined way to interact with it so far and no code has been written to use it.

So it's something that will have to be implemented, hopefully even better than on other platforms... We now have the awesome advantage of Lua that allows anyone to write custom menus and UIs which aren't possible with others beyond the text based menus on graupner. More details would help i.e what FC, how are you doing it with Graupner, etc...

Sent via mobile
User avatar
jhsa
Posts: 19480
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: Taranis telemetry questions;

Post by jhsa »

does it have to be done ONLY with LUA?? or can be done also the normal way? I think that would be the best for simplicity..

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

Anker
Posts: 7
Joined: Mon Jul 28, 2014 7:00 am
Country: -

Re: Taranis telemetry questions;

Post by Anker »

Regarding "Graupner protocol isn't more open than FrSky's," ;
1.- Graupner never understood the advantage of open source, so it's not open in that sense. However, I just wrote them and told I needed to make something of my own, and recieved all documentation. The quality of documentation is rather ridiculous, but fully understandable. The protocol is very easy to work with.

So they shared all necessary data to emulate all existing HoTT equipment. Mikrokopter people are very secretive about it, (as usual, basically everything there is very over-priced and/or secret) - but despite what they wrote; there is no NDA, no secrets. As I can see it, the only reason the info is not published by graupner, is the amateurish look of the document.

2.- I am surprised to read you suggest that FrSky protocol is not open. - I thought all OpenTX firmware was open, and Taranis/other opensky products were fully open except for hardware ?

The main reason I look towards Taranis - is that I like to use MX-20 - but it's stuck with only 12channels. - they I could go for MC-32 - but I don't like the enormous, self-important, bulky, design with very high sticks.
Currently, I have some implemetation of HoTT in ArduPlane, Some in ArduCopters I fly using another microcontroller between MavLink and Pixhawk - getting full advantage of almost another ground station on my TX - much of the code is related to controlling certain payloads.
It's in no way a simple job to switch, it would almost be easier to make OpenTX accept HoTT compatible serial data (19200bps)
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Taranis telemetry questions;

Post by MikeB »

So the serial data rate is 19200. Have you any idea of how many bytes/sec are actually sent? I ask, because FrSky have SPort serial sensors. You can put one on the Rx and one on the Tx and then you get a, bi-directional, serial data stream between them. The only problem is the actual bytes/sec rate is limited.

Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: Taranis telemetry questions;

Post by Kilrah »

jhsa wrote:does it have to be done ONLY with LUA?? or can be done also the normal way? I think that would be the best for simplicity..
Well, each different remote device will likely require a different matching UI as their parameter sets and needs will be completely different. So a redistributable lua script for each, that whoever who has a device can code makes a lot more sense than dozens of hardcoded screens in the firmware that most people have no use for, and for which the firmware team would have to get samples of each device, and spend the time to do all the job besides the rest. Much easier and quicker for everybody, especially to follow evolution. That's exactly why we have lua.
Anker wrote: 2.- I am surprised to read you suggest that FrSky protocol is not open. - I thought all OpenTX firmware was open, and Taranis/other opensky products were fully open except for hardware ?
The OpenTX firmware is open, but the RF modules, receivers and sensors all run proprietary FrSky firmware.
Same as Graupner, you should ask them for the protocol specs if you want to use them. Or just use the OpenTX source as reference as several have done already to create compatible sensors.
User avatar
dvogonen
Posts: 453
Joined: Tue Jan 31, 2012 9:38 pm
Country: Sweden
Location: Stockholm

Re: Sv: Taranis telemetry questions;

Post by dvogonen »

Kilrah wrote:The Graupner protocol isn't more open than FrSky's,
That is simply not true, please refrain from spreading misinformation.
Anker
Posts: 7
Joined: Mon Jul 28, 2014 7:00 am
Country: -

Re: Taranis telemetry questions;

Post by Anker »

MikeB wrote:So the serial data rate is 19200. Have you any idea of how many bytes/sec are actually sent?.
I sent you all the data I have as PM.
Another useful source of information is Adam's analysis : https://code.google.com/p/hott-for-ardu ... DetailHoTT there's also source and more description of how it works in the wiki.
In short: it works fully - by looking at Adams code, and Mikrokopter's code, you can easily find plenty of examples, - I can provide better struct definitions with better comments on what exactly is in the variables are.

If I remember correctly, the biggest message is the EAM Message (Electric air module) and is 45bytes, only textmode is bigger. Graupner did a decent job reducing the overhead, by using offset values for some values, like transmitting voltage in 100mV units and , RPM's in 10, and temperature with an offset of 20 (0degree = 20) - so it can dislpay ut to -20degree without transmitting a floating point value.

There are 4 kinds of messages "EAM, GAM, GPS, Vario" - plus text mode.
I do agree that LUA is useful, as it could display things neatly and do placing/formatting, instead of stuffing all that into flight controller or another device in the UAS.


An example:

Code: Select all

/* * * * * * * * * * * * *
 * EAM Message structure *
 * * * * * * * * * * * * */
struct {
  uint8_t startByte;
  uint8_t eam_sensor_id;
  uint8_t alarmTone;       /* Alarm */           //#03 1=A 2=B ... or 'A' - 0x40 = 1
                                                                // Q    Min cell voltage sensor 1
                                                                // R    Min Battery 1 voltage sensor 1
                                                                // J    Max Battery 1 voltage sensor 1
                                                                // F    Mim temperature sensor 1
                                                                // H    Max temperature sensor 1
                                                                // S    Min cell voltage sensor 2
                                                                // K    Max cell voltage sensor 2
                                                                // G    Min temperature sensor 2
                                                                // I    Max temperature sensor 2
                                                                // W    Max current
                                                                // V    Max capacity mAh
                                                                // P    Min main power voltage
                                                                // X    Max main power voltage
                                                                // O    Min altitude
                                                                // Z    Max altitude
                                                                // C    (negative) sink rate m/sec to high
                                                                // B    (negative) sink rate m/3sec to high
                                                                // N    climb rate m/sec to high
                                                                // M    climb rate m/3sec to high

  uint8_t sensor_text_id;
  uint16_t alarmInverse; //#05 alarm bitmask. Value is displayed inverted
                                                                //Bit#  Alarm field
                                                                // 0    mAh
                                                                // 1    Battery 1
                                                                // 2    Battery 2
                                                                // 3    Temperature 1
                                                                // 4    Temperature 2
                                                                // 5    Altitude
                                                                // 6    Current
                                                                // 7    Main power voltage
// This is really 2x 8bit vars      int8_t alarm_invers2;                   //#06 alarm bitmask. Value is displayed inverted
                                                                //Bit#  Alarm Field
                                                                // 0    m/s
                                                                // 1    m/3s
                                                                // 2    Altitude (duplicate?)
                                                                // 3    m/s     (duplicate?)                                    
                                                                // 4    m/3s (duplicate?)
                                                                // 5    unknown/unused
                                                                // 6    unknown/unused
                                                                // 7    "ON" sign/text msg active



  uint8_t cell1L;         /* Low Voltage Cell 1-7 in 2mV steps */
  uint8_t cell2L;
  uint8_t cell3L;
  uint8_t cell4L;
  uint8_t cell5L;
  uint8_t cell6L;
  uint8_t cell7L;
  uint8_t cell1H;         /* High Voltage Cell 1-7 in 2mV steps , 124=2.48v */   
  uint8_t cell2H;
  uint8_t cell3H;
  uint8_t cell4H;
  uint8_t cell5H;
  uint8_t cell6H;
  uint8_t cell7H;
  uint16_t battery1;     /* Battery 1 LSB/MSB in 100mv steps; 50 == 5V */
  uint16_t battery2;     /* Battery 2 LSB/MSB in 100mv steps; 50 == 5V */
  uint8_t temp1;         /* Temp 1; Offset of 20. 20 == 0C */
  uint8_t temp2;         /* Temp 2; Offset of 20. 20 == 0C */
  uint16_t height;       /* Height. Offset -500. 500 == 0 */
  uint16_t current;      /* 1 = 0.1A */
  uint16_t driveVoltage; /* Main battery */
  uint16_t capacity;     /* mAh */
  uint16_t climbm2s;     /* climb rate in 0.01m/s; 30000 == 0 */
  uint8_t climbm3s;      /* climb rate in m/3s; 120 == 0 WATCH the 255 (uint8) as max*/
  uint16_t rpm;          /* RPM. 10er steps; 300 == 3000rpm */
  uint8_t minutes;
  uint8_t seconds;
  uint16_t speed;        /* Air speed in km.h */    // moet dit niet een uint8_t zijn!!!!

  uint8_t endByte;
  uint8_t chksum;
} HoTTV4ElectricAirModule;
It seems to me the biggest problem is the loased source of the RX, - if we are not able to control that, we are stuck with one-way telemetry communication on the reciever end. (?)
Last edited by Anker on Tue Jul 29, 2014 7:14 am, edited 1 time in total.
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: Taranis telemetry questions;

Post by Kilrah »

Anker wrote:It seems to me the biggest problem is the loased source of the RX, - if we are not able to control that, we are stuck with one-way telemetry communication on the reciever end. (?)
No, because the RF firmwares already offer bidirectional communication facilities, nothing to change there. As long as code is implemented in OpenTX and the FC to use them and pack/unpack the data in the correct transmission protocol, it should work as it is.
Anker
Posts: 7
Joined: Mon Jul 28, 2014 7:00 am
Country: -

Re: Taranis telemetry questions;

Post by Anker »

nice, What are the limits of this bi-directional communication ? - can it do TTL level RS232 ?, at what speeds and have enough buffer size ?
Using HoTT protocol, is 19200 bps - but tha actual use is much less. Each "sensor" EAM/GAM is polled about once a sec, and responcs with 40-something bytes or less - the presence of all sensors is not required. and each it polled in sequence about 250ms apart.
Textmode is the most bandwidth consuming, 173 bytes. - resending all display contents (originally 8x21characters) every time.
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: Taranis telemetry questions;

Post by Kilrah »

With the UART adapters yes you get transparent UART with guaranteed transfer but max 300 bytes per sec.

Probably makes more sense using the native smart port interface though, which is a muxed transmit/receive UART at 57600bps.
The receiver polls devices every 12ms and gives them an opportunity to send a 7-byte packet. That one is not guaranteed to arrived, and usually used to send one individual telemetry value.
How often a device gets polled depends on the number of devices on the bus.
Anker
Posts: 7
Joined: Mon Jul 28, 2014 7:00 am
Country: -

Re: Taranis telemetry questions;

Post by Anker »

3 seconds ago I were browsing the OpenTX source , and found files like mavlink and ardupilot under telemetry ?
Is there some projects like that already ? - All I could find were people who do a tranlating approach between mavlink protocol and S.port.
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: Taranis telemetry questions;

Post by Kilrah »

This is some old stuff for the 9x, where you could connect transparent radio modems to the radio's serial port and have the mavlink data decoded and displayed. It's not using FrSky telemetry.
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Taranis telemetry questions;

Post by mstrens »

Kilrah wrote:
Probably makes more sense using the native smart port interface though, which is a muxed transmit/receive UART at 57600bps.
The receiver polls devices every 12ms and gives them an opportunity to send a 7-byte packet. That one is not guaranteed to arrived, and usually used to send one individual telemetry value.
How often a device gets polled depends on the number of devices on the bus.
Please do not forget the issue 701 (asking to transmit value from Tx to sensor using SPORT).
I also think that using the native Sport would be a good solution (if possible).
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: Taranis telemetry questions;

Post by Kilrah »

This thread is exactly issue 701 :)
Except that when that issue was opened we didn't really have a clean way to actually interact with things and enter values to send on the radio side. Lua telemetry screens or "custom UIs" that are now available are what was missing.

Sent via mobile

Post Reply

Return to “General help (FrSky Taranis radio)”