TROUBLE.TXT       TROUBLESHOOTING GUIDE
===========================================================================
Document version: 8.4.0
Document dated:   3 May 99
Author(s):        Bob Bruninga, WB4APR <bruninga@nadn.navy.mil>
ABSTRACT
TROUBLE.TXT       Guide to APRS troubleshooting:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

INSTALLATION:  Did you use PKUNZIP -d to get all the following subdirectories?
                   SYSTEM    (must have INITTAPR.TNC and RESTORE.TNC)
                   MAPS      (Must have at least WORLD or USA map)
                   BAKS
                   LOGS
                   HSTS
                   README
                   MAPLISTS 

PC VIDEO: Did you get an immediate error 5?  THis is usually because your
PC may be using a non-standard video card, such as a Hercules.  To make it
CGA compatible run the utility SIMCGA /P or the other one HGCIBM /E.

TNC-TYPE:  There are two basic types of TNC, the TAPR-2 clones and the
AEA products.  THey display received packets differently.  APRSdos is
written around the TAPR-2 types such as TINY-2, MFJ, Kantronics, etc.
All AEA packets are first converted into TAPR format within APRSdos, that
is why it needs to know what type of TNC you are using.
One CAUTION:  THe AEA PK80 is a TAPR-2 standard TNC, so if you use the
PK80, then do *not* answer AEA as your type of TNC...

POWER-SAVER:  Are you using an HT with a "power-saver"?  This causes the
radio to sleep for 90% of every second.  It will wake up for a voice QSO,
but it will rarely wake up fast enough to get the first 100% of a packet.
Thus, you are missing 90% of everything on the air.

CONFIGURATION:  Did you answer all menu prompts with SINGLE keys where
applicable?  This was the #1 problem found in Nov 97 for all prior
versions.  In otherwords, answering type of TNC with AEA instead of A
caused APRS to not see the "A".

OPERATION:  Is your receiver volume set high enough so that the DCD lamp
on the TNC lights whenever there is received data?

RECEPTION:  Verify reception by observing the DCD lamp whenever data is
heard.  If the data is strong enough, and ERROR-FREE, then it will be
displayed on the bottom line of the display.  Verify proper decoding by
observing the L and P lists for collection of packets from other stations.

TRANSMISSION:  Hit the XMIT-POS or XMIT-CQ command to force your system
to transmit.  Within a second or so, and after the channel is clear, your
transmitter should key up for about a second.

VERIFY COMMS BETEEN YOUR PC AND TNC:  Do an OPS-COMM-TNC to verify proper
serial interface to your TNC.  Hit ENTER and verify that you see the TNC
cmd: prompt.  If OK, then your serial PORT and TNC are communicating.  Hit
ESC to return to the program.  Do NOT type any commands to the cmd: prompt
because there are 100's of commands, each one of which can screw up the TNC!
APRS initializes your TNC using the commands in APRS\SYSTEM\IinitTAPR.TNC
or InitAEA.TNC.

VERIFY PROPER DATA FORMATS:  Using the OPS-COMM-TNC command, observe
received packets.  They should appear in approximately the following format:

   W3XYZ>APRS,WIDE:@123456/.......etc

The WIDE represents a list of digipeaters, but nothing else should be in the
received packet header other than the FROM call, APRS, digipeaters, and then
the COLON: that begins the data.  The data must be on the same line as the
header.  If not, set HEADERLINE OFF.  If any other stuff is being inserted
into the monitored packet, use your TNC manual to turn off all other monitoring
features.  If your TNC needs any special set up parameters, add them to the
InitTAPR or InitAEA.TNC files.


BAD COMMS BETWEEN PC AND TNC:  If there appears to be no data going to or from
the TNC and there is no cmd: prompt in the OPS-COMM-TNC mode, then stay in the
OPS-COMM-TNC mode and do a power cycle on the TNC power.  You should get a
RESET of the TNC and see several lines of initialization text.  If you do,
then ESC back to the program and do an alt-SETUP-TNC command to have the
program initialize the TNC parameters.  If there is still no data, then check
your serial port cables.  If You see characters but they are garbled, check
your TNC parity commands.

PARITY:  The MFJ and other standard TAPR TNC's need PARITY 0, but the
KAM needs PARITY 4.  We found a KPC-2 that needed PAR 3.  Keep trying!

AEA PRODUCTS:  Since some of the AEA setup commands are different than the
standard, you must tell APRS that you are using an AEA so that it will use
the commands in InitAEA.TNC.  Also, the AEA monitor format is different.
In some early models of the PK-12, the monitor function was not correct.
If you add the command BBSMSGS ON to the InitAEA.TNC file, then the PK-12
will emulate the standard TAPR monitoring function and work properly.

DISCONNECTED:  APRS periodically sends a D command to the TNC to be sure
that it is disconnected.  You will frequently see the TNC response saying
TNC is DISCONNECTED.  This is NORMAL!

TNC NOT RESPONDING:  Every time APRS sends a command to the TNC, it checks
to see if it got a cmd: response.  If not, it displays the warning "TNC
not responding".  If you see this warning ALL the TIME, then something is
wrong with the TNC mode or interface.  You will see this warning frequencly
whenever there is lots of data on the channel and APRS misses the cmd: in
the middle of all the traffic.  In this case, ignore the warning.

CAN'T VALIDATE:  If APRS cannot find the APRS\SYSTEM\VALID.sys file, then
it bombs out of the alt-S-SAVE routine without properly asking for
your validation number.

WRONG DIGIPATHS:  If you are using the /XX path specifier in your SEND
messages, then you must accept some missrouted packets.  This is because
the UNPROTO path is not assigned by the TNC until the instant the packet
is transmited.  Even though APRS wrote the correct PATH at the time it
set the packet to the TNC, if the channel is busy, then the packet may be
transmitted some time later and it will use whatever UNPROTO path is then
in the TNC at that instant.  To mitigate this problem somewhat, APRS will
add 5 seconds of dead time each time it changes the UNPROTO path.  There is
also a BIG problem with acks.  This is why this alternate path feature
should be used with caution.  See  NO ACKS.

NO ACKS:  Nothing you can do about it.  The other station's path must be
set to hit you, period.  If you are sending multiple messages in multiple
directions, then you have a problem if/when the other stations respond.
Your acks to their responses will ONLY got to your default DIGIPATH!  So
YOU must watch EACH incomming MESSAGE and decide if you need to change your
UNPROTO path to hit them.  For this reason, in general, only send alt-path
messages to un-attended or inactive stations.  Keep your main path set to
everyone with whom you are having a dialog.

HSP PROBLEMS:  Use the O-C-T mode to check out the HSP switch.  While
in O-C-T mode with your TNC, the F8 key will toggle the HSP switch
between the GPS and the TNC.  Also PacComm has written a file called
HSP-bugs.txt which is now included below.

CRASH ERROR CODES: The error codes are standard BASIC error codes.  Here
are the common ones for APRS:
   ERROR 5  - Illegal Function Call [Usually an incompatible video card at
                                     start-up.  Other times can be ANYTHING.
                                     Try to capture the offending packet
   ERROR 6  - Math Overflow         [Some bad formatted packets..  Try to
                                     capture the bad packet and send it in
   ERROR 7  - Out of Memory
   ERROR 14 - Out of String space   [Usually not enough conventional RAM]
   ERROR 55 - File Already Open
   ERROR 61 - Disk Full             [Check your LOG and HSTS directories]
   ERROR 68 - Device not available  [Usually your COMM port is missing  ]
                                    [or WINDOWS stole it.  Boot to DOS...]
   ERROR 71 - Disk Not ready

OCCASSIONAL LOCKUPS:  It has been reported that older PC's with the old
16450 UART serial ports somehow occassionaly get locked up.  The newer
16550 UART serial ports have some built in buffering that seems to work
much better.  (BUT! see following comments...)

COMPAQ LAPTOP:  One person found that his NEW 486 laptop (AER) 4/33)
with the new 16550 UARTs would lock up.  He found that running the
setup program and setting COMFIFO 1 OFF solved his problems.

MORE 16550 LOCKUPS:  It is now generally known that there are lots of BAD
16550 chips out there.  If your system occasionally locks up when using the
HSP or ULTIMETER-2000, or just your TNC, then first, turn FIFO off in your
setups.  If that doesnt work, then run program contained in SMC.ZIP which
is purportedly a FIX for some of the bad 16550 problems.  YOu can find it
on @tapr.org in the /tapr/SIG/aprssig/upload directory.


HSP-bugs.txt 7.3a        APRS HSP Port Switch

     If You Have Difficulty Getting the APRS Port Switch to Work
There are two common problems to look for: The unit is not getting
power or the GPS signals are at too low a level.

Use a voltmeter to determine if there is DC Voltage coming in from
either the PC connector pin 6 or the TNC connector pin 6. If not,
check for another pin on the PC or TNC which can provide 6-12 VDC
and change the cable wiring accordingly.

If power is not available from the PC or TNC, then a 9 Volt battery
may be connected to supply power between Pin 6 (+) and Pin 5 (-) of
the RS-232 (PC) connector. This is also a good way to get the unit
operating initially after trouble is experienced.

    The other most likely cause of problems is inadequate drive in the
positive direction from the GPS receiver. In some cases, DTR is always
a little too high and this is the next most likely cause of trouble.
The circuit works only on positive going signals. The GPS data output
is fed through a 1k resistor and must have adequate drive capability
to get at least 0.7V on the base of transistor TR3 in order to turn
it on. This is normally the case, but SOME GPS receivers don't seem
to do this. Adding a 4k7 resistor between the data input and pin 6
of either the TNC or computer port of the adapter should provide enough
pull-up to make it work. The series 1k resistor on the GPS input cannot
be lowered in  value because TR4 is used to hard clamp the data and
would short circuit the GPS output.....

     DTR is used to switch the circuit between data sources. This needs
to go at least 1.2V POSITIVE when the circuit is in the TNC mode.
On some computers the low state was still too high and would cause
TR4 to remain turned on all the time, thereby preventing any GPS data
to be gathered. A simplistic fix to this was to add a second diode
in line with DD5 and thereby drop 0.7V. A better fix would be to vary
the value of RD9 up a little.

    Troubleshooting is performed by using APRS in HSP mode. Select Ops-
Comm-TNC to see TNC data (O-C-T).   Use the F8 key to toggle the HSP
switch.  The OPS-COMM-GPS command is for dual-port TNC's but will also
toggle the HSP switch to the GPS data.
over.

        Revision History for PacComm APRS Port Switch Units.

ECN 97 11/30/94: Add a 1N914 diode is series with D7 to work better
with GPS inputs that have minimal negative voltage swing.

ECN 103 3/13/95: Connect Pin 6 of the TNC connector to Pin 6 of the
PC connector to provide an additional source of supply voltage for
computers with no wiring to Pin 6. PacComm TNCs provide +5 VDC on
pin 6.

HECN 104 3/16/95: Change RD8 from 1k to 4.7k to improve TR2 switching
reliability.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Gwyn Reedy, W1BEL      gwyn@paccomm.com        W1BEL@amsat.org
(813) 874-2980        Fax:+(813) 872-8696     BBS: +(813) 874-3078 (V.34)
PacComm Packet Radio Systems, Inc, 4413 N. Hesperides St, Tampa, FL 33614-7618

