New FrSkyX protocol

Thanks for the testing Wene. Pull request submitted.

Thanks to hexfet and vlad_vy !!

As Devo now got more channels, I guess I don't need my Taranis as it is too versatile for a newbie like me. Devo is of the right balance and I particularly love the trim buttons more than the throw switches.

Devo has always been far superior to a Taranis, so nobody really needs a Taranis. My drones use DSM2, DSMX, FrSky, FrSkyX, JJRC, Hubsan dialects, Cheerson dialects, Futaba, FlySky and DEVO. Now show me a Taranis that can do all of that. None of them can. Taranis might support only few of those at a time, if I’m lucky, mostly with a bulky external module. Devo just has it all, one button click away. Taranis is merely an outcome of a lucky YouTube hype, that’s all.

That said, having easy-to-install Hall effect gimbals on the Devo would be awesome.

andrej,
You have forgotten one CRUCIAL point:
Hampering with the stock Devo by changing firmware and/or adding modules voids any certification immediatly.

As good as a modded Devo on Deviation then may be (and I have both worlds - Taranis and a 12E moddded to the hilt to judge their specific quality on my own), this loss of certification will backfire if you have to let your RC insurance step in to regulate any damage.
(Here in Germany it is mandatory to have such an insurance)

Just saying.

Besides - as long as I see brave fellows here that are willing to try any mods, who neither have a clue how to build it reliable or in decent quality nor are knowing enough to use the GUI properly, I see problems occuring everywhere where common sense simply forbids to use this frankensteined TX for security sake on heavier and more dangerous builds.

Don't get me wrong, I encourage everyone to mod his TX, the result is often enough outstanding and reveils the real possibilities of these TXes. But one should know its limitations.

BTW, I LOVE my speaking multimodule 12E as an cheap and clean AIO solution, but I just use it on BNF toys that aren't more than 2-3 ounces and only on my private property.
For all serious builds I go with a FrSky OEM TX. For reason as stated above.

MikefromGermany wrote: andrej,
For all serious builds I go with a FrSky OEM TX. For reason as stated above.

Nice one Mike, I wouldn't have been so diplomatic....

I don't use my Devo for anything but my "toy" quads and small foamies - it is an ideal form factor for my son with his small hands.

The insurance issue is the same in the UK relating to CE marking and bodged TX modules, I am not saying the Devo is any less reliable than Oem Frsky when installed correctly but I have seen some dreadful TX builds in the past by people that have zero understanding of RF electronics.

I have tested the 16 channel mod with my U7e and what I have tested has worked flawlessly. I tested the channels above 12 on the betaflight console with quad attached and saw expected behavior. I modified my model file to send some of my channels above 12 and flew a couple of batteries LOS with my quad with no issues. I used channel 14 to switch flight modes and that behavior worked as expected.

Thanks compman2. The change will be in the next nightly build (when they start again).

Mike, I agree with your reasoning on the insurance. In the US it's not required by law and where I fly there's nothing around to damage. In my opinion a deviated radio remains legal according to the "Home-Built Transmitters that are Not for Sale" section of this document , though it may no longer be "certified".

Curious if you are able to use OpenTX or need to use the OEM firmware?

MikefromGermany wrote: andrej,
You have forgotten one CRUCIAL point:
Hampering with the stock Devo by changing firmware and/or adding modules voids any certification immediatly.

Mike, if changing the firmware voids your certification on a Devo, then the same should hold for a Taranis, right? That would imply that flashing the latest OpenTX to replace the factory firmware would also void certification. Losing certification e.g. for re-flashing a Taranis from FCC to LBT/EU or vice versa (in order to comply with local regulations wherever you fly) sounds quite paradoxical to me. (As a side note, it's also great that the FCC/LBT FrSkyX variant is just a standard model option on Deviation, as opposed to re-flashing the firmware on a Taranis.)

Admittedly, an uncertified 4-in-1 module is a different story. If someone sold a fully certified 4-in-1 module for, say, $200 extra, I'd be happy to pay that, but sadly there's no certified version available.

MikefromGermany wrote: As good as a modded Devo on Deviation then may be (and I have both worlds - Taranis and a 12E moddded to the hilt to judge their specific quality on my own), this loss of certification will backfire if you have to let your RC insurance step in to regulate any damage.
(Here in Germany it is mandatory to have such an insurance)

Good point, but if a flashed Taranis and also a FrSkyX receiver reflashed from FCC to LBT already gets you on thin ice, the fact that the original hardware was certified from the factory doesn't seem to help much. This is one of the areas where regulations and insurance policies are painfully detached from reality.

Insurance is an interesting matter, so I'll take the liberty to ramble about it a bit. (Forum moderators can of course delete my post if they dislike it.)

Insurance caveats are the reason why I never choose an "RC" insurance plan. Instead I have a common personal liability insurance that covers any unintentional damange I may cause. I asked the insurance company to send me an explicit written statement confirming that my insurance plan covers model aviation. The statement explicitly says that damage caused by my "aircraft models or drones" is covered, within the legal weight limit of 30 kg. (The heaviest drone I have is less than 2 kg anyway.) Importantly, there are no technical requirements concerning the aircraft, the radio system or the like. This type of insurance also matches all the local legal requirements imposed on "models" above 0.5 kg (in Switzerland). The "RC" plans are cheaper, but have way too many caveats.

Then there's this obvious "double standard": A certified transmitter is great, but what about receivers? A (certified) receiver is expected to somehow work, although no official authority checks that it is (1) properly mounted, (2) powered in a correct and reliable way, (3) equipped with a compliant antenna system and (4) sufficiently protected from interference from other onboard electronics. Only the receiver itself is certified, but not the whole aircraft, regardless type, build quality etc. "Receivers" also transmit telemetry (which has further safety/compliance implications).

MikefromGermany wrote: Besides - as long as I see brave fellows here that are willing to try any mods, who neither have a clue how to build it reliable or in decent quality nor are knowing enough to use the GUI properly, I see problems occuring everywhere where common sense simply forbids to use this frankensteined TX for security sake on heavier and more dangerous builds.

Don't get me wrong, I encourage everyone to mod his TX, the result is often enough outstanding and reveils the real possibilities of these TXes. But one should know its limitations.

I completely agree with you on this. People should definitely avoid mods that go beyond their understanding of the matter or pose additional risks. However, the 4-in-1 mod on a Devo doesn't really have much to do with electronics. It's a matter of plugging an antenna pigtail, plugging a connector and soldering 3 chip selector wires. It doesn't involve anything like re-flowing / re-balling of complex RF chips onto a board, modifications of an antenna system etc. The only weak point in the whole process is the trust in a 4-in-1 chip from Banggood (or from whoknowswhere). As far as the mod itself is concerned, it's just mechanical work with a tiny bit of low-precision soldering (wires to pads).

MikefromGermany wrote: BTW, I LOVE my speaking multimodule 12E as an cheap and clean AIO solution, but I just use it on BNF toys that aren't more than 2-3 ounces and only on my private property.
For all serious builds I go with a FrSky OEM TX. For reason as stated above.

Well, I don't think that Devo with Deviation and 4-in-1 is good for toys only. (You didn't say that explicitly, but that's the overall impression I get from these^^^ statements.) First, an OEM Taranis would be somewhat limited in usability if you couldn't flash the latest OpenTX or switch between FCC and LBT when needed. Second, an OEM Taranis can and does fail , just like any other piece of equipment. It's sad that regulations and insurance policies see it otherwise.

Good day!

Could you please help me.
I've devo7e + frskyx4r reciever (new).
Use last night build firmware.
I'can't see AIN (Volt2)
Is is bug in the firmware or reciever is fault?

Did you set value for the multiplier ratio in the protocol submenu, I find this bit of confusing....

I've checked the multipler value. There are 100.

I confused that the voltage value is "shaded" and do not updated.....

The shaded background does mean the telemetry value is not being received. What voltage are you applying to the AIN input? Maybe the receiver doesn't send if below a certain threshold.

Can you please help me, you look like you know what is hapening. I have a jumper t8sg and an Frsky XMplus. I flashed the RX with rssi firmware and now channel sixteen in receiver tab in BF is working. but in setup tab and in osd my rssi value is always between 28 and 32 no matter what. does not the FC read the value from the RX directly? does it have something to do with the jumper? I am stuck and i can't figure it out.

hi there , Can you please help me, you look like you know what is hapening. I have a jumper t8sg and an Frsky XMplus. I flashed the RX with rssi firmware and now channel sixteen in receiver tab in BF is working. but in setup tab and in osd my rssi value is always between 28 and 32 no matter what. does not the FC read the value from the RX directly? does it have something to do with the jumper? I am stuck and i can't figure it out.

hexfet wrote: The shaded background does mean the telemetry value is not being received. What voltage are you applying to the AIN input? Maybe the receiver doesn't send if below a certain threshold.

If I measure the voltage on the disconnected AIN pin, there are ~3.3V
If I touch the AIN pin and ground, the voltage descend to ~0.4V (I've short circuit through hand)
I've tried to apply to AIN pin 1.5V-3.8V...
Multiplier changed from 0 to 2000
Result: no changing.... on the telemetry is 0V....

Bozos, looks can be deceiving. I don't use this feature. If you have the model configured with 16 channels and the RSSI protocol option set to LastChan then deviation will put an RSSI value on channel 16.

andreypav, you have found a problem in the documentation. The VOLT2 telemetry value is not available on the 7e in the FrskyX protocol. It is available in Frsky, and those two protocols share the same telemetry display code which is why it appears on the telemetry monitor page. The Frsky protocol includes the VOLT2 value in the standard receiver telemetry, but in FrskyX it is sent in the extended telemetry (s.port) packets which are not supported on the 7e due to memory limitations.

Thank you very much for your answer. I did that too at the model setup. But what I set on the transmitter isn't in order the rssi to work at the transmitters telemetry? Doesn't my flight controller take the rssi value directly from the receiver from sbus?

hexfet wrote: andreypav, you have found a problem in the documentation. The VOLT2 telemetry value is not available on the 7e in the FrskyX protocol. It is available in Frsky, and those two protocols share the same telemetry display code which is why it appears on the telemetry monitor page. The Frsky protocol includes the VOLT2 value in the standard receiver telemetry, but in FrskyX it is sent in the extended telemetry (s.port) packets which are not supported on the 7e due to memory limitations.

Ok! Now I understand! Thank you very much!