CRSF: Haptic feedback due to low RSSI values

[KnuckleUpFPV]

Not sure whats causing it yet. Going to put the wing back in the air and then check the sensor list to see whats causing the alarm. I will post the logs once I pull them.

[KnuckleUpFPV]

It was just the rssi warning. I turned it off in the menu and its good to go.

[teckel12]

I assume you mean you turned off in RSSI Feedback in the Lua Telemetry menu?

What RSSI telemetry sensors do you have? The standard Crossfire 1RSS & 1RSS? If you're using the latest development branch, Lua Telemetry should show the RSSI value based on these sensors.

Maybe you have your RSSI Low alarm and Critical alarm in your OpenTX settings for this model sent too high? They default to Low=45 and Critical=38. I know many Crossfire users think RSSI is always 99 with Crossfire and only drops once really bad, but that really isn't the case. Getting the actual RSSI values and using the 130dB scale is what Lua Telemetry is doing.

Lua Telemetry uses the RSSI low and critical values you have set for the model in OpenTX. I would assume the RSSI value shown in Lua Telemetry is somewhere in the 80's or 90's?

Another rule with Lua Telemetry is if something is beeping or vibrating, the reason should be obvious by looking at the display. The value flashing (or yellow/red on Horus) is the value that's causing the alarm. Also, as you discovered, these alarms can be controlled or turned off for unique situations.

[wx4cb]

@teckel12 wouldn't it be better to use the RLQY and TLQY for crossfire? the 1/2rss values aren't really indicative?

[teckel12]

@wx4cb RLQY and TLQY go from perfect to zero. Not really a linear method of showing signal quality (and zero warning). Also, according to TBS, the RSSI values are the correct signal strength indicators.

[wx4cb]

you need to use them with RFMD though right? when rfmd is 1 and lq is like 70 percent then time to turn around.

[teckel12]

@wx4cb My experience is that LQ goes from perfect to really bad in a heartbeat. RFMD even starts at 2 when using 12 channels. Basically, that method is flawed, even though I know it's common with Crossfire flyers.

As TBS has not got back to me on how they calculate LQ and RSSI that they transmit over channel 8/12 back to the FC, I'm going with what they have provided to date. RSSI is the better of 1RSS and 2RSS at a 130dB scale. Until I get a way to calculate a better LQ or RSSI, I'm forced to go with that. Doing any type of calculate based on RLQY and RFMD yields very poor results.

If you believe you have a formula that works, I'd love to see it.

[wx4cb]

All i know is that i send lq over to the fc on 12. I have a callout on the taranis when the fmd goes to 1.

I use that as an indicator to watch the lq on the osd.

On Sat, Jan 19, 2019, 15:05 Tim Eckel <notifications@github.com wrote:

@wx4cb https://github.com/wx4cb My experience is that LQ goes from perfect to really bad in a heartbeat. RFMD even starts at 2 when using 12 channels. Basically, that method is flawed, even though I know it's common with Crossfire flyers.

As TBS has not got back to me on how they calculate LQ and RSSI that they transmit over channel 8/12 back to the FC, I'm going with what they have provided to date. RSSI is the better of 1RSS and 2RSS at a 130dB scale. Until I get a way to calculate a better LQ or RSSI, I'm forced to go with that. Doing any type of calculate based on RLQY and RFMD yields very poor results.

If you believe you have a formula that works, I'd love to see it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/LuaTelemetry/issues/244#issuecomment-455811033, or mute the thread https://github.com/notifications/unsubscribe-auth/ABbRARQ7RwceUOa_5bORcG3vzVcVB3EPks5vE3qSgaJpZM4aJKpo .

[KnuckleUpFPV]

1rss and 2rss jump around like made in a heavy noise enviornment. We use lq instead of rssi in crossfire so it reports a solid link in rfmd2 mode. Once we hear the call out to rfmd1 we know its time to start watching rssi on osd. With the newest 2.88 firmware the turn around point is 30%. It was 70% on older firmwares. According to Remo the guy that writes the code we should use 30% now. 1rss and 2rss start out bouncing between 56 and 77 when im next to the model. While rqly is at a steady 100 and progressively drops the further I go. Until power bumps up then rqly goes back up. According to tbs lq is a linear reading once it goes into rfmd1. While in rfmd2 it reports a constant 99. You should have no fear of failsafing in rfmd2. If you do use rssi instead of lq, then the osd rssi is all over the place even in rfmd2. Rqly would be a better indication of the received signal quality. You will lose telemetry long before control. So tqly may go to 0 while rqly is staying strong. The qx7 was reporting rssi at 99 while the lua had rssi very low. I just turned off rssi warning in the lua menu and it stopped the alarm. The taranis will still warn me when signal actually gets low, and logs are still showing correct signal strength. Im fine with leaving it off. I dont know how others feel about it.

I dont know if its possible, but it would be great if the lua was able to display the rfmd mode and make its own logs.

[KnuckleUpFPV]

If the lua was able to detect and display the rfmd mode then it may be possible for it to report 99rssi until it goes into rfmd1. Then it would actually start to display the actual rssi. I dont know what this would do to memory usage or if it would even be possible. Just throwing ideas out there.

[teckel12]

@wx4cb The LQ value you're sending to channel 12 is not exposed as a telemetry sensor. That's the exact value I'm trying to get out of Crossfire, the value they're sending to the FC over channel 12.

I believe you're under the impression the sensor value is the same as what's sent to the RC, that's not the case. If that value was exposed, I'd use it, it's exactly what I'm trying to get.

[wx4cb]

Just got back from flying it for the first time with 2.1. I must say, it worked great. obviously I can't look at it when im flying fpv, but the callouts pretty much matched my taranis callouts that I have programmed in. there wasn't any RSSI haptic feedback loops, although it was fluctuating between 100 and 150 with callouts which im assuming is the RSSI. my LQ was fine and was only dropping to 96-97.

i'm flying in a high noise urban environment. I do have (or should have) taranis SD logs if that's any help to you. i'm assuming that it was saving them as i have SD logs 0.5 in the Special functions when i arm.

[teckel12]

@KnuckleUpFPV The link quality telemetry value doesn't match the RSSI value sent back to the FC.

What I need is the formula that Crossfire uses for RSSI sent to the FC over channel 8/12. Without this, I can do nothing other than use the RSSI values they provide.

[KnuckleUpFPV]

The link quality wont match until it goes into rfmd1 I dont believe. Rssi is all over the place in rfmd2. I will message remo and see if I can get the information you want.

[teckel12]

@KnuckleUpFPV Trappy's email address changed, so I can't contact him anymore.

[KnuckleUpFPV]

I messaged him and remo on Facebook messenger.

[KnuckleUpFPV]

Talked to trappy and remo. I can give you trappys email. He's thinks the lua is cool. Email me at (removed since contact was made) and I will send you trappys email. And ill pass your email onto remo

[teckel12]

@KnuckleUpFPV Emailed Remo. I had emailed him previously, but to a different email address and I didn't get a response (or maybe lost in email spam).

Really just trying to duplicate the LQ/RSSI value sent over ch 8/12 to the FC which is used for the OSD RSSI value. Starts at 99 and slowly goes lower as LQ/RSSI gets worse. I believe everyone would be in agreement that the RSSI value shown in the OSD would be a useful measurement of signal quality?

[wx4cb]

@teckel12 if we could get the same 0-100 that is used in the LQ from the transmitter etc then yes. for me, i have LQ only on ch 12. others have RSSI/LQ. not 100% what the difference is though

[KnuckleUpFPV]

Agreed Tim.

[teckel12]

@wx4cb I've tried both LQ and LQ/RSSI and I don't really see a difference either. I'm sure there is a difference, it's just hard to tell. Whatever calculation they're using for LQ/RSSI, I'd really like to use that for Lua Telemetry.

[wx4cb]

this is what i found on it. you probably already know though. the way i see it, if RFMD is 2 then don't worry too much about it. but when it goes to 2 is when it's 0-100% if that makes sense.

https://oscarliang.com/lq-rssi-tbs-crossfire/

The Crossfire LQ is scaled from 0% to 300%, not 0% to 100% like other traditional signal indicators. This is because of the increased data link in Crossfire.

Traditional remote controls can only do 50Hz, which means 50 commands per second. The Crossfire can transmit at 150Hz maximum, that’s 150 commands per second. If we assume 50 commands per second is 100% link quality, then 150 commands per second would be 300%.

[teckel12]

@wx4cb That's well-traveled ground.

The issue is that when RFMD is 2 and RQly is 100, the LQ/RSSI sent to the FC for RSSI on OSD can vary quite a bit. It may be 95dB on the OSD, but is still showing RFMD 2 and RQly of 100, again not linear at all.

So, there's something else in the calculation. If you look at the LQ/RSSI channel in the INAV configurator you can see the signal strength moving around (much more like a traditional RSSI value). So they're doing something more than just RFMD and RQly to calculate it. Maybe they combine it with RSSI? Who knows. I may be able to fudge the math and do some other calculation that may be close. But, I feel it's probably better to just use the same logic if they're willing to share it.

[wx4cb]

@teckel12 of course, just throwing out thoughts

[teckel12]

I haven't heard back from Sheng, but the following is his last email. I'm posting it because I couldn't make sense of it and maybe someone else understands what he's saying?

Have you tried the latest 2.88 firmware? Crossfire will send you the link statistics frame thorough CRSF. So you can access the full data set there and you don't need to scale anything back.

It sounds like something was added to 2.88 (which I'm running). Specifically, anyone know what he means by "link statistics frame through CRSF"? I don't see any additional telemetry sensors with 2.88 and I'm not sure what a link statistics frame is or how I would access it though a Lua script.

Anyway, posting here in case someone understands what he's talking about because I'm totally at a loss.

[wx4cb]

yes. 2.88 added a frame in the CRSF telemetry data stream that gives you what you want. but I beleive that's only to the FC though. if you remember we had this conversation on the inav github a couple months back and there's that (currently) unused frame set in the crossfire spec that inav wasn't getting.

[teckel12]

@wx4cb So it's something that could be accessed via MSP if it was both added to INAV and Lua Telemetry added MSP support (which is out of scope for the Crossfire release of Lua Telemetry). Basically, it means that can't be used with Lua Telemetry. And I also don't believe ever could be as MSP is slow. It's fine for controlling VTx or adjusting PIDs, but really not appropriate for 20 frame per second telemetry reporting.

[wx4cb]

@teckel12 i'm not sure. i can't find the release notes for 2.88 in agent (actually just updated my full module) the agent release notes only go to 2.41 as i say.

I would assume that if it comes to the FC as part of the CRSF data stream there should be a way to get it back to the transmitter via the FC is there not? that's how the other sensors would work such as pitch roll etc ?

[teckel12]

@wx4cb Yes, but it still would require an update to INAV to send it via telemetry to the transmitter as a new sensor. It could also be used to to set the RSSI on the FC without using channel 8/12 going back & forth as it is now (and wasting a channel).

However. What still remains is that at the transmitter Crossfire is currently calculating LQ/RSSI which (if the calculations are exposed) could be used for Lua scripts. Actually, what TBS should do is just set the transmitter's RSSI value to the same thing they're sending back to the FC. Lua scripts could also grab that currently, without any drastic changes. And it would also make a HUGE amount of sense! Would take 5 minutes to implement in Lua Telemetry if Crossfire set RSSI at the transmitter the same as they send back on ch 8/12.

Maybe I'll suggest TBS visit this issue....

[teckel12]

I heard back from Remo. He suggests measuring link quality and strength with the RSNR sensor using the range -4dB to 40dB (scaled to 0 to 99). Basically, (max(RSNR, 40) + 4) * 2.25. Did a little testing and it seems fairly good. I'll change the development branch and test it tonight (feel free to as well).

[wx4cb]

ok cool... send me a matek f405 wing target and i'll test wednesday - little too cold today n tomorrow in FL :D

[teckel12]

@wx4cb "too cold" for Florida maybe! It's 9 degrees here!

[KnuckleUpFPV]

Let me know when its up and I'll switch over. Its freezing and extremely windy here. Should be ok tomorrow. Unless it rains.

[wx4cb]

@teckel12 it was 39 here this morning :P

[teckel12]

I ran 10 miles yesterday when it was 6 degrees with a 25 mile/hour wind. I would have seriously worn shorts if it was 39 degrees!

[KnuckleUpFPV]

You may have a medical condition. Should seek out a therapist. 😂

[wx4cb]

@KnuckleUpFPV hahaha I go running every day at 5am for an hour. then at 6am, I get out of bed :D

[teckel12]

@wx4cb If you don't already have a version of INAV with the upgraded Crossfire telemetry, here's 2.1.0-RC2 with bonus MSP over Crossfire added:

inav_2.1.0_MATEKF405.zip inav_2.1.0_MATEKF405SE.zip inav_2.1.0_MATEKF722.zip inav_2.1.0_MATEKF722SE.zip inav_2.1.0_OMNIBUSF4PRO.zip

You'll also need the latest Lua Telemetry development build: https://github.com/iNavFlight/LuaTelemetry/wiki/Upgrade-to-Development-Build

[wx4cb]

still gettingit, ill post pics and video later

[teckel12]

@wx4cb Getting heptic feedback? Sure it's from RSSI? What values are flashing or yellow/red?

What does the RSSI value show? And what do you have set for low and critical levels for RSSI in your model settings? According to TBS, critical RSNR shouldn't be till 0dB, which would be a 9 RSSI. So probably setting critical to 9 and warning to 22 or 23 would seem about right.

[wx4cb]

yes mine are down around 10-20 for RSSI warnings.

The photos below are from when i was walking to get my model they were taken between 30-50 feet away. the RSSI was jumping all over the place. Now I do seem to have an issue where it's constantly jumping between FMD 1 and 2 and tends to favour FMD 1 for some reason. but this is a new module and new immortal T antenna. I do have a diamond which should be here today to make sure it's not an antenna issue. i get the same thing on multiple receivers with the crossfire running on 2.88. i'm fixed at 100mW and don't get any issues with control.

the call-outs you can here about flight mode is the crossfire going between 1 and 2.

The OSD however only went down to about 97 and stayed at 99 throughout the flight and pickup.

https://www.youtube.com/watch?v=1CZhWONU71k

[wx4cb]

ok just done another test. the haptic feedback is coming from RSSI for certain, but i just walked 50+ feet from the model (video uploading now) with it going crazy.

here's the CSV from the taranis that goes with the video:

https://drive.google.com/open?id=1ei6L6C5G2FhZN0bAikXr08C4LceyIssd

EDIT: no clue why it's upside down. is the right way up on my phone. I'll re upload it when i get back home - gotta go for my "run" :D

EDIT 2: found a hack in the youtube html... the rotate buttons are still there just "hidden" LOL https://www.youtube.com/watch?v=Zd80oFmxLFI

[teckel12]

@wx4cb I can't do anything about what the OSD says for RSSI as TBS refuses to release the math they use to calculate RSSI nor send it to the Tx as RSSI. They provided the formula they were willing to supply, and that's what Lua Telemetry is using.

You should look at the RSNR telemetry sensor and note what that is showing (you can put it on another screen). The math Lua Telemetry is using is simply: RSSI = (RSNR + 4) * 2.25

For me, it stays fairly constant at 99dB as I walk around my entire house. It dips down a few times, but goes right back up to 99dB. I have the receiver in the basement and I have a 3 story house so even with the transmitter the top level in a bad location (next to a brick chimney) it's basically 99dB (with occasional dips which is expected).

[teckel12]

Maybe I don't know what you're looking for?

I first referenced the TBS manual and used 130dB subtracted from the 1RSS & 2RRS values. That wasn't acceptable.

I then asked TBS and they said to scale RSNR from -4dB to 40dB to the 0 to 100 range which I'm doing now. And I guess that isn't acceptable either.

So what would you like me to do? I can't use RQly as that always show 100% even with the antenna off, and then it drops directly to zero (in other words, zero warning). I can't get the RSSI/LQ value it sends to the FC as TBS believes that's a trade secret.

RSSI jumps all over the place, that's the nature of RSSI. If you've ever used FrSky receivers and telemetry, that's exactly what happens. Due to the formula that TBS is using, and RSSI warning isn't needed till it drops below 9 (RSNR = 0 add 4 multiply by 2.25).

It really sounds like everyone just wants the RSSI to be stuck at 100% and that would solve all problems.

[teckel12]

@wx4cb Watching your second video when you show the Crossfire Tx module, it shows the uplink SNR all over the place too. Shows 11dB to 36dB. According to TBS, 11dB would be an RSSI of about 34. That would trigger a low RSSI warning if you haven't changed the RSSI warning levels. An RSNR of 36dB would be an RSSI of 90dB. Jumping from 36dB to 90dB seems to be about what the Lua Telemetry display was showing. Which matches what the Crossfire Tx module was showing as well.

Maybe it just doesn't seem as much "jumping all over the place" when numbers go from 11dB to 34dB but it does when values go from 36db to 90dB even though they're exactly the same? Maybe the updates are faster on Lua Telemetry? I'm not sure.

Basically, I don't know what you're looking for, what you want, or what the videos are supposed to show. They actually seem just about correct to me. Maybe your RSSI low and critical alarms should be lowered to 22dB and 9dB? Maybe there's some dips in RSNR as Crossfire switches signal strength? I'm not sure. But, I can only display what Crossfire is giving me. If there's some double-secret formula that could be used for RSSI, I'm not aware of it.

[wx4cb]

the RSNR dipping as it changes FMD is entirely possible. on the taranis, i double checked on the MD and i hadn't lowered them down, but i could only get the warning/crit down to 15/12 respectively on the telemetry page (IIRC) so i'll check that again when i fly next.

I did notice that you did some commits today so when i get chance tomorrow i'll re-update the SD card.

don't take my comments as a criticism, that was far from it. I just wanted to see if a second pair of eyes could see something i'm missing, which in fact you did and i thank you for that. i'm still going to try a different antenna now that I have the diamond here and hopefully the constant fmd changes with reduce/go bye-bye as i still think i have an antenna issue.

I was just trying to give you as much information as possible in different environments. If everything looks good to you i'm happy with that. Like i say, it was more a double check than anything else.

[teckel12]

@wx4cb The changes from today change to using just RQly and labeling it LQ as a % instead of RSSI in dB. It seems there's not really a good RSSI value for Crossfire, so LQ will have to do unless something else is identified.

To set the warnings for LQ, do it from the model's telemetry page (the low and critical alarm values). Probably setting them to 70 and 60 would be a good start.

If LQ bounces around too much or you get a warning when switching power levels, again from the model's telemetry page change the RQly sensor and enable filter to do some averaging on it to even it out. Crossfire is already doing some filtering on the LQ as there's about a 1 second delay between an actual RSSI dip and the LQ value changing. Checking the filter switch for the sensor will delay a warning probably a second or two more. But, if you like seeing a strong signal and you don't like to be notified when the signal drops for a second, this is the avenue to take before you totally turn off warnings.

Let me know how this works for everyone.

[wx4cb]

ok cool. yes ill let you know. probably be out tomorrow.

[teckel12]

@wx4cb I added setting of your battery's capacity when using Crossfire from the config menu of Lua Telemetry. This will allow a battery capacity % gauge and alerts at warning and alert levels. I find this much more informative than cell voltage, which tends to dip. But, you can also select to view the traditional mAh used instead if you wish.