The columns were the intersection of the award's bands with a fixed list
that ended at 70cm, so a band the award genuinely covers could not appear
whatever it said. DDFM is worked well into the microwaves and had no 23cm
column, and nothing anywhere would have produced one.
The intersection is now taken against every band in frequency order, the
same list internal/award already sorts its own band counts by. The classic
HF-plus-2m-and-70cm set stays as the fallback for an award with no band
list and no contacts yet — the full list would be twenty-nine columns of
mostly nothing.
Reported from a station running an IC-7850 over USB: with split engaged,
turning VFO B moved VFO A slightly. OpsLog writes nothing to that radio on
its own — but it shares it, and what it was sharing was wrong.
Hamlib's 'f' means the VFO IN USE. RigState follows ADIF, where FreqHz is
where we TRANSMIT, and the two are the same number until split is
engaged — so the adapter handed FreqHz over unchanged and every client
asking for the dial was given VFO B. A client that reads the dial and
writes it back, which is what WSJT-X and its like do, then wrote VFO B's
frequency into VFO A. Hence a shift the size of the split offset, and
hence 'it did not do this before': it only happens with split on.
get_split_freq ('i') already answers the transmit frequency and is
untouched. The one-line rule is lifted into shareRXFreq with a test that
includes this case, the simplex case, and a backend that reports split
without ever filling in the receive frequency — which would otherwise
answer a client with 0 Hz.
Two faults, and the first was a design mistake of mine.
The choice was written only as the award override, to keep the imported
CNTY as a record of what HAMLOG said. But CNTY is what the comparison
READS, so the contact went on disagreeing for ever: settle a hundred
rows, run the comparison again, get the same hundred back. The reasoning
was about preserving evidence; the effect was a button with no visible
consequence anywhere, which is indistinguishable from one that does
nothing. This is the operator's own log, and correcting a field in it is
the point of the exercise. The district now lands in CNTY as well as in
the award reference.
And the settled rows stayed on screen, which made the same button look
broken a second time. They are dropped as they are applied — locally,
rather than by re-running the comparison, which reads the whole log and
would be seconds of silence on a remote database to be told what is
already known. The agree/disagree counters follow.
Reported by VK4DX with the case that names itself: YB confirmed on 20m
digital, painted blue, because one unconfirmed YB station had also been
worked on that slot.
The ladder ran call_c > call_w > dxcc_c > dxcc_w, so a callsign worked and
not confirmed beat an entity CONFIRMED on the same band and mode. The grid
answers 'what do I still need here', and a confirmed entity needs nothing
whoever was worked afterwards — so the order is now call_c > dxcc_c >
call_w > dxcc_w.
Two things made it easy to get wrong, and both are fixed rather than
merely corrected. The code was a run of assignments where the later test
silently overwrote the earlier, so 'call worked' erased 'entity
confirmed'; it now takes the maximum. And the rule lived inside a scan
loop where nothing could reach it, so it is lifted into bandStatusCode
with a table test — including this exact case, and one that fails if
anybody reorders the constants.
The comparison could show two hundred contacts where the log and the
database name different districts, and leave the operator with nothing to
do about any of them but open each QSO and edit it by hand.
Now each row carries the two values as buttons: click the district you
keep, then apply. There are shortcuts for keeping one source everywhere,
and applying is a separate act — clicking through two hundred rows with
each one written as it is clicked would make a slip permanent before the
reading was finished.
The choice is written as the contact's AWARD REFERENCE, not over the
imported CNTY, and that distinction is the point. CNTY is what the
downloaded log said; overwriting it would destroy the evidence the
comparison runs on, and the next comparison would agree with itself and
prove nothing. The override is the operator's decision, it is what the
award engine counts, and it beats both sources. So the log keeps saying
what it said, the database keeps saying what it says, and the contact
counts for the district that was chosen.
The buttons show the districts themselves rather than a tick box: someone
arbitrating between RO-19 and KO-05 should be picking a value they can
read, not remembering which source a checked box stood for.
v0.26.15 had already shipped, so its entry about setting the source by
hand in ExpertSDR3 goes back exactly as released — it describes the
version operators are running. What replaces it belongs to the version
that carries the change.
The specification settles what a night of experiments could only guess at.
TRX takes an optional THIRD argument naming the signal source — tci, mic1,
mic2, micPC, ecoder2 — and TCI 2.0 says it plainly: 'The signal for
transmitting is always taken from the microphone selected in the
ExpertSDR3. If a third-party software connected via TCI wants to transmit
its audio signal, you must specify the third argument - TCI.'
Without it the radio sends no chrono at all, whatever the mode. That is
what the SSB attempts ran into, and what was misread here as 'digital
modes only' — the mode was never the rule, the missing argument was.
So OpsLog says it, following the 'To radio' device: 'tci' when the voice
keyer owns the transmission, nothing at all otherwise, which leaves the
operator's own microphone alone for every other PTT. Nobody has to find
that setting in ExpertSDR3 and set it again for every mode, which is how
it is remembered there.
Two more things from the same document. A chrono with no audio ready is
now answered with silence rather than left unanswered — the vendor calls
that preferable. And the receive stream declares float32 and two channels
instead of trusting the defaults: they are the documented defaults, but a
default is something another program sharing this radio can have changed,
and a stream in an unexpected format is heard as noise rather than as a
mistake.
The RDA and Elecraft SWR entries move with it: both were written after
v0.26.14 was tagged, so they ship in the version that carries them rather
than in the one already on operators' machines.
Elecraft's release note settles it: SW; returns the most recent reading in
transmit or TUNE as three digits in tenths of a ratio — SW023 is 2.3:1,
and SW999 is the 99.9:1 it reports instead of infinity.
This asked for four, so every answer failed to parse and the bar stayed
empty for the whole transmission. A tester saw exactly that: no SWR at
all, which reads as an unsupported radio rather than an off-by-one.
SW also comes out of the probe list. It is known now, and asking again
mid-transmission costs a round trip on the link the carrier depends on.
Two faults, one behind the other.
RDAPanel is nested inside SettingsModal so it can read its state, and it
was written as <RDAPanel />. A nested function is a new component TYPE on
every render: React cannot know it is the same panel, so it unmounted the
tree and mounted a fresh one — and a fresh scroll container starts at the
top. It is called now, like the other panels, which produces the same
elements in place and never disturbs the scroll position.
What it was reacting to should not have reached it either. The PSK
Reporter and grid-cache poll ran every three seconds from wherever you
were in Preferences, re-rendering the whole dialog for a count shown only
on the cluster section. It now runs while that section is open, and the
one-time loads it was sharing an effect with have stayed where they were
rather than refetching on every click in the sidebar.
The visible result: a hundred contacts to correct can be read from top to
bottom.
The 0.26.14 block described the satellite dropdown being clipped, then
not following the list as it was edited — both repairs made to a feature
in the same block, on a machine no operator has ever seen. An entry only
earns its place if a reader could have met the problem: the feature is
announced once and the fixes are simply part of it.
The launch story was told four times over — the startup log, the profile
folder, the fixed-version runtime, the Edge blocker. They are one answer
to one question, 'it does not start', and read better as one. Same for
the two RDA entries: one list, one repair.
The path had lost its backslashes and read LOCALAPPDATAOpsLogWebView2 —
not something anybody can follow to a folder they are being told they
may delete when it is the thing that is broken.
Confirmed on the machine that started this: an 'Edge blocker' utility was
in the way, and unblocking Edge fixed the launch.
Those tools work by registering a Debugger entry under Image File
Execution Options for msedge.exe and msedgewebview2.exe, so Windows
refuses to run the process. The runtime is installed and registers its
version quite happily — which is why the logs showed WebView2 present —
and then never starts. OpsLog draws its whole interface with that engine,
so the window never opened: no error, no crash, a process sitting there
doing nothing.
That entry is read at startup now and said plainly, in the log and on
screen, with the one thing that helps: unblock Edge in the tool that
blocked it. Reinstalling OpsLog cannot fix a machine in this state, and
that is where an unexplained silence sends people.
Also logs the Windows build and which Edge policies are set — value names
only, never their contents: a policy key holds URLs and account names
that are nobody's business here.
'The Evergreen installer will not install either' moves the problem out
of OpsLog's reach: the runtime is a Windows component, and on a managed,
offline or otherwise locked-down machine it may simply refuse.
Microsoft publishes the same runtime in a FIXED VERSION form — a folder
an application carries and points at, needing no installation and no
administrator. That is exactly this case, so OpsLog now looks for it
beside its own executable and uses it when it is there. The versioned
subfolder the download unpacks into is handled, because asking someone to
flatten it by hand is one more step to get wrong on a machine where
nothing starts.
No setting for it: that would be a question asked of the one operator
least able to answer it. The folder is either there or it is not.
The startup log also records the Windows build — the first thing anyone
diagnosing a runtime that will not install is going to ask for.
His log reaches 'entering wails.Run' and stops: WebView2 is installed
(120.0.2210.91) and never hands control back. A hang, not a failure —
there is no error to report, so the two remaining causes have to be
addressed rather than diagnosed.
The profile folder is now named explicitly, on the LOCAL disk. Wails
defaults it into the ROAMING profile, which on a managed account can be
redirected to a share; a WebView2 profile on a share that is slow or gone
does not fail, it hangs. Naming it also gives someone a folder they can
be told to delete, which is the fix when the profile itself is corrupt.
And a marker is written before the window is attempted, removed when it
paints. Finding it at the next launch means the last one never got there,
so that launch runs with GPU acceleration off: a WebView2 that cannot get
on with the graphics driver hangs exactly like one that cannot start, and
this is the single lever that separates them — at no cost on machines
where it was never the problem.
His startup.log stops after 'data dir ok', which rules out the two faults
already covered and leaves the window creation itself — where a missing
WebView2 runtime lands, sometimes as a silent exit rather than an error
anyone can print.
So the runtime's version is read from where it registers itself (both
hives, and the 32-bit view where a per-machine install usually lands) and
written BEFORE the window is attempted: 'WebView2: not found' answers the
whole question in one line. Breadcrumbs now also mark entering wails.Run,
reaching OnStartup, and the window painting — which places any launch
that produces nothing between two known points.
Reported from a Windows 10 machine: the process appears, no data folder
is created, nothing starts. There was nothing to read because the only
log OpsLog has lives inside the folder that was never created.
Three exits happen before any window or log exists, and all three were
silent. Another instance already running — correct to refuse, since two
would fight over the rig, but indistinguishable from a crash. The data
folder unwritable — it is created BESIDE the executable, so a copy
dropped into Program Files is refused by Windows outright. And wails.Run
failing, which is where a missing WebView2 runtime lands; its error went
to println, which in a GUI-subsystem program goes nowhere at all.
Each now writes to %LOCALAPPDATA%\OpsLog\startup.log — a folder Windows
guarantees the user can write to, whatever OpsLog was installed into —
and shows a message box naming the fault and what to do about it.
TWO FAULTS, ONE SYMPTOM — 'it refreshes ten times a second and the
buttons cannot be pressed'.
Preferences is a child of the main view, so every cluster spot, CAT push
and decode re-rendered the entire panel. On a busy evening that is
several times a second, and the panel is large enough that the rebuild
outlasts the gap between them: buttons missed their clicks because the
element under the pointer was replaced between the press and the release.
It is memoised now, and the callbacks App hands it hold their identity —
without that the memo compares unequal every time and buys nothing.
The dropdown menu was an absolutely-positioned child, so it was clipped
by whichever scrolling or overflow-hidden box it sat in: the satellite
list showed one entry of eight. It is portalled to the body now,
positioned from the field's rectangle, re-measured while open, and opens
upward when the field is near the bottom of the screen — which is exactly
where these fields tend to be.
SATELLITES: the field read the list once, when the details panel first
mounted — which is at startup. A list saved in Preferences afterwards
therefore did nothing until a restart. It comes from App now, which
already reloads the lists when Preferences close.
RDA COMPARE: a failed comparison wrote its error into the message beside
the FILL DISTRICTS button, a row above — the error appeared under a
button nobody had pressed while the one that had been pressed showed
nothing, which reads as 'the button does nothing'. It has its own message
now, and reports the two results that look like silence: no disagreement
at all, and no Russian contacts to compare. Both buttons say what they
are doing while they do it, and the comparison logs before it starts
reading — on a remote MySQL that read is seconds of quiet.
SAT_NAME is compared character for character by the awards and by LoTW:
AO-91 and AO91 are two different satellites to everything downstream, and
typing it afresh on every pass is how one of them ends up in a log. So
the station keeps its own list (Preferences → Lists → Satellites) and the
field offers it, alphabetically — while still accepting anything typed,
because a bird worked once and never added to the list must not be
impossible to log.
Not seeded with a shipped list of two dozen birds: an empty list means
this station does not work satellites, and filling the dropdown with
names nobody here has heard makes the field harder to use, not easier.
Also fixes the RDA district comparison: its conflict list was capped at
about six visible rows of a list holding up to two hundred, in a panel
that would not scroll to show the rest, and nothing in it could be acted
on. Taller, scrolling, and a callsign opens the contact.
Three wide buttons for something most radios cannot vary was noise, and
they pushed the fields below into whichever grid column came next — the
panel looked shuffled.
Now: a dropdown, shown only when the brand has more than one way in. A
Yaesu is reached over USB and that is the end of it; a control offering
one entry that cannot be changed is a decision that is not one.
Brands: OmniRig first — it is the one that works with any radio, so it is
where someone who cannot find their rig should land — then alphabetical.
Kenwood and Elecraft drop the proprietary-network entry: neither is
implemented and neither is planned, and naming a road that goes nowhere
is only useful when someone might reasonably look for it.
The standalone checkboxes (protocol log, DTR/RTS) take a full row instead
of half of one, which is what was breaking the alignment.
The backend list mixed two different questions. 'Icom (USB)' and 'Icom
(network)' were separate entries; Kenwood and Elecraft hid the same
choice in a field further down; and Flex, TCI and OmniRig sat in the same
list as if they were the same kind of answer. An operator picks a radio
and then says how it is plugged in, so that is what the panel asks, in
that order, and the two answers together choose the backend.
Each brand offers only the connections it has, and a brand with one way
in still shows it, greyed: 'there is no choice here' is an answer and an
empty space is not. The stored backend names are unchanged — 'icom-net'
is still 'icom-net' — so a settings file written by an older build keeps
working, and brand+connection are DERIVED from it rather than held
alongside it, which is what keeps them from drifting apart when something
else writes the backend.
USB, RS-232-to-Ethernet, and the radio's own network protocol are three
different things, so they are three entries in one dropdown — and the
transport is now a stored setting rather than something deduced from
which field happened to be filled in. The old rule (a host wins whenever
it is not empty) is invisible from the settings page: someone who typed a
host months ago and later set a COM port had a radio that never answered
and nothing on screen to say why.
The third entry is named and refused, with the reason. It is a session
with its own framing and login, not the CAT byte stream over a socket, so
it has to be written per radio and against one — and a K4 owner reading
this list should be told that, not left wondering whether the empty
address field was the problem.
The upgrade reads an older install from what it has: a configured host
means the bridge, which is what the previous code used it for. Pinned by
a test, including the case that matters after the fact — choosing USB
with a stale host still stored gives the COM port.
The network option IS implemented — the same ASCII CAT over TCP instead
of a cable, for a ser2net bridge, an Ethernet-serial adapter, or a radio
exposing its raw CAT port. What was wrong is how it was offered: the COM
port and the network address sat side by side with nothing to say that
the address wins whenever it is not empty.
Worse, the example address read 192.168.1.50:4532. That is Hamlib
rigctld's port — a different protocol, and the one OpsLog SERVES under
'Share CAT'. Anyone copying the example was pointing the radio link at
OpsLog's own server.
Now one choice, then the fields that belong to it. And when the far end
answers something that is not the radio's CAT, the error says that rather
than 'check the baud rate', which over TCP is advice about a setting that
cannot be the cause.
F3 listed every award that existed, enabled or not, followed or not — so
a station chasing three of them assigned references from a list of twenty
and had to know which of the twenty mattered.
It now applies the same two rules the Awards tab already uses: an award
switched off in the editor is not a candidate for anything, and when a
selection of followed awards exists, only those are offered. An empty
selection still means all of them, so nobody loses a picker by never
having chosen.
A station with a switch knows something the log does not: which antenna
is actually connected. The working conditions hold what was PLANNED for
the band, and stay right until the operator throws the switch — after
which every QSO keeps claiming the other antenna.
Optional, and off by default: a station that names its antennas
differently in the two places would otherwise find its log quietly
rewritten. The name written is the one configured on the device, since
that is the name the operator gave it and the one they will look for.
WHICH PORT is the real problem, and the reason this is not a one-liner.
The switch has two, the radio has two jacks, and the QSO went out through
one of them; naming the wrong port's antenna is worse than naming the
band default, because it looks authoritative. The radio's own TX antenna
selection decides, and the jack-to-port wiring is a setting — it is the
station's cabling and neither device can report it.
When the port cannot be told — a transverter jack, a rig that reports
nothing, both switch ports live — nothing is written and the band default
stands. Silence beats a confident guess in a field nobody re-checks.
Reported: OpsLog shows STANDBY on a PowerGenius XL that is operating, and
pressing the button 'puts it in Operate' — because it was already there.
The amplifier's status frame has no operate= field. The direct GSCP
client only looked for one, so Operate stayed at its zero value until the
operator pressed the button: at startup OpsLog was not reading the state
wrongly, it was not reading it at all.
The live state is in the frame under 'state', and the FlexRadio side of
this same amplifier has been reading it that way all along — anything but
STANDBY/OFF means the amp is in line, with IDLE meaning in line but not
keyed. The GSCP client now does the same when no operate= is present.
An unknown state leaves the flag alone rather than guessing: claiming
STANDBY on an amp that is in line is precisely the error being fixed, and
it invites the operator to switch on what is already on.
Reported from a multi-monitor station: window.json held x=-7680 and the
window opened where nobody could see it, with no way back short of
editing the file — which nobody knows to do.
The guard existed but asked the wrong question. It tested the position
against the VIRTUAL SCREEN, the rectangle spanning every monitor, and
monitors rarely tile that rectangle: a wide screen beside a tall one, or
one mounted higher, leaves gaps inside the box that belong to no monitor.
A window in a gap passes a bounding-box test and is invisible. The test
now walks the monitors themselves, through EnumDisplayMonitors, and uses
each one's WORK area — a title bar under the taskbar cannot be dragged
either.
A position that is genuinely lost is now MOVED onto the nearest monitor,
keeping the window's size. Handing it back to Windows lost the size too
and dropped the window on the primary screen wherever Windows chose.
The arithmetic is in screenclamp.go with no Win32 in it, and tested
against the reporter's four-monitor layout and against a gap between two:
this fault is invisible by definition and cannot be reproduced without
the reporter's screens, so a table test is the only place it can be held.
The layout is also logged at every start, since the first question after
'OpsLog does not open' is what the screens looked like.
Two things reported together, both about a list that fights back.
The GRID froze nothing: every spot landed at the top and pushed the rest
down, so a few rows in, the callsign under the pointer had moved by the
time the click arrived. It now stops redrawing as soon as it is scrolled
away from the top and says how many spots are waiting; reaching the top
again, or clicking the notice, releases it. The arrivals are counted by
finding the frozen top row in the live list rather than by comparing
lengths — the list is a ring buffer, so once it is full a length
comparison would report nothing new for the rest of the evening.
The COMMAND BUTTONS were capped at 120 characters. A DXSpider filter
naming the prefixes an operator wants runs well past that, and the field
just stopped accepting keystrokes: the command was saved truncated with
nothing to say why. 500 now, with the full text in the tooltip since the
box cannot show it.
The transmit meters were read on k.tx, which records only that OpsLog
keyed the radio. An operator using the front-panel PTT, a footswitch or
the mic button therefore had a panel that believed the rig was receiving
— and since the power and SWR bars are read only while transmitting,
they were never read at all. IF carries the radio's own transmit bit;
that is what decides now.
The meter probe logs RAW answers rather than parsed numbers, and asks a
wider set (SM, SMH, BG, SW, PO, TQ). A command answering in a shape we
did not expect is the interesting case, and parsing hid it behind the
same dash as a command the radio refused — which is what still stands
between us and a working SWR reading on a K3.
FT8 decodes made on 14.095 were labelled 2190 m. That band is 135.7-137.8
kHz, and every affected decode's audio offset plus 136.1 kHz lands inside
it — while the ones shown with no band at all land just above 137.8. The
decodes were being stamped with another instance's dial.
WSJT-X refuses to start a second instance without --rig-name, so its ids
differ and keying on the id worked. MSHV has no such rule: both copies
call themselves 'MSHV', so the LF instance's Status overwrote the HF
one's dial, T/R period and mode.
Instances are now identified by their sending socket as well as their
name — the socket is stable for as long as the program runs, which is
exactly the lifetime this has to hold over. A second application claiming
an id already in use is shown as 'MSHV #2' and says so in the log, so the
decodes panel can still split them.
This also fixes replies: a Reply was addressed to whichever copy sent
Status last, which on a two-instance station is a coin toss.
A station new on this band AND in this mode is one status, 'new-band-mode',
and the badge table has an entry for neither half. The lookup returned
nothing, so those rows showed only their grid or prefix badge — and with
NEW/BAND/MODE selected, a row whose visible badges were LOC and PFX read
as the filter letting through things nobody asked for. It was not: the
row belonged there and the panel failed to say why.
catsOf has always split that status into its two categories for filtering.
The badges now do the same on screen.
Both are the same bug. ReadState returns early while transmitting — the
rig answers '?;' to IF; then, and treating that as a fault used to drop
the link — but that early return also skipped the panel update and the
meter read.
So the panel believed the radio was still receiving. Pressing MOX again
therefore sent ANOTHER transmit command instead of RX, and the K3 stayed
keyed, exactly as reported. And the power and SWR bars were only ever
read at the one moment they mean nothing.
Reading meters while transmitting needs one more guard: a '?;' then says
when the question was asked, not what the radio supports, so the
unsupported-command memory is suspended for that read. Without it, one
badly timed refusal would silence a meter for the rest of the session.
Adds RIT/XIT offset control (±10/±100 Hz, offset shown), a 4.0 kHz filter
button for FT8, and logs the K3's icon word when it changes: there is no
command for 'is the ATU in line', the reference says the switch functions
show up as icon changes, so an operator toggling the ATU while watching
the log will name the bit and the button can then light up honestly.
Dragging a four-pixel slider to change the power by five watts is a fussy
gesture, and the Flex and Yaesu consoles have had the wheel for a while —
an operator moving between them expects it.
React registers onWheel as PASSIVE, so preventDefault() there is ignored
and the panel scrolls under the pointer while the value changes; the
listener is attached natively instead, with the live values read through
refs. Both existing panels solved it the same way, so this is a third
copy turned into one shared component -- used by the new console only.
The other two are left alone deliberately: they work, they are in daily
use, and their styling differs in ways a merge would have to guess at.
Power steps 5 W a notch, matching the K3's own coarse step.
SWT20 was written from memory of the reference rather than from Table 7,
and 20 is not an ATU switch at all — it would have pressed something else
on a real K3. An operator read the table out for us: switch 19 is the ATU
row, TAP for a tuning cycle and HOLD for tuner in line or bypassed.
Adds the HOLD as its own ATU button, because on the radio they are two
different things: tuning is a cycle you start, bypassing is a state you
leave it in.
Power takes 0-110 W on an Elecraft, per the reference — a K3 makes a
little over its rated output — while a Kenwood keeps 200.
The list is a ring buffer that held a thousand spots, and on a busy
evening a thousand arrive in a couple of minutes. So the buffer decided
how long a spot lived, and the spot LIFETIME setting never got the chance
to expire anything: fifteen minutes meant nothing when the oldest spot
was pushed out after two.
Now settable (Preferences → Cluster, beside the lifetime, since between
them they decide the same thing), 100 to 10 000. The ceiling is a real
limit rather than a round number: every spot is matched against the
worked index and the alert rules, and is a row the cluster grid and every
open band map re-render.
Reading the cluster means running down dozens of lines, and a single
click did the whole job — QSY, mode, callsign — so every line looked at
dragged the radio with it. One stray click while reading took the
operator off the station they were working.
Looking and going are two different intentions, so they are two gestures
now. The band map is unchanged: clicking a spot there is already a
deliberate act, not a way of reading a list.
Reported from a real FTDX101, and each one is a different kind of wrong.
MIC GAIN was read and written through the 0-255 scale the audio gains
use, but the CAT reference gives MG000-100. A rig set to 80 therefore
showed 38, and moving the slider sent 204 — outside the range the radio
accepts, so it refused the command and the slider sprang back. That
snap-back was the symptom; the scale was the cause.
POWER was capped at 100 W by the slider, not by the radio. There is no
CAT command for 'how much power can you make', so the ceiling comes from
the model name, with the rig believed if it ever reports more than the
table expects — it has just proved what it can do.
NAR is the narrow IF filter, and on a rig that does not implement NA the
button showed a state the radio never gave and did nothing when pressed,
which reads as a fault in the radio. Now shown only when the rig answers,
with a tooltip saying what it is.
Also: the frequency readout steps the Hz digits under the wheel, not just
the kHz ones. Zero-beating a CW signal is a few tens of Hz and it was the
one move the display would not make. And the split chaser is CW-only —
its marker comes from a CW skimmer.
An operator reading a cluster page sees 28500 and wants to be there. The
hands are on the callsign field; reaching for the frequency box, or the
mouse, is the part that loses the station. So the call field takes a bare
number on Enter: kHz for a frequency, or a band on its own.
Ambiguity resolves to the band on purpose -- 40 is 40 m, not 40 kHz --
because neither of those kHz values is anywhere a radio tunes, and it
reads the way an operator says it. Anything with a letter in it is a
callsign and behaves exactly as before; a number that is neither a band
nor a plausible frequency does nothing at all.
Bands go through the ordinary band change, so the antennas, the per-band
power table and the outbound integrations hear about it as they would
from the dropdown. Also adds 4 m to the QSY table, so a band that can now
be typed is a band that has a frequency to go to.
It filled the window: on a wide screen a slider ended a hand's width from
its own label and the panel stopped reading as one instrument. Capped and
centred like the Yaesu, Icom and Flex consoles, grouped into Meters,
Levels and Receive cards, with the level sliders in two columns.
Also opens the 0.26.12 block: the TQSL logging and this console were
written after v0.26.11 was tagged.
So the tester can exercise everything in one session instead of one
control per build: RF and mic gain, squelch, preamp, attenuator, NB, NR,
AGC, filter width, antenna, RIT/XIT with a clear, and the keyer speed.
The analogue scales differ between an Elecraft and a Kenwood — RF gain
000-250, mic 000-060, squelch 000-029 against 0-255 — so each is mapped
through its own full scale and shown as a percentage. Using one rig's
range on the other silently halves or doubles every setting.
Antenna only appears when the radio answers AN: a K3 without the internal
ATU has one socket, and a switch that goes nowhere is worse than none.
The Elecraft backend already existed; what was missing was somewhere to
operate the radio from. This adds the panel, on the Kenwood-dialect
client the K3 already speaks, in a tab of its own beside the Yaesu and
Icom consoles.
Scope is the six controls asked for and nothing else. Every extra command
added without a radio to test it against is a control that may or may not
do what its label says, and a K3 exposes dozens.
No K3 was available while writing this, so the two halves are treated
differently. The setters are the commands the reference documents
unambiguously and whose effect is visible and reversible (PC, AG,
TX/RX). The meters are the opposite: their scaling differs by model and
firmware, so the raw answers are logged next to the power setting, the
panel says the scaling is provisional, and an unmeasured SWR shows as
'—' rather than as a perfect 1.0 — a good match on an antenna nobody
measured is the reading that costs a radio.
ATU tune sends SWT20 (the K3 front-panel tap) and logs exactly what it
sent, so a wrong mapping names itself instead of leaving an operator
guessing which button OpsLog pressed.
'No QSOs processed' (exit 8) covers already-uploaded, out-of-certificate-
date-range, and a station callsign that does not match the location being
signed with -- TQSL's message does not say which. An operator whose QSO
was refused and then accepted after a round trip through another logger
is reporting a difference in the record itself, and the temp ADIF is
deleted the moment TQSL returns, so that difference could not be seen.
Logged on any non-zero exit: the record verbatim, the exit code and the
station location. It is QSO data; the key password is not logged.
Withdrawing auto-call added a runtime guard and removed every control.
The stored preference was left alone, so 'enabled: true' still sits in
localStorage on the machines that had it on -- and any build without the
guard reads it and keys the transmitter for a feature that no longer has
a switch anywhere in the interface.
loadAutoCall now switches it off and writes it back the first time it
reads it, so the disarming survives a downgrade or a reinstall. Also
drops the dead auto-call state left behind in the settings modal.
A withdrawn feature that keys a radio has to be disarmed where it is
remembered, not only where it runs.
Club Log wrote to this station about 167 requests in four minutes and a
coming IP block. That was one deletion of a couple of hundred rows going
through delete.php, which is a REAL-TIME endpoint: it exists for an
operator removing a contact they just logged wrongly, at human pace.
Today's earlier fix stops the requests that were pointless -- QSOs Club
Log never had. This one handles the rest, which are legitimate but still
a batch: one delete every 1.2 s, and a stop at 25 with a line saying to
finish on clublog.org. There is no bulk-delete API to move to, so going
slower and refusing to push a large deletion through a real-time endpoint
is the whole of the answer.
Costs the operator nothing: the withdrawals already run in the
background.
Five entries were written after v0.26.9 was tagged (b952e07), so they
were never in the release the operators actually got -- their What's New
stops at the Club Log delete fix.
rouggy