SA displays incorrect band, channel, and power on some VTx (Crossfire Sixty9)

MrD-RC commented 2 years ago

Current Behaviour

On most of my VTx there is no problem. However, this exists on the TBS Crossfire Sixty9, possibly others too.

OSD element for VTx Channel: always shows CH:A2:1
OSD element for VTx Power: always shows 1
OSD CMS -> VTx menu: top info bar always shows A2 FREQ 25. Where FREQ a static frequency is show, can't recall the numbers, but it does not change.
OSD CMS -> VTx menu: Band, Channel, and Power options, allowing you to change the settings, show the correct data.

Steps to Reproduce

Use a TBS Crossfire Sixty9. This may also happen with other new model TBS VTx?
Add OSD elements for the VTx
Look at OSD
Enter the CMS and go to the Features -> VTx menu
Look at the line of data at the top and compare to the menu options for Band, Channel, and Power

Expected behaviour

All elements should show the correct VTX band, channel, and power

Additional context

Data obtained via osdInfo (vtxDeviceOsdInfo_t osdInfo; vtxCommonGetOsdInfo(vtxCommonDevice(), &osdInfo);) is incorrect. However, data in vtxSettingsConfigMutable() is correct. Somewhere the two aren't getting synchronised.

FC Board name and vendor:
INAV version: 4.1 release and current master. Not tested on earlier versions.

erstec commented 2 years ago

@MrD-RC

CLI status shows same results

vtxSettingsConfigMutable() - contais valid configuration

It looks like for me SA2.1 on Sixt9 is not operable at all, I can't get it working. (Same setup working on BF without issues, so I am sure HW is ok).

FC constantly trying to "talk" to VTX, but no valid answer is parsed and saProcessResponse() not entering any case SA_CMD_GETSETTINGS... more, there is no valid packet from VTX parsed at all (passed CRC successfully)... and as result SA version is not set, no adjustments on VTX are performed

Can you advice me, maybe I missed something to configure from CLI to make SA2.1 work? Like vtx_smartaudio_early_akk_workaround or vtx_smartaudio_alternate_softserial_method

erstec commented 2 years ago

So, vtx_smartaudio_early_akk_workaround need to be OFF

After investigations with oscilloscope/data analyzer and step-by-step debugging: TBS Sixty9 (at least one I have, FW 6.13) uses UART @ 4800bps 8N1, not 8N2 as secribed in TBS SA datasheet. After changing SmartAudio UART init to 1 Stop bit - it communicates perfectly... https://github.com/iNavFlight/inav/blob/c91d3a85106bf9e0d193f219f1ff8bc79a52512d/src/main/io/vtx_smartaudio.c#L692

@DzikuVx maybe you have contacts on TBS to ask them for clarifications?

erstec commented 2 years ago

@MrD-RC what Target you are using? Or, maybe if you can build FW yourself, can you check it? I can provide you hex for quick testing, and if it solves your issue too - we probably need to think about additional config parameter...

MrD-RC commented 2 years ago

I'm using an F411-WING, think the target is MATEKF411. Everything is on default as far as the vtx_smartaudio_early_akk_workaround or vtx_smartaudio_alternate_softserial_method go. Using Crossfire FW 6.17.

erstec commented 2 years ago

I'm using an F411-WING, think the target is MATEKF411. Everything is on default as far as the vtx_smartaudio_early_akk_workaround or vtx_smartaudio_alternate_softserial_method go. Using Crossfire FW 6.17.

I updated mine to 6.17 too, no changes, CMS, OSD and status showing A2:1 and Sixty9 VTX are not settings configured at all, UART is "trying" to communicate with a lot of Framing Errors.

Then using my "workaround" - all became ok. All places are showing configured values and VTX, obviously, setted up too.

Attaching 5.0.0 "test build", use "new" CLI command vtx_smartaudio_sixty9, when this set to ON 1 Stop Bit will be used for SA UART. Let me know results, is you can. UPD: I setted vtx_smartaudio_early_akk_workaround to OFF, just information

P.S. Strange thing is that I compared BF sources with INAV and main places (init, rx, tx, parsing and etc.) are completely same. But this setup somehow works with BF4.3-rc3... drivers? idk how... P.P.S. oscilloscope I using (with Serial data analyzer), when setted to 4800 8N2 shows alot of framing errors, only sometimes pakets sent by FC are parsed ok, but no packets from VTX are ok at all in this mode. Same time, when setup is 4800 8N1 and FC UART is configured to use 8N1 accordingly - dataflow are perfect. I can think that data analyzer is not perfect, but then how Sixty9 SA2.1 communicates on 4800 8N1 fluently? idk this too...

inav_5.0.0_MATEKF411.hex.zip

iNavFlight / inav