Fix TGXL Fwd Power/SWR gauges: parse meters from direct connection (#625)#627
Conversation
…ethersdr#625) The TunerApplet power and SWR gauges always showed 0 because meter data comes from the TGXL's direct TCP connection (port 9010), not the radio's VITA-49 meter stream. Three issues fixed: 1. TgxlConnection discarded all R responses (status poll replies) which contain fwd= and swr= fields. Now parses R response bodies as KV pairs and emits statusUpdated(). 2. TunerModel had no fwd/swr fields. Now parses fwd (dBm→watts) and swr (return loss dB→ratio) from both stateUpdated and statusUpdated signals, emitting metersChanged() for the gauge. 3. Removed txMetersChanged→TunerApplet connection that was overwriting TGXL readings with exciter power values. TGXL protocol: fwd is reported in dBm (watts = 10^(dBm/10)/1000), swr is reported as negative return loss in dB (rho = 10^(rl/20), SWR = (1+rho)/(1-rho)). Fixes aethersdr#625 Co-Authored-By: JJ Boyd ~ boydsoftprez ~ KG4VCF <kg4vcf@gmail.com> Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Claude here. This is the right fix — TGXL meters come from the direct TCP connection, not VITA-49. Nice work parsing the R response body. This also explains #600 which we were investigating from the wrong angle. 73, Jeremy KK7GWY & Claude (AI dev partner) |
|
After thinking through this more, this approach definitely solves the problem on LAN and over VPN. However, it probably doesn’t solve it with a SmartLink-connected radio — will need to investigate further. As a data point, with SmartSDR on iOS, the Tuner Genius and Power Genius integrations don’t appear to work unless you’re on the same LAN or VPN — though it’s not clear whether that’s a limitation of that particular client or whether FlexRadio does have a mechanism to relay those commands over SmartLink. I plan to do some packet captures between native SmartSDR, the tuner, and the amplifier to see exactly what commands are exchanged. |
Summary
Fixes #625.
TgxlConnectionwas discarding allRresponse lines, which containfwd=andswr=from the 1/sec status poll. Now parses the response body as KV pairs and emitsstatusUpdated().metersChanged()signal. Converts TGXL's native units: fwd (dBm→watts via10^(dBm/10)/1000), swr (negative return loss dB→ratio viarho=10^(rl/20),SWR=(1+rho)/(1-rho)).Root Cause
The TGXL reports forward power and SWR via its direct TCP connection (port 9010), not through the radio's VITA-49 meter stream (PCC 0x8002). SmartSDR v3.9.18+ gets TGXL meters this same way (introduced in TGXL firmware v1.2.17).
AetherSDR's
TgxlConnectionalready polled status every 1 second and received the data, but:Rresponses were discarded at line 91 (return;)TunerModelhad no fields to store fwd/swrtxMetersChangedfallback sent exciter power (~100W) to the tuner gauge insteadTGXL Protocol Notes (port 9010, firmware v1.2.17)
Status poll:
C<seq>|status→R<seq>|0|fwd=40.53 swr=-25.78 tuning=0 relayC1=0 ...fwd: forward power in dBm (40.53 dBm ≈ 11.3 W)swr: return loss in negative dB (-25.78 dB → SWR 1.10, -60.00 dB → SWR 1.00 idle)Files Changed
src/core/TgxlConnection.cpp— parse R response bodies as KV pairssrc/models/TunerModel.h— addm_fwdPower,m_swr, getters,metersChanged()signalsrc/models/TunerModel.cpp— parse fwd/swr with unit conversion in both status lambdas, add<cmath>src/gui/TunerApplet.cpp— wireTunerModel::metersChangedtoupdateMeterssrc/gui/MainWindow.cpp— removetxMetersChanged→TunerAppletconnectionTest Plan
Known Remaining Issue
The TUNE button SWR capture after autotune still has a race condition between the radio's TCP
tuning=0(fast) and the TGXL's 1/sec poll (slow). This is a pre-existing issue documented in CLAUDE.md and will be addressed in a follow-up.🤖 Generated with Claude Code