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.
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.
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
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.
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
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.
Here is the PR. I have seen some VTX concepts in your last impl of the CRSF telemetry that i want to integrate. But first lets cleaning the house. I came from Java World.
There is a functional version in dev (4.0 version or above) for sma in ardupilot, it’s a very basic protocol impl which permit to setup vtx parameters at GCS level and sincro the hardware vtx options with this data. Is already a wip but it’s tested against smartaudio 2.0 impl.
The setup method is to config vtx_ namespace parameters like vtx_band, vtx_channel, vtx_power, etc…
and in reboot the hardware vtx take this values. Serial port must be defined with protocol 35 and the uart tx on the fc connected to the sma pin in the vtx. Actual comm is a “hardcoded” half-duplex uart.
Wiring: Connect the tx of one spare uart of your fc to the sma pin in the vtx. Also connect the gnd from uart to the gnd of the vtx, be carefull to not mistake with the - pole from power.
Setup the uart port protocol to value 35 to enable sma protocol in this uart, baud setup is in the sma driver settled to 4800 baud as spec says. This is made setting the value into the SERIAL_<<UART_NUMBER>> protocol param. Setup uart options to half-duplex.
Enable vtx setup setting to 1 the para VTX_ENABLE, save and reboot.
Enable sma protocol in vtx setting the VTX_SMA_ENABLE PARAM TO 1, save and reboot.
Enable hot_deploy to auto-adjust your VTX settings on the fly without rebooting.
Setup your desired params for band,chan and power in the VTX_BAND,VTX_CHAN,VTX_POWER.
Setup the additional options which affects pitmode, or unlocking features for the vtx.
Save and reboot.
When the vtx has power on, the sma driver will send to the hw-vtx the commands needed to sincro your vtx params config with the hw-vtx, and if hot_deploy is enabled, you could change at runtime into your GCS.
Thats all for now.
