Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Implement 'vtx_' settings and SetFreqByMHzMsp support #4265
This PR encompasses the changes for 4 PRs that I've posted on the Cleanflight side, as described below. With these changes, TBS-SmartAudio and IRC-Tramp video transmitters can be configured via CLI settings, and can be directly tuned to a frequency in MHz using a CLI setting or a Taranis/OpenTX transmitter (via smartport telemetry and modified 'lua' script).
This takes the 'vtx_' settings that @hydra created (vtx_band / vtx_channel / vtx_power) for RTC6705 and also implements them for TBS-SmartAudio and IRC-Tramp video transmitters. At startup the settings are applied to the transmitter. If the video setup is modified via the CMS OSD menu or via MSP (Taranis/OpenTX smartport), the settings are updated.
One nice thing the settings can provide is a way to configure a frequency (via USB / CLI) while the video transmitter is not powered up. Afer a save and power cycle, the system will startup at the new frequency.
Also, this adds a 'vtx_freq' setting for TBS-SmartAudio and IRC-Tramp video transmitters (I don't have an RTC6705 / SPRacing NEO board to test with.) If vtx_band=0 and vtx_freq!=0 then the 'vtx_freq' value (in MHz) will be configured on the transmitter at startup. If both are zero then the settings will be ignored. If vtx_band!=0 and a video transmitter is connected then 'vtx_freq' will be set to the current frequency value (in MHz) at startup.
vtx_band = #
vtx_channel = #
vtx_power = #
vtx_freq = ####
if vtx_band==0 and vtx_freq==0 then the settings will not be sent out to the VTX
SmartAudio-CMS fixes and improvements
Implements some fixes and improvements to the SmartAudio part of the CMS OSD menus:
CMS set of USER frequency would fail if frequency was same as previous USER frequency
CMS would set vtx freq immediately when going from USER to CHAN freq mode
After changing CHAN/USER freq mode but before SET, the CMS status line
CMS will now update when saDevice settings change
Modified SA CMS to use 'saSetPitFreq()' function
Moved 'saCmsUpdate()' declaration to 'cms_menu_vtx_smartaudio.h'
Add SetFreqByMHzMsp support for SmartAudio and Tramp
Adds support for setting the VTX frequency in MHz via MSP for TBS-SmartAudio and IRC-Tramp video transmitters.
I've posted modified 'betaflight-tx-lua-scripts' that utilize this new functionality, here:
overall this PR is great, quite a few trivial style cleanups to fix and magic numbers to replace with
@ethomas997 can you fix them with additional/replacement commits (add-to or update this PR branch)?
Can you also confirm that you have tested the changes on:
@hydra Thanks for reviewing it; yes, I'll do those changes. For hardware to test with I have a "TBS Unify Pro HV Race (SA V2)", a "TBS Unify Pro HV V2" and a "Tramp HV". (I don't have anything that's SA V1.)
Most of the new functionality is not implemented for RTC6705 / SPR-NEO. The current RTC6705 implementation would need some reworking to support setting frequency in MHz. I'm willing to work on it, but I would need to get my hands on compatible hardware.
@ethomas997 , overall I like these changes.
One thing you have changes is how the VTX config works - if the config is changed then
@ethomas997 , I understand they need to be save to take effect next startup. However this can be handled at a higher level, ie in CMS or MSP - this is how it is done for other configs. Eg
@martinbudden My implementation preserves the pre-existing functionality, which is that VTX changes in CMS or via MSP are persistent and don't need to be explicitly saved. I think it's best that it operates this way. If a pilot is in a group setting and the VTX frequency changes (unexpectedly) after reboot, that would be bad.
@hydra I think that would be a significant change to how the CMS VTX menus currently operate. Right now the user does the SET operation, the VTX config changes, and the config change is persistent.
The other thing is the config via MSP / Taranis-lua-script. Similarly, the user enters the config change and it is persistent.
The power setting for my setup is not being restored (or perhaps saved) correctly. Whenever I save via OSD my desired power, the next time the board powers up the power is set back to 25mW. It doesn't matter what power level I have chosen when I save.
referenced this pull request
Oct 24, 2017
This PR introduces a VTX device independant API to Frequency settings. Very good. Howabout doing the same for power? Pitmode is already fairly device independant, actually quite hard to make ON/OFF brand specific. Other than inverting it....
A generic power API could be done using a 16 bit arg for power in mW, 0 ... 65000mW would be enough range. This arg should be interpreted as the max allowed power, and the VTX device should set the closest lower power level.
One question on the Frequency API vs Band/Channel API. In the first post there are some dependencies described that I do not like. For instance setting band=0 and ch=0 will lock the Freq API. Is this still in place? If so, why this complication?? I could read the code, but I though i'd ask here.