Yep, that is what I was referring to. Your settings are exactly the same as what are on my Nano RX. I guess it's still not working on the newer 3.23 firmware? Mine isn't installed on a quad at the moment (going in this weekend hopefully) so I'll let you know if I get the same LQ / RSSI problem (or not) once it's all soldered in.

Yeah, that smart audio version is a problem.  Before, when I had the green audio wire to tx3, I ran that same log and there was no response, so I knew it wasn't working for sure.  When I switched those pins today, and glanced at it, I noticed it was returning a signal, so assumed that all was well.  Indeed though, looking at the link you provided closer, the actual smart audio version should be 200 or 216, but it's showing 222??

Interestingly this guy is having a very similar problem after going to v 4.1 bf...lots of similar issues there...I'm reading through it

https://github.com/betaflight/betaflight/issues/9057

Another 8hrs into this issue today....my gf is gonna lose it...lol. I am putting so much work aside trying to get this deal done...lol. Going to eat dinner and then get back at it in 2hrs or so. Somethings def up...this blows...lol.

Having 222 as the value means you are on SmartAudio 2.0. The trailng number "22" holds the bit flags (0110) that are to do with pit mode settings. Seeing this suddenly triggered a thought about low power mode during disarm which looking at the BF dump you posted, you have switched ON. Try turning that OFF by running the following CLI commands and then see if you are able to change the power level via SmartAudio in your OSD...


Also, make sure you switch the Blackbox debug value back to "NONE" after you are done with debugging the SmartAudio version so debug mode doesn't interfere with normal operation of the FC.

(30-Jan-2020, 03:42 AM)SnowLeopardFPV Wrote: Having 222 as the value means you are on SmartAudio 2.0. The trailng number "22" holds the bit flags (0110) that are to do with pit mode settings. Seeing this suddenly triggered a thought about low power mode during disarm which looking at the BF dump you posted, you have switched ON. Try turning that OFF by running the following CLI commands and then see if you are able to change the power level via SmartAudio in your OSD...

Code:

set vtx_low_power_disarm = OFF
save

Also, make sure you switch the Blackbox debug value back to "NONE" after you are done with debugging the SmartAudio version so debug mode doesn't interfere with normal operation of the FC.

I'm glad you mentioned that part...lol. I had it left on since....like....a day or two ago.

Ok, let me get at this and see what happens here.  I do recall with the HV version of the unify, it mentions this function of going into low power mode when changing channels and while disarmed I think, to avoid overheating.  All this sh*t is so confusing because it seems like its hard to monitor.  If the goggles updated the data in real time, which I assume they do when working properly, sure would be handy.

Ok, update here. In the Betaflight tab, in the video transmitter tab, you mentioning the low power during disarm, I recalled a tab. In the video transmitter tab I had "Low Power Disarm" activated. So, it was allowing my channel and band changes, but not my power changes, as the quad was disarmed. So, unchecking this worked, and now I have ability to change all the vtx settings, SO....that's done.

Thanks a LOT bro...pointed me in the right direction and figured that one out.

NOW...the rssi issue is all that remains and I'll be comfy.

So, strange scenario here and I can't quite figure it out.

Suddenly, the LQ in the OSD is working and at 299-300 with me sitting next to it. Somehow, fixing changing the video transmit tab settings, and repeatedly rebooting the OSD to make everything sync, has somehow brought the lq alive.

It seems like changes in betaflight and saves, somehow were reflecting in the osd because I wasn't save/rebooting enough possibly? Just the process of changing that video tx setting, then rebooting in the osd, started making things come together.

I still have no rssi % in configuration tab, but my osd lq is bouncing between 299 and 300 sitting next to me, does that sound right?

Great news on the VTX power level. With low power disarm either set to "On" or "On until first arm", changing the power level through the CMS still works but you will see the "live" power setting immediately switch back to the lowest power value again. However, the power setting you selected does still gets persisted in the Betaflight configuration and when you arm it will then use the power level you actually selected in the CMS, even though the live setting in your goggles is showing the lowest power setting (because you're disarmed). I guess it would be nice if the CMS displayed two power values - the current live value and the actual power value (the one you set) that will be used when the quad is armed. I guess we're asking for a moon on a stick  

I have my Low Power Disarm set to "On until first arm" because after plugging in a LiPo I don't want my VTX to start overheating before the first arming of my quad, however I want the power level to remain high if I have to disarm during flight (i.e. in an emergency) because I want the ability to be able to use my goggle module as model direction finder. If the power was to drop to the lowest setting again on a disarm then that would defeat my ability to do that. One thing to be aware of if you decide to use the Low Power Disarm feature is that it takes about 5-10 seconds after arming for the power to switch over, and during that switch-over you lose video for about 1 second. If you've forgotten about that and have taken off immediately after arming, can sometimes cause a bit of an "underpants need changing" moment, especially if you're in the middle of a power loop when that happens  I try and remember to wait on the ground after arming until I see the power switch-over occur in my goggles before actually taking off, but sometimes in the heat of the excitement I forget

I bet it was the SMARTAUDIO debug mode still left enabled that prevented the LQ value from showing up. One way to find out for sure would be to temporarily switch that back on and see if the LQ value disappears again.

A value of 300 is perfect. When LQ shows between 300 and 200 it is running in 150Hz ultra low latency mode, when it's between 200 and 100 it's running in 50Hz mode, and when it's below 100 it's running in 4Hz mode. The further away you fly will depend on which of those modes Crossfire decides to use. 70 is the magic number. If you let it go below that, there is a high chance of you getting a failsafe.

As for RSSI, I will try and figure that out but in all honesty you don't really need it when running Crossfire because LQ is all that really matters. If you do get RSSI working you will see it going down to some scary looking numbers that might freak you out, but which don't really matter because the Link Quality is still high. So it maybe best to just remove that unnecessary worry by simply not displaying RSSI in the first place.

Yeah, from what I've read LQ seems to be preferred.

GLAD you told me about that switch that happens after you arm...that would've been scary as hell. Seems best practice is to arm and idle until the switch and get into that habit. Is it best to immediately turn back the MOMENT you get any video scratchiness? It seems a small glitch will go to massive loss very quick, but then again I was clearly on 25mw before. Just trying to understand safest and best practices to avoid loss/crash.

Next I want to get the gps return to home on a switch, and set as a failsafe, in the event I suddenly lose video moving away or turning back. I'm going to wire that in today, now that everything seems to be in order.

On everything lining up between the goggles and betaflight, it seemed it had mostly to do with rebooting. Certain changes in the OSD screen via betaflight i'd see reflected immediately in the goggles, so I never rebooted at times. I don't know...I really haven't narrowed it down. I disabled smartaudio in blackbox last, after everything was done, so that's not the culprit. Everything happened right after I disabled that low power disarm, then hit save/reboot in the goggles a few times, because I'd set the default power in betaflight, and it wouldn't change in the goggles, so I kept rebooting and realized that would get it to agree. During that process, I saw LQ go from its usual flashing 0 to 299-300. I really don't know though...I wish I knew exactly but...if I ever feel like something isn't working I'll be sure to reboot everything and check...idk man. It all happened quick and I definitely disabled the smartaudio setting in blackbox afterwards. You pointing me to the pit mode after the 222, just started it all in motion, as I unchecked low power disarm, rebooted, kept messing with the vtx defaults and rebooting, etc. It just all started working.

This quad flew REALLY nice from first start up and crashing it into rocks isn't something I wanted to happen unnecessarily. After doing simulator for about 10hrs, I then started out with a 3" R349 Diatone on 4s which was FAST and twitchy as hell, but I got the hang of it doing basic loops and rolls and maneuvers, plus crashing that thing was so light it actually took a HELL of a beating...this 5" feels buttery smooth and soft by comparison which made it easy to fly but still had a lot of bite if I throttled it. My goals are cinematic though...flowing lines, hitting gaps smoothly, and only using split s and inversions to dive and chase a car, etc....mostly for my channel KnightDriveTV, but I do want to get into close drift and motorsports chase. Just need to work out these issues and get some system confidence.

OK, so I just finished installing a Crossfire Nano RX on my 5" to replace the original FrSky R-XSR and I have all three Link Quality, RSSI, and RSSI dBm values working and displaying valid values in my OSD. I simply just disabled the RSSI channel that was originally configured for my R-XSR and then enabled the Link Quality, RSSI, and RSSI dBm items in my OSD. I already had RSS_ADC disabled from the original RSSI setup for my R-XSR. I didn't need to do anything else.

If you still care about RSSI, is yours now working?

As I previously mentioned though, with the quad just a few metres from my transmitter the RSSI values are reading quite low at between 60% and 70%. Compared to what I'm used to seeing with my R-XSR at the same sort of separation distance, with that receiver I usually see an RSSI value in the high 90's. The all important Crossfire LQ value however is flickering around between 299 and 300 so I know the Crossfire link is good.

People have been complaining about the low Crossfire RSSI values in JB's recent live streams, and apparently something recently changed in the Crossfire firmware which is seemingly causing those values to be lower than they used to be. In JBs video you can see his Crossfire RSSI value flickering around the 80% mark, which is still quite low compared to an R-XSR, but not as low as I'm seeing in mine. His video was shot back in October though and it is since then that subsequent Crossfire firmware updates have lowered the RSSI values now being seen.

I will leave the RSSI and RSSI dBm values on my OSD for now but I will likely just end up switching those off and just rely on the Link Quality value.

I've spent the last few days doing test flights, etc. I've worked out all the VTX woes, for the mostpart. I found more documentation on the 5g8 HV...it's got some quirks that it absolutely mentions nothing about in the directions. Additional documentation from TBS on gethub revealed all kinds of things. The fact that there are system defaults on the vtx that aren't visible in BF at all, but must be altered in the config menu, otherwise its in a "race" mode. Therefore, I wasn't seeing the defaults I was setting in BF (no pit mode enabled, no low power disarm, 500, etc)...power up the quad it'd be putting out MEGA low power to where I could barely see in the goggles, standing next to it. Basically, it was all linked to selecting Race or Free in the config menu, then my defaults in BF were working and agreeing. In Race mode, the HV powers up very low...like .01 mw low, to not interfere with other racers. Now I am in Free, and everything is in order.

Been having some GREAT flights now...500mw is pretty nice and I can finally see and fly a distance with confidence. I have been working on a soft mount for GoPro5 to use in RealSteadGo and that's been working great as well. I'm currently shooting an Overland/Off Road short film/feature and incorporating some FPV and former Mavic Pro footage is going to be great.

On the RSSI issue...I've never even reattempted to see if it works or not. In BF, I still see 0%, on that setup or configuration tab (can't recall which it is). Regardless though, I have LQ values which seem to be doing well for me, plus I have the audible warnings through the Tarranis which I have yet to hear, at the distances I've been testing. I've been flying at some slower paces just to look for breakup in vid and monitor the LQ...getting a feel. The desert gives great line of sight, so shy of diving down in ravines or through Joshua trees, it's pretty solid.

My last task is to just get to it on the GPS, because a recovery out in the desert will be tough...the amount of ground clutter, small brush, etc makes it REAL hard to see anything. Hiking to where it may land would be easy, but knowing where to go, not so much. The GPS return features sure look interesting....have to input a bunch of values, angles, etc. As long as I get a location of the crash site that's all I'm really worried about, but an auto return to signal/video would be nice for sure.

Going well overall though...successful flights, no crashes and some good GoPro vids feels good finally.