Is there a way to get SmartAudio working?

Would love to see this as well. My main reason is as VTX get more powerful it’s nice to have them power up in pit mode and then go full power on arm.

1 Like

I am also ready to donate $ 20! Please place the developer’s wallet, and we will start transferring money for motivation.

1 Like

Hello @sergbokh
Do you have SmartAudio protocol code extracted for Arduino.
Or a library for that.
I plan to connect simple arduino Nano to arducopter via passthrough PWM and control the vtx with the Nano borad.
(Or the new Arducpter 4.0 onboard scripting)

If you want just to control VTX power basing on incoming PWM - you don’t really need a SmartAudio library for that. Just open serial port at 9600 and send a corresponding set_power command - this is just a few bytes.

Also I saw a PR that allows ArduPilot scripting to access serial ports. So you event don’t need a arduino board. You can handle PWM channel within your script and send set_power SmartAudio command to a serial port.

I would most certainly chuck at least $20 into the pot if it will help towards getting smartaudio implemented - even if it’s only able to control power levels, i think that is the most important feature of smartaudio. Such a shame it’s not implemented seeing that so many vtx units support it now.

I am trying to use realterm and or serial port monitor to send commands to my eachine vtx 1200 this uses the tramp protocol. What I want to do is just send power commands to the vtx. I am using the software mentioned and a ftdi board with the tx wire to the smart port. I have the software set up as 4800 baud, parity none, data bits 8 and stop bits 2. I can’t find any real information on the protocol. I have looked at your work and tried to send some hex but no luck. can you lead me in the right direction on this project.

Could you be more specific the commands needed to send to the vtx. I am using eachine 1200 I sure it uses the tramp protocol. Is it as easy as sending text set_power = ??? Or do I need to send it in Hex? I really can’t find information about these protocols.

I don’t know much about Tramp protocol, but here is the SmartAudio set-power payload example, that should work with SmartAudio v2 and v2.1 devices.
Also here is the specs http://www.team-blacksheep.com/tbs_smartaudio_rev09.pdf

Set power payload: 0x00 [pull line low], 0xAA 0x55 [header], 0x05, 0x01 [set power command], 0x00 [power level (0-3 usually)], 0xXX [CRC of all bytes including header], 0x00 [some devices have a bug and requires this low byte as ending, but other devices doesn’t]

CRC alg in “CRC-8/DVB-S2” with polynom 0xD5. You can find some online calculators. Also TBS spec has a C method example.

You should use HEX

hi Sergey,

could you pls remind me - your implementation was able to control recording and photo/video switches on RunCam devices, right? were you able to associate this activity of your smartaudio implementation with the RELAY_PINx configs in ardupilot, so it could be possible to actually map camera control for RunCam from Taranis channels?

PS. i just read comments in the PR - so, is this whole effort pretty much dead now? damn, i just got back to it all with a hope to put a spare RunCam on the plane i intend to build. too bad, too bad indeed.

I did two implementations - the first one is my internal thing, that I’m actively using on my builds. It does support RunCam (start/stop recording only) and SA, in fact there are two drivers in a single class. That’s because I wanted to use a single UART for both devices (had no much free ports on my PixRacer). And this is working. Driver just need to change UART speed accordingly when talking to different devices. Yes, RunCam recording is bind to a RC switch by a custom RC-switch action definition.

Also I did another try to do “public” implementation of SA driver, but unfortunately I’m haven’t enough time to complete it. There was no RunCam support.

Add me to the money pot, got $30 waiting for whoever implements SA.

I’ve started to implements the smartaudio spec where sergey left. After a refactoring to include the spec implemented in betaflight. I have a question about the vtx tables. Betaflight includes this tables after 4.1 version, and i’m planning to configure this tables, based in the same json formats as betaflight does. Are there any json parser wich can be used out of the box into the ardupilot proyect?. Thanks in advance

Not sure you want to do it that way. Do you have a branch?

I’m working into a branch on a forked repo ( un GitHub space ) . I’ll try to explain this. Vtx in a more generic fashion are using an array to express working frequencies grouped into bands. Other functionality is about the trasmisión power applied to the signal expressed in other structure. Into the smartaudio spec there are at least there versións which operates in a diferentes manner at terms of the vtx power output. Betaflight are using this json structures to configure each vtx model. The plan is use the jsons and use the model name to config the vtx into the AP, reads then json descriptor and load the correct table into memory , then spec frecuency and power to finish the vtx setup. The final steps is integrate the vtx controls into the osd.
Hope it helps.
Codebase is into https://github.com/wapophis/ardupilot smartaudio2 branch
Jsons could be found at https://github.com/Jackjan4/betaflight-vtx-tables

Can you turn the branch into a draft PR it’s easier to review that way?
In AP we have no way of reading config from files - it all needs to go via parameters, unless you want to do this via a lua script - which won’t work on 1mb boards.
I have done this for CRSF in this PR: https://github.com/ArduPilot/ardupilot/pull/14257
That PR has the TBS table, which I don’t think is far off what you are looking for.
I recommend you don’t get to hung up on the configuration but focus on getting the protocol right. With an 80% fit and the right protocol it will be easier to get something merged.

EDIT: CRSF support is now merged

4 Likes

Thanks for the recomendations, i’ll follow the PR draft process and your recomendation to be close the spec, and then resolve the config. I’ve seen interesting things in the PR about CSRF which i will follow. I have some question about the testing process and the SITL device simulation, in first place do you know any place where there are best practices to make this device simulator?.

@peterbarker is your friend if you want to write tests :slight_smile:

I dont think there is anything useful in the docs for this situation - its all in the code. The CRSF code has an inbound test which you can see, but not an outbound test - which is what you want. I was planning to write one of these for CRSF but not got around to it.

There is a very alpha version with almost all the features implemented. Any suggestion or “Must” on how to test into real hardware, to prevent blue smoke, bricking,etc …
Thanks in advance.

Is there a PR? 12345

Not yet, implementation need hardware testing before, then, i must read the docs about the pr process.