You are here: Home PACTOR PACTOR Firmware Firmware Update Information 2.4
Always current
Worldwide SCS Dealer Network

More than eighty percent of our products are sold and used outside Germany. A dense worldwide dealer network is available to our customers.

Worldwide PACTOR Service Providers

Click to the graphic to choose your PACTOR Service Provider.


Firmware Update Information 2.4

v2_4_news.eng.txt — Plain Text, 29Kb

File contents

                      Update Info for version 2.4 firmware

The main new functions of ver. 2.4 are a Packet Radio to Pactor gateway, and
an automated "change-over" (Pactor duplex mode), coupled, completely trans-
parent, within the WA8DED hostmode.
An additional new feature incorporates a User List, allowing file access
(read), and PR->Pactor gateway priorities to be set, with further small
additions (and bug fixes) rounding off the new version.

PACTOR Duplex and Pactor data transparency
In order to simplify the use of PACTOR, and for compatibility with the many
existing PR mailbox and terminal programs, a way was sought in order to be
able to execute "change-overs", without the usual use of control sequences
(i.e. Ctrl-Y), as these PR programs do not need these sequences as commonly
used in HF, and behave in simplex mode as if in duplex, no change-over as
such existing.
Pactor Duplex is the PTC-II's answer to this, bypassing the change-over
sequence with an automatic change-over.

PDuplex command (0/1, default 0)
Pactor-Duplex is activated with the new command "PDuplex 1" (can be shortened
to "PD"), and then works to the following, relatively simple principles:

1. If the PTC-II is the data transmitter (ISS),i.e. "has the keys", it
   immediately does an automated change-over as soon as it's xmit buffer is
   empty. (no remaining data to send).

2. If the PTC-II is the data receiver (IRS), it will carry out an automatic
   "Break-in" (change-over) if it has data to be sent in it's xmit buffer,
    and has been in the IRS state for at least 12 seconds.

In practice the use of Pactor-Duplex needs to be carefully thought about,
especially in the case of when a PTC-II with activated duplex, and one without,
must work together.

It follows that, as of now, general everyday use of the Pactor duplex system
is not feasible, as the "old" style Pactor mailboxes can not handle it,
and even in normal QSO conditions, one should switch to duplex only with
the qso partner's agreement, who will otherwise likely be irritated by the
somewhat erratic behaviour of the change-overs!

In addition, the following further changes concern the PTC-II itself, when in
Pactor duplex mode:
1. The "change-over" bell is deactivated.
2. Open files for the on-board PTC mailbox are no longer closed through a
3. Access to the mailbox by a user with PDuplex works correctly (the command
   interpreter no longer being closed by a change-over as is normally usual,
   but only with a "carriage return").

Main applications of PACTOR-Duplex
1. PDuplex is particularly suitable for accessing PR mailboxes using the
   WA8DED Host mode protocol (i.e. DPBox, DieBox, GP, WinGT) in PACTOR, as
   the terminal or mailbox programs can no longer differentiate between a
   PACTOR and a PR link, as long as PDuplex is activated, and the PC program
   no longer has to send change-over characters.

   The particular advantage of this technology is that the PR program of a
   mailbox is available to ALL PACTOR users, regardless of whether they work
   with PDuplex or not, or if they are PACTOR-I or II users.

2. In connection with the full binary data transparency that exists in the
   WA8DED host mode as of version 2.4 in PACTOR, it is no longer necessary to
   have to convert binary files to 7PLUS or similar encoders, this now being
   done in AUTOBIN mode.
   If, for example, one wishes to send a file to a friend who also has a PTC-II,
   then both PTCs' would be switched to PDuplex, and, using a WA8DED compatible
   host mode program, all the usual PR "features", including the (normally 4)
   PACTOR channels, and including the AUTOBIN file transfer, are then
   unrestrictedly available!

3. A very comfortable working system, with partners who also activate PACTOR
   duplex, can be attained. In this instance, the qso follows the lines of a PR
   QSO, change-overs or break-ins no longer being necessary, and disregarding
   the actual xmit or receive status of each PTC-II.

   We would like to point out that the choice of method is still very much a
   matter of taste, and the more usual manually activated direction changes will
   still maintain a strong following, especially due to past habits!

Incompatabilities (and how to avoid them!)
PACTOR-Duplex opens the door to many, hitherto unknown, possibilities for
experimentation, especially as regarding PC software particularly designed for
PR radio, but the duplex simulation does cause some, unwanted, side effects,
in connection with the existing "old" PACTOR systems!

* In this connection, the general rule to follow when accessing a PACTOR   *
* mailbox is to DISABLE the PDuplex mode, unless one knows explicitly that *
* that particular box can cope with PDuplex.                               *

The internal PTC-II mailbox also reacts unfavourably (if the the PDuplex mode
is not activated) if, for example, whilst inputting a command a change-over is
initiated, the user being in PDuplex mode, but typing very slowly, and it would
therefore be extremely desirable if ALL available PACTOR mailbox programs could
be modified to be able to handle the PACTOR duplex mode/users!

PACTOR data transparency
Through the introduction of the PACTOR-Duplex structure, and the data trans-
parency content of the WA8DED Host mode, this tranparency could be usefully
employed (as already suggested by many users) in PACTOR applications.
As already explained above, this transparency allows the use of direct binary
transfer protocol through PR programs via PACTOR.

As of firmware version 2.4, the PTC-II transmits and receives the PACTOR data
fully binary transparent, including when WA8DED Hostmode is in use.

IMPORTANT to note: this transparency is only assured when both sides of a
PACTOR connection are equipped with firmware version 2.4 (or higher).

The data transparency  obviously includes all special "terminal mode"
characters, so that, in Host mode, the normal change-over and break-in
characters are meaningless (as are the keyboard macros in GP, for example!)
and must use the Host mode commands %0, or %1 instead!

The Packet to PACTOR gateway
The PTC-II, as the first TNC worldwide, offers, as of firmware version 2.4,
the possibility of a PR->PACTOR gateway. This means in effect that a PR
user in VHF/UHF can access a PACTOR HF station!
In order to use this unique feature sinfully, two conditions must be observed:
A) The TNC must be able to control the transceiver independently (i.e. without
the help of a PC), and B), the TNC must be independantly capable of ascertain-
ing whether an HF channel is busy or not, in order to avoid unnecessary
The PTC-II fulfills both these conditions admirably, having a TRX control port
on the one hand, and an excellent DSP algorithm to check the "channel busy"
status, on the other.
In order that the gateway handling be kept as simple and secure as possible,
the PTC-II uses QRG data, and other information, from the already existing TRX
frequency list as used for scanning, using an additional "Gate" parameter to
define whether a particular channel is available as a PR->PACTOR gateway.

There follows a typical TRX frequency list:-

Ch    Frequency (khz)    Scan     Gate       Comment
1:       3583.650        YES       NO        dl1zam channel 1
2:       3585.650        YES       NO        DL1ZAM channel 2
3:       3584.000        YES       YES       Test QRG DL1ZAM
4:      14079.000        NO        YES       DL2FAK CN2SM
5:      14076.540        NO        NO        EA5FIN's summer QRG
6:      14075.600        NO        YES       LA2MV
7:      14080.000        NO        YES       9K2EC special
8:       3587.000        YES       YES       SM3HUA QRG
9:       3595.400        NO        YES       DJ9YJ QRG
10:      3588.000        NO        YES       DK0MAV HB9AK
11:     14077.000        NO        YES       second ch dl2fak


This list can be made up, as usual, using the Channel command in the trx:-menu.

XGate command
The Xgate command, found in the trx:- menu, allows the XGate parameter to be
set for the individual channels, for example:-

      XG 5 1 sets the "Gate" parameter for channel 1 to YES.
      XG 10 0 sets the "Gate" parameter for channel 10 to NO.

The "Gate" parameter is defaulted to "NO" when a channel is newly defined using
the Channel command, so, for the PR->PACTOR gateway to be allowed on particular
channels, the XGate command must be used to enable each one individually.

New commands for PR use in the PR to PACTOR gateway
There are two new commands for the PR->PACTOR gateway, "TRX" and "Gate".
The "TRX" command has only been used to attain a certain standardization with
the PACTOR port, so inputting "TRX list" (or only "TRX") results, as in the
PACTOR port, with the TRX frequency list being screened.

Gate command
The Gate command is important when using the PR->PACTOR gateway, and has
different functions:

1. Given without an argument, the PTC-II shows, as per the TRX command above,
   the TRX frequency list.

2. Should a callsign be added as an argument, i.e. G DL2FAK <enter>, then the
   PTC-II attempts to create a PR->PACTOR gateway to DL2FAK, having found
   this callsign in the "Comment" column, whilst searching the TRX frequency
   list for channels with enabled gate parameters, starting at channel 1.
   The end of a callsign entry in the "Comment" column is marked with any non-
   alphanumerical special character, perhaps a space, comma, or similar, and
   the search engine compares the number of (alphanumerical) characters in the
   callsign of the Gate argument with the callsigns listed in the TRX frequency
   If, for example, "G DL2FA" has been entered, then the "test-length" is
   set to five characters, and although DL2FAK contains this call, it would not
   be accepted as valid, having the further alphanumeric character "K" at the
   end, and not, as mentioned above, a space, comma, etc.
   If, on the other hand, "DJ9YJ/M" was an entry in the Comment column, for
   example, then the search engine would find it with "G DJ9YJ", or even with
   "G DJ9YJ/P", as "/" is not an alphanumeric character.

   Going back to the example of "G DL2FAK", the PTC-II found this callsign
   initially in the Comment field of channel 4, with the frequency shown as
   14079 khz. The system now sends this frequency, as a remote command, through
   the TRX port to the transceiver, checking that this frequency is free for a
   five second time span, and, if so, then calls DL2FAK in Pactor, limited to a
   maximum calling period of one minute, in order to avoid unnecessary frequency

   A typical sequence, sent to the PR user and based on above, follows:-

   *** QRX - CHANNEL BUSY TEST ON: 14079.000 khz



   The connection can now be maintained as per PR radio, provided that the
   connected PACTOR station does an automated change-over after text trans-
   mission, which is normally the case in all mailbox systems, including the
   PTC-II's box. ("Remarks concerning change-over problems in the PR->PACTOR
   Gateway system" are noted further below).

   Now the connection can be broken either by the Gateway user disconnecting as
   per normal PR protocol, or the connected station is given a normal link-down
   instruction by the Gateway user in Pactor mode, i.e. the Q command, in which
   case the gateway user then returns to the PTC PR box command prompt, and can
   input further instructions, i.e. another Gateway command.

   A link built using the PR->PACTOR gateway is automatically terminated in
   the case of ten minutes of total inactivity.

   Should the HF port be occupied when giving the Gate command, a message is
   shown as follows:-

   *** BUSY fm HF-GATE


   Or if the system finds the called-for HF channel already occupied, it
   responds as follows:-

   *** QRX - CHANNEL BUSY TEST ON: 14079.000 khz


   In the above case, the system looks for the next channel where the requested
   callsign is to be found in the Comment column, and, as in the sample TRX
   (Channel) list, it finds callsign DK2FAK again in channel 11, and tries,
   provided the channel is free, to establish a link there.

   If the requested callsign can no longer be found, then the search is broken
   off, with no further attempt to establish a connection.

   As a reminder, when using the long-path option, the exclamation mark must be
   input with the requested call, and of course, also in the Comment column of
   the Channel list!

3. If, following the callsign, as a third argument a channel number is quoted,
   then the system no longer searches the Comment column, and would attempt to
   establish a link as per the precedure mentioned previously.
   As an example, the input of "G !DL6MAA 7", as per the sample TRX frequency
   (Channel) list, means that the system would attempt to establish a long-
   path link with DL6MAA on 14080 khz, always providing that the respective
   channel has been made available for Gateway access ("XG 7 1").

PR->RACTOR-Gateway connects appear in the internal log of the gateway providing
PTC-II marked with "G1:" or "G2:" dependent on the level of the PACTOR connect.

Remarks concerning change-over problems in the PR to PACTOR Gateway system
As already explained in the paragraph concerning PACTOR-Duplex, Packet Radio
(PR) does not require any particular change-over control sequences, i.e. no
CTRL-Y, for example, to change control direction.
There exists a principal conflict when a PR link is established with a PACTOR
link, in that the PR user cannot be expected to enter change-over control
sequences blindly for the PACTOR side of the link.
This means in practice that as long as the PACTOR link  sends a "Break-in"
before sending data, and on completion a further "Change-over" sequence, the
link can function perfectly, and if the PACTOR station is the caller of a
mailbox, then the PR->PACTOR gate works well.
If a PACTOR station is called, one that does not control the change-over
sequences automatically, then this station has to control the system steerage
manually, which is of course impossible if the station called is unmanned, and
not enabled as a mailbox.

As an alternative in this case, we suggest that the Gateway PTC-II be switched
to PACTOR duplex mode, this still not being entirely satisfactory, as certain
PACTOR mailboxes cannot work with the PACTOR duplex system (see further above).

It remains to be seen, through practical experience, how the system will be
accepted in it's present form.

(A worthy point of discussion, for example, would be a further Gate command
choice, allowing a "normal" PACTOR link to be establshed, or that the link
should run in PACTOR duplex mode. In this case it is necessary that the PR
user be very familiar with the HF PACTOR system, which hardly seems ideal to
us either).

The access to the PR->PACTOR gateway is ONLY ALLOWED to users who fulfill
the necessary HF licencing requirements, and the gateway user's callsign can
be seen, without any forewarning, on HF! (a commonly used callsign extension
of -X, i.e. DL2FAK-5, would very probably cause considerable upsets in most
established PACTOR maibox systems, anyway!), and therefore the following
access restriction possibilities are available forthwith, as explained below.

Note: The possibility of a transparent AX.25 or TCP/IP "protocoled" HF-Pactor
gateway is presently being thought about, but the legal position of such would
need further clarification.

User priorities and the new XUser command under the cmd:-menu:
The PTC-II firmware, as version 2.4, allows user access restrictions to be set.
This means in effect that in a "User List", for example, one can stipulate
whether the user of callsign DK9FAT may access the PR->PACTOR gateway, read
private messages intended for other mailbox users, etc, etc.
This User List may have up to 64 entries, the first entry always being allocated
to the callsign "ALL", and lists which priorities that users receive who are
NOT specifically noted in the User List.

A typical User List follows:-

User priorities /PR-BOX/PT-BOX/PR-GATE/
ALL......2220  DL1ZAM...9999   DL6MAA...3330  DL2FAK...3330  DL3FCJ...3330
DK9FAT...2230  DL1ZAM...2230

Every entry consists of the user's callsign, followed by a four figure numerical
group designating the individual access priorities. As of now, only the first
three figures are being decoded, the fourth being reserved for future expansion.

These first three figures allocate priorities for 1. access to the mailbox
through PR, 2. access to the mailbox through PACTOR, and 3. the use of the PR
to PACTOR gateway.

Version 2.4 does not allow an exact decoding of the priorities, but has been
simplified as follows :-

PR to BOX access: number less than 3.: only reading of own or general files.
                  3 or greater than 3: Read all files allowed.

PT to BOX access: as per PR to BOX, above.

PR gate access..: number less than 3.: access disallowed
                  3 or greater than 3: free access through the gate

A further exacting coding/decoding of the priorities may be expected in future

Looking further in the above sample list, we see that users not specifically
listed have no access to the PR to PACTOR gateway, as the setting for the call
"ALL" is 2. On the other hand user DK9FAT may use the gate, but is restricted
from reading private messages.

The command "XUser" allows control of this User List, and, depending on the
number of arguments, has different functions.

XU, with no argument:-
Shows the complete User List.

XU ----
Deletes the User List entries, and resets the "ALL" entry to it's
default setting (3330).

Shows the priorities set for that callsign.

Although call signs may normally be eight characters long, in practice they
should be limited to six, as Packet Radio protocol limits  them to six anyway,
meaning that callsigns such as F/DL6MAA/M are not allowed, and of little use,
causing problems with the PR protocol.
Therefore the PTC-II cuts all characters off that appear after these "special"
characters, automatically, making DL6MAA out of "DL6MAA-10", and the input of
an SSID in the call list is therefore obviously not possible.

XU CALLSIGN - (minus sign)
Deletes the entries for CALLSIGN from the list, needing a confirmation of "OK"
through the PTC-II. Note that the Callsign entry "CALL" is not deletable!

Sets the priorities for CALLSIGN through the entry xxxx, which can contain
values from 0 - 9, i.e. 1330.
There must be NO spaces between the individual figures, and, in the case where
there are less than a total of four, the PTC-II adds zeros for those missing,
and requires input confirmation of "OK".

The User List has no influence over keyboard input.

Further enhancements in the firmware:

Cross-Port-Digipeating using the MYALIAS-Callsign

If the PTC-II is accessed with its MYALIAS-callsign for digipeating, it acts as
a cross-port digipeater. That means that packets received at port 1 are trans-
mitted at port 2 and vice versa. This feature is independent from the kind of
the modems installed, so that cross-digipeating from 1200 bd to 9600 bd is

The default setting of the MYALIAS callsign is still the first entered PACTOR
callsign, but now the SSID 15 is added. If for example the global MYCALL in
PACTOR is set to DL6MAA, the PTC-II automaticly sets the MYALIAS to DL6MAA-15.
Certainly the MYALIAS call can be changed any time with the MYAlias command in
the pac:- menue.

Extention of the TRX-Frequency-List

The TRX frequency list has been extended from 16 possible entries to 32.

Connect-Command in PR more flexible

The connect procedure of PACKET-Radio now allowes (but not needs) the use of
"VIA" or "V" between the digipeater- and destination-callsigns.

AGC in the DSP improved in PACTOR STANDBY.
As of version 2.4, the dynamic range of the PTC-II in PACTOR STBY has been
increased by 20 dB, meaning that transceivers with a very low LF output
(especially under quiet conditions) can still deliver sufficient signal
strength to the PTC-II.

Auto-Power command modified.
The value range of the AP command has been increased from 0 -1 to 0 - 200.
Auto-Power is activated as soon as the argument given is greater than zero, but
in no instance is the power lowered beyond that of the PSK Amplitude value, set
by the AP argument.
This means that the AP value equals the "minimum PSK amplitude" (but, as before,
the PTC-II reduces the maximum amplitude only down to 1/64th, regardless of
whether a very low AP value would allow a further decrease or not).

Example:- say AP is set to 200, then the PTC-II never lowers the PSK output
signal to below 200 mV, i.e. that when a value of, say 140, is set for the PSK
maximum output level (under the PSKA command per the manual), and an AP value of
200 is set, then the output power would never be reduced.
But were the PSKA value to be 140, and an argument of 70 be given for AP, then
a maximum reduction of 50% is then possible (maximum power reduction is 25%,
regardless of values).
This means that adjustment of the minimum amplitude can limit the range that
Auto-Power covers, this being useful, and necessary, in certain situations,
such as that some transceivers only run as designed within a certain power
range, and one can also considerably increase the average throughput on strongly
fluctuating channels.

Transceiver control for the Rhode & Schwarz XK 2000 series.
The TYpe command has been enlarged, as of version 2.4, to include "TYpe R&S",
"TY R" being sufficient. this also allows input of the baud rate, and is then
limited to a maximum of two arguments, i.e. TY R 2400 <enter>.
The port parameters are set to E71 with R&S systems, and data coming from the
radio is not "translated", but sent as such directly to the terminal.
This means that, using the "F" command without further argument, results in the
raw original frequency string being shown, as apposed to the usual offset
adjusted (dial) frequency!

CWTerm command, with optional argument.
From version 2.4 onwards, the CWTerm command allows an (optional) argument, in
that the start/beginning decoding speed may be given, so that in the case of an
existing argument the decoder starts in so-called fixed speed mode, the auto
speed adjustment being inoperative.
This allows, for example, the optimum decoding of commercial CW transmissions
(weather bulletins, for example), whose transmission speed is previously known.

Gate command in cmd:-menu extended (PACTOR->PR Gateway).
The Gate command arguments may now be up to thirty characters long, so that, in
the case of a PACTOR->PR gateway, the whole path through digipeaters to the
target callsign can now be entered.
As an example, one can enter "DL1ZAM-8 DB0KT DB0GV-7" as a target call, so
that stations not normally within reach become "connectable" (the maximum
length of three complete calls is sufficient for modern autorouters, i.e. the
Flexnet router, for example).

XScan as new command in trx:-menu.
In order to standardize the command syntax, the PTC-II now includes the XScan
command in the trx:-menu, which is identical to the XGate command (for changes
made to the Gate parameter, see further above), and allows changes to be made
to the scan parameter in the TRX frequency list.
As an alternative to the previous scan instruction possibility of two arguments
(i.e. S C 1), that toggled (switched) the scan function on or off, the XScan
command allows particular channel scan definition, as an example:-

"XS 10 0" sets the scan parameter for channel 10 to NO
"XS 4 1"  sets the scan parameter for channel 4 to YES

The command XScan is particularly useful in the initialization/configuration
(Startup) file of the PTC-II, it now no longer being necessary to know the
previous scan state(s) of the individual channels, these now being able to be
defined as desired in the above file.

MYLevel command expanded.
The MYLevel command now has a second line which shows the link level status of
the actual or last link, this being, for example, useful, when testing the link
status of the link in a PACTOR connection, actual or previous.

Trace mode for Packet Radio.
As of version 2.4, a trace mode is available at the terminal level in the pac:
subdirectory for PR, this meaning, that with the command "TRACE on" or "TRACE
off", a special Frame report can be activated (or deactivated).
The PTC-II screens the Trace mode data in three columns, as a Hex dump, as
straight ASCII, and as shifted ASCII, and finally the normal monitored Packet
is shown, the horizontal separator between frames consisting of "=" signs.
This function is mainly for test and experimental purposes, and is NOT
available when in the WA8DED host mode!

Split baud rate for the SCS FSK modem.
From version 2.4 onwards, the direct FSK modems (the "9k6" or "G3RUH compatible"
optional modules) can be used with different xmit and receive baud rates,
thereby now covering those digipeaters that work different speeds for the user
data and Upload.

The Baud command in the pac:-menu now allows two arguments to be given, i.e.
BAUD 19200 9600 <enter>, the first being the required receive speed, and the
second the required transmit speed.
In the case where only one argument is given, this is used by the PTC-II, as in
previous versions, as both the receive and transmit speed (baud) rates.

Status report when WA8DED host mode is activated.
When the WA8DED host mode is first started, a short status report is screened,
which shows the present version number of the PTC-II firmware and BIOS.

Bug fixes
* The modem adjustment possibilities (Baudrate/FSKFilter) for direct FSK PR
  modems are now saved, and rewritten to the modem when restarting the PTC-II.
  (this was really only relevant to speeds other than 9k6, as the default
  setting of the direct FSK modem is 9k6, anyway).

* TXDelay timing improved: The TXDelay is no longer tied to the CPU loading.
  (Up to now it was possible that, when downloading large files through a
  9k6 DAMA system, one received a "*** TX-DELAY TOO LONG" error message from
  the digi).

* Error in comparitor mode (under fax:-menu) corrected: The xmit routine could
  misalign the center frequency of the receive filter, this being now fixed.

* PR connect error fixed: The Connect command argument used to be broken off
  when entering a callsign with a double figured SSID, for example:
       Where C DB0GV-10 DB0GV was entered, only DB0GV-10 was called directly,
       the digi in the argument being ignored.
       Or where C DB0GV DB0KT DB0ID-10 DB0MV had been entered, DB0GV was called
       via DB0KT & DB0ID-10, with DB0MV being overlooked.

* PR REJECT error corrected: In certain REJECT situations of NON DAMA digis,
  the data flow between PTC and digi would be blocked, this now no longer
  being possible.

* The appearence of strange graphic symbols after CONNECTED- and  DISCONNECTED-
  messages when connected to stations with SSIDs greater than 8 is removed.

* Bug removed which prevented the PTC-II from digipeating

* Bug removed which prevented the PTC-II from being found by a FlexNet-search-


 Much fun and success with the new version, from

   Peter, DL6MAA, and the complete SCS-PACTOR team!

Document Actions
Log in

Forgot your password? New user?
Always current
View all news items
Mar 12, 2014
SCSmail 2.0
SCSmail 2.0

Operate your own flexible and powerful e-mail system using long-range radio technology.

Oct 30, 2013
P4dragon Firmware Version 2.0 with Packet Radio
P4dragon Firmware Version 2.0 with Packet Radio

Nov 13, 2012
Crew of the "Bounty" rescued by PACTOR
Crew of the "Bounty" rescued by PACTOR

Aug 05, 2012
Red Cross Communication in Austria
Red Cross Communication in Austria

The austrian Red Cross supports a Short Wave Network using PACTOR Modems as well. The austrian HAM Organizations are also involved in the network. The documentary shows the technical environment in Feldkirch.

Jul 20, 2012
The economic way to get the PACTOR 4 standard.
The economic way to get the PACTOR 4 standard.

Our new compact HF-Modem DR-7400 offers a lower-priced entry to the p4dragon modem class.