FrSky sensor hub telemetry

I've been working on bringing the FrSky sensor hub telemetry working properly. As far as I know, the only one that has actually been tested was the voltage sensor, and it was pretty bogus.

I am handicapped by not having any FrSky sensors to work with, but building my own. So I could use a lot of help testing, especially from people with FrSky sensors, or DIY sensors known to work with FrSky transmitters. I've just listed the issues at the bottom here, and will expand on each in it's own post on this thread. I'll change the title to help people find/skip them, so please reply to them.

Test builds are at deviationtx.com/downloads-new/category/2...kysensorhubtelemetry

If you want source for some reason, it's at bitbucket.org/mwm/deviation , in the FrSky-temp-names branch.

Pull request for the team repository is at
bitbucket.org/deviationtx/deviation/pull...lemetry-display/diff

Issues:

1. The monitor page layout needs fixing. I need ideas for this!
2. Not sure if the values are right, as I'm writing both ends of the system
3. Connections appears to be flaky, even though non-hub data is rock solid.
4. Items that need more than 16 bits are flaky.

Note that the telemetry test page has not been changed on the color touch screen transmitters - only the 7e & 10. So the 6, 8, 10 and 12 builds are not uploaded. The F7 build is included, but won't be in the future as it apparently doesn't do telemetry. If you would like to test a build on a color Tx, please let me know and I'll fix things and upload it ASAP.

Misc	Bat	Cells
RSSI	Tx AD1	Cell1
Temp1	Tx AD2	Cell2
Temp2	Hub Voltage	Cell3
RPM	Min Cell	Cell4
Fuel level	Amp Voltage	Cell2
Vario altitude	Amp Current	Cell6

Note that Vario altitude is not on the 7E for memory reasons.

This is really ugly, and confusing even to me. The easy alternative would seem to be to mimic the GPS layout, alternating labels & values, but that would make already long page even longer.

Adding a page would require reworking the DSM & Devo telemetry code as well. Not really something I want to do.

So suggestions for a better layout gratefully considered!

Because I'm building both ends of the connection, it's not at all clear that I'm extracting the values properly from the signal. While there are open source implementations of both ends, those aren't much help. The Rx end translates from their own internal values to the values to send, which means I need to figure out what those (usually undocumented) values are. The Tx ends are generally for ER9X variants, and are reading the serial data from a transmitter module, not the values coming off the CC2500 that I'm seeing, so again, not really much help.

So, if you can test this code - either end - with either real FrSky hardware or known good clones, and let me know which values, if any, are working properly, I'd appreciate it. If you are seeing wrong values, let me know what you see vs. what you expect, and hopefully I can fix it.

Testing with FrSky compatible sensor should be obvious - just connect things up and see if it works with deviation!

Testing with FrSky compatible Tx's will require setting up an arduino to send the data. The "arduino.zip" file in the test downloads section will guide you through setting up an arduino to send simulated data via the Rx. Doing that and reporting the results here would be appreciated.

The connection seems flaky, in that sensor hub data is frequently marked as missing. I'm not sure if this is a problem in the implementation on the transmitter or the arduino.

So, if you have a genuine FrSky sensor hub or a flight controller that's known to generate compatible data you can test the with, great! Let me know if the connection is flaky or not, and that will tell me which is which.

If you have a FrSky compatible transmitter and can work with arduino's download the arduino.zip and install it on an arduino connected to your Rx as described in the README.md, and let me know how that works.

The longer values from the sensor hub - meaning everything from the GPS sensor, and the vario altitude reading (which isn't on the 7e) - are flaky. They seem to simply not get all their values, or use bogus values for some of them. In particular, latitude and longitude seem to use each others values.

I've got no idea what's going on with this, so letting me know if these values are/aren't working for your and with what hardware would be appreciated. Ditto for anyone who wants to look at the code in protocol/frysky2way_cc2500.c and make suggestions.

Hello,
you need some testing here ?
I have a Hub and some Sensors , but my Tx is a 8d with cc2500.
Sensors are Vario,Amp 40 + 100,Normal Altimeter
Greetings Alex

Well, yes, but not here. The FrSky X protocol code - which uses SPort sensors - uses the same frame and telemetry decoding as the FrSky protocol. If you could go to the FrSky X protocol thread at deviationtx.com/forum/protocol-developme...-new-frskyx-protocol and offer to test there, that would be best.

The worst case is I'm going to wait until they've finished working on that code before trying to work on the FrSky protocol hub sensor stuff.