A WinUI 3 desktop application for monitoring and controlling HP/Symmetricom SmartClock GPS-disciplined oscillators over RS-232.
The SmartClock family — the Z3805A and its siblings — is widely used in home and
small labs as a 10 MHz frequency and 1 PPS time reference. The receivers expose a
rich SCPI command set over a serial port, but the tools built to drive them are
Windows-9x-era applications that need serial-port shims, look badly out of place
on modern Windows, and in several cases put destructive firmware commands
directly next to harmless queries. The alternative is screen-scraping
:SYST:STAT? in a terminal emulator.
Two ideas shape this replacement:
- A glanceable primary window. The receiver's state should be readable at a glance on a second monitor that has been left running for weeks — not a reproduction of the device's 80×24 terminal screen, but a native Fluent surface.
- Destructive commands are unreachable, not merely warned about. The command catalog is an allowlist. Commands that can damage a receiver's calibration or firmware are absent from it entirely — they are not entries carrying a warning flag, and there is no dialog that leads to them.
Early development; there is no release yet, and the application does not yet
do anything useful when run. The serial transport and line protocol are
implemented and tested against a real receiver; the status-screen parser, command
catalog, design-token layer, and every view are still to come. Progress is
tracked in the issue backlog,
whose § references resolve against the specification.
| Receiver | Serial default |
|---|---|
| HP/Symmetricom Z3805A (reference device) | 9600-8-N-1 |
| Symmetricom Z3801A | commonly 19200-7-E-1 |
| HP/Symmetricom 58503A/B | — |
| Symmetricom 59551A | — |
| Symmetricom Z3816A | — |
These units share the 58503A/B SmartClock command set. Because the defaults
differ between siblings, every serial parameter is user-settable — baud, data
bits, parity, and stop bits — and the connection dialog offers an auto-detect
that walks the most likely combinations sending *IDN? until a valid identity
returns. Handshaking is always off; DTR and RTS are asserted on open. §7.1 of the
specification gives the full parameter ranges.
On ARM64 machines: the application is built for x64 only and runs on Windows on ARM under emulation. The thing that actually bites there is the driver, not the emulation: third-party USB-serial drivers frequently lack ARM64 builds — Prolific PL2303 and CH340 clones especially, while FTDI is generally fine. A serial-port driver is kernel-mode, so emulating the application does not help. If no ports enumerate on an ARM64 machine, the adapter's driver is the likely cause rather than the application.
There is no release yet. When there is, the application will be distributed through the Microsoft Store, with a signed MSIX available for sideloading. Deployment of the Windows App SDK is framework-dependent rather than self-contained, so the framework package dependency is resolved at install time (§6.3).
- .NET 10 SDK (LTS) — the exact version is pinned in
global.json;
rollForward: latestFeatureaccepts a newer patch. - Visual Studio 2026 with the .NET desktop development workload and the Windows App SDK extension. Windows App SDK 2.3.1 itself is restored from NuGet rather than installed separately.
- Windows 10 1809 (10.0.17763) or later to run; the app project builds against the 10.0.26100 SDK.
MSBuild is not on PATH by default. Resolve it with vswhere, or use the full
path:
$msb = 'C:\Program Files\Microsoft Visual Studio\18\Enterprise\MSBuild\Current\Bin\MSBuild.exe'
& $msb WinZ3805A.sln -t:Restore -p:Configuration=Debug -p:Platform=x64
& $msb WinZ3805A.sln -t:Build -p:Configuration=Debug -p:Platform=x64Prefer MSBuild over dotnet build locally. Both work, but dotnet build
does not surface XAML compiler diagnostics: a malformed .xaml fails with no
indication of which file or what is wrong, while MSBuild reports it correctly.
This repository is XAML-heavy by design, so the difference matters in practice.
(CI uses dotnet build regardless — the hosted runner's Visual Studio MSBuild is
too old to load net10.0 projects. A XAML failure in CI may therefore not name
the file; reproduce it locally with MSBuild.)
Restore is per-platform, because the runtime identifier — and so the assets file
— differs between them. The valid combinations are Debug and Release
configurations against the x64 platform. There is no AnyCPU (the Windows App
SDK is native), no x86, and — since 15 August 2026 — no ARM64: the
certification kit installs and runs what it certifies and so cannot cross-test,
and there is no ARM64 hardware to certify a submission on. See §6.1.
TreatWarningsAsErrors and EnforceCodeStyleInBuild are both on, so a clean
build produces zero warnings and a code-style violation is a build error rather
than an editor suggestion.
The app is a single-project MSIX and needs package identity to launch, so run it
from the build output rather than by starting the .exe directly:
winapp run src\WinZ3805A\bin\x64\Debug\net10.0-windows10.0.26100.0\win-x64 --detachThe transport, parser, and command catalog live in a library with no UI references, so the tests run headlessly and the plain SDK is enough here:
dotnet test tests\WinZ3805A.Tests\WinZ3805A.Tests.csprojFixtures are status screens captured from real hardware. tests/WinZ3805A.Tests/Fixtures/README.md records their provenance and which receiver states are still missing.
Two of the design-system acceptance criteria are enforced by script rather than by review. Both are dependency-free and answer in about a second, which makes them the fastest local check available — CI runs them before any restore, so a regression fails in seconds instead of after four builds:
pwsh build/Test-NoHexLiterals.ps1 # no hex colour literals outside Themes/Colors.xaml
pwsh build/Test-IconOnlyButtons.ps1 # icon-only controls carry an automation name and a tooltipRun them before pushing.
docs/requirements.md the specification
src/WinZ3805A/ WinUI 3 app, single-project MSIX
src/WinZ3805A.Device/ class library — no UI references
tests/WinZ3805A.Tests/ xUnit, with Fixtures/ for captured status screens
build/ the two CI gate scripts
The Device library has zero dependency on Microsoft.UI.*. All parsing,
command classification, and transport lives there, which is what makes the
highest-risk logic testable without a UI.
- docs/requirements.md is the specification. It is
the authority on behaviour, and the
§references in issues, commit messages, and code comments resolve against it. Where anything else disagrees with it, the document wins. - CLAUDE.md carries the working conventions for the repository.
Both are linked rather than restated here, so there is one authority per fact.
WinZ3805A is the repository, solution, root namespace, and MSIX package
identity name. The Store display name is deliberately a separate thing that can
change at any time, so it is read from the package manifest at runtime and never
hard-coded (§6.3).
The name contains a model designation rather than a company mark. This project is not affiliated with, endorsed by, or sponsored by HP, Hewlett-Packard, Agilent, Keysight, or Symmetricom; those names appear here only to describe the hardware the application talks to.
MIT.