What’s the Vector 4000, uh Victor?

Preface

This began as a journal blog entry just about a newly acquired antenna however I have expanded it to include some backstory about the early days of my youth before I became a fully licensed radio amateur, a little bit of my life from the age 14 and up.

I hope you enjoy the read, please let me know if there are things that you would like to hear about in the future. This story is not embellished, though it does lack some pieces I had originally intended to publish but the things I wanted to include with the permission of a friend unfortunately didn’t materialize in time but will hopefully make it into another journal entry at some point in the near future.


QRM

That afternoon, my radio had been particularly noisy with the usual noisy pest- skip from the continent. All the channels were full of it, just a splatter of constant atonal screeching- the all too familiar FM carriers colliding from people too far away to hear one another. The whine and raspy hash of mashed up signals mixed with Italian and Spanish SSB wobble & warble breakthrough- it was useless trying to get out anywhere “local”.

While clunking the channel selector on the radio I settled on some unusually strong signals. I’d heard POCSAG pagers from the local hospital before but these were entirely different and I could tell that some, but not all were coming in on the skip. I really didn’t know what I was listening to but the tones were pleasant and definitely structured in packets. A header, a data burst and a tail, each one a little bit like the loading sounds from a cassette loaded computer game.

It just to happened that I’d actually been flipping through the Maplins catalogue while sat on the bog. Looking back now, it was probably a bit weird but for me at the time, it was how I chose how to blow all of my saved up birthday & pocket money.

I’d seen the kit several times in the mag already but not really bothered to read the item description before, but I’d got a spark from the idea that it might actually be for this type of signal so I looked it up. A packet radio modem kit, 1200 baud speed. Hmmm.

I had a hunch. After a neatly coordinated bus and train trip to and from the Maplins in Coventry, I’d bought home a pile of components and a plastic box.

After successfully constructing and then setting up the modem with the radio and then configuring the terribly old and slow Compaq Deskpro XT PC with the Baycom software, the first packets decoded floored me.

Readable data traveling through the air from France, the Netherlands, Germany, Italy, Spain and probably more- incredible!

This was gonna be huge for me and my mates. Unlimited “online” chatting, connected so no need to use the mic to talk all night- we could chatter & trollolol on about cheese without any distractions or interruptions or sleep- today in the age of smartphones this is seriously taken for granted.

Ramsey Packet Modem PDF


The BBS

By 1996 ENG01A BBS had served quite a large portion of the Midlands during its four or so years of operation. The radio also served as a digital packet repeater (digipeater) during frequent radio path openings to the continent as well as a “hotspot” for forwarding mail up to Cannock and across to Birmingham. Some of my mates even used my system to hop to distant stations on the continent during “sporadic-E”-layer ionospheric propagation– it was awesome to watch in action!

The BBS in its final form was a machine comprised of a “custom built” 486 DX built from 2nd hand scrap, with a Kantronics KPC-3 Terminal Node Controller (TNC) connected to a “Superstar 3900” CB radio- operating on Channel 24. (27.235MHz). Running inside a shed that would easily spike at over 35°C during the summer months, the gear was punished pretty severely!

Networked to the secondary machine located in my old teenage bedroom via a massive run of RG-213 coaxial Ethernet cable, enabling remote access, saving uncountable trips down to the owl house attached shed during freezing cold or miserably wet British weather.

Teenage Bedroom & secondary BBS circa 1997: Beige

Fast Moves

By aged 17, having passed the RAE (amateur radio exam qualification), and then diving head first into the internet, it was not long before an online relationship quickly matured to a very real life getting-engaged situation. A sudden and swift decision on my part to save money on the phone bill and weekly plane tickets- I ultimately quit my job and moved to live in the Netherlands, with some hard graft put in at Ericsson R&D, we finally purchased our first home together in 2001.

The shack, as it arrived from England in the Netherlands.
All but one of these radios originally belonged to Pete (G4KQU, now EI4JR).

Early Bloomers

CB radio had been booming & blooming in the Netherlands with digital packet radio networks for almost a decade. Dutch legislation had effectively enabled the digital adoption by deregulating the Citizens Band entirely. This lead the way for manufacturers to legally advertise and sell packet radio equipment to quite a substantially larger market than just radio hams. A stark contrast compared with the UK.

Later, unlicensed usage and the allowance of data over RF would be ratified and somewhat protected in the CEPT specification with several channels/frequencies specifically set aside for packet/data.

The CB and ham packet stations in the Netherlands eventually began to decline beyond a sustainable network in the mid-2000s. For the CBers, The sunspot cycle had come to an end and so too did the interest in long distance (DX). For the hams, there were fresher new digital-mode pastures to play with now that the internet had most certainly won.


COVID-19

The lockdown due to the COVID-19 pandemic has seen a noticeable increase of activity on amateur radio as people- perhaps likely perturbed by everything going on- have come back to their radios. As a consequence the packet community has been busy helping a number of hams set their packet stations back up again. Yay! 🎉

The idea to put up a new 10 meter band antenna began to gather momentum as personal forecasts for 2021 predicted it likely to be up to another year locked indoors- something we are already quite familiar with due to Ilona’s cancer treatment in 2019. So I purchased a shiny new antenna from the local ham shop and it was delivered the very next day:

Woah.

The Vector 4000 is a J-Pole style antenna.

The radiator is the short stub on the lower left that couples to the large vertical in the center.

At the top of the antenna is a wire ball for hypothetically reducing corona discharge- high voltage RF (radio frequency) sparking into the air when running very high power. Though I suspect this is yet another window dressing feature of CB antennas- its probably for the looks. I operate almost exclusively within my limits and I have consideration for my densely packed in neighbors so it’ll never be presented with more than 100 watts of power.

The circular basket? Probably extra capacitive coupling for the radiator element, though- jury is still out on this one… Looks cool though 😎 📡

If only we could see RF with our eyes… 👀

The Vector 4000 next to the 20 meter band inverted Delta Loop. The Loop is roughly 9 meters wide, as you can see the Vector 4000 kinda dwarfs it.

Performance

Yay! 😁 I’m once again able to work 10 meter band digital modes, so you may hear me on FT8 or WSPR from time to time.

I have checked the packet signals on 11 meters (CB)- there is a bit of “local” FM packet activity from stations about 80-100km away, but it is too weak to decode- unfortunate!

Luckily I am able to log into those packet stations remotely via the internet gateway and can remotely trigger their transmitters, so far I have worked out who I can hear: NL9UTR and NL9SHB – Utrecht and Den Bosch respectively. Bit of a reach to Rijen apparently. 😿

Due to quite high levels of neighborhood interference from power-line networking, solar panels, crappy laptop chargers and ISM band encroachment- its a constant S5 of noise here, even with local phase cancellation mitigation on the packet frequency. However, during good skip conditions, signals from abroad can easily be 20db+ so its a bit of a mixed bag- now on to some testing ⚡️

Early Signal Reports

Above are a couple of maps showing my experiment on the 10 meter amateur band with FT-8, an insanely narrowband slow digital transmission capable of penetrating signal-to-noise ratios previously only touchable by Morse code.

With the use of advanced digital signal processing machine FT-8 can decode signals that are barely perceptible to the human ear.

Read up on WSJT-modes here.

The maps were created with the use of the reverse beacon network– a bunch of automated listening stations. The RBN is mostly unmanned ham equipment left running while the operator is away, decoding and reporting what they can hear to a central database on the Internet, (pskreporter.info for example).


Conclusion

So the Vector 4000 is basically as good as I remember it being back in the 90s. It is limited in use though, as one cannot tune it to anything other than the designed band.

The resonance drops way off after 1.5MHz bandwidth curve so don’t be expecting this to work as a multi band antenna.

For 10 meters, the Vector 4000 is an exceptional performer, the reception across the shortwave spectrum is also decent but not overwhelmingly as you might expect for a vertical.

Weather robustness – this Vector 4000 has happily survived some close-to-gale force winds recently, metal fatigue is a factor I may yet have to contend with as the aluminum joints aren’t all that large or convincingly strong. My previous Vector 4000 back in the 90s suffered from a severe clobbering from an Oak tree, breaking it in half, though if not for that, it probably would have lasted many more years.

All of the bolts, joints and connections have been triple wrapped in “Scotch 23” electrical self amalgamating tape which does offer some extra tensile strength as well as waterproofing, so we will have to see!


Bonus quiz round: what “B” was the name of a successful British television game-show popular with the 90s youth?

Go to Page 2 to find the answer!

I’ll have a Sporadic-E please Bob

You will see several mentions of Sporadic-E on this site, so I’ve taken a shot here at explaining the phenomenon in my own words. I hope you enjoy the tangent from the usual posts, but if you are already versed in solar physics feel free to skip along- wait maybe you won’t get that reference unless you read this bit… 🤔

Credit: The ESA/NASA Solar and Heliospheric Observatory (SOHO)

Sporadic E events- a phenomenon frequently observed in the early 90s as the increased frequency of the Sun’s coronal mass ejections created observable disturbances in the Earth’s ionosphere.

The phenomena occurs naturally every 11-year cycle, waxing and waning between the peaks- known as the solar maximum– during these periods, the most sunspots are produced.

Sunspots are a product of the complex interactions between the suns powerful magnetic fields and the fusion reactions occurring deep within the core of the sun. Magnetic fields twist and contort through the plasma as the sun rotates on its axis, eventually some of these powerful magnetic fields can no longer hold on to their couplings and break apart in violent and destructive solar flares, scattering the sun’s plasma deep into space. Sometimes, directly at Earth.

The difference between a solar maximum and a solar minimum.


Powerful magnetic interactions during solar flare events also cause magnetic disturbances that travel at the speed of light towards Earth. These are known as geomagnetic storms and can in the most extreme cases cause severe problems for the electrical grids that deliver power to our industry and homes, as well as damage satellites that operate out beyond the protection of our magnetic field.

Approximately three days after a geomagnetic storm, the sub-light-speed particles ejected from the sun arrive at Earth and hit the magnetic field, and if powerful enough can sometimes reach the upper ionosphere. These particles are extremely high-energy, if they were to reach the surface of Earth they would have a devastating and deadly effect on biological organisms.

The magnetic field of Earth is generated by the planet’s liquid core- much like a bicycle dynamo, the magnetic interaction though rotation of the different densities of liquid metal in the core produce strong magnetic fields that protrude out from the north and south poles, enveloping the Earth with a magnetic shield.

As the sun shines, it also emits solar radiation in the form of a constant stream of charged particles- this ambient bombardment is known as the solar wind.

Aurora Borealis as captured from the International Space Station

The solar wind speed increases dramatically during sunspot activity, putting greater pressure on Earth’s magnetic envelope. As the magnetic field interacts with the solar wind, particles billow around the envelope towards the poles- the weakest points of the magnetic field- where the charged particles interact with the oxygen and nitrogen gas in the upper atmosphere- this can be observed visually as the Aurora Borealis and Aurora Australis.

Sporadic-E is the name designated for the unpredictable property of the ionosphere when the solar wind travels deep and at high enough energy through the ionosphere that it causes a plasma to occur. This plasma is conductive, and therefore capable of reflecting radio frequency back to the ground.

This is how high frequency (HF) radio waves that would otherwise be absorbed by the ambient ionosphere propagate great distances beyond line of sight. Although the radio waves always travel in a straight line from the source, they can bounce off the sporadic plasma and back towards the ground. In combination with the ocean, this can sometimes happen multiple times before the radio wave is intercepted by a radio receiver. This is colloquially known as radio skip.

Other forms of radio propagation such as Tropospheric Ducting affect VHF and higher frequencies.

For the most part the F1 and F2 layers form from the separation of the radio-absorbing D layer at night when the solar wind reduces pressure on the magnetic field facing away from the sun, as Earth rotates from day to night- this allows shortwave to propagate further which is why distant radio stations can only be heard coming through in the evening hours.

Sporadic-E layers of the ionosphere are responsible for the majority of radio propagation phenomenon at upper-HF frequencies, such frequencies as the common CEPT and UK CB radio specification and the 10, 6 and 4 meter amateur radio band.

Gilze-Rijen Airbase on LiveATC

Over the last year LiveATC.net has been provided with several live audio feeds that can be streamed here.

There are now several feeds on LiveATC.net covering the military base Gilze-Rijen and the Gilze-Rijen CTR. The airbase is approximately 2km from my location and more of less in the approach one of the runways.

The airbase is home to a fleet of Apache, Chinook and Cougar helicopters and home to a museum of World War 2 aircraft such as the Mitchel B25 and Spitfire. There are also a number of light aircraft and gliders that use the runway from a clubhouse located nearby and civilian aircraft entering the CTR are required to contact the tower during operational hours, so it can get quite active at times.

The language spoken on frequency is usually English, with the exception of some civilian CTR interlopers. The military aircraft frequently practice manoeuvres in coordination with NATO.

Up until recently every 4 years the airbase would host an international air show often attracting in excess of 250,000 visitors per day. Unfortunately due to the pandemic this has been cancelled for obvious reasons.

Hardware & Software

The setup consists of two RTL-SDR dongles redundantly chained together to a single vertical antenna, each dongle working independently on two different Raspberry Pi systems. This gives continuous operation if one of the SDRs locks up.

rtl_airband is used to manage, tune the SDRs, mix (if needed) and encode the streams. rtl_airband makes use of the Raspberry Pi’s GPU to offload some of the processing form the CPU, which is quite neat.

The rtl_airband encoders connect directly to a local icecast server. LiveATC then pulls the streams from the icecast server at roughly 8kb/s per mono feed.

My setup has an additional feed- a mix of the Ground and Tower frequencies, each separated into either the Left or Right stereo channel.

rtl_airband configuration

devices:
({
# mode = "scan";
type = "rtlsdr";
serial = "ehgr_71ppm";
gain = 35;
centerfreq = 125.500;
correction = 71;
mode = "multichannel";
sample_rate = 0.96;
channels:
(
{
freq = 125.330;
squelch = 24;
outputs: (
{
type = "icecast";
server = "192.168.1.xx";
port = 9000;
mountpoint = "ehgr-fallback";
name = "EHGR Tower Backup (rtl_airband, UHF)";
genre = "ATC";
username = "source";
password = "password";
},
{
disable = true;
type = "mixer";
name = "mixer1";
balance = -0.75;
ampfactor = 1.0;
}
);
},
{
freq = 278.125;
disable = true;
squelch = 24;
outputs: (
{
type = "icecast";
server = "192.168.1.xx";
port = 9000;
mountpoint = "ehgr-ground";
name = "EHGR Ground UHF";
genre = "ATC";
username = "source";
password = "password";
},
{
type = "mixer";
name = "mixer1";
balance = 0.75;
ampfactor = 1.0;
}
);
}
);
}
);

mixers: {
mixer1: {
outputs: (
{
type = "icecast";
server = "192.168.1.xx";
port = 9090;
mountpoint = "ehgr-twrgnd";
name = "EHGR Tower & Ground Mix"
genre = "ATC";
username = "source";
password = "password";
}
);
},
mixer2: {
outputs: (
{
type = "icecast";
server = "icecast.server.example.org";
port = 8080;
mountpoint = "mixer2.mp3";
name = "Ground + Delivery (not used just an example)"
genre = "ATC";
username = "source";
password = "mypassword";
}
);
}
};

Redundancy

The above setup is duplicated on another Raspberry Pi that feeds into a different icecast mount point.

If icecast loses the feed from the SDR illustrated above, it will automatically drop the fallback feed. In the unlikely event of both feeds going down, then the icecast server selects the fallback’s fallback.

This consists of a looped MP3 fed by a continuously running instance of ezstream with a nice digitally synthesised voice apologising for the inconvenience! Beep beep beep…

When the feeds recover, icecast automatically reconnects the listeners (LiveATC) back to the main feeds.

Packet Web Portal, Games & More

This is a demonstration of several cool features I have added to a regular packet radio switch, one of which enables access to crucial information that would otherwise have be unobtainable for a vulnerable and isolated radio amateur without Internet (they exist!)

Packet Web Portal: COVID-19

The idea was initially sparked by Sholto, K7TMG who had expressed the desire to fiddle with websites over packet during a casual discussion in the round table packet chat.

At first, I wasn’t too keen on the idea namely because of restrictions on the type of information permitted over amateur radio links, however after some thought it occured to me that it would be possible to implement a portal with some precautionary measures in place, but the idea was then shelved for a few weeks.

While it may have been fun to play with, on its own merit- it was likely to be a total waste of time!

A couple of weeks passed and a series of packet mails arrived from a elderly fellow OM who was in total lockdown due to heightened measures surrounding COVID-19 in the UK. He had no Internet and his only contact with outside was via a volunteer who came by his home once a week to bring groceries.

This bothered me perhaps more than it should, but in these mail exchanges over packet radio he was asking me to look things up on the Internet for him. Uh… eureka much?

My reaction

Software

LinBPQ – (BPQ32) by John Wiseman, G8BPQ

BPQ switch is the system that connects all of the bits and pieces together: Radio, Computer, Internet, Services and applications.

For simplicity, a simple telnet terminal is sufficient
to interface with BPQ32, and BPQ32 also provides a web-browser based terminal.

Hey, I designed this icon!

UZ7HO’s modem has been ported to multi-platform by G8BPQ. The sound-modem is used for interfacing radio with the BPQ switch, in turn providing access to users via RF. Released currently under alpha and beta test as QtSoundModem Software-Terminal Node Controller.

QtSoundModem (Alpha Test)

A terminal program. The DOS program Paket 6.2 running in DOSBOX is for demonstrative purposes only, it is not necessary to run this when more modern alternatives exist…

However for this test case, Paket 6.2 is actually the terminal used by the fellow ham mentioned in the introduction. It has been used in this scenario to optimise the appearance of the web portal for the end user.

Paket 6.2 for DOS

I mentioned earlier the restrictions on certain types of data over amateur radio links, this is where OpenDNS FamilyShield came into play, and a HTTP proxy server that serves as the filter for requests going to the internet. This is accomplished by setting the proxy to use OpenDNS’s DNS-servers, therefore inheriting their DNS-based safety features.

Another risk reduction measure is the Express Menu- this makes getting information directly pertaining to COVID-19 easier and a simple matter of entering two or three digits. One of the choices available enables one to enter any web address if desired, and those requests are logged, and if necessary- filtered (denied).

Screenshot of the WEB Portal via QtTermTCP Client

Source Code

All of the tools demonstrated in the video such as Packet Web Portal, Games, Graphs – are all available from my GitHub:

https://github.com/pe1rrr/packet-scriptlets

Do you have a Raspberry Pi* and fancy having a go?


A ready-to-go build of (pi)LinBPQ combined with QtSoundModem and QtTermTCP is available via GitHub, and an introduction posted right here.

* The minimum-fuss specification for running all of the software is a Raspberry Pi 4.

Unfortunately, the RPi3 has some issues with the ALSA libraries and PTT timing on GPIO and serial ports, meaning any PTT-timing sensitive application may not work as intended out of the box.

This bug affects not only QtSoundModem but Direwolf TNC as well.

The OSS-ALSA sound bridge workaround for RPi3 is included in the GitHub repository. However, if you are looking to purchase a Pi specifically for this purpose, definitely go for the RPi4.

Words of Encouragement

You may find this additional info useful, in response to a comment posted on the original unedited video:

“Is this TCPIP over AX25?”

No, technically the big difference is that we are using AX25 encapsulated over IP rather than the other way around to link nodes together over the internet where RF either isn’t available or practical.

The software TNC with the waterfall visible in the background is linked into the switch over KISS-over-TCP. This means we can run dedicated little boxes like Raspberry Pi4s and radios bunched together in one place with the switch physically located else where.

QtSoundModem is then linked into the switch (the node) running on a separate Raspberry Pi elsewhere in the house.

Setting this up is not easy, as there is no one-size-fits all. It can be just as complex as setting up a enterprise-level Cisco router- where there may be technical manuals out there but basically your network design is unique to you and mine is to me, depending on your needs.

This means there is very help on offer that would not have some huge bias towards a certain intended purpose.

The documentation for linbpq is thorough, but requires full assimilation before even picking up and starting to write a config file as boy is it modular as heck!

This also applies to other network stacks like JNOS, the manual for that is thick, so it is not a problem with the software itself- but mostly a mild case of PEBCAK.

Not to be too discouraged, I have put together a bundle to get some basic functionality up and running but it will still require some due diligence and has a dependency on basic Linux operational competence (LinBPQ RTG).

Hopefully the README.md included with linbpq_rtg is sufficient to get most started. You can leave a comment if you have questions below 👇 or better- join the BPQ32 Groups.io Support Group.

QtSoundModem Auto-Starting from Systemd

I don’t run the QtSoundModem on the same machine as the node so I use a systemd service script to automatically start up QtSoundModem and put it on a virtual-VNC session that is independent from the physical desktop.

The following systemd scripts call a pair of bash scripts located within the home directory, so that modifications can be done to them without having to reinitialize the systemd service.

Packages Required

sudo apt install realvnc-vnc-server
sudo apt install screen

Note: realvnc is free on the Raspberry Pi, alternatives that may work for other platforms: tightvnc or tigervnc

Systemd Scripts

/lib/systemd/system/qtsm.service


[Unit]
Description=QtSoundModem Start Script
After=vvnc.service
Wants=vvnc.service


[Service]
Type=forking
WorkingDirectory=/home/pi/bin
Restart=always
RestartSec=20
StartLimitInterval=60
StartLimitBurst=3
User=pi
Group=pi
ExecStart=/usr/bin/screen -S QTSM-Console -d -m /home/pi/bin/startqtsm
SyslogIdentifier=QTSM-Debug


[Install]
WantedBy=multi-user.target

/lib/systemd/system/vvnc.service

[Unit]
Description=Shack Desktop Start Script by PE1RRR
After=network.target


[Service]
Type=forking
WorkingDirectory=/home/pi/bin
Restart=always
RestartSec=20
StartLimitInterval=60
StartLimitBurst=3
User=pi
Group=pi
ExecStart=/home/pi/bin/vvnc
SyslogIdentifier=Shack-VNC


[Install]
WantedBy=multi-user.target

Virtual Virtual VNC?

vvnc for virtual-VNC, yep its a virtual virtual desktop, one that runs independently from the default usually found running as a clone of the desktop monitor display.


This script starts a virtual VNC screen that can be attached from any device such as a smart phone, iPad or other desktop Pi.

/home/pi/bin/vvnc

#!/bin/bash
vncserver -kill :1
vncserver :1 -geometry 2732x2048

Set permissions to execute:

chmod 755 /home/pi/bin/vvnc

QtSoundModem Start Script

/home/pi/bin/startqtsm

cd /home/pi/bin

# Launch invisibly
# /home/pi/bin/SM nogui

# Launch with GUI

# Set the display number here. If HDMI connected monitor, this is usually :0

# For VNC sessions, this is determined in the desktop- check it with “echo $DISPLAY” in a shell within the VNC.

DISPLAY=:1
export DISPLAY
/home/pi/bin/QtSoundModem # path to your QtSoundModem binary

Set permissions to execute:

chmod 755 /home/pi/bin/startqtsm

There are a couple of ways of launching QtSoundModem, I prefer to have the GUI to keep and eye on the waterfall and monitor packets etc.. there is an option to start it invisibly in which case- you can opt to use the nogui mode, and remove all references to vvnc.service in the previous scripts as they won’t be needed.

Initialise systemd

Need only doing once:

sudo systemctl enable qtsm.service
sudo systemctl enable vvnc.service

To Stop/Start manually:

sudo service qtsm start

If the vvnc service is not yet running qtsm’’s service will auto-start it for you. This is due to the “Wants=“ directive in qtsm.service.

Restarting the vvnc service will kill any vnc server running on the display defined in the /home/pi/bin/vvnc file before starting up again.

Displaying the VNC Session

If all has gone well, then QtSoundModem should be displayed on your Virtual VNC screen. That is, assuming you’ve connected a VNC client to it to display it!

The common way to connect to the VNC server is using the address and the display number. 0 (zero) nearly always refers to the hardware-wired display, and the first virtual server after that is :1

e.g IP-address:1

vncviewer 192.168.0.44:1

Monitoring the Consoles

As these systemd scripts launch with the screen command, this provides a way to keep an eye on the console output without it thrashing the SD Card with continuous writes. To attach to the running screen console, try the following:

screen -r

If you only have one screen session running then it will re-attach automatically, if not then it will show you a list from which you must provide a string after the -r that can be wildcard-matched either with the process number or the console’s name.

Starting LinBPQ from Systemd

Ideal for Raspbian Buster.

Optional but recommended:

Note in the above example there is a line referencing an application /usr/bin/screen. If you do not have the screen package installed, it is highly recommended to do so- screen will create a virtual console for linbpq, ideal for checking, diagnostics, debug/errors etc.

sudo apt install screen

When the node is running, while logged in as the user defined in the linbpq.service:

To attach:
screen -r linbpq
To detatch, press key combination sequence:
Ctrl-a d

Create the runbpq Script

I recommend running a script rather than the binary directly so that if you need to add TNC drivers or bind additional devices such as bluetooth TNCs, this would be the ideal place to put them In sequence.

#!/bin/bash
#
# Edit to reflect the directory location of linBPQ installation
cd /home/bpq/node
#
# Attempt to upgrade (if linbpq.new exists) on next restart
mv linbpq.new linbpq
./linbpq

Set execute and the correct USERID and GROUP permissions on the runbpq script AND linbpq binary. This will make it run with the correct user ID if at any point it is launched manually.

sudo chmod +x runbpq
chown <userid>:<groupid> runbpq linbpq
sudo chmod u+s runbpq linbpq

Upgrade preparation

IMPORTANT: If you drop an upgraded linbpq into the directory, you should name it linbpq.new and run the following commands on it to prepare it for when the linbpq service is next restarted (useful if running a node with a specific scheduled maintenance window).

sudo chmod +x linbpq.new
sudo chown <userid>:<groupid> linbpq.new
sudo chmod u+s linbpq.new

Starting linbpq from systemd

Create the file linbpq.service with the following contents:

[Unit]
Description=LinBPQ
After=network.target
[Service]
Type=forking
WorkingDirectory=/home/bpq/node
Restart=always
User=bpq
Group=bpq
ExecStart=/usr/bin/screen -S linbpq -d -m /home/bpq/node/runbpq
#ExecStart=/bin/bash /home/bpq/node/runbpq
SyslogIdentifier=LinBPQ
[Install]
WantedBy=multi-user.target

Edit the ExecStart path to reflect the location of runbpq on your system.

Move linbpq.service into the /etc/systemd/system/ directory

sudo mv ./linbpq.service /etc/systemd/system/
cd /etc/systemd/system/

Then run

sudo systemctl daemon-reload
sudo systemctl enable linbpq.service

Which does this:

Created symlink /etc/systemd/system/multi-user.target.wants/linbpq.service → /etc/systemd/system/linbpq.service.

And that should be it. LinBPQ will now start from boot, and you have prepared a system to assist with future upgrades of the node binary.

Further tips

You can check your systemd startup sequence status issuing:

sudo systemctl status

LinBPQ “Ready to Go”

Got a Raspberry Pi and want to get back into Packet Radio?

The LinBPQ-RTG has been moved to a GitHub repository, meaning keep it up-to-date is much easier. To download, install ‘git’ on your system and use the following command to copy the repository to your system:

git clone https://github.com/pe1rrr/linbpq_rtg

This is a complete packet radio setup for amateur radio use. The repository has binaries included for the Raspberry Pi providing the full node network stack, QtSoundModem and QtTermTCP.

The repository contains documentation and configuration pretty much ready to go, only a few things need to be edited to set your callsign, file paths and a couple of parameters such as grid square locator, GPS coordinates and APRS-IS password.

Please note this software is in Beta, it is recommended that you run all three update scripts before starting, and most importantly, read the README.md – also viewable on https://github.com/pe1rrr/linbpq_rtg

Recommended system requirements: Raspberry Pi4 if running the provided QtSoundModem soundmodem. If not using the soundmodem, serial port based TNCs can be used on a Pi Model B / Pi Zero as the performance overhead is much lower. Raspberry Pi Model 3’s have issues with ALSA driver (see: https://bugs.launchpad.net/raspbian/+bug/1819560) although a workaround has been included in the repository, see qtsm_rpi3 file.

If you wish to compile the source code yourself, download the latest archive from G8BPQ’s website/repository here. If using a 64bit OS, you must first install x86 32bit compatibility libraries before building. A binary compiled without these may execute but it will send corrupted frames, so be careful.

Good luck!

73

Red – PE1RRR

Appendix

The update scripts provided can be easily modified to download the binaries for x86 32bit Linux.

Open them in a text editor and adjust the filename= parameter.

The filename downloaded by the scripts should be changed from ‘pilinbpq’ to ‘linbpq’. The same procedure should be employed for qtsm and qtterm update scripts- just remove the ‘pi’.

Linux x86

If running a 64bit OS you will need to install the 32bit compatibility libraries. For Ubuntu and Debian, this is accomplished with:

apt-get install ia32-libs
QtTerm configured in MDI mode
QtSoundModem

Windows

For Windows users, the configuration files are compatible with the Win32 build of BPQ32 available from G8BPQ’s website here.

Be aware the configuration here is for the latest Beta so after installing the Win32 package, also download the latest beta DLL. As this package is aimed at Raspbian Linux for the Raspberry Pi it is a little out of scope to provide details for the Windows platform.

See BPQ32 Documentation

JNOS<>BPQ – Forwarding Mail over Telnet

UPDATE – Foreword: The easiest way to exchange mail between BPQ and JNOS would be to simply create a AXUDP link between BPQ and JNOS and then use NETROM connectivity to do regular AX25 connections over the link. The document below was composed before this realisation.

This foreword is here as a heads up that using Telnet method is really the longest route around the problem, and is really not recommended.

Internally Forwarding Mail to BPQ

Create a new user with BBS flags for your JNOS instance within the BPQ User Management Area.

For this account, do not use the callsign of the JNOS instance, instead use a descriptive alias. This avoids a problem with callsign collision which will usually cause JNOS to refuse to work. In my example, I will refer to this USER as RRRNOS on the BPQ side.

The HROUTE of RRRNOS is RRRNOS.PE1RRR.NLD.EURO, as configured in the mailbox settings for JNOS.

All mail for RRRNOS arrives first at PE1RRR.NLD.EURO and is queued for forwarding to RRRNOS.

In turn, we also will refer to the BPQMail instance in the JNOS configuration as MATRIX, rather than the callsign.

Configuring forward.bbs

IMPORTANT: The passwords for BPQ telnet sessions are NOT defined in the BPQMail User account, but instead in the bpq32.cfg node configuration file under the TELNET port declaration. See BPQ Telnet Server Documentation.

matrix 0023 P
telnet <bpq node address> <bpq fbbport> cronly
.<bpq port defined telnet userid>
.<password>
* 0
.BBS
* 0
<list of areas to forward>

IMPORTANT: The FBBPORT is often misunderstood as a direct connection to the BBS- when it is not. The port opens a connection to only the node which is why we must issue an extra command: .BBS

FBB sysops frequently get this wrong and wonder why their telnet forwarding to a BPQMail instance doesn't work.

JNOS ftpusers Configuration

It is necessary to provide BPQMail with an account on JNOS with which to log in and access BBS functions. This is possible by adding an account with the necessary privileges set.

JNOS won’t allow the use of an invalid callsign for a login user ID by default, to do so would require recompiling the JNOS source with one of the config.h “defines” changed (it is easy to do, but not recommended).

A workaround, if forwarding downstream to yourself– is to just use your own callsign for the login, as it would be coming from your own upstream BPQMail BBS anyway.

Permissions needed (if not using your own sysop login): Expert, BBS.

From the FTPUSERS PERMISSIONS reference sheet, sum up the permission level as such:

  • BBS: 8192
  • Expert: 16384
  • Summed together: 24576
FTPUSERS PERMISSIONS
The following is a list of the user permission values allowed in FTPUSERS file.
  Name          value    hex value    comments
FTP_READ         1        0x1       /* Read files */
FTP_CREATE       2        0x2       /* Create new files */
FTP_WRITE        4        0x4       /* Overwrite or delete existing files */
AX25_CMD         8        0x8       /* AX.25 gateway operation allowed */
TELNET_CMD       16       0x10      /* Telnet gateway operation allowed */
NETROM_CMD       32       0x20      /* NET/ROM gateway operation allowed */
SYSOP_CMD        64       0x40      /* Remote sysop access allowed */
EXCLUDED_CMD     128      0x80      /* This user is banned from the BBS */
PPP_ACCESS_PRIV  256      0x100     /* bit for PPP connection */
PPP_PWD_LOOKUP   512      0x200     /* Priv bit for peerID/pass lookup */
NO_SENDCMD       1024     0x400     /* Disallow send command */
NO_READCMD       2048     0x800     /* Disallow read command */
NO_3PARTY        4096     0x1000    /* Disallow third-party mail */
IS_BBS           8192     0x2000    /* This user is a bbs */
IS_EXPERT        16384    0x4000    /* This user is an expert */
NO_CONVERS       32768    0x8000    /* Disallow convers command */
NO_ESCAPE        65536    0x10000   /* Default is no escape char */
NO_LISTS         131072   0x20000   /* No lists displayed from mailbox */
NO_LINKEDTO      262144   0x40000   /* Disable '*** linked to'  */
NO_LASTREAD      524288   0X80000   /* Ignore lastread in <area>.usr
                                       (shared accts)*/
NO-FBBCMP        1048576  0x100000  /* Avoid FBB compression */
XG_ALLOWED       2097152  0X200000  /* Allow XG (dynip route) cmd */

Edit the ftpusers file and append:

<callsign> <password> /jnos/public 24576

Note: If this BBS is also a regular user, give them AX and netrom permissions too (add 8 + 32 to the final sum).

Configuring BPQ Forwarding

The BPQ User created with the BBS flag (RRRNOS in this example) should be visible in the Forwarding Management Area of BPQ as one of the callsigns in the list.

Click on RRRNOS user and then set the fields with the following information, if not explicitly mentioned, the fields are to be left empty.

Connect Script

ATTACH 10
C <jnos host/ip> <jnos port> TELNET <jnos userid> <jnos password>

BBS HA

RRRNOS.PE1RRR.NLD.EURO

Hierarchical Routes (Flood Bulls)

AF
AS
OC
EURO
NOAM
SOAM
CEAM
WW

HR (Personals and Directed Bulls)

WW

Enabled Checkbox/Flags (all not explicitly mentioned should be disabled)

  • Enable Forwarding [ON] Interval [600]
  • FBB Blocked [ON] Max Block [10000]
  • Send new messages without waiting for poll timer [ON]
  • Allow Binary [ON]
  • Use B2 Protocol [ON]

Click Update to finish.

Check and Test

Open a new terminal an go to your BPQ directory, open the log file using the tail command, this will open the log file and checks the file for new data is written to it every 0.1 seconds.

tail -f -s 0.1 logLatest_BBS.txt

From the BPQ Forwarding Area, select the BBS account and click Forward

Alternatively use: fwd <callsign> now from the BPQ mail prompt.

Watch the log file for errors.

If all goes well this is what you should see:

200213 16:31:41 |RRRNOS    Incoming Connect from RRRNOS
200213 16:31:41 >RRRNOS    [BPQ-6.0.19.30-B2FWIHJM$]
200213 16:31:41 >RRRNOS    0 messages to fwd to RRRNOS
200213 16:31:41 >RRRNOS    PE1RRR BBS>
200213 16:31:41 <RRRNOS    [JNOS-2.0m-B2FHIM$]
200213 16:31:42 <RRRNOS    FF
200213 16:31:42 >RRRNOS    FQ
200213 16:31:42 |RRRNOS    RRRNOS Disconnected

To test from the other direction, log into JNOS sysop console and issue:

Note: In the examples below. ‘MATRIX’ is the arbitrary name I have given to the BPQ mailbox in JNOS, it just so happens to also be the BPQ mailbox’s NETROM alias but that is not important at all as this is a telnet session, it is just for practicality.

mbox kick <bpq bbs name defined in forward.bbs>
e.g.
mbox kick MATRIX

Note: when calling mbox kick, use upper case for the callsign if there is no local mail to actually forward. This initiates a reverse forward. If you don’t use this method, and you have no mail to forward, it won’t try and connect, and as such you won’t see diddly squat happening in the log file.