Naming the AIO rested on the uConsole's panel alone. It now takes every
mark, from two independent sources: ClockworkPi's uConsole overlay
describing the hardware in the device tree -- the cwu50 screen, the
AXP228 power chip, the OCP8178 backlight -- and the hardware answering
for itself on USB, the built-in keyboard (1eaf:0024, made by
ClockworkPI, named uConsole; the ids alone are any LeafLabs Maple). An
overlay on the wrong machine has no uConsole keyboard, and the keyboard
on another machine has no uConsole overlay. Any one missing, and the
radio is listed unnamed on the AIO's wiring, as before.
`BuiltinRadio.compatible` gives way to `board`, a test only its machine
passes (`is_uconsole`).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The radio on spidev1.0 was listed as a bare "SPI radio" and reported
"MeshTerm SPI node", because spidev1.0 alone could be any Pi. A
uConsole now proves itself by its own screen: ClockworkPi's uConsole
overlay declares the panel `cw,cwu50`, which no other machine carries
(the DevTerm's is cw,cwd686; the CM's model string and the AXP228 and
backlight are shared). Seen on JP's CM5 uConsole.
`BuiltinRadio` takes a device-tree `compatible` beside its marker path,
read once a run from /sys/firmware/devicetree/base. The named AIO comes
first in BUILTIN_RADIOS; without the panel, the unnamed entry still
lists spidev1.0 on the AIO's wiring as before.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The SPI node reported every radio as "MeshTerm SPI node", so the
Cardputer's Cap read that way wherever a device's model is shown. The
node is now told the shipped board it runs on (`board_name`, matched by
the SPI node on this machine's board, so a profile that adjusts the
Cap's pins is still the Cap) and reports that; a radio on a board
MeshTerm doesn't know by name keeps "MeshTerm SPI node".
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
On the Cardputer Zero, connecting to an ESP32 companion that wants a PIN
stalled for a minute and never asked for one. Its link came up and its
services resolved; the UART subscribe made BlueZ ask MeshTerm's agent
for the PIN; with none given the agent refused, and the companion
disconnected -- it hangs up rather than refusing the subscribe. The
guard that holds back drops while bleak retries HCI 0x3e swallowed that
hang-up too, so meshcore waited out its timeout on a dead link.
The agent already records whether BlueZ asked it for the PIN. A drop
after that is now flagged, and the connect ends at once as a pairing
failure -- the words the PIN handling answers -- so the reader is asked
for the PIN in seconds. Drops with no pairing asked are held as before.
Also: a link that opens and then drops during service discovery
("failed to discover services, device disconnected", an HCI Connection
Timeout 1.7 s in, at -22 dBm as readily as at -86) is retried like a
link that never opened. It was surfacing on the first try, and the next
try usually connects.
Checked on the Cardputer against the companion: three connects with no
PIN each answer "requires a Bluetooth pairing PIN" in 2-7 s, where each
took the 60 s timeout before.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The Cardputer Zero's Cap carries a GPS on the header's UART, which the
device screen listed as "~ n/a" (pyserial's name for a port with no USB
identity): a companion to connect to, and with nothing remembered, the
lone port a command-line connect would pick. A wiring now names its
board's GPS (`gps_port`, `gps_baud`; the Cap's is /dev/serial0 at
115200), and wherever that radio is listed, its GPS port is not: the
device screen, `meshterm devices`, and autodetect.
The radio node reads it the way MeshCore companion firmware reads a
board's GPS: `gps` (off until switched on, remembered in prefs.json)
and `gps_interval` (0, every fix, once a second), reported and set as
custom variables, which is where Device config already shows them. A
valid RMC or GGA fix becomes the node's position, the one its
self-info reports and, with Share location on, its adverts carry. The
last fix is saved as the node shuts down. Standard library only, as
the node's contract asks; NMEA checksums are checked.
On MeshTerm's side, our own self-info is now refreshed behind the
answer after a minute, like the contacts, so screens opened after the
node moves show where it is; and the connect-time settings offer no
longer flags a position the running GPS moved.
Checked on the Cardputer: the ttyS0 row is gone from `meshterm
devices`; `config custom gps 1` opens the port, is saved, and reads
back on; the real-terminal test passes there.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
On the device MeshTerm ran, drew every frame, and stayed invisible: the
panel kept the launcher's last frame while a splash nobody could see
waited for a key. The panel is a DRM driver whose /dev/fb0 is fbdev
emulation, and the kernel copies to the glass only what it sees change
through the *mapping*. pwrite() put the pixels in the buffer, where
reading /dev/fb0 back showed them, and never on the panel. The frame
now goes through an mmap, as M5's own LVGL apps write theirs. Checked
on the panel.
Also scripts/cardputer-zero/type-text.py: paste a long string (an API
key, a Wi-Fi password) on another computer and it is typed on the
Cardputer's keyboard over SSH, into whatever app has the screen. Input
is hidden and travels on stdin, never on a command line.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
With the Cap powered, I2C bus 1 doesn't only fail reads: some come
back garbled (a capacity of 56414, clamped to a confident 100), and
the kernel's bq27xxx driver caches whatever it read, failure or
garbage, for five seconds. Retrying 0.1 s apart only re-read the
cache, so every retry missed.
Now an unreadable or out-of-range percent is asked again 5.5 s later,
past the cache; a step of more than 5 points between polls waits for
the next poll to confirm it, which catches garbage that lands inside
0-100; and the sysfs reads leave the event loop, since a failing
transfer on that bus takes its time. Measured on the device with the
Cap on: a steady 96%, where it showed nothing or 100 before.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Tried on a real Cardputer Zero for the first time. It draws on the
panel, takes the keyboard, and opens from M5's app launcher:
scripts/cardputer-zero/launcher-entry.sh puts a source checkout there
(and `remove` takes it off) until there is a store package.
Three things the hardware showed:
- The splash opened with the highlight on /dev/ttyS0, the Cap's GPS
UART, because serial is listed first as found. Below the companions
we've used, anything that looks like one now comes before a port
nothing vouches for, across transports.
- The title bar's battery is the handheld's own BQ27220, as the
PicoCalc's is. The host pack is now found by what it is (a Battery
supply that isn't a peripheral's), not by the PicoCalc's name.
- While the Cap is powered, I2C bus 1 turns noisy: a quarter to three
quarters of the gauge's reads fail with an I/O error (one in ten of
the clock's), none with the header off. A failed read is asked again,
a status that won't read keeps its last verdict, and a good reading
stands through six failed polls instead of blinking out.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
On a Cardputer Zero the device screen lists the Cap as "Cap LoRa-1262",
and --spi reaches it, with no profile: its wiring ships beside the
AIO's, listed when the board's own ext_5v_out switch says this is a
Cardputer Zero (spidev0.1 alone would claim every Pi with SPI on).
The Cap needs two things before the chip answers, and the wiring can
now say both. `leds` sets the switches the device tree hands to
gpio-leds — ext_5v_out powers the header, ext_usb_gpio_fun=0 keeps
the reset and interrupt pins on GPIO rather than USB — and puts them
back when the node ends, so the header is unpowered again after
MeshTerm quits. `pi4io_*` drives the Cap's PI4IOE5V6408 at 0x43, which
enables the RF path; a silent expander is reported as the Cap not
being attached.
Checked on the hardware: reset 26, busy 22, irq 23 on spidev0.1 (the
lines M5's factory test drives), the node comes up from a cold
header, and it hears the mesh at +12 dB.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A full T1000-E read 9 or 10% in the header on Ubuntu, while the radio
reported 4.21 V. The battery was never the fault. A full pack's "100"
lost its last zero, and 99% lost its 9 to the % sign that followed it.
MeshTerm adds one column to the width the terminal reports, because
prompt_toolkit's Windows console output reports one column fewer than
the window has, on purpose. That was done on every desktop, but a Linux
or macOS terminal reports its width exactly. There the extra column fell
off the screen. prompt_toolkit draws with autowrap off, so each row's
last character landed on top of the one before it, and whatever sat
flush right lost its end. The battery gauge sits flush right.
The column is now added only where the terminal hid one, which is the
Windows console. The full_width preference and MESHTERM_FULL_WIDTH still
override either way. Driven into an exact 80-column terminal under
--mock, the header now ends "100" at 4.21 V and "98%" at 4.18 V, where
it ended "10" and "9%". In a real Windows console the reported 119
columns still widen to 120.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Only 24 of 144 direct messages and posts in the history were ever marked
delivered. Three faults, each fixed:
- The wait was the radio's own estimate times 1.2: about 5.7 s for a
flood, while a flooded round trip from a few hops out takes ten (a
room's answer from five hops landed at 10.1 s on hardware). It is now
the login's patience, the estimate stretched a quarter plus a round
trip sized to the route, about 15 s for a flood.
- An ack that landed after the wait was dropped. The radio pushes one
whenever it arrives, for any of its last eight sends, but nothing was
listening, so a delivered message stayed failed for good. The history
shows ACK and PATH packets heard seconds after messages recorded as
failed. The send now returns a Delivery carrying the ack code, and the
chat service keeps the last sixteen messages still waiting. A late ack
flips one to delivered, in history and in the message the chat screen
holds, and every code a retried message went out under counts.
- The Courier trusted the failure and sent the message again: a
duplicate for the recipient whenever the ack was only late. A late ack
now marks the entry delivered.
The ack listener is also armed before the send rather than after it,
so a neighbour's ack quicker than the send's own return is not missed.
The debug log names how a message went out and the radio's own
round-trip time.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A long room name ran the join's caption ("logging in to YJN-ROOM-OBS
St-Jean along its 6-hop route… 37 s") one cell past its box, and the
count's last letter wrapped alone to column zero. A busy card's caption
may now carry line feeds, each later line hanging under the caption's
text rather than under the spinner. The card is as wide as its widest
line, and a line too long for the screen wraps under the text too. The
join puts the room on the first line, and how the login went out with
its running count on the second.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Joining a room moves out of Chat into a Rooms page beside Channels. It
lists every room server the radio knows, joined ones first, with each
room's access, unread count, last post and last-heard time. Each room
has a page: join, log in again, change password, open the board, forget
it, or delete its stored posts. Chat now lists only joined rooms, the way
it lists only channels on a slot, and only a joined room raises the
unread badge. chat join becomes rooms join, alongside rooms list and
rooms forget.
"No reply" told the reader nothing, because a room is just as silent for
a wrong password as for a login that never reached it. Testing on
hardware showed the commonest cause is neither: a login sent along the
route the radio had learned met silence, and the same login by flood was
accepted in eleven seconds. A silent login is now explained from what is
known: how it went out, when the room was last heard, and whether this
password has worked before. It offers the one next step that evidence
points at:
- Try by flood, after a learned route met silence. The radio forgets
the route (local, nothing transmitted), then sends the login once.
- Try again…, after a flood met silence. The prompt reopens with the
password filled in, so Enter resends it and typing replaces it.
- Add it & try again, when the radio doesn't hold the room as a contact.
Every retry is a button press, and none is ever sent on its own. A
password over 15 bytes is refused at the prompt, since MeshCore sends
only the first 15.
On the board, a failed or unfinished login used to leave the compose
line taking posts the room would drop. It now opens only while we are in
and may post, and otherwise says why and what to press. Opening a joined
room that has gone quiet logs in in the background. ^L runs the
explained flow.
Underneath, the login exchange listens for the radio's own confirmation,
matched to the login by its expected ack. It records whether the login
went by flood or along a route, or the radio's reason for not sending it
at all. This also corrects the debug log: "send unacknowledged" read the
library's wait for the *answer* as the send. On hardware the radio
confirms in under 0.1 s. Device.reset_route is new. The simulator learns
routes, can be given a stale one, and refloods.
Refs: #24
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A review of the room work turned up ways the remembered passwords could
go wrong, and a doubled login:
- A room that lets readers in lets any password in, so a login that only
earned read-only proved nothing about the password. It replaced the
room password anyway, so one mistyped ^L left a member read-only for
good, with no prompt to fix it. It now never replaces a password that
is already kept, and ^L asks for one while you are read-only.
- A blank login only asks "do you know me?". Accepted, it overwrote the
remembered room password, and as an admin it emptied the admin
password Repeater admin shares. It now replaces neither.
- A room's login replaces a known member's role with the one the
password earns, so an owner who held both passwords was demoted to
member each time the room password was tried first. The admin password
now goes first.
- Closing a room view and opening it again mid-login sent a second
login. The room service now shares a login already in flight, and a
room with one under way is not due another.
- A refusal forgot the room password even when it refused a different
one. ^R is no longer offered to a read-only member, whose resend the
room would drop. Enter on a picked post opens its paths when there is
nowhere to put a reply, and a paste is refused there too.
Refs: #24
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
chat join logs in to a room server and prints what it allowed: member,
admin or read-only. It uses --password, or the password MeshTerm
remembers for the room. A room says nothing to a wrong password, so a
join that hears nothing fails (exit 4) and names both possible reasons.
send --to a room posts to it, and its receipt says kind "room". A room's
history names each post's author where a direct transcript names the
peer, drawn the way a route draws a hop: "Alice (d4e5f6a7)", or the bare
hash when nothing names the key. The document carries the author on
every row, null outside a room, so history answers in one shape for
every kind of conversation; listen streams it too. chat list calls a
room a room.
The CLI manual, the features guide and the README describe rooms, and
CLAUDE.md adds room and post to the lexicon, 📌 to the icons, and ^L to
the chord list.
Refs: #24
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A room server is a message board on a radio: it keeps its members' last
posts and sends each member the ones they missed. MeshTerm could see rooms
and run your own, but not join one. Posts that reached the radio were filed
as direct messages from the room, with their authors thrown away.
Chat now has a Rooms section between Channels and Direct. Opening a room
shows its board at once, each post under the member who wrote it. A post
carries the first four bytes of its author's key, so it is named by any
contact or overheard advert with that key and coloured by the key itself.
An author nothing names stands as the hash, in the unknown-node grey. The
first visit asks for the room's password over the board. After that,
opening a room logs in again only once it has been quiet for
room_relogin_minutes (a new preference, 30 by default), and ^L (F6 on the
handhelds) logs in on demand. The title says what the room allowed:
member, admin or read-only. A read-only member gets a line saying the room
drops their posts, in place of a compose box. A post goes out once, never
soft-retried, since a duplicate would reach every member.
Underneath: messages carry an author (schema 18), a room's board leaves
out its command replies, and a re-sent post is recorded once. Room posts
raise the unread badge and a room's command replies don't. The device
gains room_login, sharing admin_login's exchange and reading the access
the room granted. Room passwords are remembered in rooms.json; an admin
login is kept in admin.json, shared with Repeater admin. The simulator
has a room, Lakeside BBS, to join with "hello".
Two fixes the research turned up. An admin command took the first direct
message from anyone as its reply, so a room post or a companion's message
landing mid-command was read as the node's answer. It now listens before
sending, and only for a reply from that node that is not a post. And
Repeater admin names a room server's guest password "Room password", the
password members join with.
Refs: #24
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Each hop row drew its link as a whole route, square at both ends, so every
hop read as a walk that began and ended there. A hop is one link of the
walk: only the first hop's start and the last hop's finish are the route's
own ends. Every other end is a node the route runs on through, and now
wears the notch or the point (a bare → in arrow mode), the marks a path
line already uses for "this goes on".
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Each hop used to read as "origin (hash) → destination (hash)" in a
four-column table, which ran past the edge on any link between two long
names. The link now draws through the path widget the way the route lane
above it does: names with no hash after them, an unnamed node by its hash
(the only identity it has), and our own end as the bare star.
Where every row fits on one line the hops stay a table, one line each. Where
any row doesn't, every row takes two lines, all alike so the readings never
jump between lines: the hop number and its path on the first, and the
reading with its meter flush right on the second. A path still wider than
its lane breaks off on its cut mark and slides under ←→, with the hop number
pinned and each path stopping at its own tail. The footer offers
"←→ scroll" only while something can slide, and sliding lets go of the
action cursor so the page stays on the hops being read.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Once a trace had run, ↓ on the last action did nothing. The results sat in a
window of their own under the actions, sized to whatever rows the controls
left, so the page came out exactly as tall as the screen: the frame had
nothing to scroll, and edge scroll with it, while "↓ n more" sat under the
last action. Only PgUp/PgDn slid that window.
The results now follow the actions on the page. ↓ off the last action
scrolls on down through them to the oldest trace, the snap-back brings the
actions back, and PgUp/PgDn/Home/End page the whole screen, the way the TX
sweep and Records pages already work.
So that no other screen hides rows this way, ListWindow.fit and fit_blocks
take the highlight with no default: a window is for a list the highlight
walks, since every row it hides must be one an arrow reaches by walking onto
it. Anything nothing highlights belongs on the page, where the frame scrolls
it. The trace results were the only window over rows no highlight walks.
CLAUDE.md states the rule beside edge scroll.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The transport badge now leads each row with no heading over it. A list
whose rows declare `pans` slides its column header and every table row by
one shared shift, kept as the highlight moves and stopping where the
widest line meets the edge, so the splash box keeps its width. Rows
outside the table, like Add a network device and Quit, stay put.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Each lane was squeezed against a budget so the row fitted the box, which
cut names to "Johnp…" beside a long address. Now every lane is sized to
its longest value, the header keeps its full labels, and a row wider than
the box runs off its edge for ←→ to read. The address moves to the end.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Zooming in showed the ghost, then a black screen, then the map drawn in. The
black was a raster started the moment the view changed, before the new tile
zoom's tiles had loaded. It had nothing to draw, and being the view's own
frame it replaced the ghost. On the PicoCalc it stayed up 0.4 to 1.0 s, and
sometimes a half-drawn frame followed it before the real one. The same
happened when the map first opened.
The map now starts no raster while a tile of its view is still on its way.
It keeps standing on what it has (the aligned frame, or the ghost), and the
first raster it draws is the real picture. A tile that comes back as silence
is no longer on its way, so a map with no network still draws what it can.
Measured with a zoom tour on the PicoCalc: in to z11, z12 and z13, then back
out to z10. Before, every zoom across a tile zoom published a raster with
none of its tiles. Now each zoom draws one raster with all of them. The
finished picture arrives as soon as it did before (0.8 to 1.35 s in, 0.4 to
0.7 s out), with 6 rasters drawn instead of 13.
Tests that exercised raster scheduling now let their tiles answer first,
since a captured load used to stay on its way for ever.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A click on one of the Cardputer Zero's keys drawn under the panel, or on a
chip of the lane along the panel's bottom row, types that slot's key. The
PicoCalc has no keys drawn, so its chips are where you click. Shift held
through the click types the slot's Shift companion. The app reads the bank
off the key that arrives, not off the Shift it saw, so the window spells the
shifted key itself, the way the desktop's Shift+F-key already was: F6 to F10
on the PicoCalc, xterm's shifted F4 to F8 on the Cardputer.
The drawn keys take the lane's own fills, resolved from the deck's styles
through the panel's palette, so a key and the chip above it are one colour.
They turn blue with the lane while Shift is down, and fill solid while
pressed. Losing focus lets go of Shift, which a release in another window
never would.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Panning or zooming the map quickly on the PicoCalc could stop the whole app
for many seconds. A watchdog run on the device found two causes behind it,
plus the port walk fixed in the previous commit.
Memory. A decoded tile holds 1 to 4.6 MB of RAM on the device (65 bytes a
point), not the 0.9 MB the code assumed. The source kept up to 24 of them,
counted as tiles, and the map screen kept 8 or more of its own on top, so a
few pans and a zoom out filled a 104 MB device. Swap is on the SD card, so
the process then stopped while the kernel read its code back in: 16,000
major page faults and a 15 s freeze in one run. Now the source holds decoded
tiles to a byte budget, one eighth of the machine's RAM (12.8 MB on the
PicoCalc, at most 128 MB on a desktop), weighed by mvt.resident_bytes. That
estimate was fitted against tracemalloc on the device's 157 cached tiles: 1%
under to 9% over there, and 6% under to 21% over on a 64-bit desktop. The
screen keeps only the tiles in view, and takes any tile already in RAM
straight from the source on the paint (BasemapSource.resident), with no trip
through a thread. The prefetcher warms the disk cache (BasemapSource.warm)
instead of filling the RAM with guesses, and passes over any tile already
written down. Tile loads take turns, two at a time, and a tile the view has
left before its turn comes is dropped, not loaded.
CPU. fill_polygon asked every edge about every scanline, which at z7 means
coastlines with tens of thousands of edges: 6.8 s of a 7.6 s frame. Each
edge is now filed under only the rows it crosses, and draws the same dots
(checked against the old fill on 3,000 random polygons, and in a test).
_draw_tile also tests each ring's bounds before projecting it, and skips a
ring wholly outside the view. That changes no dot: 1,500 frames from the
device's tiles match rendering with no culling at all. The one frame that
differed from HEAD was HEAD's own building cull, which dropped a footprint
whose fill rounds onto the canvas edge.
Measured on the PicoCalc with the profile-picocalc map_burst tour (keys sent
at 10 a second, from a pinned z10 view, real radio and database). The new
code ran first, so the baseline had the warmer tile cache:
pans, catch-up after a burst HEAD 1.0-1.8 s now 0.4-0.6 s
longest silence, whole tour HEAD 11.6 s now 0.6 s
whole-process freezes HEAD 8.0, 3.1, 2.1, 11.6 s
now one, 1.6 s (idle pages swapped back in)
swap at its peak HEAD 25 MB now 7 MB
warm raster, z7 / z8 / z9 HEAD 7.6 / 1.9 / 1.8 s
now 0.57 / 0.29 / 0.81 s
warm raster, z10 / z13 HEAD 0.49 / 0.56 s now 0.26 / 0.26 s
Still open: z9 spends 0.23 s drawing lines; a prefetch decode of a heavy z7
tile is still 1.3 to 1.7 s on a worker thread; and pages swapped out while
the map sits idle can still cost a second or two to come back.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Edge scroll reached only the eight screens that answered cursor_at_edge, one
gate each; the trace screen, the autocomplete prompt and anything built
tomorrow went without. Now no screen says where its edges are. An arrow goes
to the screen like any key, and the next paint reads the answer off the page:
a highlight on the same line, drawn the same, moved nothing, so the page
takes the line instead. Comparing the drawn line, not just its index, keeps a
list that scrolls in its own window from looking stuck. Arrows pressed faster
than the screen paints are judged together. All a screen supplies is its
highlight's line in cursor_line, which keeping it in view asked for already.
The eight gates and row_at_edge are gone.
The snap-back's arrow is now the one pointing at the off-screen highlight,
read from where the paint left it, so it no longer needs to know which edge
the page went past. Home and End take the page to its ends after the screen
has handled them, without assuming the highlight followed.
The remote CLI opts out (edge_scrolls = False): the line it keeps in view is
its prompt, and its arrows recall history. The autocomplete prompt now names
its highlighted suggestion, so a short box follows it; an empty select list's
"no matches" line stands in for the highlight; and the reorder list's Home
and End jump to its first and last rows, as on every list.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Every two seconds the liveness watcher asks whether the companion's serial
port is still there, and that question is a walk over /sys/class/tty: about
30 ms of small reads on an idle PicoCalc. It ran on the event loop. Each read
hands the GIL back and has to wait its turn to take it again, and while a
worker thread is busy (a map frame being drawn, a tile being decoded) that
turn is up to 5 ms away, hundreds of times over. A freeze watchdog on the
device caught the main thread inside this walk in 20 of the 21 stack samples
taken while the map was stalled, for up to 1.2 s at a time.
It now runs in asyncio.to_thread, as the device picker's and the reconnect
dialog's walks already did; the worker pays the wait and the screen doesn't.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The September messages reached the device picker and the command line, but
three other places still lost them. The reconnect dialog retried every
failure in silence, so a device that came back and refused (its port taken
by the MeshCore app, a stale pairing) kept the spinner up forever; from the
second failure in a row it now shows the reason under the spinner, and goes
back to waiting if the device is unplugged again. A device named on the
command line skipped the picker, and a failed start was dropped unlogged; it
is now shown before the menu opens. And a failed open left the dead device
behind, so is_connected said yes and every later tool failed with "not
connected": it is dropped, and the next tool tries again and says why.
TCP failures are named one by one (host not found, nothing on the port, no
route, no answer, hung up) instead of all reading "no response from a
MeshCore companion". A failure MeshTerm has no name for is no longer called
"not a MeshCore device": it is said in its own words, its traceback is
logged once, and the dialog says where the log file is. The tool-failure
dialog stops reading an error's brackets as markup, which had silently
deleted "[org.bluez.Error.Failed]" from Linux Bluetooth errors.
docs/guide/connecting.md lists the TCP messages and where each message
appears.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
`meshterm emulate cardputer-zero --mock` and `meshterm emulate picocalc-lyra --mock`
open a desktop window drawing MeshTerm as that device's own screen draws it. An
EmulatedDevice (emulator/devices.py) holds what differs per handheld: the panel, a
Linux console's top-left grid and bold-as-bright 4-bit palette for the PicoCalc, the
lane keys drawn under the Cardputer's panel, and how each keyboard spells Shift with
an F-key (the PicoCalc's F6-F10, the Cardputer's xterm-shifted F4-F8).
It is not a strict emulator, and the docs say so wherever they offer it: MeshTerm runs
on the desktop as itself, and the window mimics the display's and keyboard's
constraints, never the CPU or the OS. Inside it the platform resolves with own_display
(platforms.drawn_by_meshterm), so nothing offers to move to another terminal.
Global options typed anywhere (--mock, --port, --db...) reach the emulated MeshTerm.
The command refuses --json like specimen. The Terminus fetch moved into the package as
`meshterm emulate --fetch-fonts` (with --archive for a copy fetched another way),
replacing scripts/cardputer-zero/fetch-terminus.py. A build without Tk says to install
with pip or pipx instead of failing.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
"Host" already meant two things here: a TCP companion's network host,
and battery="host" for this machine itself. And with a PicoCalc preview
coming, the package is less a console host than an emulator of a
handheld's display: its panel, grid, font, colours and keys. So it is
meshterm.emulator, Platform.console_host is own_display, its desktop
window is window.py (EmulatorWindow) and its device front end
framebuffer.py, since "sim" and "device" now mean the radio simulator and
the device being emulated. MESHTERM_HOST_FONTS is MESHTERM_EMULATOR_FONTS.
The package's own description opens on what it is not: nothing runs the
handheld's processor or operating system; it mimics the display's
constraints so the window obeys the device's.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
M5Stack makes three Cardputers and only the Zero runs Linux; the PicoCalc
takes several cores and only the Luckfox Lyra runs MeshTerm. So the bare
names were ambiguous, and every reference to the two devices now carries
the variant: the --platform values and MESHTERM_PLATFORM, the Platform
constants (PICOCALC_LYRA, CARDPUTER_ZERO), their lane decks and every
screen's picocalc_lyra_lane / cardputer_zero_lane, the font inventories,
the lane chips' theme styles, the scripts/ folders, the two chrome test
files, and the docs and CLAUDE.md that name them.
There is no alias: --platform picocalc is refused with the three real
choices listed, rather than falling back to the desktop layout. The
PicoCalc is auto-detected from its device tree, so it needs nothing.
What names hardware or a user's data keeps its name: the PicoCalc
keyboard's input-device name, its battery's sysfs supply, and the serial
profile the Lyra setup script writes. .gitignore follows the firmware's
folder, and the changelog keeps the words each release used.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
docs/ was one flat folder: the user guides, the CLI manual, the device
manuals, the code notes and an old survey side by side. It is now
guide/ (features, configuration, connecting, terminals), cli/ (the
manual as its README, the cookbook), devices/ (which manual is yours
as its README, then one per device) and development/ (architecture,
the survey); screenshots/ stays put. The index follows the folders.
The device manuals are named for the device they are about: the
PicoCalc's is picocalc-lyra.md, since MeshTerm runs on the PicoCalc's
Luckfox Lyra core and on none of the others, and the uConsole's stays
uconsole.md, since its CM4 and CM5 run it alike. A new cardputer-zero.md
opens on a warning that the device is not supported yet, says what has
been built and tested only in the simulator, and how to try it there.
Every relative link was resolved from where it was written and rewritten
from where it now lives, and the repo-root spellings in code, config and
the release skill moved with them; the changelog's GitHub URLs too.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The AIO's pins sit on whichever /dev/gpiochip carries the Raspberry Pi's
40-pin header, and that number is no fact about the board: chip 0 on a
uConsole's CM4, chip 4 on a CM5 under its early kernels, chip 0 once
Raspberry Pi aliased the RP1 there, and another number again on some
later kernels. gpio_chip now defaults to -1, which asks each chip for its
label and takes the one called pinctrl-rp1, pinctrl-bcm2711 or
pinctrl-bcm2835, falling back to chip 0 where none is; a number in the
profile still pins it. The chip is settled once before the node starts,
so the node, every error and the lsof hint all name the same one.
The uConsole guide says CM4 and CM5 both work, that ClockworkPi's own
A-04, A-06 and R-01 cores are not supported, and explains which chip and
why; config.example.toml and the configuration guide say the same, and
the guide's test record now names the CM5 it has run on since 09-24.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
CLAUDE.md and the platform's own comment still said the port lived on the
cardputer-zero branch. It is merged; the hardware is what is still to come.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A chart's y-axis labels got exactly the cells their widest mark needed,
so the gutter grew under the reader as a busy minute took the peak from
9 to 10 to 100, sliding the whole chart sideways. Every gutter now gets
at least three cells (AXIS_LABEL_MIN), which hold every mark below a
thousand and every compacted one, so it stays put.
The Time Machine's Rhythm heading ended on its slice width ("20-min
slices"), which on the PicoCalc's and Cardputer's 53 columns wrapped the
heading onto a second row. Where the whole heading would wrap, the slice
width goes; the axis under the chart already marks the day's hours.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The activity heading's aside ended "one minute per dot column". The
PicoCalc and the Cardputer draw braille as solid tiles, so there are no
dots there to count, and on 53 columns the words cost the heading its
line. Where braille is solid the aside is "every packet heard" alone;
the axis under the chart still marks the minutes. The desktop keeps it.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
On the PicoCalc's lane (and the Cardputer's, which deals the same) the
scope chip read "▸ yul" and the Time Machine's window chip "▸ 30 d". The
triangle took two of a chip's six cells to say what its place on the lane
already says, and cut a region's name to four. Both chips are now the
view a press goes to and nothing else, so a name gets all six cells.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
On a page taller than the screen, whatever sat above the first selectable
row or below the last could scroll away for good: the frame always pulled
the highlight into view, and nothing up there could take it. Now, with the
highlight on the first row, up scrolls the page a line instead, and on the
last, down does, until the page's real top or bottom is in view. Home and
End take the page to its ends with the highlight.
The highlight may leave the screen meanwhile, on purpose. The snap-back
brings it home: while it is out of view, the other arrow, Enter or Delete
only bring it back, and do nothing else, so nothing runs that cannot be
seen. Any other key ends the edge scroll.
It lives in Screen.edge_scroll, asked before a screen's own handle; select
and reorder lists, the node page, chat, message paths, the path composer,
records and the TX sweep answer cursor_at_edge. CLAUDE.md names the rule.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
On a short frame the bar reads the node's type glyph and its name in its
own colours, "▲ Hilltop-Repeater" where it said "Node — Hilltop-Repeater",
so the identity line under the bar said the same thing twice and is gone.
The Routes tab drops the rule under the graph there too, and both freed
rows go to the graph: its ceiling is what the chrome and the list's window
leave, so a busy fan spreads into them. A sparse fan keeps its compact
pitch, as the graph always does. Taller frames are unchanged.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The channel list's activity sparkline is the row's last column, and
where the row was too wide for the screen, the PicoCalc's above all,
the row's ellipsis cut it off mid-chart. The row now takes the render
width and draws the chart in whatever cells the lanes before it leave,
dropping its oldest buckets so now stays on the right; with no cell
left it is not drawn, and the ACTIVITY heading shortens and then goes
with it, so MSGS is never cut instead.
A row like that declares itself fitted, so the highlight draws it
fitted too rather than as a full line for the arrows to slide. And a
row exactly as wide as its list no longer claims to overflow by a cell.
CLAUDE.md states the rule for any chart that ends a row.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The channel list's activity sparkline is the row's last column, and
where the row was too wide for the screen, the PicoCalc's above all,
the row's ellipsis cut it off mid-chart. The row now takes the render
width and draws the chart in whatever cells the lanes before it leave,
dropping its oldest buckets so now stays on the right; with no cell
left it is not drawn, and the ACTIVITY heading shortens and then goes
with it, so MSGS is never cut instead.
A row like that declares itself fitted, so the highlight draws it
fitted too rather than as a full line for the arrows to slide. And a
row exactly as wide as its list no longer claims to overflow by a cell.
CLAUDE.md states the rule for any chart that ends a row.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The conversation list now reads CONVERSATION, NEW, LAST, MESSAGE: LAST
over the last message's age, MESSAGE over the message, shortening to MSG
on a narrow terminal. The live feed's timestamp lane is TIME again, and
the channel list keeps NEW.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The conversation list now reads CONVERSATION, NEW, LAST, MESSAGE: LAST
over the last message's age, MESSAGE over the message, shortening to MSG
on a narrow terminal. The live feed's timestamp lane is TIME again, and
the channel list keeps NEW.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The chat picker's unread count is headed NEW and its last-message age
WHEN; the channel list's unread count is NEW; the live feed's timestamp
lane is WHEN. Short words over a badge and an age, which UNREAD outgrew
by a cell and had to borrow the gap for. The command line's columns keep
their names: they are a documented contract of their own.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The chat picker's unread count is headed NEW and its last-message age
WHEN; the channel list's unread count is NEW; the live feed's timestamp
lane is WHEN. Short words over a badge and an age, which UNREAD outgrew
by a cell and had to borrow the gap for. The command line's columns keep
their names: they are a documented contract of their own.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The Cardputer's 14 rows had a whole one spent on the header. It has no
header row now: its unread and Watchtower badges and the battery ride the
title bar's right end, after the way out, so they sit in the top-right
corner they always had, one row up, and every screen gets that row back.
The way out gives way first and then the title, never the status. The
wordmark moves to the main menu's title, in the header's own colours, and
the activity pulse goes; the dashboard draws the mesh's activity in full.
A tall dialog now draws over the bar, eleven rows instead of ten, but
never over the lane, which is the dialog's own and names keys nowhere
else. Where a box covers the bar, the bar's ends either side of it are
blanked, since a stray "7%" beside the box would read as the battery.
JP chose the corner placement and the dialog height from rendered
mockups. The PicoCalc and the desktop are unchanged.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
