Table of Contents:
- Preface
- What do you need to play with HF packet in the modern era?
- Which HF packet protocols are en vogue?
- Where is the action? (IARU R2)
- How do I start decoding traffic?
- How do I start sending traffic?
- What’s next?
Preface:
When I first became interested in amateur radio, packet radio networking was a major draw for me. The prospect of participating cooperatively with others in the hobby was what I found to be interesting aside from a new technical aspect to learn. I initially started with APRS, as many in the hobby do, but I was disappointed (as was Bob Bruninga) to see that the network was mainly used for vehicle tracking. I wanted to be able to pass more interesting general purpose information as well as extend my reach beyond VHF/UHF without internet gateways. I remember early on in my journey reading about AREDN, AMPRNet, and ARDC but it was either internet related or devoted to emergency communication, of which I had no interest whatsoever. At the time, I only had a technician license, VX-6R, and a PicoAPRS.v3. With these tools I was limited to fairly short range VHF/UHF FM AX.25 and I soon lost interest after only having played with the ever controversial Winlink to send myself a test email to a WL2K iGate using the PicoAPRS as a 2m FM 1200Bd AX.25 KISS TNC using WoAD.
Fast forward about 5 years and I now have my general license, HF transceiver, and a lot more knowledge about amateur radio. After the JS8 debacle, I was looking for another way to participate in K2K and RF networking and I came across a mention of Network 105 on the amateur radio Mastodon instance. I took it as an opportunity to dive back into AX.25 but this time at 300Bd over HF and even set up a packet BBS of my own. It has only been a few weeks but I’ve learned about John Wiseman’s (G8BPQ) PBBS suite of software. I chose this software suite to focus my efforts on because it is not only still actively being developed but it is being currently being developed with the low-cost, low-power, Raspberry Pi single-board computer in mind.
What do you need to play with HF packet in the modern era?
- HF transceiver
- USB audio to transceiver interface w/ CAT control
- Computer
- CAT control software
- Software TNC
- SoundModem (Windows)
- QtSoundModem (Windows/Linux)
- Direwolf (Windows/Linux/MacOS)
- Terminal emulator (KISS TNC or AGW frame compatible)
† I was able to compile QtTermTCP using qt5 from macports and the c compiler bundled with xcode 14 on mac OS Sonoma on an M2. Notably the ‘Listen’ feature is missing from this build. Someone will need to work with John to get proper macOS builds fully working.
There is also the hardware DIY KISS TNC route but there are no performance advantages and you still need terminal emulator software
Which HF packet protocols are en vogue?
Where is the action?
These are the preferred or priority Automatic Controlled Data Station (ACDS) segments per the IARU R2 Band Plan
- 10m
- 28120-28150 – 500Hz BW
- 28300-28320 – 2700Hz BW
- 29200-29300 – 6000Hz BW
- 12m
- 24925-24929 – 500Hz BW
- 24931-24940 – 2700Hz BW
- 15m
- 21090-21110kHz – 500Hz BW
- 21110-21120kHz – 2700Hz BW
- 17m
- 18105-18109kHz – 500Hz BW
- 18111-18120kHz – 2700Hz BW
- 20m
- 14089-14099kHz – 500Hz BW
- 14101-14112kHz – 2700Hz BW
- Net105 – 14105kHz LSB
- 30m
- 10130 – 10140kHz – 500Hz BW
- Net30 – 10144kHz LSB
- 40m
- 7047-7050kHz – 500Hz BW
- 7050-7053kHz – 2700Hz BW
- 80m
- 3590-3600kHz – 500Hz BW
- 3600-3625kHz – 2700Hz BW
- 160m
- 1839-1840kHz – 200Hz BW
To make matters more complicated, the ARRL has not lobbied the FCC to enact laws that conform to the regionally agreed upon ACDS segments.
§ 97.221 Automatically controlled digital station.
(a) This rule section does not apply to an auxiliary station, a beacon station, a repeater station, an earth station, a space station, or a space telecommand station.
(b) A station may be automatically controlled while transmitting a RTTY or data emission on the 6 m or shorter wavelength bands, and on the 28.120–28.189 MHz, 24.925–24.930 MHz, 21.090–21.100 MHz, 18.105–18.110 MHz, 14.0950–14.0995 MHz, 14.1005–14.112 MHz, 10.140–10.150 MHz, 7.100–7.105 MHz, or 3.585–3.600 MHz segments.
(c) Except for channels specified in § 97.303(h), a station may be automatically controlled while transmitting a RTTY or data emission on any other frequency authorized for such emission types provided that:
(1) The station is responding to interrogation by a station under local or remote control; and
(2) No transmission from the automatically controlled station occupies a bandwidth of more than 500 Hz.
[60 FR 26001, May 16, 1995, as amended at 72 FR 3082, Jan. 24, 2007; 77 FR 5412, Feb. 3, 2012]
https://www.ecfr.gov/current/title-47/chapter-I/subchapter-D/part-97/subpart-C/section-97.221
US Amateur Radio ADCS Segments
- 10m
- 28120–28189 kHz – 500Hz BW
- 12m
- 24.925–24.930 kHz – 500Hz BW
- 15m
- 21090–21100 kHz – 500Hz BW
- 17m
- 18105–18110 kHz – 500Hz BW
- 20m
- 140950–140995 kHz – 500Hz BW
- 141005–141120 kHz – 500Hz BW
- Net105 – 14105kHz LSB
- 30m
- 10140–10150 kHz – 500Hz BW
- Net30 – 10144kHz LSB
- 40m
- 7100–7105 kHz – 500Hz BW
- Net40 – 7104 kHz LSB
- 80m
- 3585–3600 kHz – 500Hz BW
Is packet always ACDS?
The short answer is, it depends:
The automatically controlled station either must be connected to another station that is under manual control, or the automatically controlled station must transmit only within a subband designated for communications between automatically controlled stations.
https://www.govinfo.gov/content/pkg/FR-1995-05-16/pdf/95-11978.pdf
The way this has been interpreted is that a OP↔BBS is okay anywhere digital is allowed but BBS↔BBS (forwarding) needs to be in the ACDS subband defined above.
Do I need to do something special to ID?
(b) The call sign must be transmitted with an emission authorized for the transmitting channel in one of the following ways:
(1) By a CW emission. When keyed by an automatic device used only for identification, the speed must not exceed 20 words per minute;
(2) By a phone emission in the English language. Use of a phonetic alphabet as an aid for correct station identification is encouraged;
(3) By a RTTY emission using a specified digital code when all or part of the communications are transmitted by a RTTY or data emission;
(4) By an image emission conforming to the applicable transmission standards, either color or monochrome, of § 73.682(a) of the FCC Rules when all or part of the communications are transmitted in the same image emission
https://www.ecfr.gov/current/title-47/part-97/section-97.119#p-97.119(b)
This one is a little easier to answer. No! If you can ID via RTTY or an image, you can ID via packet. *X.25/IL2P packets are very easy to identify by ear and every packet you send starts with your callsign so no need to worry about timing. While the IARU band plans suggest that ACDS should ID in morse code every so often for non-digital users, this is not a requirement. I do not recommend enabling this if software allows for it and do not let anyone bully you about it. Send them here if they need some help clarifying rules. I’m the process of getting this officially clarified. I’ll make a new post with details when I get IDing and Packet/ACDS bandwidth officially sorted.
How do I start decoding traffic?
The best way is to tune to the Net105 frequency and start up your AFSK modem of choice. Make sure to use the most appropriate mode available on your radio (DATA, DIGI, etc.) and set the appropriate sideband. If your radio has an offset setting for the digital mode, make sure to set it to 0Hz. Setting up SoundModem is very easy. If you’ve set up WSJT-X software you can rest assured that it’s no more complicated. Set the mode to AX.25 300Bd from the box in the upper lefthand corner and you should start seeing traffic being decoded so long as you set your input and output devices in the software. If you’d like to use FX.25 that is done under the modem settings.
To optimally set the RX levels, SoundModem’s waterfall using the color setting should appear mostly green. You shouldn’t have to adjust anything else. To start, I recommend setting your AGC to fast and the radio wide open.
How do I start sending traffic?
This is slightly more complicated to get right but not by much. I suggest reading my post about setting levels. The post has some WSJT-X specific settings but the concepts are mostly the same. One big difference is that you can use filters to narrow the input. A 500Hz mechanical filter would work well here. As for RX volume, we want to set the levels just under the point that ALC would be triggered and in general, you don’t want to amplify a signal more than is necessary as it introduces unnecessary noise.
Next, you’ll need to connect a terminal emulator like QtTermTCP or EasyTerm to your TNC via the telnet port the software exposes. This varies by software so I’m not going to make any explicit references to port numbers here in this post. Once you’re connected, you’ll be able to tell your TNC to connect to a station you’ve decoded messages from as well as call CQ if you’d like in ‘Listen’ mode.
Depending on the type of station you’re connecting to, you may have access to a BBS, multiuser chat, file transfer, and potentially internet connected services. Commands will vary depending on the TNC software/hardware of the station you are connected to. Sending ‘?’, ‘h’, ‘/h’, or ‘help’ will usually get you the list of commands available. Often the SSID or lack therof will tell you a little about the station. In the most basic of TNC to TNC connections, you’re left with just a direct serial or telnet connection to the sysop.
Common HF Packet SSIDs:
- -0/R (or no SSID) = Direct sysop K2K chat
- -1/B = BBS
- -4/C = Chat
- -7/N = Node
- -15,-14,-13 = OP is connecting through other station(s). The SSID decrements by one for each hop. The base SSID of 0 loops back to 15 on the first connection out.
There are others but these are the most common you’ll see on Net105 as it was designed to be a place for live K2K chats.
What’s next?
I suggest first reading this packet radio primer by Larry Kenney, WB9LOZ. While not new, nothing has really changed other than the TNC’s being implemented in software. After you’re done, head on over to the first post in the Linux Packeteering series!