New FrSkyX protocol

I finally got a Tx with a CC2500 in it again. No X series Tx, but I did try 72aa192 on it to check the D4R-II telemetry since you said you were interested in it. Hub input was from the Arudino code I posted over on the FrSky thread.

The Rx-provided stuff seemed to work fine. Volt3 showed up intermittently. Nothing else from the "hub" ever showed up at all. I suspect the Arduino code is busted as indicated earlier. I probably won't have time for much more than this kind of quick test until next month.

Hello,
Test Ver.72a

The Telemetry Alt show a 30K Number with reacting the right way , more Pressure the Number goes down ( Altitude loosing )
The Cell6 for Vario Function looks not so good . On Taranis this Number goes to Neg (-5,-10) on loosing High and goes Pos. (+5,+10) on Gain High), here we have 6XX on loosing and 2,xx Volt on gain High.
-> t try to find some Info on the Net for calculating the right Numbers on ALT and VARIO ( Vario should show neg Numbers to)

-> I have to do a longtime Test on the Protocol because i think there is a Glitch with the Connection, sometimes (around 3-5 Min the Failsave comes up and the RX light goes off for 1 Sec.)
may be the Afternoon i make this Test and report.

btw. You need Debug on D8r with hub connected ?


greetings Alex

Thanks Alex. Probably have a scaling issue on the altitude. What's your local elevation? Do you know if OpenTX has the option to choose ASL or AGL on the display? I see the code store the current altitude as an offset when it gets the first telemetry, but not sure if it's an option on the altitude display to choose with or without offset.

There was also code limiting the vario to (-10,-5) and (5,10) but need to look closer at that. At least the numbers are in the correct boxes

Not sure about a glitch. Nothing in the protocol happens on 3-5 minute timescale. Please collect any info you might think helpful, such as does it repeat at regular intervals? Happen on every power cycle?

Testing with the D8R would need to be with the protocol_combo build as the D8 protocol changes are there. From what mwm reports I need to revisit that code and bring in the latest changes made to FrskyX. It would be great to get some more testing after I get that done.

midelic wrote: I see in opentx code 3 checks for 0x7E byte,And every time they reset the index.Strange they expect multiple times consequent 0x7E numbers.

The 3 three checks are not (necessarily) applied to three consecutive bytes. What they do is reset the state machine if a 0x7e appears in while the state machine is any of those states. Consider what happens if three 0x7e are received in a row starting in the IDLE state. (I'll refer to the deviation code because opentx mixes hub and sport telemetry state machines in one and it's more confusing.) The first is treated as the start of a new frame, moving the state machine to the DATA_START state. When the next 0x7e is read, it's treated as the start of a new frame - nothing's put in the buffer and the state is unchanged. This would be repeated for however many consecutive 0x7e's were received, with the last one always optimistically being treated as the start of a valid frame.

Hello,

i done the long Time Test for the Glicht and do not found any bad things. Looks all Ok.

The ALT is around 30135 at Deviation and my Alt is 213 (google earth). The ALT Numbers are looking like cm. If i rise the sensor around 30 cm the around 3016X is showing up. my be 3016.X is the cm or inch Value ?
I looked at Taranis and do not found the Alt Switch. At WWW i found thad only the Gps Alt is the real one from See level.
Normal it is better to set the ALT to 0 at Start and counting then up or down to bring the Plane save home ( at Mountain flying Locations there is hard to calculate the Alt with the eye ) .

The -10 -5 5 10 is the Trigger limit for the Vario Function . On -5 Plane loosing Alt an Beeping come up for loosing Alt. On 5 Plane gain High and Beeping comes for Thermal lift ( i think the Values are 10cm/sec -> 5 = 50 cm/sec lift).

greetings Alex

They are consecutive checks not numbers .. sorry .My concern with these is that I want to know how the SPORT frame is build inside the rx especially how the stuffed bytes are handled inside the RX telemetry frame.
I will explain a little SPORT protocol.Better for record.
The rx is polling sensors every 12ms sending serially(57600 bauds)out two bytes 0x7E and ID (HUB) sensor(It can be 0x1A,0X1B,0x28,aso. a long list)
If the sensor is available it will reply with 0x10, next 2 bytes are specific sensor ID, next 4 bytes are data, last byte is checksum totally 8 bytes
Inside the sensor data those 4 bytes can be in a form of 0x7E or 0x7D.
The sensor when answering back to rx is doing so called byte stuffing of these bytes.
If the byte is 0x7E or 0x7D he sends out additionally one byte 0x7D and the byte 0x7E or 0x7D is XOR-ed with 0x20 and send out(they can be more bytes added if there are more similar bytes to stuff).
Now the RX will receive more than 8 bytes.depends on how many stuffed bytes are.
So it will receive from sensor something like that
0x10,ID1,ID2,0x7D,0x5E,val2,val3,val4,CRC, totally 9 bytes if only one is stuffed(but it can be more)
Now here coming my concern.We know how the RX is packing normal telemetry frame without stuffed bytes.My concern is with the stuffed bytes frame.
Normal frame is for example:

0x7E,0X1A,0x10,ID1,ID2,Val1,Val2,Val3,Val4.- 9bytes(6+3).

A stuffed frame if there is no processing inside the RX will be like:

0x7E,0X1A,0x10,ID1,ID2,0x7D,0x5E,val2 ,Val3,Val4 ,-10 bytes.

If the bytes are unstuffed inside rx wiill be like

0x7E,0X1A,0x10,ID1,ID2,0x7E,val2,Val3,Val4 -like normal SPORT frame 9 bytes

So the 0x7E byte may land inside a valid telemetry frame.We saw in telemetry frame only 6+3 bytes arrangement,with valid frame bytes(pkt[6]) 6 or 3.If there are stuffed bytes the frame will have valid bytes other values than 6 or 3,It may be 4,5depends on how many stuffed bytes were.
Now we know the opentx is processing stuffed bytes but the bytes can be stuffed by the XJT module and sent out to opentx.
For example out of XJT can be :
0x7E,0x1A,0x10,ID1,ID2,0x7D,0x5E,Val2,Val3,Val4,CRC- 11 bytes serial frame 57600 bauds(inverted signal) stuffed.

or it can be directly from rx unstuffed
0x7E,0x1A,0x10,ID1,ID2,0X7E,Val2,Val3,Val4,
in which case the frame is dumped with actual code in Deviation.

I expressed this because if the code is not handled properly especially with stuffed bytes this can lead to errors.
When I get back home in 3 weeks I will modify the openxsensor code and send out to my X4 only stuffed bytes,I will monitor with my multi and see what SPORT telemetry frame the rx put out.Still long time to wait.

Alexandro wrote: Hello,

i done the long Time Test for the Glicht and do not found any bad things. Looks all Ok.

That's good news.

The ALT is around 30135 at Deviation and my Alt is 213 (google earth). The ALT Numbers are looking like cm. If i rise the sensor around 30 cm the around 3016X is showing up. my be 3016.X is the cm or inch Value ?
I looked at Taranis and do not found the Alt Switch. At WWW i found thad only the Gps Alt is the real one from See level.
Normal it is better to set the ALT to 0 at Start and counting then up or down to bring the Plane save home ( at Mountain flying Locations there is hard to calculate the Alt with the eye ) .

I think you're right about the altitude being in cm. Looks like the hub sensor is cm also. I need to scale the value. Have not been about to find info online about the units of measure reported by the sensors so need to pull that info out of opentx. Makes sense that the baro altitude would be AGL as there's no way to adjust for current weather.

The -10 -5 5 10 is the Trigger limit for the Vario Function . On -5 Plane loosing Alt an Beeping come up for loosing Alt. On 5 Plane gain High and Beeping comes for Thermal lift ( i think the Values are 10cm/sec -> 5 = 50 cm/sec lift).

greetings Alex

Thanks that's good information. I'm working through hooking up the sport sensors to the display over the next few days...

midelic wrote: I expressed this because if the code is not handled properly especially with stuffed bytes this can lead to errors.
When I get back home in 3 weeks I will modify the openxsensor code and send out to my X4 only stuffed bytes,I will monitor with my multi and see what SPORT telemetry frame the rx put out.Still long time to wait.

Thanks for the sport description. Now I understand better end-to-end.

I agree with your description of the byte stuffing. If for example the value of the sensor is 0x7e, the sport packet from the rx will have that replaced by 0x7d5e (and that sport packet will have 10 bytes split across two or more rx packets). After those bytes are processed through the state machine the value in sportRxBuffer will be back to 0x7e when it's passed to processSportPacket. None of the spi captured packets have an example of this but I can add it to the emulator test data. Will be good to get a real test too.

Test build is updated.

• The sport sensors that correspond to existing telemetry monitor page boxes (including gps) should appear in the correct spots (temp, cells, etc) and in the correct units. I've added a new box for vario.
• The baro altitude should now display AGL. The units are meters or feet depending on the telemetry settings on the transmitter config page.
• The vario is in a new box under altitude (row 7, first column). Should display feet or meters per second.

There may be some scaling issues as I haven't found info online about the sport sensors. Currently they are treated the same as the corresponding hub telemetry sensor.

Any suggestions on the telemetry monitor page layout? It's possible to add some labels if that would be helpful. Does anyone look at this screen while flying? What sport sensors are most beneficial?

Don't think the sport telemetry will ever fit in the 7e. Not sure how much of the hub telemetry will fit on the 7e in the Frsky protocol once the fixes are made.

I have an X4R-SB on the way, should be here within the next days.. is there still any modification being made to the main code, or is that complete? I don't really care for SPort and would use RSSI only, and maybe A1 voltage telemetry.

Hello,
Test Ver. 418

Test on Altitude :
Done a paralel Test with Taranis . All pos Numbers are running with the same Numbers on Taranis (Alt). Good Work !
-> Can You do a 0.5 resolution on the Altitude ?

The neg. Alt Numbers are arround
-3.7 m 23589
-4.0 m 23588
.........
There are ( 23XXX - 23589 = -3.7 ) ?

Test on Vertical Speed:
4.3 -> 5
4.0 -> 4
3.6 -> 4
3.0 -> 3

Looks very Good ! Good Work !
-> Can You do the same here to get a 0.5 on the Dispaly ? Or better a 0.2 or 0.1 with a low jumping filter ? ( on Thermal search it is good to have a fine range to center the Plane at the biggest lift)
The neg. V Speed is the same as Alt, here is the 23XXX Number at neg. Values. May be doing a calculation to display the Neg Numbers.

All test were done with 2 X8R on Taranis and Deviation with the High Precision Vario from Frsky , i used a Tubber ware Plastic Box to simulate the Pressure changes.


The Telemetry Screen:
my 2 ct.

At flying it is not good to leave the Plane or the Quad out of the Eye, most Time you have to hunt it again at the Horizon to find it again.
What i like is to have 2 or 3 Big Numbers on the Screen ( Volt1, RSSI, Used mili Amp or VSpeed, Volt1, RSSi on Sailplane ) and setting the Alarm to Beep at some to low Numbers. Here you can rise the TX up and take a fast Blink to the Screen. If there is to many Info then you need to long to read it .

The 2nd Telemetry Screen is good for checking the Sensors and to find the Plane or Quad again on Trees or in the Woods with GPS .
Some Pilots like to do a revive with the logged Values from the Telemetry to show it to some Friends or to test the Plane , Engine, Batt........

I think here is no big Thing to change at the Color TX Screens.
On the BW Screens i dont know , there i can take a look if You want.

The SPORT Sensors:
- On Motor Planes
RSSI,Volt1, Volt2 (Main Engine Batt), AMP (max Ampere), mAh (consumed mAh from Main Engine Batt), ALT (max High on Location with Alarm at restricted Sides), Temp (Batt and or Engine) , GPS (Horizontal Speed)
i use personal RSSI,Volt1, Volt2 (Main Engine Batt), mAh (to time the Fuel for landing) and not so often Alt for Glider towing.

- On Sailplanes.
RSSI,Volt1,Alt, Vertical Speed, Volt2 (main Batt without the BEC), GPS (Horizontal Speed and to Locate the Plane on landing out of sight )
i use RSSI,Volt1, Vertical Speed ( Thermal hunting), Alt ( on landing to get the right Alt)

Telemetry on 7e:
my 2 cnt.

On 7e with the LCD Display it is good to have it on Sunny days but it is not fast to read at the Telemetry Screen with the Black and White.
The Tx is nice small but it is hard to get a good fit for the Modules (cc2500, 7105) and the Antenna, here it is a bit Toy grade.
I think a good way is to use the Main Screen with a small Part of the Telemetry ( with out the GPS processing to save Memory).
And if it is possible a 2nd Screen like the Main screen with 4 or 5 Big adjustable Boxes for the Telemetry ( to save Memory)

The same Way for the other TX , The big Telemetry Screen is nice to have on Checking the Sensors but it is not thad useful at flight. There are to many Numbers on it to watch it fast.
Here might be better to do a 2nd or 3rd Main Screen , switchable with one Button (like the Main <-> Telemetry Button Switch) and making 4-5 Big Boxes who can config by the Pilot for needed Infos on Flight.
And a log Function to store the other Data at point of landing out of sight or to have a Blackbox on Crash review.


if You need more Info feel free to ask

greetings Alex

For me a full log not directly required, but an event counter, we can check after flight is usefull.
min value, max value, event (or alarm) counter nr of times that, value pass the set threshold.

On the telemetry screen layout, that really needs a serious rethinking. Not just the FrSkty stuff, but the entire approach. We have at least one protocol with telemetry that we only support bits of, because getting it all to fit on the 7E just wasn't happening. We either need to punt completely on extended telemetry on the 7E, sticking with just the basics like voltages and signal strength indicators, or figure out how to do telemetry for multiple protocols with a single screen.

I was thinking for the latter something dynamic, with a list of values plus an "active" indicator, and then when we build the page to display, we only display those flagged as "active". I'm not sure that would fit on a 7E, but it would at least be better, and it take automatically handle protocols that were missing telemetry elements on the 7E. But I haven't really given it a lot of thought.

I'm fine with leaving extended telemetry off from the 7e. Just the frsky decoder code puts it near the memory limit.

Wouldn't you put things you want to see while flying on the main screen? Would a configurable layout for the telemetry monitor page set in the model.ini be useful? (Not that i'd take that on )

Arakon wrote: I have an X4R-SB on the way, should be here within the next days.. is there still any modification being made to the main code, or is that complete? I don't really care for SPort and would use RSSI only, and maybe A1 voltage telemetry.

No changes recently for non-telemetry code. Would be good to get some more test time.

Alexandro wrote: Hello,
Test Ver. 418

Test on Altitude :
Done a paralel Test with Taranis . All pos Numbers are running with the same Numbers on Taranis (Alt). Good Work !
-> Can You do a 0.5 resolution on the Altitude ?

The neg. Alt Numbers are arround
-3.7 m 23589
-4.0 m 23588
.........
There are ( 23XXX - 23589 = -3.7 ) ?

Test on Vertical Speed:
4.3 -> 5
4.0 -> 4
3.6 -> 4
3.0 -> 3

Looks very Good ! Good Work !
-> Can You do the same here to get a 0.5 on the Dispaly ? Or better a 0.2 or 0.1 with a low jumping filter ? ( on Thermal search it is good to have a fine range to center the Plane at the biggest lift)
The neg. V Speed is the same as Alt, here is the 23XXX Number at neg. Values. May be doing a calculation to display the Neg Numbers.

Nice work as always, Alex. Thanks.

Test build is updated. The negative values should be displayed for altitude and vario. This fix required changing the shared telemetry array from unsigned values to signed. Not sure if this will affect the display of Devo or DSM telemetry, so if anyone could test that it would be much appreciated.

The altitude and vario should already be displaying up to two decimal places if space allows. It works on the emulator. Maybe a pic of your screen would help me understand what you're seeing.

I think the telemetry test page is for testing telemetry and other things you probably don't want to do while flying. The few your actually want to see should be on the main page and possibly triggering alerts. So I'd say no editable telemetry page.

That's also why I think the fancy kinds of layout I was trying to do are a waste. Just make them all visible, but only if set, on the telemetry test page.

Further discussion -if someone feels like working on this - should probably be on a new thread.

Hello,
Test Ver. 15e

the neg. Numbers are looking good , some times at VSpeed is a wrong Number jumping into Display for 1 sec.
here the Pictures, i try to show the same on booth TX ( Taranis and 8e)

The Rf power on XJT original is not set to maximum power it cannot be increased it is set like this in firmware.On deviation you can set to max.
So what is the power settings used?

@midelic
the Taranis TX Power is not changed , it is the normal TX Power
on the 8e i changed from 100 myW to 150mW and the RSSI is only changing for 93 to 98 (on 5 m through 2 thin Walls)
i think here is something wrong with the Wire solder or the Deviation .
i used the New Version of the Bridges for the cc2500 soldering .
i open it up and take a look at it later.

Edit:
The low RSSI from Tarains is because the 2 TX and 2 RX are near on the Table. The normal RSSI from Taranis is 99 to 100 near the RX.
Edit 2 :
All Bridges are set right 5-10 7-9 on cc2500, Power Setting does not the right Thing. on 100 myW is the Range to good.