Frsky compatibility

Yes, exactly. The X protocol is not working right yet, D8 is working fine. I'd suggest using a D4R-II with PPM, so you only need 1 wire for 8 channels.

Arakon, bonsoir.
Good idea.
This kind of practice is not yet in my intellect.
I will ask a friend for one help.
Have à good night
Regards

Please leave the other thread for the ongoing discussion by the protocol developers. A lot of us are following it closely, and can answer questions about it here - where the development is finished.

To try and answer you questions:

1. Yup, that's the most recent official build. It has support for the FrSky V and D protocols (those names - as well as "X protocol" aren't official, but are derived from the names used by the radio modules that use them V8R, D8R, X8R, DJT, etc.). You will need to install a CC2500 for that (looks like you have one one). Read the articles from bitbucket.org/PhracturedBlue/deviation/wiki/ModuleInstallation for current instructions.
2. It has all the software you need to install it on your transmitter, but there aren't really any official tutorials. If you tell us what you'd like a tutorial on, we can point you to one if it exists. For installation instructions, the official ones can be found in the Installation section of deviationtx.com/user-manual/user-manual-6-8-12 .
3. Sort of. Some of the international X series receivers can do D as well, but telemetry is wonky. Likewise, some of the older V series receivers can do D, but don't have telemetry at all.
4. Yes, the X protocol is in development. Since they're still trying to fix the control channels, changes may well break the things that work ok now, so flying with it is not a good idea. When it's ready, it will be merged into the nightly builds. You'll need to upgrade to a new nightly at that point.
5. Yes. Be aware that using PPM/CPPM/PWM Sum with 8 channels has some issues, and needs to be done with care. In particular, dialing any on/off channels back from -100/100 to -50/50 or lowerr.

Speaking of protocol development, still need a volunteer to test the Frsky-V8 hub telemetry fix in the protocol_combo test build...

hexfet wrote: Speaking of protocol development, still need a volunteer to test the Frsky-V8 hub telemetry fix in the protocol_combo test build...

FrySky-V8? You sure you don't mean D8?

I can try it with my DIY arduino-based hub, if that would help. Well, as soon as I put my 10 back together (though this would provide more incentive).

It's the D8 protocol. Why is the protocol name Frsky-V8 in deviation?

I think you've got the names backwards. The protocol supported by all the FrSky V series radios is called FrSky-V8 by deviation, and AFAIK none of them has telemetry. The protocol supported by the FrSky D series radios (and some of the V and X series radios for forwards and backwards compatibility) which I think FrSky calls D8 is called just FrSky by deviation. PB changed the names last march, from FrSky-1 (the V protocol) and FrSky-2 (for "2-way", since it had telemetry support).

I've suggested that we fix the names - either using the FrSky names if it has them, or the letter designation if not - but nobody else seemed to care.

X-D-L-V Series seems to be the names Frsky uses.


www.banggood.com/Frsky-Horus-X12S-Textur...itter-p-1037814.html
Compatibility: FrSky X series, D series, L series and V8-II series receivers

Yep, I had the names backwards. Thanks. The telemetry fixes are in the deviation Frsky protocol.

I'm with Mike on this, just change the names to reflect what Frsky does for they receivers. No need to introduce yet another layer of complexity.

+hexfet, would testing the D8 code with my DIY arduino help? I don't think so, as the software on it is also untested, but let me know if you'd like me to try.

The L series is their "Long range" stuff. And yes, it's yet another protocol. They claim twice the range of the X series radios, which is already 50% more than the D series radios.

Hmm. The actual text on the banggod page is "FrSky X series, D series, L series and V8-II series receivers". And (almost) all the V-series radio names started with "V8". However, if you look at the D8R manual, it talks about "D8" and "D16" mode. Not to mention the EU mode."

Given that V8 is the name they use, I think we should leave that one alone. The old "FrSky" should either be -D or -D8, depending on whether or not we want to call the new FrSky protocol -X or -D16. One set of names matches the receiver series names, the other matches the receiver mode names. I'm ok with either one, and think hexfet should pick one. If we ever implement the -EU protocol, that one is obvious.

The problem with changing the name of the FrSky protocol is that it will break existing model.ini files. However, we've changed it before, and it's only been available in the nightly build, so I'm ok with that.

FWIW, I don't see any reason to implement the -EU protocol. IIUC, right now it's legal to flash receivers with the non-EU firmware, so you can do that to use deviation. Later this year, it'll become illegal to do that, but it'll also be illegal to install deviation, so who cares? But I think we should get some of our EU users to weigh in on the matter.

I think the arduino testing would help because it's unlikely to get tested for many sensors otherwise. Not sure how you're going to shuffle it into your project stack without toppling it.

I've got D4RII receivers. Just need to build an equivalent diy. And finish my multi-module...

mwm wrote: ...names. I'm ok with either one, and think hexfet should pick one.

Why are you sticking me with the hard thing?


Luckily midelic and planger have already named this implementation FrSkyX. Let's keep it the same as the multiprotocol module

My opinion is to leave the existing Frsky names unchanged. Just don't see much benefit in changing them.

You're the last one to touch it, so it's yours to fix

I'm still working on getting a Tx with a CC2500 working. As soon as I do that, testing with the arduino code should be easy - the arduino hardware is all set up and everything is connected.

I've attached a zip of the arduino library I'm using. There's a test file that sends fixed values for all the possible sensors. Last time I checked it, I was getting values for everything - unreliably. I suspect the problem is the packet length limit on the being discussed on the X protocol thread. Going back and testing each sensor one at a time was the next thing on my task list for this.

The actual sensors I have are a GPS sensor. I've also got a 3-axis accelerometer and a humidity detector (this is for a yacht - that's roll & leak detection).

Note that this isn't really release code - just stuff I wrote to test the telemetry code in deviation. I'm uploading it on the chance that someone can use it to test before I get to it.

Looks reasonable. Why is start_frame in both the loop and send_block routines? Are you aware of this code ?

Don't know that I saw that code, but I looked at a number of different libraries before I wrote that. About the same time as that posting, in all probability.

Don't recall why it's in both. I know dealing with it needing to be at the end of the last frame as well as at the start of every frame caused some odd code gyrations.

That must be it. Looks like the D8 protocol has the start code front and back.

mwm wrote: FWIW, I don't see any reason to implement the -EU protocol. IIUC, right now it's legal to flash receivers with the non-EU firmware, so you can do that to use deviation. Later this year, it'll become illegal to do that, but it'll also be illegal to install deviation, so who cares? But I think we should get some of our EU users to weigh in on the matter.

I agree the EU protocol is flawed but the new EU LBT would be useful to implement. I have been doing a lot of research regarding this as I am in the UK, looks like all new Frsky transmitters are now sold in the EU with D16EU LBT firmware and it is locked down to prevent reflashing. All EU X-series receivers will be LBT but are reflashable using the frsky programmer and s.port converter or a taranis with opentx 2.1.x .
This is a list of current frsky protocols:
V8
LR12
D8
D16 (international)
D16EU - flawed protocol with a number of users reporting range issues. With this firmware Taranis TX's had D8 disabled in Opentx as standard. Superseded as of Dec 2015 by LBT.
D16EU LBT - New firmware addressing range issues.

I think some people are going to want the EU LBT protocol as all new EU receivers will be sold with this protocol and no one really knows if the receivers are going to be locked down in the future like the official tx modules.

What are the difference between D16INTL and the D16EU versions ?

Are there any loss of functionality in the D16EU vs the INTL ?

blackmoon wrote: What are the difference between D16INTL and the D16EU versions ?

Are there any loss of functionality in the D16EU vs the INTL ?

EU version complies with EN 300 328 V1.8.1 and is CE marked as of Jan 2015. This is basically implementing Listen Before Talk functionality and is not cross compatible. See here:
www.etsi.org/deliver/etsi_en/300300_3003...n_300328v010901p.pdf
Frsky disabled D8 on the taranis with D16EU firmware - I think it was to comply with this spec. The D16EU LBT now complies in both D8 and D16 mode but it is not compatible with D16INTL or D16EU.
There is no loss of functionality apart from some reports of reduced range on D16EU which have been addressed in D16EU LBT.