SmartAudio UART doesn't send anything

[elderkeltir]

Cheers!

I did write some code to communicate with FC via SmartAudio.
Basically I just readout band, channel and power for my purposes.
The code was created and tested using betaflight, now I'd like to support iNav as well, but I stuck with a simple yet big problem: UART that is assigned to TBS SmartAudio doesn't send anything to me. In betaflight it spams "REQ_GET_SETTINGS (3)" until I reply with "RESP_GET_SETTINGS (9)", which is not the case.
I setup serial port with 4800 baudrate and stopbits=2.

I assume it's some kind of different approach between betaflight and iNav, I faced similar issue when was writing handler for MSP Displayport: iNav doesn't send you any data until you send heartbit to it.
Sadly I can't find any code to support this claim applied to TBS SmartAudio.

My FC target is FURYF4OSD.
UART3 = TBS SmartAudio

If someone can point to the spot in code that I can start digging into - would be awesome.

Tnhx in advance!

[sensei-hacker]

Here's the VTX task:

inav/src/main/io/vtx.c

Line 163 in 03efa41

void vtxUpdate(timeUs_t currentTimeUs)

What are you actually doing trying to accomplish?
If your device needs to initiate something, MSP is a way to do that.

[elderkeltir]

Let's say I'm working on some device and need it to be controlled via some standard protocols like SmartAudio.
Thanks for the advice, will try to debug it!

[sensei-hacker]

If you would like to speak privately you can find me on the INAV Discord.

The problem you're running in to may be implied by "I need it to be controlled", which puts the FC in charge and the VTX would sit and wait for a command. But then there seems to be an expectation that it won't sit and wait for commands?

If your device needs to take charge of the communication, if it needs to do something other than wait to be controlled, both Betaflight and INAV have MSP, where the connected device initiates communication.

[elderkeltir]

Okay, so I debugged a bit and found out that vtxSmartAudio device was overwritten by vtxMsp because USE_VTX_MSP was defined and vtxMspInit() was called AFTER vtxSmartAudioInit(), which basically substituted SmartAudio handler: vtxCommonSetDevice(&vtxMsp);

For now I disabled USE_VTX_MSP define, and it now sends requests via supposed UART, but I'm not sure if it's the best way to do it. I assume there is some kind of configuration that can do this better?

[elderkeltir]

the reason why it will rewrite vtx device from smartaudio to msp is because I also use MSP Display port to get osd through UART, iNav expects I will use MSP VTX as well in this case, so no smartaudio for me with MSP Display port active =(

[mmosca]

What is your use case, where you want to use MSP DisplayPort OSD but not MSP VTX?

[elderkeltir]

I set up video transmitting via wifi card, and MSP Displayport is used to get OSD and draw it on top of the video stream.

[sensei-hacker]

I set up video transmitting via wifi card, and MSP Displayport is used to get OSD and draw it on top of the video stream.

Cool. Similar to OpenHD, then?

[elderkeltir]

yep something like that. I know that some similar project utilize telemetry to draw fixed OSD, but I found MSP Displayport a bit more robust.