New FrSkyX protocol

In base of LQi value you can adjust the fine variable on the fly.If the values are less than 50 you are set.Keep some distance from RX to avoid swamping.
This way you can get more accurate lock on the channel.
Fine variable takes value from -127 to 127..Need adjusting one time and set for protocol selected not for every flight
So you increment up from -127 till you get right values for LQI.Make it on the fly.The LQi you read it from telemetry frames The TX and RX channels should be in sync.
LQI as the name said is the best indicator of the link quality, is better than RSSI.

Hi,

Had a strange lock-up yesterday. Took a full format and flash (even just a format and reload didn't fix it, hae to flash the DFU).
No issues last use, powered on and nothing...

Hi all,

If i good understand, for telemetry with the xsr on my devo10, i should buy this converter and put it on my quad ?
S.port to uart converter

we need nothing else on the Tx ?
i go to the telemetry menu and setup the lines i need ?

Thank you

That particular sensor is for serial data transfer and is not supported yet. Any of the s.port sensors for voltage, vario, gps, and current are supported. Or a s.port telemetry source such as a flight controller board.

And you need a cc2500 module in your devo.

cool, i have the CC2500 working now very well with the XSR, i have the RSSI, but voltage sensor would be great !

As same far telemetry distance and control distance? Can Deviation firmware make the LNA enable?

Yes, if your cc2500 module has PA/LNA then deviation enables them at the proper times.

hexfet wrote: Yes, if your cc2500 module has PA/LNA then deviation enables them at the proper times.

Thanks you,I mean if I use the Multiprotocol TX Module, all the LNA can be enabled?

I've now had a second instance of file system corruption during data logging that required a format and reload (of the file system only, not the dfu).

Will load video later. This time it happened in flight but thankfully this issue doesn't cause a loss of control (but note it does cause a loss of internal devo safety including allowing startup without throttle check) and obviously lack of any data on screen at all.

What is the data logging configuration?
Can you estimate how much data had been captured when it happened?

It's setup to log RSSI TEMP and throttle % whenever the arm switch is on (well technically it's ¡Mix2!)

Both times it's happened now it's been after multiple days / weeks of use so the log was getting pretty big. Probably over 20000k.

Really busy but I have an interesting video to upload ASAP...

Probably best to start a new thread if it's related to logging. That feature is independent of the protocol used.

The addition of S.Port telemetry output through the trainer port is in the latest nightly build. The bit rate is changed to 57600bps.

The User Manual test build contains pdf files of the latest manual updates.

The frsky_lqi test build adds LQI and LRSSI telemetry to Frsky and FrskyX. Text I put in the user manual is below (mistakenly since it's not merged yet ).

The LQI (Link Quality Indicator) and LRSSI (Local RSSI) indicate the quality and signal strength of the telemetry
signal from the receiver. The LQI can be used as a guide for adjusting the fine frequency protocol option. Lower LQI
is better and values under 50 are typical. The LRSSI units is (approximately) dBm.

Hi, I know I was one of the ones asking for telemetry output on the trainer (and for that im thankful) but right now with my datalogging causing file sys corruption issue im looking for the last usable build before that was implimented while I try to get ahead of my issue. Can you twll me which one to try first (thats still available)?

EIther that or a way to disable the output, either in a menu somewhere or in the tx / hardware.ini

You can disable it in the model setup by changing the PPM In setting to something other than None. Don't need to do anything else.

Hi, I posted this over on rcgroups but didnt get any replies.

Is it possible to transmit lipo voltage to my non-ultmate 7e via my FrSky XSR? I have the XSR hooked up to my SPR F3 flight controller with my lipo plugged into the battery voltage monitoring port on the FC. I get RSSI strength and Volt1 which shows my rx voltage (4.8v) but Volt2 is 0V. I just want a low voltage alarm so i dont have to strap a battery alarm to my quad.

Yes it's possible but you'll need to make some hardware.

The 7e doesn't support s.port telemetry from the FC. You'll need to feed the lipo voltage to the XSR AD2 analog input. Use a resistor voltage divider so you put no more than 3V on the analog input when the lipo is fully charged.

The XSR doesn't provide a connector for the analog input but looks like someone on rcgroups has figured out where to make the connection.

Use the AD2GAIN protocol option to scale the voltage display to the actual voltage of the lipo.

LumpyLouis wrote: Hi, I posted this over on rcgroups but didnt get any replies.

Is it possible to transmit lipo voltage to my non-ultmate 7e via my FrSky XSR? I have the XSR hooked up to my SPR F3 flight controller with my lipo plugged into the battery voltage monitoring port on the FC. I get RSSI strength and Volt1 which shows my rx voltage (4.8v) but Volt2 is 0V. I just want a low voltage alarm so i dont have to strap a battery alarm to my quad.

The reason why the 7e doesn't support s.port telemetry is because of the smaller size flash on the MCU. You can free up the flash space by compiling your own 7e firmware without the standard GUI. Most people don't need standard GUI and you will free up enough space to include s.port telemetry. No hardware hack is required.

hexfet wrote: You can disable it in the model setup by changing the PPM In setting to something other than None. Don't need to do anything else.

hexfet, is there any reason why the telemetry serial out for FrskyX is enabled by default? You only check whether the PPM In is active. However, it will still conflict with other modules that use the UART port, such as Voice, and probably debug output too.

IMHO, I think the majority of FrskyX protocol users won't be using the telemetry serial out, and having it enabled by default is not a good idea. I believe it will be better to have an option (such as protocol option) to explicitly turn it on.

My thought was that using PPM In to disable the s.port output is sufficient and no separate control is needed. If you're actually using PPM this happens automatically. If you're making your own debug build for serial output, and using frskyx, then I expect you're savvy enough to disable the s.port echo. So why complicate things with another option to set?

Compatibility with voice alerts will be addressed when a voice alerts PR happens. Likely by disabling s.port echo if voice alerts is using the trainer port. Just got a few DFPlayers so I'll be looking at this soon.