SDR# SDRTW — Python-to-Rust Migration and Decoder Progress

[Quint-1-29]

SDRTW is still under active development and is not yet available for public testing, but the application is already working well in several areas.

One important lesson from development was that replacing the Python voice path with Rust finally produced reliable audio after many unsuccessful tests. Based on that result, I am now systematically replacing the remaining Python-owned components with Rust. The goal is to determine whether moving time-sensitive processing, application services, and hardware coordination into native code resolves the remaining performance and reliability problems.

Current protocol status:

• P25 Phase 1: Working
• P25 Phase 2: Working; Tested with UHF & 7/800 Systems; Harris systems remain a work in progress
• DMR: Voice decoding works but still needs refinement
• NXDN: Implemented but still requires live-system testing

The migration is being performed one complete subsystem at a time. Each Rust replacement must be integrated and tested before the corresponding Python implementation is removed. The final public test build will run without requiring or bundling Python.

Current priorities include improving decoder stability, completing Harris P25 support, refining DMR audio, validating NXDN with live traffic, and finishing the Rust migration without introducing duplicate processing paths or temporary patchwork.

 

[Quint-1-29]

A progress update on SDRTW since my September 17 post: the current application launch and service now run through Rust, and the current Windows package passes an inspection for Python executables, libraries, and bytecode. I still need to complete the release validation on a machine without Python before calling the no-Python requirement finished.

Live P25 testing has moved forward. A recent six-hour 800 MHz run maintained native control-channel decoding, processed grants, opened voice sessions, and delivered decoded PCM to the speaker path. I’m also testing a UHF and a Harris 700 MHz system. The Harris system gave me trouble at first, but it’s now performing just as consistently as the others. These systems provide different conditions for finding general decoder and follow-state problems; the fixes are intended to work across all systems.

P25 Phase 1 and Phase 2 remain the main focus. Some calls still fail to produce audio, and the audio proof checks need more work before I can call playback consistently reliable. Harris behavior remains under active testing. DMR voice works but needs refinement, and NXDN still needs live-system validation.

SDRTW is still under development and is not ready for public testing. I’ll post another update when the remaining live and clean-machine release checks pass.

 

[dickie757]

What radio(s) are you testing/using?

 

[Quint-1-29]

Main unit right now is the AirSpy R2. The others RTL-SDR Blog V3, & Nooelec RTL-SDR v5 were paired together, one on VC's and the other held on the CC.

 

[dickie757]

Thanks for reply. Nice to see "normal" receivers.

 

[Quint-1-29]

Haha, yes—some “normal” receivers for a change! The AirSpy R2 is my main unit now. I used the RTL-SDR Blog V3 and Nooelec V5 as a two-receiver setup, with one on the control channel and the other following voice. I’m still testing SDRTW across different systems; The Harris System voice is sounding noticeably clearer in the latest run. Which is still running as I type this.

 

[Quint-1-29]

September 26 update — the native path is now producing sustained results

SDRTW’s production application path is now Rust-only. Startup, the service host, receiver ownership, control-channel decoding, call following, audio output, recording, and the web UI are running through the Rust service. The packaged build contains no Python interpreter, Python DLL, bytecode, frozen archive, or PyInstaller loader.

A live test tonight ran for approximately 4 hours 47 minutes:

• 172.2 billion hardware IQ samples processed
• Captured time within 0.01% of wall time
• Zero native IQ overflow drops
• 688,464 valid TSBKs
• 19,005 normalized grants
• 338 voice sessions opened successfully
• 210 calls produced voice codewords and admitted PCM
• About 17.2 minutes of clear PCM decoded
• 210 native recordings opened and finalized without errors
• Speaker delivery accounting reconciled with zero unexplained samples
• 328,475 spectrum frames, averaging about 19 FPS
• Clean shutdown with no queued audio discarded

This is a major improvement over the earlier baseline, where no audio reached the speaker and billions of samples were being dropped.

It is not finished yet. Of the 338 opened voice sessions, 128 never produced codewords. The output also recorded 193 active-voice underruns and approximately 47.7 seconds of missing output across the run. Those continuity gaps, along with a remaining inconsistency in the decoder identity ledger, are the next targets.

One clarification regarding the migration: Python has now been fully removed from the repository—not merely from the production runtime. The application, DSP, diagnostics, tests, development tooling, and packaged release are all native, with no Python interpreter or Python source remaining. Rust has grown from 23.7% to 87.4% of the repository’s language composition, completing the Python-to-Rust migration.

So the current state is: live native IQ, control decoding, grants, call following, native audio, recordings, and clean shutdown are all functioning. The focus has shifted from “make the path work” to improving call capture and eliminating audible gaps.

 

[Quint-1-29]

October 2 update — P25 audio continuity has improved substantially

Since my last update, the main focus has been eliminating interruptions during active P25 calls. Recent live testing shows a substantial improvement in both Phase 1 and Phase 2.

Recent live testing across three local counties included three runs. All three systems support P25 Phase 2, and the two Motorola systems also carry Phase 1 traffic.

• Phase 2 700Mhz (Harris) — approximately 4 hours 26 minutes: 479 voice sessions opened successfully, and 407 produced decoded audio. One 10 ms mid-call playback gap occurred. Peak playback latency was 980 ms, with no latency resynchronizations.
• Phase 1 UHF (Motorola) — approximately 2 hours 4 minutes, with 269 voice sessions opened. The initial 32½-minute test recorded zero speaker gaps and a peak playback latency of 900 ms. The longer 1-hour-31½-minute test produced audio in 101 sessions and recorded one 110 ms playback gap. Both runs passed speaker delivery accounting and ended with clean application shutdowns.
• Phase 2 800Mhz (Motorola) — approximately 2 hours 17½ minutes: 724 voice sessions opened successfully, and 481 produced decoded audio. Six gap events were classified as final-tail behavior rather than interruptions that resumed with new decoded speech. Peak playback latency was 830 ms, with no latency resynchronizations.

All three runs passed speaker delivery accounting, reported zero IQ overflow drops and recording errors, and shut down cleanly.
The improvements come from revised native audio buffering, including a 720 ms startup buffer and brief holdover to bridge short interruptions in decoded audio delivery. Earlier tests recorded dozens of mid-call interruptions; the latest runs recorded one brief gap in Phase 2 and none in Phase 1.

The Rust service and audio components have also been reorganized into smaller modules to make continued development and testing easier.

These runs pass the audio-continuity checks for their tested durations. They do not mean every call is captured perfectly or that every supported protocol is fully validated. Longer Phase 1 testing and investigation of calls that open without producing audio remain on the list.

SDRTW is working much more consistently now. I’m continuing validation before announcing a public test build.

I’ve also moved back to the main STW project, where I’m migrating the remaining Python-owned components to Rust. Each feature is being tested after Rust takes ownership to verify that it works correctly before moving on.

 

[Whiskey3JMC]

SDRTW is working much more consistently now. I’m continuing validation before announcing a public test build.

Screenshots or a demo video would be nice. Is this an SDR# plugin or a standalone app?

 

[Quint-1-29]

Standalone app mostly in Rust.

 

[vince48]

well if i had a electron microscope, i might be able to look at the picture. Its too small?

 

[dickie757]

SDRTW

well if i had a electron microscope, i might be able to look at the picture. Its too small?

.....The Long Way

 

[Quint-1-29]

Lol, sorry for the tiny screenshot! Here are five screenshots of the app running. It would take eight or nine to show the entire interface while running.

 

[Quint-1-29]

Here a better look at the Activity Panels.

 

[Quint-1-29]

October 3 update — Complete conversations captured in live testing

Quick SDRTW update: live P25 testing continues to improve. Recent recordings preserved complete back-and-forth exchanges between units, including longer conversations, with no missing speech that I could hear. Playback sounds comparable to my scanner.

Trace checks confirmed that those calls stayed intact through speaker changes and that all admitted audio was recorded. Some reported gaps appear to be normal pauses between transmissions. A few calls still open without producing audio, so acquisition remains under investigation.

I’ve also returned to the main STW project, migrating Python-owned components to Rust and testing each feature once Rust takes control.

 

[Quint-1-29]

October 3 update — Another 2.5-hour live test completed with no audible voice gaps that I noticed.

The trace captured 387 call epochs with no dropped continuity events, no IQ overflow drops, and no recording queue drops. It flagged seven speaker starvation intervals across three epochs, which I compared against what I heard:

• One transmission sounded like the dispatcher keyed up before speaking, followed by an open-mic check.
• Another was a short unit status report and dispatcher acknowledgment.
• The third had what sounded like another radio echoing in the background.

None of those flagged moments corresponded to missing speech that I noticed. The logs still show speaker starvation, so I’m keeping that separate from claiming completely gap-free playback. Transmitter silence is a plausible explanation for some of the intervals, but it isn’t proven.

This is encouraging evidence of stable operation over a longer session. The next step is more live testing and checking whether future trace flags line up with anything audible.

 

[Quint-1-29]

October 5 update — receiver fixes, analog recording, and simpler controls

SDRTW development continues on the native Rust application.

Recent P25 changes preserve the remaining queued audio from a normally completed call when the next call starts. Radio activity history now also includes source IDs decoded from Phase 1 and Phase 2 voice traffic, alongside control-channel observations. These changes have passed native regression checks; fresh live listening validation have also passed.

Receiver-follow logic now honors an assigned voice receiver. Single-receiver Auto Center handling has also been revised to retune for voice channels near the capture-window edge, where reception can degrade even though the channel technically fits.

Conventional analog audio can now be recorded directly to WAV through the native recording system. Recent live captures finalized successfully, with no recording drops or speaker underruns observed during those captures. Noise-reduction comparisons are also being evaluated offline; a live denoiser has not been enabled.

I’m simplifying the interface as well: duplicate audio-recording controls have been consolidated, irrelevant options are hidden for the selected mode, Settings actions are grouped more clearly, and Diagnostics puts P25 information first.

SDRTW remains under development. Continued live testing and the remaining release-validation checks come before a public test build.