Getting Started with Packet radio KI6ZHD dranch at trinnet d o t net 01/18/21.1 ------------------------------------------------------------------------------- Index: ------ 1. Learning the basics about Packet radio and AX.25 -- 2. Deciding on Layer-1 - the hardware and software 2.a. Radios: Frequency vs. Speed 2.b TNCs (hardware vs software) 2.c. Picking Packet software (Linux/Win/Mac) -- 3. Setting up a packet station -- 4. What frequencies should you use? -- 5. Making Connected connections -- 6. Understanding Kantronics KNet and KaNet TNC interfaces -- 7. Making UnConnected connections (UNPROTO) -- 8. Next Steps -- 9. FAQ -- 10. Advanced packet - not using AFSK for the mode; use Fldigi -- 20. Errata ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- 1. Learning the basics about Packet radio and AX.25 There are a few good packet intros out there but one of my favorites is the Choisser one from WB9LOZ: http://www.choisser.com/hamradio/packet.html I also have some other tutorial URLs and other high level descriptions on my HamPacket documentation: http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#5.pkttutor Here is the Packet Tutorial section from this HamPacket document: - Packet Tutorial - Learning about AX.25 packet radio What is "packet": ----------------- "Packet" radio is the complete solution to send AX.25 framed packets over Radio. A complete solution usually consists of a computer, a TNC, a radio, and an antenna. What you send over "packet" can be things like APRS (a positioning and messaging service), connections to remote BBSes and PBBSes, live chat to other people, telemetry, etc. It's VERY flexible and powerful. What is a "digipeater" vs. a "node" ------------------------------------ Beyond reading the excellent links in the "Packet Tutorial" section above, packet users can reach a remote station in one of four ways: direct, digipeated, node, or NetRom/ROSE/KNet: Example: o ------ o ------ o ------ o ------ o My first second third destination station hop hop hop Digipeated: ----------- A packet that is digipeated is sent with an explicit routing path from the originating packet machine. With that digipeated path, every follow-on packet will also follow that path. When traversing that say three hops path, the packet is copied from one hop to the next but if there is a decode failure mid-path, the packet is lost and the originator's system will have to wait until it's AX.25 stack times out and re-transmits the original packet. A VERY slow process. It's generally accepted that digipeating more than THREE hops will be unreliable as you significantly increase a packet's chances of getting corrupt, be collided with, etc. with each additional hop. Node / KaNet: ------------- Using intermeadiate nodes to send relay packets is different in the sense in two main ways: Manual connection ----------------- The packet originator has to manually *connect* to each hop in the path. Putting it another way, the originator would create a connection to the first hop, then create a connection from that machine to the second hop, etc. until he or she reaches the desired destination. This is a somewhat tedious process. Automatic in-path re-transmission --------------------------------- The major benefit of using nodes is that if there is a packet loss in the middle of the path, the two intermeadiate nodes will automatically re-transmit the lost packet and continue on. This is FAR more reliable, faster, etc. NetROM / KNet / FlexNet / ROSE ------------------------------ These technologies are very similar to eachother in the sense that they ALL send out periodic "route" updates advertising what local services your machine offers (a PBBS, a full BBS, a Node, a digipeater, etc). Other machines that understand these protocols then build a table of these nodes and how they are interconnected. Once the "routing" table is built, this system allows to simply connect to the DESTINATION machine without having to know the path. Once the connection request is made, each packet is "NODED" along the path. Putting that another way, you get the benefit of not having to manual create connections along the way like a classic node or KaNet connection yet if there is a packet failure mid-path, you don't have the performance and delay issues that are experienced with a digipeater. Some other exceptional Packet tutorials on the web: #Getting started with Packet radio http://www.qbjnet.com/packet.html #Detailed breakdowns of all TNC details http://www.rain.org/~jkrigbam/packet.htm #Setting proper AFSK and audio levels for packet TNCs and other digital #modes http://www.febo.com/packet/layer-one/transmit.html #More good details on Packet http://www.vectorbd.com/bfd/packet/index.html ------------------------------------------------------------------------------- 2. Deciding on Layer1 - The hardware and software The choice of hardware and software can be a bit complicated as packet can run on different speeds and frequencies: 2.a. Radios: Frequency vs. Speed -------------------------------- Radios: Frequency: HF / 300 Baud If you want to run packet on HF, you need an HF radio and the appropriate amateur radio operating license. The specific choice of the radio really isn't as important as you'd expect. Sure, better the radio, the better the reception but even old tube-type radios can be made to work quite well. At HF frequencies of, 300baud FSK (Frequency Shift Keying) packet is as fast as you can LEGALLY go per FCC Part97 here in the US. It's only at 10meters that your allowed to use higher BAUD rates. You might be thinking that's super slow honestly, that's a *LOT* faster than almost *all* other HF digital modes modes! It's true! With that said, 300baud HF packet signals needs to be very strong and very clear to work well and that doesn't happen all that often on HF. There are newer versions of HF packet such as SCS's proprietary "Robust Packet" mode but it only works with SCS hardware TNCs (not covered in this document). Another approach here is to not use the traditional AFSK mode and instead, use more modern HF digital modes. See the "Advanced Packet" section below for more details. Radios: Frequency: VHF / 1200 BAUD The most common packet setup is a system running on VHF frequencies like 2 meters (144MHz) running at 1200BAUD via the AFSK mode. Notice the term AFSK which stands for Audio Frequency Shift keying. This is a very simple mechanism and is one of the reasons why these type of packet systems are easy to setup. Here, almost any 2m handheld (HT) or mobile FM radio will do. The robustness of the 1200 baud AFSK mode, inexpensive radio hardware, ease of setup, combined with inexpensive omni-directional antennas are why this is the most common setup. It's worth noting that 9600 BAUD using an FSK mode also will work on 2m but it's not very common. Radios : Frequency: UHF / 9600 BAUD and faster The most common 9600 baud packet setups run on UHF frequencies like 70cm / 440MHz and these radios can also support 1200baud packet as well. 9600 BAUD FSK packet is substantially faster than 1200 BAUD packet but it requires very strong signals to be reliable. Unless you have a good path to the remote station, you'll need a directional antenna (Yagi, etc) to make this mode work well. In addition to a good signal, you need a different type connection to the radio itself. Unlike 1200baud AFSK packet that uses audio frequencies via basic microphone and speaker connections, 9600BAUD needs to interface to the radio at the FM discriminator input/output. This interface provides for flat passband, which is cleaner and wider interface for data than what a pre/post- emphasized microphone and speaker connection can offer. Modern 2m/70cm radios usually have 6-pin "DATA" jack on the back where one of these pins is for 9600 BAUD / direct discriminator access. If your radio DOESN't have that connection, you'll have to modify your radio to get access to it. EVERY radio has a discriminator so it's only a matter of finding the right connection. Sites like http://mods.dk and other radio sites will have this information for your radio. It's also worth mentioning that 19200 baud packet is technically possible on UHF frequencies. To be useful, the radios in use need to be of "data grade" which means they can go from TX to RX within 50ms where as most radios like a Kenwood D710 does that in about 150ms! Companies like Tekk used to make data radios but there aren't any of these radios on the new market as far as I know. 2.b TNCS : Hardware vs Software ------------------------------- When packet radio first came out in the 1980s, it required dedicated hardware to interface between the radio and the computer. Many of these TNCs also had features like PBBS systems to leave messages, route packets via Netrom, etc. all without the computer on. As time has progressed, many of these TNCs were miniaturized, were optimized to use very little power, etc. Today, common TNCs available are the Kantronics KPC3+, Timewave PK96, Coastal Chipworks TNC-X / TNC-Pi, Kenwood D710, etc. You can still find TNC2-based TNCs like MFJ1270, Kantronics KAMs, and AEA / Timewave PK232s, etc. In more recent times with computers having decent quality sound cards, the base TNC function can now be completely executed in software. Software programs like SV2AGEW's AGWPE for Windows and Tom Sailor's Soundmodem opened up hardware-less world. Programs like AGW/PE became full suites with lots of features but they were still pretty simple at their core. In recent times there is now UZ7HO's Soundmodem for Windows, WB2OSZ's Direwolf for Linux, Mac, and Windows, and other software TNCs that are leveraging the power of the computer to improve the weak decode of packets, etc. Reliability: Hardware TNCs offer the simplicity of setting things up once and forgetting it. That's great and reliability key. Many people still dismiss software / soundcard based TNCs because of their previous experience of using Microsoft Windows which would change/reset it's audio levels after patches were installed, etc. With the pairing with Linux, all of those inconsistent level issues are gone. There are even tricks with Windows to ensure sound card audio levels remain stable. KI6ZHD's recommendation: Direwolf for Linux You can read more about software TNCs here: http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#6.softtnc If you prefer HW TNCs, I have some cheat sheets for those: Timewave/AEA PK232: http://www.trinityos.com/HAM/CentosDigitalModes/misc/AEA-PK232-TNC-notes.txt Kantronics KPC3: http://www.trinityos.com/HAM/CentosDigitalModes/misc/KPC3-TNC-setup.txt Kenwood D710: http://www.trinityos.com/HAM/CentosDigitalModes/misc/D710-TNC-setup.txt 2.c Picking Packet Software --------------------------- Back in the hayday of Packet (early 1990s - just before the Internet and dialup modems starts to become popular), there was a lot of software out there for packet. Over time, most of the commercial software died off like PKware, Pakkrat, PKTerm, etc. but there are some still out there. Linux: ------ My personal focus with HAM radio is with a pure Linux environment. Linux's biggest strength here is that it supports AX.25 natively in the OS itself. While there are several packet applications for Linux, there are still more available for Windows (or even DOS) but I'm not going to cover those in this document. There are Linux packet BBS programs like FBB (still maintained), JNOS (still maintained), BPQ32 (still maintained), TNOS(not sure if it's maintained), and others. For enduser software, there are several serial terminal programs to connect to hardware TNCs like Minicom (ncurses text interface), Putty (GUI), etc. To take full advantage of Linux's native AX.25 stack, there is a program that I maintain: Linpac http://sourceforge.net/projects/linpac/ The choices of software really depend on what you want to do and the platform / operating system you're going to run it on. For Linux software, check out: http://radio.linux.org.au/?sectpat=packet&ordpat=title Some of my other favorites are: UroNode - node software (for sysops) FBB - BBS software (for sysops) Windows: -------- There is a lot more software out there for Packet on Windows but I'm not all that familar with them. I know some people are very fond of the XPware program which natively supports the multi-stream abilities of Kantronics TNCs while not requiring to be in KISS mode. Check out http://www.dxzone.com/catalog/Software/Packet/ for a list of other Windows packet program possibilities. Mac: ---- There are a few options for AX.25 support on OSX. Sure, you can run a serial terminal program like iTerm to connect to your HW TNC. There is the program Multimode which is commercial software for $89 which natively supports some level of packet but I don't know how good or extensible it's interface is. Direwolf - As of Direwolf 1.4, it's AX.25 stack includes support for for both APRS packets and CONNECTED mode (classic packet). The connected session support can be accessed via Direwolf's AGW/PE API support as well as using Direwolf's serial or TCP KISS interface and connecting to an external AX.25 stack like the one built into Linux. In recent times, there have been some new alternative though I haven't used any of these in detail: #AX.25 in JavaScript https://github.com/echicken/node-ax25 #APRS / AX.25 in GO https://godoc.org/github.com/dustin/go-aprs # More APRS / balloon https://github.com/chrissnell/GoBalloon #TNC Mux https://github.com/chrissnell/tnc-server #Libraries https://libraries.io/go/github.com%2Fsamuel%2Fgo-dsp%2Fdsp There are also some Java-based AX.25 stacks available though I don't have any experience with them. You can learn more about a few of these in my Linux doc: http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#6.softtnc ------------------------------------------------------------------------------- 3. Setting up a packet station This is a huge topic in itself on how to connect radios, TNCS/sound cards, etc. I have many detailed instructions for Centos Linux on 86: http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html Debian / Raspberry Pi OS / Ubuntu Linux on ARM: http://www.trinityos.com/HAM/CentosDigitalModes/RPi/rpi4-setup.html If you're interested in running packet on Linux, I recommend a few things here: PC hardware / VM: ---------------- - Packet radio can be setup pretty quickly on most Debian based distro like Debian, Ubuntu, Mint, etc. More business centric distros like Centos, RHEL will take more work but they will work too - x86 systems: If you'd like to try out a packet and a lot of other HAM radio software on Linux with everything pre-built on a USB pendrive (doesn't touch your computer's hard drive) on your X86 bsaed PC or VM, check out: Andy's HAM Radio ISO - http://sourceforge.net/projects/kb1oiq-andysham/ Ps. I recommend the use of the "Universal USB Installer" Windows program ( http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/ ) or the LiveUSB-creator Linux program ( https://fedorahosted.org/liveusb-creator/ ) to send the images to USB pendrives and also give yourself at least 1GB of persistant storage (or more) to allow programs to save their configuration files, add security updates to the Linux side of things, etc. I personally would recommend to only use 8GB or larger pendrives and give yourself 4GB of persistant storage. Raspberry Pi / ARM boards: -------------------------- - KM4ACK's Pi-Build (an a-la cart Rpi image that you choose what you want) https://github.com/km4ack/pi-build - AE7GN's Nexus Pi image (a minimalisic image) https://github.com/AG7GN/images - W3DJS's HamPi image (a fully build, massively pre-built image): https://github.com/dslotter/HamPi - Other, older images: - From the maintainer of FBB and FPAC, Bernard offers an Rpi image as well (as of Feb 2017: http://f6bvp.free.fr/AX25_BBS_Node_RaspBerry_Pi_install.html - If you'd like to try out a pre-built Linux SD image that includes a very easy to use AX.25 configuration GUI, check out Hal-Digital: http://sourceforge.net/projects/haldigital/ NOTE: It should be worth noting that this image hasn't been updated in some time (Raspbian Wheezy based) but the setup GUI is quite simple yet powerful. Beyond that, I encourage you (the reader) to feel free to email me about any specific questions you might have. I'd be happy to give you my view on on things, give you more URLs to help your research, etc. It's just too complicated and vast area of topics to address in this one document! A few final points: - As they say: Antenna! Antenna! Antenna! - At all costs, get your antenna outside. You just won't be able to do much with an antenna that's inside even with a lot of power. It might be a pain for people in apartments, etc. but it really is required to have even decent level of performance. - For 2m only antennas, I've fallen in love with the Diamond CP22E. HRO had them on sale just a little bit ago for $45 and they are usually $53. - HT vs Mobile - 5w only goes so far. A gain antenna will help a LOT but if it's not enough, you need more power to be heard. You could get an amp for a HT but it starts getting complicated and I generally recommend to get a mobile radio WAY before getting an HT amp. Disable all RX power saving features Disable APO Disable all PL tone squelch Open the Receive squelch on the radio to be always open ------------------------------------------------------------------------------- 4. What frequencies should you use? Well, that all depends on where you live. Here in the South Bay Area of California, there are several high level nodes that can get you to very far away places. There are also lots of local stations too. Who you can talk to all depends on your station (the ability of your antenna, your radio, and power) as well as the remote station's abilities. To hear what's around you, you need to first determine what are you local packet frequencies. Almost all regions on the planet have repeater coordinators and frequency coordinators. Some of the larger areas also have packet coordinators. Here in Northern California, we have the Northern California Packet Association (NCPA): Main NCPA page: http://ncpa.n0ary.org/ Here is the NCPA station database: http://ncpa.ampr.org/cgi-bin/database/ncpa.pl I recommend to start out with finding the "band plan". From that, do you want to connect to BBSes? Do you want to chat with remote HAMs live? Figure out what you want to do, change your radio's frequency to the right type of traffic and listen for a while to see what activity is around. I've put together some packet maps for California and parts of Nevada here: http://www.trinityos.com/HAM/index-ham.html#packetmap There are also various packet nets out there. In Norcal, there is one Sunday night at 8pm: http://varmintal.com/ahamp.htm I also have a very detailed Mheard list that I maintain if you're interested ------------------------------------------------------------------------------- 5. Making Connected Connections Once you have a working packet setup, you'll want to connect to remote destinations. This can be done either via CONNECTED or UNCONNECTED sessions. We'll talk about CONNECTED sessions first. In a connected session, every step of the communication is tracked and checked. If there are any errors in the packets, the packet is resent. This is called an ARQ mode where it retries vs. a mode has extra error correction data in it called FEC (Forward Error Correction). Physical TNCs: -------------- When using a physical TNC like a Kantronics KPC3, you would use the "c" command to make outgoing connections. For example to connect to the remote station LPRC3, I would use "c lprc3". If everything is working, I would get a connection established connection and I would start to see data from the remote side Linux ----- If you have a setup Linux machine, you could use the "axcall" (sometimes named "call") program to make outgoing connections. Assuming your setup has everything working and your outgoing interface is named "vhfdrop", you would make an outgoing connection with "axcall vhfdrop lpc3". ------------------------------------------------------------------------------- 6. Understanding Kantronics KNet and KaNet TNC interfaces Here on 145.050 in the South Bay Area of California, there are several high level and low TNCs and other machines you can connect to. The LPRC3, WOODY, KHILL, and KBERR are all Kantronics TNCS but they can be a bit complicated so let me give you the secret decoder ring. Most of the TNCs here in Norcal are named after locations. For example there is BERRY, KBERR, and K6JAC-4 which all THREE names are the *same* TNC. Why? Specific functions: K6JAC-4 : this is the specific amateur radio trustee's callsign and SSID. If you connect to this "K6JAC-4", you will connect to what's called the Kantronics K-Net node. This is the full featured Kantronics node where you can connect to the internal Personal BBS (leave simple messages for the sysop or other callsigns), make outgoing connections (plain AX.25 and Netrom connections), see remote Netrom routes to other nodes, etc. Here is what a K-Net TNC prompts look like: -- BERRY:K6JAC-4} TYPE 'HELP' OR ? FOLLOWED BY COMMAND FOR MORE INFORMATION BYE BBS CONNECT CQ HELP INFO LINKS MHEARD NODES PORTS ROUTES STATS USERS SYSOP -- BERRY : This is an alias for the same above "K6JAC-4" K-Net node just to make it easier to remember. The chosen name infers that it's up on Mount Berryesa next to Clear Lake, CA. It's your pick on which name you choose to connect to it. KBERR : This is an alias for the Ka-Net node side of the Kantronics TNC (notice the "a" in there). This is a very simple interface to also make simple AX.25 outbound connections and list the heard stations. This is also the side of the TNC that is the UNPROTO digipeater that can be used for unconnected messages, QSOs, and what we use for the UNPROTO net here on Sunday nights at 8pm. Here is an example of those Ka-Net TNC prompts: -- ###CONNECTED TO WILD NODE KBERR(K6JAC-6) CHANNEL A KBERR is the KaNode in the BERRY TNC ENTER COMMAND: B,C,J,N, or Help ? -- K6JAC-6 : (a bit of an anomaly here) - this "-6" SSID is configured on the Kantronics TNC to send data to the RS232 serial port for interactive chatting. The usual standard here in Norcal is to set this up on the -1 SSID but it's not like that on this specific TNC for some reason. As for BBSes, yes, there are BBSes still around. The NCPA or Northern California Packet Association is our group to coordinate these things and they also have a very nice database you can check out. Anyway, there are generally two types of BBSes out there these days: - Classic general purpose BBSes - http://ncpa.n0ary.org/bbsindex.html - EmComm centric BBSes (here is that database I mentioned) http://ncpa.ampr.org/cgi-bin/database/ncpa.pl?records_per_page=25&columns_to_view=category&columns_to_view=nodecall&columns_to_view=nodealias&columns_to_view=frequency&columns_to_view=digicall&columns_to_view=digialias&columns_to_view=city&simple_search_string=&sort_field1=category&sort_field2=city&first_record_to_display=25&session_id=d125b05b0a3cb3699961d1abe43019f6& Many of these EmComm BBSes do support full world-wide BBS forwarding, Internet-based SMTP email, classic BBS bulletins (called floods), etc. There are all kinds of different BBS software running out there (JNOS, ARY, FBB, BPQ, etc) so you'll have to figure out which ones you like! ------------------------------------------------------------------------------- 7. Making UnConnected Connections (UNPROTO) Making CONNECTED sessions to remote TNCs is very reliable but that's only half the story with packet. You can also send out packets that are UNCONNECTED. These unconnected packets won't get any ARQ / packet retry treatment if packets are lost (like CONNECTED sessions) but it's a great way to get packets to multiple different areas at almost the same time. What do I mean? For example, If I use the digi path: KLPRC3 KBERR KRDG KCORN KVOLC KBETH TAH0E Everyone in the greater Mt Berresa (KBERR), Redding (KRDG), Corning (KCORN), Sierra Foothills (KVOLC), and South Lake Take (TAH0E) areas will hear my packet! You also might be familiar with this concept this is EXACTYLY what APRS uses to sent it' s packets using it's WIDE-n system. The difference here is that APRS's uses the same UNPROTO digipeating concept but with a subtraction system. You can learn about all that in one of my other documents on my website such as: http://www.trinityos.com/HAM/Aprs/APRS%20Beginner%20Guide%20-%20K9DCI%20Ver%205-1.pdf Anyway, here on the local 145.050 frequency, you can monitor the frequency and see what digipeater paths people use. From that, you can generally figure out where they are located based on which digipeater comes FIRST in their path. Here, almost all digipeaters are prefixed with a "K" meaning Kantronics KaNode. Here is the path I use from Santa Clara, CA using the Linpac program: KI6ZHD to DAVID via KLPRC3 KBERR KRDG KCORN KVOLC KBETH TAH0E It's not a requirement that the "K" be present as it's just a NorCal naming convention. Some NorCal owners have chosen to not follow the standard we put out there. An example of a non-standard KaNet TNC setup is "TAH0E" (South Lake Tahoe), "ROSE" (North Lake Tahoe), "WOODY" (Woodside), etc. ------------------------------------------------------------------------------- 8. Next Steps: This document is intended to be a very lightweight intro to packet. To learn more, I'd recommend to read: Some of the other recommends intro docs mentioned at: http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#5.pkttutor For a more complete but complex document, read the packet sections found in: http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html ------------------------------------------------------------------------------- 9. FAQ: a. AX.25 vs. Netrom connections With the software I'm using (AGW Packet Engine and AGWTERM), it seams you can connect to a call sign via a route. I assume the route includes suggested nodes like WOODY, KHILL, KBERR. So I'm making an AX.25 connection to the call sign with the suggested route - right. From there I'm essentially telnetting with the other call? Well, it's a little more complicated than that. If your using AGWPE, you're making basic AX.25 connection to say KBERR (simple Ka-Net node). If you then made a connection from KBERR to say LPRC3 (a K-Net node), that would also be a plain AX.25 connection. On KBERR, the "mheard" list would only show remote paths... *not* Netrom routes. More on that in a bit. Now, let's change it up a bit. Let's say you connected from your home station to BERRY (notice the missing K - this is the full K-Net node) and then made a connection to LPRC3. Since BERRY is the full K-Net node, it will try to make a Netrom connection to LPRC3 and not an plain AX.25 connection. If you run the command "nodes", you'll see all of the *routes* to not only heard remote TNC but remote networks many hops away. This is what netrom is for.. to let you connect to distant machines without having to know each hop along the way. Make sense? b. When I connect to WOODY I seem to be disconnected immediately but a connection (AX.25) remains up. Know what's going on? WOODY's signal is very poor these days and I think once you make a connection request (a very SHORT packet). Then WOODY tries to send you a longer response, your path is so weak that it keeps retrying and retrying and finally it just gives up. You need to see if you have better connectivity to other nodes in your area. c. What call sign should I connect to for the UNPROTO net? UNPROTO or UI packets are connectionless.. just like APRS. I'm less sure on how to send unproto packets with AGWPE in Windows (I'm a Linux guy) . According to http://www.soundcardpacket.org/4probtx.htm , they say AGW-Term can send UI, UNCONNECTED or "ASK QRA" packets. I do know that the satellite centric UISS program can send them well too. The main Sunday night unproto net web URL is here but is very centric to KPC3 TNCs. I'm happy to help fill in the blanks - http://varmintal.com/ahamp.htm ------------------------------------------------------------------------------- 10. Advanced packet - not using AFSK for the mode; use Fldigi As mentioned in the 300BAUD HF packet section, this was one of the first packet modes but it doesn't work very well. The crux of the issue is that the AFSK mode and the lack of forward error correction hurts it. Modern modes to the rescue! Programs like Fldigi have long offered many different HF digital modes that supported different speeds, FEC, ARQ, etc. but they were only available to Fldigi itself. In recent times, Fldigi now supports the KISS protocol so just like connecting to a classic hardware packet TNC, you can now use a software connection to connect the packet AX.25 system to any mode supported by Fldigi! I have detailed this in my HamPacket documentation: http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#16b.hf-ax25 ------------------------------------------------------------------------------- 20. Errata 01/18/21 - Finally added the "what is packet" section - Updated the link for the Raspberry Pi and Ubuntu documenation - Added more links to other pre-built Rpi images 01/18/20 - Added more details on unproto paths 05/09/17 - Updated the doc to reflect that Direwolf now supports connected packet sessions - Updated thoughts on other software TNCs 12/10/16 - Added a note on how to make outgoing Connected AX.25 sessions - Added URLs for additional reading - Fixed some misnumber chapters 11/21/15 - Added notes on tuning the radio settings for best packet reception 10/26/15 - Added recommended USB and Rpi images - Added Next Steps section - Added Mac options 10/24/15 - First revision