Two more fixes in v2.4.2-pre2 — stuck "Initialising" overlay, FTDX3000/VSPE frequency freeze

[mm5agm]

Two more bugs tracked down and fixed, both from reporters working through several rounds of testing with me — thank you wa6auf and iu1teu.

"Initialising…" overlay stuck forever, even though the app is actually live — the poll that hides the startup overlay gave up permanently after a single failed HTTP request instead of retrying. If your meters and frequency were updating fine but the spinner never went away, this was it.

FTDX3000 frequency display freezes when YWC is routed through VSPE (Virtual Serial Ports Emulator, used to share one COM port between several CAT apps) — meters kept working, but frequency never updated. YWC was discarding bytes from the serial receive buffer before every command to clear stale data, which could silently eat a genuine unsolicited frequency update landing at the wrong moment. Real hardware rarely loses that race; a slower virtual port does.

Fix available now as a pre-release: v2.4.2-pre2. You don't need to uninstall v2.4.1 first — just run the new installer over the top; it'll close YWC if it's running and your settings carry over untouched.

This is a pre-release for testing, not a general recommendation to upgrade — if things are working fine for you on v2.4.1, no need to touch this. If either symptom above sounds familiar, please do try it and let me know how it goes, either here or on Issue #73 / Issue #74.

[iu1teu]

Hi Colin,
Tested v2.4.2-pre2 on my VSPE setup (COM5) — unfortunately the frequency is still frozen. Meters are still updating fine, same as before.

[mm5agm]

Hi iu1teu — thanks for testing pre2 and reporting back so quickly. Turned out pre2's own fix had a bug: it introduced a thread-safety issue in the CAT message buffer that could still swallow the frequency update, just via a different path. v2.4.2-pre3 is up now with that fixed — I've posted the details on #74. Same caveat as there: I thought pre2 was right too, so treating this as unconfirmed until you've had a chance to retest.

[mm5agm]

v2.4.2-pre4 is up, with a further fix on top of pre3.

wa6auf retested pre3 on #73 and the "stuck Initialising" problem was still happening. Going back through the log, the CAT-buffer lock in pre3 was a real fix for a real bug, but not the one causing that hang. It looks like YWC's logging was blocking enough thread-pool threads under load to slow the whole app to about one operation per second during startup — pre4 moves logging off the blocking path and gives the thread pool more headroom to absorb a startup burst.

I don't have confirmation this is the same thing affecting VSPE frequency freezes (iu1teu, #74), but VSPE's added latency is exactly the kind of setup where it would show up more if it's present at all — worth another test regardless of whether it's related.

Download: v2.4.2-pre4

Same caveat as pre2 and pre3: I can't reproduce either symptom myself, so this isn't confirmed until wa6auf or iu1teu can retest.

[iu1teu]

Gotcha! The frequency is live updating now! Look at: https://we.tl/t-6Z1gY1oS4NoJWqTO
Working fine with VSPE in a shared environment with HRD (I developed my app to get rid of HRD but my CAT control is very basic, just frequency, mode and split on both VFO, power and tune management).
My goal is having a shared environment with my app and YWC. 😄

[iu1teu]

A small visualization glitch on my Macbook Pro Retina with a resolution of 1512x982 (default resolution).
On a higher setting (1800x1169) there's no problem but... maybe is a bit higher for my eyes. 😅

[mm5agm]

Hi iu1teu,

Thanks for the screenshot — that's exactly the extra detail I needed.

I checked the FTDX3000's CAT manual: the RM/MS meter-read commands only define values for S, COMP, ALC, PO, SWR, ID and VDD — there's no meter-read value for temperature at all on the FTDX3000. So the "Temp" gauge you saw was reading an undefined/unsupported command, which explains the nonsense "3°" value. I've made a change (queued for the next release) that drops the Temp gauge entirely for the FTDX3000 — it genuinely doesn't have one over CAT.

VDD is a different story — "final amplifier drain voltage" is a real, CAT-supported meter on the FTDX3000, so that part isn't unsupported in the same way. But the raw-value-to-volts conversion YWC uses for it was worked out against an FTdx101MP a while back (from another user's bench measurements), and I have no evidence it's the right scale for the FTDX3000's PA hardware — the two radios' internal PA supply designs aren't necessarily the same. So I think your "48V" is a real ADC reading being run through the wrong conversion curve, not a genuinely accurate value.

Given that, if I drop both Temp (not supported) and VDD (can't currently show it accurately) from the gauge row for the FTDX3000, that should get everything back onto a single line for you. Would that work, or is VDD one you'd rather I keep even with the caveat that the number may be off?

[iu1teu]

I don't know if (or what) the Temp gauge is showing, but... the numbers at the moment seems pretty coerent (50-54° C with no tx).
I will try some FT8 TX and see what temp shows after that.

After some FT8 TX cycle:

I don't need the VDD gauge... but maybe some other OM need it, who knows? 😅

[mm5agm]

Hi iu1teu,

Good catch with those before/after-TX screenshots — an 8°C rise on PA Temp after transmitting is a real signal, not noise, so I was wrong to write that meter off. I'm not making any changes to the Temp or VDD gauges — both look like they're doing something real on your radio.

On the layout glitch itself: since you said it's fine at 1800×1169 but wraps at your default 1512×982, that's very likely just the meter row running out of horizontal space at the lower resolution, rather than a bug. Could you try Cmd - (zoom out) a couple of steps on the page at your normal resolution and see if that gets all the gauges back onto one line? That's a much simpler fix than removing anything, if it works.

[iu1teu]

With just a single step zoom out that's perfect. 😉

Don't touch anything.

[mm5agm]

Great, glad that sorted it! Thanks for testing it through with me — and sorry for the detour on the Temp/VDD gauges, good thing you pushed back on that with real data.

Since the zoom step fixed it and there'''s nothing left to change, could you close this discussion out whenever you get a chance? Appreciate the thorough testing as always.

[iu1teu]

I'm not sure I can close a conversation I'm not the author of (or at least: I don't see the controls to do so).

[mm5agm]

Ah, that'''s on me — you'''re right, you can'''t close it, only the author can. I'''ll close both this discussion and #74 out myself now that everything'''s confirmed working. Thanks again for all the testing!