New FrSkyX protocol

That's good news on the SBUS! Hopefully we've got the basic protocol complete.

Telemetry results look encouraging too. I've uploaded a new test build with the vario sensor id added. If it's being received you should see something in the volt2 box in the telemetry monitor. Likely only if AD2GAIN is set to 3.

Is there a way on the vario sensor to set an id value? The opentx code defines a range of 16 id's for vario sensors. The new test build accepts any of them.

On the Taranis I didn't understand whether you have the telemetry equipment or were just describing what's available. If you have the equipment, what values are received both with the vario connected and disconnected.

djdazzy wrote: Sorry, I started a new job this week so I have been busy. I will check it out tomorrow.

No worries. Congrats!

Hello,
i test the new Ver. on Monday, im out of Town today.

The OpenTx on Taranis is like Hardcoded with the ID, i switch the Data to Display with using the Names of the Sensors .
To Display Altitude Data i pick the name Altitude at the Menu and pick a Data field from Display. Then the Altitude shows up on Telemetry Screen.

The Sensors are Hardcoded to, there is no chance to change ID. The ID is given from Frsky.
The SPORT is stackable , i can use all sensors at a Row like SBUS and some of the SPORT sensors can be used as a Hub to read the Serial out from the none SPORT Sensors (the old one who working on the D8 RX serial in)

greeting Alex

@hexfet
I see there is a confusion,... packet[6] control the valid telemetry data in the frame,No need to process telemetry frame every time it arrived.
Process frames with packet[6]>0,The packet[6] is the number of valid bytes in the frame.
The same is on D8 protocol.The non valid frame contain garbage bytes and will produce garbage.Maybe I'm blind but I see it is not taken care in any Frsky protocol code D8 or X
It will not work properly as it is now.

which of these modules should i use?
cc2500 (blue) or xl2500-D03 (green)

Alexandro wrote: Hello,
i test the new Ver. on Monday, im out of Town today.

The OpenTx on Taranis is like Hardcoded with the ID, i switch the Data to Display with using the Names of the Sensors .
To Display Altitude Data i pick the name Altitude at the Menu and pick a Data field from Display. Then the Altitude shows up on Telemetry Screen.

I understand. Do you know the ID of the sensor you have? You said vario before but here mention altitude. Or does one sensor give both altitude and rate-of-change? There's no information on the FrSky website except pictures of the sensors.

I'm going to update the test version to ignore the ID for now, or put it in a telemetry box to see it. I'll upload that later today.

Seems like we're getting close, but you never know with software until it works

Thanks for reviewing the code, midelic. The packet[6] value is used in the last statement of frsky_check_telemetry() to send bytes through the sport stream processing. Similar for D8. This technique is new to Deviation so let me go through it so I'm not stuck with this code forever

When the state machine in frskyx_cb() reaches DATA4 it checks if any receive data is available. If so and it will fit in the packet buffer it is read and frsky_check_telemetry() invoked with a pointer to the received data.

In frsky_check_telemetry() if the fixed id matches the tx and the received packet length value is correct the packet is processed. The rx telemetry is read from packet[4], with rssi and rx voltage in alternating packets. The packet sequence numbers are checked and updated. Then if any sport stream data is present it is sent to frsky_parse_sport_stream() a byte at a time. (This last step should only be done if the sequence number is correct, but not sure about sequence logic yet.)

In frsky_parse_sport_stream() the incoming data is processed by a state machine, starting by looking for the 0x7e start byte. The state is static and the sport packet is built in static buffer frskyRxBuffer because the sport packet will be split over multiple rx packets. When the buffer fills the sport packet is examined in processRxPacket().

In processRxPacket() the instance, PRIM, and ID values are pulled from the packet. If PRIM is a data frame the telemetry value is processed according to the id.

That's the bare bones. The code right now has lots of debug code and messiness. In the emulator the telem_test data is processed correctly.

The sport state machine and processRxPacket come straight from opentx. The sport packet size is one less here because over-the-air sport packets do not have a checksum byte. The opentx code to store the telemetry values is stripped from processRxPacket. First I've looked at opentx - the telemetry part is well designed and implemented.

Processing the stream data only if sequence is correct will improve performance by ignoring duplicate packets. Could also reset the state machine if a packet is skipped as another optimization. But sport packets will still be interpreted correctly when ignoring the sequence numbers as long as a complete sport packet is received in two consecutive rx packets.

The state machine is a common method for handling byte streams. Though the spi captures only show packet[6] values of 0,3, and 6 the state machine implementation works correctly for any number of payload bytes.

How do these work? The discussion implies a two-way serial link over-the-air. Maybe tx packet bytes 22-27 are a transmit sport stream? That would give a reason for keeping a forward sequence number. Fun to speculate... Edit: or maybe a different tx flags value indicates channel bytes have sport data?

I'm, not referring to entire SPort protocol in openTX.What I'm saying is not in opentx.
I;m saying about telemetry byte pkt[6].I'm not taking about valid telemetry frame,I'm taking about the number of valid SPORT bytes in the telemetry frame, in order to know when the SPORT data can be processed or not.This is controlled by pkt[6].
You can have a frame with pkt[6]=0 and you have 0x7E,0x1A(ID),0x10..normal and the rest of bytes garbage ,,the SPORT telemetry frame is not valid.But you process all the data as good.You saw only what was nice in sample files. I've seen wrong SPORT frames wth 0x7E,0ix1A(ID),0x10,0x7E,0x1A(ID),0x10,- 6 bytes.Or one wrong frame with normal 6 bytes and the next with 0x7E,0X1A.0x10.The SPORT frame can look correct and be with wrong data bytes.

in the last statement of frsky_check_telemetry()
there is
for (u8 i=0; i < pkt[6]; i++)
frsky_parse_sport_stream(pkt[7+i]);
}
I see nothing else.
I know you want to finish quickly.
I'm trying to help,Deviation telemetry is not much help for me in mutiprotocol

I do appreciate your help and review. I understand what you're saying and still think the current code is correct.

Yes, sometimes the stream bytes in the rx packet are not zero and yet pkt[6] is zero. The current code does not process those bytes. If pkt[6] is zero, the for() loop doesn't run. The leftover non-zero bytes are likely because the rx code didn't clear the buffer when it had no sport bytes to send. Which is fine because only the number of bytes specified in pkt[6] are processed as sport bytes.

There are also spi capture packets where pkt[6]=6, and the first three bytes of data are the end of the previous sport packet and the next three bytes are the beginning of the next packet (i.e. pkt[10]=7e). And packets with pkt[6]=3 where the three valid bytes are the last three bytes of the sport packet that was started in the previous rx packet. And packets with pkt[6]=6 where the 6 valid bytes are the last six bytes of an sport packet that started in the middle of the sport data in the previous rx packet. The current implementation handles all these cases.

Alex's last report stated with AD2GAIN=3 (sequence code enabled) and an sport sensor plugged-in, the debug high-water mark reached 5. In the code the debugTelem(5) statement is after the sport packet data frame test. A valid sport packet was received. The next test build will have code to show the ID value and byte value.

Yes you right...I had in my mind fixed idea that you process the wrong SPORT frames...sorry.

Btw if the packet[21] and pkt[ 5] sequence is not correct sometimes the RX send wrong SPORT data in valid SPORT frames pkt[6]>0.
I played at home with different values and I received some very strange SPORT data from RX, frames all valid.
When I get back home I will sniff the exchanged data between TX and RX and see better.

Thanks, that will be a big help. Still not sure exactly what the high bit of the sequence nibbles means, and no idea about the third bit. When the third bit is set don't detect any other differences in the tx or rx packets in the spi captures. Seems random, but that's the one possibility that can probably be eliminated.

TomPeer wrote: which of these modules should i use?
cc2500 (blue) or xl2500-D03 (green)

Both are listed on the moduleinstall page, and I've used both with the FrSky D8 protocol. The CC2500 fits a multimodule. The XL2500 doesn't.

I have seen them both on the module install page. but i did not see if one of them would be prefered/better than the other. there is also an issue withe the xl2500-D03. the markings for the pins are different. i have seen an post where someone mentioned that pin 9 and 10 should be reverst.

The test build is updated. If sport packets are received, the sensor ID will be displayed in telemetry boxes temp1 and temp2 and the lsb of the sensor value in rpm. The temperature box numbers have to be backed through the temp conversion to get the actual ID. Should see something there if AD2GAIN is set to 3 and the sport sensor is plugged-in.

@hexfet
I have a xl2500-D03 module, I am going to test the new build now and get back to you in a bit. It wasn't a signal swamping issue as the tx/rx were several metres apart on low power.

Hi guys now you are all deep in this protocol and sniffing and so on, can you look if we can get "the store failsave from TX" feature.
It is possible with Frsky. Would be nice if deviation can have it.

Yes it is posible but I was not interested to put it multimodule because it requires some additional bytes in Er9X code serial for multi and modified configuration in Er9X protocol menu.Maybe one day.
But it is easier in deviation.FS packets are sent every 9sec. Interesting delivery system, with FS flag packet[7] 16 FS packets every 9sec.
see here.
www.rcgroups.com/forums/showpost.php?p=32878814&postcount=116

hexfet wrote:

djdazzy wrote: Sorry, I started a new job this week so I have been busy. I will check it out tomorrow.

No worries. Congrats!

Thanks, not had much free time as it taken me up to two hours to commute each way.
Tested deviation-devo7e-v4.0.1-43639ba and it looks good. PWM on the 8 channels working ok. RSSI and receiver voltage outputing correctly.
Failsafe works and recovers fast. Some previous builds didn't recover quickly and were initially jittery.

Will do a proper range check on this over the next few days.

Hello,
Test on Ver.436

AD2GAIN 1 displays only Volt1 and RSSI, booth are working (RSSI near field at max 120 )

-> Sensor named Variometer Sensor. On D8 it transmit the Altitude over the Serial Line and the Variometer (Speed of gain Altitude ) over the AD2 In of D8R ( higher Voltage are higher Speed of gaining Altitude). The Sensor is the High Precision Version with a better resolution of the Altitude detection. But i dont know how it works on SPort with the Vario Values.

Btw.
The Vario calculation is made inside of the OpenTX ( D8R ) Program with the Value of AD2 Volt. This way was a nice chance to use self made sensors or Hardware from other Company to get a working Thermal finder.

AD2GAIN 3
-> Data Field
Temp1 1
Temp2 16 jumping to 0 and back to 16
RPM, here i used a Videocamera to slow down the Changes
Most often there was 150, 50 ,206

the other Numbers are more like counting up and down Values
149,156,148,153,151,146,147,142,137,140,139,139,133,131,136,170,172,141,133,100,174,163,165

-> RX Blackout Test
on Power Cycle of the RX the SPORT Telemetry stops, if i Power Cycle the TX it does return to work.

SBUS does every time working without Problems, i do a deep Test (SBUS 1-12 ) later

-> EDIT
There is a List for the Hub ID, may be it is the same ID Number on SPORT ?
www.frsky-rc.com/download/down.php?id=126
Power Cycle of RX on Taranis does not stop the Telemetry on SPORT (2sec then i comes back again)

-> EDIT 2
I found info on a German WWW Side -> The SBUS Servo Channel changer from Frsky can show and change the Sensor ID
ID of the Vario from me is 01.

greetings Alex

Awesome. Thanks for the thorough testing

The numbers in the telemetry fields indicate packets received, but I'll need to puzzle out the values. I haven't looked at the code yet for decoding the old ID values so I'll get that in place and see what data we're getting. The temp2 value changing might mean both altitude and rate-of-change being received.

The issue of telemetry not restarting after a power loss is almost certainly a problem in the packet sequence code. It's not re-syncing with the receiver. I didn't find any captures with rx power off so we may have to try a few different things. Currently the code is supposed to fall back to starting with packet[21] set to 0x08 if not receiving packets but need to check that's working.

Seems very strong evidence midelic is correct that the packet[21] value is not involved with channel data transmission. I'd even try the deviation implementation on a vehicle already...if I had a surface vehicle

Might take a couple days as GUI code and I have a mutual dislike. If you don't mind some more testing I uploaded a test build that has a first try at the failsafe feature.