DP Tool Club 31/CDASC_31_1996_juillet_aout.iso/vrac/aprtrak.zip/README/TROUBLE.TXT

Text File | 1995-09-01 | 6KB | 105 lines

TROUBLESHOOTING GUIDE ver 73a

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
COMMANDS:  All APRS commands are single keys.  The commands are usually
spelled out but only the first letter of each command word is needed.

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 OPS-PING 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 DOESNT WORK!  In version 73a, you can now 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 on the distro disk.