Frsky (HUB) protocol questions

[ReSt]

I'm trying to display GPS data via the FrSky version of the 9x.
I don't use FrSky rx or Tx.
NMEA version is working, so the downlink is ok.

I have attached an Arduino board to convert the ASCII NMEA data of the GPS module into the FrSky protocol.
I believe, that the GPS data is correctly converted into the HUB protocol.

As nothing from this datastream is displayed (or recognized) from the 9x, I assume, HUB data has to be embedded into the FrSky protocol.

My full HUB datastream, containing all available data fields (Date,Month,Year,Hour,Minute,Seconds,Altitude,Speed,
Course over ground, Latitude,North/South,Longitude,East/West, 6 Analog values, 6 Digital In as 1 byte, RPM)
looks like this (shown by a Hex editor, spaces and CrLf added only for readability)):

5E 15 0D 03 5E 16 0C 00 5E 17 09 1F 5E 18 22 22
00 5E 01 5C 01 5E 09 EB FF 5E 11 05 00 5E 19 05
00 5E 14 48 01 5E 1C 04 00 5E 13 13 96 5E 1B 21
39 5E 23 4E 00 5E 12 04 63 5E 1A 20 66 5E 22 45
00 5E 40 01 15 5E 41 01 0D 5E 42 01 08 5E 43 01
11 5E 44 01 16 5E 45 01 14 5E 48 3F 00 5E 03 00
00 5E


A test, only with Latitude field, embedded into FrSky frames as user data, looks like this:
7E FD 09 00 5E 13 13 96 5E 1B 21 6D 5E 7E

None of them is recognized by the 9x (r739)

Questions:
Any obvious failure ?
Which fields of the Hub protocol are supported already ?
How many data fields are allowed in one record ?
Do I have to send every single field embedded into FrSky leader and trailer?
What counts into Byte 3 (length count of user data) ?

Are my assuptions correct or totally wrong ?


Reinhard

[MikeB]

After each 5E there should be 3 bytes, the first is the item index, the next 2 are the value, lsb first. In your datastream, the last item on the top line appears to have 4 bytes after it:
18 22 22 00
All fields are supported, the data is stored, but not all fields are displayed (yet).
I believe you just send your user data into the receiver port, it arrives at the transmitter packaged in FrSky user data frames.
You do need to handle the byte stuffing of the value data. If any value is 5D or 5E then send 5D followed by the data value XORED with 0x60.
You should be able to send as many fields as you like in a single record.
There is a throughput limit, you cannot send continouos 9600 baud data, the downlink is not that fast. I can't remember what the limit is.
The rx port is a true RS232 port, so a 1 is 0V and a 0 is +5V.
Mike.

[ReSt]

Thanks Mike,

the 18 22 22 00 is a problem with the arduino command Serial.write() that is the only one (that I know) that allows hex values to be sent. Whenever it sends a 0x18 it sends the next value twice. (I believe it treats this code as Cancel)

No I do not use the original FrSky link, I'm using different hardware so I have to do the packaging by myself.
The hardware that i use is the one that I use with the NMEA solution. And in the moment, I feed the TX with 2400 Bd.

Mike, which of the values of the GPS is displayed with as little prereqs as possible so that I can use it as a starting point in debugging my code, sending only this single value to the 9x.

Do you have a sample datastream (including the HUB) that I could use?

Reinhard

[MikeB]

The maximum number of user bytes in a 'FD' packet is 6.
7E FD 06 00 u0 u1 u2 u3 u4 u5 7E - u0 through u5 are the user bytes.
If any of the user bytes are 7D or 7E, they need to be byte stuffed - 7D followed by user byte XOR 0x60.
I assume you have changed the FrSky baudrate to 2400 from 9600.
Altitude or speed is probably the easiest to use as a single value.
If I get a chance, I'll try to capture a datastream.

Mike.

[ReSt]

I assume you have changed the FrSky baudrate to 2400 from 9600.
Mike.

Stupid me
I mixed up my RF speed (2400 Bd) and the USART speed of my telemetry receiver (4800 Bd)
After correcting this, I got some data on the display.

In the meantime, after several trials without real success, I have packaged every single value that has an ID into one single packet surrounded by 7E FD 05 00 5E .....5E
From tracing my output, I'm pretty sure, that my data now is correct.

What I found is.
1. I permanently have the 'NO DATA' blinking while my GPS data is displayed ( I outcommented the NO DATA but the rest of the screens is still blinking).

2.Latitude and longitude seems to be decoded in the wrong order with respect to the manual. I have to send low byte first to get the correct values displayed.

Frame Protocol of FrSky Telemetry Hub System (V2.0)
DATA Send Form is in Little Endian , except for latitude, longitude, Voltage (Lipo Voltage Sensor), date and time.

3. Don't know why, but the display of latitude and longitude are not 'stable'.
When I switch on the TX, sometimes i get the data before the decimal point displayed (xxx.0000)and sometimes the data after the decimal point (0000.xxx). I have a separate power switch for my TX GPS receiver and when I cycle power for the receiver two or three times, I suddenly get the full data for both of the values displayed. And they are alive, because they are varying (see picture).

4. Telemetry setup screen 9/11 (no Heli) shows in the second line the string:

"LIMITS TRIM [MENU]Imp"

With one step down to select the line, the cursor disappears. Left[short] or Right[short] selects the line -->invers
Menu[short] toggles this line to:

"---x>0x<0|x|f>0f<0|f|" but nothing can be selected.


Failure was introduced with r726
in menu.ccp menuProcTelemetry(....) the two lines

lcd_putsAttIdx(....)

don't work as expected
I replaced them with the old lines from r723 and it works.


Reinhard

[MikeB]

I had a bug, the correct line for the metric/imperial option is:
lcd_putsAttIdx( 16*FW, FH, PSTR("\003MetImp"),b,(sub==subN && subSub==1 ? INVERS:0));

I was saving code space, and embedded the substring length as the first byte of the string but I missed putting the \003 in this one.

Have you included the byte stuffing for 7D/7E and 5D/5E in the data you are sending? If you have to stuff the user data, then you will need to change the 05 after the FD to indicate there are extra bytes, and if more than one byte needed to be stuffed, then the user data will become too long for a single packet!

The NO DATA is handled by making sure data is arriving without a gap of more than 0.2 seconds. This is defined in frsky.h by:
#define FRSKY_TIMEOUT10ms 20
the 20 is units of 10mS, so 20 * 10 = 200 mS. If you have gaps longer than this, you could increase this value (max is 255 for 2.55 seconds).

Mike.

[ReSt]

Thanks Mike, menu works again.

I have implemented the calculation of the nuber of charachters that are sent (depending on byte stuffing) and now provide the correct length in the data string.

For my FrSky version (r739), I had to increase the timeout to more than 700msec (=70) to get rid of the NO DATA display. Even though I'm sure, in my datablock there are no big gaps. The input signal on the transmitter side doesn't show gaps of more than one or two msec maximum (if at all).
On the other side, I'm transmitting the datastream only once per second. So there naturally is a long gap.
But I don't have a problem as long as an increased time delay does work.

On the other hand, I have even more problems.(I verified, that in this situation, valid datastreams are input to the GPS transmitter- see sample below).

With r739 (and the menu.cpp from r744), I get Latitude, Longitude, Altitude, speed and max - from time to time; that is when I power
on the TX and go to the FrSky screens, the first three screens show the fixed strings without values (that's ok) and the last screen (with GPS data) may show:

all zero values,

Lat and Lon value before decimal point (dp) and zeros for the value after dp or zeros before dp and the correct values after dp

altitude as zero or real value.


Some times the missing values suddenly show up simply while waiting for some time (minutes).

When I cycle power for the GPS receiver in the 9x, sometimes the situation switches from one to another as I showed above, or even all values are shown.

But even when all variables show a realistic value, it looks like some of them are frozen.
Either Lat and Lon values after dp vary and altitude remains at one value (and I know, it is varying) or altitude is moving around and Lat and Lon are frozen.

Can it be, that there is some kind of lockout where the code expects certain data that may not show up?

This is one record of my datastream that is sent once a second:
7E FD 05 00 5E 13 96 13 5E 7E FD 06 00 5E 1B 5D
3E 21 5E 7E FD 05 00 5E 23 4E 00 5E 7E FD 05 00
5E 22 45 00 5E 7E FD 05 00 5E 12 63 04 5E 7E FD
05 00 5E 1A 57 20 5E 7E FD 05 00 5E 01 57 01 5E
7E FD 05 00 5E 09 09 00 5E 7E FD 05 00 5E 11 00
00 5E 7E FD 05 00 5E 19 00 00 5E


Then I tried with r744 but it does work even worse for me.
Telemetry screens 1 to 3 show 'NO DATA' and on screen 4 (the GPS data screen) all fields are filled with zeros and Lat, Lon,MAX values are blinking. Independent of my GPS receiver powered off or on. It doesn't recognize the GPS data at all.


Reinhard

[MikeB]

The FrSky code is expecting a 7E byte both at the beginning AND at the end of a frame, It does not share the 7E across two frames so there needs to be two 7E bytes tigether. This explains why some fields are ignored, it gets the first frame/field, then misses the second waiting for another 7E.

Mike.

[ReSt]

Hi Mike,

shame on me
On r744 I forgot to change the baud rate.

I now get data on the GPS screen, but the situation is still as described before.
When I power on the TX, I get e.g.
LAT= 010014.0000
LON= 01523.0000
ALT= 347
Spd= 6 Max=7
Alt is varying and LAT/LON after dp stay 0

Power cycling the GPS receiver in the 9x sometimes brings up the missing LAT/LON values after dp. And these values do vary. But now, the ALT value is frozen.

Repeating power cycling the GPS receiver, may bring back varying data for ALT, but then LAT/LON is frozen.

And vice versa.

Reinhard

[ReSt]

I already tried with 7E at the beginning and the end but didn't change anything.

Will try again.

Thanks,

Reinhard

[ReSt]

Mike, you got it !!

Obviously I had one more problem in it when I tried it last time.

Mow I get LAT, LON, ALT, Spd, and MAX immedialtely when I switch to the panel. And all of then are alive.

Thanks, Mike


Reinhard

[ReSt]

Hello Mike,

this is how far I got in the meantime (GPS mouse with Arduino Mega and an APC200 transmitter)

My HUB emulator (Arduino) in the moment is able to send all kind of GPS data, six analog values, one RPM and one byte with six digital inputs (switches).

Can you implement a maximum altitude value? It should be possible to reset 'Max' values (speed, alt) at any time by means of the Exit or Home pushbutton.

Is there anywhere a description of the FrSky protocol (not the HUB), so I can, at will, use any of the fields of the other screens ?


Reinhard

[MikeB]

The FrSky protocol (not hub) is available as a download from the FrSky website. I may be able to add a max altitude, and allow reset of the max values, but I have a lot on at the moment so I don't know when I will get to it.

Mike.

[ReSt]

Thanks Mike,
I found it.

Take you time, I'm not in a hurry.

How about save the actual altitude with e.g. Exit[short] as home altitude (starting altitude) and switch display of altitude (and max) with e.g. Home[short] between total altitude and altitude relative to home position ?



Reinhard

[Eagle71]

Hi ReSt,

aus Deinen GPS Daten hab ich erkannt, dass Du eigentlich Deutsch sprechen kannst. Ich hoffe das ist so, ich kann zwar auch engl., aber so ist es leichter.
Wenn ich richtig gelesen hab, hast Du den Hub weggelassen, und das Empfangsprotokoll "umgedreht" und einfach dem Empfänger (Telemetriesender) auf die "digital data-stream Schnittstelle" geschoben?
Ist die Pinbelegung auf dem Empfänger aufgedruckt, oder hast Du sie ausgemessen?
Ist warscheinlich TTL-RS232 mit inversem 0..3.3V Pegel.
EDIT:http://www.frsky-rc.com/uploadfile/2010 ... 814373.pdf Seite4

Ich hab noch keinen Telemetrisender, aber die TH9x mit er9x geflascht, LiPoFe und Trainer/HF Mod.
Da ich ein Vario bauen möchte, würde ich mir somit die ganze HF Geschichte sparen.
Eine GPS Maus hab ich auch noch rumliegen, ist aber für einen Segler nur Balast und kaum Nutzen.

PS: Hast Du den D4R-II mit CPPM und mehr als 6CH getestet? Bei 18ms FrameRate gehen sich 8CH nicht immer aus.

Gruß aus Tirol
Eagle71

[Kilrah]

PS: Hast Du den D4R-II mit CPPM und mehr als 6CH getestet? Bei 18ms FrameRate gehen sich 8CH nicht immer aus.

I've had a bit too much German lately, so I'll answer in English, but...

FrSky now released an updated firmware with a 27ms frame period that is safe to use in PPM mode with 8CH. It's available for both the D8R-XP and the D4R-II.
http://www.frsky-rc.com/download.asp?id=23

[Eagle71]

Hi @all
this is a short explanation of my first Post 2 Steps up(Nov 11, 2012 4:55pm)

I ask ReSt how he make the FrSky Hub, but he has no FrSky hardware, he uses an other TX-RX hardware for his sensors. At the Ground he transfered the Data into the FrSky Protokoll and but it into the Er9x to fill the Display.
More Infos on http://openrcforums.com/wiki/index.php/ ... TX_display

Ciao Eagle71