Reported with a Logger32 export: the record said <DXCC:3>151 and OpsLog
stored 54.
cty.dat answers one question — where is this callsign TODAY — and that is
the wrong question for a log. R1MVI was Malyj Vysotskij Island, entity
151, until the ARRL deleted it in 2012; the same call resolves to European
Russia today. Forcing the lookup onto a 2004 contact therefore destroys a
credit that can NEVER be worked again, because the place no longer counts.
So the ADIF's number wins whenever it names a deleted entity, and nothing
is corrected on those records at all — the country name and the zones of a
deleted entity are equally beyond what a present-day prefix table knows.
The list is the ADIF specification's own enumeration, sixty-odd entities
that only change when the ARRL deletes another one.
The guard sits in the forced path, so it also covers the grid's 'Update
from cty.dat' on a selection — the other way an operator could have lost
the same credits, one right-click at a time.
Two things from one screenshot, and the second is arithmetic rather than a
bug.
Editing an award refreshed the grid and not the statistics matrix, so
changing which confirmations count left the table showing the old rule's
numbers with nothing to mark them stale. That is how a setting comes to
look as though it does nothing.
And OpsLog's 3229 against LoTW's 3004: the Challenge counts confirmed
band-slots on ten bands, and 60 m is not one of them. 3229 less the 224 in
the 60 m column is 3005. So the number was right and the QUESTION was
different — the panel now answers the Challenge one too, under the table
where the comparison is made.
The two totals also say what they are on hover. 'Total' and 'Général' side
by side tell nobody which counts entities and which counts band-slots, and
3309 read as entities is an impossible number — which is exactly how it
was read.
A spot at 10131.5 showed as DATA in the cluster list and raised an alert
announcing SSB. Two tables answered the same question: the frontend knew
10.130-10.150 is the 30 m data segment, while the alert engine knew a CW
range that stopped at 10.130 and ended with a bare 'return SSB' for
everything else.
That fall-through was the fault. A band plan that answers 'SSB' for
anything it does not recognise is not a band plan, it is a default wearing
one — and it fed the alert text, the FlexRadio spot colours and the mode
the radio is told to switch to.
The Go table is now transcribed from the frontend's, segment for segment,
and returns nothing where it knows nothing. The order matters and is now
load-bearing — the FT8 and FT4 watering holes are listed BEFORE the wide
data blocks they sit inside — so there is a test that fails if anybody
sorts the table by frequency and quietly turns every FT8 hole into DATA.
WPM counts as CW while we are here: nothing else is reported in words per
minute, and RBN puts it on every line.
TCI pushes everything about the radio unasked, so the console is mostly a
place to put what was already arriving and being logged once as unhandled.
Drive, tune drive, mic gain, TUNE, volume, mute, squelch, NB/NR/ANF/APF,
AGC, passband, RIT and XIT, VFO lock, and an S-meter in real dBm.
Merged with two corrections to the audio page the console's own work
turned up: the radio was being offered as a recording microphone, and the
RX monitor was enabled for a source it cannot play.
Adding it to the device lists put it in all four dropdowns, and an
operator picked it as their RECORDING MIC — which would have recorded the
station they were listening to instead of their own voice, on every voice
message and every QSO recording. It is not a microphone, and it is not a
pair of speakers either: the audio going the other way is transmit audio.
So it is listed for 'From radio' and 'To radio', and taken out of the mic
and the listening dropdowns.
And the RX monitor is disabled when the radio IS the source, with a line
saying why: the TCI stream is pushed into the QSO recorder, and nothing
plays it to the speakers. The button was there, enabled, doing nothing
audible — which is worse than a button that says it cannot.
TCI already carries the frequency, the mode, the meters and now the audio.
It also carries everything else about the radio — and OpsLog was logging
most of it once as '(unhandled once)' and throwing it away. The console is
mostly a place to put what was already arriving.
That makes it the cheapest panel here, and it is worth saying why. A K3
console costs a command and a reply for every value it shows, which is why
it reads its settings in a rotation and its meters only while on screen.
TCI PUSHES: the radio announces its drive, its filters, its noise blanker
and the rest on connect, and again whenever any of them changes —
including when the operator changes them in ExpertSDR3's own window, which
this panel therefore follows without asking anything.
What it drives: drive and tune drive, mic gain, TUNE, volume, mute,
squelch and its threshold, NB, NR, ANF, APF, AGC speed, the passband, RIT
and XIT with their offsets, and the VFO lock. The S-meter is a real dBm
reading, so its S units are arithmetic rather than the calibration guess a
K3's meter needs.
Setters never update the cached state. The radio answers with the new
value, and taking its word is what keeps the panel honest when a setting
is refused, clamped, or changed at the radio a second later — the one
exception being a slider mid-drag, held for 900 ms so it is not dragged
back by its own echo.
Capped width and centred, like the other consoles. Also offered as a
docked pane — and the Elecraft console is offered there too now: App has
always had that pane, Settings simply never listed it.
Reported on an Ultrabeam over USB: the port could not be chosen from the
dropdown, and the panel would not scroll.
That field was a Combobox — a list you can also type into — chosen so the
port of an adapter currently UNPLUGGED could still be configured. It is
now the same Select every other serial device in OpsLog uses, the one that
demonstrably works. The case it was built for is kept differently: a
configured port that is no longer detected is added to the list, so it
stays selected and visible instead of vanishing when the adapter is out.
Also hardened the Test button's guard, which called .trim() straight on
the port and the host. A settings object without them — an older build, a
save that landed short — throws there DURING RENDER, and a panel that
throws while rendering is exactly a panel with a dead dropdown that will
not scroll. Whether or not that is what this operator hit, it is a way to
produce both symptoms at once and it costs nothing to remove.
Reported with a screenshot: the map came up with API KEY REQUIRED written
twice across the middle of it, on the Light and Voyager views only. Those
are exactly the two Carto basemaps.
Nothing here could have caught it. The tiles still answer 200 with a real
image — the watermark is IN the image — so the map looks like it is
working and simply says otherwise in large grey letters.
Both views move to Esri, which is already behind Street and Satellite. That
is the point: a second key-free provider is a second chance to be cut off,
and this is now the third time a tile source has changed its terms under
us. Light is Esri's light canvas with its own label layer, and Voyager
becomes the topographic map, labelled Topo — the stored key stays
'voyager' so nobody who chose it is quietly moved somewhere else.
The canvas runs out of tiles at zoom 16 where the others go to 19, so
maxNativeZoom is set per basemap: Leaflet upscales the last real tile
instead of asking for a level that does not exist, which is the difference
between a slightly soft map and a blank grey square.
Written into the entry itself rather than added as a line of its own:
somebody reading about the feature should learn it there, not two entries
further down.
A fourth amplifier brand alongside the SPE, the Acom and the PowerGenius,
sharing the same multi-amplifier support: the linking, the fan-out and the
polling all work on it unchanged.
The protocol is the Elecraft one — a caret, letters, a semicolon — decoded
from the KPA1500 Programming Reference, with the document's own examples
kept as the test. ^WS gives forward power and SWR in one exchange, ^VI
gives volts in tenths and amps whole, and ^FL is HEX: read as decimal, the
'antenna not connected' fault matches nothing at all.
Three things this amplifier does that the others do not, each handled
where it shows: a KPA500 has no network side, the amplifier answers while
its main supplies are off, and going to OPERATE clears the current fault.
Nothing here has met real hardware yet.
Telling somebody's amplifier where to be is a write to their station, and
it now has a switch — the SAME switch an Acom uses. 'Keep the amplifier on
the radio's band' is one idea to an operator; that it needs a second
serial port and a rig emulator on one amplifier and a single ^BN on
another is our business, not a reason for two checkboxes.
On by default for a KPA, because an amplifier left on the wrong band is
the worse outcome of the two, and the operator who has wired it straight
to the radio turns it off once. The hint says exactly that case, since it
is the only one where a second voice telling the amplifier where to be is
unwelcome.
Two things the wiring got wrong, both visible on screen.
A KPA fell through to the PowerGenius branch of the amplifier card and was
drawn as one — titled 'POWERGENIUSXL · ELECRAFT KPA1500', with a
PowerGenius's meters and none of its own. It has a card now: OPERATE, ON
and OFF, band, power, SWR, temperature, supply, and the fault across the
end. The OPERATE button carries a tooltip saying it also clears the fault,
because that is the button an operator already has under the cursor when
they need it.
And the band-follow option was offered on it. That option exists because
an Acom POLLS a transceiver and has no command to be given a band, so
following it needs a second serial port and a rig emulator answering those
polls. The KPA has ^BN — OpsLog simply tells it, on the link it is already
using, and only when the band CHANGES. The option is gone from the KPA and
the telling is automatic.
Also: Acom rather than ACOM everywhere it is read, which is how the
company writes it. Identifiers, package names and log lines are left
alone — renaming those is churn with no reader.
Wired into the multi-amplifier support that already carries the SPE, the
ACOM and the PowerGenius: a fourth brand rather than a fourth mechanism.
The linking, the fan-out and the poll all work on it unchanged.
Three things the KPA does differently, and each is handled where it shows
rather than explained in a hint:
- A KPA500 has no network side at all. Choosing it puts the entry on
serial, and a configuration still asking for TCP is refused with a
line saying so instead of retrying an address that cannot answer.
- The amplifier answers ^ON while its main supplies are OFF — a sleeping
microcontroller stays awake for exactly that — so power-on stays
available over the network, unlike the SPE and ACOM which need their
serial control lines.
- Going to OPERATE clears the current fault, everything except
temperature. The widget says so under the fault, because the button
that fixes it is the one already on screen.
Defaults that leave a working configuration when the model is changed:
38400 baud, TCP port 1500, and a full-scale power mark of 500 or 1500 W
by model — a KPA500 read against a 1500 W scale looks idle at full
output.
One package for both amplifiers: they share the Elecraft command set — a
caret, letters, a semicolon, case-insensitive in and upper case out — the
same family as the K3/K4 panel. What differs is the transport and which
commands exist, not the grammar.
Everything here comes from the KPA1500 Programming Reference, and the
document's own examples ARE the test:
^WS1204 014; 1204 W and SWR 1.4:1 — power and SWR in one exchange
^VI513 061; 51.3 V and 61 A — volts in tenths, amps whole
^FL91; HEX, and 0x91 is 'antenna not connected?'
That last one is why the parsing is pinned rather than eyeballed: read as
decimal, 90 and 91 become 144 and 145 and match nothing, so an amplifier
shut down by high reflected power would report a fault OpsLog could not
name. SWR in tenths is confirmed by the reference too — 'expressed in
tenths, 123 is 12.3:1' — where it had only been inferred from Hamlib.
The client is question-and-answer under one lock, never two questions in
flight: the reference states there is no flow control and that commands
are paced by waiting for the reply. Fast cycle four times a second for
power, SWR and the fault; the rest once a second.
Faults are named in the operator's terms — 'the ATU found no match', not
'fault 92' — and an unknown code from a newer firmware still says
something rather than nothing.
Not wired to the app yet, and two commands are deliberately absent: ^TX
makes the amplifier transmit from software, and ^ON0 cuts the main
supplies with Wake-on-LAN as the way back. Neither belongs on a poll loop
or behind a button that can be pressed by accident.
The columns took the award's declared band list when it had one, so every
band the award PERMITS got a column whether or not anything had ever been
worked on it. DDFM permits 6m and 70cm; a station that has never worked a
French department on either was shown two empty columns, which reads as a
gap in the log rather than as a band nobody tried.
They now follow the bands this operator actually has contacts on for the
award. The declared list is the fallback for an award with nothing worked
yet — there, saying what the award is played on is the only honest answer
available — and the classic HF set is the fallback for an award that
declares nothing either.
Together with taking the order from the full band list, this is what puts
23cm on DDFM: the column appears because there are contacts on it.
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 TCI section of the audio settings was an investigation: open the
stream, read what arrives, record ten seconds to listen to, key a tone.
It answered every question it was built for — the frame layout, the
sample width, that the radio asks rather than follows a clock, that the
transmit audio source decides — and confirmed 80 W on real hardware.
None of that belongs in front of an operator now. The radio is simply one
of the devices in the two dropdowns, and choosing it IS the configuration:
one control, in the place where the question is already being asked.
Keeping the tick box beside it would have been two switches for one
decision, with the second one where nobody looks.
Gone with it: the stream/record/probe bindings, the audio.tci_rx setting,
and twenty-four translation keys. The plumbing they proved out stays and
now carries the voice keyer.
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.
A SunSDR carries its audio on the same WebSocket as its commands, so
OpsLog can take it directly: no virtual cable, no second sound card, no
Windows mixer between the recording and the air. The radio appears as a
device in both audio lists and can be chosen for either direction.
Everything here was settled on real hardware over one evening, and none of
it was guessable from the documentation:
- The receive stream answers format=3 for four-byte floats, so the
sample width is derived from the frame rather than trusted from the
field.
- The radio asks for transmit audio only when the transmission is the
CLIENT'S, and only when its transmit audio source is TCI rather than
the microphone.
- The chrono is a REQUEST, not a clock: no payload, carrying the size it
wants, 47 times a second. Audio goes out in answer to it and never on
a timer of our own — a timer was the first attempt and all 234 frames
of it were ignored.
Confirmed: a clean test recording, and 80 W out of a 1 kHz tone.
The radio now appears as a device in both audio lists — 'Radio (TCI
network audio)' — so the receive audio and the voice keyer can both take
the CAT link instead of a sound card. No virtual cable, no second card, no
Windows mixer between the recording and the air.
The transmit side reuses the exchange the tone probe established, with a
WAV in place of the sine: the radio asks, we answer with the next slice,
and it sets the pace. The message is converted once, up front, rather than
per frame — a voice message is a few hundred kilobytes, and resampling
inside a callback that has 21 ms to answer would put arithmetic on the
path where a late frame is a gap on the air.
The PTT is untouched by all this: the keyer keys before and unkeys after
exactly as it does with a sound card, so a transmission is bracketed by
the same code whichever way the audio travels. And the playback runs OFF
the CAT goroutine, since everything else about the rig goes through that
one place and a ten-second message would otherwise freeze the frequency
display and the antenna following for ten seconds.
Two refusals rather than silent failure. A radio that has gone away stops
being offered as a device at all, and a radio whose transmit audio source
is still the microphone is caught within a fifth of a second — a voice
keyer that transmits silence is worse than one that says why it will not.
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.
Transmit over TCI is confirmed on a SunSDR: 80 W out of a 1 kHz tone at
70% of full scale into 80% drive, every request answered.
Which makes the earlier rule wrong. 'Digital modes only' came from a real
observation — SSB silent four times over, DIGU answering at once — but the
mode was a coincidence. ExpertSDR3 has a transmit audio SOURCE, microphone
or TCI, kept per mode, and it was on the microphone in SSB. Refusing SSB
would have blocked the one thing a voice keyer exists for.
So nothing is refused on the strength of the mode. The radio declares what
it wants by asking for audio, 47 times a second when it wants any: key,
wait for one request, and stop within two tenths of a second if none
comes — naming the setting to change rather than theorising about it.
That is better on three counts. It works in SSB when the source is set
right, it cannot be wrong about a mode nobody thought to test (AM, FM,
RTTY), and a misconfiguration costs a quarter-second of carrier instead of
five seconds.
The transmit path works: six passes, the radio asked 231 times and was
answered 231 times, none missed, and the tone was there on the panadapter.
What was missing was power on the meter, and the cause was the level. The
tone went out at a quarter of full scale, out of caution, into a radio set
to 15% drive — enough to draw a clean signal and not enough to move a
needle. In a digital mode the radio expects a line level it can drive to
full output; the POWER is its own drive control, so sending quietly only
wastes the range. Now 0.7, short of 1.0 to leave room for the peaks.
The start line carries both numbers — ours and the radio's drive — because
a quiet transmission has two possible causes and one line should settle
which, rather than an evening of guessing. Reading 'drive' off the radio
is the only reason it is parsed at all.
Three transmissions on a real SunSDR settled how the transmit side works,
and none of it was guessable from the documentation.
The radio asks for audio only when the transmission is the CLIENT'S: with
the operator keying the microphone it sent 282 receive frames and nothing
else. And it asks only in a DIGITAL mode — keyed from here in SSB it stayed
silent four times over, and answered in DIGU immediately. In SSB the
modulator is wired to the microphone, which is also the honest answer to
'why can I hear myself but not the tone'.
The chrono turns out to be a REQUEST, not a clock. It carries no payload —
the message itself is the ask — and it names the size it wants in the
header: 2048 samples, two channels interleaved, 47 times a second, which
is 1024 pairs at 48 kHz, exactly real time.
So audio goes out in answer to a request and never on a timer of our own.
The timer was the first attempt and the radio ignored all 234 frames of
it. Answering also hands the pacing to the radio: no drift, no buffer to
tune, and the size taken from what it asked for rather than from what we
assumed. The sine keeps its phase across frames, since one restarted every
frame is a click 47 times a second.
A pass in SSB is now refused rather than attempted. It keys the
transmitter, produces nothing and teaches nobody anything — and it is
still a transmission.
The feed mechanism is the one the voice keyer will use: WAV samples in
place of the sine, everything else unchanged.
A first real transmission settled one question and raised a better one.
With the receive stream open and six seconds of transmit, the radio sent
282 frames of receive audio and NOTHING else: no chrono, no transmit
audio. So the chrono the documentation describes is not offered to a
client that merely happens to be connected while the operator keys the
microphone, and waiting for it to appear is waiting for nothing.
The reading that fits is that the radio asks for audio when the
transmission is the CLIENT'S and takes the microphone when it is the
operator's — which makes the experiment obvious. Key it from here, push a
1 kHz tone, and watch. Chrono frames appearing gives their size and
cadence by measurement instead of by guesswork; no chrono but a tone on
the meter is just as useful, because then the pacing is optional and the
voice keyer can push frames at the rate the stream already runs at.
A tone rather than silence so the answer shows on the power meter and not
only in the log.
It transmits, so: an explicit button inside a warning box, five seconds,
capped at ten, and every path out unkeys — including the panic that has
not happened yet and a socket that dies mid-tone. A transmitter left keyed
by a defect is the one fault here that would reach somebody else's band.
Writes are now serialised too. send() held the lock only long enough to
read the connection, which was enough while every command came from the
poll loop; a stream of audio frames from a second goroutine is not, and
gorilla panics on a concurrent write rather than failing quietly.
The first transmit test came back with a log that said nothing, which is
the one answer that cannot be read: either no transmit frames arrived, or
they arrived and went unlogged.
So each pass is now bounded by a line of its own, and every stream type is
counted without limit. A pass that reports 'receive audio: 240, and
nothing else' is a result — it says the radio sends no chrono unless
something more is asked of it — where a log with no transmit lines was
merely a silence. The forty-frame logging budget is also handed back to
the transmit types on each pass, since it was always spent on receive
audio long before anyone got round to keying.
The start line says whether the receive stream is even open, because a
radio with nothing streaming has no reason to send chrono, and that is the
likeliest reason the first attempt saw nothing.
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.
The data folder is created and stays empty, the process keeps running,
and no window appears. Nothing returns, so nothing is logged: WebView2
never hands control back, and a hang has no error to report.
So the ABSENCE of progress is reported. If OnStartup has not been reached
twelve seconds after wails.Run, that is written to the startup log and
shown in a message box naming the two causes — a missing WebView2 runtime
and an antivirus blocking msedgewebview2.exe — because 'OpsLog is not
responding' otherwise sends people to reinstall OpsLog, which is the one
thing that cannot help: the part that has not started is not ours.
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.
Confirmed on a real SunSDR: the stream decodes and the test recording
plays back clean. So it can do the job a virtual audio cable was doing —
this wires it to the QSO recorder, which already accepts a pushed source
(the Icom network audio uses the same door).
The conversion lives here rather than in internal/cat: the radio's job is
to hand over what it sent, not to know that the recorder works in 16 kHz
mono. Three samples are AVERAGED rather than two of them dropped —
decimating by picking every third folds everything above 8 kHz back into
the voice band, and on a receiver that is hiss, which a QSO recording has
plenty of already.
Off by default, and applied the moment it is switched: it replaces a
sound card the operator has already wired up, and an option that needs a
restart to take effect reads as an option that does not work.
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.
It has been a combobox since it was written, but without showToggle it
opens only on a keystroke or ArrowDown — both of which have to be known
about first. On screen it is a text box, which is exactly what 'still no
dropdown' meant.
allowFreeText with it: the list is the station's own, so a bird worked
once and never added must still be loggable.
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.
overscroll-contain on the conflict box stops the wheel from chaining to
the pane behind it. With a short list — nothing to scroll inside the box
— the pointer over the table therefore froze the whole panel: the page
would not move and neither would the list.
The box scrolls when it has something to scroll; the page scrolls the
rest of the time, which is what containment was preventing.
Save builds the lists payload field by field, and the new list was not
among them — so every Save wrote an empty satellites array over whatever
had just been typed.
Normalised in the save as well as on the field's blur: the Save button is
reachable without ever leaving the box, and a list whose survival depends
on where the cursor went first is a list that saves sometimes.
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.
The frame log had one budget for the whole session, and the first forty
receive-audio frames spend it in under two seconds. A transmit-chrono
frame — the thing the voice keyer will have to answer, and whose size and
cadence cannot be read off the documentation — only appears once the
operator keys the radio, by which time nothing would have been logged.
Counted per type now, so the first frames of each kind are recorded
whenever they turn up.
The SunSDR announces its own stream at connect —
audio_stream_sample_type:float32 and audio_stream_channels:2 — and both
were being logged as unhandled while the code worked the format out from
frame arithmetic. The declaration is better evidence and arrives before
the first frame; the arithmetic stays as the check on it. The channel
count now drives the mix-down instead of an assumed stereo.
Adds a ten-second test recording, written as a WAV beside the QSO
recordings. Counting frames proves a socket is delivering bytes; it says
nothing about whether those bytes are the receiver's audio, at the right
rate, in the right order. A stream decoded with the width wrong or the
samples misaligned counts exactly as well as a correct one and sounds
like a fan — so the test is a file the operator can play, the same way
the CW decoder was settled on the air rather than on a spectrogram.
The file is written at the rate the RADIO reported, not a constant: a
recording at the wrong rate plays at the wrong speed, which is the one
fault that would be blamed on the decoding.
A real SunSDR answers format=3 where this expected 0 — and 0 was read
from the documentation, which is exactly the kind of detail a memory of a
document gets wrong. The stream was refused outright: 'format=3, expected
float32', zero frames, silence.
Swapping one magic number for another would only move the guess, so the
width is now MEASURED: the header says how many samples the payload
holds, and dividing gives the bytes per sample. Four is float32, two is
16-bit PCM scaled to the same -1..1 the rest of the audio path uses, and
anything else is reported rather than mangled. That stays true whatever
number the format field carries on the next firmware.
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.
A SunSDR already carries its receive audio on the same WebSocket as its
commands, so a virtual audio cable and a second sound card are two pieces
of plumbing an operator installs for no reason. This is the receive half:
what the QSO recorder and the CW decoder need.
The reader now looks at the frame type. It used to ignore it and split
every frame on ';' -- harmless only for as long as no stream was ever
opened, since audio bytes would otherwise have been handed to the command
parser a hundred times a second.
NOTHING HERE IS CONFIRMED ON A RADIO. The header layout comes from the
TCI documentation, and the stream-type numbers are exactly the sort of
detail a document gets right and a memory of it does not -- so the first
forty frames of a session are logged verbatim, and a test bench in
Preferences > Audio reports the sample rate the radio chose, the frames
arriving and the peak level of the last second. 'The stream is open' and
'audio is arriving' are different claims and only the second is worth
anything to whoever tries this first.
Transmit (the voice keyer) is the other half and is deliberately absent:
it has to answer the radio's chrono packets at the right pace, and that
is worth doing once the format is settled on real hardware.
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.
Send-on-type keys each character as it is typed, which only the WinKeyer
and Flex CWX can do -- so the checkbox is shown for those two alone. The
stored preference, however, survives a change of engine: an operator who
had used it on a WinKeyer and moved to CI-V carried an invisible switch
that was still on.
The consequences fit the report exactly. Nothing keyed while typing,
because wkSendRaw falls through to the WinKeyer that is not there; and
Enter sent nothing either, because sendText believes the text has already
gone out. Macros take another path and kept working.
The panel now derives the flag from the engine rather than trusting the
stored value.
The transmit row already carries SPLIT, TUNE, MOX, the chaser, its offset
and the TX readout. The marker field was the one control on it that is
set once -- to agree with SDC -- and then never touched again, so it is
summoned by right-clicking the button instead of parked there. Enter
commits, Escape restores. The button's tooltip says so: an unannounced
right-click is not a feature.
The marker field needs no caption -- it sits against a button showing the
same text -- and 'offset' spelled out crowded a row that already carries
SPLIT, the chaser and the TX readout.
Nobody has seen 0.26.9 yet: a fix to a feature released in the same block,
and the panel field it should have had from the start, are not news --
they are how the feature works. Folded into the one entry.
The marker text is chosen in the skimmer, and the two have to agree or
nothing fires -- so it belongs next to the switch, not in a settings page
the operator would have to remember exists. Kept as raw text until blur:
it is a comma-separated list and normalising each keystroke would eat the
comma as it is typed.
rouggy