stateBlock was built and then not placed in the row — the field simply did not
exist on screen. Now between QTH and the locator, where it was meant to go.
Left column 210 → 230px, and Comment and Note move onto ONE line side by side:
two fields that are usually a few words each were taking two full rows of the
entry strip. That frees a row for whatever goes there next.
Name, Band, Mode and Country go from 300px to 210px, which moves QTH, Comment
and Note left by the same amount. The width is set in TWO places — the Name row
and the Band/Mode/Country stack below it — and they have to stay equal or the
two rows stop lining up, so both were changed together.
State goes between QTH and the locator: it is part of the same "where is this
station" reading, and it is what WAS and the US county work key off. Narrow,
since it holds two or three characters, and upper-cased on the way in like the
other coded fields.
The Name label in this layout was hardcoded English while its twin went through
t(); fixed while here.
A log greets an operator; it does not address an envelope. "Robert Smith"
filled the Name field with something no one would ever send on the air, and it
is the first name that gets used when the contact is answered.
So fname alone, with the surname kept only as a last resort for a record that
has no first name at all — better a surname than an empty field. The nickname
option now falls back to the first name too, which is what it should have done
from the start.
joinName went with it: nothing composed a name any more.
QRZ publishes <nickname> — the name an operator goes BY on the air — and
OpsLog was composing fname + name instead. "Bob" is what belongs in a log;
"Robert J Smith" is what belongs on a licence.
QRZ only, and deliberately so: HamQTH's <nick> already fills the Name field
that way, so the same switch there would toggle a behaviour it has no way to
turn off.
A published nickname is optional, so an empty one falls through to the
registered name. That is the whole point of it being a fallback rather than a
swap, and it is what the test pins — a blank nickname must never blank the
name.
Spots were bounded by COUNT alone, so on a quiet band a two-hour-old spot sat
on the band map looking like something to chase. Settings → DX Cluster now
takes a lifetime: presets at 5/10/15/30/60 minutes, or any value up to twelve
hours, and 0 keeps the old behaviour.
Spots are REMOVED from the shared list rather than hidden at render. The
cluster list, every band map and the counts all read that one array, so pruning
it once is what makes the setting mean the same thing in every view — the
lesson already paid for when the band map ignored the cluster's filters. It
also gives the memory back.
A spot whose timestamp will not parse is never dropped: an unreadable stamp is
a reason to distrust the clock, not to throw away the spot.
Swept every 30 seconds — close enough that a 5-minute setting is honoured, and
invisible next to the spot stream. Clamped in the backend as well as the UI.
Reported on BH2SWB and 4X9AA: both flagged NEW PFX, neither ever worked, both
vanished the moment "hide worked" went on.
The predicate hid a spot when worked_call OR status === 'worked' — and that
second one is the ENTITY's status, not the callsign's. So any spot in an entity
worked years ago disappeared, however new it was for something else.
The extra markers are orthogonal to the entity status; the band map already
says so in as many words. They now win: a new prefix, county, grid or park is
never hidden, whatever the entity says. A worked entity that is new for nothing
is still hidden, which is what the filter is for.
Extracted to spotIsWorked in lib/spotDisplay, beside the other rule the cluster
and band map share, rather than left inline in a predicate that has already
grown once.
This repo has no frontend test runner, so this is verified by build and reading
rather than by a test.
Replaces the four fixed rules with the model Logger32 uses and the operator
asked for: Worked / Confirmed / QSL sent / To be sent, and inside each, which
channels count — paper QSL, LoTW, eQSL, QRZ.com. No ticks means every channel,
because a rule the operator has not narrowed must not quietly become a rule
about nothing.
"To be sent" is FIRST in the order, and that is the substantive decision here.
A contact can be confirmed on LoTW and still owe a paper card; the colour an
operator scans for is the one meaning "something is still owed". Placed after
"confirmed" that row goes green and the card never gets printed.
"Worked" is the catch-all — nothing sent, nothing requested, nothing back — and
is off by default, since turning it on paints every remaining row.
R and Q both count as owed: ADIF says requested and queued, and both mean the
card has not gone out.
"The ON button does nothing" has three different causes — the modem-line pulse
was refused, the pulse went out and the amplifier ignored it, or the amplifier
woke and the UI missed it — and the log could not separate them: it recorded
one combined error and never said whether the amp came up.
RTS and DTR are now reported separately (not every USB-serial chip honours the
modem lines, and some refuse them without saying so), alongside the model and
transport. A watcher then logs whether the amplifier answered within 15
seconds, off the caller's goroutine so the click still returns at once.
No change to the wake sequence itself, which is the part that took a long time
to get right on the 1.3K-FA.
"Was the grid in what WSJT-X sent, or did OpsLog put it there?" is the first
question asked when a contact is logged in the wrong square, and a byte count
cannot answer it. An expedition logged at its licence holder's home QTH stayed
undiagnosable for exactly that reason.
One line per QSO, around 280 bytes, whitespace collapsed so the record sits on
a single line.
Grid: RI0FA transmitted QN35 all evening and was logged with its licence
holder's home square. WSJT-X's logged ADIF usually carries no GRIDSQUARE, so
the lookup was the only source left — and QRZ/HamQTH describe where an operator
LIVES, which for an expedition is the wrong side of the planet.
The square heard on the air is now applied before the lookup runs, so
refineGrid has something to defend. It still upgrades a 4-character square to a
6-character one from the same field, and still refuses a finer square from a
different field.
SPE: decodeCSV marks the client connected on every frame it parses, and the
poll goroutine can be mid-read while PowerOff runs. The frame from a second ago
landed after PowerOff had marked the amp offline and put it straight back,
which is why OFF had to be pressed twice.
Frames are ignored for three seconds after the off key goes out — the window is
opened before the key is sent, so nothing already travelling can beat it. Time
bounded rather than latched: an amp switched back on at its own front panel has
to reappear without being told.
Reported: ten fresh contacts upload and appear on LoTW; twenty older ones,
bulk-edited to exactly the same LOTW_SENT/RCVD state, are accepted by OpsLog
and never arrive. The operator's reading was that a failed attempt could not be
overridden. It is simpler and worse than that.
TQSL's exit codes, from its own cmdline documentation:
8 NO QSOs were processed — already uploaded OR OUT OF DATE RANGE
9 some processed, some ignored — same two reasons
14 some already uploaded, the rest signed
8 and 9 were both read as plain success. So on 8 — nothing uploaded at all —
OpsLog announced "already uploaded (duplicate)" and stamped every selected
contact as sent. They were never on LoTW and now looked as if they were, which
is exactly the reported symptom, and it is not recoverable by re-uploading
because the operator has no reason to try.
"Out of date range" is the cause that bites here: a contact older than the
callsign certificate's validity is silently left out. Older QSOs failing while
today's succeed is the signature.
Now: 8 is a failure and nothing is stamped — a duplicate left at "R" is
harmless and will be refused again, whereas a contact wrongly marked sent is
one nobody will look at twice. 9 and 14 succeed but carry Ignored, and the
caller says so in the console and a toast.
TQSL's own sentence ("20 QSO records are out of date range") is captured and
shown. It was being read and thrown away, and it is the whole answer to "why is
my contact not on LoTW".
Two BandMap instances, and cleaning up a duplicated attribute took the prop off
the docked one as well as the copy. The multi-band tab drew the badge; the map
beside the entry form — the one actually in front of the operator — did not.
Logger32 draws a green square for a LoTW user and an X for a worked one. The
square is the part worth copying; the way it is drawn is not.
Colour on this map is already spoken for — it carries the entity status, and
the left edge of each pill stacks the new-park / new-county markers. Adding a
green fill for LoTW would put two unrelated meanings on one channel, and an
operator would have to work out which green meant what. So it is the same "L"
badge the cluster list draws, in the same muted blue, for the reason written
there: whether a station uploads to LoTW says nothing about whether the spot is
worth chasing.
Worked stations already read as worked here — the pill goes grey and the
status markers speak — so no X is needed.
Switchable in Settings → Appearance, and on by default: a `configured` flag
distinguishes "saved with this off" from "saved before the option existed", so
turning it off sticks instead of being undone by the next default.
The band map received the raw spot stream filtered by band alone, so none of
the cluster's filters reached it: switching on "LoTW users only" changed the
list and left the panadapter showing everyone. The same was true of hide
worked, the spotter continent, and the status and mode chips.
The predicate is extracted and shared rather than copied — two views of one
spot stream disagreeing about the same spot is the fault lib/spotDisplay
already exists to prevent, and a second copy would have drifted the first time
a filter was added.
The BAND filter is deliberately excluded from the shared part: a band map's
band is its filter, and applying the cluster's would empty every map but one.
The first version filled the whole row at 24%, and in a real log that meant
every row was painted: nearly every contact has SOME QSL state, so colour was
present everywhere and stopped being information — a striped background with
the data behind it.
The default is now a 3px stripe down the left edge. Same signal, nothing lost
to read it. A filled row is still offered, with a strength slider, for
operators who want the block — and the rule cards in Settings preview whichever
is chosen, so the decision is made by looking rather than by imagining.
Drawn as an inset shadow rather than a border: a border would shift the cells
three pixels on coloured rows only, and the columns would stop lining up.
Style and strength are normalised rather than rejected — a value out of range
is a slider that got away, not a reason to reset the operator's colours.
The "to send" rule only looked at qsl_sent, so a contact waiting to go to LoTW
— marked R, and the commonest not-gone-out-yet state in a digital log — matched
nothing and stayed uncoloured. It now covers any route still queued, and the
label says so.
New Settings → Appearance section: whole-row colouring in the log grid driven
by QSL / LoTW state, each rule with its own colour from a palette or a free
picker. What Logger32 does, with one difference that matters — the colour is
applied as a 24% tint, not a fill. Logger32's grid is white; this one is dark,
and a saturated user-picked colour behind white text is unreadable at exactly
the moment the operator is scanning for what still needs sending.
Rules are ORDERED and the first match wins, because a contact is usually
several of these at once: one confirmed on LoTW and by card is confirmed, not
"sent, awaiting reply". The order lives in the data so the panel can show the
rules in the order they actually apply, numbered.
The colour is interpolated into a CSS color-mix(), so anything that is not
plainly #rrggbb is refused on the way in and falls back to the default.
Also fixes the QSO number column, which was empty for contacts logged from
WSJT-X: that path inserts through the repo directly and never reached AddQSO.
Rather than chase each of the remaining bulk-insert paths — the POTA hunter
import and the LoTW/QRZ "add what I was missing" passes, which insert OLD
dates and so shift every number after them — the index now checks its length
against a COUNT and rebuilds when they disagree. One indexed count beats
remembering to invalidate in a place that does not exist yet.
OrderedIDs scanned qso_date straight into a time.Time. The column holds a
formatted STRING — the repo writes it with Format(isoMillis) and reads it back
through parseTimeLoose everywhere else — so the scan failed on every call, the
index was never built, and omitempty then dropped the zero from the JSON. A
column that shipped blank.
Scans the string and parses only the newest row; the ordering already came from
SQL, so 30 000 parses were never needed.
Tested against a real SQLite file with the date stored exactly as the repo
writes it, and with the ids running opposite to the dates — the imported-ADIF
case that is the whole reason this is not the id. It fails without the fix with
the scan error itself.
Not the id: the primary key follows insertion order, so importing an old ADIF
gives the oldest contacts the highest ids. This is a rank over qso_date.
Computed over the WHOLE log, not the query result — ranking inside the result
would renumber every contact the moment a filter is applied, and QSO #1 would
change identity as the operator typed.
Held as one id-to-rank map, built from a single ordered id query and dropped
with the other derived indexes when the log changes. A contact logged from the
entry form is the newest, so it takes the next number without rereading the
log: AddQSO deliberately avoids full invalidation because a contest run would
pay for it once per QSO. A contact entered with an OLDER date belongs in the
middle of the order, so there the map is dropped and rebuilt rather than
mis-numbered.
A batch that never reaches the disk looks exactly like one that does: the
locators are in memory either way until the next restart, which is the one
moment the difference shows. The shutdown flush was the least observable of
all — it runs last, and nothing said whether it had written anything.
Audit of every field a lookup returns against what OpsLog can store, prompted
by a report that HamQTH was not fetching the email.
The email was never broken: pinned now against a captured HamQTH answer, it
parses and reaches the QSO. The reported callsign simply has no public address
on HamQTH, which the empty field could not distinguish from a fault — so the
"[email protected]" placeholder is gone. A greyed-out sample address in the one
field an operator checks to see whether the lookup found one reads as a value.
Real gaps found and closed:
- web: the qso table has had the column since migration 0003 and no provider
mapping ever read it. HamQTH sends <web>.
- picture: Result.ImageURL was documented "QRZ only" because HamQTH's element
is <picture>, not <image>. It was there all along.
- zip: sent by both providers, read by neither.
- adr_name: used only as a fallback when a record carries neither nick nor
name. Deliberately NOT preferred over <nick> — a log wants the name the
operator goes by on the air, "Igor", not "Igor Vladimirovich Getman".
The parse tests use a real captured payload, including the stray <div> advert
the server injects into its own XML.
The chips in Settings only ever shaped the PSK Reporter SUBSCRIPTION. Neither
feed path checked them: both asked bandopen.Watched, which says which bands the
detector is capable of and knows nothing about the selection. So the cluster
path announced every watched band regardless, and widening the subscription to
"+" for grid chasing let PSK Reporter do the same — a station with only 6 m
ticked got 10 m and 2 m badges.
The selection is now cached beside the on/off flag and checked on both paths,
and unticking a band puts its badge out: badges fade on a timer fed by spots
the detector no longer looks at, so it would otherwise stay lit until a
restart.
The store shipped without its main source. Locators came only from this
station's own WSJT-X decodes, which is what the whole MQTT discussion was
about.
PSK Reporter now feeds it through a new OnGrid callback, fired before any
geographic filtering: what the store wants is "which square is this callsign
in", and that is true whoever happened to hear the report.
The subscription filters on the RECEIVER's square, a level the v2 topic
exposes. Measured on the live feed: the four opening bands unfiltered are 83
messages a second, of which roughly one in a hundred survived the NearKm test
that already existed here — the rest was received, TLS-decrypted, JSON-parsed
and discarded. One ring of squares is 0.2 to 1.2 a second.
By square rather than by DXCC, which was the obvious alternative: one country
measured 1.2 messages a second (OH) against 72.5 (K) on a single band, because
a DXCC can be a continent. By square the same measurement is 0.2 to 1.2, so the
load follows distance — what the feed is actually about — and is the same for
every operator.
Grid chasing subscribes with the "+" band wildcard, so one subscription per
square covers every band instead of one per band per square.
The store gains a source column (decode | mqtt), migrated in place on an
existing file.
The callsign->grid map died with the process. Every restart began with an empty
Locator column that took an hour of listening to refill, and everything learnt
the day before was thrown away.
internal/gridcache is its own SQLite file in the data directory, not a table in
the settings database: that one sits wherever the operator chose to put it,
often a synchronised folder, and a store that rewrites itself every minute has
no business there. Deleting the file costs a few days of listening and nothing
else.
Callsign is the primary key and the newest report wins — operators move, go
portable, go on expedition, and a stale locator is worse than none for grid
chasing because it reads as a square already worked. Entries not seen in two
years are pruned at open: that is the one way this cache can be actively wrong
rather than merely empty, and it is what bounds a store that would otherwise
only grow.
Only CHANGES are queued. The feeds repeat themselves, so writing every report
would put the whole stream in the batch instead of the news in it. Batches
flush on a timer and on shutdown — a restart is exactly when the cache is worth
the most.
Rotation is switched off while the store is attached: the cap would discard
callsigns the database still holds and the lookup would then miss what we know.
Age in the store is the bound instead.
The cache dropped EVERY entry once it passed 20 000. That was survivable while
the only feed was this station's own WSJT-X decodes, which never reached the
ceiling — it is a cliff for anything larger, and every locator in the cluster
list would disappear at once, periodically, for no reason the operator could
see.
Two generations: when the current map fills it becomes the previous one and a
fresh map takes over; lookups consult both. A rotation therefore costs the
older half and nothing more. It needs no insertion order, no per-entry
timestamp and no bookkeeping on the write path — all of which "evict the
oldest thousand" would require, on a path that runs once per decode.
The cap is 100 000, measured at 82 bytes an entry: 8 MB a generation, 16 MB
for both. 20 000 was chosen when the ceiling was unreachable anyway.
Both maps now go through rememberDecodeGrid / lookupDecodeGrid. Rotation swaps
the map headers, so the read had to be guarded; routing every access through
one accessor is what makes that checkable rather than remembered.
Entries had grown to 250-450 characters, carrying the symptom, the mechanism
and the reassurance about existing setups. The panel is read top to bottom;
that belongs in the commit message, which has no length limit and is not
competing for the reader's attention.
"Watch for band openings" only ever governed the extra DATA SOURCES — the RBN
nodes and the PSK Reporter feed. The detector itself ran on every ordinary
cluster spot regardless, so an operator who had never enabled the watch still
got 10 m and 6 m opening banners from a feature he had deliberately left off.
The flag is cached on bandOpenState rather than read per spot: this is the
cluster hot path, where a settings query per spot is exactly what the rest of
this file avoids. startBandOpenFeed owns it, and it already runs at startup and
on every save, so the switch takes effect without a restart.
Switching it off also clears the live badges and the accumulated spot window.
The badges only fade on a timer fed by spots the detector no longer looks at,
so they would otherwise hang there until the next restart; and dropping the
window means switching back on starts from what is on the air rather than from
an hour-old burst. The remembered openings are kept — those really happened.
Hidden from the filter panel and forced off, without touching the machinery
behind them — it is correct and took several rounds to get right, so it stays
whole.
One flag in lib/spotDisplay does both jobs: readSpotDisplayOptions answers
false while it is down, which covers the band map, and App.tsx seeds its two
states from that same call instead of reading localStorage directly. Without
that second half an operator who already had "No colour on worked" saved would
have kept it applied with no switch left to turn it off.
The saved preferences are deliberately left in localStorage rather than
cleared, so whoever had either option on gets their choice back the day the
switches return instead of silently starting from off.
Two dates side by side put each one in a half-width Field2, which spends 120px
on its label column — the second label overlapped the first input and the row
ran off the panel. The comment ten lines above says exactly this about the
group/subgroup fields; one per row, as everything else in this editor.
Also shows a far-future end date as open-ended. RDA carries 9999-12-31 as "no
end" and printing it back reads like a real deadline.
The claim that an empty per-reference window inherits the award's is now a
test rather than a comment: a QSO before the award's own ValidFrom does not
count for a reference that has no window of its own, and a narrower reference
window still applies on top.
References are not forever: a park is delisted, a district merged, a castle
loses its number. A QSO made while the reference existed is a valid contact
and must keep counting; one made afterwards must not.
The JSON format did not need to change — ValidFrom/ValidTo were already on
awardref.Ref, already columns in award_references, already round-tripping
through export and import. They were simply never read: awardRefMetas dropped
them on the way into the engine, so nothing downstream could enforce them.
This carries them through and checks them in keepRefs.
Empty means the award's own window governs, which inScope already enforces for
every QSO in the award. That fallback is deliberately NOT duplicated per
reference — two places enforcing the same dates is two places for them to
disagree. The editor shows the award's dates as the hint under the boxes so
the operator can see what empty inherits.
Dates are compared as ISO strings rather than parsed times: the stored shape
is "2006-01-02", lexical order on it IS chronological, and this cannot fail on
a malformed value the way a parse can — a reference with a typo in its window
keeps counting instead of silently vanishing from an operator's totals.
The Explain trace names the date and the cutoff, because "did not count" on a
contact the operator remembers making is exactly when they need to be told it
is the reference that has a window, not their log that is wrong.
Only the whole-catalogue bundle was reachable from the UI, so sharing one
award meant handing over every award you have — including the ones you edited
for yourself.
Nothing new was needed underneath: ExportAward(code) already existed and
already reads the definition AND its references from the database rather than
from the embedded catalog, which is the point (a WAPC is only worth sharing
because of the province list and city regexes the operator added). The English
and French strings existed too. Only the button was missing.
Kept distinct from the catalog publish next to it: that one stamps a version
and clears user_edited to seed a release, this one is a plain share and leaves
both alone, so the recipient's copy is correctly marked as someone else's work
instead of a pristine built-in that future catalog updates would overwrite.
The band buttons in Station Control tuned to a fixed mid-band frequency baked
into the frontend. An operator who lives in the CW segment, or in the FT8
window, got the antenna resonant somewhere he never operates and had to nudge
it every time. The SteppIR's own controller has a Frequency (KHz) column per
band for exactly this; this is that column.
Stored sparsely: a band with no entry uses its default, so nothing migrates
and an operator sets only the bands he cares about. Left empty the Settings
box shows the default as its placeholder, which makes clearing it the obvious
way back.
The value is checked against the band plan before it is kept, because it goes
to the antenna as a tune command — a lost digit (1450 for 20 m) or kHz typed
as MHz would send the elements travelling to a length wrong for the band the
operator is on, and on a SteppIR that journey inhibits transmit the whole way.
A rejected entry is logged and the band falls back to its default.
Resolution happens in the backend and rides on the existing status poll, so
the widget no longer decides where a band button goes and cannot drift from
what Settings shows. Its own table stays only as a floor for the first poll.
The follow loop only ever had one behaviour — re-tune once the rig moved
further than a fixed step. The SteppIR's own controller software offers three,
and operators arrive with that mental model: every frequency change, past a
threshold, or only on a band change. They are real operating trade-offs, not
preferences: "always" keeps resonance perfect at the cost of motors running
constantly (and on a SteppIR every move inhibits transmit while the elements
travel), "band" moves them a handful of times a day.
"Always" is implemented as the threshold mode with a 1 kHz threshold rather
than as a separate branch, so all modes keep the one deadband reference that
matters: the rig frequency last commanded for, NOT the antenna's own reported
frequency — a SteppIR flips its reported frequency between the commanded value
and its home value, which would re-issue a SET on nearly every poll and leave
the operator permanently unable to transmit.
Band mode compares against the band last COMMANDED for, not the rig's previous
band, so the first move after startup and any move made by hand still get
reconciled. It applies to the immediate spot-click path too: a click inside the
band the antenna is already resonant in moves nothing.
An unset or unrecognised mode resolves to the step mode, so every config
written before this option behaves exactly as it did.
Also routes the antenna settings block through t() — it was hardcoded English.
The card is two grid columns wide and sits beside a tall neighbour in Station
Control, so a single row of four bars left the height unused and squeezed each
bar into a quarter of the width. Two rows of two fill the room already there
and double the resolution of every bar.
The PowerGenius XL card gated its whole meter row on flex.amp_available, so
on any station without a FlexRadio it rendered OPERATE and the fan selector
over an otherwise empty two-column card — reported from a TS-590 station.
Nothing was missing from the backend. internal/powergenius already parses
forward power, drain current, VSWR and temperature out of the GSCP status
frame, and the docked AmpWidget already prefers the radio's meter stream and
falls back to those. Only the full card never learnt the fallback.
Same source preference as the widget, and the same two exclusions: peakfwd
and peakid are latched maxima that are never reset and survive in the
last-known status after the amp disconnects, so the plain readings are used
and gated on the transmit state instead of freezing on the last over.
WSJT-X "Fake It" shifts the dial for the duration of each over and puts it
back afterwards, but the restore is conditional: it reads the frequency back
and only moves the dial if it disagrees with where it believes the radio
should be.
That read lands inside the window where this backend stops polling on
purpose. A Kenwood answers "?;" to IF; while it is transmitting, and treating
that as a fault used to drop the shared CAT link entirely, so the cached
state answers instead. SetFrequency wrote the command to the rig without
touching that cache — so mid-over the cache still described the pre-over
dial, WSJT-X read its own receive frequency back, concluded there was nothing
to restore, and the radio stayed on the transmit frequency. Every later over
started from there.
Reported from a session where the dial stuck at 7075500 after a full FT8
over while a bare TUNE, which never sets a frequency, worked fine.
Only simplex updates the cache. Under split, FreqHz is the transmit frequency
while the write lands on whichever VFO the operator is on, and guessing which
side moved would put a wrong number in front of the operator — a stale one
survives until the next poll.
The test reproduces the reported sequence and fails without the fix with the
same frequency the log shows.
A 2 m opening was announced at 9650 km towards Japan. The callsigns gave it
away — 7M4RRM, JA7RPC, JF1AWC — all working EME, which is routine on 2 m and
reported to PSK Reporter like anything else. Real contacts, real grids, and no
evidence whatsoever about the band: an operator turning a beam on that bearing
would hear nothing.
Removing the flat 2400 km ceiling was right; it threw away genuine multi-hop Es
on 6 m. "No limit anywhere" was the overcorrection. The limit is per band now,
and it is physics rather than a threshold: 2 m reaches a few thousand kilometres
by tropospheric duct or a chain of Es clouds and no further, so 3500 km, and
4 m 4000. Six and ten metres keep no ceiling — multi-hop Es and F2 genuinely do
go round the world, which is the case that started all this.
Pinned from both sides: the 9650 km Japanese burst produces nothing, and a
2000 km 2 m burst in one sector still counts.
The UDP path applies the station profile, the DXCC number, the Club Log
exceptions, the zone refinement and the QSL defaults — and its comment says
"same as the manual AddQSO path", which it was not. applySolar and fillDistance
were never called there.
For an operator running digital, and that is most of the traffic on most
stations, it meant SFI, A, K and distance were empty across the whole log while
a hand-logged contact carried all four. It also quietly undermines the
history-based propagation work, which needs those numbers to be there.
applySolar now refuses a QSO more than a day old, whichever path it arrives by.
The UDP feed and the ADIF monitor normally carry contacts seconds old but
neither promises it — a logger re-broadcasting its backlog, or an operator
typing last month's contact by hand, would be handed this morning's SFI as
though it had been measured at the time. A wrong reading is worse than a missing
one: afterwards nothing tells it apart from a real one.
Width should follow use, and these two are nowhere near equal: a manager's
callsign is typed constantly, a QSL message almost never. The message held 7
columns of 12 for text most operators never write, while the field beside it —
often a long "via" instruction — was the one running out of room.
Swapped, so QSL via takes 7 and the message 5. Also puts them in the order they
are reached for.
QRZ has no record under M0BFS/QRP, so the lookup falls back to the home call —
that part worked. What followed did not: the home record's location is then
discarded, on the reasoning that a portable operator is not at their registered
address. True for /P and /M, and simply wrong for /QRP, which says something
about the transmitter and nothing about where it is.
So the grid came back empty for M0BFS/QRP while the same call without the suffix
answered perfectly, which is exactly how it was reported.
The distinction is now explicit rather than lumped in with the other operational
suffixes. /P and /M keep clearing the location, because mobile and portable both
mean somewhere other than home — that behaviour was correct and is untouched.
A power suffix stacked on a portable one (F4BPO/P/QRP) still clears: one of them
moved the operator.
A NULL never equals '', so a condition written that way returned zero rows. The
question is perfectly clear — the operator wants the ones with nothing in that
field — and answering it with silence makes the filter look broken rather than
mis-stated. eq and ne with a blank value now run the empty / not-empty test.
Empty on a NUMERIC column also had a real fault behind it. IFNULL(col,'')=''
compares 0 against '', which SQLite calls false and MySQL calls true — one
expression quietly answering two different questions depending on where the
logbook lives. Numeric columns test NULL or zero explicitly now; text keeps the
string test, where '' is a real value and 0 is not.
The dialog walked a hand-written GROUPS array. "The contact" was added to the
fields and not to it, so mode, submode and RST existed, passed every check I had
written, and could not be picked — the same shape of fault as the missing column
mapping, one layer further out. Two lists that must agree, with nothing making
them agree.
GROUPS is derived from the fields now, in declaration order, so adding a group
is adding a field. A group with no translation falls back to its own name rather
than rendering an empty heading: a missing label should look untidy, not
invisible.
Also stacks the DX sunrise/sunset in the band-slot header. Side by side it cost
about 150 px of a row that also carries the callsign, the badges and the band
grid, and it was what pushed that row onto a second line. Two short times one
above the other cost a fraction of it and no extra height — the row is already
taller than one line of text. The "UTC" label goes to the tooltip: the times are
monospaced and always UTC everywhere in OpsLog, so it was spending width to
repeat a convention the operator already lives by.
A bulk-editable field passes through THREE tables: the list the dialog shows,
bulkFieldColumns in app.go, and bulkEditableCols in internal/qso. I added mode,
submode and RST to the first and the third and missed the middle one, so the
dialog offered them and every save came back "unknown field".
Nothing warns about that. Each table is perfectly valid on its own, and the
mismatch only surfaces when an operator picks the one field that falls through
the gap — which is exactly how it was found.
So both directions are pinned now: every mapped field must be writable by the
qso layer, and every writable column must have a field mapping to it. A column
nothing maps to looks supported from the inside and cannot be reached from
outside, which is the same fault wearing the other hat.
The button was the wrong shape twice over. A maintenance chore does not belong
beside the options an operator actually chooses, and nobody should have to be
told their log is missing a field before it gets filled in.
So the distance is computed where QSOs come from: on the logging path and on the
ADIF import. fillDistance is its own function rather than part of
applyStationDefaults, because the import only applies those when the operator
ticks a box — and a distance is not a station default. It is derived from the
QSO's own two grids and is true whatever was chosen about profile fields.
What is already in the log is handled by a one-time migration at startup,
recorded by a settings key. In the background: on a large log over a remote
MySQL that is thousands of row updates and startup must not wait for a tidy-up.
Marked done only on SUCCESS, so a run cut short by a closed program tries again
next time rather than leaving half the log filled for ever.
An imported value still wins. It came from the log that made the contact, which
knew the real positions rather than two four-character squares.
Every one of the 2660 references was filed under European Russia. Corrected
against the RDA reference list: 991 are Asiatic Russia (15), and the 24 KA-
districts are Kaliningrad (126), which is not Russia for DXCC purposes at all.
1645 were already right.
dxcc_filter went from [15,54] to [15,54,126] with them. That filter decides
which QSOs are even considered, so leaving it alone would have made the 24
Kaliningrad districts unclaimable — a correction that quietly removes references
is worse than the error it fixes.
BA-27 (Mezhgorye) and BO-33 (Schebekino) are not in the reference list at all
and were left exactly as they were. Guessing an entity for a district nobody
lists is how a second wrong answer gets added to the first.
Only the dxcc field changed. Names differ in transliteration between the two
sources — Maykop against Maikop — and rewriting those was not asked for and
would churn 2660 lines to no purpose.
The published page derives a distance as it renders, which fixed the empty
column there but not the cause: the field is empty in the database, so it goes
out empty in every ADIF export and leaves the same gap in whoever imports it.
BackfillDistances computes it from the two locators for QSOs that have both.
Only where it is EMPTY: a stored distance came from the log that recorded the
contact, which knew the real positions, and two four-character squares are a
worse answer that must not overwrite a better one. Whole kilometres, for the
same reason the published column is.
In the Database panel rather than beside the county backfill, which lives under
US Counties: this one touches the whole logbook, whatever country the QSOs are in.
The page was capped at 1100px — a comfortable reading width, and the right
choice for the eight default columns. Now that all 123 fields can be published,
anything past about eight sat behind a horizontal scrollbar on a screen wide
enough to show the lot.
Worse, Windows hides overlay scrollbars until something moves, so a table that
scrolled looked exactly like a table with its right-hand columns missing. That
is what was reported, and the report was reasonable: nothing on screen said
otherwise.
The wrapper grows with its content now, up to the window, and keeps a minimum so
a two-column table does not collapse on a large display. The table sizes to what
its cells need rather than being squeezed to the container first — that squeeze
could wrap a callsign while empty space sat further along the same row. And the
scrollbar is drawn permanently, thin and in the page's own colours.
Nothing computes a distance when a QSO is logged. The DISTANCE field is only
ever filled by an ADIF import that carried one, so publishing it straight gave
an empty column to anyone whose log was made in OpsLog — which is everyone who
reported it.
It falls back to the two locators, which are on the QSO already. A stored
distance still wins: it came from the log that recorded the contact, which knew
more than two four-character squares do. No grids means an empty cell, not a
zero — an empty cell is honest, a zero is a claim.
Rounded to whole kilometres. The squares are tens of kilometres across and a
decimal would assert an accuracy nobody has.
The geometry moved to internal/geo on the way. It lived in package main, which
internal packages cannot import, so the PSK Reporter watcher already had its
maths injected from main and this would have been a third copy. A bearing that
disagrees with itself between two panels is a fault nobody reports, because each
screen looks perfectly plausible on its own.
They were excluded as "per-QSO", alongside callsign and date. That rule confused
two different things: bulk edit is not for describing QSOs, it is for REPAIRING
a batch of them — an import that mapped every contact to SSB, an ADIF that
carried no MODE at all. Refusing because a hundred rows should not normally
share a value left the operator editing a hundred rows by hand.
Setting the mode CLEARS the submode. A submode belongs to the mode it was
recorded under; left behind it contradicts the new one, and "FT8 with a submode
of USB" is not a thing — worse, the submode is what most ADIF readers believe.
Band is still refused on its own, and that half of the rule stands. It travels
with the frequency through BulkSetFrequency, which writes the pair: a band
contradicting its own frequency is invalid ADIF, and every export would carry
the contradiction out into the world. Callsign and date stay out too — they
identify the contact rather than describe it.
A saved band selection outlives the code that made it. 12 m was removed from the
watched set, but every operator who had already enabled the watch kept
subscribing to it — paying for a firehose whose messages the detector then threw
away. The stored list is filtered against the offered one now.
The badge appeared on the next poll rather than on the event, up to twenty
seconds after the announcement, so the two read as unrelated things that happened
to mention the same band. It appears immediately.
And the toast is gone. It said the same thing as the badge and vanished after
five seconds — an operator who was tuning when it passed had no way back to it,
which is precisely what the badge was built to fix. Keeping both announced an
opening twice and still lost it once.
Abbreviating 1500 to "1.5k" and then appending "km" produced "1.5kkm", which
means nothing. Plain kilometres now.
Written correctly it would still have been wrong: "1.5k km" asks the reader to
do arithmetic to recover a number that was four characters long to begin with.
There was nothing to save.
It read "6M OPEN" and kept the rest in a tooltip nobody hovers — an alarm with
no content, announcing that something was happening and refusing to say what.
Band, direction and typical distance are on the badge now: the three facts that
decide whether to point an antenna, all readable without touching anything. Out
of season gets a mark there too, since that is the one an operator must not
learn last.
The compass point is computed in Go and carried on the Opening rather than
derived in the UI. Sector() already gets the wrap round north right, and it got
it wrong once — a second copy of that arithmetic is how a badge ends up naming
the opposite direction to the log line beside it.
set_split_vfo and set_split_freq both answered RPRT 0 and did nothing. WSJT-X
and JTDX in "Split Operating: Rig" send exactly that pair, believed both, and
transmitted on the RECEIVE frequency — on a pileup, straight onto the DX, while
showing the operator precisely what they had asked for. A lie that leaves no
trace in any log is the worst kind of bug this program can have.
The two commands are honoured as a PAIR. Arming alone does nothing on the radio,
because WSJT-X sends the frequency second and split armed on whatever the
transmit VFO happened to hold is worse than no split at all: it transmits
somewhere the operator never chose. The request is remembered and set_split_freq
does the work.
Kenwood gains SetSplit — FB to place the dial, then FR0/FT1 to arm, in that
order for the same reason. It writes what State() already knows how to read.
Everything else REFUSES, and that is the feature, not a shortfall. Only Flex and
Icom could even toggle split before, neither could set the transmit frequency,
and Yaesu, TCI and OmniRig have nothing at all. A refusal WSJT-X can report —
and act on, by falling back to Fake It — is worth far more than a success it has
no way to check.
Both paths are pinned: split reaching the rig as one armed call with the right
frequency, and a backend that cannot do it producing an error rather than RPRT 0.
IF reports the VFO "in use". In split that is the RECEIVE VFO while receiving
and the TRANSMIT VFO while transmitting — the backend took it as the receive VFO
in both cases. Everything therefore read correctly until the PTT closed and then
reversed, which is exactly how it was reported from a TS-590 on USB.
The IF frame has carried the transmit bit all along; parseKenwoodIF already
decoded it into f.TX. It was simply never consulted here.
This is not only a display fault. FreqHz is what a QSO is LOGGED on, so a
contact worked in split went into the log on the DX's frequency instead of the
operator's — wrong in the log, wrong in every ADIF exported from it, and
invisible until someone checked a QSO by hand.
The emulated rig in the test package can now be keyed, so the case is pinned
from both sides: verified failing without the fix (tx and rx exchanged) and
passing with it.
Every condition was joined by ONE global AND or OR. "2 m or 70 cm, in FT8, since
January" therefore had no expression at all: AND killed the two bands, OR let
every FT8 QSO through. The filter could ask simple questions and nothing else.
Rather than grow nested groups — a tree in the UI to answer something that is
nearly always "this field, any of these values" — the OR lives INSIDE one
condition and everything else keeps ANDing. Two operators, a comma-separated
value, no change to how the rest of the filter behaves.
Two edges that matter more than they look. An empty list matches NOTHING rather
than being dropped: dropping it would widen the result set, the opposite of what
someone typing a filter expects. And "is none of" wraps the column in IFNULL,
because raw SQL NOT IN discards NULL rows — a QSO with no band recorded is not
one of the listed bands, so it belongs in the answer.
SetMotorFollow went through SaveUltrabeamSettings, which tears the client down
and dials again. That is right when the transport changed and absurd for a
checkbox: the operator flipped tracking and watched the antenna disconnect and
come back, which on a remote controller is several seconds of a link that was
working perfectly.
The follow loop is a goroutine with its own stop channel and can be replaced on
its own — the connection underneath never knows. Only the two keys this call
actually changes are written, too: re-saving the whole block to change a
checkbox means re-normalising host, port, baud and bands, and every one of those
is a chance to alter something nobody asked to alter.
startUltrabeam now starts the loop through the same function rather than its own
copy. Two versions of "start the follow loop" drifting apart is how a step
change quietly stops taking effect.
It showed pattern, elements and Retract — everything except where the antenna
is pointed, which is the thing an operator changes most. Tuning it meant opening
Settings or moving the rig.
A button per band, taken from the bands configured in Settings rather than a
list invented here: a band dropped there cannot be clicked here. They point at
where people actually work, not the arithmetic centre — 20 m centres on 14175
and nobody lives there, 10 m spans 1.7 MHz of which the top half is empty.
Up and down move 25 kHz, which is also the finest tracking threshold: a smaller
nudge would be undone by the next poll while tracking is on. They work from the
ANTENNA's frequency, not the rig's, or walking the antenna across a band while
the rig stays put would be undone on the first press.
Tracking moved within reach because it is an operating decision — off to park
the antenna, on to resume — not something set up once. Its step only appears
when it is on: a threshold for something switched off is a question the operator
cannot act on.
MotorTuneKHz carries the CURRENT direction rather than resetting it. Both
controllers set frequency and pattern in one command, so a bare frequency would
silently drop a 180° or bidirectional pattern — a beam turning round is not an
acceptable side effect of clicking a band.
Club Log refuses with its ordinary web page rather than an error string, so the
new test reported a rejected login by pasting a 403 page — title, stylesheets,
navigation and all — into the status bar. The body now goes to the log, where a
real diagnosis happens, and the operator gets the one sentence there is to act
on: check the e-mail, the password and the logbook callsign.
Dropped the startyear=2099 filter with it, and that one matters more than it
looks. It was there to keep the reply small, but it was never verified against
Club Log's API — and Club Log answers an unrecognised request with the SAME 403
it uses for a refused login. An unverified parameter would therefore have made
every CORRECT password look wrong, which is precisely the failure this change
set out to end. The reply is capped at 4 KB and closed at once instead; the
status code arrives ahead of the body either way.
Band-opening detection had five entries in 0.24.5 — long paths, the PSK Reporter
feed, which bands, the densest sector, the region filter. Those are five steps I
took, not five things that happened to the operator, and the version read like a
work diary. Merged into one entry describing what the feature now does.
The 12 m mention went with them: it was added and removed inside this same
version, so it never existed as far as anyone reading this is concerned.
A PSK Reporter message says "X was heard BY Y". The watcher measured the
distance and bearing from the operator to X and stopped there, never asking who
had actually heard it — so a station 1400 km away, decoded by somebody in Japan,
counted as evidence. That proves the path from X to JAPAN and says nothing about
whether anything reaches this station. It is how a "2 m opening" came to be
announced out of a KX9X in the United States, and the operator was right to find
the callsign list absurd.
Reports are now kept only when the RECEIVING station is within 300 km. Far
enough to borrow the ears of a whole region — an opening reaches an area, not a
postcode, and waiting for a decode at one's own antenna is just working the band
— and close enough that the ionosphere doing something there is it doing the
same thing here. The transmitter still supplies the direction and the path
length, which is what was always wanted from it.
Also drops 12 m from the watched bands, at the operator's request: at this point
in the cycle it is open often enough that announcing it is a notification rather
than news, and a band that cries wolf costs the ones that do not. One fewer
subscription is also less traffic on a PC that pays for every message.
Two faults, both found from one field log: 70 000 decodes, 10 and 12 m plainly
open, nothing announced — and the two openings that DID fire named the wrong
direction.
evaluate() required EVERY distinct station in the window to fit inside one 90°
arc. That is the shape of a sporadic-E cloud and of nothing else. With 10 and 12
m open on F2 the reports arrive from all round the compass, the arc is 360°, and
the test can never pass — so the busier the band, the less likely an opening was
announced. Exactly backwards. It now finds the DENSEST sector instead, which
keeps the Es signature intact (a cloud still makes one direction dense) and lets
a real F2 opening be seen through the handful of neighbours who are always
there. Scattered-but-busy still reports nothing: the point was to stop demanding
global agreement, not to call every open band an opening.
Sector() averaged the two bearings arithmetically, so an arc crossing north was
labelled by its opposite: 353–61° averaged to 207° and went out as SW when it
was NE. Not a vague error — a reversed one, given to an operator who may turn a
beam on it. The detector has handled the 0/360 wrap since it was written; only
this label had not.
The only sign of a detection was a toast. It is gone in seconds, and an operator
who was tuning at that moment had no way back to it — for an event that lasts
hours and happens a handful of times a season, that is the wrong shape entirely.
The badge sits at the right-hand end of the status bar, before the clock: an
opening is a state of the WORLD, not of this station, so it belongs with the
time and the logbook rather than among the rig and amplifier chips.
Knowing when to go out was the real work. Nothing announces that an opening
ended, and the detector deliberately says nothing more about a band for 45
minutes after announcing it — right for a message, useless for a badge. So it is
inferred: every qualifying spot on that band pushes a deadline out, and when
they stop arriving the badge fades by itself. Fifteen minutes, comfortably more
than the detector's own twelve-minute window, so a quiet couple of minutes
mid-opening does not blink it off and on again.
Gated on the same distance floor the detector uses. Without that, a band busy
with short-range tropo would hold an Es badge lit indefinitely on spots the
detector itself had refused.
TestClublog checked that three fields were non-empty and returned "Ready — CALL
via EMAIL". Nothing was ever sent to Club Log, so a wrong password produced the
identical green message. It now signs in, through getadif.php because that is
the one authenticated endpoint that cannot change anything: a test must never
put a record into someone's log. A future start year keeps it from downloading
130 000 QSOs to prove a password, and a rejected login answers 403 before any
body arrives.
LoTW is two credentials doing two jobs and the button reported only the first.
Uploads go through TQSL signed by the certificate — the website password is
never involved — so a wrong one breaks nothing until the day confirmations are
downloaded, by which time nobody connects the two events. Both are now checked
and, more importantly, reported separately.
Also: the detector still refused 12 and 10 m while the PSK Reporter feed was
already subscribed to them, so those decodes were fetched and thrown away. The
rule was never "HF is out", it is "is an opening here an event" — 20 m being
open is the normal state of the band, 10 m opening is not.
Beside the rig and amplifier chips, before ON AIR, because it is the same kind
of fact they report: a link that is either up or it is not. Clicking it opens
the settings that control it, like the amplifier chips do.
Shown ONLY while the opening watch is on. A permanently grey chip for a feature
nobody enabled is clutter, and the bar is 28 px tall — every chip in it has to
earn its width.
Green once decodes are arriving, amber while connected but silent: those are
different states and an operator wondering why no opening has been announced
needs to tell them apart. The count itself is in the tooltip, not on the chip —
it moves several times a second on an open band, and a number flickering in the
corner of the eye is a distraction rather than information.
The detection shipped reading whatever the operator's cluster nodes happened to
carry. On VHF that is a few hundred skimmers, nearly all of them on HF: a 6 m
opening carrying 869 stations reached OpsLog as a handful of spots or none, and
Nexus flagged it on the same PC while OpsLog stayed silent.
internal/pskr subscribes to pskr/filter/v2/<band>/# on PSK Reporter's MQTT
broker. Every ordinary station running WSJT-X reports what it decodes, so the
difference is two orders of magnitude rather than a threshold. The feed's shape
suits us exactly: BOTH grids are in each message, so distance and bearing are
arithmetic — no lookup, and no DXCC-centre approximation, which is what made the
cluster path's bearings coarse. The geometry is injected from app.go so it stays
the same arithmetic the cluster path uses; two answers to one question is how a
bearing quietly becomes wrong.
Volume was the design constraint, not the protocol. Six metres open is thousands
of messages a minute and this runs on some very old PCs, so nothing is kept or
persisted in the watcher: each message is parsed, measured and handed on or
dropped, and the detector's existing window does the deciding.
And the part that was the real bug: enabling the watch now ARRANGES ITS OWN
SOURCES. It adds the two RBN nodes when missing and brings the feed up. A
feature that silently depends on sources nobody can know are needed does not
look unconfigured, it looks broken. Matched on host and port, not name, so an
operator who renamed theirs does not get a duplicate — which the detector would
read as twice as many stations, and announce an opening that is not there.
Turning it off leaves the nodes alone: they may have been wanted for their own
sake, and removing a node someone is using is worse than leaving one they are not.
The detector refused any path over 2400 km, reasoning that past a single hop the
bearing test stops meaning anything. That was wrong, and it discarded exactly the
openings worth announcing: Nexus flagged a 6 m opening at 5477 km that OpsLog
never saw, because the spots were thrown away before any test ran.
Multi-hop Es is ordinary on 6 m — 5000 km paths are common, 10000 km happens —
and it stays directional: a second hop leaves the sector the first one entered.
So the sector test, which is what does the real work here, holds perfectly well
at any distance. The ceiling was standing in for a judgement it could not make.
The floor stays at 500 km: a short 6 m contact is tropo or ground wave and says
nothing about the ionosphere. Both are now pinned by a test.
Both are ordinary Hamlib commands, and Nexus sends them around every transmit.
Refusing with RPRT -11 is permitted and a tolerant client carries on, but
nothing obliges it to — and while they sit in the log as "unimplemented" they
stay suspects every time something else goes wrong.
get_lock_mode answers 0, which is true: OpsLog never locks the dial against its
own clients. set_lock_mode is accepted and ignored, like set_vfo — there is no
lock to set, and failing would abort a client's transmit sequence over a setting
with no effect either way. stop_morse answers success because nothing is queued
here: CW is keyed by the rig's own keyer through the backend, never buffered in
this server, so "stopped" is accurate rather than polite.
Whether this is what Nexus is actually unhappy about is not established. It
removes two known irritants and two lines of noise from the log; if the trouble
persists, what remains in the log will be about the trouble.
It was sticky inside the scrolling list, and the rows went over it: a menu item
carries its own background and its own stacking context, so it wins against a
sticky sibling however high the z-index is raised.
The menu is a flex column now — a header that never scrolls, and the list
scrolling beneath it. Nothing to lose the fight with.
The first attempt laid 123 fields out on the page, sectioned by group. That
buried every other setting in the panel and was no easier to read than the flat
wrap it replaced — more surface, same problem.
One dropdown now, alphabetical, with a search box pinned at its top. Alphabetical
because any other order means hunting: the operator arrives knowing the name of
the field they want. The menu stays open while ticking, since picking eight
columns should be one visit rather than eight.
The chosen columns keep their place above it, in publication order — that list
answers "what will the page look like", which no catalogue can.
The catalogue held 23 hand-picked columns, so publishing a county, a satellite
pass or an award reference was simply not possible. It is generated from the
qso.QSO struct now — 123 fields — which also means a new ADIF field cannot be
forgotten here, as a hand-written list always eventually is.
Three keys were renamed to their ADIF names on the way (pota, sota, station).
An alias map keeps existing configurations publishing the same columns; without
it three would have vanished silently on upgrade, which is the worst way for a
setting to change.
The picker had to change with it: 123 chips in one wrap is a wall nobody reads
to the end of. It is sectioned by group, filtered as you type, and the chosen
columns sit on top in publication order — after picking eight out of a hundred,
the question stops being "what exists" and becomes "what did I pick".
The package doc said columns were curated so the operator's address could not
be published. That is no longer true and the comment now says so plainly: the
judgement moved to the operator, the default selection is unchanged, and nothing
is published that was not chosen.
Also collapses the changelog: four separate shared-CAT entries were one thing
from where the operator sits, and all of them were far longer than the one or
two sentences this project asks for.
Nexus sends set_ptt 0 about sixteen times a second, and every one of them became
an "xmit 0" to the FlexRadio — a write every 60 ms, for ever, saying nothing.
Repeating a state is not a request to change it. Only transitions reach the
radio now, and each is logged, so the next "it will not transmit" can be traced
to whoever asked rather than inferred from a wall of identical lines. The first
call always goes through: how the radio was left is not ours to assume.
This is not the whole of the reported symptom, and should not be read as such.
The log also shows "xmit 1" followed by "xmit 0" one to two milliseconds later,
off the 60 ms cadence — that is a genuine transition pair, so it still gets
through and the radio still unkeys at once. Those two commands come from the
client, not from here; the writes originate only in set_ptt, and there is no
loop in OpsLog that emits them.
Listen() succeeding is not the same as being reachable. OpsLog binds 0.0.0.0,
and Windows lets a second program bind the SAME port on the specific address
127.0.0.1. Connections to localhost then go to the more specific listener, so
every client reaches the other program while ours sits there having logged
"sharing CAT on port 4532" and never seeing a single connection.
Found with Nexus, which starts its own rigctld on 127.0.0.1:4532 and talks to
it. Neither side reports anything wrong: the operator gets a CAT timeout from a
daemon with no radio behind it, and OpsLog's log is silent because nothing ever
arrived. Three exchanges went into establishing that the connection simply never
reached us — the port table was what settled it, not the code.
So the server now dials its own port at startup and checks the connection lands
on its own accept loop. If it does not, it says which program will be receiving
the CAT connections and what to do. The counter it compares can only be raised
by our own accept loop, so a real client arriving during the probe makes the
check pass, never fail wrongly.
A client set to a RIG MODEL (Kenwood, Yaesu, …) pointed at the CAT-sharing port
speaks raw rig dialect: "ID;", "IF;". That is not rigctl, so it fell to the
unknown-command branch and got RPRT -11 like anything else.
The symptom hides the cause completely. RPRT -11 has no ';' for the client's
parser to terminate on, so it waits out its timeout and reports "reply
incomplete, got nothing" — a hard failure that reads as "OpsLog's CAT sharing
does not work", when it is one setting in the other program.
A frame ending in ';' with no space in it cannot be a rigctl command, so the log
now says what it is and what to set instead. Reported from Nexus, whose Hamlib
error named kenwood_transaction — the one word that gave it away.
cfdd24d shipped the "?;" tolerance with no changelog entry, against the
project's own rule. Placed before the CW entry: the link had to survive being
busy before anything keyed through it could matter.
CW over CAT never worked on a Kenwood. The KY implementation was written against
Elecraft's, which accepts a string of any length, so "KY OH5CX;" went out and a
TS-590SG answered "?;". OpsLog read that as "this radio refuses CW over CAT" and
told the operator to fit a serial keyer — advice that was wrong, and expensive.
The TS-590 manual is explicit: P2 has a fixed length of 24, blanks are filled
with spaces, and those spaces are not keyed. So the fix costs nothing on air; it
is simply the shape the command has. Elecraft stays variable-length, where
padding would key the trailing spaces as word gaps.
The semicolon is also gone from the allowed CW characters. It TERMINATES a CAT
frame, the manual forbids it in P2, and one in a macro would have closed the
command early and left the rest of the message to be read as commands.
Found from a log and a manual page, not from a rig: nobody here owns a Kenwood.
What is proven is the frame shape; that a TS-590SG then keys it still needs the
operator to confirm.
A Kenwood answers "?;" while it is busy, and the TS-590SG does it for a moment
after RX; — which is exactly when the poll resumes. One rejected IF; then tore
down the whole CAT link.
The code already knew this. Its own comment says a "?;" to IF; is "a transient
busy, NOT unsupported" and that latching it off "would read as lost the rig".
That reasoning was applied to the unsupported-command map and stopped there: the
call still returned an error, the poll loop still turned it into connected=false,
and the link still dropped.
What it cost was not cosmetic. WSJT-X keys through shared CAT, so it lost the
rig mid-sequence; Hamlib then sent "F 9223372036854775808.000000" - an
uninitialised 2^63 - which OpsLog refused and logged. The operator sees a
frightening frequency error whose actual cause is three lines earlier.
A "?;" is now sentinel-wrapped so the poll can tell "the rig declined" from "the
serial link is gone", and three consecutive ones are ridden out on the last
known state before the link is called dead. Under a second of tolerance: enough
for the rig to finish, far too short to hide an unplugged cable. A serial fault
is untouched and still drops immediately.
Tested against the emulated rig already in this package, with a hook that
answers "?;" on demand: the link survives inside the grace and still reports the
last good frequency, the count resets on recovery so a later busy spell gets the
full allowance, and a rig refusing forever is still reported as broken.
N0CALL is what WSJT-X transmits under when its owner never set a callsign. It
has a letter, a digit and an ordinary shape, so nothing rejected it: it was
spotted, coloured, counted as a new WPX prefix, and now that CQ grids are read
it would have put a grid into the worked index under a callsign nobody holds.
The obvious fix - adding it to looksLikeCall's reject list - was wrong, and the
test caught it before it shipped. That function answers "could this token be a
callsign at all", and the CQ grammar uses it to decide whether the word after CQ
is a modifier (DX, NA, a zone) or the call itself. Teaching it that N0CALL is
not a callsign made "CQ N0CALL JN36" skip a slot and return JN36. Shape and
policy are different questions and now live in different functions.
Chasing that turned up the real defect behind it: ANY unrecognised word after CQ
made the parser skip a slot, and a four-character grid passes every shape test a
callsign does. "CQ FOO JN36" returned JN36 as the sender - logged, spotted and
coloured as a station. A grid in the callsign slot is now refused outright.
An operator reporting "nothing happens for two or three seconds after I click"
was impossible to answer from opslog.log, because the first line applog writes
already sits inside startup(). Everything spent loading the binary and creating
the WebView2 environment happened before the log begins.
In one of the reported logs, startup() to window-visible is 251 ms end to end -
so whatever the wait is, it is not OpsLog initialising. It just could not be
proven, only asserted.
processStart is stamped on the first instruction of main. Two lines now bracket
the launch: how long was spent before startup() ran at all, and click-to-window,
which is the only number that matches what the operator experiences.
Finishes the half of this that was already computing on the backend and reaching
nobody. A Grid column in the Geo group, NEW GRID as a badge in Status, a filled
cell in the marker's own colour, and a filter chip.
new_grid joins lib/spotMarkers rather than getting colours of its own, so the
badge, the cell fill and the chip cannot drift apart - and the per-marker colour
setting will drive it with the rest from one table. Magenta: the last hue in the
categorical set not already spoken for, and one that does not read as a status,
because a new square is never urgent the way a new entity is.
The band map leaves it to the cluster, as it already leaves the prefix. The pill
is 22 px tall and its accent strip stops being readable past three segments.
A row carrying a new grid is no longer "dull", or the dimming would grey out the
one thing worth looking at.
The column is off by default, like the other Geo columns: it is only ever filled
for stations this receiver decoded over the UDP link, so for an operator who
does not run digital it would be a permanently empty column.
"No colour on worked" blanked the spot status as well as the worked-call flag,
on the theory that a spot bringing no novelty should stop painting entirely.
But the status is exactly what the cluster list reads to DIM a row. Blanking it
made isDull() fall through its "unresolved, never dim" guard, so every quiet grey
row came back at full brightness. The option meant to calm the list was the one
making it shout. It also forced a `muted` flag to exist purely so tooltips could
say that an empty status did not, this time, mean "entity not resolved".
It now removes the blue already-worked mark and nothing else, which is all it
ever needed to do: a worked entity already renders with no colour of its own and
is already dimmed. The flag, its two tooltip strings and the special-cased band
map styling all go with it.
The amplifier PUSHES status frames ("S0|state=…") on the same socket it answers
commands on, and it pushes them constantly once in OPERATE - power, SWR and
temperature all move while transmitting.
command() read exactly one line and took whatever arrived first as its answer.
One pushed frame therefore put the stream permanently one reply behind: every
later command read the PREVIOUS command's answer, and eventually one waited out
the 3 s deadline, failed, and dropped the connection. Hence a fresh TCP
connection and a fresh authentication every few seconds in the log.
The stall in transmit is the same defect seen from the other side: command()
holds the connection mutex across that whole dead wait, so SetOperate and every
other control queued behind up to three seconds of nothing.
It only appeared remotely and in OPERATE because that is when there is anything
to push - on a LAN with an idle amplifier the race hardly ever opens. Which is
why it did not do this yesterday.
readReplyLocked now reads until the R<id>| that belongs to the command, feeding
every frame it passes to parse() on the way - a pushed status is fresher than
the one we were about to ask for, so nothing is wasted.
authLocked used the same one-line read and worked around this by re-sending the
whole handshake, which is visible in the log as "auth reply=S0|state=IDLE
(try 1)" followed by a second attempt. It goes through the same reader now.
IOTA is an official ADIF field, and almost everything for it was already here:
the qso table has carried my_iota since the first migration, the insert and scan
handle it, and both ADIF import and export write it. The one missing link was
the station profile, so the reference had to be typed on every contact of an
island activation, or added afterwards in a bulk edit.
Migration 0025 adds the column; it joins my_sota_ref and my_pota_ref in the
profile, in the Station Information panel, and in the same stamp-if-empty block
that fills the other My* fields on a logged QSO.
Uppercased and trimmed on save. ADIF spells it EU-005, and an operator typing
"eu-005" would otherwise put a reference no award matcher recognises on every
QSO of an activation - the kind of mistake you only find months later.
AddQSO emitted qso:logged but never invalidated the cluster status snapshot.
The frontend did its part - it re-queried every visible spot two seconds later -
and ClusterSpotStatuses answered out of a snapshot built before the contact, so
it returned exactly the same "new band" as before. For ever, until an import, an
edit or a profile switch happened to invalidate it for another reason.
Reported twice: an E51 and then a ZD7 that stayed yellow on the band map with
the QSO plainly in the log. The first report was answered by fixing the
visibility gate, which was a real bug of its own and hid this one.
Confirmed against the operator's MySQL logbook rather than guessed: ZD7BG has
dxcc=250 on all eleven QSOs and 0 of 29579 rows lack a DXCC number, which ruled
out the missing-entity-number theory and pointed here.
Deliberately not invalidateAwardStats(): that also drops the award matrices,
which are expensive on a large log, and a contest run would pay for it once per
QSO. This index is a few DISTINCT scans and it is what the spot colours read.
Also fixes the new worked-grid query, which asked for a column named
"gridsquare". The column is "grid" - gridsquare_ext is a different one - so NEW
GRID could never have worked on either backend. Verified against the real
database: 12516 distinct grid|mode pairs.
RBN spotters report as "VU2OY-#" and cluster nodes as "DL1ABC-2". That string
went straight into the DXCC prefix matcher, which saw an unknown callsign and
gave up, so every spot came back with an empty continent.
The filter then matched nothing at all - and worse, silently: unresolved spots
are deliberately never dropped, because the status arrives a moment after the
row and filtering meanwhile makes the list flicker. So selecting AS left the
Europeans and the Americans exactly where they were, with nothing to say why.
A real callsign never contains a hyphen, so cutting at the first one is safe.
The panel had grown two shapes for the same kind of choice. Some filters were
checkboxes, some were chips, and New counties only was a checkbox duplicating a
chip - which I added, and which was the worst of it: a control that exists twice
is not more discoverable, it is one control the operator has to recognise twice.
The rule now:
SWITCH a behaviour that is on or off, and narrows nothing by a property of
the station: hide worked, group duplicates, the two display options,
LoTW users only.
CHIPS pick any number from a set; none picked means all. Status, mode,
spotter continent. Selected is solid, unselected is the same chip
faded, so the palette keeps teaching the colour code while switched
off.
Nothing appears in both shapes. The duplicate county checkbox is gone.
Spotter continent became a chip row: seven two-letter codes fit on two lines,
they read as a set the way Status and Mode do, and several can be picked at
once - which "EU or NA" needs and a dropdown cannot express.
Both Lock buttons now sit in the heading of the section they lock, instead of
floating between sections, and every multi-select section clears the same way
through the same heading slot. One section helper and one chip helper, so the
next filter cannot drift.
The panel was also entirely hardcoded English - Search call, Hide worked, Bands,
Status - against the project's own bilingual rule. All of it goes through t()
now, both locales.
rouggy