New FrSkyX protocol

Fernandez that sounds reasonable but not familiar with that part of the code yet. Don't let me forget.

Alex, looks like failsafe is behaving as expected. I'll try not to break it in the future You mentioned you have the old vario sensor (that works with D8 hub). Does it plug directly into the X8R sport or is there some adapter?

I'll spend some time now going through the telemetry display. I think more than one telemetry field might be going to volt2. There's also some uncertainty about when to update telemetry fields that are received as multiple values (e.g. latitude is three values: before decimal point, after decimal point, and direction). I tried to duplicate the order that opentx uses but not sure it's working that way.

Hello,
the Vario Sensor is the Altitude High Precision Sensor from Frsky -> www.frsky-rc.com/product/pro.php?pro_id=111
It has the Direct Output for SPORT and it is a HUB for old non SPORT Sensors. I can use it with my FAS-40 and FAS-100 Amp. Sensor ( they connect via Serial to the Vario Sensor).
With this Way i do not need the Big HUB from Frsky (wich i have to )

greetings Alex

@hexfet
I have a feeling that we should introduce one more check regarding telemetry.
The SPORT full telemetry frame is split in 2 frskyX telemetry frames and 2 complete SPORT frames fill up 3 valid full frskyXframes .... If is missing the consecutive one or more we end up processing a frame with wrong data.
I think we can use to prevent that ,...packet[5],.We store packet [5 ] from a telemetry frame and compare with the the subsequent one(doing the calculation) and if ok we process the frame as valid if not toss it.
let me know what you think about it.

midelic, it's a good point and it does need to be addressed. I'd like first to try using the packet sequence numbers as intended. If we can fully understand the algorithm it'll be easy to detect dropped and duplicated packets. Otherwise we'll have to come up with something ad hoc based on packet[5].

The next test build I'll add the code to reset the sport state machine on sequence errors and we can see how that goes.

Looking at the state machine in frsky_parse_sport_stream() (pretty much straight from opentx) there is already some protection against missed/duped packets. If the start flag (0x7e) is encountered when it shouldn't be - as a byte in an sport frame - then it's treated as the start of a new frame. Any data collected in the sport frame buffer is discarded.

It would catch the case if columns 2 and 3 of your example data were missed, but not if only column 2 was dropped.

hexfet, have you tried upping the max output channels to 16 in your test builds? Since the X protocol supports 16 channels, we ought to at least find out if we can up that number without breaking anything along the way. But the 7E may be a problem again.

The ram overflow is that the protocol file has gotten bigger than the area of ram we've set aside to load it into.

Indigo1 ran into this with the DSM telemetry. The fix there was the idea of "extended" telemetry: features that were less likely to be used. Those are disabled in the 7E. You ignore those values in the protocol file, which saves your ram space. You can also remove them from the display, so they save space in ROM.

This is confused by that busted merge of the FrSky telemetry I did. The DSM version used HAS_DSM_EXTENDED_TELEMETRY. I changed that to just HAS_EXTENDED_TELEMETRY, using that to disable it in both protocols. As we discussed earlier, those got into the nightly via a bad merge. I just backed that out.

I have not tried changing the max number of channels. I'm hesitant to change the layout of the raw array. Hopefully all the code that addresses into there by offset would handle the change automatically...hopefully. I'm not going to put too many balls in the air at once - PRs welcome

mwm wrote: This is confused by that busted merge of the FrSky telemetry I did. The DSM version used HAS_DSM_EXTENDED_TELEMETRY. I changed that to just HAS_EXTENDED_TELEMETRY, using that to disable it in both protocols. As we discussed earlier, those got into the nightly via a bad merge. I just backed that out.

Would it be better for me to start with those changes applied or reverted? If the code you added to handle values and display is correct that would be a head start, even if the protocol stuff is removed.

I would recommend using my display code. Or at least looking at it - you may not like the layout I chose. There are a bunch of values in the FrSky hub telemetry (per-cell voltages for 6S batteries!), and getting a workable layout for them wasn't easy.

And even more values in the sport protocol - up to 32 sensors of each type! No sense trying to display that much data, but an sport serial stream out the trainer port might be valuable...

I'll forge ahead with your changes since they're in the protocol_frskyx branch already.

Hmm. Any idea how you're going to deal with that many display value? Just ignore it?

BTW, I've just gotten a comment about backing things out - Gyrfalcon is working on the Devo telemetry, and wanted to use the now-missing HAS_EXTENDED_TELEMETRY option to disable things to avoid breaking the F7 & 7e. I pointed him to you and this thread to coordinate things.

@hexfet ,
Actually I thnk there is a problem taking open tx code unmodified.
Taranis XJT module is doing some processing of telemetry frame before sending serially to open tx.
For example :
You may find one or more 0x7E bytes inside the telemetry frame as valid bytes,The byte is stuffed byte is split in 2bytes one 0x7D and second XOR-ed with 0x20. ......and after send serially to OpenTX where is processed.
if ((p == 0x7e) || (p == 0x7d))
{
Serial_write(0x7d);
Serial_write(0x20 ^ p);
}
so 0x7E byte inside the SPORT frame that coming from RX may be valid.

edit:
I see the code that openx sensor...sends to RX bytes already stuffed...0x7E already split on 0x7D and byte^0x20.
Maybe the RX is converting to serial SPORT but I maybe wrong about that.I did not see telemetry frames with 0x7E or 0x7D.
I have to do some more research.

hexfet wrote: Looking at the state machine in frsky_parse_sport_stream() (pretty much straight from opentx) there is already some protection against missed/duped packets. If the start flag (0x7e) is encountered when it shouldn't be - as a byte in an sport frame - then it's treated as the start of a new frame. Any data collected in the sport frame buffer is discarded.

It would catch the case if columns 2 and 3 of your example data were missed, but not if only column 2 was dropped.

Hexfet,

Have you got the latest 7e build please? Was it the telemetry hub code that wouldn't fit?

Thanks

+hexfet - heads up on my telemetry display code. The color screen UI's were not modified! I never got any feedback on the B&W screens - or testing of any kind. That's why I put it aside - nobody but me seemed to be interested.

Test build is updated. The 7e build is back but without sport telemetry. Still has the rx voltage and rssi. I also added code to reset the sport state machine on packet sequence errors. Please check that this does not disable sport telemetry completely.

Haven't heard from Gyrfalcon but I used HAS_EXTENDED_TELEMETRY to remove the sport code for the 7e. I intend to just build on what you had started. To handle the sensor possibilities I plan to collapse multiples of the same type to one value. You could have one sensor of each type but any id you give it will work.

Hello,
Test Ver. c65
i testet the Telemetry (Vario Altimeter, FAS-100)
The Curr. from FAS-100 works and show the same with Taranis. Good Work !
The Alt does not work, it shows always 0
The Volt2 is jumping the same way.
The TeleVAmp shows 3.00 V . TeleVAmp ?

Any other things to test ?

greetings Alex

Not sure what TeleVAmp is. Still successfully procrastinating looking at the display code. And this weekend is good weather so probably no updates till next week

Everything but the telemetry seems pretty solid. No changes were made to midelic's and Pascal's implementation other than what was required to run on Deviation. I'd say it's ready for range testing. If that looks good fly it on something inexpensive

Snuck in a little time to clean up the altitude and vertical speed indication. Test build is updated. Altitude should be in the correct box but not sure about the scaling. Currently its treated the same as an old altitude sensor. The VSI is in Cell6 for the moment - haven't changed the screens yet. Both of those were being put into Volt2 before which explains the jumping (hopefully

What box on the telemetry monitor screen is TeleVAmp?

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.