BPQ Ports

From Digital Traffic System
Jump to: navigation, search


Ports connect BPQ with the outside world which allows in particular to use radios and teletype controllers with BPQ. Besides these physical devices ports for network protocols are becoming more and more important. Those are used to connect software modems like the Winmor virtual TNC as well as other BPQ nodes with each other e.g. using AXIP.

Examples for ports offered by BPQ are:

Port Device Protocol
BPQtoAGW AGW software AX.25
SCSTracker SCS Tracker AX.25
SCSPactor SCS PTC controllers AX.25, Pactor
AEAPactor AEA modems Pactor
Winmor Winmor soft Winmor
Fldigi Fldigi soft Fl modes
Telnet -- TCP/IP
TNC TNC emul hostmodes

Ports abstract the external interfaces from the switch and use circuits on the switch for use with inbound and outound connections. See above for more details on this.

The skeleton of a port config

        ... ... ...
            ... ... ...

consists of two parts: parameters which apply to ports in general are before the CONFIG token and parameters which are specific to the device in question are below the CONFIG token. The latter ones will result in commands being send to the device.

General port configuration

The following parameters are part of the general port config:


Description of the port (30 chars max) to be displayed by the NCI "PORTS" command.


Unique numerical identifier for the port used in port related commands e.g. ATTACH.


The driver used to control the device. Most port drivers are now implemented as part of the main bpq32.dll and do not require to load an external DLL.


used instead of the DRIVER statement in case the port is implemented with an external DLL (e.g. Winmor)

  • ASYNC: ASYNC board
  • INTERNAL: used for the loopback port only
  • EXTERNAL: port using an external connection

Transport protocol to be used on the port. Specifying PACTOR or WINMOR is not needed.

Hardware related parameters include:

COMPORT=nr number of the serial line port to be used for the BPQ port
SPEED=nnn speed for serial line communications

This allows a radio to be shared among multiple ports, typically a Pactor and a Winmor port. Details can be found in the section on the scanner.

Application related parameters are:

BBSFLAG=NOBBS the BBS application cannot be accessed from this port

incoming calls on the port invoke the specified application e.g. "APPL BBS" or "APPL RMS" are typically used on HF Pactor ports

Callsigns used on the port are configured with:


Inbound connections for PORTCALL will be accepted if the parameter is present. Otherwise the NODECALL will be used for inbound connections. The same goes for the aliases.

BCALL=CALL callsign used for a beacon running on this port

User related parameters are:


A list of callsigns separated by commas with a maximum string length of 256 characters. Multiple VALIDCALLS lines may be given. When the parameter is present inbound connections are accepted from the specified callsigns only.

USERS=n maximum number of concurrent users on the port


QUALITY default quality for NETROM routes on this port

"suppress all level 3/4 activity (including NODES broadcasts) on this port" and no routes are used on the port

DIGIFLAG=0/1 (de)activates AX.25 digipeating (for KISS ports)

(de)activates the MHEARD list for this port; if the parameter is not specified the MHEARD list is active by default

Gathering port data

Use the PORTS command at the terminal to list all ports of your BPQ:

    DB0NTS-2} Ports
    1 TelnetServer
    2 SCSPactor

The STATS command shows statistical for the system (see above) and for the first seven ports (more may not fit on your screen) and STATS p displays the data for the seven ports starting with port number p.

                      Port 01  Port 02
    L2 Frames Digied        0        0
    L2 Frames Heard         0        0
    L2 Frames Rxed         16       73
    L2 Frames Sent         58      109
    L2 Timeouts             0        0
    REJ Frames Rxed         0        0
    RX out of Seq           0        0
    L2 Resequenced          0        0
    Undrun/Poll T/o         0        0
    RX Overruns             0        0
    RX CRC Errors           0        0
    FRMRs Sent              0        0
    FRMRs Received          0        0
    Frames abandoned        0        0
    Link Active %       0   0    0   0

Each port has it's own window within the BPQ console showing the status of the port and active connections.

The MHEARD command (abbreviated MH) followed by a port number lists the stations heard and connected (indicated by a plus sign following the callsign) on this port. A couple of variants and options are available for the command:

Command Desription
MH p [string]

heard list for port p; only callsigns containing the given string are listed if the optional second parameter is present

MHL p [string]

heard list for port p with timestamps in local time; for the second parameter see above

MHU p [string]

heard list for port p with timestamps in UTC; for the second parameter see above

MHV p [string]

heard list for port p in PI1LAP format (including packet statistics); for the second parameter see above

MH p CLEAR clear the heard list for port p
    mh 2
    DB0NTS-2} Heard List for Port 2
    KW1U+      00:02:47:53  14.0979
    KW1U+      00:04:07:44  21.0934
    G4KUJ+     00:23:25:36  3.585
    G4KUJ+     01:22:36:33  3.586
    G0DUB+     03:23:00:49  3.585
    mhu 2 K
    DB0NTS-2} Heard List for Port 2 filtered by K
    KW1U+      Sep 10 04:25:00  7.0515
    KW1U+      Sep 09 20:50:57  14.1104
    KW1U+      Sep 09 20:35:17  14.0979

Note that additional status commands are available for some port types which are discussed in the corresponding sections.

Both the STATS statistics and the MHEARD list are cleared on exiting BPQ.

The Loopback port

The loopback port is a simple port that echos back everything it receives. Here is a sample configuration:


You can choose any port number and id of course (they must be unique within your config, of course). The diagram below shows a user using a loopback port via a telnet port connection and who types in "hello" and receives back the same text.

     TX:"hello"  +----------+      +--------+
    ------------>|          |----->|--->--+ |
                 |          |      |      | |
    <------------|          |<-----|-<-+  | |
     RX:"hello"  +----------+      |   |  | |
                 telnet port       |   |  | |
                                   |   |  | |
                                   |   |  | |
           +----------------+      |   |  | |
           | +->-TX:"hello"-|----->|->-+  | |
    "loop" | |              |      |      | |
           | +<--RX:"hello"-|<-----|--<---+ |
           +----------------+      +--------+
             loopback port          switch

Use the command "C p NODECALL" to connect to the loopback port where p is it's port number and NODECALL is replaced with your nodecall.

The telnet port

"Telnet" is the name of a network protocol used to provide network virtual terminals dating back to the early days of the internet. The telnet protocol uses special characters to control the (remote) terminal. Most telnet connections use TCP as the underlying transport mechanism.

Besides true telnet terminals BPQ also supports connections based on plain vanilla TCP connections which are also often referred to as "telnet" connections. Both types of connections are implemented in BPQ with the same port driver.

We use the term "telnet" to refer to both true telnet and plain TCP connections.

Telnet ports can be employed for the following use cases:

  • connect a remote BPQ terminal to access your BPQ
  • use telnet to access your BPQ
  • offer a web interface to access your BPQ node
  • integrate with FBB software
  • build your own application(s)

If you would like to use telnet BPQ ports (and you will) it is strongly recommended to make up a cheatsheet for the TCP ports for various purposes first, e.g.

TCP port range purpose
7000 -- 7999 TCP ports used by the BBS application directly
8772 RMS TCP (fixed)
8000 -- 8999 TCP ports for BPQ telnet server port (except for 8772)
9000 -- 9999 TCP ports for use by other applications

The skeleton for a BPQ TCP port is


        ... ... ...
        ... ... ...


The BPQ telnet driver supports four different types of connections:

  • Telnet remote terminals (TCPPORT)
  • plain TCP connections (FBBPORT)
  • TCP connections for applications (CMDPORT) covered in the section on applications
  • web interface (HTTPPORT, not discussed here)

An important use case for the telnet port is to access WL2K CMS servers which is needed to set up a WL2K RMS and will not be covered here.

Telnet port configuration

Logging for the telnet port driver is activated by setting the LOGGING flag to 1. The log file is located at


The MAXSESSIONS parameters determines the maximum number of concurrent sessions supported by the telnet driver.

The parameter DisconnectOnClose determines what happens when a user exits an application. The connection can either be terminated (DisconnectOnClose=1) or the user can be redirected to the switch (DisconnectOnClose=0) instead.


        ... ...

It is usually safer to set DisconnectOnClose to 1.

User management

The two endpoints of a TCP connection are identified by so-called socket addresses consisting of an IP address and a port number each. As there are no radio callsigns associated with the TCP connection the VALIDCALLS directive is not supported by the telnet port driver.

However an inbound connection on the BPQ network needs a callsign to be associated with the corresponding circuit on the switch. This is achieved by the user management component of the telnet port driver. This user management is used for all types of telnet server ports except applications (i.e. TCPPORT, FBBPORT, and HTTPPORT).

A login prompt is presented to a user connecting with a telnet terminal and authentication is done by means of passwords which resembles telnet access to computer systems.

A user is defined with the statement


below the CONFIG keyword where

user login user name
password user password
callsign callsign assumed by the user after successful login

optional; the application invoked after successful login; use "" if you want to stay on the switch (no application) and the parameter SYSOP follows


literal string; the user can acquire sysop privileges on the node by using the "password" command

Here is a sample config:


      ... ...

This defines two users. The first one logs in with the user name "dl4fn" and the password "secret". After logging in the user assumes the callsign DL4FN-15 and the BBS is automatically invoked. When returning to the node (using the BBS command "node") dl4fn can acquire sysop privileges.

    inbound TCP  +--------+          +--------+          +--------+
    connection   | port 1 |          | switch | stream   | appli- |
    ------------>| telnet |----------|-c-->-c-|----------| cation |
    user: dl4fn  |        | DL4FN-15 |        | DL4FN-15 | BBS    |
    pass: secret +--------+  |       +--------+          +--------+
               |             |           |                  /
               |             |        +--------------------+
               |             |       /   |
             --+--------- ---+---- -+- --+--

The reserved user name ANON is used to provide anonymous access to the node.


Neither an application nor the SYSOP flag can be specified additionally. Be careful with using anonymous access as it easily allows for callsign spoofing.

With anonymous telnet access enabled everyone can log in using their callsign (either lower or upper case) as user name and the (global) password. Note that the latter is case sensitive.

Telnet terminal support

A telnet terminal port is defined with the TCPPORT statement:

    TCPPORT=<TCP port number>

The standard port number is 8010. The following configuration options are avaialble:

LOGINPROMPT=text the login prompt presented upon connecting
PASSWORDPROMPT=text the password prompt

the connect text shown after successful login. \n denotes a new line. A builtin default text will be used if CTEXT is not specified.

Here is a sample config:

    CTEXT=Type '?' for list of commands\n

You will need a telnet terminal client software to connect to a BPQ TCPPORT port. Free software is available to this end e.g. the TeraTerm terminal suite. The VT100 terminal type usually works fine and please note that you will have to activate the "local echo" feature in some of the telnet clients to see what you type.

Plain TCP connections and BPQTermTCP

Whereas the telnet protocol provides mechanisms to control what happens on the terminal screen this is not needed when connecting with a non-interactive software component like a BBS.

The FBB software by F6FBB uses plain TCP connections to this end and BPQ offers them for integrating with FBB and other software. Furthermore the BPQ remote terminal BPQTermTCP also makes use of this feature.

Authentication with plain TCP connections is as follows: Once the connection is established the client is expected to send the user name and password on a single line each and the CR character (x0D) is used for line endings.

Plain TCP connection ports are defined with the FBBPORT config statement and multiple port numbers may be separated by blanks:

    FBBPORT=<port1> [<port2> <port3> ...]

The standard port numbers are 8011 and 8012.

Use the config line "FBBPORT=0" if you want to explicitely deactivate support for this kind of TCP connection.

The BPQ remote terminal BPQTermTCP also uses FBBPORT for communications. Copy the executable file BPQTermTCP.exe from your BPQ installation to the remote machine you want it to use on. Enter the hostname, FBBPORT port number, user name, and password to use in the Setup menu under the TCP hosts entry. The program stores all your configuration in an .INI file in the same directory the executable is located in.

Telnet Server Status

The BPQ console will show a Telnet Server Status window if you defined a telnet port. It lists all active connections (telnet terminal and plain TCP) with user names and associated callsigns. The column labeled "Queue" lists the number of bytes received on the last read operation.

When you click on the status window the Actions menu becomes active and allows you to configure logging options, to reread the port configuration, to disconnect active users, and more.

The data shown in the status window are also available with the TELSTATUS (abbreviated TEL) CLI command followed by the port number.

    TEL 1
    DB0NTS-2} Telnet Status for Port 1 CMS Ok
    dl4fn      DL4FN       0

A complete sample configuration

Here is a complete configuration sample for the Telnet Server port:

    ; TCP ports




        CTEXT=Type '?' for list of commands\n

        ; BBS on tcp/8772

The optional parameters LOGGING and MAXSESSIONS are included so that they can be easily changed if needed.

The last part with the BBS comment will be discussed in the section on BBS.

Outbound TCP connections

The BPQ telnet port driver has the capability to make outbound plain TCP connections to connect to remote FBB ports. Since the connect string will require you to specify multiple parameters (remote host, TCP port, user name, password) this cannot be achieved with the standard packet radio connect syntax. Therefore the BPQ telnet port needs to be attached first so that all parameters can be specified in a device specific form (although no real hardware device is involved here).

Thus an outbound connection is initiated with the two commands

    ATTACH p
    C host tcpport [NEEDLF] [user] [password] [command]


p BPQ port number of the telnet port
host remote host (either host name or IP address)
tcpport the remote TCP port number

optional; specify the literal NEEDLF if the remote side requires a CRLF sequence (x0Dx0A) after both the user name and password

user optional; user name for remote login
password optional; password for remote login
command optional; send this command to the remote host after successful login

Newer versions of BPQ allow to combine both the attach and connect commands into a single attach command

    ATTACH p host tcpport user password

which is helpful for defining BPQ applications based on outbound TCP connections.

Unfortunately you cannot use this mechanism to connect to a WL2K CMS with "C p server.winlink.org 8772 CALLSIGN CMSTELNET" as a regular user.

However you can use outbound TCP connections to connect two instances of BPQ with each other and to hide any other (radio) connection behind a local telnet connection. To this end consider the following configuration:

    ... ... ...


        ... ...
        ... ...
        ... ...

From an inbound connection on any other port (A) issue the command

    ATT 1 localhost 8011 dl4fn secret

This will attach the telnet server port (B) and issue an outbound connection to the FBBPORT of the very same BPQ telnet server port. Now there is a new inbound local telnet server connection at (C) using the callsign DL4FN-15. Note that you need DisconnectOnClose=1 to close this chained connection when exiting the switch or an application.

    inbound +--------+   | switch    |
    radio   | radio  |(A)|           |
    -->-----| port   |->-|-c->-+     |
    connect |        |   |     |     |
            +--------+   |     |     |
                         |     |     |
                         |     |     |
            +--------+(B)|     |     |
        +-<-| telnet |-<-|-c-<-+     |
        |   | port   |   |           |
        +->-|        |->-|-c->       |
        (C) +--------+   |           |

This mechanism can also be used to easily acquire sysop privileges by additionally specifying the SYSOP flag in the user definition.

The scanner

Scanning is mainly used for HF radios to provide access on multiple frequencies and to support multiple applications (see above) whereas on VHF/ UHF usually radios with fixed frequencies are used.

In order to support multiple digital modes on a radio it may be necessary to connect it with several devices because teletype controllers typically support a single (type of) mode only e.g. Pactor, Winmor, or Fldigi modes. An inbound connection on one of the devices needs to stop the scanner for the radio it is connected to. Therefore all devices connected to a single radio are organized in a so-called INTERLOCK group.

The scanner is officially known as the "Rig Control Driver" in BPQ and the software supports multiple radios each of which may have multiple teletype controllers connected to. However most stations are using a single radio with a single (Pactor) controller. Among radio amateurs only contesters and DXpeditioners manage to run multiple HF radios in parallel ;-).

In order to use the scanning functionality your radio needs a computer interface (CAT) which most modern transceivers have.

There is one instance of the Rig Control Driver per radio. The following (slightly simplified) schematic shows a setup with two radios each having an SCS PTC controller and a soundcard modem connected to.

    +------------------------------+  +------------------------------+
    | radio 1                      |  | radio 2                      |
    +------+-------+--------+------+  +------+-------+--------+------+
           |audio  |CAT     |audio           |audio  |CAT     |audio
           |PTT    |        |PTT             |PTT    |        |PTT
    +------+------+| +------+------+  +------+------+| +------+------+
    | SCS PTC     || | Winmor      |  | SCS PTC     || | ARDOP       |
    | Pactor      || | soundcard   |  | Pactor      || | soundcard   |
    +------+------+| +------+------+  +------+------+| +------+------+
           |       |        |                |       |        |
           |       |        |    hardware    |       |        |
    - - - -|- - - -|- - - - | - - - - - - - -|- - - -|- - - - | - - -
           |       |        |    software    |       |        |
           |       |        |                |       |        |
    +------+------+| +------+------+  +------+------+| +------+------+
    | BPQ SCS     || | BPQ Winmor  |  | BPQ SCS     || | BPQ ARDOP   |
    | port        || | port        |  | port        || | port        |
    +-------------+| +-------------+  +-------------+| +-------------+
    |PORT         || |PORT         |  |PORT         || |PORT         |
    | ID=PTC1     || | ID=Winmor   |  | ID=PTC2     || | ID=ARDOP    |
    | PORTNUM=11  || | PORTNUM=12  |  | PORTNUM=21  || | PORTNUM=22  |
    |             || |             |  |             || |             |
    |             || |             |  |             || |             |
    | CONFIG      || | CONFIG      |  | CONFIG      || | CONFIG      |
    |  RIGCONTROL--+ |  ... ...    |  |  RIGCONTROL--+ |  ... ...    |
    |  ... ...    |  |  ... ...    |  |  ... ...    |  |  ... ...    |
    |ENDPORT      |  |ENDPORT      |  |ENDPORT      |  |ENDPORT      |
    +-------------+  +-------------+  +-------------+  +-------------+
           |                |                |                |
    |      c                c                c                c      |
    | BPQ switch                                                     |

Each device (Pactor controller, Winmor virtual TNC, ARDOP virtual TNC) is controlled by a corresponding BPQ port. All ports connected to one radio each share the same INTERLOCK number in their port configuration and one of the ports each contains the scanner config with the RIGCONTROL keyword.

If for example an inbound connection is detected on the Winmor port (PORTNUM=12) the scanner for INTERLOCK group 1 (INTERLOCK=1) i.e. for radio 1 is stopped on the current frequency and when the connection is finished the scanner resumes it's work again.

Frequency and mode of the radios are displayed as part of the Pactor port status window in the BPQ console.

If your radio has a facility to lock the main tuning knob, use it to prevent accidental unwanted frequency changes during scanning.

Scanner configuration skeleton

The scanner configuration for a radio is part of the CONFIG section of exactly one port in the INTERLOCK group of the radio and consists of several parts:

        ... ...
        ... ...
            ... ...
            | RIGCONTROL              |
            | radio definition line   |
            | block of scanning lines |
            | starting time           |
            | block of scanning lines |
            ... ... ...
            ... ... ...
            | ****                    |
            ... ...

The boxes in the above sketch are only to illustrate the different parts of the scanner configuration.

The INTERLOCK config statement is not needed if there is only one BPQ port connected to your radio.

The keyword RIGCONTROL on a single line starts the scanner configuration for a radio and it is terminated by the token **** on a single line.

The next line just below RIGCONTROL is the radio definition line which contains all parameters for BPQ to control the radio. This depends on the radio of course and may read e.g. "COM1 9600 ICOM IC7100 0C" for an Icom IC-7100. See below for more details. There is also an option to specify a password to remotely control the radio by an application, typically a BPQ BBS. This is described in the chapter on the BBS.

Scanning is organized by time periods and there is a block of scanning lines for each period. These scanning lines basically contain the frequencies to be scanned. The first block always starts at 0000 UTC which is implied by BPQ and if you scan the same set of frequencies until 24000 UTC there is no need for another block.

There is an additional block of scanning lines for every UTC time with a change in the set of frequencies to be scanned and the starting time is at the top of the block.

    | RIGCONTROL                             |
    | radio definition line                  |
    | these lines contain the frequencies    |
    | to be scanned from 0000 UTC on         |
    | 01:00                                  |
    | here are the lines for the frequencies |
    | to be scanned from 0100 UTC on         |
    | 02:00                                  |
    | here are the lines for the frequencies |
    | to be scanned from 0200 UTC on         |
    ... ... ...
    ... ... ...
    | ****                                   |

You can have as many blocks as you like and can choose any values for the starting times. However, the blocks have to be in chronological order.

Controlling Icom radios

Icom radios use the CI-V (which stands for "computer interface version 5) protocol for remote control. The physical connection between the radio and the computer is either through a serial cable connected to a so-called CI-V level converter or through USB. In any case there is a (virtual) serial port on your computer used to control your radio.

Refer to your radio's manual on how to configure your radio for use with CI-V. For the newer Icom models you have to enter the so-called SET mode to perform these settings. Typical configuration parameters on your radio are:

CI-V baud rate

the serial line speed used for CI-V communications. 9600 baud works fine in most situations.

CI-V address

the logical address of your radio. Keep the default value for your radio and note it down.

CI-V transceive

propagates changes to the radio to connected equipment. Set this to "OFF" unless you are using two separate radios for transmit and receive.

On the (virtual) serial port for your radio perform the following settings:

  • speed: choose the same value as the CI-V baud rate
  • data bits: 8
  • parity: none
  • stop bits: 1
  • flow control: off

For the scanner use the configuration:

    COM<port nr> <port speed> ICOM <model> <CI-V address>

Unfortunately there is no list of supported radio models on the BPQ website. IC7100 works fine with many modern Icom radios. When in doubt ask someone more experienced e.g. on the BPQ Yahoo group.

If you have trouble getting your radio controlled add the word "DEBUG" at the beginning of the radio definition line (just before the COM port definition). The debug messages will be sent to the Windows debug log and can be displayed with the MS DebugView tool (see above).

A typical configuration is

    COM1 9600 ICOM IC7410 0C

for an IC-7410 (note that there is no dash in the radio model name used in the radio definition line) which is connected to serial port COM 1 with 9600 baud and uses the CI-V address 0C (displayed by the radio as 0Ch).

Controlling Kenwood radios

I have never owned a Kenwood so others should add this

Controlling Yaesu radios

I have never owned a Yaesu so others should add this

The scanning lines

The format of the scanning lines is

    <dwell time>,<frequency>,<mode>,<filter>,<options>

The dwell time is the time in seconds (resolution 0.1s) how long the radio will stay on frequency and BPQ will wait for an incoming call. Typical dwell times range from 3 to 6 seconds.

The frequency is the dial frequency of the radio in MHz, e.g. 14.0964. Since multiple BPQ ports may share a radio and have their own centre frequency offset specifying the dial frequency is the simplest way to go. Many Pactor controllers have an audio centre frequency of 1500 Hz. When you use USB you have thus to substract 1.5 kHz from the desired radio centre transmit frequency.

Mode is the operating mode of the radio. Valid values include USB, LSB, FSK-R. USB is mostly used.

There is variety of options available and multiple options are separated by commas.


antenna switching via DTR and RTS signals on the rig COM port. Those may be difficult to access. If you need antenna control consider using a so-called band decoder which is common in the contesting community.


(Icom only, IC-746 and later) set data mode (e.g. USB-D). This sets (digital) IF filters in the receiver which are optimized for use with digital modes. Use this option if it is supported by your radio.


(Icom only) IF filter setting. Use a 500 Hz bandwidth filter for frequencies with Pactor 1 and 2 and a 2400 Hz bandwidth filter for frequencies with Pactor 3 and 4.

H1 H2 (SCS Tracker only) HF packet radio with 300 Bd (H1) or 1200 Bd (H2)
R1 R2

Robust packet radio (RPR) with either 300 Bd (R1) or 600 Bd (R2)


Capital letter P followed by a sequence of digits in the range 0...4 specify Pactor protocol levels to be used on this frequency. P0 disables Pactor. P234 allows for Pactor 2, Pactor 3, and Pactor 4 connects. Disable Pactor on those frequencies which you would like to use for Winmor exclusively.

W0 W1 W2

W0 disables Winmor connects on this frequency, W1 is Winmor with 500 Hz, and W2 Winmor with 1600 Hz.

APPL=... the name of the application to invoke on this frequency

When using the APPL option you can either use the PORTCALL for all applications or you can alternatively have the application callsigns set on the Pactor port by specifying the USEAPPLCALLSFORPACTOR keyword on a single line directly after the scanner config. See the section on the switch for more details and background.

The application feature can even be used without radio control, e.g.


DUMMY replaces the radio definition and the scanner changes the callsign every 6 seconds between the RMS and the BBS application callsign while the radio stays on the fixed (dialed) frequency.

Here is a complete sample configuration for the scanner:

    ; dial frequencies
    ; Pactor: dialFreq = centerFreq - 1.5 kHz
    COM1 9600 ICOM IC7410 0C

For the time periods where the radio stays on a single frequency a long dwell time (200 seconds) has been chosen.

The scanning life cycle and manual control

TODO: do you need SYSOP rights to control a radio from remote? AUTH code description to be added.

When you start BPQ the scanner(s) will also start working. Scanning is interrupted by one of the following events:

  • an incoming call is detected on one of the interlocked ports
  • one of the interlocked ports is ATTACHed

The radio will then stay on the last scanned frequency.

When all interlocked ports report to be disconnected and are not attached (anymore) scanning will be resumed after a grace period of 20 seconds. This allows a user to reconnect on the same frequency after an aborted connection.

Radios can be manually controlled with the RADIO command. Scanning can be stopped and started with the commands

    RADIO p SCANSTART [delay]

respectively where "p" is the port number and "delay" is an optional delay in seconds before scanning starts.

Besides the scanner the RADIO command is also used to set the frequency and mode on the radio. As with the scanner it is the dial frequency which is set on the radio so you have to compensate for audio offsets yourself (see above).

There are two ways to set the radio frequency. The first one is:

    RADIO p <frequency> <mode> <filter> <options>

where p is the port number and the parameters as in the scanning lines. This is useful only when scanning is stopped anyway. Otherwise scanning will start again after a few seconds and will change the radio frequency again.

The second form is to attach the port first:

    ATTACH p
    RADIO <frequency> <mode> <filter> <options>

Note that you have seen a similar pattern with the telnet server port.

This version has the advantage that you have control over the radio (and the port) as long as you are connected. Furthermore you can use this to initiate an outbound connection from a single-connection port, e.g.

    ATTACH 2
    RADIO 7.0500 USB 2 D
    C %DA5UDI

This attaches port 2, sets the radio frequency to 7050 kHz in USB with filter 2 and data mode, and initiates an outbound robust (pactor) call to DA5UDI.

When you have changed the scanner configuration go to the BPQ console and select the BPQ32.dll sub-window (the one which shows the initialisation messages). From the Actions menu choose "Re-read Rigcontrol Config" to activate your new scanner settings.

The SCS Pactor port

Pactor is a class of digital modes developed for robust HF communications which evolved from both Packet Radio and SITOR (known as AMTOR by radio amateurs) in the early 1980s. This was mainly driven by Hans-Peter Helfert (DL6MAA) and Ulrich Strate (DF4KV) who later founded the company "Special Communication Systems" (SCS) to further develop both the Pactor protocol family and dedicated controllers for these modes.

Although Pactor offers both FEC and ARQ modes it is today mainly used for peer-to-peer ARQ links and currently consists of the four modes Pactor 1 (PT1) to Pactor 4 (PT4).

The BPQ SCSPactor driver supports both the operation of Pactor and packet radio with SCS controllers.

Before you start

This section is not specific to BPQ and gives some hints on how to configure the serial port for your SCS controller and perform some basic settings.

There are several ways an SCS controller can be physically connected to your computer. Older models used serial lines whereas newer models offer USB, ethernet, and Bluetooth connections. For some devices you need to install a driver on your PC. Please refer to the manual of your controller for details. In any case the connection of your controller terminates with a (virtual) COM port on the computer.

BPQ operates the controller in so-called hostmode and SCS recommends a minimum port speed of 19200 baud for this. I use 38400 baud which works fine. On the COM port set the desired port speed as well as the following parameters:

  • 8 data bits
  • no parity
  • 1 stop bit
  • flow control off

Now have a look at the advanced settings of your COM port.

  • If your serial port driver offers settings for I/O buffers (send and receive; using or emulating a 16550(A) chip) set the buffer size to 8

bytes each.

  • If there is a choice for the USB transfer size choose the lowest available value (typically 64 bytes) both for receive and transmit.
  • In case your driver offers a latency setting choose the lowest available value (typically 1 ms) both for sending and receiving data.
  • Disable any of the "serial enumerator" and "serial printer" options if your serial port driver has them.

Use a simple terminal for the basic controller configuration and your first steps. Personally I prefer the TeraTerm terminal software suite but all terminal software works more or less the same.

Configure your terminal to use the (virtual) COM port connected to your controller with the same port settings (speed, data bits etc.). After connecting to the controller you should see the basic cmd: prompt. Whenever I connect to a controller I always issue the "DD" command first. It terminates all ongoing connections, clears the receive and transmit buffers, and safely puts the controller in standby mode.

You may need to adjust the terminal program settings so that the controller messages are nicely printed on your terminal screen. Use the controller "help" command to this end which produces a lengthy multi-line output.

For a PTC-II I recommend to set the controller to a fixed baud rate with the SERBAUD command. Have a look at your manual on how to do this. Use the same speed that you already configured on the serial port (e.g. 38400 baud).

Now carefully adjust the FSKA and PSKA audio transmit levels for the prescribed ALC meter reading of your transmitter. Turn of any audio compression on your transmitter first. Refer to your controller manual on how to correctly set both parameters. Note the values of FSKA and PSKA as we will need them later for the BPQ port configuration.

Do not be fooled by an ostensibly low reading of your power meter when operating Pactor 3 or 4. Instead check that the ALC meter shows the prescribed reading.


Although SCS controllers are mainly used for Pactor some models also have one or more builtin packet radio boards. This section describes how to configure BPQ for Pactor operation. For details on packet radio see one of the following sections.

Here is a skeleton for the BPQ SCSPactor port configuration:

      ID=id text



        APPL BBS

        | scanner config (if any)      |
        | Pactor config                |
        | Packet radio config (if any) |
        | BPQ controller specific      |

Replace the "id text" with a description of the port and "p" with the real port number (see above).

  • COMPORT is the number of your serial port, e.g. 1 if you are using COM1.
  • SPEED is the COM port speed in baud e.g. 38400
  • For the INTERLOCK line see the section on the scanner. You do not need this if you use this radio for Pactor exclusively.
  • Below the keyword CONFIG first configure the application to use on this BPQ port if any.
  • The scanner configuration follows if needed. See the section on the scanner for details.
  • The next block consists of configuration statements for operating Pactor with your controller.
  • A similar block for operating packet radio with your controller may follow.
  • Finally there are settings which are interpreted by BPQ itself (and not send directly to the controller).

BPQ initializes the controller on startup and when it recovers from lost serial line communications which should happen very rarely. Initialization happens in three phases:

  1. In the first phase BPQ sets some default parameters on the controller.
  2. In the second phase the configuration supplied by the user is applied.
  3. In the third phase BPQ sets parameters which are essential for BPQ to work correctly.

The following parameters are set on the controller in the first phase:

    TONES 4         audio centre frequency 1500 Hz
    MAXERR 30       abort connection after 30 successive errors
    MODE 0          disable controller data compression
    MAXSUM 20       20 data packets for memory ARQ
    CWID 0 2        CWID disabled

These parameters may be overriden by the user in the second phase.

In the user supplied configuration (contained in the box entitled "Pactor config" in the above listing) you should set at least the values for FSKA and PSKA. Here is a typical configuration:


    MODE 2
    CWID 4 0
    TONES 4
    FSKA 390
    PSKA 390
    APOW 0
    TXD 5
    MAXUP 3
    MAXERR 60
    BR 1

Strictly speaking this is not a controller configuration command. When set to 1 BPQ logs all communications with the controller in a separate log file SCSLog_[date] in the BPQ32 main directory. Make the DEBUGLOG directive part of your configuration so that you have it at hand when you need it.


The DD command terminates all ongoing connections, clears all transmit and receive buffers, and safely puts the controller in standby mode. This is always a good idea when configuring a device.


This enables full level 2 data compression (Huffman, pseudo Markov, and run length coding) for the controller.


CW identification of the controller. If enabled the controller sends it's MYCALL about every 7 minutes when being connected. The regulations for amateur radio in your country may be relevant in this context.


The audio tones are already part of the phase 1 configuration. It is however a good idea to make the value explicit.


These values determine the transmit audio levels and are very important. See above for details.


This disables automatic transmitter power adjustment used for PT2.


This is the transmit delay in steps of 5 msec. The default value is 4 and greater values will decrease the coverage of your station (electromagnetic waves travel about 1,500 km within 5 msec in free space).


These parameters determine how transfer speed is changed according to errors occuring during the transmission.


When being connected this is the maximum number of consecutive errors before the connection is aborted. For a connect this is the number of connect tries. The default value is 70. BPQ sets this to 30 which from my perspective is far too low. It means in particular that the maximum duration of a connect attempt is 30*1.25 s = 37.5 s which may be less than the total dwell time of many stations.

BR The brightness of the display (saves power and the LEDs).

For some features BPQ has it's own configuration statements. This is what the block entitled "BPQ specific" in the above configuration skeleton refers to. This includes:


When the controller reports the frequency to be free BPQ waits for n seconds for a possible change. The default value is 3 seconds.


When the controller reports the frequency to be busy BPQ waits for n seconds for the frequency to become free. The default is 10 seconds. If the frequency becomes free in the meantime an outbound call may be initiated otherwise the connect attempt is considered to be failed.


The maximum Pactor protocol level. MAXLEVEL=3 allows for operation of PT1, PT2, and PT3. The default value is 3. The regulations for amateur radio in your country may be relevant for this.

DATE Sets the current date from the computer clock on the controller.
TIME Sets the current time from the computer clock on the controller.
WL2KREPORT This ist to report to the Winlink 2000 database.

Finally BPQ sets the following parameters in phase 3 to ensure correct operation:

    ARX 0           Amtor phasing disabled
    BC              FEC reception disabled
    LISTEN 0        Pactor listen mode disabled
    ADDLF 0         auto linefeeds disabled
    LFIGNORE 0      no insertion of linefeeds
    BELL            bell off
    CHOBELL 0       changeover bell off
    BKCHR 2         breakin character x02
    CMSG 0          connect message off
    MAIL 0          mailbox reporting off
    REMOTE 0        remote control disabled

The callsign (MYCALL) is also set by BPQ depending on various parameters which are described in the section on callsigns in the chapter on the switch.

Here is a complete sample configuration for the SCS Pactor port:




        APPL BBS

        ; dial frequencies
        ; Pactor: dialFreq = centerFreq - 1.5 kHz
        COM1 9600 ICOM IC7100 0C

        ; Pactor controller config
        DEBUGLOG 0
        MODE 2
        CWID 4 0
        TONES 4
        FSKA 390
        PSKA 390
        APOW 0
        TXD 5
        MAXDOWN 6
        MAXUP 3
        MAXERR 60
        BR 1

(VHF) Packet Radio

Besides Pactor operation some SCS controllers have additional boards to connect with a VHF/ UHF radio for packet radio operation. Both HF Pactor and VHF packet radio can be operated simultaneously sharing the same serial line connection with the computer. This section is NOT about HF (robust) packet radio operation which is configured with the scanner.

Two callsigns are supported for packet radio: MYCALL which is set to the same value as on the Pactor side and MYALIAS which you can set yourself. Choose an application callsign or the NODECALL if you would like to offer access to an application or the node besides the application already defined by the Pactor configuration.

TODO: how does this work in conjunction with USEAPPLCALLSFORPACTOR?

Have a look at the SCS Pactor port configuration skeleton in the previous section on where to put the configuration statements for packet radio. All statements start with PAC. Here is typical configuration:

    PAC MCON 0
    PAC MONI 0
    PAC BAUD 1:1200
    PAC TXL  1:A 300
    PAC TXD  1:70

This BPQ keyword says how many channels i.e. inbound connections are supported. Set this to the number of concurrent users you would like to support on this port. 5 is a reasonable value.

PAC DIGIPEAT OFF Digipeating is disabled on the controller.

This sets an alternative callsign a user may connect to. In the particular case MYALIAS is the same as NODECALL to offer node access (besides BBS access inherinted from the Pactor MYCALL).

PAC MCON 0 Disable monitoring while being connected.

Disable packet radio monitoring. At the time of this writing there is a bug in BPQ which results in stations heard on the packet radio part being reported in the MHEARD list with HF frequencies.

PAC BAUD 1:1200

This sets the speed for the first packet radio board (1:) to 1200 baud.

PAC TXL 1:A 300 Sets the audio transmit level.
PAC TXD 1:70 This is to set the TX delay for the first packet radio board.

In phase 3 the following additional parameters are set on the port:

    PAC CBELL 0     switch off the connect bell
    PAC CMSG 0      switch off the connect text
    PAC PRBOX 0     switch off the builtin mailbox

HF robust packet

TODO: does USEAPPLCALLS work with HF robust packet and scanner config for HF packet radio?

TODO: SCANFORROBUSTPACKET is a BPQ config keyword for the SCS Pactor port.

TODO: BPQ config keywords DEFAULT ROBUST and FORCE ROBUST for the SCS Pator port.

TODO: robust packet radio, bandwidth 500 Hz, speed level is for unproto packets only; speed will be negotiated in a connection

TODO: outbound connects wich command "RC CALLSIGN"

TODO: Dragon has a single packet radio instance which can either be used on the Main or the AUX port; if you configure for HF RPR on the Main port you cannot have VHF Packet Radio on the AUX port

Tame dragons

SCS introduced Pactor 4 together with a new series of controllers called "Dragons". Currently two models the DR-7800 and the smaller DR-7400 are available. These new devices come with the newest DSP technology but they do not support RTTY, AMTOR, and PSK31 anymore as the older PTC models did.

Because of the popularity of the PTC-II models a lot of software has been written for these controllers. For compatibility reasons a Dragon therefore acts like a PTC-II by default. This can be changed with the PTCC command. There are two points you should be aware of when running in PTC-II compatibility mode:

  • you cannot benefit from the additional commands of the Dragon models
  • physical Pactor 4 connections are reported to the user software as being Pactor 3 because PTC-II models did not know about Pactor 4.

Furthermore the PTC-II command set as described in the manual for the version 4 firmware also applies to the Dragon models. For additional features of the newer controller models please refer to the release notes of the controller firmware updates.

The BPQ configuration keyword "DRAGON" marks an SCS controller as being a Dragon and BPQ uses this to free the Dragon from the default PTC-II compatibility mode. In the BPQ port configuration all the new commands of your controller may be used, e.g.:

      ... ...
      ... ...

        ... ...
        ... ...
        CB 2
        DISP MODE 1
        DISP CON 1
        DISP DIMMOFF 1
        ADEC ALL 0

Note the keyword "DRAGON" in the last line. In the above example the display and the auto-decoder of a DR-7800 are configured. See your manual for a detailed description of the parameters.

When operating PT2 with 500 Hz bandwidth you will notice that the channel busy detector of a Dragon will always show the channel to be busy even when it is apparently not. This can be solved by setting the channel busy detector to "Pactor only" mode (CB 2) as shown above.

Port usage

The Pactor part of an SCSPactor port is of the single-connection type which means that you have to attach the port before usage whereas the packet radio part is of the multi-connection type.

After attaching the Pactor port the following commands may be used on the port:


Sets the maximum Pactor protocol level for an outbound call. This may be necessary depending on the band plan or licence conditions.


Displays the highest possible Pactor protocol level. Avoid using this command and set the Pactor protocol level you need with MYLEVEL instead.


This overrides the channel busy detector and allows for outbound calls on busy frequencies. This is rude - use with care.


Activates the Pactor protocol for an outbound call. This is not necessary if you are only using Pactor on the HF part of the port anyway but see below.

RPACKET Activates (robust) packet radio on the HF part of the port.

Connects to callsign. Pactor also supports robust connects by prefixing the callsign with a percentage sign (e.g. C %KW1U) and long-path connects by prefixing the callsign with an exclamation mark (e.g. C !VK5EEE). Note that these options require at least PT2 (and that the controller will set MYLEVEL 2 if you need a connect option with PT1).


This disconnects the remote station immediately and puts the controller in standby mode. As this command does not have a return value it can not be used in BBS connect scripts. However, issueing a DD will not terminate your BPQ session as a normal link termination does.

After issuing a command the port responds with either "SCS} Ok" or just with "Ok". Here is a usage example which also shows the error message for busy channels.

    ATTACH 2
    DB0NTS-2} Ok
    C %G4KUJ
    Sorry, Can't Connect - Channel is busy
    *** Disconnected

Status information on the SCSPactor port is shown in the SCS Pactor Status window in the BPQ console. Please note that there is no information on the packet radio part of the port. Pactor speed levels in the status window start from 0 and not from 1 as e.g. in the display of the DR-7800.

Termination of a connection can be requested by a port user with the D (disconnect) command or by an application on the stream in use. Note that this is a normal disconnect.

The SCS Pactor window in the console shows packet statistics for an active Pactor link in the line named Traffic. RX is the number of bytes received, TX is the number of bytes transmitted, and ACKED is the number of bytes acknowledged by the remote side.

Packet Radio ports

A reduced primer on Packet Radio

This section covers general aspects of the BPQ32 packet radio configuration and details relating to particular devices are discussed in subsequent sections.

Research on radio communications based on the transmission of short self-contained bursts known as packets has been undertaken since the 1970s and radio amateurs started experimenting with this type of communications in the late 1970s employing microprocessor boards (the predecessor of Personal Computers). A first major step was the development of the Terminal Node Controller (TNC) by the Vancouver Amateur Digital Communications Group (VADCG). Software and hardware evolving around the work of the Vancouver group resulted in a variety of incompatible standards. Therefore, the Packet Radio standard was established in 1982 based on the ITU-T (CCITT at the time) protocol standard X.25 which is why Packet Radio is also known as AX.25. Packet radio became popular for the average amateur with the famous TNC board developed and marketed by the Tucson Amateur Packet Radio club (TAPR) in 1983.

Because of it's transmission characteristics Packet Radio is best suited for use on VHF/ UHF and the Robust Packet Radio (RPR) version was particularly designed for HF. However, the data packets defined by the Packet Radio standard can not only be transferred by radio but basically by any other transport medium e.g. computer networks (or carrier pigeons).

Packet radio is a mode for communications between computers. The device interfacing the computer with the radio is named Terminal Node Controller (TNC).

    +----------+    +----------+
    | computer |    | computer |
    +----------+    +----------+
    +----------+    +----------+
    | TNC      |    | TNC      |
    +----------+    +----------+
    +----------+    +----------+
    | radio    |    | radio    |
    +-----+----+    +----+-----+
          |              |
     station 1       station 2

The two stations involved are usually considered as equal peers instead of being in a master-slave relationship.

The packet radio protocol covers the transfer of data between the two endpoint TNCs of a connection (including intermediate hops) but it does not include higher-level functions like the routing of packets. These functions are provided by add-on software like FlexNet or NET/ROM.

The reason why we discuss packet radio quite detailed is that BPQ offers many implementations of AX.25 and that a basic understanding of the mode is necessary for configuration and troubleshooting.

In packet radio data is sent in small self-contained bursts (packets) called frames. Using bursts instead of a permanent transmission allows several radio stations to use the same channel for multiple parallel connections.

Packet radio connections use callsigns followed by a so-called SSID (secondary station id) both on the sender and receiver side. Callsigns are limited to 6 characters and SSIDs are numbers in the range 0-15. Note that today's callsigns may have more than 6 characters. Every frame contains both the sender's and receiver's callsigns together with their respective SSID which allows for multiple connections on the same (radio) channel including multiple stations being connected to a dedicated station. This comes in handy for BBS and similar applications.

Packet checksums are used to detect transfer errors on the receiving side. Packets carrying information are sequentially numbered by the sender and acknowledged by the receiver. Retransmission timers are used to get all packets through.

There are three basic types of frames:

  • I = information frames
  • S = supervisory frames
  • U = unnumbered frames

All frames are considered to be either commands or responses and come with an appropriate flag (C/R). Additionally, the P/F flag is used in all types of frames. In command mode (poll) it is used to request an immediate reply to a frame. The reply to this poll is indicated by setting the response (final) bit in the appropriate frame. Only one outstanding poll condition per direction is allowed at a time.

I frames carry information i.e. data to be carried on to higher layers. They come with a PID (Protocol ID) to identify which kind of layer 3 protocol (e.g. NET/ROM, TCP/IP, FlexNet), if any, is in use. Furthermore they come with the two numbers

  • N(S): the sender's send sequence number (the send sequence number of this frame)
  • N(R): the sender's receive sequence number (the sequence number of the next expected receive frame)

which are used to acknowledge the receipt of frames and to request the retransmission of missing ones (flow control).

U frames are responsible for maintaining additional control over the link beyond what is accomplished with S frames. This is done with commands which can both be issued and replied to with U frames. The so-called P/F (poll/ final) bit is used to this end where P (poll) requests an immediate reply to a frame. The reply is indicated by setting the response F (final) bit in the appropriate frame. Only one outstanding poll condition per direction is allowed at a time. The UI and UA frame types are U frames having the characteristics of an I and A frame, respectively. They are described in the following (incomplete) list of commands supported by U frames:

U frame Description
SABM(E) command (P)

places two TNCs in the asynchronous balanced mode in which both devices are treated as equals or peers. The next response frame is a UA or DM frame with the F bit set to 1.

DISC command (P)

terminates a link session between two stations. Prior to acting on the DISC frame, the receiving TNC confirms acceptance of the DISC by issuing a UA response frame at its earliest opportunity.

DM Response (F)

The disconnected mode response is sent whenever a TNC receives a frame other than a SABM(E) or UI frame while in a disconnected mode. The disconnected mode response also indicates that the TNC cannot accept a connection at the moment.

UA Response (F)

(Unnumbered Acknowledge) acknowledges the reception and acceptance of a SABM(E) or DISC command frame. A received command is not actually processed until the UA response frame is sent. Information fields are not permitted in a UA frame.

UI Frame (P and F)

Unnumbered Information frame contains PID and information fields and passes information along the link outside the normal information controls. This can be used to send information to multiple users e.g. to broadcast a digipeater callsign.

S frames provide supervisory link control such as acknowledging or requesting retransmission of I frames. To this end the S frame control field is used which may in particular contain:

S frame Description
Receive Ready (RR) (P and F)

Indicates that the sender is now able to receive more I frames and acknowledges properly received I frames up to, and including N(R)-1.

Receive Not Ready (RNR) (P and F)

Indicates to the sender of I frames that the receiving TNC is temporarily busy and cannot accept any more I frames. Frames up to N(R)-1 are acknowledged.

Reject (REJ) (P and F)

This requests retransmission of I frames starting with N(R). Any frames sent with a sequence number of N(R)-1 or less are acknowledged. Only one reject frame condition is allowed in each direction at a time and the reject condition is cleared by the proper reception of I frames up to the one that caused the reject condition. The status of the TNC at the other end is requested by sending a REJ command frame with the P bit set to one.

We will show an example in the following section because this may look a bit complicated at first glance.

The Monitor

The BPQ monitor allows you to monitor the packet radio frames sent and received on a particular port.

In the BPQ32 console select the Monitor sub-window and choose the desired frame types and port(s) to monitor from the Config menu. Packets received are shown in blue and those sent are shown in red. The monitor is also available in BPQTerm and its networked version BPQTermTCP where you choose the frame types and port(s) to monitor from the Monitor menu. Monitored packets are displayed in the upper window of the terminal. They can be logged to a file by selecting "log monitor" in the Setup menu. The log file is located in the working directory of the terminal and is named BPQTerm_#.log where the hash sign stands for a sequence number (0,1,2...).

Furthermore, the "LISTEN p" node command monitors packets of port p at any other packet radio port. Use "LIS" or "LISTEN OFF" to disable monitoring.

Here is how typical monitor lines look like

    08:45:13R PI1HGL>DB0NTS Port=4 <I C P S4 R2>:

with the order of fields being:

  • timestamp followed by either R or T for received and transmitted, respectively
  • FROM>TO callsigns
  • BPQ port number
  • frame data in angle brackets
    • type of frame (C=connect, D=disconnect, UA, I, RR)
    • C=command, R=response
    • flags: P=poll, F=final
    • S#: counter for TX packets
    • R#: counter for RX packets
  • any data transferred is printed on a new line

Here is a complete commented example of a packet radio link between DB0NTS and PI1HGL on BPQ port 4.

Monitor line Description
08:45:08T DB0NTS>PI1HGL Port=4 <C C P>
connect command sent from DB0NTS to PI1HGL
08:45:09R PI1HGL>DB0NTS Port=4 <UA R F>
UA frame to accept the connection, R=response, F=final
08:45:09R PI1HGL>DB0NTS Port=4 <I C S0 R0>:
(X)NET Digipeater/Networknode Den Haag The Netherlands
 >>>   WW-Convers: C PI8HGL-4 <<<
 >>>   HGL-BBS:    C PI8HGL   <<<

    <L>inks  <D>estinations
    <H>elp   <N>odes

I frame with data, send and receive counters are both 0
08:45:09R PI1HGL>DB0NTS Port=4 <RR C P R0>
PI1HGL now ready to receive data (RR), immediate reply requested (P)
08:45:09T DB0NTS>PI1HGL Port=4 <RR R F R1>
RR request acknowledge (R F), DB0NTS's receive counter now 1 (R1)
08:45:09R PI1HGL>DB0NTS Port=4 <RR C P R0>
repeat of the previous frame because the reply was lost
08:45:09T DB0NTS>PI1HGL Port=4 <RR R F R1>
acknowledgment repeated
08:45:10T DB0NTS>PI1HGL Port=4 <I C P S0 R1>:
c pi8hgl
I frame issuing a connect to PI8HGL
08:45:10R PI1HGL>DB0NTS Port=4 <RR R F R1>
I frame acknowledged and ready to receive more
08:45:10R PI1HGL>DB0NTS Port=4 <I C S1 R1>:

Interlink setup...
I frame
08:45:10R PI1HGL>DB0NTS Port=4 <I C S2 R1>:
*** connected to PI8HGL
next I frame, note that the send counter is now 2 (S2)
08:45:10R PI1HGL>DB0NTS Port=4 <I C S3 R1>:
Hallo Peter

more data received and send counter now 3 (S3)
08:45:11T DB0NTS>PI1HGL Port=4 <I C P S1 R4>:
I frame acknowledging received packets (R4)
08:45:11R PI1HGL>DB0NTS Port=4 <I C P S1 R1>:

Interlink setup...
repeat of a previous packet because the acknowledgment was missed or did not arrive in time
08:45:11R PI1HGL>DB0NTS Port=4 <RR R F R2>
packet nr 1 from DB0NTS received
08:45:11T DB0NTS>PI1HGL Port=4 <REJ R F R4>
received up to packet 3 ([FBB...), now send packet 4
08:45:11R PI1HGL>DB0NTS Port=4 <RR C P R2>
repeat of previous RR packet
08:45:11T DB0NTS>PI1HGL Port=4 <REJ R F R4>
repeat of previous REJ packet
08:45:12R PI1HGL>DB0NTS Port=4 <I C S4 R2>:
I frame
08:45:12R PI1HGL>DB0NTS Port=4 <I C S5 R2>:

*** reconnected to PI1HGL
this is now I frame 4 (as requested by the RR above)
08:45:13T DB0NTS>PI1HGL Port=4 <D C P>
08:45:13R PI1HGL>DB0NTS Port=4 <I C P S4 R2>:
repeat of previous I frame
08:45:13R PI1HGL>DB0NTS Port=4 <UA R F>
disconnect confirmed

As can be seen from the above example it may happen that packets are considered to be lost because of a missing acknowledgment or that an acknowledgment is expected earlier than received by the remote side. Timers are used in packet radio to control the flow of packets.

Configuration parameters

The flow of data between the two TNCs involved in a packet radio link is controlled through various timers which determine in particular when packets are to be re-transmitted and how long a TNC waits for subsequent packets to arrive. Instead of discussing the timers from the ÁX.25 specification we directly show how to configure them within BPQ.

A typical AX.25 port configuration looks like this:



        ... ... ...
        ... ... ...

MAXFRAME is the maximum number of frames which may be underway without being acknowledged yet by the remote side. Large MAXFRAME can be good if the error rate is very low, as only one TXDelay and ACK is needed for each block of packets. But with a normal AX.25 stack if a packet within a transmission is missed, all subsequent packets are discarded and have to be resent, so the benefit is very soon lost. This combined with the increased chance of dropping a packet with digipeating means that if you are digipeating MAXFRAME 1 or 2, is likely to be the best choice.

Parameter Description

(L2 timeout, also known as T1) is the time in milliseconds we wait for a packet to be acknowledged.


(L2 delayed ack timer, also known as T2) is the time in milliseconds we wait for another frame to arrive in order to acknowledge them together.


is the number of times a frame is resent until we give up and regard the link as failed.


is the maximum length of a frame in bytes. The maximum PACLEN is 256. Note that e.g. NET/ ROM adds a 20 bytes header to each frame which reduces PACLEN effectively to 236. Large PACLEN is an advantage so long as the error rate is such that the chances of any one packet being corrupted are small. As link quality deteriorates, smaller packets have a better chance of being received correctly.

AXIP ports

AXIP is the TCP/IP implementation of packet radio and is used to internally network multiple BPQs within one station, to link nodes over Hamnet (Net44), and the public internet. The BPQ AXIP driver supports native IP transport and encapsulation in both UDP and TCP. UDP transport is the option mostly used.

The BPQAXIP driver is used for AXIP and the typical port configuration layout is as shown in the previous section.

The most important configuration statement is MAP which associates a hostname or an IP address with a callsign (including an SSID). Hostnames are internally resolved into IP addresses by BPQ every 15 minutes but be aware of your operating system's DNS cache.

        MAP DB0FHN db0fhn.ampr.org B
        ... ... ...

The optional parameter B here means that certain packets defined by BROADCAST config statements (e.g. our nodes table with BROADCAST NODES) are broadcasted to this station. You can have up to eight BROADCAST statements. Omit both the B and the BROADCAST statements if you do not need broadcasts e.g. for dedicated BBS links.

Not specifying an SSID with the callsign implies all SSIDs of the callsign (DB0FHN, DB0FHN-1, DB0FHN-2, etc.). If an SSID is present the MAP entry is valid for this particular SSID only with SSID -0 meaning the base callsign. We will see an example later on.

IP protocol 93 is used by default if no other transport is specified as in the above example. To use UDP instead specify the keyword UDP and the destination port in the MAP line as in

        UDP 93
        MAP DB0FHN db0fhn.ampr.org UDP 9300

The line before the MAP statement specifies an UDP port for incoming datagrams. You can have multiple of them if you need multiple ports to listen on. 93 is the reserved port for AXIP. However, using port numbers below 1024 requires extended privileges on Unix operating systems (e.g. Linux) which is why many stations use port 10093 instead of 93. If the remote side needs a particular source port to be used, specify it with the SOURCEPORT keyword.

Although UDP is the most popular transport there are rare cases where it cannot be used because of infrastructure issues (e.g. firewall settings) and you have to revert TCP. A pair of TCP-Slave and TCP-Master statements is needed for this as in

        MAP G8BPQ-1 example.net TCP-Master 10093
        MAP G8BPQ-5     TCP-Slave  10093

where the first line is for the outbound TCP connection to G8BPQ-1 to example.net:10093 and the second one is for listening on all local IP addresses ( and tcp/10093.

Besides using the MAP statement in the BPQ32.cfg file, entries can also be added on the fly with the BPQ32 console. To this end select the resolver window of the AXIP poort in the console and choose "add entry" from the Actions menu.

Usually only network packets are accepted from stations you have MAP statements for in your configuration which obstructs public access.

When networking two BPQs with AXIP keep in mind that the callsign used for an outbound connection is the application callsign or the node callsign as a fallback.

The AUTOADDMAP config statement is to automatically add the callsigns and IP addresses of stations from which you receive UDP packets and for which you do not have a MAP entry (yet).

Furthermore, the DONTCHECKSOURCECALL option allows packets to be received from stations for which you do not have a MAP entry. This should only be used in exceptional circumstances as normally you also want to be able to reply to received packets.

The AXR (for AX resolver) node command displays the list of stations with their IP addresses both from MAP entries and learned from AUTOADDMAP:

    AXR 4
    DB0NTS-2} AXIP Resolver info for Port 4
    DB0FHN     = db0fhn.ampr.org 9300 =
    PI1HGL     = pi8hgl.ampr.org 93 =
    KW1U       = 10093<93 = B A

The entries for DB0FHN and PI1HGL are from MAP statements showing the hostnames (and UDP ports) with their corresponding IP addresses.

The last entry for KW1U was learned from AUOADDMAPP and shows the IP address (, the UDP source port (10093), and the port the connect was made to (93). The B at the end is the broadcasting flag (see above) automatically set by AUTOADDMAP and the A indicates that the entry was made by AUTOADDMAP.

Connections on a port can be listed with the MH command already detailed above. For an AXIP port to have an MHEARD list requires the configuration keyword MHEARD in the CONFIG section, e.g.

    ; AXIP port - external internet/ hamnet
      ID=AXUDP external


        UDP 93


        MAP DB0FHN      db0fhn.ampr.org  UDP  9300
        MAP PI1HGL      pi8hgl.ampr.org  UDP  93

Besides creating an MH list for the port this also opens a window in the BPQ console. Additional information can be listed with the AXM (for AX MHEARD) command. AXM and MH have slightly different output:

    MHU 4
    DB0NTS-2} Heard List for Port 4
    DL4FN      Sep 18 19:12:46    via DB0FHN*
    PI1HGL     Sep 18 09:10:28
    DB0FHN     Sep 18 09:10:22
    KW1U       Sep 17 02:49:18

    AXM 4
    DB0NTS-2} AXIP Mheard for Port 4
    DL4FN   U 93     Tue Sep 18 19:12:45 2018
    PI1HGL     U 93     Tue Sep 18 09:10:28 2018
    DB0FHN   U 93     Tue Sep 18 09:10:22 2018
    KW1U     U 93     Mon Sep 17 02:49:18 2018

TNC emulation

TODO: there should be a short description of the TNC emulation port here which shows in particular how to integrate e.g. Winlink Classic or Airmail through a pseudo-TNC with BPQ. This is cool.

Related Links