FrSky Telemetry set + Turnigy 9X v2

[rayholland]

That would be awesome!

[rayholland]

I was just browsing the er9x svn three (see http://er9x.googlecode.com/svn/trunk/) and there was a er9x-frsky.hex firmware (Author - Philip Moss)!
Has anyone more info on this?

[soopy]

I'm the author of that build. It is based on the Jeti telemetry code written by Shaddi. The mods to the radio that are needed are pretty well the same as for the Jeti build. It requires the re-routing of two tracks to spare pins on the processor to free up the serial port Rx and Tx lines (technically you only need the Rx at this stage but if you're doing it you might as well do both. You also need to build a cable or circuit that will convert the RS232 signals from the FrSky module to the TTL levels that the processor uses. I'm currently using a MAX233 chip as it doesn't need any other components. It can either be built into the radio or made into a cable that runs from the programming port (used to flash the firmware) to the FrSky module. The latter is how I'm currently doing it.

The build is functional but still under development, I just asked Erez to add it in so that it would track his constant updates. It currently displays the raw hex values for A1 and A2 converted to decimal (0-255) and the Rx RSSI figure. I haven't built a voltage sensor cable yet so haven't changed the display to show voltage. A picture of the current display is here: http://www.rcgroups.com/forums/showthre ... st16121886 and some close up shots of the PCB mods are here: http://www.rcgroups.com/forums/showthre ... st16130699 .

I'm a bit time-poor for the next couple of weeks but will throw together a proper how-to when I can. My ultimate aim is to extend this to also include EagleTree eLogger data as well but this will require adding a microcontroller at the FrSky Rx end on the aircraft. I have some basic code running but have yet to tie it all together.

Phil

[rayholland]

hi phil,

thank you for your info. these modifications are way over my head but i think my nephew can do this for me.
Great work!!! can't wait to see the final product.

[RCModelReviews]

For what it's worth -- I've suggested to FrSky that they consider a version of their transmitter module specifically for the 9X and designed to accept a digital datastream consisting of each channel pulse as a binary value.

This would allow for a much faster frame-rate (ie: lower latency) and dispense with the unnecessary hassle of creating then decoding a PPM datastream within the radio.

No word back from them yet -- but that would make the radio even better, with the custom firmware allowing for that ultra-low latency.

And, for what it's worth, my telemetry hub is designed to return a unique code that will identify the model it's in -- that opens the door to the custom firmware providing auto model-load capabilities where, when you turn on the receiver, it tells the transmitter which model-memory to use for this model. If that model is not the current one, the user would be prompted "Model xyz is turned on.. change to model memory xyz (Y/N)?" -- or something similar.

Better than model-match

[JollyKoker]

P.S.: Bruce, would you please change my username to "JollyJoker"? There is a typo i missed when registering. And due to the low postcount, (one for now) i am not possible to write you a pm for that.

Hi Bruce,

you are very consequent in thinking ahed for the things. It will be a really challenge for the "big ones" to keep up with this project once finished. And leaving the internal processing digital, as 2G4 anyway using this is a good clue. Did you tests with the serial connection of the frsky backshannel? What datarate you reached, are there problems with buffer overflows? This project is very interesting in my eyes.

Nice to hear that our weather has left europe and is now hitting down under

regards

[RCModelReviews]

Did you tests with the serial connection of the frsky backshannel? What datarate you reached, are there problems with buffer overflows? This project is very interesting in my eyes.

Yes, there are some significant constraints on the backchannel bandwidth and there is no flow-control so it's easy to lose data if you exceed the available bandwidth.

I've used data compression to squeeze more into the available bandwidth but I wish there was more available.

[JMP_blackfoot]

-- that opens the door to the custom firmware providing auto model-load capabilities where, when you turn on the receiver, it tells the transmitter which model-memory to use for this model....

For what it's worth, couldn't the model memory be stored in the receiver and downloaded to the transmitter at switch-on?
Then each modification of the model memory configuration could be uploaded back to the receiver. No more transmitter memory size constraint - it would permanently hold only a spare default configuration as a starting point for each new model - and no more model mismatch.

[RCModelReviews]

The problem is then -- what happens if you change a trim setting while the receiver is turned off?

And what happens if you reverse a channel while the receiver is turned off?

How is the receiver informed of the model's settings?

it would require a significant change to the protocol and if a receiver required replacing, you'd have to reprogram the whole thing again.

Transmitter memory is cheap and having the settings stored in the transmitter allows for cool stuff such as copying from one model memory to another when setting up similar models, etc.

Also remember that most people buy many more receivers than transmitters so if the cost of extra memory/functionality has to be included in each receiver, that's going to cost more in the long run.

What would be useful however is a unique identifier that each receiver returns when turned on -- which is what I've done with the telemetry hub. That could be a built-in function of the receiver so you'd get auto-model-load even on models without telemetry enabled.

[jay-pheno]

This, and the integrated telemetry would *really* produce a superior radio to the DX8 at a tiny fraction the price.

i agree , win win