RSSI OSD display in iNAV 6.0.0 (RC1)

[NorthIceMan]

Could not get RSSI to show anything but "1" (number 1) So in CLI I set "rssi_source = CHANNEL", and "rssi_channel = 11". Then in Receiver page I set "RSSI Channel" to 11. In Taranis Qx7 I Config an Input (for rssi) with source on RSSI , then an Output to send rssi to channel 11. RSSI then shows on OSD as 99 (Oh well, missing only 1% is not bad!).

FYI-I am connecting to a Matek H743 WING FC via FrSky R9SX receiver and R9M-2019 module on a Qx7 - configured as FPORT. BTW-in Receiver page both "Serial Port Inverted (comparing to protocol default)" AND "Serial receiver half-duplex" had to be set to OFF I wondered if the 100% (true rssi value) could be reached by somehow multiplying that "1" by 100 someplace? ... and why FPORT doesn`t get this to FC ? If there is a more elegant way to do this by manipulating the rssi settings in CLI please let us know.

[OptimusTi]

For some reason that escapes my sleepy mind, RSSI goes 100 units but it starts from 0 to 99. Other protocols like crsf, don't have this issue because rssi is scaled differently.

[NorthIceMan]

Correction....in the above... "then an Output to send rssi to channel 11." SHOULD READ "then an entry in MIXES for Input rssi on Cnannel 11.

[b14ckyy]

if you use FPort, then in CLI just use set rssi_source = PROTOCOL you need to correct the scaling as fport scales from 0-49 so you need to set rssi_max = 50 No channel assignment needed and you should be golden.

[NorthIceMan]

Thanks for your reply. Is it same if I use SBUS?

Ron

On Fri, Mar 22, 2024 at 7:21 AM b14ckyy @.***> wrote:

Closed #8762 https://github.com/iNavFlight/inav/issues/8762 as completed.

— Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/8762#event-12213756214, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARYDOP63C3CORXBRMKCQI4DYZQA3ZAVCNFSM6AAAAAAUPZKNCOVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJSGIYTGNZVGYZDCNA . You are receiving this because you authored the thread.Message ID: @.***>

-- A Man can never have too much wine or too many books or too much ammunition

[sensei-hacker]

Thanks for your reply. Is it same if I use SBUS? Ron

F.Port really just packages Sbus and Smartport together. So yeah, f.port is Sbus.

[b14ckyy]

Although f.port contains a pure sbus stream, the RSSI feedback comes over the (already bidirectional) SmartPort stream.

When you use sbus + SmartPort Telemetry, then SmartPort is handled as a one way street and RSSI does not come back in protocol form. Then you need a RC channel to provide RSSI info to the FC.

When using f.port then the SmartPort datastream is bidirectional and you get RSSI as a data package to the FC.

Maybe this is a good point for an enhancement?

[NorthIceMan]

Thanks for the clarification and yes it probably wouldn't take much work to get to an enhancement.

I have been building and flying model aircraft for 71 years and there is probably more that I forgot than what I remember !

I'm in NB Canada - where are you located? Do you fly drones or airplanes?

Ron

On Sat, Mar 23, 2024 at 4:46 AM b14ckyy @.***> wrote:

Although f.port contains a pure sbus stream, the RSSI feedback comes over the (already bidirectional) SmartPort stream.

When you use sbus + SmartPort Telemetry, then SmartPort is handled as a one way street and RSSI does not come back in protocol form. Then you need a RC channel to provide RSSI info to the FC.

When using f.port then the SmartPort datastream is bidirectional and you get RSSI as a data package to the FC.

Maybe this is a good point for an enhancement?

— Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/8762#issuecomment-2016399509, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARYDOP6FJ2HZEU2D7KDNE3DYZUXNLAVCNFSM6AAAAAAUPZKNCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWGM4TSNJQHE . You are receiving this because you authored the thread.Message ID: @.***>

-- A Man can never have too much wine or too many books or too much ammunition