Main /

Packet Radio - Hitchhikers Guide to becoming a BPQ SysOp

This Hitchhikers Guide to becoming a BPQ SysOp (aka. HG2BPQ) is a compilation of the notes I collected during my journey to set up a BPQ node.
Even though I'm a amateur radio operator since 1976, I was on hiatus for some years and missed the Packet Radio boom of the 80's.
With the encouragement of another OM, I went on this journey to learn what I had missed and I found that there is a lot of information out there, but hardly organized, mostly outdated and not updated. The best one I found so far is from Charles R. Verdon, W5KAV Digital Traffic Network (DTN) but there where still some roadblockers that took me some time to resolve and some are still mysteries which we could chase together
I will not give you here the full recipes, specially regards some of the Raspberry Pi and Linux skills, which you will have to find somewhere else.

The following SysOps (in order of appearance) contributed significantly to my learning:

Eduardo Castillo, LU9DCE
Jean Pierre Roussarie, F1OYP
Red R.R. Tuby, PE1RRR
Brian Rogers, N1URO
Mark Taylor, N5MDT
Aly Badawy, AL0Y

I would also suggest very strongly to subscribe to the BPQ support group https://groups.io/g/bpq32 with a very active community and the extraordinary support from John Wiseman himself and don't forget to check out the links I have put in the reference section at the bottom of this page.

73 and have fun, because that is what Amateur Radio is all about.
May the Layers of the Ionosphere be with You

Building your BPQ Node on a Raspberry Pi

The first step to becoming a BPQ SysOp is to install and configure your own node. This is not very difficult these days, and the chosen platform is usually some flavor of the Raspberry Pi. A BPQNode has no large demands of CPU power, so any of the boards out there should be sufficient (not sure a Pi Zero would work though).

This means that you need to master a few basic Linux skills and this page does not intent to provide you with that in case you don't have them yet. There a plenty of resources out there to aquire those.

Once you're ready, you have to decide which path to follow to build one. You can just go to the BPQ Homepage and download the code and install it manually following the instrucions given and experimenting a lot with all the little tweaks neccesary to make it work. Or you can use one of the several shell scripts that are availabe in the wild. I used one from Willem A. Schreüder AC0KQ sucessfully a few years ago and you could get it here

Another way is to use the Linux package from the Online Amateur Radio Community, which is extremely easy to use. You can find the Wiki page with all the instructions here. The OARC has severla very usfeull pages on Packet and specifically on Raspberry-Pi builds. It is worth exploring!

Configuring your BPQ Node

Coming soon

Configuring BPQ as a Winlink CMS

Coming soon

Setting up routes

How do Hierarchical Addresses work?
Configuring node routes
Configuring message forwarding

(by Aly Badawy, AL0Y)
BPQ differentiates between three types of messages

Flood bulls
Directed Bulls
Personal messages

There is a very small difference between "Personal Messages" and "Directed bulls" that I will be mentioning later, but to keep it simple and to not confuse, let's talk about bulls first.

When you first setup your BBS using BPQ, one of the fields you enter is the BBS HA (Hierarchical Address) route. I will use mine as an example: AL0Y.#NNJ.NJ.USA.NOAM

This field is very important, as this is how the BBS later differentiates between directed bulls and flood bulls. So, let's assume I receive a message on my BBS (locally or forwarded to my BBS), the BBS will then examine the destination flood area. If the message is addressed to @NJ.USA.NOAM, this message will be considered to have reached its flood area (because my BBS is in NJ.USA.NOAM). If the message is addressed to @USA.NOAM, it's also considered to have reached its flood area, because my BBS is in USA.NOAM. Same applied if I received a message for @NOAM.. You get the idea.

So, the 3 previous examples are considered by the BBS to be "FLOOD Bulls"

Now, let's assume I receive a message for KY.USA.NOAM.

Even though I am located in USA.NOAM, this message is directed to only KY state, and not NJ. The BBS considers this a "DIRECTED BULL". Same applies if I receive a message for @CAN.NOAM or even if I receive a message addressed to @EURO, @AUNZ, @SOAM, etc. They are all considered as "Directed BULL". We now know how the BPQ system differentiates between DIRECTED and FLOOD bulls.

But what difference does it make? The difference is how and where the messages are routed.

When the BBS wants to forward a "Flood bulls", it will send it to *ALL* BBSs that have the route in their forward configuration, where "Directed Bulls" are forwarded to *ONLY* one BBS which has the best match for a HR. The best match, is based on WHICH LEVEL of the HR is matched.

So, I usually send all EURO messages to PE1RRR but I have a GB7YEW configured to receive @GBR.EURO. If I have a message for FRA.EURO (and I have no configured BBS to receive FRA), my message will go to PE1RRR for relay, but a message for GBR, will go to GB7YEW since GB7YEW matches 2 levels of the route, but PE1RRR matches only one level.

If I am configuring forwarding with N5MDT, who is in #STX.TX.USA.NOAM. N5MDT and I'm in a different state, but both are in USA.NOAM. So, in my BPQ forwarding configuration for N5MDT, I put "USA.NOAM" in the "FLOOD BULLS". I can also add "WW" in "Flood bulls" since any WW message is a flood bulls by definition. See, we both are in USA.NOAM.WW (if you will).

However, I also want to send him "Directed Bulls" addressed to @TX.USA.NOAM. So, I add "TX.USA.NOAM" in the field of "DIRECTED BULLS and PERSONAL MESSAGES" I also know (by having a conversation with N5MDT) that he has an out let to AR.USA.NOAM and GA.USA.NOAM. Since I don't have any forwarding partner to those states, I can add those HRs for AR, and GA in N5MDT's "directed bulls" field.

Now, let's say I receive a bull directed to "IN.USA.NOAM", and I don't have IN.USA.NOAM in any of my forwarding partners configurations. This message will die on my BBS. the same happens for messages directed to un-recognized areas like "LATNET" for example, but we will get to that in a moment.

I hope the previous explained the difference between Flood and Directed Bulls. Flood are directed to your same area, and are sent to ALL who match. Directed bulls are for areas outside your HR, and are sent ONLY to best match.

So, where do personal messages fit? Personal messages are routed EXACTLY as directed bulls (and hence share same configuration field). But there are two difference still:

if you receive a Personal message on your BPQ BBS, and you don't have a route to forward, your BBS will generate a Service message to the "FROM" callsign informing them that the BBS is unable to forward that message and it may not reach its destination. For directed bulls, a similar message is generated but to the SYSOP of that BBS instead of the bull's originator.
the second difference, is in BPQ, you can choose to "SEND P messages to more than one BBS" This is a checkbox that you can choose in BPQ. Enabling this options sends the P message to ALL matching routes and not only the best match. It adds confidence that the message will be received by allowing multiple paths (in case one route is incorrected, forwarding station across the route is no longer functional, or lost forwarding with another station) Remember that BBSs will not receive a message twice though (they still have same BID)but it allows multiple paths (I recommend having this option enabled)

I mentioned earlier that there are non-recognized (HR-wise) area like LATNET, VKNET, etc. To forward those to a specific station, you will need to add those in the "ATSIGN" field of that station. In BPQ you can also add "ALIASES", so for me, I added the following aliases to my BBS:

AMSAT:WW

ARRL: USA

LATNET:SOAM

VKNET:AUNZ

But note that aliases in BPQ are not a re-write of the HR. It only tells your own BBS to treat LATNET as if it was addressed to SOAM. but it doesn't change that to the receiving station (not as rewrite.sys in FBB where it actually changed the destination)

So, unless your forwarding partner (assuming running BPQ) has configured LATNET as an alias, or added it to some other station's ATSIGN field... messages to @LATNET will die there.

The official document referencing this topic could be found here

Operating your node

Operating your node using QtTermTCP
Monitoring the BBS traffic
The tail command is a command-line utility for outputting the last part of files given to it via standard input. It writes results to standard output. By default tail returns the last ten lines of each file that it is given and it is used here to follow the logLatest_BBS.txt log file in real-time and watch as new lines are written to it.
Type the following on your SSH console:

tail -f  logLatest_BBS.txt

Monitoring message forwarding (by Mark Taylor, N5MDT)
Access the web page for your own BPQ Node, then click on Mail Mgmt and select Messages.
You will see a list of all the messages sent and received by your BBS. This is where I spend most of my time, looking at each message to make sure it forwarded to the proper place. You can click on each message number and in the right pane you will see the message details From, To, Subject, etc.

At the bottom of that pane is a list of all your forwarding partners, each in his own table cell. The cell changes color based on the forwarding status. No color if the selected message was not forwarded to this person, yellow if it is queued to send to this person on the next expiration of the forwarding timer, and green if the message has been forwarded to this station. As I select each message I pay attention to the VIA line, and the forwarding partners, and make sure that the message was forwarded properly.

Here are some of the considerations if the message was not forwarded at all (no color), either:

The message is for you.
You received it from the only possible place you could forward it.
There is no place to forward it.
You have an error.

Regarding #3, there will always be a message or two addressed unconventionally, that you have no place configured to forward. Don't worry that it didn't forward. You are not required to forward all messages. If it has an invalid HA then it probably should not be forwarded. Ask a friend or Elmer for assistance since there are so many cases and it would be difficult to address them all here.

Many of the messages are sent via WW and you may have several forwarding partners that you send all message to. You will be able to see the pattern of the station colors. All of the WW message will have that same color pattern of green cells, with one exception. You will not send a message back to the station from whom you received it. So one green cell may be missing.

When you hit a message sent VIA USA then there may be slightly fewer green cells and when you select a message that is sent VIA another country, so you should only see ONE green cell. If you see more, then your BBS forwarding is not configured properly. There is no reason to send a message destined for Europe to multiple USA stations, and no reason to send USA messages to Europe (baring the most unusual cases.) So, watch for that as well.

All of the above applies mainly to Bulletins. Personal messages will look slightly different. Personal messages are only sent to ONE forwarding partner. So, when you see only one green cell then the message could be a bulletin to another country (or even another general area) or it could be a personal message.

The easiest way to see if your configuration is correct for directing personal messages is to send each of your partners a WP Update as a personal message. To accomplish that, on the BBS Configuration you should have Send WP Updates checked, and Send as Personal Message selected. In the Send Updates to: add each of your forwarding partners, one to a line, using the format:

WP@N5MDT

Once per day your housekeeping should run, sending a personal WP Update message to each of your forwarding partners. As you select through each of the messages you will soon find those WP message. Each should be sent only to the one station intended. The VIA will have his call, and the cell containing the call will be green. Many will simply send WP Updates as bulletins, although I block those. It's not wrong to send WP Updates as bulletins, but it is not recommended to do it. The WP server that runs in the background is looking for a message directed to user WP.

[My notes]
Here you also can:

Edit header and forwarding flags directly
Edit Text of messages
Save your changes
Save Message to a file
Print one or more message
Export one or more messages

Message Status Values are:

N Not read or forwarded

Y Has been read

$ Bulletin that still has stations to be forwarded to

F Has been forwarded to all stations

K Message has been killed

H Message has been Held. (ie can't be forwarded, read or killed, except by sysop).

D Message has been marked as Delivered. Used only for NTS Messages

Maintaining the health of your node

Updating the operating system
The operating system of your Raspberry Pi needs to be maintained current as well as all the software you have installed on it from the repositories. For that purpose, you will need to execute the following commands on your SSH console periodically:

apt-get update
apt-get upgrade

Updating BPQ
The same way as with your operating system, you will need to keep your BPQ software updated. Since you have not installed it from a repository, you will have to do this manually. The beta versions seem to be very stable und updated frequently, so if you update frequently you will get the fixes as new issues surface
I have included the following steps in a short shell scrip that looks like this:

#!/bin/bash
#
cd /opt/bpq                       # This is BPQ's install folder
sudo systemctl stop bpq.service   # Stops the BPQ service
sudo mv -f pilinbpq plinbpq.old   # Renames the current BPQ executable as a backup
# Downloads the latest beta version:
sudo wget http://www.cantab.net/users/john.wiseman/Downloads/Beta/pilinbpq 
sudo chmod a+x pilinbpq           # makes it executable
sudo systemctl start bpq.service  # Restarts BPQ service
#

Restarting BPQ
BPQ has a know issue with the BBS that makes it hang, so regular restarts are required. The recommendation is to restart it at least once a day to be sure it does his job.
In order to accomplish that, I decided to write a small script named bpq-restart.sh that I have scheduled with cron.
The core of the script looks like this:

#!/bin/bash
#
systemctl restart bpq.service	# Restart BPQ service
#

You could add success/failure control and email the respective notifications if you wish.

To edit your cron schedule, you will need to execute the following commands on your SSH console:
crontab -e

And write:

00 2 * * * /bin/systemctl bpq-restart.sh bpq.service

It is also a good idea to verify it with:
crontab -l

This example will restart your node every day at 2AM

Backing up your system
It is always a good practice to back up your data, specially in this environment where an MicroSD card is the main data storage. These cards are nice and convenient, but they do have a limited life, so I attached an external HD to my RasPi for this. It is actually on my LAN on another RasPi, but you will have to figure out what works best for you.
With this setup, I back up my BPQ install (yes, the whole install is not that big and it will make the restore easier) and keep the last 10 backups. I do all of this with the following script:

#!/bin/bash
#
DATESHORT=`date +%Y%m%d`			# Date string without dashes for filename
SRCDIR=/opt/bpq/				# Source directory
DESDIR=/mnt/disk1/bpq				# Destination directory
FILE=bpq$DATESHORT.tar.gz 			# Backup file name
REMOVEDATE=$(date --date="10 days ago" +%Y%m%d) # throw away files older than 10 days
REMOVEFILE=bpq$REMOVEDATE.tar.gz		# File to remove
#
# Let's start with the backup
#
systemctl stop bpq.service			# Stop BPQ service
tar -cpzf $DESDIR/$FILE $SRCDIR	> /dev/null 2>&1# Tar directory
rm $DESDIR/$REMOVEFILE > /dev/null 2>&1 	# Remove old files
systemctl start bpq.service			# Start BPQ service
#

I would recommend scheduling this with a cronjob as showed in the example above and as you can see, this restarts your node too, all in one take.

You should also have a backup copy of the MicroSD card, taken every time you do major changes to your operating system.
I use Win32 Disk Imager on my Windows machine to do that and you could find all the details on The PiHut or on any other site out there.
The recovery process would then be:

Burn your new MicroSD card with the latest backup image using Win32 Disk Imager (make sure you use a card with he same capacity)
Restore the latest daily BPQ backup onto the new MicroSD card
Restart BPQ and you should be back in business.

Packet Netiquette

The rules of any other text based communications, like chat, newsgroups or e-mail also apply to Packet and there are a few additional considerations you have to make due to the fact that most of the traffic is over, well... radio.
You should assume that p-mail is not secure nor allowed to be encrypted, so never put in a message anything you would not put on a postcard.
Respect the copyright on material that you reproduce. Almost every country has copyright laws.
If you are forwarding or re-posting a message you've received, do not change the wording. If the message was a personal message to you and you are re-posting to a group, you should ask permission first. You may shorten the message and quote only relevant parts, but be sure you give proper attribution.
A good rule of thumb: Be conservative in what you send and liberal in what you receive. You should not send heated messages even if you are provoked. On the other hand, you shouldn't be surprised if you get flamed and it's prudent not to respond to flames.
Make things easy for the recipient. Many mailers strip header information which includes your return address. In order to ensure that people know who you are, be sure to include a line or two signature at the end of your message with contact information, but keep it short. Remember there are radio links and any extra character takes up unnecessary resources.
Dont get too fancy with bulletin branding. We don't need to see multi line banners of your callsign. Keep it to a minimum.
Be careful when addressing bulletins. There are certain groups that where created for special purposes, like the SYSOP group. You should probably not address any bulletin to SYSOP@WW unless there is something going on with a misconfigured system somewhere.
Do not change the bulletin groups in your replies. If somebody posted to ALL@WWW, then keep it there, otherwise it will be difficult to track the conversation.
A bulletins is communicating with many people via one message and is quite analogous to communicating with one person with the exception of possibly offending a great many more people than in one-to-one communication. Therefore, it's quite important to know as much as you can about the audience of your message.
Do not change the subject line, it makes it more difficult to follow conversations.
Remember that the recipient is a human being whose culture, language, and humor have different points of reference from your own. Remember that date formats, measurements and idioms may not travel well. Be especially careful with sarcasm.
Use mixed case. UPPER CASE LOOKS AS IF YOU'RE SHOUTING.
Be brief without being overly terse. When replying to a message, include enough original material to be understood but no more! It is extremely bad form to simply reply to a message by including all the previous message: edit out all the irrelevant material.
Use symbols for emphasis. That *is* what I meant. Use underscores for underlining. _War and Peace_ is my favorite book.
Wait overnight to send emotional responses to messages. If you have really strong feelings about a subject, indicate it via FLAME ON/OFF enclosures.
Limit line length to fewer than 65 characters and end a line with a carriage return.
Mail should have a subject heading which reflects the content of the message.
"Reasonable" expectations for conduct via p-mail depend on your relationship to a person and the context of the communication. Norms learned in a particular p-mail environment may not apply in general to your p-mail communication with people across Packet. Be careful with slang or local acronyms.
Know how large a message you are sending. Including large files such as 7Plus image files or programs may make your message so large that it cannot be delivered or at least consumes excessive resources. Many BBSs filter these out for those reasons.
Read the bulletins for one to two months before you post anything. This helps you to get an understanding of the culture of the group.
Messages should be brief and to the point. Don't wander off-topic, don't ramble and don't send messages solely to point out other people's errors in typing or spelling. These, more than any other behavior, mark you as an immature beginner.
If you should find yourself in a disagreement with one person, make your responses to each other via p-mail rather than continue to send messages to the group. If you are debating a point on which the group might have some interest, you may summarize for them later.
Don't get involved in flame wars. Neither post nor respond to incendiary material.

References
WB9LOZ - Introduction to Packet Radio
PY2BIL - BPQ User and SysOp Commands Cheatsheet
G8BPQ Home Page
W5KAV - Digital Traffic Network (DTN)
AC0KQ - BPQ Quick Start with bpq-config
Online Amateur Radio Community
Massive repository on Packet Radio from PD9Q
A very interesting site with some key tips from PE1RRR
BPQ Nodemap
BPQ Chat Network