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 (This is new in 75a and is REQUIRED)
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 APRSSYSTEMIinitTAPR.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 APRSSYSTEMVALID.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 HSPBUGS.HTM which is now on the distro disk.
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]
ERROR 6 - Math Overflow [Some glitched packets..
ERROR 7 - Out of Memory
ERROR 14 - Out of String space [Usually not enough conventional RAM]
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.