IRC Tramp VTx support in ArduPilot

I can see that CRSF and SmartAudio support is included now in AP, but don’t see anything relating to IRC Tramp support (which is used to control Matek VTXs over a uart). I originally raised a feature request in Github for this ( and it was closed recently with @andyp1per suggesting that it had been implemented now. If this is implemented, can anyone please advise how to set it up as its not covered in the documentation?
Cheers, Paul

Sorry, no - I thought that issue was requesting tramp or smart audio - SA is done, tramp is not

No worries, I’ll swap out the VTx for a SA one. Slightly different question - is there a way using FrSky s.port, with maybe yaapu solution to control the VTx parameters in AP using an available LUA script?

I’m going to reply to my own question here to serve as potential future help for others who find this post looking for a similar solution.
Yaapu (Alex) has developed a very cool (and very understated) lua script called FrSkyLuaGCS which is a Tools script for OpenTx 2.2.4 (or newer), customisable to allow adjustment of any AP parameters. So if you are using FrSky Tx/Rx with passthrough protocol configured on your Rx smartport connection (SERIALn_PROTOCOL=10 in AP), then using the Yaapu scripts you can create a custom script page specific to VTx parameter configuration. This is the custom page I wrote for my AKK X2 VTx named plane_params_4.lua:

local description = "Plane VTX"

local parameters = {
  {"VTX_BAND",{"Band A","Band B","Band E","Band F","RaceBand",},{0,1,2,3,4,}},
return { list = parameters,description = description}

Saying all this, I am having considerable issues getting the AKK-X2 VTx to respond to the smartaudio commands sent by Ardupilot 4.1.0 (Plane in my case). The VTx occasionally works perfectly in response to the VTX_… parameter changes, but this is very occasional. In the most cases where I was testing power changes, the VTx would just not respond. In one test session it responded a bit too well - The VTx was set to the 500mW setting by Ardupilot VTX_POWER=500, and I could not get it to change to any other value using either the OSD settings screen (which is still a bit buggy I have found generally), or with the button on the VTx itself. It was locked to that power setting, and no matter what I changed the VTX_POWER parameter to, it would not budge. The OSD settings screen would display VTX+POWER=500 and if I changed away from this figure, it would immediately jump back to 500.

I still think the smartaudio code needs some work. I’d really like to hear from someone who has it working perfectly with their VTx.

I’m afraid that actually the answer here is that all on the non-TBS smart audio implementations need some work. I have found that these can be very poor and I only test on TBS gear - so the flakiness you are seeing is likely down to a poor SA implementation on the VTX side. Yes, it probably works in betaflight, but that’s part of the problem - vendors only test against betaflight and their bitbang implementation is very forgiving of protocol errors. That said there are some SA improvements I am planning but I doubt these will help the particular issue you are seeing.

Andy, which TBS VTx would you recommend? I’m looking for something which can go to 800mw if poss. Cheers

The Unify Pro32 HV is a great VTX and goes to 1000mw

1 Like

I agree, that looks really nice and some great reviews. Unfortunately unavailable at the moment from all UK suppliers, and a few in Europe I checked.
I did some more testing tonight with my AKK-X2 (non ultimate version). I get better results (at least I think I do - could be placebo) when I set VTX_OPTIONS (BIT 4). But I still see anomalies getting unreliable response from the AKK board when I change vtx_power value. Its as if the VTx board stops listening for smart audio commands on occasion, and if you changed a value in this down time then it doesn’t pick up on it. You can change the value to something else a minute later and it works again. I haven’t found a specific pattern to it sadly. Problem I have is that the VTx will be buried in the foam with only heatsync protruding, so no easy access to the led display or button.

SA specifies 2 stop bits - the behaviour you describe is the same behaviour I saw when using a VTX that did not use 2 stop bits.

Gosh yes I see that! Maybe next stop TBS in HK

This one looks pretty good: TBS Unify Pro Race 2 VTX HV 5.8GHz (MMCX) | HobbyRC UK