STATION_CALLSIGN was the one field the option deliberately skipped, on the
grounds that stamping the active call could re-route a mixed-call log.
That protected nothing. The same option already writes this profile's grid,
rig, antenna, city and postal address onto every record it finds blank — it
has assumed "this log is mine" long before it reaches the callsign. And the
thing that actually keeps a multi-op log intact is that a record CARRYING a
station callsign is never touched, which has always been true and still is.
Withholding it only meant the option quietly failed on the one field an
operator goes and checks afterwards, leaving imported QSOs with no station
call at all — invisible in the ADIF they export, and unroutable for LoTW
and Club Log.
Counted and logged: "did it fill the callsign?" is the first question after
an import, and the log is where it gets answered.
Compared side by side, DXHunter's decode list is plainly easier to read,
and three things account for the gap.
The Call column repeated what the message already said. Every FT8 line
opens with the callsigns — "CQ A93MO LL56", "PG5FRL JH3CUL PM74" — so a
column in front of it printed the same token twice and pushed the line
everyone actually reads to the middle of the row. It is gone; the message
is the identity, and the tokens worth finding are picked out inside it:
green for CQ and for our own call when someone answers, red for the station
we are calling. The grid went with it, being the message's last token.
Time is on every row now, compact, no separators. A decode belongs to a
period and the section heading names it — but once a slot runs past a
screenful the heading is somewhere above, and an instant you cannot read
where the decode is is not an instant you have.
Band and mode became their own columns, band as a chip, and the status
flags moved into one column at the right edge with LoTW and a "worked"
marker beside them. Rows are tighter: 13 px for the message and the report,
11 px for the figures, 10 px for the badges, and the column rules run
through the lot.
It joins the left/right dropdowns in Settings -> General alongside the maps,
the cluster and the rest, so decodes can sit beside the entry strip instead
of only behind a tab. Per-profile like the other pane choices.
The panel itself is now built in ONE place and rendered from both: two
copies of that call would be two sets of props to keep in step, and the
click handler in particular is not something to duplicate.
The status refresh follows. Its "is anything showing a spot status?" test
decides whether a logged QSO refreshes the NEW badges now or only marks
them dirty, and a panel that had become a pane would have gone on wearing
stale badges whenever it was shown that way rather than as a tab.
A countdown for the T/R slot, against the UTC clock — a bar, the seconds
left, and the mode. Slots are anchored to UTC rather than to when OpsLog
started, so it is computed from the wall clock alone and keeps running when
the band is dead and there is nothing to group. The last fifth of a slot
turns amber: that is when a decode is imminent and an operator deciding
whether to answer has run out of time to think.
Which exposed a real fault in the grouping. Status reports the T/R period
as a whole number of seconds, so FT4 arrives as 7 or 8 depending on which
way the sender rounded, and the code floored to whole seconds on top of
that — two FT4 periods landed in one heading and others were split down the
middle. The slot length now comes from the MODE, which knows the exact
figure and the whole halving family (FT8 15, FT4 7.5, FT2 3.75), with the
sender's number only as a fallback; and the arithmetic is in milliseconds.
Sub-second slots get a decimal in their heading, or two FT4 periods inside
one second would print the same time twice.
Two rows now stand out from the band behind them, because they are not
about the band at all but about the QSO in progress:
- the station being called is red, taken from the transmit state, so it
can be found in a slot holding thirty others;
- anyone ANSWERING is green and labelled, which outranks everything else
on the screen. A reply is a decoded line that opens with our own
callsign — bracketed too, since a non-standard call comes back
compressed.
EY35S went on showing NEW SLOT for the rest of the half hour it stayed in
the list, five minutes after the QSO was in the log.
A decode's verdict is resolved once, when it arrives, and then read from
the shared status cache for ever. The cache IS refreshed after a QSO is
logged - but refreshSpotStatuses only ever re-queried the cluster spots, so
no decoded callsign was in the batch. And the decodes tab was not in the
"is anything showing a status?" test, so logging a QSO while looking at
this very panel only marked the cache dirty and waited for the cluster or
the band map to be opened.
Both fixed: decoded stations join the refresh batch, deduplicated by
call+band+mode so half an hour of a busy band is a few hundred queries the
backend answers with one pass of the log, and the tab counts as visible.
Second, worse bug found on the way. The cache is pruned back to the live
spots once it outgrows twice the spot cap - keeping only keys present in
the cluster list. Decodes share that cache and are exactly what pushes it
past the cap, so on a busy band the panel would have wiped every one of its
own badges the moment it filled up. Decoded stations now count as live.
Clicking a decode now ANSWERS it. It sends WSJT-X/MSHV a Reply message
(type 4), which is the same thing as double-clicking the line in their own
Band Activity window: the application looks the decode up, sets its
transmit frequency to the caller's and starts the exchange.
It deliberately does not tune the radio, which is what it did before and
why nothing happened. On FT8 the whole band sits inside one passband, so
moving the dial changes nothing about who gets answered - the decision
belongs to the decoding application, and the Reply is the only way to hand
it over. Tuning would also just fight it for the VFO. The entry is still
filled so the QSO can be logged here.
The reply is routed by PROGRAM ID, not by listener: two receivers can share
one multicast group, and answering a station heard on the 6 m instance by
talking to the 20 m one would start a call on the wrong band. It goes to
the address that instance's packets actually arrive from - a multicast
listener must answer the sender, never the group. WSJT-X matches the reply
against its own decode list, so the payload replays the decode field for
field: time, snr, delta time, audio offset, mode and message text.
Two columns added, DT and Freq - the audio offset inside the passband, not
the RF frequency, which is the same for every station in the list and says
nothing. Past about two seconds DT takes a warning tint: that station is
drifting out of the window.
The transmit strip. "You cannot see what you are sending, or who you are
calling" - two separate faults. The message was only ever threaded into its
period, and in FT8 you transmit in the slots you are NOT receiving in, so
its period had no decodes and the whole line was dropped; a transmit slot
now creates its period. And the state is a strip of its own at the top,
because it is the one thing on the screen that is about the operator rather
than the band. It is fed by every Status rather than only by one carrying
transmit text, so it can still name the station being called on MSHV and
older JTDX builds, which stop before tx_message in the Status payload.
"New only" became per-category badges, in the colours and the vocabulary of
the Chase New panel. None lit shows the whole band - this is a decode log
first, and a panel that opened by hiding most of the traffic would be lying
about what is on the air.
Three things from reading it on a real screen.
Column rules. The grid alone was not enough to follow a line across: cells
now carry a right border and the row stretches, so the rules run unbroken
from the header to the bottom of the list. That is what turns rows of text
into a table.
Left-aligned. The previous pass centred the grid inside a maximum width,
which on a wide screen opened a dead margin down the left before the first
callsign - trading the hole in the middle for a bigger one at the edge. Now
it fills the width and the slack lands in the message column, which is the
one that can use it and the one bounded by rules on both sides, so it reads
as a cell rather than a gap.
"CQ CQ PE1NAO JO32" - a green CQ badge in front of a message whose own
first word is CQ. The badge is gone; the word already in the line is picked
out instead, which scans the same and stutters not at all.
First pass on the panel from operating feedback.
Columns are a grid template shared by the header row and every data row, so
the two cannot drift and the eye has a rail to follow. It is capped at
1500 px and centred: free-flowing, a 2500 px window put the country a foot
from the callsign it belonged to and left a hole in the middle of every
line.
"New" gets a COLUMN. It was only a coloured edge before, which says
something is special without saying what — and every one of these is a
reason to break off what you are doing and call. The entity verdict is a
solid badge, the orthogonal ones (park, grid, prefix, county) are outlined
in the colours markerColour already gives the cluster list and the band
map, so a new park is the same green in all three. Applied inline because
those are categorical --chart-* custom properties, which the theme does not
expose as Tailwind colour utilities: written as border-chart-7 the badge
would simply have had no colour.
Band and mode selectors now appear only when the feed actually carries more
than one of each. One MSHV is one band and one mode, so for most operators
they were furniture; they show up the day a second instance puts a second
band on the link, which is the only day they mean anything. Same rule for
continent, and a receiver count when more than one instance is feeding.
Added a LoTW-only filter, and raised the type throughout (call and message
to 14 px, secondary to 12 px, badges to 11 px) with more room per row.
The decode payload now carries the sending application's own id. It tells
two receivers apart on one multicast group — and it is the address a
WSJT-X Reply message would have to go back to, so it is carried now rather
than requiring another trip through the parser later.
Every FTx decode WSJT-X, JTDX or MSHV puts on the wire, grouped by T/R
period. Optional and closable, from Tools -> FT decodes; its open state is
remembered, because an operator running digital modes leaves it open for
the session rather than consulting and closing it.
The period is the point, and what separates this from the cluster list.
FT8 is a sequence of fifteen-second slots and a band is read by watching
them go by: who called CQ this slot, who answered, what I was sending while
they did. A flat list sorted by time loses exactly that, so the list is
grouped one section per period, newest first, with the operator's own
transmission shown inside the slot it went out in.
Three fields had to be carried up from the wire to make it possible:
- the decode's OWN timestamp, which the parser read and threw away. It is
what assigns a slot: a period's decodes arrive in one burst a second or
two after it closes, so arrival time piles a whole period into the next
one. Rebuilt to UTC from milliseconds-since-midnight, with the
day-boundary case handled - a decode stamped 23:59:58 arriving at
00:00:01 would otherwise be dated a day ahead and sit at the top of the
list for the rest of the session.
- the decoded line itself. The exchange is what says where a station is in
a QSO, and no set of extracted fields reads like "R-09" does.
- tx_message and transmitting from Status, which nothing parsed before.
Recorded once per message rather than on every Status, which repeats it
about once a second for the whole over.
Also picked up on the way: is_new, low_confidence, off_air, the operator's
own call and grid, and the T/R period itself - better authority on slot
length than the mode name, which says nothing about a custom period. The
Status tail is read defensively: those fields were appended over successive
schema versions and JTDX and MSHV each stop at their own point, so a short
packet is normal and keeps whatever parsed.
Status flags come from ClusterSpotStatuses, the resolver the cluster list
and band map already use, filling the same cache. One verdict per call:
"new band" in this panel and plain worked in the cluster two seconds later
would be worse than no flag at all. Clicking a call goes through the same
handler as a cluster spot, so answering a station is one gesture whether it
came off telnet or off the receiver.
Filters: CQ only, new-anything only, band, mode, continent, an SNR floor
and a free search. The band, mode and continent choices are built from what
is actually on the feed - offering 160 m to a station whose receivers are
all on 6 m is noise.
Decodes are held in the frontend and pruned to a rolling half hour: they
are a live view, not data, nothing outside the panel reads them, and a
night of FT8 on 20 m would otherwise grow a list no filter can rescue.
Arrivals are staged on a 300 ms timer so a period landing as fifty packets
costs one status lookup and one render.
The PH/CW/DIG grid in the Stats panel is the fastest read in the app and its
palette was fixed per theme. Settings -> Appearance now offers the six: the
four status fills, the never-worked fill, and the ring on the cell being
entered.
Stored as OVERRIDES, not as a palette. Each of the twelve themes ships an
--mx-* ramp tuned to its own background, so an operator who only wants a
different green must not thereby freeze the other four to the theme they
happened to be using that day. An empty value means "whatever the theme
says"; the chosen ones are stamped inline on <html>, where they win over
every theme; switching the feature off hands the colours straight back.
The pickers are seeded from what the matrix is painting at that moment
rather than from a fixed palette, so the choice starts from the colours in
front of the operator. A new --mx-cur token carries the current-entry ring:
it follows --warning by default, so it stays theme-correct on all twelve,
but can be recoloured without dragging every other warning in the app along.
The legend under the matrix and its cell tooltips were hardcoded English.
They now go through t() with the same keys as the pickers, so the grid and
the settings cannot disagree about which green is which.
HTTPS to a relay board could not work. Nearly every board that offers it signs
its own certificate — there is no authority anywhere that could have signed it —
so the request failed verification before it left.
A checkbox, per board, off by default. Not a blanket switch, because the other
HTTPS case is real and opposite: a board reached from outside through a proxy
with a genuine certificate, where verification is the only thing standing
between an antenna switch and the internet. Same setting, two boards, different
answers.
Off by default is only safe if the failure explains itself, so a certificate
error now names the box to tick. Go's own "x509: certificate signed by unknown
authority" is accurate and tells an operator nothing about what to do next.
Shown only once an https:// URL is actually in the board's configuration. A
board on plain HTTP has no certificate to argue about, and an option that cannot
matter yet is one more thing to wonder about.
The flag joins the driver cache key: ticking it has to rebuild the driver, or
the cached one would go on refusing the certificate with the verifying client it
already holds.
The boards that take a bare host — WebSwitch, KMTronic — keep verification. An
https:// typed there is the proxy case by construction, since they default to
plain HTTP on the LAN.
Three tests against a real self-signed TLS server: accepted with the box,
refused with a message naming it without the box, and one board's setting not
leaking into another's.
Opening Station Control left the compass blank for a second or two while the
amplifiers, relay boards and power supply filled at once.
Nothing was slow. The status bar keeps the shared heading loop running, so when
the compass mounts there is already a tick pending — up to the full three-second
idle interval away — and the new subscriber simply waited out the rest of it.
The heading was known the whole time and had nowhere to be read from.
The last heading is now kept and handed to whoever subscribes next. That matters
more on the Alpha SPID this was reported on than it would elsewhere: every poll
is an open, a read at 600 baud and a close, so even fetching immediately on
mount would not have been immediate.
In a microtask, so a subscriber is never called back before subscribeRotorHeading
has returned to it.
The one field the editor would not let you touch, and the one that was wrong on
WAJA. Every other property of a reference — its name, pattern, entity list,
validity window — was editable; the code was rendered readOnly, so correcting a
number meant deleting all 47 references and importing a new list, throwing away
anything the operator had adjusted in it.
A rename in the store, not a delete plus an insert: everything the reference
carries travels with it, which is the whole point of correcting a number rather
than replacing an entry. A number already in use is refused — REPLACE INTO would
have let one reference silently swallow another, discovered much later as a
prefecture quietly missing from the list.
The typed code is held apart from the selection. The list and every field patch
key off the selected code, so editing it in place made the editor lose the
reference mid-edit.
SaveAwardReference now recomputes the log like Delete and Replace already did. A
reference's name is what the award column SHOWS for awards displaying by name,
and its pattern is part of what matches at all — so editing one changes rows,
and the grid was left showing the old label until something else happened to
trigger a pass.
Changelog: the three TCI-sharing lines are merged into one. The server and the
two fixes made to it while building are one unreleased feature, and an operator
only ever meets the finished thing. The TCI-client PTT line stays separate — it
is OpsLog driving a SunSDR, the other direction entirely.
Wanted for the case where the answers are moving: an operator correcting their
own QRZ record, or chasing a DXpedition whose page changes during the operation,
otherwise waits out thirty days before OpsLog will ask again. Clearing the cache
by hand works once; this is the setting for a whole session.
Nothing is read from it and nothing is written to it — rows stored while it is
off would only sit there going stale, waiting for the day it comes back on.
Switching off is NOT clearing: what it already holds stays, and the Clear cache
button remains the way to throw that away.
Two distinctions the code now has to keep, both load-bearing:
An EXPLICIT stored zero is off; an ABSENT key is the thirty-day default. Every
operator who has never opened this setting has nothing stored, and reading that
blank as a zero would silently switch the cache off for all of them.
The CONSTRUCTOR's zero is still the default, not off. At startup the settings
have not been read yet, and beginning with no cache would hammer the provider
for the first seconds of every launch. Only SetTTL, called once the operator's
settings are known, can switch it off.
A negative lifetime is meaningless and is ignored rather than rounded into
either meaning.
The input had to change too: it derived its value from the stored number on
every keystroke, so the box could not be emptied — and 0 was unreachable
outright, since parseInt('0') || 30 is 30.
internal/rigctld exists because Windows gives a COM port to ONE process: the
moment OpsLog talks to the radio natively, nothing else can. It answers the
programs that speak Hamlib NET rigctl. This answers the ones built around Expert
Electronics' TCI instead — and it answers them whatever radio is connected,
because it sits on the same backend-agnostic Rig interface. An operator with an
Icom or a Yaesu can now hand a TCI-only program a working rig.
One server or the other, never both. They answer the same questions about the
same radio, nothing speaks both, and a second listener is only a second thing to
go wrong.
Written against the official TCI Protocol document (ExpertSDR3/TCI, 12 January
2024, MIT — downloaded and read, not recalled): the initialisation set of §4.1
in its documented order, and the argument order of every command from §4.2. A
client will not proceed past connect without that block, which is why it is
written out in full rather than stubbed.
The one dangerous detail is the VFO mapping. TCI's channel A is where you
LISTEN and channel B where you transmit — the opposite way round from OpsLog's
RigState, which follows ADIF. Getting that backwards would put a station on the
DX's own frequency, so it is pinned in both directions by a test, and RxFreq was
added to the adapter rather than inferred.
Writing channel B while the rig is simplex is ignored: the client asked to
prepare a split transmit frequency, not to QSY, and a logger doing that on every
spot click would drag the operator off the station they were listening to. A
backend that cannot split still refuses out loud.
Only changes are pushed. TCI clients redraw on each command, so re-sending an
unchanged frequency four times a second makes a VFO readout flicker and fights
the operator's own tuning.
Nine tests, no socket needed — the protocol is the decision, not the transport.
The three layers underneath were already there and unreachable: the change-log
format (7d664bd), the identity column (724e68b) and the no-backfill decision
(c48294b). This is the wiring that gives the operator a switch.
Settings, all profile-scoped, because each profile can point at its own logbook:
the folder, this PC's name, the machine id minted once from it, the per-peer read
offsets and the tie-break counter. Scoping the machine id is what keeps two
profiles sharing one folder from writing two logbooks into one file.
Three hooks. Add and update publish asynchronously, down with the rest of the
after-the-fact work — a folder on a network share can block for seconds and a
contact belongs on screen long before another machine hears about it. Deletion
publishes SYNCHRONOUSLY and BEFORE the row goes, for the same reason
deleteRemoteCopies does: once it is gone its identity is gone with it and the
tombstone names nothing.
The apply path uses the repository directly and never AddQSO/UpdateQSO/DeleteQSO
— those publish, and a change applied here would be written straight back out,
two machines echoing each other for ever.
Saving writes a probe file to the chosen folder rather than asking whether it
exists. A read-only cloud folder, or a share whose credentials expired, exists
perfectly well and would swallow every contact in silence; if the probe fails the
switch goes back off instead of sitting on while nothing is written.
The panel is mostly status, and deliberately: every part of this runs on another
machine and on a sync client OpsLog cannot see, so "it is not working" has to be
answerable from the settings page — which PCs are in the folder, when each last
logged, what is waiting unread.
Four tests on the apply path, the middle two being the ones that matter: an edit
made on the other PC lands on the copy already here, matched on the contact
itself, instead of becoming a second row — that is what makes the no-backfill
decision safe — and a contact with the same station on another band stays a
separate contact.
withIOTARef was applied inside fillFromLastQso, the backfill that runs when the
provider came up short. That function returns early when there is no previous
contact with the callsign — so the island reference appeared for stations
already worked and never for the new one calling from the island, which is the
entire point of reading QRZ's <iota>.
Moved to the provider result in runLookup, where the rest of the callbook fields
are applied. The precedence is unchanged: a reference the operator typed or
picked still wins over the callbook.
Reported on F5IRH, Le Palais, Belle-Île-en-Mer — EU-048 in the QRZ record, and
nothing on the IOTA award.
No changelog line: the feature has not shipped yet, so the entry already in the
0.25.7 block now describes what it does.
The four buttons on the left change WHICH settings database is in use; the two
on the right act on the file already there. Splitting them by that line makes
the row read as two groups instead of six equal choices, and it stops the pair
wrapping to a ragged second line under the others.
ml-auto rather than a second container, so they still wrap gracefully when the
panel is narrow.
Also removed: "OpsLog can copy the SQLite database to a folder of your choice
when you close it, once per day. Rotation keeps the last N copies…" — everyone
knows what a backup is, and the controls underneath say the same thing in their
own labels. Gone from both dictionaries, and the bilingual test passes.
Text only — every feature stays exactly as it was.
gen.mwDesc what a Most Wanted rank is
bk.hintMysql what the on-close backup does with a MySQL logbook
db.profileHint that the logbook follows the active profile
db.mysqlHint that several OpsLogs on one MySQL see each other live
They explained things an operator already knows, in a settings panel that has
plenty to read as it is. The backup header keeps its ordinary hint; only the
longer MySQL variant goes.
Each removed from BOTH dictionaries: a string left in one and dropped from the
other shows the bare key in the other language, which is what
TestEveryStringIsInBothLanguages exists to catch — and it passes.
QRZ's XML carries <iota>EU-048</iota> for an operator on an island, and OpsLog
read past it. Wired end to end: the provider, the lookup cache (a column, like
web and zip before it), and the entry's award references.
It matters more here than the same field would for another award. There is no
live "who is on an island right now" feed anywhere — POTA has one and that is
what OpsLog matches spots against; SOTA has one behind conditions; IOTA
publishes only static lists. So the callbook record is the practical source, and
it is known BEFORE the contact is logged, which is when a reference is useful.
The reference goes in as an IOTA award reference, exactly as one picked by hand,
so the existing path carries it to the qso.iota column on save.
Two limits, both deliberate. A reference the operator typed or picked WINS: a
callbook entry can be years out of date, and the operator in front of the radio
has just been told where the station is. And the value must look like an IOTA
reference — two letters, a hyphen, three digits — because writing anything else
into the award makes a reference no list contains, which counts for nothing and
has to be found by hand later.
Two faults behind one screenshot: 3Y0K, recorded in the log as Bouvet Island,
showing the Antarctica matrix.
SELECTING A QSO now shows what that QSO records. The panel asked WorkedBefore
with no DXCC hint, and a hint of zero makes the backend resolve the entity from
cty.dat and the ClubLog exceptions AS THEY ARE TODAY — right for a live contact,
wrong for one being looked at in the log. The repo's own "infer from past QSOs"
path never ran, because the hint was no longer zero by the time it got there.
Hence Antarctica, and "5 QSOs with this entity" against "11 with this call":
two different entities, one of them nobody had asked about. The selected row's
dxcc now travels with it and is passed as the hint.
Browsing the log shows what the log says, even where the log is wrong.
Correcting an entity stays a deliberate act — right-click, Update from ClubLog.
BACK-ENTERING A QSO now resolves the exception at the CONTACT'S date. An
exception carries a validity window and a DXpedition's window closes: 3Y0K typed
months later, with the activation's own date in the form, was resolved against
today, matched nothing, and fell back to cty.dat. Both callers pass the date
they already hold — the entry strip's, and in the editor the record's own.
The date is trusted to move the resolution BACKWARDS only. A half-typed
"2026-0" must not send the lookup to the year 20, and a mistyped future date
must not resolve against a window that has not opened; both fall back to now.
Midday rather than midnight, because a window given in whole days is inclusive
of its end date and 00:00 sits exactly on the boundary.
Reported from a photograph of a French screen: "Spot lifetime" and "Chase new
grids" still in English in the DX Cluster settings. Diffing the two dictionaries
turned up fifteen more — including the ENTIRE update panel, which is why an
operator who reads French had nothing in French to react to when a new version
appeared.
All seventeen translated. Both dictionaries now hold 2685 keys with no
difference either way.
Every user-visible string ships in both languages: that was a rule, and until
now only a rule. A test parses the two dictionary literals and compares their
keys, so the next one is caught by `go test` instead of by an operator
photographing their own screen. Verified it fails when a key is removed.
A key missing from one side is not a blank — it falls back to the key itself,
so the interface reads "clu.spotTtl" where a label belongs, or keeps the English
text, which looks deliberate and is not.
"In this award's scope but with no reference" needs a scope to be in. On a
worldwide reference award — POTA, SOTA, IOTA, WWFF — every contact anywhere
would qualify, so the backend returns nothing and the window says it found
nothing. The button was there regardless, and could only ever open that.
It now appears only for an award scoped to a DXCC entity, which is what the
help text underneath used to have to explain. Better than what I did first,
which was to make a useless screen fast.
Kept from that: the assign dropdown is searched rather than scrolled above 300
references, and the reference list is not fetched until there are rows to
assign it to. Both still bite on a scoped award with a long list — Russian
districts, the bigger European ones.
Reported as POTA: missing references, and it hangs.
The Missing-refs modal builds a dropdown of every reference the award has, one
menu item each. A POTA log with the park list imported holds tens of thousands
of them, and putting that many items in the DOM stops the window answering.
Russian districts and the bigger European lists are the same shape.
Two things, and the second is the sharper one.
The list is now searched rather than scrolled: above 300 references a filter box
appears beside the dropdown, and the menu renders at most that many, saying how
many it is holding back. Nobody scrolls to K-4521 — they type it.
And the modal no longer fetches the references at all until there is something
to assign them to. Missing-reference detection needs a DXCC scope, so a
worldwide award like POTA always has zero rows here and the modal says so — it
was loading every park behind that message, for a dropdown that could not be
used for anything. The freeze happened on a screen with nothing to offer.
Whether this is the freeze that was reported I cannot say from here; it is a
freeze on exactly that screen, for exactly that award.
A field log showed three pulls of the same 123 615 QSOs inside ten seconds, the
Go heap going 725 MB → 2213 MB → 2539 MB. It is released after the idle TTL, so
not a leak — just the same work done three times with all three results alive at
once.
The cache lock was released before the logbook was read, so every caller that
arrived during a build missed the cache and started its own. Opening the Awards
panel does exactly that. One builder at a time now, with the usual re-check
after taking the lock: the second and third caller wait out the seconds they
were going to spend anyway, minus two round trips to the database.
The slice is also sized from the previous build. Growing to 123 000 structs by
doubling copies the whole thing a dozen times and holds the old and the new
array together at each step, on the largest object OpsLog keeps.
Also, the settings panel registry. The hook trap that broke the window when the
power-supply panel was opened was headed off by a comment, and the comment did
not survive contact with the next panel — so it is now structural. PanelHost is
a module-scope component that calls the selected panel and is keyed by section:
hooks inside a panel land in a component context that persists, section changes
remount it so each gets a fresh and consistent hook list, and no panel state
leaks into the next.
Rendering the panels as <Panel /> instead — the obvious refactor — would have
been wrong: they are nested inside SettingsModal and close over its state, so
each parent render makes a new component TYPE and React would unmount and
remount the panel on every keystroke.
Asked whether the faster poll applies to all the rotator backends. It does —
GetRotatorHeading is one binding over PstRotator, Rotator Genius, GS-232/ARCO,
DCU-1 and SPID alike, and it reads only the ACTIVE rotor, so two towers do not
double it. But counting what that costs turned up two things worth fixing.
Every backend builds a fresh client per call — spid.New, gs232.NewSerial,
dcu1.NewSerial, rotgenius.New — so one poll is one OPEN and CLOSE of a serial
port or a TCP connection, not a read on a link already up. And the status bar
and the Station Control compass each ran their own interval against that same
binding, so with the tab open the controller was asked twice over. At the 700 ms
I had just set, that was nearly three port opens a second on a 600-baud line.
Both now share one loop, and it adapts: 500 ms while the position is changing,
3 s once it has been still for six seconds. These controllers do not report
"moving" — a SPID answers a position and nothing else — so it is inferred from
the position itself, and held briefly after the last change so the tail of a
movement stays smooth. Commanding a move, a stop, or switching rotor polls at
once, so the needle starts sweeping on the click.
A slow controller cannot stack requests behind itself either: at 600 baud a SPID
reply takes a fifth of a second on the wire alone, and a port still open from
the last poll cannot be opened again.
Field report from a tower: on a RAK/RAU in Rot1Prog, every commanded heading
made the antenna want to turn nearly a full circle ANTICLOCKWISE — 0°, 90°, any
of them — while the heading readout, the stop button and everything else worked.
BuildSet framed the four-digit Rot2Prog azimuth for both dialects. A Rot1Prog
reads three: its replies are three digits in a five-byte frame, and its command
field matches. So 90° went out as "0450" and was read as 045 — 45 − 360 = −315°.
Every target landed 360° low, which is why it was always anticlockwise and
always nearly a full turn. The operator's own guess, that OpsLog was in 720°
mode, was the right instinct in the wrong place: the fault is a decimal shift,
not a range.
The round-trip test added here is the one that would have caught it without a
tower — every degree of the circle through the command builder and back through
the reply parser, which must return the degree that went in. The frame tests
pinned the Rot2Prog form against the reference and said nothing about the other
dialect.
Two more from the same report. A rotator test that only READS the heading — SPID,
ARCO, DCU-1 — said "Packet sent, the antenna should swing to north, check
PstRotator's UDP listener", naming a program not in the path for a move never
commanded; it now says the controller answered and nothing was moved. And the
compass polled every three seconds, so a turning antenna moved the needle in
steps of about thirteen degrees; the heading now has its own 700 ms tick while
the relay boards and the antenna controller stay at three seconds.
It held a useState and a useEffect of its own, and the panels in that registry
are called as plain functions — PANELS[x]() — not rendered as elements. So its
hooks landed in SettingsModal's own hook list, and only while that section was
open: React counted more hooks than the render before and stopped drawing the
whole window (error #310).
The file says so three lines above the entry I added, on the two panels that DO
carry hooks and are therefore wrapped in JSX. Reading it would have been quicker
than the screenshot.
No hook here now. The COM ports come from the list SettingsModal already loads
when it opens, for the Winkeyer panel — one machine, one set of serial ports,
fetched once instead of twice.
The manufacturer's document arrived, so this is no longer guesswork: 9600 8N1,
function codes 03 and 06 only, and a register map with the output on/off at
0x0001, the measurements at 0x0010…0x0013 and the set points at 0x0030/0x0031.
ONE REGISTER IS WRITTEN — 0x0001, the output. The map also exposes the voltage
and current set points and the three protection trip levels as writable, and
none of them belong to a logbook: a wrong value there is 30 V where a radio
expected 13.8, or a trip level lifted on a supply feeding an amplifier. They are
read and displayed instead, next to the measured values, which is also how an
operator sees at a glance that the supply is on and the radio is drawing nothing.
The wire layer is tested where it can be. CRC-16/MODBUS is pinned against its
published check value — the CRC of "123456789" is 0x4B37 — which fixes the
polynomial, the initial value, the reflection and the absence of a final xor all
at once; the rest of the protocol is checked frame by frame against the manual,
including the byte order of the CRC, an exception reply told apart from a broken
line, and a reply from another slave on the bus refused. The write echo must
match the value sent: it is the only confirmation the output really switched,
and accepting the frame without it is how a radio ends up dark behind a green
light.
Framing follows the manual's own rules: 3.5 character times of silence between
frames (4 ms at 9600), and a frame is over when the line falls quiet — Modbus
RTU has no terminator, and a serial read that times out returns (0, nil) here,
so the reader is built on a deadline and a quiet-time rather than on an error
that never comes.
Untested against hardware — nobody here has the supply.
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.
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.
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.
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.
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.
rouggy