RI1FJL/MM resolved to Franz Josef Land while the expedition was still sailing
there, telling the operator they had worked an entity they had not.
The old behaviour was deliberate — the comment read "strict DXCC says no
entity, but the log should still show the operator's country" — and that is
wrong for exactly this reason. A home country on a maritime mobile is not extra
information; it is a false claim about where the contact happened, and it is
the kind of false claim that gets a QSO submitted for an award it cannot win.
Trailing only. A LEADING "MM" is the Scotland prefix and "AM" is Spain, so
MM0ABC and AM5X keep their entities — getting that wrong would be a far larger
error than the one being fixed. /P, /M and /B are unaffected: a portable
station is still ashore.
In the cluster the column says "Maritime mobile — no DXCC" rather than going
blank, because blank is what an UNRESOLVED spot looks like and the two mean
opposite things — one is "we don't know yet", this is "there is nothing to
know". Display only: the QSO's own Country stays empty, since that field holds
a DXCC entity name and there is none.
ADIF defines CNTY as "STATE,COUNTY" — "GA,BARROW". OpsLog wrote the bare county
name, which a receiving logger cannot resolve: county names repeat across
states, and there is a Washington County in thirty of them. The award engine
here was never affected, since it reads the columns rather than the ADIF; the
damage was to every file we hand to someone else.
One writer covers everything — writeRecord — so this fixes file exports and the
LoTW, Club Log, HRDLog and QRZ uploads together. MY_CNTY gets the same
treatment.
The county alone is still written when no state is known: a bare name is worth
more than nothing, and inventing a prefix would be worse than either. A value
that already carries a comma passes through untouched, so re-exporting an
imported record cannot double the prefix.
Import is the mirror: "GA,BARROW" fills both columns, and a file carrying the
bare county — as OpsLog's own older exports do — still imports unchanged. The
state parsed out of CNTY only fills a blank STATE, never overrides it: STATE is
the dedicated field and the more specific statement.
Puts "F4BPO is on air 14,074,000 FT8 IC-7300" on hrdlog.net's front page while
the station is operating, which is what HRDLog's own "Automatic HRDLog ON AIR"
setting does.
The endpoint and its field names come from HRDLog's own library
(github.com/iw1qlh/HRDLOG-net-library, HrdProtocol.SendOnAirAsync): OnAir.aspx,
with Frequency in Hz, Mode, Radio, Callsign, Code and App. Read rather than
guessed — an invented endpoint would have produced a switch that silently did
nothing.
HTTPS where that library uses plain HTTP: the upload code is a credential and
has no business crossing the network in clear, and the sibling NewEntry
endpoint on the same host already serves TLS.
A heartbeat every two minutes, not a change notification — HRDLog drops a
station from the list when it stops hearing from it. Silent when switched off,
unconfigured, or when the rig reports no frequency: announcing 0 Hz would say
the operator is on air on nothing. Failures are logged, never toasted; a
broadcast the operator did not ask for at that instant must not interrupt them
every two minutes on a flaky link.
Its own switch beside auto-upload rather than folded into it: this is a live
status and needs the rig readable, not a QSO.
compactH was 158px, "tuned so the compact entry strip fits in a single row".
A constant tuned against a layout stops being true the moment the layout
changes, and this one outlived a strip that had since shrunk — leaving about
70px of empty window under the fields.
The frontend now measures what it rendered and asks for that height, watched by
a ResizeObserver so a strip that wraps at a narrow width is followed too. The
topbar is added as its declared h-8 rather than measured, since it is fixed.
Bounded in the backend: a measurement of zero — a layout not yet painted —
must not collapse the window, and the call is ignored unless compact is on so
nothing can shrink the normal window. Rounded to whole pixels so a sub-pixel
reflow cannot start a resize loop.
The same pair already sits in the status bar, where it is 10px and several
operators reported not being able to read it. Repeated under the compass at a
size that can be read across a shack.
Clickable, like the ones in the status bar: a heading you can see and not act
on would be a step backwards from what is already there. Disabled and dashed
when no station is entered, rather than showing a heading to nowhere.
Comment and Note moving onto one line left the right column two rows shorter
than the left, and this fills it: county, both zones and the ADIF entity
number. All four are filled by the lookup and were only visible after opening a
tab — the wrong place for values an operator wants to SEE are right before
pressing Log.
County is a name, not a code ("St. Tammany Parish"), so it takes the flexible
width and the three numbers get fixed narrow boxes.
Cleared numeric fields store undefined, not 0. Zero is a real DXCC number and a
real zone, so an empty box has to stay empty rather than assert something the
operator did not type.
State stays up on the geography line beside QTH and the locator, which is how
the lookup fills them and how they are read.
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.
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".
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.
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.
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.
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.
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 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.
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 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.
rouggy