Inav: Support FuriousFPV Stealth 2.4G VTX protocol

[digitalentity]

Protocol is similar to Tramp, but supports variable length frames. Support requested by FuriousFPV.

[digitalentity]

Specs: Furious-24G-REV02.pdf

[putimir]

Hello, does anybody know if there is any work done on this and it's possible to test? The VTX's are out and it's hard to go from SmartAudio to pressing buttons ;)
Thanks

[digitalentity]

Yes, there is an ongoing effort to implement this.

[putimir]

Hi! Great to hear that. I volunteer for testing; is it already available for testing? I think I don't see anything in the dev branch, can you enlighten me :) thanks!

[whoami1975]

Hi! Great to hear that. I volunteer for testing; is it already available for testing? I think I don't see anything in the dev branch, can you enlighten me :) thanks!

would like to test it out too ... ;-)

[KnuckleUpFPV]

Eagerly waiting to test this code.

[markandkymward]

same here

[FPVZaphod]

Also got my 2.4 TX - cannot wait for implementation!

[mikekenyon99]

Has this progressed at all? It would be great to have it working. :-)

[digitalentity]

It's in progress. I plan get it ready for testing next week.

[KnuckleUpFPV]

This is closed, but is it ready for testing? Or is it being nipped in the bud.

[shellixyz]

@KnuckleUpFPV FW support has been merged for 2.1, see #4147

[KnuckleUpFPV]

Thank you Shellixyz

[putimir]

Just to report, since nobody did: I tested this on the RC2, using function number 131072 on the UART, and can confirm proper function:

• operations via OSD menu
• proper channel/band settings on boot (using vtx_* CLI commands)
• proper setting of the power level on arm/disarm (using vtx_low_power_disarm)
• proper band:channel:power display in OSD

Thank you devs!

[putimir]

Hm, I guess I was too quick :(

It works "randomly" - between reboots: sometimes yes, and sometimes not. Anyone experiencing this?

I'm using MATEKF405SE board/target, vtx related settings:

serial 4 131072 115200 115200 0 115200

set vtx_halfduplex = ON
set vtx_band = 1
set vtx_channel = 8
set vtx_power = 4
set vtx_low_power_disarm = ON
set vtx_freq = 5725

[KnuckleUpFPV]

@putimir I dont even see the option to enable it in 2.1 rc2. Im sure thats from the configurator issues though. Its messed up my font and made it huge transparent letters. After a few font flashes I got it back to normal. Then walked to the field to fly and it had completely forgot its modes. It wouldnt stabilize the elevons. Brought it back and reflashed it with old configurator and its fine now. Still no furious protocol setup showing.

[putimir]

@KnuckleUpFPV: the configurator is not yet ready for the new protocol, however you can enable the feature by entering

serial {uart-id} 131072 115200 115200 0 115200

You should be getting another menu in the OSD, under features, "FFPV something" in addition to SA VTX and Tramp VTX...

[expipiplus1]

I've been able to get this to work a couple of times, but like @putimir I am finding it unpredictable.

I am using a Matek F411-wing with the vtx connected to a softserial port: st1

The relevant parts of my configuration:

serial 30 131072 115200 115200 0 115200
set vtx_halfduplex = ON
set vtx_band = 1
set vtx_channel = 1
set vtx_power = 2
set vtx_low_power_disarm = ON

I have managed to change the frequency a couple of times on startup, however I have been unsuccessful in changing it from the OSD menu.

In the OSD menu the current settings appear as dashes, I have made sure to update the font on my board.

[expipiplus1]

I've done a little debugging:

On power up the capability request is sent and an answer is received, after that vtxState.protoTimeouts increases at a rate of 1 per second until it hits 3, and the process loops and get stuck waiting for the capability request to be returned forever.

[putimir]

Yea, it looks to me like a startup/initialization error (dashes are there if the protocol is not running / no data received, i think), because, If the system boots up successfully, showing the correct values in OSD, all functionality is ok, but if not, none of them work for that "session"...

[digitalentity]

@expipiplus1 do you have the logic probe to observe the traffic between VTX and FC?

It seems to me that VTX just stops responding after the first capability request. In this case it will behave exactly as you observe - it will timeout on liveness checks until vtxState.protoTimeouts reaches 3. Then the protocol thread will reset and retry asking for capabilities until VTX replies.

[expipiplus1]

After the first one or two packets, no more bytes are received on the serial connection. This may require an oscilloscope to debug further.

[digitalentity]

@expipiplus1 I'd say that's a VTX firmware issue - INAV will keep sending requests periodically. Oscilloscope or logic probe should help confirming.

[expipiplus1]

@digitalentity I'm inclined to agree, especially since this has failed to work with softserial and the dedicated uart on more than one board.

I'm afraid I don't have a logic probe handy.

I will email Bas at FFPV to see if he has any input.

[digitalentity]

I have a VTX on my bench and I didn't noticed this issue - it might be one-off issue, or yours may have a different VTX firmware than mine (which would explain different behavior). Will test further.

[expipiplus1]

@digitalentity given that this protocol is so similar to tramp, might it just make sense to abstract the tramp driver over channel and power level names?

(of course this wouldn't fix the current issue I'm facing, but it might help keep the inav codebase more compact)

[limayankee]

I've been able to get this to work a couple of times, but like @putimir I am finding it unpredictable.

I am using a Matek F411-wing with the vtx connected to a softserial port: st1

The relevant parts of my configuration:

serial 30 131072 115200 115200 0 115200
set vtx_halfduplex = ON
set vtx_band = 1
set vtx_channel = 1
set vtx_power = 2
set vtx_low_power_disarm = ON

I have managed to change the frequency a couple of times on startup, however I have been unsuccessful in changing it from the OSD menu.

In the OSD menu the current settings appear as dashes, I have made sure to update the font on my board.

@expipiplus1 I have exactly the same problem as yours with a F411-CTR on a dedicated UART.

[expipiplus1]

I can confirm that this also happens with the Matek 722-Wing board.

I have been in email contact with FuriousFPV. I described the issue to them and eventually had my message forwarded to their R&D team on Feb 22nd. I have sent two reminder emails but have not heard back from them since.

One hacky fix I can think of (for the 722 board) would be to supply the vtx with power from the switchable output. In order to change settings on the VTX one could power cycle it before apply the settings; needless to say, this is a nasty solution.

[putimir]

Furious support sucks big time in my experience :( This 2.4 system of theirs is my first and my last one ;)

I have bought it almost a year ago, with the dock king, and only recently they released a FW that does the signal switching correctly, but I still have problem with the BT on the dock - not related to the issue, but part of the big picture, of how they do it there ;)

(Not to mention, that inav and bf remote control was advertised big time even in pre-release time. After I got the thing, I realize they have not even begin to implement it, I started bitchin, after that they removed the text from the product page - we are here now, the thing still not working)

[expipiplus1]

Drifting off topic a little, but what other 2.4ghz transmitter can you
recommend, @putimir?

I've got plans to make my own vtx and rx (with telemetry in the blanking
period to be rendered on the ground) but who known when I'll get round to
doing that...

On Fri, 8 Mar 2019, 15:05 putimir, [e-mail] wrote:

Furious support sucks big time in my experience :( This 2.4 system of
theirs is my first and my last one ;)

I have bought it almost a year ago, with the dock king, and only recently
they released a FW that does the signal switching correctly, but I still
have problem with the BT on the dock - not related to the issue, but part
of the big picture, of how they do it there ;)

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

[putimir]

Yeah, sorry for the offtopic, but, also as said, it is somewhat related - I can't recommend VTX's, as this was my first 2.4 ;) I would say, that the VTX alone is ok (also price/performance), except the fact that it does not support audio, but if I relate to the remote functionality, the VTX was sold with false description, and after that almost no support was given.

I'm waiting on AKK to release their 2.4, which according to the representative, it is in development as we speak. (but ok, enough talk on this matter in this thread)

[KnuckleUpFPV]

Description wasn't false. They said with the next release of inav and betaflight. Which neither of them are on official release. If you are getting interference from your dock kings bluetooth, they have a guide to disable it. Or you can add a switch like the rest of us so we can turn bluetooth on and off. The dock king was made to work with 5.8 modules without osd. It was just a bonus that it worked with the 2.4 modules. You need to turn the osd off on either the dock king or the bluetooth module itself when using them together. Bluetooth is in the 2.4ghz band. This is why it causes video issues. The system works amazingly well. Even in the city where I fly. If you take the steps to stop interference from the bluetooth and the overlapping osd information.

[expipiplus1]

@KnuckleUpFPV, inav has had several releases since this vtx was released, at least 2.0.0, 2.0.1 and 2.1.0. TBH I think it's sleazy to advertise the vtx as having (future) support in these projects without at least having a working PR open.

@putimir good to hear another 2.4GHz vtx is in development!

[KnuckleUpFPV]

The vtx was released during 2.0.0
2.0.1 was a patch to fix an issue with a return to home bug.
2.1.0 is supposed to be the release to have the support.
Furious made the protocol. They are waiting on inav and betaflight to implement it. Its out of furious hands. They cannot force a merge to the main repo. They are not in control of either fork.

[giacomo892]

They can for instance provide a resonable protocol and the working implementation. We will gladly merge then!

[putimir]

Exactly. Like they do it in Matek, or Airbot.

[KnuckleUpFPV]

Is the protocol not identical to the tramp protocol, but with 2.4ghz tables?

[expipiplus1]

Got a response from FFPV:

​We have next week the firmware ready for the VTX.
Then we launch it, and the vtx can then be updated by bluetooth.
​
More info follow soon!

[jasin755]

Does 2.4Ghz Stealth support this module: https://furiousfpv.com/product_info.php?products_id=637 ?

[jasin755]

Response from FFPV to my question:

Hello Nikolai,

We are working on something to get the bluetooth working on the 2,4ghz vtx to update the firmware.

I think we have news next week when the firmware is ready to us audio control by Inav and BF

[vicdzen]

I have flashed new FW from FFPV dated 05 Apr 2019 using SWD programmer, works fine using button but a bit unstable using OSD menu setup. Sometimes VTX needs to be power-cycled to have readings of chan and band on OSD menu page. Also some minor issues with indication which I have listed in new ticket.

[expipiplus1]

@vicdzen cool. I'm curious to learn more about how you did this. Did you jumper the programmer straight to the arm pins? Where did you get this new firmware (I couldn't find it after a quick look)?

It sounds as though this firmware isn't much better than the last one if it still requires power cycling the board...

[vicdzen]

@expipiplus1 Yes, there are two test points right near the mcu. I have used stm32 discovery board as programmer. FW located at the downloads page if FFPV site

[vicdzen]

Also I’m not completely sure about power cycling. But after applying new settings, VTX continues to blink previous values of band chan and pow. Maybe it is using new ones but indicates old because they were not set by push button

[vicdzen]

Guess what? I've just mail from FFPV support and they told me that new FW is buggy and was placed in download section by mistake. So, now it seems, that I'm only one with buggy FW ))))) and no chances to rollback to previous. VTX comes read-protected from factory.
By the way, connection diagram is here

[jasin755]

FuriousFPV posted tutorial how to upgrade firmware to 2.0 for VTX. Have somebody tried 2.0 version?

[putimir]

I wouldn't do it, according to my previous experience and the posts above. FFPV is deeper in s...t each step they do.

[sniperxnl]

I have uploaded the firmware and it works great when using cli commands
Now Inav should make the OSD part ready for it

[vicdzen]

Same here, waiting for OSD menu fix (I've made ticket already) Where did you get binaries? the links are disappeared from off site? ))))

[putimir]

What do you mean? OSD menu for FFPVVTX is already there?!?

There is no configurator support....

https://github.com/iNavFlight/inav/pull/4147

[vicdzen]

Yes, it is there. You have to config your port like serial 131072 115200 115200 0 115200 to use FFPV protocol. And than use FFPV VTX menu in OSD menu
But it is a little bit buggy yet

[sniperxnl]

Weird i dont see the OSD menu for the FFPV control in my osd
I run the latest inav version

[sniperxnl]

aah i see it now
Band A and B ar working only it still say FFPV not band A and Band B

[vicdzen]

That’s right. There are only A and B. I think those letters are far to the right, outside screen region, mention that un ticket. Also page name I have is “- TRAMP -”

[sniperxnl]

https://www.youtube.com/watch?v=QolWHl5bycY

Op wo 10 apr. 2019 11:54 schreef Victor Dzenzel [e-mail]:

That’s right. There are only A and B. I think those letters are far to the
right, outside screen region, mention that un ticket. Also page name I have
is “- TRAMP -”

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/iNavFlight/inav/issues/3285#issuecomment-481623903,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APkMGbSHqYOq4mQpdB9bKR6W-Cdvwl_aks5vfbTYgaJpZM4UPLRR
.

[putimir]

FFPV says that "set vtx_low_power_disarm" has to be off!! So the almost sole feature I really need with "smartaudio" is not working here?

[expipiplus1]

FFPV says that "set vtx_low_power_disarm" has to be off!! So the almost sole feature I really need with "smartaudio" is not working here?

That's really odd, is the implication that changing the power output still isn't reliable?

It's probably something worth asking FFPV about.

[expipiplus1]

Got an email from FFPV saying that 800mW doesn't work at the moment due to an inav bug, I've asked them to elaborate on this thread.

[expipiplus1]

@vicdzen It seems as though the file you posted on RCGroups has been reuploaded to the ffpv website. Perhaps it's not buggy after all...

[KnuckleUpFPV]

It was on the site the same day he said it was taken down. I downloaded it and flashed my vtx with it.

[expipiplus1]

I patched the April 2019 firmware to fix an issue I was having where the VTX often wouldn't speak to the FC when they were powered up together. It's here: https://github.com/expipiplus1/ffpv-fix

I've not finished testing it, so be warned!