Logbook

After the introspection analysis showed poor cluster separation in the t-SNE embedding, I went back through the capture dataset and cleaned up misleading captures — removing mislabelled signals, duplicates, and captures where the signal was barely visible above the noise. The improvement was immediate and significant: the silhouette score went from −0.114 (misclustered) to −0.027 (barely overlapping) — a 4× improvement. FM's intra-class spread dropped from 38.06 to 34.51, exactly as predicted in the previous post, and three FM-related confusion pairs improved substantially. The updated t-SNE projection below tells the story:

The overall embedding space has moved from "misclustered" to "barely overlapping," and more cleaning of the dataset should improve things further still.

Since my last post on derived spectral features and the decision to pivot away from augmentation toward more over-the-air captures, I've been using the Verulam ARC's remote IC-9700 to generate clean, labelled signals across the missing modes. The capture count has grown from 403 to 675 training samples across 10 active classes. With the expanded dataset in hand, I wanted to understand what the model has actually learned — not just its accuracy number, but where it succeeds, where it fails, and why. Three analysis tools gave me a clear and consistent answer: Class Activation Maps (CAM) for the convolutional layers, t-SNE embedding visualisation of the 128-dimensional representation the model produces just before its classifier head, and a statistical analysis of the auxiliary feature vector.

Conv Activation Maps

The Class Activation Map below compares which conv channels fire for FM versus AM — two modes that look very different to a human operator but can be tricky for a classifier to tell apart.

FM and AM fire largely different conv channels. AM activates the "wide signal with structure" filters — its carrier with symmetrical sidebands spreads energy across the patch. FM activates the "narrow signal" filters — the same ones CW uses, because FM's frequency-modulated carrier looks like a single spike to the CNN. The aux analysis confirms this: spectral kurtosis is the best FM-vs-AM discriminator (|d|=1.89), because AM's peaked spectrum (0.736) is very different from FM's flat-top (0.321). The separation is real, though without an ablation experiment I can't say how much comes from the pixels versus the metadata.

The key takeaway: the conv layers can distinguish FM from AM, but only through a small number of channels. Only 2 of 56 conv filters across all three layers are dead; several are discriminative, but most fire generically on both classes. The useful signal is concentrated in ch22 (AM's "wide structure" detector) and ch0/ch16 (FM's "narrow signal" detectors). This is why the model needs the aux features to get the full separation that the pixels alone can't provide.

t-SNE Embedding Space

The t-SNE projection below visualises the model's 128-dimensional embedding — the internal representation it builds before the final classification layer. Each point is a training candidate, coloured by its true label. If the model had learned a clean representation, each class would form a tight, well-separated cluster. The reality is messier.

An important caveat: this is not a pure view of the conv path. The hook captures the output after the conv features (3072-dim) and aux features (13-dim) have been concatenated and projected through a linear layer to 128 dimensions. The aux contribution is already baked in — the t-SNE is visualising the fused representation, so it can't tell us which path is doing the work.

Overall: poor cluster separation. Silhouette score = −0.114 (negative = misclustered, 0 = overlapping, 1 = perfect). The model's learned 128-dim representation does not cleanly separate the signal classes. Only 24.5 of 128 dimensions are active per sample on average (post-ReLU). 76 dimensions are completely dead — always zero across all 675 samples. 52 dimensions are ever active at all, meaning the classifier head is operating in a much smaller effective space than its architecture suggests.

RTTY is the most separated class — its centroid distance to the nearest class (JT65) is 74.3, far from all others (>90). RTTY's centroid norm (107.6) is 2–3× larger than any other class. The model strongly distinguishes RTTY's two-tone structure. At the other end, the least separated class pairs — the ones the model most confuses — are:

FM ↔ AM distance = 43.3 — moderate, not close. RTTY aside, most class pairs sit between 20 and 40, which is why the overall silhouette score is negative: the clusters overlap more than they separate.

FM has the highest intra-class spread (38.06) — FM captures are scattered across the embedding space rather than forming a tight cluster. This likely reflects FM's 222 samples coming from diverse conditions: repeater vs simplex, different spans, varying SNR. The model is learning FM-specific features that vary across capture conditions rather than modulation-invariant ones. More diverse FM captures would help consolidate the cluster.

Auxiliary Feature Analysis

To complement the visual introspection, I also ran a statistical analysis of the 13 auxiliary features (the metadata the model receives alongside the image patch) to see which ones actually carry discriminative power. The table below summarises how each signal type is best differentiated from all others:

What It All Means Together

Three tools — the class activation maps, the t-SNE embedding, and the auxiliary feature analysis — all point to the same conclusions:

1. The conv channels show few class-specific patterns. Only 2 of 56 filters across all three conv layers are dead (3.6%), and several are discriminative — but most fire generically rather than tuning to specific signal types. The t-SNE shows that even with both image and metadata combined, the classes still don't separate cleanly.
2. CW and FT8 are nearly impossible to distinguish at typical scope spans. All three tools agree: the conv layers see them as the same narrow spike, the t-SNE puts them closest together, and the best metadata feature (center_freq_offset_hz, |d|=1.30) separates them mainly by where the operator placed the signal, not by modulation. There is a physics-based separator — spectral periodicity also separates them (|d|=0.72, CW's on/off keying creates stronger periodicity) — but it's weak. At the spans most operators use, FT8's 8 tones are narrower than a single pixel. The model can't tell apart what it can't see.
3. FT8 vs FT4 is the hardest pair of all. Both modes use the same 6.25 Hz tone spacing, which is narrower than one pixel at any practical scope span. Even the best metadata feature (spectral_flatness) only achieves weak separation (|d|=1.29). This pair may benefit from the temporal envelope CV feature — FT8's structured 15-second transmission cycle has a different on/off pattern to FT4's faster 4.48-second cycle, so the temporal envelope should help distinguish them where the spectral features can't.
4. 76 of the model's 128 internal dimensions are dead. They're always zero post-ReLU, meaning their pre-ReLU values are always negative — a training artifact, not necessarily architecture waste. The average sample uses only ~25 dimensions; 52 are ever active across all samples. Shrinking the architecture from 128 to 64 would reduce parameters, but those dims might become active with more diverse data or different training. The overfitting gap (85% on training vs 66% on validation) is more likely caused by the small, imbalanced dataset (675 samples, FM=222 vs FT4=37) than by architecture size.
5. The noise floor feature is useless. It's virtually identical across all signal types (~0.062) and contributes no discrimination at all. It's taking up a slot in the metadata vector for nothing. Removing it would tighten the model's input without losing anything.

What This Means for Next Steps

The introspection confirms the direction I set out in my previous post. The model's weaknesses are not in its architecture — they're in the data. The pixels don't contain enough information for the hardest pairs, and the metadata is carrying much of the load. The remaining work is:

• More over-the-air captures for the under-represented modes — particularly AM, RTTY, PSK, MSK, and the other zero-sample classes. The Verulam ARC radio has been invaluable for this.
• More diverse FM captures — different spans, SNRs, and signal conditions rather than more of the same. FM's 222 samples are the largest class but also the most scattered in the t-SNE, with the highest intra-class spread (38.06). Capturing FM at a wider range of spans and conditions would help the model learn what's consistent about FM rather than what's consistent about how I captured it.
• Drop the dead weight. Remove noise_floor from the metadata — it's identical across all signal types and contributes nothing. This tightens the input from 13 to 12 channels.
• Consider shrinking the model. Reducing the embedding dimension from 128 to ~64 might reduce overfitting, but it's secondary to more data and better class balance. The 76 dead dimensions are a training artifact, not necessarily waste — they might become active with more diverse data. The bigger lever for closing the train/validation gap (85% vs 66%) is likely the small, imbalanced dataset, not the architecture size.

Progress, but still work to do. The three analysis tools have given me confidence that the architecture is sound and the feature engineering is targeting the right problems — the path forward is more data and better class balance, not a fundamentally different approach.

My earlier post on data augmentation for Pycom's signal classifier laid out a plan to synthetically expand my small 403-sample training set with on-the-fly transforms. After more thought I realise that the plan never really sat right with me. Creating frankenstein like patches is not something I'm comfortable with, I've changed direction. Augmentation may still be on the roadmap, but it's no longer the next step — and the reason comes down to a resolution problem that augmentation can't fix.

The Resolution Problem

The IC-9700's scope produces 475 frequency bins. At the spans most operators use (5–25 kHz), each bin covers 10–53 Hz. The tone spacing of FT8 and FT4 is 80-90 Hz, and JT65's is 400 Hz — many tones of a multi-tone signal collapses into less than one bin.

Side-by-side (FT4 left | FT8 right), row 0 = newest frame:
 Legend: space=<0.05 .=0.05-0.15 :=0.15-0.25 -=0.25-0.35 +=0.35-0.45 *=0.45-0.55 #=0.55-0.70 @=>0.70

|                                ::                              |  | .  ..            .    .  ....*@@@..   ... ..  .     .  .   .   |
|                                 .:.                            |  | .. ..      .       .  .   . .#@@@...   ..   .    ...     .  .  |
|                               ......                           |  |             . .            ..#@@#.   .. .       .  .          .|
|                                .:..                            |  |     .         .     . . . ..:#@@@:.  . .  .  .      .. .   .  .|
|                                ..:                             |  |    .  .   .  .            ...*@@@......    .    ...    ...     |
|                                 ...                            |  |       ..  ..  . .   .     ...#@@@:... . ..  .  .               |
|                               ....                             |  |  ...            .          .:*@@@:...       ..   .  .   . .    |
|                                ..:.                            |  | ..  . .    .  . .     . . ...*@@@...        .    . ..      ..  |
|                                 ::                             |  |.     . .    .   .     ..   ..#@@@:...                          |
|                               .:.                              |  |   .                      ....#@@@.....     .       ..        . |
|                                                                |  |  . . ..    .  .     . .  . ..#@@@...           .   ...       . |
|                                                                |  |   .. .      .     .    .   ..#@@@.. . . .       .  . . . .     |
|                                                                |  |   .      .         .      ...*@@@: .   .    .           .    ..|

ASCII waterfall visualisation showing side-by-side FT4 (left) and FT8 (right) tone patterns over 13 frames. The FT4 tones appear as faint scattered dots; FT8 tones form bright concentrated clusters (@ symbols) in these examples. Both signals occupy a narrow vertical stripe, illustrating that individual tones cannot be resolved at typical scope spans.

The 100×64 waterfall patch fed to the CNN shows a narrow vertical stripe with no resolvable tone structure at all. No amount of amplitude scaling, noise injection, or frequency shifting will conjure detail that isn't in the pixels to begin with. Augmentation diversifies the views of information the model already has; it doesn't add the information the model is missing.

Given my small sample data set and obfuscation of the signal captured over the air:

• Information the CNN can't extract → solved by derived spectral features: seven statistical descriptors computed from the 100-frame scope history that capture modulation characteristics invisible in the image patch.
• Classes the model has never seen → solved by more over-the-air captures: eight of Pycom's fifteen supported modes have zero training samples, and the remaining seven are badly imbalanced (FM 160, SSB 9). No feature engineering fixes a class the model has never been shown.

Seven Derived Spectral Features

The auxiliary feature vector fed to the classifier alongside the image patch has grown from 6 channels (span, reference level, noise floor, bandwidth, frequency offset, SNR) to 13. The seven new descriptors are computed from the signal's averaged spectrum and temporal envelope in under a millisecond per candidate. Each one captures a different aspect of spectral shape that the CNN patch cannot resolve at typical scope spans:

Taken together, the seven features improve 9 of the 10 measured confusion pairs (signals that the model otherwise confuses eg; FT8/FT4). The one holdout is FT8 vs FT4 — both use 6.25 Hz tone spacing and collapse to the same sub-pixel width at every span above 2.5 kHz. The only real difference is occupied bandwidth (FT8: 80 Hz, FT4: 90 Hz), which is weakly captured.

More Over-the-Air Captures

The remaining weakness isn't an architecture problem — it's a data problem. Eight of fifteen supported modes (AM, RTTY, FT2, Q65, PSK, FSK, MFSK, MSK) have zero training samples, and the seven that do exist are heavily skewed toward FM and JT65. No feature, however well-engineered, teaches a classifier a class it has never been shown. The fix is to generate more labelled over-the-air captures, particularly for the under-represented modes.

To that end I have reached out to the Verulam Amateur Radio Club who have kindly agreed that I can use the remote Icom 9700 — so I can transmit clean, labelled examples of AM, RTTY, PSK, MSK and the other missing modes and capture them directly through the IC-9700's scope, without having to endure the cost of purchasing a second radio. This gives data without relying on whatever happens to be on the bands, and lets me balance the class distribution deliberately rather than opportunistically. The earlier O'Shea et al. (2018) finding still stands — models trained on clean data degrade over the air — so once the class-coverage gap is closed with real captures, the augmentation transforms from the previous post (noise injection, frequency shifting, Mixup) may come back to harden the model against the SNR, carrier-offset, and multipath variation it'll meet at inference time.

It's about time. Pycom's next release will allow you to submit satellite status reports directly to AMSAT — no need to switch to a browser to log that you heard (or didn't hear) a satellite. The new AMSAT Status dialog shows current satellite status at a glance, auto-fills your callsign, grid square, time and the tracked satellite from S.A.T (if in use), and submits reports with a single click.

Two influential papers in Automatic Modulation Recognition (AMR) provide clear guidance for improving Pycom's signal classifier. O'Shea, Roy & Clancy's Over-the-Air Deep Learning Based Radio Signal Classification (IEEE JSTSP, 2018) demonstrates that models trained only on clean, ideal data degrade dramatically when deployed over the air, where carrier frequency offset, varying SNR, and multipath effects conspire to confuse the classifier. Li, Wang, Dong & Wang's Data Augmentation for Automatic Modulation Recognition (IEEE Wireless Communications Letters, 2025) shows that targeted augmentation — particularly noise injection, channel impairment simulation, and synthetic data generation — significantly improves classification accuracy, especially for underrepresented signal types at low SNR.

Pycom's architecture already mitigates the worst of the over-the-air pitfalls: the center_freq_offset_hz auxiliary feature directly encodes the carrier offset that was identified as the primary error source, and the six-channel auxiliary input (span, reference level, noise floor, bandwidth, frequency offset, SNR) gives the model explicit metadata about signal conditions rather than forcing it to infer everything from pixels. Bandwidth-aware centred patch extraction normalises the view regardless of mode width, and WeightedRandomSampler balances class representation during training. What both papers make clear is that architectural design alone isn't enough — the model also needs to see the full range of variation it will encounter at inference time, and that's where augmentation fills the gap.

The current ScopeCNN-Patch (Convolutional Neural Network) model was trained on just 403 samples across seven active signal classes — FM (160), JT65 (95), CW (73), FT8 (35), FT4 (17), AFSK (14), and SSB (9) — achieving 77% validation accuracy. Eight of the fifteen supported modes have zero training data. This severe class imbalance means the model can recognise strong FM and CW signals reliably but struggles with underrepresented modes like SSB and FT4, where it simply hasn't seen enough variation to generalise. The augmentation approach directly addresses this: rather than requiring hundreds more captures (which means more time at the radio, and potentially investing in something like an IC-7100 so I can generate my own signals to capture), we can apply five on-the-fly transforms during training that synthetically expand each sample into many unique training views. The model sees different augmented versions of the same signal every epoch, teaching it that the same mode can look different under varying conditions.

Augmentation would be enabled by default for training from scratch and disabled for fine-tuning to preserve the feature distribution the frozen layers expect. The expected improvement is from 77% to 80–85% overall, with the biggest gains on minority classes like SSB and AFSK.

The waterfall now includes a colour-coded band plan strip showing IARU allocations for your region. Hover any segment to see its category and description — no more guessing which part of the band is reserved for CW, where the satellite sub-band starts, or whether that frequency is in the FT8 window.

Multi-Region Support

Band plans differ across the three IARU regions. Pycom ships with allocations for all three, sourced from RSGB (Region 1), ARRL (Region 2), and the IARU Region 3 interim band plan. Select your region in Configuration → General → IARU Region and the display updates immediately — no restart needed.

Categories

The band plan strip uses 15 colour-coded categories so you can identify segments at a glance:

CW, All modes, WSPR, FT8, FT4, FM, Repeaters, Beacons, Satellite, EME, Digital modes, SSB, ATV, APRS, and DX. Shared calling frequencies (like FT8 at 144.174 MHz) appear in all regions regardless of your selection.

Customising the Band Plan

The band plan data is stored in bandplan.csv in your Pycom configuration directory (~/Pycom/ on macOS, %USERPROFILE%\Pycom\ on Windows). The file is modifiable — edit it to add, remove, or change allocations to match your local band plan. Pycom will replace it with the default on start-up only if the file doesn't exist; your changes are never overwritten.

Full 70cm Coverage for Region 2

Region 2's 70cm allocation spans 420–450 MHz, wider than Regions 1 and 3 (430–440 MHz). The band plan strip and frequency labels cover the full range, so Region 2 operators see their complete allocation on the waterfall.

Pycom has evolved from a repository where every line of code was written manually to a fully agentic development stack. Using opencode — a CLI-based AI coding environment — backed by the Ollama Pro plan with access to the GLM-5.1 Cloud model (currently around £15/month), the project now operates with custom skills, specialised agents, structured expertise management, and automated quality gates that keep the codebase consistent and the protocol layer correct. The combination of opencode's skill system and a capable cloud-hosted model means every session starts with deep project context and ends with consistent, reviewed and tested code.

From Solo to Agentic

In the early days, every feature, bug fix, and protocol implementation was hand-coded and tested against the radio. The codebase has grown to over 25,000 lines across 40+ modules, with a CI-V command reference spanning 542 commands. Managing that complexity manually was becoming unsustainable. Today, opencode is configured with persistent context — AGENTS.md, docs/CODING_STANDARDS.md, and docs/PR_REVIEW_CRITERIA.md — that guides every session. These files encode project conventions (decimal-nibble encoding rules, threading constraints, naming standards, read-only library boundaries) so that the AI agent produces code that is consistent with the existing codebase from the start, rather than needing correction afterwards.

A dedicated expertise manager called mulch records patterns, failures, decisions, and conventions across sessions. Before each task, opencode queries mulch to avoid re-introducing known-bad patterns or repeating investigations that were already resolved. Findings are recorded under domains like gotchas, architecture, connection-flow, and scope-protocol, building a living knowledge base that persists between conversations.

Custom Skills & Tools

opencode skills provide domain-specific expertise on demand. Each skill is loaded contextually — when a question or task matches its domain, the full skill instructions and reference data are injected into the session. The table below shows the skills currently configured for Pycom:

Specialised Agents

Beyond skills, opencode is configured with dedicated subagents that handle specific workflows autonomously:

• PR Reviewer — Analyses pull requests and diffs against project standards (coding conventions, threading rules, CI-V protocol constraints, read-only boundaries). Catches architectural violations before merge.
• Docs Maintainer — Audits documentation for staleness, duplication, and inconsistency. When features change, it updates the relevant docs to stay in sync with the code.
• Test Runner — Discovers and runs the appropriate test modules, interprets failures, and suggests fixes. Knows the project's pytest configuration, coverage targets, and SerialMock patterns.
• Explore Agent — Fast codebase search for files, patterns, and architectural answers. Used when you need to find "where is X implemented" or "how does Y work" without reading every file.

Two Repositories

Pycom's codebase is split across two repositories:

• pycom-radio-controller — The main application repository. Contains the GUI, radio controller, signal detection, satellite tracking, configuration, and all the agentic tooling described above.
• ICOM_UDP — A separate repository containing the ICOM UDP transport library. This provides scope data parsing, audio streaming, and network-based CI-V communication for radios with built-in Wi-Fi/Ethernet.

The UDP library is copied into the main repo at lib/icom_udp/ as a read-only dependency. Files are set chmod 444 to prevent accidental edits. All changes must be made upstream in the ICOM_UDP repository first, then synced via scripts/sync_icom_udp.sh. This separation ensures the library can be developed and tested independently while keeping the main repo's copy in sync.

Self-Hosted Gitea

All source control, CI, and issue tracking runs on a self-hosted Gitea instance. The setup provides:

• Git hosting — Private repositories for both pycom-radio-controller and ICOM_UDP, with full branch and merge management.
• CI Action Runner — A Gitea Actions workflow (.gitea/workflows/pyinstaller.yaml) builds distributable packages on every push to main. It produces a macOS .app bundle and a Windows .exe, both packaged for distribution. The build excludes dev-only dependencies (pytest, coverage, flake8, torch) via --exclude-module flags.
• Issue tracking — Bugs, feature requests, and milestone tracking (including the UDP transport migration plan) are all managed in Gitea Issues.

Test Suite

The Pycom test suite is built on pytest with hardware-free testing as a core principle. Since the app communicates with a physical ICOM IC-9700 via serial, every test must work without the radio connected:

Every test run creates a fresh virtual environment via scripts/run_tests.sh, installs dependencies, runs the full suite with coverage, and tears down — ensuring no contamination between runs. Coverage targets range from 90%+ for protocol/encoding code down to 40% for GUI code, with an overall target of 75%+.

The Agentic Advantage

The transition from solo manual coding to agentic development has fundamentally changed the pace and quality of Pycom's delivery. In the months since adopting the opencode stack, features that previously took weeks of careful manual implementation — each requiring protocol reference lookups, encoding verification, threading audit, and manual testing against the radio — now ship in days or even hours. The CI-V Explore skill eliminated constant context-switching to the ICOM manual; the pcap debugger turned hours of trace analysis into minutes; mulch ensures that hard-won knowledge about decimal-nibble gotchas and threading constraints is never lost between sessions.

Recent feature velocity illustrates the shift: AI signal detection and classification with a trainable ONNX model and 15-mode classifier, 542-command CI-V coverage with validated encoding reference, full UDP transport library integration for network-based radio control, and a redesign of the main display tab with enhanced support for dual transceivers — all developed and merged with AI-assisted code review, automated testing, and structured expertise management. The test suite alone grew from zero to 45+ test files covering protocol encoding, command queues, signal processing, configuration, and regression guards — something that would have taken far longer to build manually.

The key insight: agentic development doesn't replace understanding — it amplifies it. The project's AGENTS.md, coding standards, and mulch expertise records ensure the AI operates within well-defined constraints, while the specialised agents handle review, documentation, and testing that would otherwise be bottlenecks. The result is a system that allows me to test ideas and ship faster without cutting corners.

Pycom can automatically detect signals on the waterfall and classify them using a built-in AI model — no manual scanning required. Configure sensitivity with three presets or eight tuneable parameters, capture signals for review, and train your own model from real off-the-air data. See the Signal Detection, AI Identification, and Signal Reference pages for full details.

Signal Detection

The statistical detector runs in real time alongside the waterfall, finding signal groups that stand out from the noise floor. Choose from Normal, Sensitive, and Strong Only presets, or adjust individual parameters like detection percentile, and minimum contrast Z to suit your operating conditions. Detection is automatically suppressed during transmit to prevent overloading the detector.

Signal Capture & Labelling

Detected signals appear in the capture window sorted by frequency. Select any candidate or drag select a section on the waterfall to inspect a specific signal, then assign a label from the 15 supported signal types — or mark it as Unknown. Add notes, adjust the label, and capture as many examples as you need to build a training dataset.

AI Classification

The built-in ONNX neural network classifies detected signals against 15 mode types including CW, FM, FT8, JT65, SSB, and more. A confidence threshold (default 50%) filters out uncertain predictions. The distributed model achieves 77% validation accuracy on signals with training data at present, and you can reload a fine-tuned model without restarting the app. As I capture more signals, they will be automatically added to new distributions of the application. Contact me on Discord and share your classified signals for them to be included in the application.

Train Your Own Model

Collect captures, label them, and retrain the classifier to recognise the signals you encounter on your own bands. Use python retrain_model.py --fine-tune to add your data to the distributed base model, preserving what it already knows while learning new patterns. Or train from scratch for full control. Quality warnings alert you to class coverage gaps, data imbalance, and accuracy regression before the new model is deployed.

The Status tab includes a CI-V command executor for sending raw commands directly to your IC-9700. This is useful for experimenting with commands that aren't exposed in the GUI, reading radio state, or diagnosing communication issues.

How It Works

The command field is pre-filled with the CI-V preamble and addresses (FE FE A2 E0 in my case). Enter your command and data bytes after the preamble, add a terminating FD, then click Execute CI-V Command. The radio's response (or an error message) appears in the status text area above.

Examples

The full CI-V command reference contains over 540 commands refer to the ICOM IC-9700 instruction manual for complete details on data encoding.

The UDP transport library has now been fully integrated into Pycom. Network connectivity is available in the latest release — see the download page.

The video below shows a fully implemented library that I've created for using the radios built in Wi-Fi/ethernet server over the network. I'm currently working on integrating this with Pycom so that it's no longer tied to a USB connection. Benefits include integrated audio and faster responsiveness including scope.

Pycom can log every S.A.T update to with precision, along with WSJTX log files it's possible to create polar plots for multiple satellite passes from your base station. At the default one-second polling interval, each entry captures the satellite's position, applied doppler, and the exact frequencies in use at that moment:

2026-01-30 21:09 INFO [Pycom.lib.csnsat.csnSatManager] Timestamp: 21:09:40, Sat: RS-44, Az: 202.978245, El: -0.136604, Range km: 4338.595298, Main: 435620549, Sub: 145990135, Doppler up: -2865, Doppler down: 8549, Doppler up rate: 0, Doppler down rate: 0, Offset: 0, Tracking: Reverse, Freq Scaling: OFF, RIT: OFF, RIT Freq: 0

Dual WSJT-X Instances

Two instances of WSJT-X run simultaneously — one to generate and transmit FT4, the other to receive and decode the repeated signal. This is set up by duplicating the WSJT-X shortcut, renaming it (e.g. wsjtx - RX), and appending --rig-name=None to the target. Each instance maintains its own log directory, accessible from the file menu.

WSJT-X communication logs are stored in ALL.txt and contain precise timing, frequency, mode, SNR, and offset for each decoded message:

            260123_102722   435.118 Rx FT4     -1  0.3 1081 CQ DL3NGN JN59
            260123_102730   435.118 Tx FT4      0  0.0 2245 CQ M0SNZ IO91
            

Post-Pass Analysis

Scripts for post-pass processing and creating polar plots of satellite passes are available at github.com/stevendodd/Sat-Analysis.

Pycom now fully supports network connectivity and is no longer tied to USB. See the radio setup guide for network connection details.

Initial Local Installation

Remote Setup

Remote Audio Chain