This is the value that has been asked for ages, and is only a temporary fix. A full blown rework off FlySky telem is on the way , it is just unsure which side of 2.3.0 release it gonna land on. Since we have a massive 2.3.1 release planed not to long after 2.3.0, probably part of that

Originally Posted by CapnBry

No real sensors, just iNav telemetry with all of its sensors.

Have a look at my branch for comments instead since this is what will be pushed in the end when everything will be tested: https://github.com/pascallanger/open...lysky_ibus.cpp
Pascal

Originally Posted by hpnuts

Have a look at my branch for comments instead since this is what will be pushed in the end when everything will be tested: https://github.com/pascallanger/open...lysky_ibus.cpp

mmmm (yummy sound) that looks amazing.

@3djc: I've built a copy of 2.3.0 branch and can confirm that it fixes the issue of getting "RF signal critical" when powering a receiver and bumps up the RSNR by 20 so the user's perception of what the signal is is now higher. Working with FS-IA6B and Flit10 receivers. Maybe make it 2*RSNR + 20, so the span will go from 100 at max signal down to 20 at no signal (expect to failsafe around 36)?

With my FS-IA6 (non B) the telemetry goes nuts now, but does not complain over and over with "RF signal critical". What happens now is that it gets telemetry items TRSS, A1, RQly and populates the value, but immediately flags them as old because telemetryStreaming is only set by RSNR. So it is constantly fighting enabling and disabling the values.

If this is just a quick fix, then can we just use 100-RQli (LQI) as the opentx signal source like Pascal's branch will do? That way we achieve the goal of fixing this "RF signal critical" issue, we get a 100->0 signal strength meter on a larger range of receivers (instead of 60->40 from receivers that send RSNR), and the telemetry won't flash on and off on FS-IA6 receivers. It also means users won't have to reset all their models' Low and Critical levels in this release and the next release, which I can see causing issues with failsafes due to the source of RSSI changing on every release.

I’m not against this suggestion, but we need to confirm that doing so will allow the users to properly set ‘rssi’ alarms within the limited range for the alarm, that will actually match pre control loss

If you test my branch that would accelerate... I mean I'm just waiting someone having access to different sensors and receivers to test it before doing the PR.
The problem is that no one is helping to test it right now. Therefore 3djc is trying to do something... So instead of talking about the PR of 3djc, test mine and if it doesn't break any of your current setup we call it good?
Pascal

Absolutely, I'll give your branch a try, Pascal. sweet-16-squash branch?

Just for funsies I modded the opentx origin 2.3.0 branch:

diff --git a/radio/src/telemetry/flysky_ibus.cpp b/radio/src/telemetry/flysky_ibus.cpp
index a38354605..a0efad57c 100644
--- a/radio/src/telemetry/flysky_ibus.cpp
+++ b/radio/src/telemetry/flysky_ibus.cpp
@@ -91,28 +91,24 @@ static void processFlySkySensor(const uint8_t *packet)
     id = 0x100;
   }

-  if (id == FS_ID_SNR) {
-    if(value>0) {
-      value+=20;
-      telemetryStreaming = TELEMETRY_TIMEOUT10ms;
-    }
-    telemetryData.rssi.set(value);
-  }
-
   for (const FlySkySensor * sensor = flySkySensors; sensor->id; sensor++) {
     // Extract value, skip header
     if (sensor->id == id) {
       // The Noise and Signal sensors that are specified in dB send the absolute value
       if (id == FS_ID_NOISE || id == FS_ID_RSSI)
         value = 135 - value;
-      else if (id == FS_ID_ERR) // ERR RATE
-        value = 100 - value;
       else if (id == FS_ID_TEMP)
         // Temperature sensors have 40 degree offset
         value -= 400;
       else if (sensor->unit == UNIT_VOLTS)
         // Voltage types are signed 16bit integers
         value = (int16_t)value;
+      else if (id == FS_ID_ERR) { // ERR RATE
+        value = 100 - value;
+        if (value > 0)
+          telemetryStreaming = TELEMETRY_TIMEOUT10ms;
+        telemetryData.rssi.set(value);
+      }
       setTelemetryValue(PROTOCOL_TELEMETRY_FLYSKY_IBUS, id, 0, instance, value, sensor->unit, sensor->precision);
       return;
     }

With this I get rssi on all my receivers, 100->0 (failsafe around 30), the telemetryStreaming stays on, and I do not get "RF signal critical" when powering up the receiver. I will say it is a bit weird to see signal bars on my Taranis. haha I a so used to full signal being like one bar normally that seeing actual bars seems out of place. So the concept of using FS_ID_ERR / AFHDS2A_ID_RX_ERR_RATE seems sound, but I'll build Pacal's branch with all the new code to see how it looks.

Do you want me to talk your opentx branch here or is there someplace better? I can't build for my target (X7):

CMakeFiles/firmware.dir/io/multi_firmware_update.cpp.o: In function `Fifo<unsigned char, 64>::clear()':
/opentx/radio/src/fifo.h:40: undefined reference to `intmoduleFifo'
CMakeFiles/firmware.dir/io/multi_firmware_update.cpp.o: In function `intmoduleGetByte':
/opentx/radio/src/io/multi_firmware_update.cpp:47: undefined reference to `intmoduleFifo'
CMakeFiles/firmware.dir/io/multi_firmware_update.cpp.o: In function `multiInitInternalUpdate':
/opentx/radio/src/io/multi_firmware_update.cpp:41: undefined reference to `intmoduleSerialStart(unsigned long, unsigned char, unsigned short, unsigned short, unsigned short)'
CMakeFiles/firmware.dir/io/multi_firmware_update.cpp.o:(.data.multiInternalUpdateDriver+0x8): undefined reference to `intmoduleSendByte(unsigned char)'
collect2: error: ld returned 1 exit status
radio/src/CMakeFiles/firmware.dir/build.make:5832: recipe for target 'firmware.elf' failed

The multiprotocol updater wants to use intmoduleFifo from target/common/arm/stm32/intmodule_serial_driver.cpp, but X7 target doesn't build this file only XLITE variants and X9D+. To work around it I just disabled multi_firmware_update in the build.

Telemetry works perfectly! I've got signal strength on all receivers, no "RF signal critical" on power up, 100->0 signal meter with failsafe occurring around 30.

Only issue I see is that TRSS got a new telemetry ID or something, so the old value doesn't populate. I just have to "Discover new sensors" to get a new TRSS and it updates with the TX RSSI properly (255 scale? or 250?).

I gotta say I am super excited about this. I know it has been a common issue for folks complaining that their signal was too low when using the Multiprotocol module with AFHDS2A and we'd have to repeat to just set the thresholds lower because the values are different. Now not only does that work but I have signal strength on a receiver I never thought would get it!

EDIT: Tested with iNav + Flit10 receiver, Betaflight + Flit10 receiver, FS-IA6B receiver, FS-IA6 receiver, and a generic AFHDS v1 receiver (doesn't get telemetry, but binding and control still work) and that's all the receivers I have currently.

Originally Posted by hpnuts

On my radio, system->tools->spectrum.
I'm not sure I follow your other remarks... There is no control at all. The only thing you can do at least with multi is to move the cursor right<-> left to digitally the frequency value at that spot.
Pascal

Its obvious you are running a LUA script that I take it is not for public consumption?

It is not lua, but it is still in a development branch at this point as previously mentioned.

Originally Posted by Kilrah

It is not lua, but it is still in a development branch at this point as previously mentioned.

Roger that.

The pathing fooled me.

Originally Posted by CapnBry

Telemetry works perfectly! I've got signal strength on all receivers, no "RF signal critical" on power up, 100->0 signal meter with failsafe occurring around 30.

Perfect I would say.

Originally Posted by CapnBry

Only issue I see is that TRSS got a new telemetry ID or something, so the old value doesn't populate. I just have to "Discover new sensors" to get a new TRSS and it updates with the TX RSSI properly (255 scale? or 250?).

Yes I had to remap it so it is not in the middle of other "virtual" sensors... (255)

Originally Posted by CapnBry

I gotta say I am super excited about this. I know it has been a common issue for folks complaining that their signal was too low when using the Multiprotocol module with AFHDS2A and we'd have to repeat to just set the thresholds lower because the values are different. Now not only does that work but I have signal strength on a receiver I never thought would get it!

Great!

Originally Posted by CapnBry

EDIT: Tested with iNav + Flit10 receiver, Betaflight + Flit10 receiver, FS-IA6B receiver, FS-IA6 receiver, and a generic AFHDS v1 receiver (doesn't get telemetry, but binding and control still work) and that's all the receivers I have currently.

So it looks good from your tests which is already giving a good insight that I'm on the right direction.

I think what's really left is the interpretation of the "presure & temperature" sensor to determine the altitude. I've done something but I'm not sure it works (the opposite in fact) therefore I need someone to test as I don't have the hardware myself... I've found someone but it's just going to take some time so hold on, it's coming.

Pascal

Yeah it looks perfect. I'm going to keep this as my main radio firmware for a while to see if I run into any issues. I already took it out and did some high speed quad flying and have nothing to report. I did look down at my transmitter and think, "This isn't my radio, the signal level is too high." I'm just so used to seeing 1 or 2 bars at the most. haha

I have a couple assumptions I’d just like to verify if they're accurate as I dive into updating the firmware in my two iRangeX 4-in1 Plus DIY modules ( one at a time).. ( P.S I hate rebinding Rx's cause its a hassle and things like antennas and servo wires etc break.... but it's a necessary evil I suppose)

1.) Each time you do any firmware update, either from an image or from a re-compile and re-download into the module.. I’ll need to select each model and re-bind it. Correct?
2.) Once re-bound, the DIY Module will work even if I swap the two DIY modules between two 7XS Radios that have an identical list of models in their 60 slot memory.. since the receiver in each plane is linked to a Rx’s MAC address-equivalent that's stored in a non- volatile storage location within the DIY module.. But not tied to the Radio's Settings which don't track or care about External DIY modules.

Are these two statements basically correct ? if not, what's inaccurate please
Thanks..
JimS

Originally Posted by jims123

1.) Each time you do any firmware update, either from an image or from a re-compile and re-download into the module.. I’ll need to select each model and re-bind it. Correct?

You don't need to rebind anything. It will just work.

Originally Posted by jims123

2.) Once re-bound, the DIY Module will work even if I swap the two DIY modules between two 7XS Radios that have an identical list of models in their 60 slot memory.. since the receiver in each plane is linked to a Rx’s MAC address-equivalent that's stored in a non- volatile storage location within the DIY module.. But not tied to the Radio's Settings which don't track or care about External DIY modules.

The RXs are bound to a Multi module. If you move the module to another radio the RXs will be working with that radio.
It's important that when you do the switch that the models have the same RX number (Receiver No. or whatever it's called on your radio) as well as protocol and subprotocols.

As a reminder RX number is used to match one specific RX to this number for this protocol and subprotocol. Which means that if you give number 1 to one of your RX and number 2 of the other RX, only the RX with number 2 will respond to a model configured with number 2. You have up to 16 possible matches per protocols and subprotocols. You can duplicate the RX numbers which will just break the 1 to 1 match but it will still work fine.

Pascal

Originally Posted by hpnuts

You don't need to rebind anything. It will just work.

The RXs are bound to a Multi module. If you move the module to another radio the RXs will be working with that radio.
It's important that when you do the switch that the models have the same RX number (Receiver No. or whatever it's called on your radio) as well as protocol and subprotocols.

As a reminder RX number is used to match one specific RX to this number for this protocol and subprotocol. Which means that if you give number 1 to one of your RX and number 2 of the other RX, only the RX with number 2 will respond to a model configured with number 2. You have up to 16 possible matches per protocols and subprotocols. You can duplicate the RX numbers which will just break the 1 to 1 match but it will still work fine.

Pascal

Thank you Pascal for clarifying this..
That's really great news in my case.. since I'be been using the DIY module with ASSAN Rx's and WilToy AutoBind Rx's that really don't know or care about Receiver Numbers so I leave them all as Rx No 01 I believe.. and I've been too chicken to use it with my FrSky Rx's cause well .. there is an internal RF board in there I select and use with them instead..

Some day I will try a DIY with the FrSky Rx's too tho, and I understand the constraint because I deal with it every time I want to use the same Rx No ( and Receiver) with a slightly different version of the OTx Model to test a new change in it, I don't expect the DIY will flag duplicates like OPEN Tx does when dealing with duplicate Rx No's but it sounds like they behave pretty much the same and will work anyway on a duplicate FrSky Rx No. when I break the 1 to 1 match.
Good to know.. Thanks!
JimS

P.S. I am surprised to hear that I can expect to be able to update the firmware in the DIY and it will still work without need to re-bind each plane each time .. that's great news.. !