Amateur Packet Radio

So you may have heard about packet radio in the distant past, but what is it today?  Packet radio became a reality in the early 1980's when ASCII (American Standard Code for Information Interchange) was approved as a method for data transmission over the air.  It was in its prime until the 90's when the internet took over.

Yes packet radio is the basis for APRS (Automated Packet Reporting System) on 144.39 Mhz, but packet is more than just unconnected packets.  Packet can be connected packets finding their way around the world by a hierarchical method of location addressing.

The intricacies of packet are best explained by this series of documents written by WB9LOZ.

Packet is not dead, it is alive today and passing information for the National Traffic System, Bulletin Boards, and personal messages between hams.  Packet can get through when the internet can't.  Packet is error-free, it may have re-tries but when it does get through, the message crosscheck insures that the data is intact.

Look at all the packet activity around the world on the nodemap.  There are more than what are shown here.

http://nodemap.g8bpq.net:81

Packet operates primarily on RF via the 2 meter band for local hops, and 20 meters for longer hops.

• Typical frequencies are on FM 2 meter band: 144.93, 145.01, 145.03, 145.05, 145.07, 145.09 and 145.53 MHz running 1200 baud.

• HF BBS in North America, you can find the "Network 105" BBS on 14.105 MHz LSB running 300 baud.

• There are backbone links between BBS's on 220 and 440 Mhz as well, but most of the local activity for users is on 2 meters.

So how do you get in on this technology?  All you need is a 2 meter FM radio and some knowledge of where the packet activity is in your area.  You can use a SignalLink, or any sound card as a modem.  Sound card modem software packages are SoundModem and Direwolf.  You can use a Terminal Node Controller that was purchased at a local hamfest or fresh off the shelf of your amateur radio product dealer.  The favorite TNC is the Kantronics KPC-3.  This TNC contains the appropriate firmware to maintain a Bulletin Board System (BBS) within the TNC itself, requiring no external devices other than a computer with a terminal program to access the data over an RS-232 serial port.

What if you want more?  What if your QTH is the only one with access to the BBS backbone of the packet radio network?  In that case you may want to become a SYSOP (System Operator).  This is the next level of BBS system.  It can accept messages and traffic from BBS's via the Internet or from an RF source.  It can distribute the internet gathered bulletins and pass messages back through the BBS backbone.  In this case you want to look into BQP32.  Written by G8BPQ this fully featured software suit will enable your node to become a fully featured BBS net/rom.  And there are versions for Linux and Raspberry Pi as well.

If the documentation seems overwhelming, or unclear there is a shortcut for Linux users.  Run the bqp-config configuration software from AC0KQ.  Run it once, get the settings roughly the way you need, and then don't run it again.

Still confused, need it all step-by-step.  NL7OM has the guide for you.

Here is an excellent guide to each parameter in BPQ by AG6QO.

So after all that configuration you are ready to get online.  My node is CLYPA:N3FIX on 145.030 Mhz, part of the Underground Packet Network of Central Pennsylvania.  This node acts as a digipeater and serves to forward BBS messages and serve the South Central Susquehanna Valley from Cly, PA near 3 mile Island.  The antenna is a classic Ringo-Ranger fully restored and mounted on top of the roof fed by LMR-400 coax.  The rig is a simple 25 watt Azden PCS-4000 courtesy of KA3LJL.  The TNC is a PK-232 MBX running KISS mode operated by a first generation Raspberry Pi running PiLinBPQ software.

• N3FIX-1 is the BBS server
• N3FIX-2 is the CHAT application

 

The humble Ringo-Ranger

The humble CLYPA alias node in the basement running unattended.

K3CHB had a good idea to install the Raspberry Pi INSIDE the PK-232.  This is a pretty good idea, and I may try that sometime.

Packet Radio - BBS generate Automatic Bulletin

Packet radio is fun and all but if you want to be serious about generating useful bulletins it is rather a chore to type them up.  What is required is a way to post an automatically generated bulletin from a text file source.  Sounds easy right?  It actually is.  This is designed around a Linux operating system, and some pre-requisite software is required.

BPQ32, expect, and telnet

Install these packages on your Linux computer like you normally would.  In this example I will show how to use any text file that you might generate, and post it as a BBS Bulletin.

Let's start with a text file.  It can be any text file, the internet of things and a home automation system allow us to capture data around us and put it in a text file reporting values for a day.

The Telnet access to BPQ32 (or linbpq) in this case must be set up correctly.  This will give us command line access to the packet BBS, and therefore the world if we want.  The expect command in Linux is clever.  It expects some output from stdout and replies with a response on stdin.  It will just be like typing the information into the command line yourself, only the .exp script will do it for you.  The text file is read in and translated into binary, this is key otherwise the file will not maintain the formatting it originally had.  No one likes long lines on a BBS system.  Keep it to less than 80 characters across when you generate your text file.  Then the expect command can spawn a telnet connection and step through logging into your BBS to send a bulletin.  You might want to just verify your login prompts on your own BBS.  They may differ, change any text in quotes after the expect command to match your system.  Finally the bulletin text can be inserted and the expect script can just log itself out of the telnet connection.

You will notice a \r at the end of some of the commands.  This is a carriage return, just like hitting enter on the keyboard.  Without it the command won't hit enter and won't go to the next step, so don't forget them.

In your home directory (in this case I'm running this on a Raspberry Pi), so the /home/pi directory I've made a folder called BBSScript.  My telnet host actually runs on a non-standard port 8010, so you'll have to change that and any other text in bold to suit your needs.  My standard outgoing message file is msgout.txt, and in the example it is being sent to SUBJECT@WW.  You can categorize your bulletin however you like.  Save the file as sendbulletin.exp and make it executable with a chmod u+x command.

#!/usr/bin/expect
set timeout 20
set msgfile [open "/home/pi/BBSScript/msgout.txt" r]
fconfigure $msgfile -translation binary
set msgout [read $msgfile]
close $msgfile
spawn telnet localhost 8010
expect "user:" { send "MYCALLSIGN\r" }
expect "password:" { send "MYPASSWORD\r" }
expect "MYALIAS:MYCALLSIGN} Nodes" { send "bbs\r" }
expect "BBS>" { send "sb SUBJECT@WW\r" }
expect "Enter Title (only):" { send "BULLETIN SUBJECT\r" }
expect "Enter Message Text (end with /ex or ctrl/z)" { send "$msgout\r" }
expect "EOF" { send "/ex\r" }
expect "BBS (Expert)>" { send "b\r" }

That's the extent of it.  It is really that easy.  Have another shell script overwrite your msgout.txt file daily, weekly, or any time via a crontab job.  Then call this exp script for automatic bulletin generation.  You can even call this script from inside your other script.

The last post I made about the weather report on AllStarLink can be modified to gather your weather from the internet and generate the msgout.txt file.  Think up your own clever bulletin topic.

73 and good DX

de N3FIX