v1.9.6 — POTA/SOTA ADIF fixes, wheel-to-tune, iOS bar menus

POTA and SOTA logging put right, the mouse wheel tunes the radio, and the bottom-bar
menus work on a phone again. Almost all of it came from field reports in the two days
after v1.9.4 - Don Adams WB0LQW went through the ADIF file field by field after four park
activations, and the rest arrived from people using v1.9.4 and v1.9.5 on the air.

Logging — from Don Adams WB0LQW's report after four park activations

• Your callsign is written as STATION_CALLSIGN, the field POTA reads. It used to warn "No station_callsign field, assuming operator …" on every upload, and guess.
• Park-to-Park and Summit-to-Summit contacts can be entered afterwards. A new P2P ref column in the web log editor: type just the reference — US-1241, G/LD-049, DLFF-0123 — and the Tab5 works out the programme and fills in both fields. It refuses a reference with no dash, because that value goes out as a claim that a specific park was worked.
• FT4 is logged the way the ADIF specification defines it: MODE=MFSK with SUBMODE=FT4. Editors like ADIFMaster refuse to open a file that declares FT4 as a mode at all. LoTW uploads are unchanged — the pair is turned back into FT4 before signing.

Records already in your log keep the old spellings; only new contacts change. The Today only download gives you a clean file for an activation.

The mouse

• The wheel tunes the radio over the spectrum and waterfall: 10 Hz a click in CW and the digital modes, fine enough to zero-beat by ear, and 100 Hz in SSB (Roy KI0ER, John Dusek). It stops at the band edges, and anything covering the panadapter takes the wheel instead.
• It no longer scrolls panels into blank space — winding past the last row of the settings list or the log used to carry the contents off the screen (Roy KI0ER).

Updates

• The bottom-bar menus work on an iPhone again. A line added for portrait mode in v1.9.4 made Safari hide those popups behind the page (Travis AK6TB, Randy N4OPI).
• "Check for updates" stops claiming you are up to date while it is still asking (Michael KZ4LY, Samuel W7STF).
• Background downloading is now a switch — Tab5 Settings → Network, or the web Settings → Updates. Off still tells you a new version exists; it just waits before spending 3.3 MB (Michael KZ4LY, Samuel W7STF, Steve N9SZ). Nothing has ever installed itself, and that has not changed.
• An automatic download now waits until the Tab5 has settled after boot and has memory to spare (Steve N9SZ).

Also

• Coming back from the radio's own menus restores your frequency and mode — a trip through them could leave the radio on 160 m (Randy N4OPI).
• Basic/Expert is remembered across a reboot (Samuel W7STF).
• A re-sent signal report now carries a fresh measurement rather than the one from when you first called.

Full detail: docs/version-history.md

v1.9.5 — POTA activation double-count fix, ADIF delete safety

A fast-follow patch: two logging bugs that could cost you a POTA activation or corrupt your QSO log's storage.

A duplicate contact could falsely claim your park was activated. If you worked the same station twice during an activation, both the Tab5 and the web page counted it toward POTA's 10-QSO (SOTA's 4-QSO) minimum — so the device could say "10 contacts, park activated" while POTA.app credited only 9 unique stations and rejected the upload (Eric, GitHub issue — three parks in one outing affected before he noticed). Fixed: a station now counts once toward the minimum no matter how many times you work them.

Deleting a single QSO record could silently do nothing — or, on a card with damaged storage, corrupt the log. The single-record delete (Tab5 ADIF viewer and the web log editor) never checked whether its file rewrite actually succeeded before replacing the log — so a storage write failure looked like the delete "worked" while the record stayed put, and in the worst case could have written a broken file over a good one. The device now verifies the rewrite before committing it, refuses to touch the log if it can't, and — new in this release — automatically repairs and reclaims space from a storage card that's become fragmented over a long uptime, so a delete that would have failed now just works.

No new features, no UI changes. Everything else is exactly as it was in v1.9.4.

v1.9.4 — FT8 Options, live tone refresh, phone-friendly web UI

A feedback-batch release: the FT8-specific settings get their own home, the TX tone picker stops going stale, and the web page finally works on a phone held upright.

FT8 Options — one place for everything that's only meaningful in FT8 mode. The Tab5's left-pane button used to be called Filter, which undersold it — it also holds real behaviour toggles like Auto-work pileup and grey-listing, not just filters, so it's renamed Options (Roy KI0ER). The web page gets the same idea properly for the first time: CQ message presets and the FT8 filters, which used to sit buried in one long general Settings list, now live behind their own Options button next to TX tone, shown only in FT8 mode. The button carries a count of how many settings are currently on rather than a plain colour — a colour would always read "active" for anyone who runs filters permanently, telling you nothing — and hovering it lists which ones (Dirk DK7CVD, Roy KI0ER). Inside the panel, an active checkbox gets a coloured border in addition to its own tick mark, so nothing depends on colour alone to be readable (Don N2VGU).

The TX tone picker no longer goes stale while you're deciding. It used to read the band's occupancy once, when you opened it — so a slow decision (reading the strip, weighing EVEN against ODD) could cross a 15-second slot boundary and land you on a slot that filled in while you were looking at it. It now re-checks every 3 seconds while the picker is open, without disturbing your own in-progress pick.

The web page works on a phone held upright. In portrait, the top and bottom bars could lose controls off the edge of the screen with no way to reach them — landscape was always fine (Randy N4OPI, iPhone Safari). Both bars now scroll sideways, the same swipe as the decode list, and the page itself scrolls if the whole layout doesn't fit.

Battery display simplified, and now says when charging is capped on purpose. The raw cell voltage is gone from both the Tab5 and the web page — the percentage already carries the level, and nobody reading the bar needs the number underneath it. In its place: once your Battery Care charge limit trips, the reading now says (limit), on both screens — before this, "capped on purpose at 80%" and "not charging for some other reason" looked identical (Don N2VGU).

The snap-on keyboard can be attached (or reattached) any time, not just at boot. It used to be probed once at startup; a keyboard snapped on later was never found until the next reboot. It's now found within a couple of seconds whenever it's attached, and a detach-then-reattach mid-session works the same way. Its two LEDs are dark once it's found — the keyboard works identically no matter when it was attached, so there's nothing left for a light to usefully say.

The macOS/Linux flasher script works on more systems. A packaging bug could ship flash.command with Windows line endings, which some shells refuse outright with bad interpreter (Michael K Johnson KZ4LY, Fedora). The packaging script now guarantees it's clean regardless of what machine builds the release.

v1.9.3 — updating is one decision now

Updating is one decision now

The Tab5 fetches new releases quietly in the background and asks you once, when it's ready. Tap the bottom bar and you get a window in the middle of the screen with two buttons: Restart now or Later.

No long-press any more, and no cryptic line at the bottom trying to explain itself in twenty characters. While an update waits for you the bar breathes gently; choose Later and it goes quiet and stays out of your way. Tap it again whenever you're ready.

If you'd rather it didn't download by itself, turn it off under Settings → Network → Download updates automatically. Each update is about 3.3 MB, which matters if you're on a phone hotspot in a field. Nothing is ever installed without you asking — downloading and restarting are separate, and only the restart changes anything.

The spectrum, waterfall and FT8 decoding now keep running while an update downloads. Before, everything stopped until it finished.

Also in this release

• TXCQ ANY / EVEN / ODD on the web FT8 page — choose which 15-second slot your CQ goes out in, from the browser. It's the same setting as the button on the Tab5, so the two always agree. (Randy N4OPI)
• SSB tuning snaps to 500 Hz instead of 250. Stations that stray off an integer kHz sit at 0.5, so this lands on the ones that exist and gives you half as many stops to drag through. (Dave KX3DX)
• The band-plan strip is much easier to hit. It's a thin strip between the waterfall and the bottom bar and was easy to miss; its touch area now reaches up into the waterfall while it still looks the same.
• Audio is no longer dropped while a log upload is running. Uploading to QRZ, eQSL or LoTW quietly interrupted the audio feed, which could cost you FT8 decodes at the time.
• Thanks to Don N2VGU, whose report on the old update wording is why the whole flow changed rather than just the sentence.

Installing

Already on v1.9.2? Your Tab5 will offer this update by itself — tap the bottom bar.

Otherwise download QMX-Panadapter-flasher-v1.9.3.zip below and run flash.bat (Windows) or flash.command (macOS/Linux). Your settings, QSO log, LoTW certificate and memory channels are untouched.

v1.9.2 — a field-report release: five things fixed or added, three from Randy N4OPI

A field-report release: five things fixed or added since v1.9.1, three of them from Randy N4OPI.

A stuck exchange that never logged (Roy KI0ER, working K7FD). His diagnostic log showed the same message - K7FD KI0ER R-17 - retransmitted every slot for over ten minutes while K7FD kept sending RRR. Root cause: when a caller's own first message back to us was already a signal report (not a fresh CQ), the QSO machine correctly built the reply but started itself in the wrong state - "waiting for their first report" instead of "waiting for RR73" - so it had no idea what to do with a bare RRR and just kept re-sending the same reply forever. Fixed at the single choke point all three ways of starting this kind of exchange share (the auto-pileup drain, the pileup modal, and a decode-row tap), and regression-tested: a full simulated QSO through the exact same state transition now completes and logs normally.

The SWR-protection fault is visible from the web page now (Randy N4OPI). Before this, tripping the SWR protection stopped the radio from transmitting and the only way to see why - or clear it - was to walk over to the Tab5 and tap the prompt. The web page showed nothing but a bare "QSO Cancelled", with no way to tell a real fault from an ordinary cancel. The web page now shows the same fault message the Tab5 does, and tapping it clears the trip exactly like the Tab5's own prompt.

"Who is hearing me" gets time windows and sortable columns. The panel that shows who's reported hearing you on PSK Reporter now has 15 min / 30 min / 6 h / 24 h chips, and every column header is clickable to sort by it - distance, bearing, SNR, band, age, whatever you want to see first. Both are pure re-slices of the one fetch the device already makes, so there's no extra load on the link. The FT8/FT4 decode list in the browser got the same sortable columns, with a "CQ callers on top" link to get back to the device's own priority ordering whenever you want it.

Working an older pileup caller from the web page now actually works (Randy N4OPI). Clicking a "Calling you:" entry used to refuse outright - "no longer in the decode list" - the moment the caller's row had aged out of the live decode table, even though the Tab5's own pileup screen could work the identical caller fine. The web page now falls back to the same report-first reply the Tab5 has always used, built from the pileup entry's own cached signal report. Pileup entries also show their age now ("37s ago" / "2m ago"), on both the web page and the Tab5's own decode list - the Tab5's HRD (heard-count) column is now AGE in seconds, a more useful number for judging how much to trust a row. And since that number now matters, how long a row survives before it drops off the list is operator-tunable: a "Max age:" dropdown in the Filter modal, 30 to 90 seconds, defaulting to the same 90 s it's always used.

Simulation mode no longer leaves real stations flickering on screen. Turning it on now clears the decode list and pileup immediately, the same as turning it off already did - and real decodes are suppressed from the shared list for as long as sim mode is on, so a QMX still attached and receiving can't keep re-populating the practice session with genuine stations. Verified on hardware over multiple decode cycles: every phantom station reaches the list, nothing real does.

v1.9.1 — the hotfix that makes the update-from-the-device feature actually work

A hotfix for the update-from-the-device feature announced in v1.9.0. It did not work over a real download, on any version, ever - here is why, and what it means for you.

The bug. v1.8.9 introduced updating from the device. v1.9.0 was meant to be the first release where the offer could actually be seen and used. Testing it for real, for the first time, against the live GitHub release turned up two bugs in the firmware's download code — both invisible until a genuine download was attempted against the real infrastructure, which nobody had done until today. The device could not even open the connection: GitHub's own redirect response carries more header data than the firmware's HTTP client was sized to receive, so every download failed instantly with "could not reach the download". This is why the v1.9.0 offer showed up correctly, downloaded nothing, and failed at 0% for everyone who tried it. Once that was fixed, a second bug appeared: the device could crash and reboot right at the end of a successful download. The same fix that let the connection open also made each downloaded chunk larger, and the download loop never handed control back to the rest of the firmware while processing it — audio and FFT processing were starved for the whole download, badly enough to eventually trip a hardware reset. Both are fixed here, and a real download was run to completion, twice, with a full serial capture proving zero crashes and zero audio interruption throughout.

What this means for your Tab5. Your v1.8.9 or v1.9.0 unit cannot update itself to this release, or to any future one, over WiFi. The download code that is broken is the one currently running on your device — it doesn't matter what is on the other end, its own attempt to reach it fails the same way. This needs one cable flash, the same as any earlier update. After that single flash, OTA updates work normally from then on — this was tested and confirmed on the bench. Please do not try the in-device update from v1.8.9 or v1.9.0. It will not work, and there is nothing wrong with your unit or your network.

Everything else is unchanged from v1.9.0 — the faster web page, WiFi power saving, the WebSocket eviction fix, and the snap-on keyboard shortcuts are all exactly as described in the v1.9.0 release notes. This release exists solely to fix the OTA download path.

v1.9.0 — the web page is fast again, the snap-on keyboard drives the app, and the update-from-the-device feature can finally be seen working

⚠️ v1.9.1 is out - cable-flash it. The update-from-the-device feature described below ("Try the update, from this release onwards") does not actually work in this release: it fails instantly for everyone due to a bug in the HTTP client, and if that alone were patched a second bug would crash the device partway through the download. Both are fixed in v1.9.1, but this release cannot download that fix itself - it needs one ordinary cable flash. After that, OTA updating works normally.

The web page is fast again, the snap-on keyboard drives the whole app, and this is the release where the update-from-the-device feature can finally be seen working.

Try the update, from this release onwards. v1.8.9 added updating from the device, but nobody could see it happen: the offer only appears when a release newer than the running one exists, and at the time there was none. From v1.9.0 there is, so here is how to try it. On the Tab5, look at the version at the bottom of the screen. When a newer release exists it turns cyan and reads something like v1.9.0 → v1.9.1 tap?. Touch it, hold for about a second, and let go — holding is the confirmation, so brushing past it does nothing. It downloads in the background and does not restart on its own; the line then says tap updates, and the same long press restarts into the new firmware when you are ready. In the web page, the version in the bottom bar does exactly the same thing, with a single tap. Do not want to wait? The Tab5 checks every 30 minutes, but you can ask it straight away: long-press the version even when it says you are up to date, and it will check there and then, showing checking... while it does. The web page does the same if you tap the version. That is the quickest way to see the whole thing work after an announcement goes out. Nothing is ever downloaded without you asking. Your settings, QSO log and LoTW certificate are untouched, and the previous firmware is kept as a fallback.

The web page got a lot faster. Three separate faults, all found by measuring rather than guessing. The page was being sent uncompressed — 263 KB of it, on a link that shares its bandwidth with the live spectrum stream. It is now compressed to 83 KB and carries a tag so a reload of unchanged firmware costs almost nothing. A cold load went from about 95 seconds to under two. WiFi power saving was switched on, which is right for a battery sensor and wrong for something that serves web pages: the radio slept between beacons and depended on the access point to hold anything arriving for it. Outbound traffic was never affected, which is why the spot feeds always worked while the web page did not. Measured over 500 samples, requests that failed outright went from 14.4% to 0.4%, and the slow ones got twice as fast. The page was killing the very stream it displayed. The web server evicts its least-recently-used connection when it runs out of slots, and a connection's place in that queue is only refreshed when it receives something. The spectrum stream only ever sends — so it was permanently bottom of the pile, and the browser's own polling was enough to get it thrown out every few seconds. That is the "reconnecting" some of you have seen for a long time. If the panadapter in your browser has ever felt slow, stuttery, or dropped out and came back, all three of those were contributing.

The snap-on keyboard now drives the app. If you have the Tab5's snap-on keyboard, it does considerably more than type into text fields. The radio's own menus can be driven from it — arrows, Enter, digits and backspace — so the Radio Menus screen no longer needs the on-screen keys, and Esc leaves the screen. Enter and Escape work in every window that has buttons, including the FT8 transmit confirmation and Antenna Tune, and Escape also backs out of the memory page and the settings drawer. Arrows and Page Up/Down scroll the settings drawer and the manual — press an arrow repeatedly and it scrolls further each time. Shortcuts: hold Ctrl and press a key — R radio menus, M manual, L QSO log, K memory channels, P panadapter, F FT8, S settings, H guidance, D display off. And you can change them: the web page has a shortcuts editor under Miscellaneous, with 25 actions to choose from — zoom, brightness, release the radio, any of the setup windows. Alt is left entirely free for your own bindings. Nothing that transmits can be bound to a shortcut. A button you deliberately press is one thing; a two-key combination a slipped finger can produce is another.

Fixes from your reports. Randy N4OPI found five, all fixed: the TX power and SWR readout was hidden behind the exchange status, so that whole strip is rebuilt — status, figures and buttons now sit across the panel instead of stacked down it, taking about a third less height — and the power and SWR figures only appear while you are actually transmitting. The TX tone picker selected a slot one or two to the left of where you clicked, an arithmetic mistake that grew from nothing at the left edge to nearly two slots at the right. "Busy: working …" and "QSO cancelled" never went away — that line reports what happened when you last clicked something, so it now expires by itself. A worked station stayed green in the decode list until the next QSO started. "Who is hearing me" was quietly discarding reports — it stopped reading after 64 and said nothing about it, and now handles 128 and tells you when the collector had more than it could read. The decode list also shows the country, spelled out, where it used to repeat the grid square that is already in the message text. Don N2VGU asked for keyboard support in the radio menus — see above.

Also: the web page no longer asks you to confirm ordinary operating actions — calling CQ, cancelling mid-QSO, working a station from the list and starting Antenna Tune all just happen, though deleting things and installing firmware still ask. The mid-QSO Re-send / RR73 / 73 / Cancel buttons are all the same size. The firmware version at the bottom of the Tab5 is no longer dimmer than everything beside it.

v1.8.9 — the Tab5 updates itself, and a keyed radio can no longer be left transmitting

The Tab5 can update itself now, and a transmitter that could be left keyed no longer can.

The radio can no longer be left transmitting. Roy KI0ER reported his QMX transmitting continuously until he power-cycled it, with the Tab5 running normally throughout. His log had the whole story: a USB transfer timeout mid-burst, then every command failing — including the two that stop transmission. The burst finished, the radio stayed keyed, and nothing tried again. The link recovered about two seconds later. Nothing re-sent the stop command. That is fixed twice over: the stop command is now retried immediately, and if it still cannot get through it is handed to the radio-control task, which keeps re-sending it on every cycle that works until the radio is demonstrably back in receive. Two seconds or two minutes, it no longer matters. If it ever happens again the log says so plainly instead of looking like a healthy transmission.

Updating from the device. The version at the bottom of the screen now tells you when a newer release exists, and installs it if you ask. Touch it, hold for a second, let go. It downloads in the background and does not restart on its own — you choose when. The web page says the same thing in the same words. Nothing is downloaded without you asking. Your settings, QSO log and LoTW certificate are untouched, and the previous firmware is kept as a fallback. Install this release with the flasher as usual; after that the cable is only for emergencies.

Also:

• A crash now survives the reboot. If the Tab5 ever restarts unexpectedly, the next boot records what happened — which part of the firmware, how far into the session, and where. Send the diagnostic download and that is enough.
• The diagnostic log is written to a microSD card again while WiFi is on. Previously the card only received a backup at start-up, so the log was not there when it was needed.
• The flasher download is 2.9 MB instead of 44 MB (Gyula HA3HZ) — it had been quietly carrying every previous version inside it.
• FT8 can move off an occupied frequency mid-QSO, to the nearest clear slot only (Roy KI0ER, Gyula HA3HZ). Far enough to escape whoever is on top of you, near enough that a station with a narrow receive filter still hears you.
• A bandwidth reading stuck on a CW filter after switching to LSB is fixed (Samuel W7STF).
• The out-of-band tuner now works in the browser too (Samuel W7STF).
• Browser display stalls: the message telling a second browser it had lost the live view was malformed, so browsers hung up and grabbed it straight back (Samuel W7STF).
• The frequency readout could stick on an old value while the spectrum and the radio were correct.
• Spur suppression has been withdrawn from the settings drawer. It only ever worked at ×1 zoom, which is not where anyone looks at spurs, and with a real antenna the problem is far smaller than bench measurements suggested. The work is kept for a future release.
• Every web API command is documented, and the error behaviour is now described correctly.

v1.8.8 — crashes are diagnosable, and the FT8 double-spawn root cause

A diagnostics and field-report release. Nothing here changes how the radio is operated; several things change how much can be found out when something goes wrong.

A crash now survives the reboot. Until now a crash left nothing on the device. If your Tab5 rebooted and you sent a diagnostic download, it contained everything except the one thing needed — the panic text went straight out of the serial port and was gone. The next boot now reports the previous crash in the log, with the reason, the assert text, which task died, how far into the run, the registers, and a ready-made decode command. It reaches both Diagnostic download files. So if the Tab5 restarts unexpectedly, please just send the diagnostic download — that is now enough. A side effect worth knowing: a reset with no crash record is positive evidence that it was not a crash — a power cut or a reflash looks identical otherwise.

FT8: the double-spawn root cause, open since v1.3.0. There has been one unreproducible reboot on entering FT8 for a long time. It now has a cause: an internal "is the FT8 task running" flag was set by the task itself rather than when it was created, and these tasks run at the lowest priority on the board — so a watchdog could look during the gap, conclude nothing was running, and start a second one. Both then built the same buffers and the second freed memory the first was still using. Fixed, along with a second instance of the same mistake found by checking the whole codebase for it.

FT8 decodes were being quietly discarded. Measured over a 54,142-decode run: 99 decodes thrown away by an internal timeout that was far too short for what was at stake. A dropped decode is gone — it never reaches the list, the occupancy map, or the check for a reply addressed to you. A lost reply looks exactly like the other station going quiet.

From Samuel W7STF:

• Bandwidth stayed on a CW filter after switching CW → LSB. Real bug: once an SSB filter had been pinned, nothing ever repainted the label on the way back into SSB. Fixed and verified on the radio.
• The out-of-band tuner now exists on the web page too. Out of band the Tab5 turns the band strip into a centre-detented coarse tuner; the browser simply hid it — the one place you most want a way back to a band had no control at all. Same behaviour as the Tab5: drag off centre, springs back on release, full deflection is half the visible span.
• Web stalls. A real cause was found, and it is not your PC. The message that tells a displaced browser "another browser took the live view" was a malformed websocket frame, so browsers failed the connection instead of reading it, reconnected, and took the view straight back — a continuous tug-of-war whenever a second browser or a phone was left open. Measured before and after: 16 takeovers in ten seconds → 2 in twenty-five.
• Radio Menus / Diagnostics colour. Not fixed yet, deliberately. The colours the menu screens use are all handled; the Diagnostics screen evidently sends something else, and rather than guess, the firmware now reports exactly which codes it did not understand. If you can open Diagnostics and send the reading, that is the fix.

Also: the frequency readout could get stuck showing an old frequency while the spectrum, waterfall and radio were all correct — it was a dropped screen update that never retried, and the poll now re-asserts it. The web page shows websocket health (sessions, takeovers, closes, partial) in /api/status, so a reported stall can be matched against what the device actually did instead of argued about. An internal audit of a class of start-up crash found two real gaps, fixed, and three other places verified genuinely safe.

Not changed: no change to FT8/FT4 operation, CAT behaviour, logging, uploads or the manual.

v1.8.7 — the browser panadapter stops freezing, and your logs can go to your own Cloudlog

The browser panadapter stops freezing, your logs can go to your own Cloudlog, and the radio's menus show the radio's colours.

The web panadapter freezing for seconds at a time (Samuel W7STF, #177196). His report was that it "hangs from time to time, and then several seconds later it begins to animate again", and that it had been getting worse with every release. Measured before anything was changed, because every "obvious cause" in this project's history has been wrong when measured. Over 9.6 hours on the bench the browser session was torn down 545 times, roughly every 14 seconds in bursts, each costing a median 2.2 seconds of frozen display while the browser reconnected, worst case 4.5 seconds. Between the drops the stream ran at its full 10 frames per second. Feed traffic was heavily implicated — RBN 8.4x and the DX cluster 8.6x more likely in the two seconds before a teardown than at a random moment. Socket exhaustion was tested and ruled out. But the feeds were the trigger, not the fault. ESP-IDF's WebSocket send writes the frame with a single call and only treats a negative result as an error — and a partial write is not negative. A frame that went out half finished was reported as sent. The browser then read the next frame's header as the tail of the previous one, saw a protocol violation, and closed the connection. That is why it froze for seconds rather than glitching one frame, and why it got worse as more background feeds were added: more congestion, more partial writes. The July fix that stopped a stuck send freezing the whole web server made it more likely — that fix put a 400 ms timeout on the socket, and a send timeout with bytes already queued is exactly how a short write happens. The freeze fix and this bug were the same line of code. Now the send loops until every byte is out, the frame header is built in front of the payload so the two cannot be split, and a frame that cannot be finished closes the session rather than leaving the browser reading rubbish. Congestion with nothing yet sent simply drops a frame, which costs nothing. The repairs are counted and reported, so the fix can be seen working rather than merely assumed. Verified on hardware: 9.3 minutes under live feed load gave 0 teardowns where the old build predicted about 9, 0 connection resets where the old build logged over a thousand, and 8 partial writes caught and completed — each one a stream that would previously have been corrupted.

Upload to your own Cloudlog or Wavelog (Mark G4MEM). The fourth logbook, and the only self-hosted one. Because the address is yours rather than compiled in, this is the first time the firmware sends credentials somewhere it does not already know. Mark runs his on his home network with no certificate, and asked whether plain http:// could be allowed when the server is on the same subnet the Tab5 is connected to. It can, and it is. That is not the same as an "ignore the certificate" switch, which was refused: the subnet test is a fact the firmware can check, and on your own network the packets never leave equipment you own. Two deliberate limits: the check runs on every upload, never cached at setup, because the whole point is that you configure at home and then operate from a field site where the same name could be answered by anything; and plain HTTP needs a numeric address, since a name has to be looked up and what answers the lookup can differ from what answers the connection — use https:// for a hostname. Records go in batches, Cloudlog does its own duplicate checking, and Wavelog works identically. If your server is on your own network this is the only upload that needs no internet at all, which suits POTA and SOTA better than the other three.

The radio's menus in the radio's colours (Samuel W7STF). Radio menus rendered everything white while PuTTY showed the same screens in red and green. The colour was being parsed and stored all along; both renderers simply discarded it. Fixed on the Tab5 and in the browser, from the same palette so the two cannot disagree. The selected-item highlight still wins wherever both apply, since losing it would cost you your place in the menus.

Battery showing 100% then 0% with no battery fitted (Randy N4OPI). On a Tab5 run from USB-C with no NP-F550, the readout alternated between 100% (8.4 V) and 0% (4.2 V). A no-battery detector already existed and was flapping in time with the rail rather than latching: it watched a five-sample window, so while the voltage sat at either value the window looked perfectly steady and the detector decided a pack was present again. It now also checks two things a real pack cannot do — moving several volts between one-second readings, and running the device at 4.2 V. The web page is told as well, so it shows "USB" instead of inventing a percentage.

Pick callers myself, while running CQ (Eric K3FNB). "When I am activating a park, I sometimes like to be a bit more engaged. If it is possible, could you have an option where I have to tap on a caller/hunter in order to initiate the exchange? I don't mind the firmware automating the rest of the exchange, I just would like to have the option to not auto-pounce on hunters." New option in the FT8 Filter modal. With it on, a station answering your CQ does not start the exchange — they wait in the pile-up until you tap them, and the exchange then runs itself exactly as before. Only the choice becomes manual. It deliberately keeps calling CQ rather than standing down: an activator wants the pile-up building while they pick, and a radio that went quiet would look like it had stopped. It also overrides "Auto-work pileup", because both settings decide who to work next and someone who asked to choose has not asked to have the strongest caller chosen for them a moment later. Off unless you turn it on. Verified in simulation mode, both ways — with the option on, a caller waits in the pile-up and no exchange starts; with it off, the same caller is answered automatically. Not yet used on the air, so if it misbehaves during a real activation please say so.

A Bluetooth mouse whose pointer moved erratically (Kevin KW6E). His Microsoft Surface Arc connected and scrolled perfectly but the pointer jumped about. Two things were wrong. The mouse fix that shipped in v1.8.4 went into the USB path, and his mouse is Bluetooth — so it never touched the code he was running. The rest came out of the diagnostic log he attached, without needing his hardware. His mouse sends nine-byte reports with 16-bit movement; the firmware treated any report of five bytes or more as the layout of a Logitech M240, where the two axes share a nibble. His own report 00 06 00 0b 00 ff ff 00 00 is X=+6, Y=+11, and that arithmetic turned it into X=−1280, Y=0 — a large jump the wrong way with no vertical movement. Scrolling survived because the wheel byte lands in the same place either way. The decode now picks between layouts that have each been captured off real hardware, and the same routine serves both the USB and Bluetooth paths — the USB one had the matching assumption waiting for the next mouse. The mouse's own report descriptor remains the preferred answer; this is only what happens when it cannot be read.

A warning that blamed the wrong thing (Samuel W7STF). After swapping cables he once got "is the radio set to 2 USB serial ports?" on a radio that was already set to two. The second port was opened exactly once, and any failure produced that message — so a radio still re-enumerating after a cable swap was reported as a configuration mistake. It now retries, and only names the setting when the radio is demonstrably present.

Also in this release: a radio receiving on VFO B is put back on A, and told you about it (Markus DL8MBY) — frequency writes go to VFO A only, so with the radio on B every tune went to a VFO he was not listening to while band select still worked, which is exactly why it looks like your own mistake rather than a fault. Waking from the screensaver no longer acts on the tap that woke it (Randy N4OPI) — sleep disabled the mouse pointer and left the touchscreen live. The browser's spot and frequency labels are readable on a high-resolution display (Randy N4OPI) — they were being drawn at roughly half size. A crash after about seven hours is fixed — a bare abort() in ESP-IDF's USB driver on a state it treats as impossible, the fourth of that family, and as with the last one the reboot was not the expensive part: it happens with the radio attached, so the QMX then could not reconnect for the rest of the night. The flash-persisted diagnostic log no longer stops writing — it reported "no space left" with 400 KB free, not a capacity problem but a garbage-collection one, caused by deleting a 256 KB file every 11 minutes, and the boot log now lists every file with its size. Two silent USB patches now count what they catch — they cannot log, because they run in an interrupt, so a clean log could not distinguish "never happened" from "happened and was handled", and neither has fired yet, which is now a statement of fact rather than an inference from silence. Entering FT8 could reboot the device — all the decoder's monitors share one FFT scratch buffer, and the code that set that up freed each monitor's old buffer without checking whether it was already the shared one, so if the pool was ever built twice without being torn down in between, the same block was freed twice and the device rebooted; caught on the bench while testing this release, and it is almost certainly the unexplained heap crash that had been on the list since v1.3.0 — the reboot is fixed, the underlying double build is not, and now logs a loud warning instead of being survived in silence.

Investigated, no change. The first entry into Radio menus after a flash drawing blank (Samuel W7STF) could not be reproduced: the first open after flashing plus six more were all clean. Randy ...