New FrSkyX protocol

The discovery step is not required. Any data received from any sensor is saved and displayed as long as the sensor is supported. The limitation in FrskyX is that multiple instances of sensors with the same ID will overwrite each other (e.g. if you had two varios, the displayed value is the one most recently received from either sensor).

The deviation fixed id does not have any relation to opentx receiver numbers. Any match would just be coincidence.

A txid value in hardware.ini is not used directly to replace the MCU id pulled from ROM (see MCU_SerialNumber). It would be difficult to find a txid value that would match to receivers already bound to taranis or deviation (without txid in hardware.ini). It might be a good idea to change MCU_SerialNumber to make that possible, but that discussion should be in another thread.

No it wil not work to use the same rx number in taranis and Devo. For the bind there is also a tx number used. For devo we can use a self choosen number. Not so for taranis.
The model id number can be 1 or 2 etc. but it will not make it interchangeable (is that a real word??)

personally I think it is even better safer to keep that......

2 devo's I can understand you would like that in some case, f.i. you buy a new devo and want to transfer install everyting on your new devo, all will fly out of the box wirthout rebind.. Or you can have a spare tx with you and fly which one you like etc.
Flying one time with Taranis, other time same model with devo, hmm I think complicated as all trims mixers setup are different, and sooner or later you'll face an issue crashing the model forgot about a setting etc ....

I think this so called model match is just to ensure only one rx, tx combination with particular selected model will work, personally I like it a lot, with my airtronics (no model match), I made the mistake once flying the model while still selected the other model ouugh...

Test build is updated - 1bb.
- The 320x240 telemetry test page now displays the extended telemetry values (except Cell6 wouldn't fit)

Please test on color screens if you can - thanks!

Hello,
Test Ver.1bb on Devo8s with FrskyX, X8r

Telemetry Test Page is very nice !

All Datas are looking good, only Amp should be /2 ( i compared it with my Amp Meter and it is around 50 % to high on the FAS 100 )

greetings Alex

Can I load the latest nightly build for 7e to acces to the X-series protocol? I received my X4R Sbus receiver so can try it out.

Yes, the protocol is now in the nightly builds.

Using the nightly builds on a regular basis is a bad idea. The 5.0 release is recent, so has most/all the bug fixes and hardware support of he nightly build. Since we're doing active development again, things are breaking in the nightly build.

I'd like an automated build of a branch that is the release build + new protocols and tested bug fixes, but it hasn't happened yet.

Just checking in I'm up and running. No testing tonight, it's late and I'm going to bed but I'm gonna try to fly my mini tri (basicly indestructible) with it tomorrow.

I love my taranis but I can not wait to have a choice (tray X9E vs regular D10 that I can just grab and go fly without the harness and setup)! Thanks KS everyone who made this possible (Hexfet and testers)!

Install (and removal of devo module) and test with a spare X4R.

Ok the model is flying! I'm getting good RSSI and I am receiving 2 voltages but I'm not sure what either are... Which voltage corresponds to VFAS (the voltage values as read by cleanflight and sent from cleanflight telemetry over Smart Port)? I dont have AD2 hooked up.

VFAS is in VOLTA - row 6 in the Bat column. The VOLT2 value in the pic does come in over s.port though - maybe cleanflight uses the AD2 ID? VOLT1 is the internal voltage of the receiver.

OK yes I see that and it's reading correct but how do I choose that value for a small box value to put on the main page? I have telemV1, telemV2 and TelemV3 as well as cell and cells1-6, no "voltA" and none of the V1 - V3 are it (they're all values under 5v)

Thanks
C_K


Edit: it shows up on the main page after setting the desired box to TelemVAmp!

Devo 7e 5.0.0-481a401,nightly build.
Tested with X4R on Sbus connected to Raceflight.

I copied my model from devo 7e, from D4R.
Channel 1-8 tested and works. Rx volt works, RSSI works, AD1 volt not tested yet, will do later, but I find one issue.

scale +-125 for, D4R = 1000-2000 on flight controller
scale +-100 for, X4R = 1000-2000 on flight controller

For X4R setting scale +-125, will result in scale overflow, as will go over 2100, resulting in faulty data.

I would prefer to put scale identical to frsky D Protocol, then also models can be shared work identical one or the other protocol. And also because deviation, can go up to +-150 Scale and 125 scale setting will already lead to faulty result. (At least when tested with Raceflight, not sure if it is Sbus overflow, or Raceflight, who cant handle higher value than 2000 andy way at full stick value was completely wrong)

Thanks for the testing!

The channel scaling was discussed starting at this post . I think the reasoning there is sound, though different than Frsky, so I'm not inclined to change it. And it would break models already created for FrskyX. But it can be changed if there's a consensus.

It's good practice to manually set endpoints on a model every time you set one up. There's a ton of things that can affect the endpoints, ranging from differences in calibration to timing differences on the flight controllers.
So no matter the scaling, this needs to be checked and adjusted as needed, so it may as well stay as-is.

Hmmm personally, I prefer we keep the same scale for x protocol as we also used for d protocol.

As cale in deviation can be changed up to +-150, however when set to 125, in my case it allready result in stange signal (overflow), so when above 2100 I think it is the limet I expect is cannot go higher.
Maybe it is is my flightcontroller (Raceflight) then ok, but if it is the X protocol -deviation who generate overflow or buggy output, then I prefer we change the scale equal to D series.

As +-125 scale , should be safely possible to set without issues.

Fernandez wrote: Hmmm personally, I prefer we keep the same scale for x protocol as we also used for d protocol.
.

+1

Can someone confirm what level of D16 telemetry is included in the nightly build please? I agree with mwn about the temporary branch until the development of fixes in version 5.0 stabilises.

I appear to be having some sort of protocol based issue...

I'll be flying, hovering or whatever and all the sudden I'll get a single failsafe engaged beep and the model will fall a foot or two then control will come back.

It doesn't appear to be range related as I get it happening regardless of distance. I also experience the opposite: again I'll be hovering still and for one second it'll climb like I'm commanding high amount of throttle.


Neither happen with taranis.