measure {mode} [value].. starts a measurement as the MEASURE menu does. The
values the menu asks with keypads are the arguments, in the same order, e.g.
measure channel_power 5800M 20M. The menu callback is reused, so the console
and the menu set up a measurement in the same way. Only in the spectrum
analyzer, as the menu.
- freq {frequency} sets zero span at the frequency, like sweep cw. It only
paused the sweep.
- hop with N points measures N points from start to stop, it measured N+1.
An invalid range no longer leaves the sweep paused.
- scan {start} {stop} also scans that range in multi-band mode and afterwards
restores the sweep points and frequencies. The stale frequency table gave a
wrong sweep stop and made the next scan very slow (27 s instead of 0.4 s).
- Remove the doubled "usage: " of the if and sd_read commands.
MODULATION -> BURST keys the generator output on and off: ON TIME of every
PERIOD, continuously or COUNT bursts. In burst mode the FREQ / AM DEPTH /
FM DEVIATION buttons set PERIOD / ON TIME / COUNT, START SWEEP becomes
START BURST (fires COUNT bursts, restarts continuous bursts) and the CTCSS
button is blank. Console: "modulation burst|period|ontime|count|trigger".
The Si4468 stays in TX with its PLL untouched: it runs OOK in asynchronous
TX direct mode from GPIO1, driven by TIM8_CH3 PWM on PB9 (one pulse mode
with the repetition counter for COUNT bursts). GPIO1 is normally the CTS
line to PB9, so while burst is selected GPIO1 is an input and CTS is polled
over SPI (READ_CMD_BUFF, the reply is read in the same transaction). PB9
only drives while GPIO1 is an input and is released before every Si4468
reset. MODEM_FREQ_DEV is set to 0 in burst mode, OOK otherwise shifts the
carrier by the deviation of the RX configuration.
- Burst works where the Si4468 makes the output (up to 1.13 GHz and the
mixer path above it), not from the ADF directly ("MOD: BURST N/A").
- Period 2us..89s, resolution about period/65536, timing from the MCU
clock (about 1%).
- The new settings fill alignment holes of setting_t: its size and the
stored presets stay valid.
F072 builds are unchanged. Tested on HW V0.5.4 with a tinySA basic in zero
span: ON level and frequency equal to CW, about 48 dB on/off ratio, COUNT
bursts exact, pulses from about 2 us.
The copyright year is 2026. The thread table of the tinySA Ultra did not
line up: the font is proportional and a space is narrower than a digit or
letter, so padding with spaces moved the columns (e.g. "idle", priority 1).
The numbers are now zero padded, the name follows them and the state is
drawn at a fixed position.
Tested on a ZS407. tinySA Ultra +16 B, BASIC unchanged.
When test 3 found no signal the hint was drawn directly on the screen and
the next redraw of the test list overwrote it (only "Did Y" remained). The
waiting line of the test list now shows "Cable connected? Touch screen to
continue" instead of "Touch screen to continue", so it is redrawn with the
list. Test 3 itself already shows the signal level fail.
Tested: on a ZS407 test 3 forced to no signal through the debugger, the
hint stays visible; the tinySA BASIC self test passes all tests and ends
with "Touch screen to continue". BASIC net about -4 B flash, +4 B RAM.
BANDS->SD stored start, end and level only, so the band names were lost.
The name is now written as a quoted fourth field (older firmware ignores
it) and loaded when present (files of older firmware keep the current
names). A line needs start, end and level: the level was read from lines
with only two fields as well.
Tested on a ZS407: band named FMRADIO stored as
0, 900000000, 0.000000000, "FMRADIO"
renamed, loaded from SD: FMRADIO again. tinySA Ultra only.
Loading a preset from SD did not call update_rbw() as caldata_recall()
does, so the RBW menu showed the preset's RBW while the sweep kept using
the previous one.
Tested on a ZS407: preset stored with RBW 30 kHz, RBW set to 300 kHz,
preset loaded from SD: "rbw" and the status panel show 30 kHz.
tinySA Ultra only, +4 B.
"ext_gain" without an argument now prints the current external gain after
the usage line, as "attenuate" and "rbw" do.
Tested on a ZS407 and a tinySA BASIC: 0.0, 12.5 after "ext_gain 12.5". +16 B.
draw_cal_status() clears the whole left panel, the battery included. The
battery is redrawn when a sweep completes, which does not happen while
paused, so after the "pause" command (it draws the status panel directly)
the battery and voltage stayed blank. draw_cal_status() now also requests
the battery redraw (not in output mode, which shows no battery).
Tested on a ZS407 and a tinySA BASIC: battery and voltage shown after
"pause". +8 B.
All units reported the ChibiOS kernel version "400" as USB serial number,
so Windows could not tell two tinySAs apart: with two of them on the same
VID/PID only one enumerated, and a unit could get another unit's COM port.
The serial number is now 12 hex digits made from the MCU unique ID the way
the STM32F303 DFU bootloader makes its serial number (UID0 + UID2, then the
upper half of UID2): a tinySA Ultra has the same serial as COM port and in
DFU mode. It is filled at every USB reset, before the host asks for it.
Windows assigns every unit a new COM port once.
Tested: ZS407 enumerates as 1781:0A44\205D346A2039 (its DFU serial), the
tinySA BASIC as 0483:5740\2056325F2039, both work side by side.
BASIC about +80 B flash, +26 B RAM.
The tinySA ULTRA enumerates as VID 0x1781 PID 0x0A44 instead of the ST
virtual COM port pair 0x0483 0x5740; the tinySA keeps 0x0483 0x5740.
The IDs now follow the model (TINYSA4) instead of the USB descriptor
variant (__USE_USB_MSC__). bcdDevice is unchanged.
Tested on a ZS405 (HW V0.4.5.1) under Windows 11: the composite device,
the serial port and the mass storage interface bind to the inbox drivers
(usbccgp, usbser, USBSTOR) without an INF, the console works on the new
COM port and "reset dfu" enters the bootloader (0483:DF11) as before.
tinySA-App with both IDs accepted connects to either firmware.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Report: in output mode, with each command sent as soon as the prompt
arrives, a command right after "output" or "modulation" (e.g. "level -30"
after "output off", or "mode low input" after "output off" twice) got no
prompt and was dropped with "Command timeout" after 20 s; the next
command worked.
Cause: after a direct command the shell set operation_requested = true,
which is OP_LEVER. The sweep thread left sweep(), found no command yet,
and ui_process() handled that "lever event" and then set
operation_requested = OP_NONE. When the shell had parsed the next command
in between (shell_function set, OP_CONSOLE set), that clear wiped
OP_CONSOLE. A zero span output mode sweep only returns when
operation_requested is set, so the command never ran. Caught on hardware
with a breakpoint on the clear: operation_requested 0x05 with cmd_level /
cmd_mode waiting, every time.
- ui_process() clears only the bit it handled, locked, so OP_CONSOLE
survives lever and touch handling (a touch, e.g. a remote "touch" from
tinySA-App, hit the same clear).
- The sweep thread clears OP_CONSOLE together with taking shell_function,
which the shell sets together, so a request left by a direct or timed
out command does not keep aborting sweeps.
- A direct command asks for the sweep restart with OP_CONSOLE instead of
a fake lever event.
- SI4432_Listen() keeps OP_CONSOLE on entry, so a command ends listen
mode instead of being lost the same way.
Tested on a ZS405 (HW V0.4.5.1): both reported sequences 15 rounds each
without a hang (release firmware: 7 of 7 hung), every reply < 0.5 s.
In zero span output mode the sweep thread loop passes once per direct
command ("output off/on", "level") and not while idle. Remote touches
mixed with commands in output mode: 10 rounds without a hang. Input mode
touch menu and sweeping work. Listen mode and the jog lever not tested
on hardware. ULTRA +88 bytes, BASIC +84 bytes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Report: after PRESET > LOAD FROM SD and STORE > STORE 1 the name keypad
opened empty, and ENTER on an empty name kept the name stored inside the
.prs file (often the old name of the slot), so the user had to look up
and retype the name of the file they had just loaded.
The keypad now starts with the name of the active preset, the same way
STORE > SD already defaults to the file the preset was loaded from:
- loaded from SD: the file name without ".prs"
- otherwise: setting.preset_name, e.g. of a recalled slot
cut to PRESET_NAME_LENGTH - 1 characters so the keypad shows what the
slot stores. An unnamed preset still opens an empty keypad. A remote
"menu" invoke ignores the default as before (ui_process_keypad).
Tested on a ZS405 (HW V0.4.5.1): an unnamed preset opens empty, a
recalled slot "RESR1" offers RESR1, and with sd_preset_path set through
the ST-Link (this unit's SD card does not mount) "FMBAND.prs" offers
FMBAND and "AIRBAND_118.prs" offers AIRBAND_1; ENTER stores the slot
under the offered name. ULTRA +68 bytes, BASIC builds.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
erikkaashoek
PhysicistJohn