New FrSkyX protocol

Thinking about a clickable button made me think about the reset functions of the navigation buttons, like resetting the timers on the main page by pressing the Left button. The telemetry monitor page already has button actions defined to mute alarms on a press of Enter or Exit. Seems like resetting telemetry fits well for this button function.

Test build is updated ( 9b44f22 ). In this build, navigate to the telemetry monitor page and long press (more the two seconds) the Down button to "zero" the vario altitude telemetry in Frsky and FrskyX.

Is the telemetry monitor page the best place for this action?
Should the battery discharge value also be set to zero?
Haven't looked at devo or dsm telemetry yet to see if a reset makes sense for any values there.

Hello
That is perfect for me.
The value is not kept so it is necessary to reset the altitude at each powering of the tx.
I have no experience of the battery discharge (I have no sensor which indicates it)
Regards
Morlacus

Test build is updated (91b7495).

• The telemetry reset button is changed to Up. This is a little nicer on the mono screens to avoid scrolling.
• The ground level is saved in the model file. Likely will still need to zero when weather changes, but not during a stable air day.
• A long press on Up on the telemetry monitor page now also resets the battery discharge and min cell values.

For me it's perfect. Super!!

Guys I wonder if you could help me out. I recently added a module to my Devo 8s to do frsky and have been experimenting with functionality. I just set up my first fport connection after updating a r-XSR receiver. I have betaflight correctly configured, but am not getting any additional telemetry back beyond what the basic stuff the receiver always sends... which is RSSI, Volt 1 (the voltage powering the receiver), LQI, & LRSSI. Arent I supposed to be getting more than that with fport? Like at least my lipo battery voltage returned via telemetry? Wondering if deviation frskyX supports fport telemetry at all - do I need to go back to sbus and two wires?

Maybe this is related?
github.com/DeviationTX/deviation/issues/415

From reading the "F.PORT PROTOCOL (without PhyId) V2.1" document it doesn't appear to change the over-the-air protocol or telemetry sensor data. I could not find any f.port specific code in OpenTX 2.3 (but opentx doesn't include the OTA code).

Unless there is an undocumented change it seems f.port telemetry should just work. Do you have a way to verify betaflight is sending f.port telemetry (with opentx or a logic analyzer)?

Well I don't have a logic analyzer or anything open tx. So for now all I can do is get out a pile of fc's and rxsr's and try different receiver firmwares and methods of connection. Hopefully I will sort the expected behavior out. Probably doesn't help that my first attempt at this is on a f3 swapped cc3d, so there is always the chance something doesn't work right in my target I guess too. Just figured I'd ask since I have heard that open tx users have to "rediscover" their sensors after going fport... so maybe fport was a deal breaker for deviation.

Just got it sorted. It seems that the cc3d has pull up resistors on the flexi port uart, and that was disturbing fport telemetey. I removed the pullup and telemetey started working. Fun

That's good news. Thanks for posting the resolution.

Off thread - my apologies, but we are having a discussion on Betaflight Slack about the FrSky D16 protocol as adopted in OpenTx - and that it sends 16 channels at 18ms even if set for 8 channels in the TX. My question is this (since I use Deviation and have for years, and specifically a T8SG V2+), if set for eight channels in the TX on the FrskyX protocol, does the TX send only blocks of 8 channels i.e.1-8 - at a 9ms rate, (it seems not to be the case), or is something else happening?

Copied below from this post as it will be good to have the explanation in this thread.

Deviation FrskyX sends the number of channels set in the model file. If that's set to 8 channels or less then all the channels will be updated every radio frame (9ms). If it's greater than 8 then the "doubled" channels are updated every other frame (18ms) while the remaining are still updated every 9ms. For example if the number of channels is set to 12 then channels 1-4 and 9-12 update every 18ms, while 5-8 will update every 9ms.

Much thanks, Hexfet! I'll post your response on Betaflight - very helpful in setting various Rc Interpolation and RC Smoothing parameters!!!

George

Hexfet - how does it work with the XM+ sending RSSI info on Channel 16 but with the Deviation TX being set to 8 channels? I fly that way, and I get the RSSI feed in OSD, but does that mess with the latency at all? Is it still 9ms? Better to use the 8 channel firmware on the XM+ ? Thanks Much!

It doesn't change the statement above. The timing is determined by the number of channels configured in the model.

The Deviation FrskyX RSSIChan protocol option allows sending RSSI on the last configured channel. If you have 16 channels enabled, then all will be at 18ms. If 12 channels are enabled, RSSI will be on channel 12 and channels 5-8 will still be updated every radio frame (9ms).

If you're a racer that needs more than 8 channels but still want lowest latency on AETR then it's best to put them on channels 5-8. Then up to 12 channels can be used while still getting 9ms updates for AETR.

Thanks! My R-XSR receivers rely on LASTCHAN for RSSI - I set the TX for 9 channels and the RSSI comes through on Aux 5 (Chan 9). It really is a nice piece of work that Deviation does to make that so simple. So, I assume 18ms latency and have set things accordingly.

But, my XM+ Receivers are flashed to 16 Channels with RSSI on Chan 16 - and the RSSI is not a telemetry function - it is just sent on CH 16 and appears in the OSD even with the Jumper set to 8 channels. So, my ultimate question is, if the Jumper is set to 8 channels, will the latency be 9ms even though the RX is flashed to 16 channels and RSSI is being sent on CH 16. I think you said yes, that the TX setting is what matters, but just wanted to be sure. Again, thanks!

Yes, the deviation behavior is determined solely by the number of channels setting in the model config.

Wasn't aware of this capability of the XM+, but it sounds like it's a function of the receiver only.

Exactly!

hexfet wrote: Test build is updated (91b7495).

• The telemetry reset button is changed to Up. This is a little nicer on the mono screens to avoid scrolling.
• The ground level is saved in the model file. Likely will still need to zero when weather changes, but not during a stable air day.
• A long press on Up on the telemetry monitor page now also resets the battery discharge and min cell values.

Hello
Is this modification included in the nightlies build ?
regards

Not yet in the nightly builds. There is an open pull request.