RX Settings for RPR LiNK500 Teensy TNC, AFSK Data Modes – Robust Packet

An operator said: I think I may be having some receive issues with Robust Packet. Several operators have asked what settings I recommend for the best possible reception when using an RPR TNC such as the LiNK500 from DIY599, the SCS Tracker, or the Teensy TNC. Today’s testing provided a clear answer. I began by comparing FT8 and Robust Packet on the same frequency path between Finland and a station near Berlin. While FT8 decoded consistently at signal levels around –18 to –20 dB, the RPR link struggled to establish a connection under identical propagation conditions. That contrast became the foundation for refining my settings. Through careful adjustment of filter width, AGC behavior, and baseband alignment, I observed how small changes directly affected decode stability. Once the RPR signal was centered near 1500 Hz and the receive chain was stripped of all processing—no noise reduction, EQ, or compression—the modem finally achieved and maintained lock even through moderate QSB. These results confirmed what the technical documentation has long suggested: RPR performs reliably when provided a clean, stable, and properly centered signal, but it cannot operate effectively in the ultra-weak conditions where FT8 still decodes. The tuning process and lessons from today’s tests formed the basis for the recommended settings that follow, which now serve as a proven baseline for future RPR field operations.

Before We Get Started

Everything in this guide also applies to RPR-based APRS on HF, sometimes referred to as Robust APRS or RPR APRS. This mode uses the exact same Robust Packet Radio (RPR) waveform, framing, and modulation layer found in Winlink or keyboard-to-keyboard RPR communication. The only difference is in the application layer—RPR APRS carries beacons, position reports, and telemetry frames instead of message data.

Because the physical and link layers are identical, the same receive-chain optimizations described here apply equally to both. Whether you’re running Winlink over RPR, using an RPR TNC for general packet work, or gating APRS packets to APRS-IS, these settings will directly improve decode performance and link stability:

• Baseband centering at ~1500 Hz keeps the OFDM carriers phase-aligned.
• 500–700 Hz filter width limits noise without distorting the waveform.
• AGC FAST or OFF prevents amplitude fluctuations that break symbol timing.
• No audio processing (NR/NB/EQ/PROC) maintains linear tone relationships.
• Clean, stable LO and proper audio levels preserve the precise amplitude and phase balance RPR requires.

In short, the same configuration that enhances Robust Packet reliability will also improve RPR APRS beacon decoding, reduce missed packets, and make HF APRS-IS gateways far more dependable under weak or fading conditions.

Optimizing RPR Reception

You can usually improve Robust Packet (RPR) decode performance by correctly centering the audio/IF, tightening the RF passband to match the waveform, and disabling any receiver processing that distorts OFDM. But don’t expect FT8-level weak-signal performance—RPR requires a stronger signal-to-noise ratio to maintain synchronization and reliable two-way data exchange.

FT8 can decode signals 20–24 dB below the noise floor because it sends short, fixed, one-way frames with no ARQ. RPR, on the other hand, is a two-way, error-correcting protocol designed for message integrity and throughput. It sacrifices some weak-signal sensitivity to guarantee accurate delivery under fading or interference.

Receiver and Filter Setup

Center the audio where the modem expects it. Both the Teensy TNC and LiNK500/LiNK500MP expect the RPR carrier cluster centered near 1500 Hz in the baseband. Use your radio’s passband or IF shift to place it correctly.

Match the bandwidth to the signal. RPR fits within about 500 Hz. Use a 500–700 Hz filter width with a flat response. Avoid overly wide or sharply shaped filters that distort tone spacing or introduce phase shift.

Turn off all audio processing. Disable noise reduction, noise blanker, notch filters, EQ, compression, mic processing, and any other TX/RX enhancements. RPR’s OFDM structure depends on clean, linear audio.

AGC: use FAST or OFF. Set AGC to FAST, or disable it and manually adjust RF gain. Prevent AGC pumping caused by QSB or nearby strong signals.

Preamp/ATT: optimize for SNR. If the band is noisy, use attenuation. If it’s quiet, use preamp. Always optimize for signal-to-noise ratio, not just signal strength.

Audio Chain and Levels

Both modems perform full RPR DSP internally and do not rely on your computer’s soundcard. Set RX audio from the radio high enough for stable decoding but never to the point of clipping. Set TX audio so the radio’s ALC just flickers on peaks—avoid overdriving. Keep audio lines isolated to prevent hum, USB noise, or ground loops.

Frequency Accuracy and AFC

RPR’s multi-tone OFDM waveform is more sensitive to frequency drift than FT8. Calibrate the radio’s frequency if possible. Allow the modem’s AFC to lock naturally and don’t retune once it starts tracking. The Teensy and LiNK modems handle AFC internally, but overall stability still depends on the radio’s local oscillator.

Propagation and Expectations

RPR is significantly more reliable than 300-baud AX.25 packet but less sensitive than FT8. FT8 excels at extreme weak-signal detection because it transmits predictable, fixed-length messages without error correction. RPR, by contrast, is interactive, using FEC and ARQ for confirmed delivery.

Expect RPR to need roughly 2–4 dB higher SNR than FT8 for a stable link. It’s common to decode FT8 while RPR fails to connect—until conditions improve slightly. Once they do, RPR can move actual data where FT8 cannot. For medium-distance paths such as Finland ↔ Germany, the 30 m and 40 m bands around twilight typically yield the most stable RPR performance.

Applying These Principles to Other Data Modes

From my experience, the same principles that improve RPR reception — a clean audio path, proper signal centering, and minimal processing — also apply directly to other AFSK data modes such as PSK31, RTTY, and JS8Call. All of these modes depend on linear, undistorted audio and a stable frequency reference to maintain timing and phase integrity. The goal is always the same: deliver the cleanest possible signal to and from the modem.

Shared best practices across AFSK data modes

• Disable audio processing. Noise reduction, EQ, compression, notch filters, and speech processing all distort the relationship between phase and amplitude. Every AFSK data mode benefits from a flat, linear audio chain.
• Center frequency alignment. Most software demodulators assume the signal is centered near 1500 Hz in the baseband. Keeping your tones around that frequency ensures filters, AFC, and symbol recovery all work as intended.
• Match the filter bandwidth to the mode. Using a filter just wide enough for the occupied bandwidth improves SNR and prevents distortion.
   – PSK31 ≈ 31 Hz
   – RTTY ≈ 170 Hz
   – JS8Call (Slow ≈ 25 Hz | Normal ≈ 50 Hz | Fast ≈ 80 Hz | Turbo ≈ 160 Hz)
   – RPR ≈ 500 Hz
• Maintain frequency stability. PSK31 and JS8Call depend heavily on phase accuracy, while RTTY and RPR require precise tone spacing. Frequency drift or a weak oscillator will destroy synchronization in all of them.
• Set AGC for consistency. Slow or “pumping” AGC can stretch symbol amplitudes and confuse the demodulator. FAST AGC or manual RF gain produces the most reliable decodes.

Dynamic filter management in the field

Before a QSO, I keep my filters wide enough to monitor the full passband of the mode. For example, JS8Call on 40 meters (7078 kHz) typically occupies the 500–2000 Hz range, where multiple stations may appear simultaneously. Once I’ve locked onto a station, I narrow the filter around that signal—just 50–100 Hz wider than the actual occupied bandwidth—to improve SNR and readability.

If the incoming signal is strong enough, there’s no need to tighten the filters at all. Leaving them open is especially useful in a net or monitoring situation where you want to copy multiple stations across the bandpass without having to retune or restrict the receiver.

Where the results differ

• RPR employs both forward error correction (FEC) and automatic repeat request (ARQ) for reliable delivery under fading or noise.
• JS8Call includes limited forward error correction (LDPC) but does not use ARQ or retransmission. Reliability comes primarily from repeated frames and acknowledgements at the application level.
• PSK31 and RTTY include no FEC and are highly sensitive to noise, distortion, or clipping.
• RPR’s multi-tone OFDM structure is more sensitive to phase distortion from steep filters or poor group delay, while JS8Call’s single-carrier FSK design tolerates those effects better.

Summary

Everything that improves signal purity, frequency stability, and SNR for RPR will also improve PSK31, RTTY, and JS8Call. The key difference is that these simpler AFSK data modes have little or no internal error correction, so a clean, well-tuned receive chain is even more important. In short, the same discipline that strengthens RPR decoding will make every AFSK data mode decode cleaner and more reliable — whether you’re in a one-to-one QSO or monitoring a wide-area data net across the bandpass.

Network Realities

RPR remains a specialized mode with relatively few active users. Random reception is rare compared with FT8. For meaningful results, coordinate with a known peer or use published Robust Packet Network beacon times for testing.

Quick Test Plan

• Use a 500–700 Hz filter width with gentle skirts.
• Center the RPR signal cluster near 1500 Hz.
• Set AGC FAST or OFF, and disable NR/NB/EQ/PROC.
• Adjust RX/TX audio for clean, undistorted levels.

Final Thoughts

If you’ve found this information useful, consider experimenting with your own RPR setup and sharing your results with the community. Every test, connection, and field report helps build a stronger understanding of how these modes perform in real-world conditions. Reliable HF data links are one of the cornerstones of off-grid and emergency communications, and each improvement we make brings the entire network closer to true resilience.