TROUBLE.TXT TROUBLESHOOTING GUIDE =========================================================================== Document version: 8.4.0 Document dated: 3 May 99 Author(s): Bob Bruninga, WB4APR 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