DP Tool Club 15/CD_ASCQ_15_070894.iso/vrac/psator6.zip/DOCS

Text File | 1994-05-08 | 91KB | 2,144 lines

PCTOR V3.07

PCTOR (c) Johan Forrer KC7WW 1991-1994


Author: Johan B. Forrer KC7WW
26553 Priceview Drive
Monroe, OR 97456
United States of America


Shareware notice



This program is your registered copy of PCTOR and is not for
distribution in any form. You may make as many copies for your
own personal use. A Shareware version of the program is available
from the author. PCTOR may not be sold or distributed with
another product without the express written permission of the
author. The author, Johan Forrer, KC7WW will only support
unmodified copies of this software.

If you are not satisfied with the program after registering it,
you have 30 days from your registration date to return it for a
full refund of your money, no questions asked.

Previously registered users may obtain a free upgrade to this
version - please send a formatted disk and SASE (or stamped
mailer or 2 IRC's).

This program may not be used by business or government
institutions without proper licensing. Commercial users please
contact Johan Forrer directly for modifications and/or details of
site licensing.
Acknowledgements



The work and ideas of Peter Martinez, G3PLX, and Paul Newland,
AD7I, has been the source and inspiration for doing the "nuts and
bolts" in this project.

Victor Poor's, W5SMM, helpful suggestions and ideas on
compatibility with MBBIOS, PAMS/APlink, and the implementation of
the extended ASCII set was invaluable.

The helpful suggestions of Frank Gorichar, W7JUF, who beta tested
early versions of this software is greatly appreciated. A special
word of appreciation to beta tester Peter Ferrand, WB2QLL/1, with
helping sort out various bugs. Malcolm, WA9BVS's beta testing has
helped locate numerous obscure bugs.

Thanks to Frank Wyatt, N6FW for forwarding technical
documentation to me.

Many individuals have sent in "wish lists", some of which are now
part of the latest version.  As always - your support, criticism,
and suggestions are appreciated.











       Please support the efforts of shareware developers.

Table of contents



0.0  Quick summary for this release.

1.0  PCTOR what does it do ?

       1.1  Minimum requirements to run PCTOR

       1.2    CAUTION

       1.3  Planned enhancements

2.0  Introduction

3.0  Hardware Interface

4.0  Installation

       4.1  Software

       4.2  Customizing the configuration file

5.0  Operating PCTOR

       5.1 Function keys

       5.2 Command menu

6.0 Appendix

     6.1 If problems persist.....
     6.2 What if it still does not work .....
       6.3 A few notes about HF modems.
       6.4 Soft error detection and correction.
       6.5 Frequencies of FEC stations for test purposes.
       6.6 Signal analysis module.
       6.7 DSP modem.
       6.8 PCTOR update history.
       6.9  1992 Newsletter
       6.10 1993 Newsletter
7.0  Disclaimer



0.0 Quick summary for version 3.07



-------------------------------------------------------
THE FOLLOWING ANNOUNCEMENT IS IMPORTANT TO SOME USERS.
-------------------------------------------------------


In order to support an new DSP modem on the same COM port that
PCTOR uses, versions higher than 3.05 now only supports
transmitted data output though TxD, (pin 2 on a DB25 or DB9).
This is due to the re-allocation of DTR for other purposes (the
DSP uses it). It is essential to establish whether your serial
port UART is suitable at higher baud rates - most modern serial
ports will work without any problems, some older styles may will
not work too well.

Input and output mask options have been removed. These options
only made sense when PCTOR was an AMTOR-only program. Ever since
PCTOR included support for RTTY and now PacTOR, these mask
settings often contradicted "normal" usage of RS232 signalling
conventions. A general rule that holds for all modes now are:

Mark  (binary 1) = -12V
Space (binary 0) = +12V

PTT keyed = +12V

This holds for RTTY/ASCII/AMTOR and HF Packet. Although PacTOR
does not commit to any specifically. In order to be compatible
with this convention, please check your modem and transceiver
interfacing.

If the TI DSK-based DSP modem is to be used with PCTOR, please
make sure that it is connected to the serial port, powered up and
ready for use. Also make sure that the "TOR.CNF" file contains
the lines:

dskmdm:2    .... this requests DSP modem support
dskbaud:1   .... 1=115200      baud for DSK comms
                 2=(115200/2)  baud for DSK
                 3=(115200/3)  baud for DSK
                 A value of 1 should work for faster machines,
                 however, if you experience problems with loading
                 the DSK, use a lower baudrate.
dskrtty:1    ....
dskascii:1   .... (Allocates which modem to use, see below)
dskamtor:2   ....
dskpactor:3  ....
dskpacket:4 .....  1=170 Hz shift 50  baud 2125/2295 FSK
                   2=170 Hz shift 100 baud 2125/2295 FSK
                   3=200 Hz shift 200 baud 2125/2310 FSK
                   4=200 Hz shift 300 baud 1600/1800 FSK
                  10=170 Hz shift 50  baud 1275/1445 FSK
                  11=425 Hz shift 50  baud 1275/1700 FSK
                  12=850 Hz shift 50  baud 1275/2295 FSK
                  20=170 Hz shift 50  baud 2125/2295 AFSK
                  21=170 Hz shift 100 baud 2125/2295 AFSK

Further information on the DSK-based DSP modems are available in
a separate document.

Known Bugs:


1. Dos versions below 4.0 will not load hot key buffer. The
reason is that in order to provide a sorted list of buffers,
PCTOR uses the dir /o:n command. This option is not available in
older DOS versions.

New features:


1. For AN-93 users, the parallel port is chosen by the LPT
parameter:

lpt:x    where x=1, 2 for LPT 1 or LPT 2. The default is LPT 1.

2. Any COM port (1 - 4) may be specified in the configuration
file. Please make sure that your configuration file contain an
entry:

com:x    where x=1, 2, 4, or 4

3. If a TI 320C26 DSK is used as a DSP modem, appropriate modem
code will be loaded automatically when operating modes are
changed.


 Bug fixes since version 3.03:

1. Some users reported that they experienced a system lockup
after the initial screen. This was reported in cases where a
sound card was installed in the system, and also with DOS 6. The
problem was traced to a Compiler bug and required some minor
rework of code.
1.0 PCTOR what does it do ?


Using only a low cost external HF modem, PCTOR makes it possible
to run AMTOR on PC compatible hardware without the need of
dedicated multi-mode terminal node controller (TNC) hardware. All
decoding is performed in software in real time using only PC
hardware. The software has been tested to work even on a lowly
4.77 Mhz PC compatible.


PCTOR will run under Microsoft Windows as a DOS application in
full screen mode (please see the supplied .PIF file), however
this kind of operation is presently not recommended. Future
releases of PCTOR will be specific for operation under the
Microsoft Windows platform.


The main features of PCTOR could be summarized as:



1  - Split screen operation: Data received through the AMTOR
     translator is displayed on the upper window. The operator's
     keyboard entry is displayed on the lower window. A status
     window shows real-time operational status of the digital
     translator. This includes, timing, path propagation delay,
       link status, selcals, and more.

2 -  All AMTOR modes are supported: ARQ, FEQ, and "Listen".
     Ascii/Baudot at any baudrate (practical maximum is 1200
     baud).

3 -  The user may define several text buffers, i.e. brag tape,
     CQ messages, etc. that may be loaded for transmission with
     with one key stroke.

4 -  Text files my be transmitted. Typically the user will
     prepare these off-line.

5 -  Unshift-on-space (UOS) option.

6 -  "PLX"-method of upper/lower case with extensions as
     developed by Peter Martinez (G3PLX), and Victor Poor
     (W5SMM).

7 -  A "high" reliability option based on multiple bit sampling
     and majority voting. Memory ARQ for AMTOR is also supported.

8 -  Receive data can be optionally be captured in a file.
     Automatic time stamps, as well as user-initiated time stamps
     may be entered into this capture file. The capture file can
     be read using an ordinary text editor.

9 -  PCTOR can open a Dos shell (viable only for 386/486)
     with the low level AMTOR decoder running. The low
     level decoder has buffered I/O queues to accept traffic even
     when PCTOR has opened a DOS shell.


10 - The user can customize the working environment through use
     of a configuration file that is read when PCTOR starts up.
     Usage of a DOS environment variable "PCTOR" allows easy
     accommodation for a variety of operating environments.

11 - Keyboard entry is either in word-edit or character mode.
     When in word-edit mode, keyboard data is only entered into
     the type-ahead buffer when a space is entered (or carriage
     return, or the special symbol sequence "+?"). This way
     typing mistakes may be corrected before releasing them over
     the air.

12 - Advanced signal processing is available when using a special
     modem. This type of modem allows PCTOR to analyze internal
     circuit voltages in order to perform "soft" error detection
     and correction. Please see section 6.4 for further details.

13 - PCTOR's time may be set either for UTC or the user's local
     time.1.1 Minimum requirements to run PCTOR


PCTOR will run on an IBM PC or close compatible computer. DOS 3.1
or higher is required. A monochrome or EGA/VGA display adaptor
will work. Although the software will run on a floppy-based
system, a hard disk is recommended. The definition of "true IBM
compatibility" is fuzzy and a great deal of flexibility has been
built into the programs to handle a wide range of PC hardware.
Please refer to the appendix where some further notes on dealing
with incompatibilities are included.

Some of the DSP options are only feasible on more powerful
machines, i.e. 386 with co-processor or a 486.

On the radio side, an HF modem, i.e. ST-6 or equivalent is
required to decode received audio to +/- 12V RS232 logic signals.
For transmission of AMTOR over the air, the user also has to
provide a PTT interface and either AFSK or FSK. These interfaces
are often included in an HF modem. If the software is used for
monitoring only, only the HF modem is required. The HF modem is
required to convert audio tones to RS232 compatible digital
levels required by PCTOR (please see 6.3 for further notes on HF
modems).

PCTOR uses some of the signal lines of the standard COM1 or COM2
serial ports as a digital interface (the user specifies which COM
port - see "Installation - software").  1.2 Caution



This software may not be suitable for all working environments.
The user should therefore proceed with the usual caution and make
sure critical software is backed up.

Every effort has been made to ensure that the software is "well
behaved", however, the user is reminded that this software relies
on critical timing. Normal system functionality is retained, i.e.
time-of-day and floppy disk timeout activities. The user must
thus be careful not to run other software that relies on similar
"tricks" that PCTOR uses as the consequences are indeterminable.

Normal program usage and program termination will undo the
actions of PCTOR and restore normal system operation. Should a
program failure occur, the only way to restore normal system
operation is to reboot DOS.

1.3 Planned enhancements



Several enhancements are planned for release in the near future.
As a registered user you will be notified of these when it
becomes available. These include:

* PACTOR (a pre-release version is already available).
* SAA/CUA standard interface (Windows Application).
2.0 Introduction



PCTOR is an implementation of CCIR specification 476-2 on an IBM
personal computer or compatible computer. As such, it replaces
the need for dedicated TNC hardware and is an attractive
alternative for the casual user evaluating a new operating mode,
as well as the serious developer that needs to embed low level
I/O functionality into a system.

PCTOR contain a user-interface program that works in conjunction
with several low-level routines that enables a user to operate
and monitor TOR traffic with a minimum of fuss. Its
multiple-window user interface allows simultaneous monitoring of
decoded traffic, decoding status, and user keyboard history. Pop-
up windows is used for setting operational parameters, file-I/O
operations, and canned buffer transmissions.

Function keys are used for quick, easy, and efficient control of
most operations.

PCTOR was developed using Borland C++ Version 3.1. The low-level
interface was developed using Borland Turbo Assembler version
3.0.
3.0 Hardware interface



PCTOR interfaces through signals of the COM1 or COM2 RS232 port.
The following allocation of RS232 signals have been made: Other
signal pins may be connected, however will play no part in the
operation of PCTOR.

Note that for a minimal interface, DTR, RTS, DCD, and Ground, is
required. This will allow operation on AMTOR. For ascii/baudot,
RD and TD must be utilized. If further software support for the
tuning display or memory ARQ is required, a parallel port
interface is required. Please contact the author for further
details.


For a 25-pin serial connector:

pin 2   (TD)  - output data bits (mark -12V, space +12V)
pin 4   (RTS) - PTT              (off  -12V, on    +12V)
pin 8   (DCD) - input data bits  (mark -12V, space +12V)
pin 7   (Ground)

The following link is required:

pin 3   (RD)  connected to pin 8 (DCD).



For a 9-pin serial connector:

pin 3   (TD)  - output data bits (mark -12V, space +12V)
pin 7   (RTS) - PTT              (off  -12V, on    +12V)
pin 1   (DCD) - input data bits  (mark -12V, space +12V)
pin 5   (Ground)


The following link is required:

pin 2   (RD)  connected to pin 1 (DCD).


When PCTOR is used in conjunction with the AN-93 analog modem,
the parallel port interface is as follows:

For a 25-pin parallel printer connector:

pin 15 - AD0    (bits 0 - 4 from the A/D convertor)
pin 13 - AD1
pin 12 - AD2
pin 11 - AD3
pin 10 - AD4

pin 1  - Strobe (strobe for A/D convertor)

pin 18-25 - Ground
4.0 Installation


4.1 Software


It is assumed that a hard disk is available, though the program
can be run off a floppy disk as well. In fact it is suggested
that you first run off a floppy disk to see if this software is
compatible with other software that you may have on your system.

1. Create a new subdirectory and change directory to it, i.e.

   mkdir tor
   cd tor

2. Copy the contents of the floppy to the new subdirectory.

   copy a:*.*

   The following files will be copied:

   tor.exe    -- The split screen AMTOR program.
   tor.cnf    -- Setup file to custom configure your program.
   docs       -- This documentation.
   brag.tor   -- An example test file to load.
   cq.tor     -- Another example file to load.
   test.tor   -- A buffer file for demonstration of control
                 characters
   AMTOR.BAT  -- A batch file to run TOR with a parameter. Check
                 to see which communications port COM 1 or 2 you
                 desire.

3. Customize tor.cnf  (see 4.2 "Customizing the configuration").

4. Create, or edit the files with ".tor" extensions. These files
   will be read when the program starts and will become the
   user's personalized buffers. These are transmitted by using
   the "hot" keys ALT-1 through ALT-9. The two included examples
   are typical.

5. Edit the the batch file "AMTOR.BAT" to suit your screen
   display color requirements (Please see section 9).

6. Run the batch file AMTOR, i.e. type AMTOR <enter>, or
   alternatively run it directly from the command line.

7. Make sure that you use the "ANSI.SYS" device driver in your
   DOS config.sys (please see about ANSI.SYS in your DOS manual).

8. There are three DOS environment variables that is worth
knowing about. If you are not familiar with environment
variables, type "SET" with no additional parameters at the DOS
command line for the present list of environment variables on
your machine. Some programs actually scans this list and may
configure themselves accordingly. As far as PCTOR is concerned,
your time zone, i.e. how many hours your are way from UTC time,
and what abbreviation you would like to use for logging and
operating purposes, is important. This environmental variable is
called "TZ" and you typically include it in your autoexec.bat:

   set TZ=PST8  (I use this for setting Pacific Standard Time,
                 that is 8 hours after UTC. Please consult your
                 DOS manual).

When you need to run PCTOR with say a bunch of different
configuration files, or different ".tor" files, the "PCTOR"
environment variable may be used to distinguish amongst them.
Otherwise PCTOR will use the configuration file and ".tor" files
in the local subdirectory from where you executed PCTOR from. If
for example you need to use a different subdirectory for your
configuration file than where your execute tor.exe, then the
following command need to be typed at the DOS command line, or
included your autoexec.bat (lets assume the configuration file is
in c:\COMM):

       set PCTOR=c:\COMM

The third environment variable that is of concern is COMSPEC.
This variable tells PCTOR where to locate "command.com" when a
dosshell is invoked (the F8 key). Usually the root directory is
used, but there are instances where users specifically wish to
locate their command.com elsewhere. DO NOT CHANGE the COMSPEC
variable unless you are very familiar with DOS.

9. Several options are configurable from PCTOR's command line.
This includes the type of display adaptor, the number of lines in
each of the split screen displays, and the colors of displayed
characters, messages, and annunciators. If you are using an
EGA/VGA/SVGA display adaptor, the default settings will probably
be adequate. In that case, leave out any further parameters on
the command line.

The general format of the command line format is:

TOR [/B | /C | /M] [/Wxx] [/R] [[/SCxx] [/SExx] [/SBxx]
                                [/SMxx] [/SAxx]]

A command line parameters require the leading "/" followed by a
directive such as B,C,M,W,R, or S. These parameters may be
submitted in any order, each occurring only once. Note that for
the display adaptor group, only one parameter, i.e. /B, or /C, or
/M must be present. If for instance you have a monitor that has
both color and black and white capabilities, and you desire to
use a black and white display, use the /B. Using monochrome in
this case will probably lock up your display.

The significance of the command line parameters are given below.

┌───────────────────────────────────────────────────────┐
│ Parameter               Description                   │
╞═══════════════════════════════════════════════════════╡
│     Display type    (ONLY ONE OF THESE ALLOWED)       │
├───────────────────────────────────────────────────────┤
│     B                   Black and white on a color display  │
│     C                   Color                               │
│     M            Monochrome                                          │
╞═══════════════════════════════════════════════════════╡
│     Wxx          Size of receive display (lines)          │
╞═══════════════════════════════════════════════════════╡
│     R       Receive only - disable transmit facilities    │
╞═══════════════════════════════════════════════════════╡
│             Display color attributes                  │
├───────────────────────────────────────────────────────┤
│     SCcc                Received traffic character color    │
│     SEcc                Echoed   traffic character color    │
│     SBcc                Background      color                            │
│     SMcc                Message     character color         │
│     SAcc          Annunciator character color         │
└───────────────────────────────────────────────────────┘
* The field xx indicates an integer number of lines.
  The field cc indicates a color code as given in the color table
below.

Certain restrictions apply to assignment of foreground and
background  colors. Example. The default settings are:

TOR /C /W20 /SC7 /SE15 /SB1 /SM3 /SA14

This translates to: Color display (CGA/EGA/VGA), 22 line receive
display size, SC=Lightgray, SE=White, SB=Blue, SM=Cyan,
SA=Yellow.

Experience have shown that there are various types of monochrome
display adapters around. Even those that are advertized as
"Hercules" compatible often behave differently. Some of these
monochrome display adapters could be used as being "color" as
they will correctly map colors to the appropriate black/white
attributes. Other monochrome adapters, however require the /M
parameter and must not contain any color attributes. Some
experimentation is necessary. Be warned that in some instances an
inappropriate display selection may lock up your machine and
require a reboot to recover.

The receive-only command line option, /R, will disable all
transmit facilities such as F1, F2, as well as functions that
enter data into transmit buffers. It is also recommended in this
instance to remove the keyboard-buffer window altogether using
/W25.




Color constants for setting PCTOR display attributes.

┌─────────────────────────────────────────────────────┐
│ Color Constant   Value     Foreground or Background │
╞═════════════════════════════════════════════════════╡
│BLACK                    0                   Both                       │
│BLUE                     1                   Both                       │
│GREEN                    2                   Both                       │
│CYAN                     3                   Both                       │
│RED                    4                     Both                       │
│MAGENTA                  5                   Both                       │
│BROWN                    6                   Both                       │
│LIGHTGRAY                7                   Both                       │
│DARKGRAY               8                     Foreground only      │
│LIGHTBLUE                9                   Foreground only      │
│LIGHTGREEN              10                   Foreground only      │
│LIGHTCYAN               11                   Foreground only      │
│LIGHTRED              12                     Foreground only      │
│LIGHTMAGENTA            13                   Foreground only      │
│YELLOW                  14                   Foreground only      │
│WHITE                   15                   Foreground only      │
└─────────────────────────────────────────────────────┘

4.2 Customizing the configuration



To enable a user to streamline the setup of the program to his
requirements, a configuration file, "tor.cnf" is read during
startup. Read and edit the contents of the provided file
"tor.cnf" to suit your own preferences. This file is optional,
but when not found, the system will use defaults. These entries
are all optional, and may appear in any order, however, please do
not enter any spaces between symbols,

i.e.

vid : 1        is NOT the same as       vid:1

(The last one is correct).



The following entries may be customized:

id:KCWW/KC7WW             ----- set your identity selcal/callsign
selcal:WDRZ/WA8DRZ/6      ----- set the  startup selcal/callsign.
wru:QRA KC7WW KCWW        ----- your WRU text.
com:1                     ----- COM port to use 1= COM 1
                                                2= COM 2
                                                3= COM 3
                                                4= COM 4
lpt:1                     ----- LPT port to use for AN-93 modems
                                1= LPT 1.
                                2= LPT 2
opmode:0                  ----- defines start-up mode 0 = AMTOR
                                                      1 = BAUDOT
                                                      2 = ASCII
baud:45                   ----- initialize BAUDOT/ASCII baudrate
txdelay:30                ----- delay (ms) after PTT on till data
                                out.This gives your transmitter
                                time to changeover to transmit.
cddelay:3                 ----- delay (ms) after a data block is
                                received before acknowledgement
                                is sent. This gives the other
                                station's receiver time to
                                recover.
timing:25                 ----- system clock timing adjustment
uos:0                     ----- unshift-on-space OFF
diddle:0                  ----- RTTY diddle is OFF
case:0                    ----- upper/lower case OFF
log:1                     ----- receive data capture (logging)
logfile:tor.log           ----- data capture filename
scrollfile:scroll.tmp     ----- name of scroll file - if a
                                ramdisk is available, use the
                                full drive name here
logprog:logger.exe        ----- name of user's personal log
                                program
packetprog:pac.bat        ----- name of user's packet program
rel:0                     ----- reliability OFF
vid:1                     ----- DIRECT video I/O enabled (see
                                appendix on hardware
                                compatibility)
fcrlf:1                   ----- Files, i.e. buffers and files to
                                be sent through the ALT-F command
                                should use the AUTOMATIC CR/LF
                                mode. This means that all CR's in
                                the input text files will be
                                ignored, and LF will be
                                interpreted as CR/LF.

refr:15                   ----- Status update rate. The number of
                                system ticks between updates,
                                i.e. 15*55mS=0.825 seconds. To
                                fast a rate will flicker or
                                perhaps may introduce timing
                                problems, too slow will affect
                                animation of timing bar, clock,
                                etc.
time:0                    ----- Use local time in displays and
                                logging. If UTC time is required,
                                use time:1 (also refer to the TZ
                                environment variable).
tuning:0                  ----- Disable software support for
                                tuning display. To utilize this
                                feature, use tuning:1. A
                                special modem is required.
marq:0                    ----- Disable memory ARQ. Different
                                levels of memory ARQ are
                                recognized. Presently only level
                                1, "hard bits" is recognized.
                                To utilize level 2 memory ARQ,
                                i.e "soft bits", a special modem
                                is required.
word:1                    ----- Turns word-edit mode on.
stats:0                           ----- Turns statistics off. When
                                stats:1, displays the number of
                                blocks received, number of blocks
                                in error, and when memory ARQ is
                                enabled, the number of blocks
                                successfully reconstructed. These
                                statistics are also inserted in
                                the log file for later retrieval.
dskmdm:0                   -----DSP modem 0 = Use external modem
                                          1 = Use DSK.

Note that the syntax isn't tested very rigorously. Please check
your input carefully against the supplied example.

Both the AMTOR mode of PCTOR and RTTY/ASCII uses "common RS232
convention" where:

                     Mark (binary 1) = -12V
                     Space (binary 0) = +12V

                     PTT not asserted (open) = -12V
                     PTT asserted (keyed)    = +12V

Until you have sorted out the required logic interfacing logic,
prepare your transceiver for low power output into a dummy load
(you may find your PTT unexpectedly comes on upon executing the
program).

Now run TOR. If your PTT comes on right away, the sense of RTS
must be inverted before further testing can be done. Normally,
TOR should put you in standby mode (PTT OFF).

Next, on-the air tests will be necessary. Try to decode some FEC.
FEC will be decoded while in standby mode. To make sure that you
are in standby mode, hit F10. Tune in on an FEC transmission and
wait for it to sync. If it fails to decode anything, first try
changing the other sideband setting of your transceiver (if you
normally use LSB, try using USB). This will show whether it's the
interface logic or whether there is some other problem. If TOR
receives FEC in the other sideband setting, the sense of DCD
needs to be changed.

The final test is to determine the logic level required for the
transmitted data. Try an ARQ call. If it fails, you need to
invert the sense of TxD.

There is an additional timing-related entry, "timing:" that need
to be set up. This parameter allows external adjustment of the
system clock pulses to cater for systems with inaccurate clocks.
Very few PC's have accurate clocks and although the default value
(25) will work reasonable well in most cases, adjustment of this
parameter is very desirable. For determining the value of this
timing parameter, see  5.2 - Command menu: usage of the 'T'
option.
5.0 Operating PCTOR



Upon startup, the shareware banner may be displayed if you are
suing the shareware version. In this case, press the ESC key to
proceed to the PCTOR screen.

The contents and layout of the status display line depends on
which options the user has selected. The following description
refers to the case when all the options are enabled. This gives
the reader a description of all possibilities.

PCTOR displays several windows: two status displays, the received
traffic window, and the keyboard display.

The smallest display is at the top of the screen, is the status
window that is updated in real time and some machines may show
some flickering. This is normal.

Link status information, i.e. ARQ/BAUDOT/ASCII, IDLE, TFC, ERR,
RQ, is displayed on the left hand side of the status line.

Adjacent to the link status is the selcal/callsign of the remote
station. This data is used in establishing the link and also for
printing out identification data (see usage of the "Ins" key).

Next, the programmed delays are shown: TD is the time (in
milliseconds) that you allow, after the PTT signal has been
activated, before data output will start. It is one way to
compensate for slower on-switching equipment on your end. It
allows for things to settle, before actual data is being sent.
The default value (30 ms) is a reasonable compromise. CD is the
time (in milliseconds) that allows the remote station's receiver
to recover after it sent a block and is getting ready to receive
your acknowledgment. The default of 3ms is reasonable. Actually,
the total time before the user will be able to sample the
acknowledgement is CD+TD. When you are sending blocks, however,
then TD only plays a role. This split timing scheme allows for
compensation in situations where the remote station experiences
slower receiver recovery that transmit turn-on time. This is
typical for local contacts.

Once some traffic starts flowing, and you were the call
originator on ARQ (i.e. the "Master"), the block receive time
will be displayed. This is an internal timing parameter that
cannot be changed. It includes the delay-parameters at both send
and receive stations as well as the time delay due to the signal
propagation through the atmosphere. If you notice considerable
variation, then multipath propagation is most probably the
reason, however, under high noise conditions, the simple types of
modems may also pass too much pulse noise for the software to
achieve good bit phasing lock.

If the unshift-on-space (UOS) feature has been selected, this
will be displayed as a µ symbol. This feature will shift letter
shift when a space character is printed. Under noisy conditions,
this will prevent the printing of data in the wrong case.

If the user has selected the receive screen capture
(autologging), the a ¢ symbol will be displayed.

When the reliability option is selected a √ symbol will be
displayed. Reliability is obtained by sampling each bit multiple
times and using a majority voting.

If the user selected upper/lower case operation, there will be
two arrows, the first one is associated with the case of the
receive text, while the second one is associated with the
transmit case. An "up" arrow means upper case, while a "down"
arrow indicates lower case.

A 24 hour-format clock is also shown on the display. This clock
is used for time stamps that are written to the log file, if
enabled. The clock may be set for local time or UTC time (also
see section 4.1 for details).

An eleven bit analog indicator on the right hand side shows how
bit phasing is progressing. During FEQ or ARQ, the indicator
should show slow motion from right to left. The speed of the
motion depends on how much your clock and the other station's are
differing relative to each other.

When the special TOR modem is used, and provided that the
"tuning:1" option is set in the configuration file, a tuning
indicator is displayed immediately below the bit phasing display.
This tuning display consists of ten gradations each for mark and
space simulating two bar-graph displays. The position of the
indicator within the bar-graph display is proportional to energy
passing through the mark and space filters in the modem's
discriminator. When there is sufficient energy present, the color
of the displayed indicator will change from a grayed outline to a
solid color (red for mark and yellow for space on color
displays). A well-tuned signal shows as two solid indicators that
rests on the extreme end of the display. The display is quite
steady and sharp.

When using the "marq:1" option is used, the level 1 memory ARQ
procedure is performed during ARQ reception. This involves block
reconstruction from multiple bad blocks using "hard bits". Level
2 memory ARQ uses "soft bits" in addition to "hard bits",
however, the special TOR modem is required. When memory ARQ has
been successful in reconstructing a block, this is shown as "ERR"
with green background instead of the usual red background.

The second status line displays the name of the user-supplied log
file, the name of the user-supplied executable (usually a logging
program), statistics, and the size of the type-ahead buffers.
5.1 Function keys



The function keys have the following functions:

F1  - Initiate an FEC (Ascii/Baudot) call.

F2  - Initiate an ARQ call.

F3  - Force a change-over (works only in ARQ).

F4  - Initiate QRT sequence (ends ARQ/FEC, Ascii/Baudot
      transmissions).

F5  - If receive text capture is enabled, will insert a timestamp
      into the log file.

F6  - Initiate ARQ listen mode.

F7  - Clear keyboard type ahead and special buffers (used for
      WRU), clears keyboard display.

SHFT F7 - Clears receive display.

F8  - Open a DOS shell (use with care - 386/486 machines).

F9  - Not used.

F10 - Abort any operation in progress and revert to standby mode.

End - Enter the +? sequence into the keyboard buffer.

Ins - Enter an identification string into the keyboard buffer.

Del - Force LTR case during receive (FEC/ARQ or Baudot). In
      addition will it reset the transmit and received cases to
      UPPER.

Ctrl-Home - toggles "raw" data mode. For experimenters only -
      displays untranslated ITA2 (Baudot) code in Hex. This data
      is also written to the log for later analysis.

ESC - Calls up the command menu when in user mode.

Pgup/PgDn// - Scrollback, any other key will restore screen

ALT-A Executes a signal analysis program. The modulation
      signal as recovered after the low pass filter of the modem
      is sampled and displayed in a graphics window. A second
      graphics window displays the frequency domain equivalent.
        Only EGA, VGA, and Hercules-compatibility is supported
      (also see Appendix for more on the signal analysis
      software).

ALT-B - Enter the buffers menu. This allows a data buffer to be
      loaded into the keyboard buffer. The user prepares these
      buffers ahead of time using a text editor. These files have
      a "TOR" extension and will be loaded when TOR is
      initialized. Also note the usage of the ALT-1 through ALT-9
      keys as "hot" keys to load any of these buffers with one
      keystroke.

ALT-C - Prompt user to enter the selcal/callsign of the remote
      station AND initiate an ARQ call immediately.

ALT-D - Toggle RTTY diddle on/off.

ALT-F - File transmission menu. Allows the transmission of text
      files while in FEC or ARQ. The transmitted text will be
      displayed as it is transmitted. There will be no echo to
      the receive window.

ALT-H - Displays a help screen, showing the usage of the various
      function keys.

ALT-M - "Hot keys" to the DSP modem control program.

ALT-L - Activate the program named in the configuration file
      option "logprog". PCTOR remains running in the background.
      Upon termination of the user's program, the PCTOR display
      is restored.

ALT-P - "Hot keys" to PC-PACTOR. Note that PC-PACTOR need to be
      available in the same directory than PCTOR.

ALT-O - Toggles output to printer on/off.

ALT-R - Prompt user for the selcal/callsign of the remote station
      WITHOUT initiating an ARQ call.

ALT-T - Enter UTC time into the keyboard buffer for transmission
      in FEC or ARQ.

ALT-W - Sends the "WRU" command to the remote station. This is
      the "figs-D" character in the ITA2 (Baudot) alphabet.

ALT-X - terminates PCTOR in an orderly fashion. Equivalent to the
      "Q" option in the command menu.

ALT-Y - "Hot key" to the packet program. Note that this typically
      is a batch file. The user must set this up the "packetprog"
      parameter in the configuration file. Please see
      section 4.2.
5.2 Command Menu



The command menu (called up when the ESC key is pressed when in
the main display) has the following one letter commands:



C - Enable or disable upper/lower case operation.
D - Set the cd and tx delays. CD is the time after reception of a
    data block until your acknowledgement is forthcoming. TD sets
    the time delay after the PTT is activated until data is sent.
    For local contacts CD=10, TD=30 will be suitable. For DX
    contacts CD=1, TD=10 is suitable. The default settings of
    CD=3, TD-30 is adequate for most modern radios.

H - Help with the function keys.
I - Set your own ARQ identity.
K - Toggle between word-edit or character keyboard modes.
L - Enable or disable receive capture (logging).
O - Change operating mode AMTOR->BAUDOT->ASCII->AMTOR->...
P - Change baudrate (300 max).
Q - Terminate PCTOR.
T - Set clock timing. This parameter allows fine adjustments of
    the master clock. See Appendix A for further details.
U - Sets UOS (unshift on space) on or off.
V - Toggles video mode (DIRECT/BIOS).
W - Set up your WRU text.
X - Exit the command menu to main display. The ESC key may also
    be used for this purpose.
Y - Sends out a 500 HZ pulse train from pin 20 for diagnostic
    purposes.

6.0 APPENDIX.


6.1 If problems persists.......



The most common feedback from users appears to be setting up
PCTOR's master clock timing. Once this is done, the user enters
the "magic" number into the configuration file that is used
automatically each time the program is started. Only when
installing the program on another computer will it be necessary
to reset this timing parameter.

Please note that this parameter has noting to do with the speed
of your processor, or whether you use an 8088 or 486. Its about
how to program a certain chip (8253/4) on the PC's motherboard.

Typical symptoms will be that either nothing happens when trying
to decode a FEC signal, or, the FEC sync is obtained, some text
is printed, however, synch is lost and only a few words of
garbage is printed before it starts re-sync. If you have a scope,
or frequency counter available, try the following (its not
serious if you do not have access to test equipment - you will
just have to be a little patient and do some common-sense trial
and error. It will take a little longer, but you will obtain the
same end result. Skip the next paragraph if you do not have
access to test equipment):

Enter the command menu (Hit ESC) and select the "Y" option. This
command should toggle the "Td" data pin at 500 Hz. Use the "+"
and "-" keys to toggle the speed up or down, however, timing
values above 30 and less than 18 are indicative of possible
incompatiblities. Most systems work fine with the default of
timing value of 25. When you have completed the test, return to
the main display and select STANDBY (F10).

Tune in FEC mode to a strong FEC broadcast station such as KMI
WOO, or WLO (see attached list 6.5). Observe the timing indicator
on the right hand corner of the status line. Notice that it may
slide slowly. The objective is to have it as stationary or
indecisive as possible. However, do not be concerned if you
cannot get a perfect steady display, that is quite normal.

Vary the timing value, one step at a time using the "+" or "-"
keys. After changing the clock setting, the previous value as
well as the new value will be displayed. You MUST then exit the
command menu for the new settings to become effective. Once back
to the main display, select STANDBY (F10) and wait for sync to be
detected. Notice that when you return from the command menu to
the main menu, you may see some received text being written to
the receive display. This is text that have been accumulated by
the low-level decoder and was stored in a system buffer while you
were using the command menu. This text should be ignored as the
changed clock setting was not yet in effect.


Once the optimal setting has been found, modify the configuration
file TOR.CNF to include the parameter for your system. Values
ranging from 0 to 36 is valid. This procedure set the system
clock close to +/-50ppm for stable AMTOR operation.



6.2 What if it still does not work ......


At this point there remains one question: how "IBM compatible"
your computer is. Perhaps your computer is quite compatible but
there may be an interface adapter card that is not. It has been
found that some video adapters does special emulation, i.e. runs
one video mode, but allows some other type of equipment to be
attached, i.e. ATI allows you to run VGA mode, yet allows you to
use a CGA display. This kind of hardware introduces either wait
states, or disables the interrupt system at a very low level.
Since PCTOR needs a stable timing source, there will be a
conflict for sure.

PCTOR allows you to minimize these conflicts that are related to
the video display by allowing the user to disable writing
directly to the video memory. By selecting the "V" option in the
command menu thus toggling BIOS on, all video access will be done
through BIOS calls. The status line is also simplified to reduce
the overhead. In some cases, this will do the trick. It is also
possible to reduce the amount of screen-writing activity by
slowing down the rate that the status line is updated (see 4.2
"refr:15" ).

Another problem that has been experienced with older PC
compatibles, i.e. 1984 or so, is support chips on the motherboard
that does not behave like later versions. Although these machines
may be perfectly capable of running most software, they will not
be able to keep accurate timing and may not work well with PCTOR.
If possible, update the 8254 and 8259 chips. Also check the 8250
UART for the same reason.

Although there has not yet been reported problems on the use of
serial/parallel interface cards using ASIC (Application-Specific
Integrated Circuit) chips, some laptops and recent desktop
machines are now using them. These ASIC's have varying levels of
compatibility with the 8250-style chips and some are known to
present real problems. The author uses both styles without
problems, however, it is possible that the software may not be
able to work in all situations. If your problems persist, as a
last resort, check whether perhaps your system uses one of these
ASIC's. Feedback on such problems will be appreciated - perhaps a
solution may be forthcoming.



6.3 A few notes on HF modems

Experience have shown that some modems perform better than
others. We may divide the class of popular modems roughly into
three categories (there are a few other types as well):

(I)   The phase locked loop (PLL),

(II)  filter type,

(III) digital signal processing (DSP) type.

It is the author's opinion that the PLL type of modems are not
suitable for average HF operations. It is best to avoid this
approach even with extensive front-end filtering.

The filter-type modem have been used with much greater success on
HF. However, there are various kinds of approaches in filter-type
modems:

Vintage designs like the ST-5 and ST-6 employed L/C filters and
are known to work reasonably well, given that some changes are
made to their low-pass filters (mainly to pass the 100 Hz AMTOR
modulation rate).

Active filter designs such as the DJ6HP will also work quite well
under fair conditions, however, do not expect too much under
adverse conditions. Another popular active filter modem is the
BARTG design. This small modem will work reasonably well too,
however it lacks front-end bandpass filtering, and has poor post-
discriminator signal processing. Both these designs are good for
newcomers.

Modern good performance filter-type modems use sophisticated
front end filters in conjunction with well-designed
discriminators and extensive post discriminator filtering
circuitry. They generally have excellent dynamic range to handle
strong signals as well as being able to "dig into the noise" to
handle weaker signals. They will tolerate some degree of off-
frequency operation. It also has become popular to monitor analog
levels of signals within the modem in order to implement "soft"
error correction techniques. Although this does not necessarily
mean an increase the level of hardware sophistication, additional
interfacing and software support is required.

The DSP approach is still new to HF operation, yet holds a lot of
promise. There are presently some commercial units available.

If you are interested in a small, yet sophisticated filter-type
modem, with "soft" error correction capabilities, please contact
the author for further details.
6.4 Soft error detection and correction



With the introduction of PACTOR, soft error detection and
correction entered the domain of HF communications for amateurs.
The idea of soft error detection and correction has been
described extensively in the literature, mostly in conjunction
with high-speed satellite data links.

A short introduction to soft error detection and correction, also
termed "memory ARQ" follows:

Most HF modems presently in use, does extensive signal processing
to recover of the transmitted modulation. The output of the modem
then is a stream of logical bits (zeroes and ones). These bits
are then further processed by digital processing methods to form
messages.

It is, however, unfortunate that a great deal of useful
information is lost when logical bits are produced by the modem's
hardware. One can think of this thresholding as a one-bit analog-
to-digital (A/D) conversion process (with resulting values zero
and one). If this A/D conversion could have produced more
resolution, i.e. eight, 16, or even 256 distinct levels, then it
would have been possible not only have access to the resultant
thresholded value, but also the magnitude of the signal at the
time that it was thresholded.

One application where knowledge of this magnitude is useful, is
AMTOR ARQ mode. During AMTOR ARQ, blocks of three characters are
transmitted on each chirp. The receiving station analyzes each of
the three received characters for a possible error, and when an
error is detected, it chirps back an RQ reply to the transmitting
station to repeat the last three-character block. It is possible,
and even probable when conditions are poor, that the
retransmitted block may again contain an error. This may result
in several repeated blocks. It is possible to improve on this
"blind RQ" method by using memory ARQ.

If the receiving station uses memory ARQ technique, it would have
stored the A/D values associated with each and every bit of each
of the three received characters. When an error is detected in a
retransmitted block, i.e. after an RQ, an error-correction
algorithm is then used to compute a "confidence" value for each
character of the bad blocks (over two or more blocks).
Subsequent block reconstruction then follows where a
reconstructed block is made up from highest confidence elements.
Such a reconstructed block is then error-tested again. More often
than not, this results in fewer RQ's. PCTOR will show the actual
statistics of how its doing. For HF conditions a success rate of
10% of received blocks in error, is achievable.


6.5 Some frequencies for FEC stations for test purposes



Logged on: Fri Dec 11 1992 22:25:19 on 8431.5 KHz using PCTOR
V2.02


AT+T HIGH SEAS RADIOTELEX BROADCAST FREQUENCIES ARE AS FOLLOWS:

+++++++++++++++++++++++++++++++++++++++++++++++++
+    ITU CHAN       COAST-TX    AT+T STATION    +
+    --------       --------    ------------    +
+      405           4212.5         WOO         +
+      412           4215.5         WOM         +
+      416           4217.5         KMI         +
+                                               +
+      626           6326.5         KMI         +
+      628           6327.5         WOM         +
+      629           6328.0         WOO         +
+                                               +
+      831           8431.5         KMI         +
+      833           8432.5         WOM         +
+      834           8433.0         WOO         +
+                                               +
+     1303          12630.0         KMI         +
+     1305          12631.0         WOM         +
+     1307          12632.0         WOO         +
+                                               +
+     1728          16870.0         KMI         +
+                                               +
+     1818          19689.5         KMI         +
+                                               +
+     2299          22425.5         WOM         +
+++++++++++++++++++++++++++++++++++++++++++++++++



WX AND HIGH SEAS INFORMATION SCHEDULED BROADCASTS ARE AS FOLLOWS:

STATION      WX           INFORMATION
-------  ------------    --------------
  KMI    ODD  UTC HR+20   EVEN UTC HR+20
  WOM    EVEN UTC HR+40   ODD  UTC HR+40
  WOO    EVEN UTC HR+20   ODD  UTC HR+20


                                6.6 Signal analysis module



Besides the benefits gained by memory ARQ, useful time domain
signal analysis is possible especially when coming across an
unknown signal. Time and frequency domain analysis software are
provided as an external executable program that is accessible via
a hot key from PCTOR. Acquisition of signal data is then
initiated and interfacing with the signal processing program is
relatively smooth and unintrusive.

Two graphical displays are shown. One panel shows the actual
analog signal with its software-thresholded counterpart, the
other panel shows the frequency domain (RMS power spectrum). A
software controlled cursor (using the left/right arrow keys),
allows inspection of power spectral peaks, while different levels
of magnification of the analog signal is user selectable (using
the up arrow key). Continuous conversions are performed while the
ALT key is held down. When the ALT key is up, the present state
of the graphs are frozen.

Unfortunately this type of work is only feasible on faster class
machines. A 386/25 with math co-processor or a 486 processor is a
pleasure to use. The signal processing software, however, has
been tested on a 8 Mhz XT without math co-processor where it took
several minutes to run to completion. Presently only Hercules,
EGA, and VGA display adapters are supported.

6.8 DSP modem


The advantages of DSP technology was already realized in the
PCTOR's early days. At that time both hardware and the
mathematics for applying DSP algorithms was not available.
Affordable DSP hardware and the development of DSP modem software
now makes the application of this technology very attractive.
Besides being more cost-effective than its earlier analog
counterparts, very high performance is possible. Being software
upgradable, future developments are made relatively simple.

The DSP modem firmware available for use with PCTOR is for usage
on RTTY/ASCII, AMTOR, PacTOR, and HF Packet. The modem hardware
is based on a TI 320C26 40 MHz and 14-bit codec. Communication
with the DSP is though the same RS232 port that PCTOR uses. All
firmware is downloaded to the DSP from the PC host.6.8 PCTOR upgrade history (since 2.03)


Version 2.03

1) Supports baudot and ascii receive/transmit (baudot has the
"diddle" feature). This includes the "O" and "P" options in the
main menu to change modes of operation and transmission speed
respectively. The PC's UART is used for this purpose and thus
requires signals be routed to and from the uart appropriately.

2) UTC or local time may be optionally be selected.

3) Either word-edit or character keyboard modes may be selected
(previously word-edit was standard). See the "K" option in the
main menu..

4) F4 now also terminates mode-L

5) Some minor enhancements and bugs were fixed, i.e.
- Reading the receive mask incorrectly from the .CNF file,
- Cleanup of the CR/LF sequence associated with F5 usage,
- Cleanup of the display when using a DOSSHELL (F8),
- Better validation of setup parameters from the .CNF,
- Allow the usage of "?" for help in the main menu.


6) Optional software support for a companion modem. This includes
an analog mark/space tuning display on the PCTOR status line. It
also allows future development of "soft" error detection and
correction using "memory ARQ". This development is needed to
fully support PACTOR.

7) If you are not interested in ascii/baudot operation, no
changes are needed in your RS232 hardware interface to use
version 2.03. If you are interested in using ascii/baudot,
however, please see 3.0 for additional interfacing requirements.
If you are further interested in using the software tuning
indicator display feature, the companion modem is required as
well as a parallel port interface.

8) Older versions of PCTOR (pre-1.17) used a terminate stay
resident (TSR) program, called TORBIOS. PCTOR now incorporates
all low-level routines previously performed by the TSR.

9) ALT-A "spawns" a special module for modulation analysis. This
involves taking 1024 data samples from the modem's low pass
filter stage, performing an FFT and displaying both analog and
frequency domain waveforms. This allows future development of
analysis of received audio. IMPORTANT NOTICE: Do not attempt this
function on a 8088 or 80286 type processor - it works but takes
several minutes to perform the calculations. Only a 386/25 with
co-processor or a 486/33 can do justice to this analysis. At this
time, only EGA, VGA, and Hercules compatible displays are
supported.

10) ALT-L "spawns" any program the user wishes to execute when
this key is pressed. Typically this would be a logging program.

11) The log filename and name of the ALT-L user program is
displayed on the status line.

12) There is an option to enable memory ARQ (MARQ) for AMTOR.
When active, "ERR" is displayed with a green background instead
of the usual red background when processing error blocks. The
MARQ algorithm is similar to that used for PACTOR. This first
level of memory ARQ is based on "hard bits" and will work with
any modem. It does not require the special modem. Future levels
of memory ARQ will also make use of "soft bits".

13). The help screen "ALT-H" is expanded to include an
explanation of the different flags associated with various
options.


                                        Version 2.04

14) ALT-X may now be used for quick exit (tnx SV1BDS).

15) Command.com (the dosshell) is now located through the COMSPEC
environment variable (tnx SV1BDS).

16) All files, i.e. TOR.CNF or *.TOR files are now located
through the environment variable "PCTOR" (please see 5.0 for
application notes) (tnx SV1BDS).

17) Baudot and ascii operations now echo transmitted text to the
receive screen.

18) Any baudrate not greater than 300 bps is allowed on
baudot/ascii, however, only integer values must be entered. The
amateur standard of 45.45 baud is a special case where a baudrate
of 45 will be interpreted as meant to be 45.45 bps (tnx SV1BDS).

19) The delay parameter called TX-DELAY have now been split into
two parts, TD (transmitter turn-on delay), and CD (control delay)
(for further details please see section 4.2 on customizing the
configuration file) (acknowledgement to Bill Henry, K9GWT, QST
June 1992, p.34-45).

20) PCTOR now dynamically locates a free user-interrupt slot in
the range 60h-67h. Previously 60h was hooked, however this may
have caused a problem is some instances. If there is none
available, the user will be notified and prompted, otherwise
installation will proceed as usual without any intervention.

21) The special option indicator symbols on the upper command
line started crowding the time clock digits, so they were moved
down a line to the right of the PCTOR logo.

22) The machine class (8088/86, v20/30, 80186, 80386/80486) is
detected at startup. This may be used in future versions of the
software to customize the time-critical software and available
options to be run on the hardware.


Version 2.07

23) Bug fixes in the BAUDOT/ASCII typeahead as well as changes to
the operation of the typeahead buffer in AMTOR. Please note that
all the keyboard data, the time key (ALT-T), and message buffers
(ALT-1 thru 9) will now be collected in the typeahead buffer in
the order that it was entered. This should work out better as you
will be able to mix text for transmission either from buffers,
and/or data from the keyboard without first waiting for the other
to buffer to empty out.

24) Printer log feature toggled on/off using ALT-O.

25) All traffic sent using the "send files" (ALT-F) will now also
be logged to disk.


                                       Version 2.08/9

26) Bug fixes associated with typeahead when ALT-B was used.

27) Bug fix in exception handler associated with printer OFFLINE.

28) F4, when used in ASCII/BAUDOT will terminate transmission
only when the typeahead buffer is empty.


Version 2.11

29) Does not require that DTR be connected any more. All data
output is now routed through TD.

30) Special embedded control characters 
 and  controls the PTT.
When using these, a submitted buffer will take control of the
PTT. For an example, please see "test.tor".


Version 2.12

31) When a user backspaced over more than one word in the
typeahead buffer, "WORD MODE" got confused. This bug was fixed as
well as cleaning up backspacing back to previous lines.


Version 2.13

32) Fix "getting one behind" during buffer load. Don't backspace
when buffer is empty.


Version 3.00

33) Introduce color user-definable color scheme.
34) Scroll back receive data area via disk file
35) Output signal via BOTH TxD and DTR; DTR with usual
OUTMASK option.


Version 3.01/2

36) F8 should not use closeall, but close logfile only.
37) After ALT-P, restore operating mode
38) It appears that INMASK settings that inverts DTR also
inhibits, BAUDOT/ASCII. Reset DTR setting for Baudot/ASCII


Version 3.03

39) ALT_M to access DSP modem control
40) Sort *.tor buffers alphabetically
41) ALT_S sends a file continuously
42) ALT_Y shells out to Baycom
43) ALT_D to toggle RTTY diddle
44) Two-page help screen
45) Remove INMASK/OUTMASK options

Version 3.03c

46) Restore the operating after returning from PC-PACTOR, i.e.
after usage of ALT-P.
47) Message buffers now sorted alphabetically.
48) RTTY diddle control. Selectable in the configuration file,
toggled using the ALT-D key.
49) ALT-P hot keys to PC-PACTOR.
50) ALT-Y hot keys to Baycom (note: Baycom is a copyrighted
program by DL8MBT and DG3RBU - it is not supplied as part of
the PCTOR package).
51) For users of the DSP modem, ALT-M brings up the DSP modem
submenu. The user can select a modem of RTTY, AMTOR, PacTOR, or
HF Packet.
52) ALT-S sends a file continuously.
53) Receive-only operation. This is selected from the command
line by inluding /R.6.9 Newsletter December 1992



With 1992 drawing to a conclusion, it may be worthwhile to
reflect on some things accomplished with PCTOR and contemplate
future milestones.

This newsletter will concentrate on the origins of PCTOR its
present status, and some thoughts on where things will be going
in the near future.

For those not too familiar with the software - PCTOR is a
complete communications package for the PC or close compatibles.
Its main purpose was to encode/decode AMTOR (SITOR) using the
PC's on-board hardware in conjunction with a simple external HF
modem, however rtty modes are now also supported. The interface
with the HF modem is through a COM port. A hardware TNC is thus
not required as all decoding is performed in software right on
the PC. PCTOR is available from the library 6 area of the HamNet
forum on CompuServe.

PCTOR has grown and undergone several revisions over the past
year. Presently version 2.03 is the latest. The user base has
also grown over the past year and support has come from all over
the world. I am extremely grateful for your interest and support.
As to all those suggestions and bug reports from users - your
contributions have been valuable. Some of your ideas have since
been implemented, others are in the queue.

By time that you receive this newsletter, a pre-release of my
PACTOR program for the PC will be available. This version of
PACTOR is for decoding and reading of PACTOR traffic and will
automatically decode 100/200 baud ascii or Huffman text on-the-
fly. This includes PACTOR "ARQ" and "UNPROTO" modes. Please check
CompuServe HamNet library area 6 or send me a formatted disk and
SASE mailer for a free Shareware copy.

6.8.1 PCTOR - some history.



During 1978 I met Alan G3RSP/MM, who was maritime mobile on a
tanker en route to the Persian gulf. I was then involved in
operating an rtty SELCAL station at that time with the call
ZS1HF. We had many interesting QSO's on every occasion that his
ship sailed around the Cape of Good Hope. As a result of these
contacts, I was introduced to Peter Martinez, G3PLX and his early
AMTOR developments. At that time, there was only G3PLX and G3YYD
on HF, with Alan using the ship's radio to communicate with Peter
on AMTOR.

Fortunately for me, I was using the same type of microprocessor
chip that Peter was using - the Motorola M6800. Peter supplied
the source code for AMTOR and with some further work, I was able
to decode AMTOR on my homebrew 6800 computer. Everything needed
to be made yourself - the modem, the decoder, and of course the
modifications to the HF transceiver to improve changeover time.
By the time that I had my first AMTOR QSO, I was ranked amateur
number 15 or so on HF AMTOR - just an indication how fast things
were happening.

My own experimental efforts amounted to a single board system,
complete with filter-type modem and tuning display. This system
could handle baudot, ascii (at various rates), CW with automatic
speed tracking, and AMTOR mode A, B and L. I called it a
universal communications processor (UCP). Details were published
for an amateur club project, however few systems were actually
built. This system served my needs very well for several years
and was a test bed for exploring many new ideas.

During 1983 I came to Oregon as a visiting scientist, wrote the
FCC examination, got my ticket and in due course as KC7WW, was
listening for AMTOR. I subsequently met Bill, K4PA, who was
experimenting with AMTOR as well, imagine - on a KIM
microprocessor system! Bill supplied all the specifics on getting
the necessary FCC permission to operate AMTOR in the USA. At that
time this involved obtaining special temporary authority (STA).

It was about 1984 that I learned of Paul, AD7I's Z-AMTOR, and
shortly after that commercial developments from AEA and others.
The publication of several technical articles followed.  The
introduction of the multi-mode TNC as a black box appliance
introduced many new enthusiasts to the world of digital
communications.

During 1990 I started translating the M6800 code to 8088 Assembly
language. The old hardware M6800 was just too cumbersome and
inflexible to compete with the ubiquitous PC. Making AMTOR work
on the PC's hardware was a challenge to say the least. With
modern software tools, however, things became easier to debug
than development work on the old embedded system.

The first release of PCTOR was version 1.03, which was uploaded
to CompuServe Hamnet library 6 during October 1991. It has been
updated several times since then.

It is with fond memories that I think of the early days. I am
indebted to those that helped me along the way - in appreciation
to the memory of Irv Hoff from whose work I learned about HF
modems and much appreciation to Peter Martinez who shared the
secrets of making AMTOR possible on a microprocessor.

6.8.2 The present status of PCTOR



PCTOR consists of two major components: a low-level interface
that handles critical timing at the hardware level, and a user
interface. Previously the low-level interface and user interface
was implemented as two separate modules, combining them made a
lot of sense and simplified things for new users.

The user interface follows the split screen format of operation
that has become standard for this kind of communications
operations. Data received through the software decoder is
displayed in the upper window while the operator's keyboard
entries are displayed in the lower window. In AMTOR mode, the
display of characters on the upper display is actually an echo of
what is being received at the remote station. This feedback helps
an operator judge the state of a link - how well the flow is
progressing, what has been sent already and what else is still
waiting to be sent. This is one of the built-in characteristics
of AMTOR.

Two status lines keeps the user informed of real-time operational
status of the digital translator. The main status line is on the
very top of the display. It shows, besides the link status, other
useful parameters such as path propagation delay, current
callsign and selcal, and the current status of some
user-controlled flags such as unshift-on-space (UOS),
upper/lower case operation, and high reliability. The latest
symbol that has been added is "δ", that is used to indicate
whether "memory ARQ" is active or not. More about this feature
later.

The real-time clock on the upper status line may now be
programmed in either local time or UTC.

Part of the upper status line and a small portion of the upper
split screen display is used for an on screen tuning indicator.
This option is available only when a special modem is used with
PCTOR. Details on this modem follow in the text below.

The lower status line is located between the upper text display
area and the lower text display area. It contains the name of the
user's log file, logging program's name, and shows the current
size of the user's keyboard buffer, i.e. the number of characters
in the type-ahead buffer. This logging program is a new feature
that was added to allow for the execution of a user-specified
program when ALT-L is pressed. This allows ready access to a
logging program via a hot key from PCTOR while the decoder
remains running in the background. The user, however, has to
supply his own logging program.

A general "help" function is available through the ALT-H key
where function key assignments, as well an explanation of the
indicator symbols are given.

In addition to AMTOR modes ARQ, FEQ, and "listen", ascii and
baudot is now also supported at 45.45, 50, 75, and 110 baud.
Please note that in order to use ascii and baudot, additional
interface wiring is required.

To further simplify operations, a pop-up menu system allows the
user to change some functional parameters on-line. This pop-up
menu system is complete with its own help function where all
available features that may be accessed through the pop-up menu
are listed. The latest additions to this menu are "O" and "P"
options that allows the toggling between AMTOR, baudot, and ascii
modes, and alters the baud rate for baudot or ascii modes of
operation.

In order to customize the state of options and other special
items, a user-prepared configuration file is read when PCTOR
starts up. The most recent keywords that have been added are
LOGPROG, REFR, TUNING, WORD, and MARQ. LOGPROG allows the
specification of the user's logging program. REFR sets the
refresh rate of the status displays. TUNING activates the
on-display bargraph tuning displays. WORD enables word-edit
keyboard entry mode. MARQ activates the memory ARQ algorithm.
Some of these features have been requested by users. Please note
that TUNING and MARQ assumes that special hardware is present in
the user's modem. More about this later in this newsletter.

Further general features are available. Off-the-air received
traffic may be captured in a text file. Automatic and manual
identification and time-stamping facilities are provided. Sending
of text files over the air is possible in all modes, recalling of
canned buffers, i.e. CQ call, or brag tape, for transmission, at
a keystroke.

PCTOR supports the APlink protocol for full upper and lower case
ascii. This is based on the "PLX"-method of upper/lower case with
extensions as developed by Victor Poor (W5SMM).

A "high" reliability option is included to improve received data
integrity beyond the 3/4 (zeroes/ones) ratio test used in AMTOR.

The Unshift-on-space (UOS) option have been available in earlier
versions of PCTOR. It is particularly useful for baudot
operation. This option switches the baudot case shift to upper
case at the reception of a space character. Baudot is
particularly prone to noise and often ends up in the wrong
letter/figs case shift. UOS, resets the case to letter shift each
time a space character is received. Based on the general
assumption that a space character is mostly used to separate
words, letter case is assumed. This method more often than not
will allow better print under adverse conditions. Do not be
concerned with all this case shifting if it does not make
sense.It really comes from an earlier era of mechanical
teleprinters. Most of these issues are now handled by the
software anyhow.

Baudot operators have all sorts of tricks to "help the print
along", especially when conditions are marginal. The baudot
"diddle" is one of them. This amounts to sending "idle"
characters when the keyboard buffer is empty. These idle
characters are carefully chosen to be either the ITA2 characters
letter, figures, or in some cases "blank". PCTOR uses diddle in
baudot mode.

As mentioned above, a new modem with special features has been
under development for usage with PCTOR. This development was
essential to support new modes such as PACTOR. At the same time,
however PCTOR's performance was enhanced through the use of
sophisticated digital signal analysis. This modem is not a
digital signal processing unit, however it is quite sophisticated
and a good performer. The hardware lineup consists of a
highpass/lowpass front end, bi-quad discriminator, active
rectification, and low pass filter optimized for 200 Hz
modulation rate. An 8-bit A/D convertor is included that is used
by the software for analyzing recovered modulation signal in the
memory ARQ algorithm. A ten element bargraph display is provided
as a tuning indicator. Further details of the modem, and its
availability in kit form, will be published shortly.

Memory ARQ is an algorithm for intelligent error correction
during ARQ (PCTOR has an option that allows AMTOR to make use of
it as well). Briefly, during reception of AMTOR data blocks, the
algorithm saves not only logical states of bits from the modem's
slicer stage, but also saves the actual magnitude of the
recovered modulation signal levels associated with each bit. This
additional information thus indicates a confidence level
associated with each logic level. When two or more blocks are in
error, the algorithm proceeds to examine the confidence levels of
individual bits for possible "reconstruction" of a good block
from erroneous blocks. The actual details of the algorithm is
somewhat more complex than this brief introduction.

Besides the benefits gained by memory ARQ, useful time domain
signal analysis is possible especially when coming across an
unknown signal. Time and frequency domain analysis software are
provided as an external executable program that is accessible via
a hot key from PCTOR. Acquisition of signal data is then
initiated and interfacing with the signal processing program is
relatively smooth and unintrusive.

Two graphical displays are shown. One panel shows the actual
analog signal with its thresholded counterpart, the other panel
shows the frequency domain (RMS power spectrum). A software
controlled cursor (using the left/right arrow keys), allows
inspection of power spectral peaks, while different levels of
magnification of the analog signal is user selectable (using the
up arrow key). Continuous conversions are performed while the ALT
key is held down. When the ALT key is up, the present state of
the graphs are frozen.

Unfortunately this type of work is only feasible on faster class
machines. A 386/25 with math co-processor or a 486 processor is a
pleasure to use. The signal processing software, however, has
been tested on a 8 Mhz XT without math co-processor where it took
several minutes to run to completion. Presently only Hercules,
EGA, and VGA display adapters are supported.



6.8.3 Future developments



The modem development is in final stages of printed circuit
layout. The details will be appearing shortly in one of the
amateur or electronic hobbyist journals. A kit of parts will be
also offered.

There has been several requests for PACTOR capability. This will
be the next major upgrade. Although I have been experimenting and
testing PACTOR, the special modem was required to implement true
memory ARQ. Without the A/D convertor addition, true memory ARQ
is not possible, regardless of what you may have been told by
others. If you have wondered of what PACTOR is like - my
experience has been that it is really fun to operate when
conditions are good. If you have ever tried HF packet, PACTOR is
a great improvement. However, when conditions are marginal,
performance degrades rapidly, delays become uncomfortably long,
and not even memory ARQ seem to be of much use. This is where you
wish that it could have reverted to AMTOR. I am of the opinion
that it may become popular with some higher powered
traffic-handling stations. This is, however, my own opinion.

Several requests were for the inclusion of embedded control
functions in text files. For example: a user wants to send an
automatic CQ while contesting: A text file is prepared that
contains the body of the CQ message including some special
control functions. The text file is submitted for transmission in
a similar same way than a buffer message is sent. The following
pseudocode shows the procedure.



Script submission for automatic transmission

1)  START:
2)        <initiate FEC transmission>
3)        CQ CONTEST DE KC7WW KC7WW (KCWW)
4)        CQ CONTEST DE KC7WW KC7WW (KCWW)
5)        AR PSE ARQ KN
6)        <terminate FEC transmission>
7)        <wait for an ARQ link (timeout=30 seconds)>
8)        <if it timed out> go back to START
9)        <cancel automatic mode and enter normal keyboard mode>

Note: F7 flushes the text buffer, F10  forces standby mode.

This simple example shows several kinds of control symbols, i.e.
LABELS, start/stop FEC transmission, and wait with timeout - a
branch address for timeout is supplied. A small language set to
support some of PCTOR's built-in features will be developed. The
script will be parsed for syntax and semantics before actual
submission occurs.


There have been several requests for running PCTOR in a
multitasking environment. This is of course possible, given that
PCTOR has guaranteed one millisecond interrupt rate for low level
services. Although this timing requirement hardly impacts
performance on a 386 or 486 type machine, it is unfortunate that
some of the popular multitaskers require the same hardware that
PCTOR uses for their pre-emptive scheduling. In the end someone
usually looses out. Windows 3.1 on the other hand, being a
co-operative multitasker, does tolerate this kind of intervention
but is not considered "well behaved". It is uncertain what future
versions of Windows will allow. It will be logical to develop a
DLL that contains the low level services as an embedded device
driver that will guarantee such high priority interrupts. The
PCTOR user interface will then be using the familiar Windows CUA
format.

I apologize for the inadequacies of the documentation, especially
for newcomers to the digital modes. It is my impression that most
new users either had some earlier experience with AMTOR, or was
very knowledgeable and capable of putting together all the
required bits and pieces. There appears to be a lack of the
basics for AMTOR, but also what these signals sound like. So,
this is perhaps one area that hopefully could be improved. It
also appears that a complete bibliography for reference purposes
would be helpful.

The inclusion of more digital signal processing is a possibility.
Not only could we benefit from noise reduction algorithms but
also from DSP modems that has been tailored for optimum
performance. This approach uses software to adapt filter
parameters and usually results in really sharp filters. An
external dedicated DSP approach, or perhaps a low-cost sound
board could be used. This kind of development is very
challenging, yet holds promise for the future.

The baudot and ascii mode presently lacks "autostart" and "anti-
space" facilities. If anyone is interested in these features,
digital equivalents are possible that works quite well.

Work on PCTOR has always been a challenge and very rewarding. The
order that features are implemented is dictated mostly by what
available time I have at hand, the hardware requirements, and
often doing the fun things first. A lot of time is also spent on
improving things, often fine tuning the time-critical parts, or
fixing irritating bugs.

Should there perhaps be something that you consider needing
attention, please let me know and we can see what could be done
about it.

To contact me, you may leave an e-mail message for me on
CompuServe (70730,3472), or leave a message at WA8DRZ via packet
or Aplink.

                KC7WW @ WA8DRZ.#NOCAL.CA.USA

If all else fails - write to me at the address below.

6.10    1993 Newsletter


This newsletter is to update registered users and those
interested in PCTOR and PC-PACTOR on developments during 1993.
Some background will be discussed and future trends also
presented.

I thank those from whom I have heard over the past year. Your
contributions and support are always greatly appreciated.



       ┼ This issue of the newsletter is dedicated in memory
       of Pim Woest, PA3AGG. Pim was one of the first to
       experiment with PCTOR - he became a silent key on
       January 31st, 1993. We will miss him.



Newsletter Summary:

1. PCTOR
2. PC-PACTOR
3. HF Modem Developments
4. Future Enhancements



1. PCTOR

What is it? For those not too familiar with the software: PCTOR
is a complete amateur radio communications package for the PC or
close compa-tibles for operating AMTOR (SITOR), RTTY, and ASCII.
An external HF modem is required to convert received audio to COM
port signals (RS232 levels). As decoding is performed in software
right on the PC, there is no need for a hardware TNC.

The 1992 newsletter covered software up to version 2.03 (included
in PCTOR documentation). PCTOR has grown and undergone several
revisions over the past year. Versions 2.04 - 2.08 included
several bug fixes and improvements for a cleaner interface with
DOS.

When the HF analog modem, AN-93, became available, memory ARQ for
AMTOR and an on-screen tuning display, was added (please see
section 3 on: HF modems).

Version 3.0 introduced a scrollable receive display and user-
definable screen colors.

Version 3.03 is currently under development. It includes support
for a new DSP modem and allows "hot keys" to operate PC-PACTOR or
HF packet from PCTOR. Additional features for customization of
the startup file includes selection of the operating mode and
baud rate. For SWL listeners, transmit features may now be
disabled and the receive screen extended to fully use the
additional display lines.

There has been considerable confusion over which RS232 signals
are used to transmit data. This came about in an effort to
simplify the hardware interface: It was found that AMTOR could
use the "break" mechanism to send data through the "Td" line.
This simplified the interface to four lines, i.e. Rd/DCD - for
input signals, and Td/RTS for output signals. Unfortunately, this
did not work with some older serial ports. For compatibility
sake, both Td and DTR was then made available for data output.
When the DSP project came along, DTR was needed for DSP control.
That is why version 3.03 now only supports serial ports that can
switch data fast enough through Td.


2. PC-PACTOR


What is it? PC-PACTOR is a program for the PC to decode, read and
transmit PACTOR traffic. It will automatically decode 100/200
baud ASCII or Huffman-compressed text.

Version 0.03 was released in December 1992 for monitoring PacTOR
traffic only. I have since had a lot of requests for a full
transmit version of the program. The current version of PC-PACTOR
is 0.16 and includes the ASCII FEC transmit capability, traffic
logging and file transmission. Version 0.20 is presently under
development for full ARQ capability.

I do ask your patience as there are some major implementation
issues to be solved. First is to achieve the 15ppm timing
requirement. The PC clock was never designed for this kind of
accuracy.

PacTOR is based on a proprietary standard developed by SCS,
Germany. In order to receive support from SCS, a license fee has
to be paid. Presently, this is why all other amateur radio
implementations of PacTOR are licensed. SCS, however, gave
permission to develop a Shareware version but indicated that no
support would be available.

Things went fairly smooth during development until it became
clear that there are a number of undocumented exceptions that
needed clarification. To date I have not been able to obtain all
the necessary details from SCS to resolve these outstanding
issues. I will persist, however, in pursuing these on my own,
though it may take a little longer.

Please note that version numbers below 1.00 indicates
"experimental" status and should be considered that.

3. HF Modem Developments


Due to numerous requests for a simple yet good performing HF
modem for use with PCTOR and PC-PACTOR, the AN-93 was developed.
The design is a conservative active filter approach using 170 Hz
shift with 2125/2295 Hz tones for data rates to 200 baud. The
unit is intended for direct FSK operation. The computer interface
is through a serial port that is compatible with PCTOR.

A 10-segment bargraph display is provided for tuning purposes. In
addition, an A/D convertor is provided that samples recovered
modulation for  implementation of soft memory ARQ by the PC. In
addition, the A/D signal is used for an on-screen tuning display.
The A/D convertor interfaces to the PC through a parallel port
interface.

To those interested, there still remains a few AN-93 kits still
at $135 plus postage.

A considerable amount of effort was spent on studying DSP math,
algorithms, and hardware. This led to the development of a
prototype DSP unit for HF digital. A small production of these
units followed. This was known as the DSP-100 project. Although
an excellent performer, the unit proved to be overly complex and
expensive. After all, it appears that the software TNC approach
is attractive because of its low cost.

Further DSP developments using a $99 evaluation module from Texas
Instruments, called the "DSK" (DSP Starter's Kit) proved very
promising. The DSK is based on a 40 MHz 320C26 DSP chip and
includes a 44kHz, 14 bit A/D convertor.

DSP applications developed for PCTOR now includes high
performance HF modems for RTTY, AMTOR, PacTOR, and HF packet. The
DSK shares the serial port with PCTOR. User-selected modems are
downloaded from the PC to the DSK's on-chip memory at a 115200
baud.

Some valid concern has been expressed about the "delay"
introduced by such a DSP and subsequent timing issues. This delay
time is known as "group delay" and is the due to the time taken
for digital data to ripple through the DSP's shift registers. I
have measured this delay to be approximately 7mS longer than the
AN-93. This has not yet proved to be a problem for me, but if it
does, there are ways to reduce the group delay.

Which is better - the AN-93 analog or the DSP unit? A unit such
as the AN-93 is very good at what it is designed for, however,
when attempting to make it work at too wide a range of baud
rates, some compromise is necessary. In such a case, versatility
is often traded for ultimate performance. The DSP algorithms on
the other hand, are customized for the application at hand and is
expected to deliver uncompromized performance.

The implementation of very efficient filters is a further
advantage of the DSP approach. The modems used in this
application uses 80th order FIR filters, has outstanding
selectivity, and good dynamic range.

It is expected that in time, further digital modem code will
become available in conjunction with yet newer modes. All that
would be required is new DSP code and decoding software on the
PC.



4. Future enhancements


The most-requested enhancement appears to be for a full PacTOR
implementation. This will receive very high priority.

The script processor for PCTOR remains to be further developed.
This feature will allow the user to embed control characters in
submitted text. These control characters will allow execution of
"test and branch" dependant on internal status variables and
allow "looping" constructs. This would allow special operations,
such as needed for contest mode.

Both hardware and software developments using DSP will continue.
The DSK code may eventually be ported to a PC Soundcard as DSP-
based Soundcard technology reaches maturity. There already are
innovative applications for CW, SSTV, and WEFAX for Soundcards.
The prohibitive cost of development software remains a problem.
The DSK will be used in the meantime.

There are plans for development of a new mode based on ideas from
MIL-STD-188-110. The new mode is expected to fill the need for
more robustness than PacTOR with data between 75 and 300 bps
suitable for HF networking. DSP modems will be used to implement
m-ary modulation at low baud rate, higher bit rates are achieved
by transmission of multiple bits per baud. This new mode will
rely on error-correction techniques to achieve coding gain and
robustness.

A draft of specifications will be available in the near future
and will be submitted to various peer forums for input. Those
interested in participating on this project, please contact me.

7.0 Disclaimer



The author, Johan Forrer KC7WW is not responsible for any damage,
injury, loss of profit or gain associated with the use,
installation, or application of this software.



November 1993
J.B.Forrer KC7WW
26553 Priceview Drive
Monroe, OR 97456
United States of America



e-mail: [e-mail]
CompuServe: 70730,3472