rouggy/OpsLog
0
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 108 Wiki Activity

feat: network audio into the QSO recorder, and a Yaesu that stays on its VFO

Browse Source 
An Icom reached over the LAN streams its receive audio through the Icom
protocol, and Windows sees no sound card for it at all — the audio settings
could only offer the PC's own microphone, so "From radio" had nothing right to
point at and the QSO recorder had nothing to record. The recorder now accepts a
PUSHED source: the decoded stream goes to the speakers and to the recorder
alike, with no virtual cable to set up. Which source it uses follows the CAT
backend, and it is restarted only when that answer changes, so an ordinary
settings save never cuts a recording in half.

OmniRig no longer sends SetSimplexMode to a Yaesu when tuning. It is a silent
no-op on some — an FT-891 logged OK on every spot click while FreqA never
moved — and actively harmful on others. From an FT-2000 log, one QSY:

	Vfo="AB"(0x80)  Split=0x10000 (off)   the operator's state
	Vfo="BA"(0x100) Split=0x8000  (ON)    after SetSimplexMode

The rig-agnostic "receive and transmit HERE, simplex" call turned split on and
moved reception to VFO B. OpsLog then displayed B — reading the radio correctly,
after having moved it itself. Icom is untouched: there the call is the
authoritative one and the direct write is unreliable.

Also:
  - the NEW county badge shows in the entry form itself, inside the field,
    where the operator is deciding whether to call.
  - the basemap buttons clear the zoom controls; Light sat a few pixels from
    the minus button and was being clicked by mistake.
  - French cluster status: DÉJÀ CTC reads DÉJÀ QSO.
This commit is contained in:
rouggy
2026-08-23 10:43:11 +02:00
parent 778db0542e
commit 405b0e24cf
9 changed files with 194 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files
internal/cat/omnirig.go
+20
View File
@@ -500,10 +500,30 @@ func (o *OmniRig) SetFrequency(hz int64) error {
// deliberately; a spot click is a request to change frequency, not to change
// VFO. On SUB the direct FreqB write below does the whole job.
onSubVFO := vfo == "B" || vfo == "BB" || vfo == "BA"
// …and NEVER on a Yaesu.
//
// On Yaesu the call is useless at best: an FT-891 logged "SetSimplexMode OK"
// on every spot click while FreqA never moved (see below — the direct property
// write is what actually tunes these rigs). On an FT-2000 it is worse than
// useless. From a log of one QSY, before and after the call:
//
// Vfo="AB"(0x80) Split=0x10000 (off) → the operator's state
// Vfo="BA"(0x100) Split=0x8000 (ON) → after SetSimplexMode
//
// The rig-agnostic "receive and transmit HERE, simplex" method turned split ON
// and moved reception to VFO B, which is exactly what the operator reported:
// OpsLog showing B instead of A. OpsLog was not misreading the radio — it was
// reading it correctly after having moved it itself.
//
// Restricted to Yaesu because that is where the evidence is: on Icom the call
// is authoritative and the direct write is the unreliable one.
isYaesu := isYaesuRig(rigType)
simplexOK := false
switch {
case onSubVFO:
debugLog.Printf("OmniRig.SetFrequency: on VFO %q — skipping SetSimplexMode so the rig stays on SUB", vfo)
case isYaesu:
debugLog.Printf("OmniRig.SetFrequency: %q is a Yaesu — skipping SetSimplexMode (a no-op on some, and on an FT-2000 it turns split on and jumps to VFO B); the direct write below does the work", rigType)
default:
if _, err := oleutil.CallMethod(o.rig, "SetSimplexMode", int32(hz32)); err == nil {
simplexOK = true