When I first started tinkering with BPQ32 I felt like someone spilled a 1000 pieces puzzle on my desk. This is why I started to write my own documentation and you can use it at your own risk. Please give (dis)credit to the author when citeing this document. Feedback in particular corrections and additions are very welcome.
This document does NOT cover all of BPQ but just those parts the author needed to get his NTSD BBS up and running. This is not a substitute for the official BPQ documentation.
Peter M. Dintelmann
BPQ32 is a software suite developed and maintained by John Wiseman, G8BPQ/ GM8BPQ. It's purpose is to build multi-user radio applications like BBS. For simplicity BPQ32 will simply be referred to as BPQ in the following.
Naming a radio software suite after the suffix of the developer's callsign is not uncommon. RLI by W0RLI and FBB by F6FBB are other examples for this.
BPQ consists of three functional blocks: ports, the switch, and applications.
+-----------------------------------------+ | +- - - - - - - - - - - - - - - - - - -+ | | | node | | | +------+ +------+ +------+ +------+ | | | | port | | port | | port | | port | | | | | | | | | | | | | | | +------+ +------+ +------+ +------+ | | | +---------------------------------+ | | | | switch | | | | +---------------------------------+ | | +- - - - - - - - - - - - - - - - - - -+ | | +--------+ +--------+ +--------+ | | | appli- | | appli- | | appli- | | | | cation | | cation | | cation | | | +--------+ +--------+ +--------+ | +-----------------------------------------+
The combination of switch and ports is often referred to as the node which traces back to the original purpose of BPQ as a software to build packet radio nodes.
The purpose of ports is to connect BPQ with the outside world in particular to give users access to the system.
Typically radio transport protocols (e.g. packet radio, Pactor) are implemented by distinguished hardware or software devices like TNCs, teletype controllers, sound card modems and software and the like which are connected to radios. Those devices are interfaced with BPQ through so-called ports.
Alternatively a port can also emulate a device so that other software components can easily interface with BPQ using the port as if it were a (real hardware) device. This is only reasonable for standard device interfaces defined by well-known protocols like the various flavours of hostmode.
The port configuration contains the relevant information to configure the device in use.
Examples for ports offered by BPQ are:
|SCSPactor||SCS PTC controllers||AX.25, Pactor|
|Fldigi||Fldigi soft||Fl modes|
|KISS TNC||TNC emul||KISS|
The purpose of applications is to offer functionality to users.
Applications come with their own usage protocols which range from simple text messages (e.g. chat, DX cluster) to rather complex ones including data compression as used in BBS.
Examples for applications are:
|Chat||interactive chat between users of the system including chatrooms|
alert the sysop and open a terminal window for a chat with him (if present at the station)
Bulletin Board System to store and forward messages to end users and other BBS. The BPQ BBS application can in particular be used to access a remote RMS station (i.e. it can act as a WL2K client).
|DX Cluster||messaging system for DX spots|
Radio Message System gateway to the Winlink 2000 CMS servers. This is for authorized WL2K gateway stations only.
Some applications like the BBS are part of the BPQ software suite and come with the standard installation. Additional applications can be implemented using the BPQ application programming interfaces.
Every application is uniquely identified with a numerical id inside BPQ and furthermore has a name which can be used to invoke the application from the switch.
Understanding the switch is essential even if you only want to run a BBS because all your inbound and outbound connections are managed by the switch.
The purpose of the switch is to
- control devices through ports
- route connections to ports
- give access to applications
Thus the switch acts like a classical switchboard.
The switch does not have a user administration of its own. Certain operations like the control of radios require extended privileges ("sysop") and are protected by one-time passwords when used remotely.
There are many ways to configure the interplay of callsigns/ SSIDs, applications, and ports. Therefore you will need a big picture first before you start configuring BPQ.
An applications can be either invoked by issueing a command at the switch prompt or by binding a port to the application and connecting to this very port.
Planning and setup guide
After having read the above overview we suggest to take the following planning steps before you go for your own installation:
1. Identify the applications you want to run from the following list:
- sysop bell
- node access
2. Identify the ports you will need for external access e.g.
- Pactor port
- Winmor port
- Packet radio port
and the hardware you would like to use for them. Is there a particular HF radio you want to use for scanning?
3. Make up a table with applications, (external) ports, and callsigns (including SSIDs if you plan for packet radio) e.g.
4. Identify the local applications you need to interface with and the ports needed to this end:
- Winlink Classic: TNC emulation port
- FBB: TCP port
- Messaging client: TCP port or TNC emulation port
- BPQ remote terminal: TCP port
5. Install the software and start with the most simple config: just your callsign and the loopback port.
6. Configure the simplest port from your list. Choose the telnet server port if you have it on your list.
7. Extend your configuration with external ports (packet, pactor, winmor) and the scanner. One port at a time. Make sure each port is working correctly beforing adding the next one.
8. Configure the simplest application from your list e.g. the sysop bell.
9. Set up a simple BBS configuration: users and forwarding rules. No connect scripts for outgoing connections yet.
10. Make the integration with your local BBS software e.g. Winlink, FBB, and a messaging client for yourself.
11. Test your forwarding rules and the integration with your local BBS software.
12. Start writing and testing BBS forwarding scripts.