AX.25 of the past
In an attempt to maintain a proper perspective of packet radio’s technical capabilities, it’s important to understand what it can and cannot do. History teaches some key points.
- TCP/IP over AX.25 – Conceptually useful, handy at one time, but a bit over the top for practical use. For production systems, let the Internet be the Internet and AX.25 be AX.25.
- Digipeating – A fundamental feature of AX.25, digipeating solves connectivity over distance issues via hopping, but with a much larger RF footprint and much much slower response times. Many hams from packet’s heyday reminisce hopping to faraway nodes to find the remote treasures. An honest assessment suggests excessive hopping degrades performance for all packet users on the frequency.
- BBS (aka Mail) – There’s no doubt the amateur world was on to something with the advent of amateur radio email well before Internet email became common. A nationwide email addressing scheme arose and in some fashion still exists, but the RF paths required to pass the traffic are dwindling. The principle benefit of BBS mail in today’s climate is the store and forward nature that alleviates the need for two operators to be on the air at the same moment.
- Chat – If one can keep the hops down to a reasonable level, keyboard to keyboard chat sessions make some sense. Some nodes provide chat servers that expand the realm to multiple user chat “rooms.”
Of all the things tried on packet, BBS email and Chat seem to be ones that offer some value in today’s radio world. Both capabilities are available on the Internet, so what’s special about packet radio is the actual over the air nature. Take radio away and there really is no point for AX.25. Of course some “packet” systems interconnect over the Internet in a hybrid approach using both radio and TCP/IP to pass data. The appeal for this should wane given the obvious security issues prevalent on the Internet. An RF only packet node with BBS and Chat capabilities seems appealing,
Amateur AX.25 packet radio is undergoing some sort of renaissance thanks in part to the efforts of Bob Bruninga’s APRS protocol. As well many non-amateurs enjoy tinkering with AX.25 over CB radio and other radio talk channels. More evidence packet radio is alive and well include:
- Despite the slow data rates, recently developed modems for 1200 bps and slower continue to arrive on the market for trendy platforms including the Raspberry Pi. Compared to the past, the price points of these new offerings are so low to be almost free.
- John Wiseman’s BPQ32 packet software suite remains in brisk development and has become the first choice of a great many current packet station operators. John’s response to bugs and feature requests are swift and appropriate.
- The Winlink crowd continues development of a system that showcases a solid packet radio development goal. I am not an advocate of connecting any amateur radio system to the Internet as Winlink does, but will tip my hat to their team for keeping packet radio viable.
In short, packet radio just won’t die as many folks continue to discover or re-discover it.
Old mode, new paradigm
The Kentucky Packet Network (KYPN) revealed a system designed from the ground up to address the needs of local amateurs who sing its praises. Key features include RF-only connectivity, minimal forwarding to and from other packet systems, 9600 bps user access on 440 MHz and a broad selection of amateur bands from which to gain access to their BBS and Chat capabilities. Despite the demise of the KYPN, its approach teaches the way packet ought to be for future systems.
By edict and design the VAPN strives to be a good neighbor especially on HF. The following points highlight this goal…
Confinement to digital subbands
There appears to be sufficient organization in the HF Packet digital cadre of operators making good use of just a handful of frequencies pre-arranged for use as digital channels. Our sense is this approach is tolerable to most operators and we aim to cooperate in this existing, small RF footprint regime. We hope our minimalist philosophy fosters respect from victims of high speed digital transmission stomp.
- We will never wander from expected digital frequencies.
- We will never succumb to the allure of high bandwidth data modes on HF.
- We want our system to be used by users and appreciated or at least tolerated by everyone else.
Stomping on existing QSOs on wandering frequencies is not in our plan.
Realistic and appropriate data rates on HF
To want more is perfectly natural. Data rates are no exception. For HF we must temper our desire to push large amounts of data the fastest way possible through the HF bands with the practical constraints unique to the amateur HF segments. We aren’t suggesting a fat Pactor signal doesn’t have a role to play every now and then, but we are talking about regular everyday use here not TEOTWAWKI. The HF bands are not an Internet substitute. VAPN’s approach to every day use is to incorporate slower, kinder, gentler modes to move messages of value at prudent speeds. We once thought short messages of value were a thing of the past; Twitter changed our minds. Fortunately some smart people are furthering kindler, gentler, data modes designed for the noisy world of HF; Robust Packet is one such example.
Realistic and appropriate data rates on VHF+
The world of 9600 bps data rates is finally here with good COTS gear a reality. VAPN will use this speed as standard when and where it makes sense. We won’t ignore the 1200 camp either since quite often a new user is just a soundcard program away from passing 1200 packets on their radio. Our hope includes the expectation a regular HF rig with 6m capability is already plumbed with a soundcard interface for PSK31, Olivia, etc. This setup will work as is for 6m 1200 bps. Time will tell if the users agree therefore we stand ready to adjust to reasonable requests.
Other than an occasional beacon or two, our systems will answer only when addressed by an amateur radio client. No polling.
A single node, RF only, frequency diverse, packet radio system in Virginia?
Is the KYPN approach applicable here in Virginia? Consider this site a feasibility study to answer this question. If a fit exists, we will engineer and document a new packet system to provide the KYPN style service to northern Virginia.
Key attributes shall include:
- Node on the hill with BBS and Chat application alongside the radios. No need to relay user traffic to a BBS machine in the valley;
- RF Only system with no connections to the Internet;
- No Winlink, by design, until a) Winlink software becomes reliable, b) The Winlink notoriety wanes and c) opening up the VAPN to Internet security threats becomes a tolerable thing;
- HF, VHF and UHF ports to provide access frequency diversity;
- Not designed to provide “communications, on a regular basis, which could reasonably be furnished alternatively through other radio services” FCC Rule 97.113(5) – no need to compete with legitimate and affordable commercial services.