Reported as JTDX "Fake It" causing CAT disconnections. Fake It is not the
cause — it is what made an existing loop fire, and a regression of mine from
this morning is what closed that loop.
The station has an inbound remote-call row and an outbound N1MM RadioInfo row
on the same port, 2241, so every RadioInfo datagram OpsLog sends arrives
straight back on the loopback. The remote-call parser strips XML tags and takes
the last token as the callsign: for a RadioInfo that is
<ActiveRadioNr>1</ActiveRadioNr>, i.e. "1" — and <Freq> became a tune request
for the frequency the rig was already on.
That was harmless only while <Freq> was misread. It is in tens of Hz, the parser
assumed MHz, every echoed tune failed "out of the 11-digit CAT range", and the
loop died on the error. Teaching it the unit (331db58) closed the loop.
Fake It shifts the dial for each over rather than using split, so every
transmission changed the state twice — and each change published a RadioInfo,
which came back as a set, which changed the state again. The log shows the dial
oscillating 24915000/24915500 three times in 200 ms, then "timeout answering
IF;" and the shared link down. Every over, all morning.
Two guards, because one was not enough to be sure: a RadioInfo payload is never
a remote-call request, and a callsign has a letter in it — so the next program
to broadcast its state on that port cannot drive the rig either. Reload also
names an inbound and an outbound row sharing a port, which is the arrangement
that permitted this and which no settings panel shows.
Relay automatic control and the band-change outbound rows both hang off the rig
state, which is right when there IS a rig: changing Band in the entry strip
pushes a QSY, the new state comes back through the CAT callback, and the relays
follow from there — which is why this works for anyone with rig control.
Without a CAT connection nothing is pushed and nothing comes back, so a station
whose rig OpsLog does not control changed band and the antenna switch sat
exactly where it was. Reported as automatic control not working; it was never
told the band had changed.
The entry selector now says so itself, but only when the CAT push did not
happen, and never when the band or frequency lock is on: a lock means the entry
is deliberately decoupled from the rig, and moving an antenna to match a contact
logged from last year is worse than doing nothing.
The frequency is passed as unknown on that path — a band selector gives a band
and nothing else, and rules written on a frequency RANGE are left alone rather
than evaluated against a made-up dial reading.
The de-duplication of "is this a new band" is now shared by both sources, so a
station that has both does not command its switch twice for one QSY.
Also: the same credit line as the QSL e-mail now closes the default recording
e-mail body, on the same terms — a default in the template, so a stored one is
untouched.
"Designed & sent by OpsLog — https://github.com/GregTroar/OpsLog/releases/latest"
now closes the default body, so a fresh install sends it without being asked.
Put in the TEMPLATE, not appended at send time. Two consequences, both of them
the point: an operator who does not want it deletes the line once and it is
gone, and one who has already written their own body never sees it appear —
a stored template is returned verbatim and the default is only the fallback.
Appending it at send would have made it unremovable, which is not a thing to do
to somebody's outgoing mail.
The link is the human release page. updateCheckURL sits next to it in update.go
and answers JSON, which is the easy mistake here — a correspondent who clicks
the credit gets a download page, and a test says so.
Reported as delayed auto-upload breaking Recent QSOs. It does not — the grid was
waiting on the upload for its news.
Nothing reloaded the list on qso:logged. The entry form calls refresh() itself
after AddQSO, so a QSO TYPED in OpsLog always appeared; a QSO logged from
anywhere else — WSJT-X or MSHV over UDP, JTAlert, NET Control, an offline replay
— reached the grid only when something else reloaded it, and the something else
was extsvc:uploaded. With auto-upload set to immediate that arrives a second
later and hides the gap completely.
Set a service to delayed and the QSO appeared one to two minutes late; set it to
upload on close and not until the next launch. So the very thing deferring an
upload exists for — correcting a contact before it goes out — was impossible,
because there was nothing on screen to correct.
The list now follows the log, on the same debounced path the upload events
already use: qso:logged fires twice per contact (insert, then award refs) and a
contest run fires it every few seconds.
The automatic pass fills a blank county only, and deliberately: a value the
operator or QRZ supplied usually beats one derived from a ZIP code. That leaves
no way at all to correct a county already stored — and the Connecticut planning
regions are exactly that case. Every CT contact logged before that correction
holds a county the state abolished in 2022, and filling blanks never reaches
one of them.
So the new entry OVERWRITES, because it is asked for by hand on a chosen set of
rows precisely because the stored value is believed wrong. Only US entities are
touched, only callsigns the database holds, and only when the answer actually
differs — so re-running it on a mixed selection is safe and the count reported
is the number of counties that really changed. Award refs are re-materialised:
the county IS the reference for CQ USA-CA and the state for WAS.
The entry appears only once the database has been downloaded, and appears
without a restart when one finishes — an action that can only ever answer "no
database" is not worth a line in a menu this long.
Reported as OpsLog defaulting QSL_SENT_VIA and QSL_RCVD_VIA to "E" on import.
It does not: recordToQSO reads the field and normalises it, so an absent, empty,
blank or unrecognised value gives an empty one. An "E" seen after an import came
from the file — Log4OM writes QSL_SENT_VIA:1>E on every record whether a card
was ever sent, which TestQSLSentViaDoesNotBecomeManager already pins.
Nothing to change, so this pins the half nothing covered: the ABSENCE case. The
opposite is an easy reach — electronic confirmation is the common case — and
defaulting to it would quietly rewrite the operator's own record of how their
cards travelled, which is the same class of fault as issue #16.
Compiles and vets clean; not executed here — this machine's Application Control
policy began blocking freshly built test binaries partway through the session.
v0.25.5 went out with its seven entries; the block is byte-identical to the
tagged one. The version constants are left alone — the release script is the one
source that bumps them, and touching them here would make its "release commit
already exists" check misfire.
v0.25.4 was already released — tag v0.25.4 at 8113557, fourteen hours ago —
carrying exactly one entry, the WinKeyer probe. Everything since (cluster empty
state and timing, the generic HTTP relay, hardware following the profile, the
SteppIR read that never returned, the DXHunter tune unit) was written into that
block and would have been announced to operators as something they already have.
The 0.25.4 block is now byte-identical to the one that shipped, and the seven
later entries are under 0.25.5.
0.25.4 is going out with eight entries. The version constants are left alone —
the release script is the one source that bumps them, and touching them here
would make its "release commit already exists" check misfire.
io.ReadFull cannot be used on a serial port, and it was.
On Windows a serial read that times out returns (0, nil) — on this transport a
timeout is not an error. io.ReadFull loops while err == nil, so a controller
that goes quiet for one poll, or answers with a truncated frame, spins it
forever. It holds ioMu throughout, and that is the whole failure the operator
sees:
- the poll goroutine never returns, so nothing is ever logged about a fault
and the cached status keeps the antenna looking connected;
- every command blocks on the same mutex, and the trace line sat AFTER the
lock, so even the attempt left no trace.
One dropped reply on a 4800-baud link therefore stopped the antenna responding
until OpsLog was restarted, with a log that showed the antenna starting, a few
status frames, and then nothing — which is exactly how it was reported.
Reads are now bounded: three seconds for an 11-byte frame that takes 23 ms on
the wire. Giving up returns an error, and the poll loop already knows what to do
with one — say so and reconnect. The command trace moved ahead of the lock, so
what the operator asked for is in the log even when the answer is not.
The SPE driver reads through a bufio.Reader, whose ErrNoProgress guard already
covers this; the ADIF parser reads a file. This was the only exposed one.
The SteppIR report was not a SteppIR fault. In the log the antenna starts,
answers every poll, and sits at 21050 kHz while the rig works 21074 — and the
status line only prints when the frame CHANGES, so a link that is alive and
parked looks identical to one that died. The one line that explained it said
"ultrabeam: follow loop stopped", which covers two quite different situations
and, at startup where nothing was running, reads as a fault. Tracking was simply
switched off. It now says which of the two it is, names the antenna type, and
states the consequence — that the antenna will not follow the rig.
Same log, a second and unrelated fault: every launch failed a tune request from
DXHunter with "frequency 2107400000000 out of the 11-digit CAT range".
<FREQ> was read as MHz, but DXHunter had echoed back the value OpsLog itself
published in the N1MM RadioInfo broadcast, whose <Freq> is in tens of Hz. Both
units come from the same peer, so the unit is now inferred: try MHz, kHz, Hz,
tens of Hz, and keep the first that lands on an amateur band — anything a
station is asked to tune to is in one. Hz before tens of Hz because their only
overlap, 40 m against 4 m, is far more likely to be 40 m. Nothing plausible
tunes nothing and says so, rather than sending the rig to a wrong band.
Every setting is per profile, amplifiers included — that is the whole point of
one profile per station. But the amplifier clients were built once at startup
and again only when Settings was saved, so switching profile left them on the
previous profile's port. An operator with an SPE on COM9 for HF and another on
COM10 for 6 m had to open Settings and press Save after every switch. Save is
not a connect button; switching profile is what asks for that hardware.
The amplifier is what was reported, but it was never alone: the motorized
antenna, the Antenna Genius and the Tuner Genius are configured the same way and
were started in the same two places. All four now restart on a profile switch,
asynchronously, exactly as a save does.
Rotators were already correct — their client is built per command rather than
held open, so they read the active profile every time.
Unconditional, like a save: comparing each device's configuration across
profiles to skip a reconnect would trade a second of downtime for the chance of
missing one. A test now keeps the two lists in lockstep — anything started at
boot must be re-applied on a profile switch or be named, with its reason, as
something that must not be.
It was built the other way round on a misreading of two screenshots: the pattern
held {value} and the per-relay boxes held numbers to drop into it. The ask was
simpler and better — {value} is the name typed in Relay labels, so a switch
addressed by antenna name is one pattern instead of eight URLs:
http://10.10.10.100/relay?on={value} relay 1 named Ant1 → ?on=Ant1
Renaming the antenna re-addresses it, and the name on the button and the name on
the wire cannot drift apart because they are the same string. It works in the
per-relay URLs and in the patterns alike, so the per-relay boxes go back to
holding URLs and nothing about them changes meaning any more.
The label is percent-encoded with %20 rather than "+" for a space: "+" is a
space only in a query string and a literal plus in a path, and this can land in
either half of a URL.
{value} on a relay with no label would send "?on=", an empty parameter that most
boards answer with a cheerful 200 and no movement. The driver refuses it and
names the label as what is missing; the editor warns while it is being typed,
beside the empty box rather than after an antenna fails to switch. The labels
also join the driver's cache key — they are part of the wire format now.
They were made session-only on a misreading: the ask was about the FIRST launch
of a fresh install, not every launch. Restored as they were — restored on
reopen, and travelling with a copied data/ folder.
A first-ever launch already starts with nothing filtered: every selection
defaults to empty or off and there is no code that switches one on. The one
route by which a new installation can come up filtered is a copied data/ folder,
which carries the previous machine's selections by design.
The filtered-out message and the clear-every-filter button stay: they are what
makes a filter that IS set visible, whenever it was set.
buildDeviceDriver had no case for "httpgen", so the generic board fell through
to the WebSwitch driver: it polled an address it had never been given, reported
itself offline, greyed out every relay button, and sent none of the configured
URLs. Nothing in the interface said so — the board was configured, saved and
listed, and simply did nothing. deviceKey did not cover the URLs either, so once
that is fixed, correcting a typo in one would still have handed back the cached
driver holding the old address until a restart.
Two shapes of home-made switch could not be described at all:
- a bit-mask board whose four URLs differ by one character
(/Set0/1, /Set0/2, /Set0/4, /Set0/8) — {value} in the pattern now takes the
number from the per-relay box, keeping the address in one place;
- a board numbering its channels from zero — {relay-1}, since giving up the
pattern for eight hand-typed URLs was the only alternative.
The pattern decides what the per-relay boxes hold, and the grid says which as
soon as {value} is typed: guessing per box ("does this look like a URL?") would
change meaning on a typo, which is not a thing to do to something wired to an
antenna. A URL typed without a scheme gets http:// like the named boards get
from relayBase; https:// is passed through untouched.
Host and the connection test are gone for this type. It has no address of its
own — its relays may each live on a different box — and no status to read, so a
test could only ever answer "OK, 4 relays". Save was greyed out without a host,
which made a complete configuration of four full URLs impossible to store.
Cluster filters no longer persist across launches. A band lock set weeks earlier
is invisible to whoever set it: the counter reads 76 spots live, the grid is
empty, and the search goes to the cluster instead. Nobody loses work by
re-ticking a chip. Grouping and the panel state still persist — they change how
spots look, never whether they appear.
An operator sent two screenshots: 76 LIVE in the counter, and the panel beside
it reading "Waiting for spots… Spots will appear as the cluster sends them."
Both his band and mode were locked to the rig — 20 m, SSB — so the filters were
doing exactly their job and the empty state was describing a different problem
entirely. He went looking for a connection fault.
It now says how many arrived, names every filter currently narrowing the list,
and offers one button to clear them all. The band and mode locks are named
first: they follow the rig rather than a click, so they are the two nobody
remembers switching on.
Also times the connection. He reports the first launch taking a while to
produce spots and a restart connecting instantly, which is the signature of a
slow name resolution rather than a slow node — the OS caches the answer, so the
second run skips it. The log now carries the dial duration and the delay to the
first spot, which separates that from a node that simply had nothing to say.
Hypothesis, not conclusion: the next log settles it.
Logger32's WinKeyer debug against the K3NG that will not answer OpsLog is a
capture of the exchange working, on the same keyer and the same port:
Sent: 13 13 13 00 04 55
Rcvd: 55 (72 ms)
Sent: 00 02 Host open
Rcvd: 23 (WK2 v23)
That is the sequence I already send. The difference is the grouping: Logger32
puts the three nulls and the echo probe in ONE write, and we split them with a
50 ms pause and a buffer purge in between. On a keyer that reboots when the
port opens, that pause is a window for it to come up mid-sequence and swallow
half of it — and there was nothing to wait for, since a null produces no reply.
The handshake bytes are now logged unconditionally, not behind the diagnostic
option. "No WinKeyer answered" cannot be told apart from a wrong port, a wrong
baud rate, a keyer still booting, or another program holding the line. The
bytes can, and it is four lines per connect attempt.
0.25.3 shipped with its two entries — the verified-confirmation fix and the
native SPID rotator — and they are two separate subjects, so there was nothing
to merge this time.
Version constants untouched: the release script owns them, and it already
bumped them to 0.25.3 in the commit before this one.
Same bug as yesterday's, one screen further on. The QSL Info table maps the
statuses it knows — Y, R, I, M — and falls through to "No" for anything else.
ADIF's V is anything else. So a contact confirmed AND validated by LoTW was
reported as not received, in the one place an operator opens to check.
V now has its own label, Verified, in the green of a confirmation, and it is in
the dropdown too. That second half matters more than it looks: a select whose
value is not among its items renders blank, so a verified contact looked like
nothing had been recorded — and the operator's next click would have replaced
the strongest confirmation they hold with whatever they picked instead.
The QSL Manager's bulk list is deliberately left alone: it sets paper QSL
status across a selection and defaults to "leave", so it never displays a
stored value, and "verified" is not something a paper card can be.
An operator with a tower at each end and an AlfaSpid on both wanted OpsLog to
talk to them directly. Multiple rotors were already there; the missing half was
the protocol.
Rot2Prog and Rot1Prog, over the controller's own COM port. The byte layout is
in the package doc and pinned by table tests against Hamlib's spid.c, the
reference implementation — including the one trap this protocol has: digits go
out as ASCII and come back as raw bytes. Send raw and the controller ignores
you; read as ASCII and every heading is wrong by a constant nobody would
recognise as such.
Two things the UI has to get right because they cannot be detected: the dialect
(different reply length AND baud rate) and the baud list, which for a SPID is
600 or 1200 — offering the usual 4800-and-up would have left the controller
permanently mute. Both are handled: picking SPID sets serial transport, 600
baud and Rot2Prog, and the baud dropdown changes to the rates these use.
The connection test reads a status rather than moving anything, so a wrong
dialect shows up there as a reply of the wrong length instead of as an antenna
that behaves oddly an hour later.
Untested against real hardware — I have none. The frames are pinned; the
controller is the only thing that can confirm the rest.
An operator's screenshot had it side by side: the Awards panel showed Morocco
validated on five bands, and the band/mode matrix two inches above showed the
entity as merely worked.
ADIF's QSL_Rcvd enumeration has both Y and V — "received" and "verified" — and
V is what a LoTW download writes for a confirmation the ARRL has validated. The
award engine's isYes accepted "Y" or "V". Everything else in the app compared
against 'Y' alone: the worked-before status grid, the slot statistics, the row
colouring by QSL status, the awards QSO list, the call history badges. So the
confirmations an operator cares most about were the ones that did not count.
Now one definition per side, named so the next reader finds the other:
qso.ConfirmedValues on the Go side, used by the queries themselves, and
isQSLConfirmed in lib/qsl on the frontend, which rowColors and the panels call
instead of testing the letter.
The Go test drives the real query shape against a real database with a 'V' row
— the constant being right is not the point, the queries using it is.
0.25.2 is going out. The version constants are left alone — the release script
is the one source that bumps them, and touching them here would make its
"release commit already exists" check misfire.
Fourteen entries for ten subjects. "UDP" appeared four times and "Motorized
antenna" twice, which is one line per commit rather than one per thing an
operator notices.
The two new outbound services are now one Connections entry, everything that
was made loggable is another, and the antenna's two silences — a lost port and
a controller going its own way — read as the single symptom they produce.
The selector offered 1, 2, 4, 8 and 16 and none of them took: the board stayed
at four relays.
The count is decided in three places — deviceRelayCount in Go, chanCount in the
Station Control panel, relayCountUI in Settings. The new type was added to the
first and the dropdown, and to neither of the others, so the panel resized the
labels from a helper that had never heard of it and fell straight through to
its fixed default. The Go side was right the whole time, which is why the
driver would have been built correctly for a count the operator could not set.
All three now know the type. A test pins the Go side against every count the
dropdown offers, and against the fixed boards, whose hardware decides and which
must keep ignoring the field.
An operator was about to build band→relay mapping into the custom URL rows.
It already exists, and better: relay auto-control has a per-relay "band" rule
driving webswitch, KMTronic, Dingtian, Denkovi and USB boards. It holds state
so a relay is only commanded when its wanted position changed, reads the
boards live before the first apply so it does not re-command one already in
place, and carries per-relay labels. A URL fired on a band change has none of
that, and would have been a second definition of "which antenna on which band"
— the drift that cost us a week on counties.
So the gap was only the hardware: a hand-made switch is none of the five named
types. It is now the sixth, "HTTP relay": an ON URL and an OFF URL, either as
one pattern with {relay} substituted, or one pair per relay. The per-relay
form is the reason it exists — these boxes often have URLs with nothing in
common between channels (…/FF0101 and …/FF0201), which no pattern can express.
Status is remembered rather than read: most have no endpoint worth trusting.
The cost is stated in the code and the panel — after a restart every relay is
re-commanded once, which is harmless on a board with no memory and far better
than assuming an antenna is already selected.
And the Connections panel now says so, exactly where the wrong choice is made:
picking a band change with a URL transport shows a note pointing at Station
Control. The URL transport stays — a lookup pushed to a webhook or a QSO to a
dashboard is an event, not a state, and Station Control has no place for it.
Two answers to "can people debug this when it does not work".
They could not. A custom UDP row logged "sent 18 bytes to 127.0.0.1:12000"
and nothing about the message — which is a template the operator wrote, so
the byte count says nothing about whether the substitution came out as they
meant. The payload is now in the line, with the trigger that fired it, for
custom rows only: an ADIF record or a binary WSJT frame on every QSO would
bury the log rather than fill it.
Worse was the silent case. A template that is a single placeholder the trigger
does not carry — {freq} on a band change — renders empty, sends nothing, and
looked exactly like a row that had never fired. It now says so, throttled per
row, and points at the field list.
And a password in a URL is redacted before it reaches the file. Storing
http://admin:secret@switch/ as typed was a deliberate choice for LAN gear;
writing it into a log that gets sent to whoever is helping is a different
choice, and was never made.
The Settings section is "Connections" rather than "UDP integrations", since it
has not been UDP-only since the URL transport landed. The log prefix stays
"udp:" on purpose — renaming it would orphan every log an operator has already
sent and every note anyone has written against it.
The hard-coded emitters each speak one published format at one fixed moment.
This is the escape hatch, and it exists mainly for antenna switches: they are
driven by a URL, and the band change is the trigger they want.
Four triggers, each carrying its own field set: band change (the RADIO's band,
not the entry form — a switch follows the rig, not what is being typed), QSO
logged, rotator command and callsign lookup. The panel prints the fields the
selected trigger can fill, which is the point of the whole thing: a placeholder
the trigger does not carry renders as nothing, and without the list an operator
writes {freq} on a band change and has no way to learn why the switch never
moved.
Three things the panel cannot show, handled here:
- Escaping. A URL needs every value percent-encoded; a UDP payload must not
be touched. The first portable callsign, F4BPO/P, puts a path separator in
the middle of a query string otherwise — it works on the bench and fails on
the air.
- Blocking. An HTTP call to a switch that is unplugged would otherwise sit
for the operating system's timeout, on the path of a band change. It runs
in the background with a 3 s limit.
- Silence. A switch answering 404 after a firmware update fails exactly like
success looks from here, so the status code is logged, throttled per row.
The rotator trigger hooks the COMMAND rather than the SP/LP buttons, so the
compass and a spot click fire it too, and the path ("SP"/"LP") is passed
through because an azimuth alone cannot say which was taken — 137° is short
path to one station and long to another.
Credentials in a URL are stored as typed. That is the operator's call, on the
grounds that this is LAN gear, and the hint in the panel says so.
"WSJT-X logged QSO (Logger32)" reads as Logger32-only, and it is not: the row
speaks the WSJT-X UDP interface, which several loggers listen on. An operator
running something else would have scrolled past a service that would have
worked for them.
Logger32 stays in the hint as the example it is — it is what this was built
against, and its additional sockets are where most people will point it — and
port 2250 stays as the default, a starting point rather than a rule.
The ADIF datagram reached Logger32's socket and still nothing appeared in its
log. WSJT-X sends TWO messages for every contact — QSO Logged (type 5), the
structured one, and Logged ADIF (type 12) — and receivers differ on which they
read: MacLoggerDX takes the structured one by default and offers the ADIF as
an option. We were sending only the half Logger32 does not use.
Both now go out on that row, in WSJT-X's own order. Nothing double-logs: any
receiver built for WSJT-X already sees both from the real thing.
Type 5 is read positionally, so the field order is pinned by a test against
NetworkMessage.hpp — one field out of place shifts every one after it and the
receiver files nonsense without complaining. QDateTime is Qt's own encoding:
Julian day, milliseconds since midnight, then the time spec, which is sent as
UTC (1) because a spec of 0 would have the receiver re-read the contact in its
own zone. The Julian arithmetic is checked against known values; a day out
there files every QSO on the wrong date.
"sent 1153 bytes to 127.0.0.1:2250" and nothing in Logger32. Both true: the
line the operator screenshotted is titled "Setup additional WSJT/JTDX UDP
sockets", and those receivers take UDP LOGGING PACKETS — the WSJT-X v2
protocol. A bare ADIF record posted to them is dropped without a word.
So there is a new outbound service rather than a change to the existing one:
"WSJT-X logged QSO (Logger32)" sends the same ADIF wrapped in a Logged ADIF
datagram (magic 0xadbccbda, schema 2, type 12), defaulting to port 2250. The
plain-text row stays for JTAlert/GridTracker-style receivers, because the two
really are different wire formats and one row cannot be both.
The id string is "OpsLog", not "WSJT-X": a receiver uses it to tell instances
apart, and impersonating the real thing would make a second WSJT-X
indistinguishable from us.
Tested both ways — the header byte for byte, and a round trip back through our
own ParseWSJT, since that is the same decoding every receiver applies.
Sahara moves to the parchment an operator asked for: page #e6ded0, panels
#f3eee2, toolbars #ded5c4, terracotta #c4501e on the buttons and the focus
ring. Lighter and less saturated than the deep sand it was.
Two silences from one operator's log.
The SteppIR is not blocked — it is being overruled. Every tune is commanded,
acknowledged on the next poll with the frequency asked for, then replaced on
the poll after by a different one: 21075 asked, 21075 confirmed, 21050
reported, again and again, with the operator tuning once more each time. Two
minutes of that reads as a dead link. It now says what it is, once, when the
motors have stopped and the reported frequency is more than 10 kHz from the
commanded one — a controller quantising to its own grid is not a fault, one
sitting somewhere else entirely is.
UDP outbound had no positive signal at all: only failures were logged. When
an operator sets up an ADIF message to a second logger and nothing arrives,
"OpsLog never sent it" and "the other program did not take it" looked exactly
the same from here — and the first is the common case, because a row created
as an inbound ADIF listener instead of an outbound ADIF message matches
nothing and emits nothing. Successful sends are logged with their destination
and service, and a QSO logged with no outbound row says so once a session.
The paper form had one "Via", which since the QSL_VIA split writes
QSL_SENT_VIA. QSL_RCVD_VIA had no way in at all outside the per-QSO editor —
a field with a column, an import and an export, and nothing to fill it.
Each direction now has its own route dropdown, sitting with the status and
date it belongs to: how the card was sent, beside Sent; how it came back,
beside Received. Both apply to the whole selection, which is the shape of the
job — a stack confirmed in one go usually arrived the same way, a bureau
delivery being exactly that, and doing it one QSO at a time in the editor was
the only option before.
Both store the ADIF enumeration (B/D/E), and neither touches QSL_VIA — that
holds the manager's callsign and belongs to the QSO, not to a stack of cards
being confirmed together.
The two columns were already available in the paper list: it renders through
RecentQSOsGrid, which gained them with the field itself.
Two problems from one operator's log, both of them the log's fault.
SteppIR. The last line about it is "status query failed, reconnecting: Port
has been closed" and then nothing — for the rest of the session. The poll loop
does retry every two seconds, but a failed open was a bare `continue`: no line,
ever. And startUltrabeam had three silent ways out — settings unreadable, the
antenna turned off, no port or host configured — so a cleared field and a lost
adapter produced exactly the same evidence, which is none. Both now say what
happened, with the port or host named. Reopen failures are reported three
times and then throttled (a port that is gone stays gone), and the recovery
says how many attempts it took.
FLDIGI. Four hundred "ADIF payload ignored" lines and nothing else legible.
The cause is in the same log: two inbound listeners on the SAME multicast
group and port, 239.255.0.1:2237 — one WSJT (MSHV), one ADIF (FLDIGI). Every
WSJT-X packet is delivered to both, and an FT8 cycle is dozens of decodes
every fifteen seconds; the bursts in the log are exactly 15 s apart. The ADIF
listener now checks for the WSJT-X magic and says so once, with what to do
about it, instead of rejecting each packet in writing. Anything else is
described a few times with its payload and then goes quiet.
An operator waited over a minute and the button never appeared; opening
Settings and pressing Cancel made it appear at once. That is the whole
diagnosis — Cancel was the only thing that re-read the option.
GetChaseNew returned the cached atomic, which exists for the MQTT goroutine
and is false until startup has read the setting. The UI asked while the
database was still opening, was told "off", believed it, and never asked
again. It now reads the setting, like the grid-chasing binding beside it.
The frontend asks again at the two moments this class of race resolves: when
GetStartupStatus returns, and when the first logbook load succeeds — the seam
that already re-reads the connection label for exactly this reason, with a
comment saying so.
The open/closed state was already remembered per machine; it is now in
PORTABLE_KEYS with the other widget toggles, so it travels with data/ like the
rotor and amplifier panels rather than being the one that does not.
Three cuts, all of them removing things nobody could act on.
The frequency column is gone. Clicking the row tunes the rig to it, so the
number was there to be read and never used. It is still carried on the spot —
the click is what needs it — and it is in the row's tooltip. The country takes
the space.
Modes are limited to FT8, FT4, FT2, PSK31 and RTTY. WSPR is the one worth
spelling out: it is a beacon, nobody answers a WSPR transmission, so a "new
entity on WSPR" is a path report and not a station to work — and on a quiet
band it would have been most of the list.
Bands are limited to the operator's own list. PSK Reporter carries every band
its receivers listen on, and a 13 cm decode is not an opportunity for a station
with no 13 cm.
Both tests run before the status lookup and both read a cached map: they throw
away most of the feed, so nothing downstream pays for it. The band list is
re-read when the lists are saved, so ticking a band in Settings applies to the
next decode rather than the next restart — which would have looked like the
filter not working.
Four things from an operator's first look at the panel, and one of them was
mine.
The frequency column showed "—" on every row. pskr.Spot.FreqHz was declared
and documented in one edit and never assigned in the next, so the payload's
"f" was parsed and dropped. A click therefore filled the callsign and left
the rig where it was, which is half the point of the panel. Assigned, with a
test that runs a real payload through and checks the value survives into the
Spot — the field being declared is what made it look done.
A row now carries ONE indication instead of stacking them. A station can be a
new band and a new prefix at once; the row says the first that matters, in the
order that would make an operator leave what they are doing: entity, band,
mode, slot, then prefix, then square. Two badges on one line made the list
unreadable at a glance, which is the only thing it is for.
Each category has a filter chip in the header, in its own colour, remembered
across sessions. A toolbar button shows the panel and a cross closes it — the
same split the Super Check Partial panel uses, where the setting decides
whether the feature exists and the button whether it is on screen.
The panel is wider and the country column gets what is left, which is more
than it was now that a row carries one badge.
An operator's keyer dropdown showed COM1 and COM3 twice, in the order
COM1 COM1 COM3 COM8 COM9 COM4 COM3, with "COM3COM3" as the selected value —
two entries sharing one value both counted as selected.
Not our bug to start with, but ours to absorb. Windows enumerates serial
ports from HARDWARE\DEVICEMAP\SERIALCOMM, which maps a DEVICE PATH to a COM
name, so the same name legitimately appears twice when two devices claim it:
a driver uninstalled without cleaning up after itself, or virtual-port
software. go.bug.st/serial returns one entry per device, faithfully.
Deduplicated and naturally sorted in the one binding every port dropdown in
the app calls, so CAT, rotators, amplifiers and the keyer all get it. COM4
now sits between COM3 and COM8 rather than after COM9, which is how a port
gets overlooked on a machine with a dozen.
A dropped duplicate is logged rather than swallowed: two devices holding one
COM name is also a good reason for one of them to report that port busy, and
that is not something an operator can work out from a list.
PSK Reporter tells you what is actually being decoded in your region, which
is a larger set than what somebody chose to spot: nobody spots the FT8 caller
running ten watts from a rare square.
Almost all of it existed. The MQTT payload already carries frequency, mode,
transmitter and both grids; the watcher already drops any report collected
further than NearKm from the operator, which is exactly the question worth
asking — the station is being heard HERE, not in Japan; and with grid chasing
on the subscription is already every band, filtered at the broker by receiver
square, measured at 0.2 to 1.2 messages a second. This reads messages that
were arriving and being discarded.
"New" is not decided here. Every spot goes through ClusterSpotStatuses, the
same function the DX cluster grid uses and the same cached index, so the two
panels cannot drift apart the way the county columns did. Cost per message is
map lookups behind an option cached in an atomic, because the MQTT goroutine
must never wait on the settings store.
The option is its own, not nested under grid chasing: chasing squares and
chasing entities are different wants, and the feed now has three consumers,
any one of which brings it up and none of which cuts the others loose when it
goes down.
The panel says "digital modes only" in its footer. An empty list has to mean
"nothing new on FT8/FT4/JS8 near you", not "the band is dead" — it will never
show a new entity on CW.
The comment came out "SSB WAC EU WAZ 15 WPX HA5" — the QSO's materialised
award_refs hold both kinds, and I took them all. Those four are what every
reader of the spot derives from the callsign in their head. They spent the
whole 30-character comment saying nothing and buried SOTA HA/KM-018, the one
reference anyone would have acted on.
Computed awards are now filtered out with the same rule the QSO editor uses
(isComputedAwardField), which is why they are the ones it lists on the left
and not in its read-only panel. The field map moves from a ref to state as
well: a ref left the first spot of a session computing before GetAwardDefs
had answered.
Also opens 0.25.2, since 0.25.1 shipped before the spot work, and sets the
default mode list to SSB, CW, FT8, FT4, FT2, RTTY, PSK31, FM. AM and
DIGITALVOICE stay in the catalogue but are no longer selected on a fresh
install. FT2 joins the digital family everywhere its siblings are listed —
report list, RST defaults, Flex power class — so it gets dB reports rather
than the 59 an unknown mode falls back to.
After the mode, which is the order a cluster line is read in:
"CW POTA FR-11553".
Two sources, because the QSO can be at either stage. While it is being typed
the entry panel holds the references as "CODE@REF;CODE@REF"; once logged they
live on the row as the materialised award_refs. The Send Spot window takes the
entry's when there are any and falls back to the last logged QSO — the same
fallback the callsign and frequency defaults already use — and picking a QSO
from the Latest list fills in that QSO's own.
A self-spot is the opposite case and gets its own builder: it announces OUR
station, so it carries MY_POTA_REF and friends. Using the QSO's award
references there would spot us with the park number of the station we just
worked, announcing us from somewhere we are not.
Both cap at the 30 characters a cluster node keeps, and add a reference whole
or not at all — a truncated park number is worse than none, since nobody can
act on it, and it still costs everyone who reads the spot. Only the comment we
BUILD is held to that; what the operator types is their own business.
The K3NG entry added an hour ago is gone. It named one clone among many —
WKmini, home-built Arduinos, unbranded boxes — for hardware that speaks
exactly the same protocol, and it was the only line in the engine list that
picked a boot delay rather than a protocol. An operator with an unlabelled
clone would have had to guess.
The delay is now learnt per port. The first connect finds out by failing the
quick attempt and succeeding on the slow one; that fact is written to a
global setting keyed by the port, and every connect afterwards goes straight
to the slow attempt. Global rather than per profile on purpose: which keyer
is plugged into COM3 belongs to the computer, and switching profiles for a
different rig does not change the keyer on the desk.
Two tests hold the contract from both sides — a slow keyer must be reported
as slow, and a keyer that answers at once must not be, or every K1EL connect
would inherit seconds it never needed.
The operator's keyer is a K3NG — an Arduino running an emulation of the
WinKeyer protocol — which changes the diagnosis and nearly broke it.
Checked against K3NG's own source before anything else, because yesterday's
handshake now FAILS a connect where it used to press on regardless. It is
safe: k3ng_keyer.ino implements admin echo (0x04) and echoes the byte back,
0x13 is a documented no-op, and OPTION_WINKEY_STRICT_HOST_OPEN — on by
default — ignores every byte except 0x00 before host open, so the resync
nulls are dropped harmlessly and the echo probe still gets through.
The real cause is in K3NG's options file, beside the feature itself:
"disabling Automatic Software Reset is highly recommended", and an option
to "discard errant serial port bytes at startup" for when it is not. On an
Arduino, DTR is wired to reset through a capacitor: opening the port reboots
the board into its bootloader. Ours spoke 400 ms later, to a keyer that was
not running yet.
So the retry now waits 2.5 s, which recovers it without an operator pressing
connect twice, and the engine list gains a K3NG entry that skips the doomed
fast attempt altogether. Everything else is identical to a K1EL — same
settings panel, same protocol.
Fifteen entries for seven subjects — the block had "WinKeyer:" twice, "QSL:"
and "QSL designer:" four times between them, "US counties:" three times.
That is one line per commit, which is how it was written, not one line per
thing an operator notices. Merged, in both languages.
An operator's log showed the whole fault in its first line: "connected on
COM3 — no reply — the keyer did not answer Host Open", followed by seven
configuration commands and two calls sent as Morse. Nothing was listening.
Reporting a link as up and then writing to it regardless is the part worth
fixing; the handshake is why it was down.
K1EL's Application Interface Guide gives the sequence, and we did one step
of it. Now all of it:
- DTR on, RTS OFF. K1EL's own init sets DTR_CONTROL_ENABLE with
RTS_CONTROL_DISABLE, and on a serial WinKeyer those lines ARE the power
supply — DTR feeds the 3.3 V regulator, RTS provides the negative rail.
go.bug.st/serial defaults both to true, so we drove RTS high on every
connect without a line of code saying so.
- 400 ms after the lines come up, for a WK1 still booting off DTR.
- Three 0x13 nulls to resync the command parser. A keyer left part-way
through a command by whoever spoke to it last would absorb Host Open as
a parameter — the everyday cause of a silent WinKeyer, and one the
operator can do nothing about from the outside.
- An echo test (0x00 0x04 0x55) before trusting the port at all. This is
the step that answers "is there a keyer here", and connecting now fails
on it, with the byte that came back when something else replied.
The whole handshake is retried once, since the first attempt's nulls are
what clear a confused parser. Tested against a fake port that reproduces
each failure: absent, mid-command, and echoing but versionless.
copyDirContents wrote into a destination it never created, so the first
os.Create returned ENOENT. The caller was written as "ignore os.IsNotExist"
— meant for a design with no pictures at all — and that guard matched the
failed write exactly: nothing was copied, no error surfaced, and validation
two lines later reported "copied design is incomplete: hero photo file
img_… not found" with no way to tell why.
Three fixes, one cause:
- copyDirContents creates its destination;
- the caller stats the source folder instead of pattern-matching an error,
so a genuine copy failure is reported and rolls back both the row and
the folder;
- DuplicateProfile had the same defect in its own form — an INSERT … SELECT
that cloned the template rows and left their photos behind, giving the
new profile designs with no thumbnail and nothing to print. It now copies
row and folder together, per template, since each needs its id first.
A test reproduces the original failure: it fails with the exact ENOENT that
was being swallowed.
rouggy