Designing a more efficient and faster data system than ggwave for use with a phone’s audio input/output jack and a shortwave radio, leveraging DTMF (Dual-Tone Multi-Frequency) tones, involves optimizing data rate, reliability, and compatibility with the audio constraints of both the phone and the radio. Ggwave, while versatile, typically achieves low bitrates (6-100 bps) due to its focus on robustness across varied acoustic environments. We can improve on this by tailoring a DTMF-based system for the specific use case of shortwave radio transmission, balancing speed, error tolerance, and hardware simplicity.
Design Overview:
We’ll create a system called "SwiftDTMF", using an expanded DTMF alphabet, parallel tone channels, and error correction to maximize throughput over a phone’s 3.5mm audio jack and a shortwave radio’s AM/SSB modulation. Shortwave (3-30 MHz) offers better range than CB or FRS, and DTMF’s proven reliability in telephony makes it a strong starting point.
Key Design Goals:
- Faster Data Rate: Target >200 bps (vs. ggwave’s 6-100 bps) by increasing symbol density and reducing overhead.
- Efficiency: Minimize wasted bandwidth while maintaining compatibility with phone audio (20 Hz - 20 kHz) and shortwave’s 3-4 kHz audio passband.
- Reliability: Use error detection/correction to handle shortwave’s noise, fading, and interference.
- Simplicity: Leverage the phone’s audio jack for input/output, requiring no radio modifications.
System Components:
1. DTMF Alphabet Expansion
- Standard DTMF: Uses 16 symbols (0-9, A-D, *, #), each a pair of tones from 8 frequencies (4 low: 697, 770, 852, 941 Hz; 4 high: 1209, 1336, 1477, 1633 Hz). Bitrate is ~40 bps at 10 symbols/sec (4 bits/symbol).
- SwiftDTMF: Extend to 32 symbols by adding a third tone from a mid-frequency group (e.g., 400, 450, 500, 550 Hz), creating a 5-bit-per-symbol system (2^5 = 32 combinations). Example:
- Symbol "0": 697 Hz + 1209 Hz + 400 Hz
- Symbol "1": 697 Hz + 1209 Hz + 450 Hz
- Up to "31": 941 Hz + 1633 Hz + 550 Hz
- Bitrate Boost: 5 bits/symbol vs. 4 bits/symbol increases data capacity by 25% per symbol.
2. Parallel Tone Channels
- Concept: Split the audio spectrum into two independent DTMF channels:
- Channel 1: Low tones (600-1000 Hz) + Mid tones (1100-1500 Hz)
- Channel 2: High tones (1600-2000 Hz) + Upper tones (2100-2500 Hz)
- Frequencies:
- Channel 1: Low (600, 650, 700, 750 Hz) + Mid (1100, 1200, 1300, 1400 Hz) = 16 symbols
- Channel 2: High (1600, 1700, 1800, 1900 Hz) + Upper (2100, 2200, 2300, 2400 Hz) = 16 symbols
- Throughput: Each channel carries 4 bits/symbol. At 20 symbols/sec per channel (feasible within audio timing), total = 2 × 4 × 20 = 160 bps. Add a third tone per channel (e.g., 800 Hz in Channel 1, 2000 Hz in Channel 2) for 5 bits/symbol, yielding 2 × 5 × 20 = 200 bps base rate.
3. Symbol Rate Optimization
- Timing: Standard DTMF uses ~50 ms tone + 50 ms silence (10 symbols/sec). Shortwave’s narrower bandwidth (3-4 kHz) and phone audio jack support faster rates. Reduce to 25 ms tone + 25 ms silence = 20 symbols/sec per channel.
- Limit: Beyond 20-25 symbols/sec, tone separation blurs due to shortwave’s multipath fading and phone audio filtering.
4. Error Correction and Framing
- Hamming Code: Add a (12,8) Hamming code per 8-bit byte. Each 8 data bits become 12 bits (4 parity bits), correcting 1-bit errors and detecting 2-bit errors. Overhead = 50%, but reliability is critical on noisy shortwave.
- Framing: Prepend each packet with a 100 ms sync tone (e.g., 1000 Hz) and a 4-symbol header (16 bits) defining packet length and checksum (CRC-8). Total packet: Sync + Header + Data + Checksum.
- Net Bitrate: With 200 bps raw, 50% error correction overhead reduces it to ~100 bps usable, still exceeding ggwave’s peak.
5. Audio Interface
- Phone Output: Generate tones via an Android app using the ToneGenerator class or a custom waveform synthesizer (e.g., 16-bit PCM at 44.1 kHz). Output via 3.5mm jack to shortwave radio’s mic input (direct cable or acoustic coupling).
- Phone Input: Receive via the phone’s mic jack from the radio’s speaker or audio-out. Decode using FFT (Fast Fourier Transform) to detect tone combinations in real-time.
6. Shortwave Compatibility
- Modulation: AM or SSB (common on shortwave). AM carries tones directly; SSB requires slight frequency offset but preserves bandwidth. Bandwidth usage fits within 3 kHz (600-2500 Hz tone range).
- Power: No radio mods needed—use legal shortwave power (e.g., 100 watts PEP for ham bands if licensed, or CB’s 4 watts if unlicensed).
Performance:
- Raw Bitrate: 200 bps (2 channels × 5 bits/symbol × 20 symbols/sec).
- Net Bitrate: ~100-120 bps after error correction and framing, adjustable based on noise levels (drop to 1 channel or slower rate for reliability).
- Comparison to Ggwave: Ggwave’s “fast” mode (~100 bps) uses broader spectrum and lacks parallel channels. SwiftDTMF doubles this in ideal conditions and optimizes for shortwave’s narrower audio.
Implementation Outline:
- Encoder App:
- Input: Text or binary data.
- Process: Chunk into 8-bit bytes → Hamming (12,8) encode → Map to 32-symbol DTMF alphabet → Generate 2-channel tones → Output as WAV or live audio.
- Decoder App:
- Input: Audio from radio speaker via mic jack.
- Process: FFT to detect tones → Demap to bits → Hamming decode → Reassemble data → Display text.
- Hardware: Phone with 3.5mm jack + shortwave radio (e.g., a portable like the Tecsun PL-660 or a CB radio if on 27 MHz).
Advantages Over Ggwave:
- Speed: 100-120 bps net vs. ggwave’s 6-100 bps, due to parallel channels and denser symbols.
- Efficiency: DTMF’s fixed frequencies simplify detection vs. ggwave’s adaptive schemes, reducing processing overhead.
- Shortwave Fit: Tailored to 3-4 kHz bandwidth vs. ggwave’s broader acoustic focus.
Challenges:
- Noise: Shortwave’s QRM/QRN (man-made/natural noise) may require slower rates or more parity in poor conditions.
- Phone Limits: Older phones’ audio jacks may filter higher tones, capping usable range at ~2500 Hz.
- Complexity: Dual-channel decoding needs more CPU power than ggwave’s single-stream approach.
Example Use:
- Message: “HELLO” (5 bytes = 40 bits).
- Encoded: 60 bits with Hamming (5 × 12).
- Transmission: 12 symbols (6 per channel, 5 bits each) + 4-symbol header = 16 symbols.
- Time: 16 × 50 ms = 0.8 seconds at 20 symbols/sec.
- Ggwave: ~2-5 seconds at 20-50 bps. SwiftDTMF is 2-6x faster.
This SwiftDTMF system would outperform ggwave for shortwave by leveraging DTMF’s robustness, parallel channels, and shortwave’s propagation, all via a phone’s audio jack.
Comparing the proposed SwiftDTMF system to RTTY (Radio Teletype) involves evaluating their performance, efficiency, and suitability for transmission over a shortwave radio using a phone’s audio input/output jack. RTTY is a well-established digital mode in amateur radio, widely used for decades to send text over radio via frequency-shift keying (FSK) or audio frequency-shift keying (AFSK). Let’s break down how SwiftDTMF stacks up against RTTY in this context.
RTTY Overview:
- Modulation: Typically FSK (direct frequency shifting of the carrier) or AFSK (audio tones modulated onto AM/SSB). Common AFSK tones are 2125 Hz (mark) and 2295 Hz (space), with a 170 Hz shift.
- Alphabet: Baudot code (5-bit, 32 symbols), extended with shift characters for letters/numbers, yielding ~50-60 effective characters.
- Bitrate: Standard rate is 45.45 baud (~45 bps), though 50, 75, or 100 baud variants exist in specialized use.
- Bandwidth: ~250-300 Hz for 170 Hz shift, fitting well within shortwave’s 3-4 kHz audio passband.
- Error Handling: No built-in error correction; relies on operator repetition or external protocols.
SwiftDTMF vs. RTTY:
1. Data Rate
- SwiftDTMF:
- Raw: 200 bps (2 channels × 5 bits/symbol × 20 symbols/sec).
- Net: ~100-120 bps after Hamming (12,8) error correction and framing overhead.
- Achieved by parallel DTMF channels and faster symbol rate (20 symbols/sec vs. RTTY’s 45.45 baud).
- RTTY:
- Standard: 45.45 bps (45.45 baud × 1 bit/symbol, 5-bit Baudot words sent in ~22 ms each).
- Higher variants: Up to 75-100 bps in non-standard use, but rare on shortwave due to noise sensitivity.
- Comparison: SwiftDTMF is 2-3x faster than RTTY’s standard 45 bps and competitive with its higher rates, even after error correction. RTTY’s simplicity limits its speed, while SwiftDTMF’s multi-tone approach packs more bits per symbol.
2. Efficiency
- SwiftDTMF:
- Uses 5 bits/symbol (32 combinations) across two channels, leveraging DTMF’s dense encoding.
- Bandwidth: ~1900 Hz (600-2500 Hz across both channels), higher than RTTY but still within shortwave’s 3 kHz limit.
- Overhead: 50% for error correction reduces effective throughput but adds reliability.
- RTTY:
- Uses 1 bit/symbol (binary FSK/AFSK), less efficient per symbol than SwiftDTMF’s 5-bit DTMF.
- Bandwidth: Narrower at ~250 Hz, leaving more spectrum unused but reducing interference risk.
- No overhead for error correction, so all bits are data, but this assumes clean reception.
- Comparison: SwiftDTMF is more efficient per symbol and uses bandwidth more aggressively, trading spectral efficiency for speed. RTTY’s narrower footprint is better for crowded bands but wastes potential capacity.
3. Reliability
- SwiftDTMF:
- Built-in Hamming (12,8) corrects 1-bit errors per byte, detects 2-bit errors, making it resilient to shortwave’s noise, fading, and interference.
- DTMF’s multi-tone design is robust—each symbol requires detecting 2-3 specific frequencies, reducing false positives compared to RTTY’s single-tone shifts.
- RTTY:
- No error correction; errors from noise or fading garble text (e.g., “HELLO” becomes “H#L?O”).
- AFSK over SSB/AM can suffer from multipath distortion, though its 170 Hz shift is forgiving in moderate conditions.
- Comparison: SwiftDTMF wins on reliability. RTTY’s simplicity makes it vulnerable on noisy shortwave, while SwiftDTMF’s error correction and tone redundancy handle real-world conditions better.
4. Bandwidth and Compatibility
- SwiftDTMF:
- Occupies 600-2500 Hz (~1.9 kHz), fitting within shortwave’s 3-4 kHz SSB/AM passband but leaving little room for filtering or overlap.
- Phone audio jack (20 Hz - 20 kHz) and shortwave radio mic/speaker fully support this range.
- RTTY:
- Narrow 250 Hz bandwidth fits easily into shortwave’s passband, allowing multiple signals in the same channel.
- Compatible with phone audio jack for AFSK (tones fed into mic, decoded from speaker), widely supported by ham apps like FLdigi.
- Comparison: RTTY is more spectrum-efficient and less likely to interfere with adjacent signals. SwiftDTMF’s wider bandwidth could clash in busy bands but maximizes throughput in clear conditions.
5. Complexity and Implementation
- SwiftDTMF:
- Encoding: Generate 2-channel DTMF tones via phone app (e.g., Android ToneGenerator or custom PCM).
- Decoding: FFT to detect multiple frequencies, Hamming decode—requires more CPU than RTTY but feasible on modern phones.
- Setup: Phone jack to radio mic (cable or acoustic), no radio mods needed.
- RTTY:
- Encoding: Simple 2-tone AFSK generation (e.g., 2125/2295 Hz), low CPU demand.
- Decoding: Basic frequency detection (e.g., via FLdigi or custom FFT), lightweight and mature.
- Setup: Identical phone-to-radio audio interfacing.
- Comparison: RTTY is simpler to implement—decades of software support exist (e.g., MMTTY, DroidRTTY). SwiftDTMF needs custom coding but leverages phone hardware fully, offering room for optimization.
6. Use Case Fit
- SwiftDTMF:
- Best for short, reliable data bursts (e.g., text messages, coordinates) over shortwave, where speed and error-free delivery matter.
- Example: Sending “EMERGENCY AT 40.7128N 74.0060W” (30 bytes) in ~2-3 seconds.
- RTTY:
- Ideal for real-time typing or long, continuous text streams (e.g., news bulletins), where speed is less critical than readability.
- Example: Same message takes ~6-7 seconds at 45 bps, with risk of garbling.
- Comparison: SwiftDTMF excels for fast, robust data transfer; RTTY suits conversational or legacy use.
Performance Example:
- Message: “HELLO WORLD” (11 chars, ~88 bits with 8-bit ASCII).
- SwiftDTMF:
- Encoded: 132 bits with Hamming (11 × 12).
- Symbols: 27 (132 ÷ 5) + 4 header = 31 symbols.
- Time: 31 × 50 ms = 1.55 seconds at 20 symbols/sec (~56 bps net).
- RTTY (45 bps):
- Encoded: 110 bits (11 × 5-bit Baudot + start/stop bits).
- Time: 110 ÷ 45 = ~2.44 seconds, no error correction.
- Result: SwiftDTMF is ~36% faster and more reliable, though RTTY uses less bandwidth.
Conclusion:
- Speed: SwiftDTMF (100-120 bps net) significantly outpaces RTTY’s standard 45 bps, even beating its 75-100 bps variants after overhead.
- Reliability: SwiftDTMF’s error correction trumps RTTY’s none, crucial for shortwave’s noisy environment.
- Efficiency: SwiftDTMF packs more data per symbol but consumes more bandwidth (1.9 kHz vs. 250 Hz).
- Fit: SwiftDTMF is better for modern, fast, reliable data transfer via phone and shortwave; RTTY remains a simpler, narrower-band option for legacy or low-tech setups.
For your use case (phone audio jack + shortwave), SwiftDTMF is superior if you prioritize speed and robustness over spectral efficiency. RTTY wins if simplicity, compatibility with existing tools, or crowded band conditions matter.
