The following settings are used to set up an KPC3 tnc as a standard digi or remote wx digi. Note that these settings also work on a KPC3+ tnc. Its highly recommened that you use at least version 8.2 firmware in either the KPC3 or KPC3+. The latest firmware for the KPC3+ , version 8.3, isnt required. No benefits will be seen by using version 8.3 in a KPC3+. If your tnc has it, use it. I just wanted to let you know that you wont need to upgrade to 8.3 in a KPC3+ thats being used as a digi. Also shown below is the "added" commands to set up a remote wx stn on a Kantronics digi. A more complete discussion about UIxxxx commands used by Kantronics tncs is also included at the end of these settings. Thoughts: Since the KPC3 tnc contains GPS buffers, I recommend that you use the functionality of these buffers to send your position text via different paths. You dont have to do this, but if you choose to do so, the TNC can beacon its position up to 5 different paths. Place the fixed position beacon text in the LT buffers: LT 1 !3617.23NN11850.23W#PHG5860/A=005726/ Blue Ridge Digi LT 2 !3617.23NN11850.23W#PHG5860/A=005726/ Blue Ridge Digi LT 3 !3617.23NN11850.23W#PHG5860/A=005726/ Blue Ridge Digi LT 4 !3617.23NN11850.23W#PHG5860/A=005726/ Blue Ridge Digi Choose paths you want each of the numbered buffers to travel: these are just examples that worked in my area in 1998. LTP 1 APRS VIA NORTH LTP 2 APRS VIA SOUTH LTP 3 APRS VIA WR6ABD,WB6NFY-3,WIDE LTP 4 APRS VIA WORM,WA6YLB-3,W6APA,WIDE,WIDE Now decide how often each of these numbered paths will be sent. Note - the TNC will send the LT buffers if BLT is activated, and there is something in the LT buffer itself. If the LT buffer is empty, nothing is sent. The time specified is HH:MM:SS in the format. BLT 1 EVERY 00:19:00 BLT 2 EVERY 00:21:00 BLT 3 EVERY 00:22:00 BLT 4 EVERY 00:20:15 You can set up the normal beacon stuff using Btext, Unproto, and Beacon commands. Note: APRSdos uses the data contained in Btext as the "latest" data as seen on the L page. I recommend that you use some "real verbage" in this buffer such as I use here. Email addresses are good ideas too. BTEXT Aprs digi on Blue Ridge, 26 miles east of Visalia @ 5726 ft. Next set up a path you want the Btext to travel. UNPROTO APRS VIA WIDE Now how often do you want the Beacon text to be sent: BEACON EVERY 20 Here are the special APRS commands used by version 8.2 software. They are not in Version 6.0 for KPC3. UIDigi sets the aliases for the digi to respond to. Version 8.2 firmware does a callsign swapping with MYCALL when one of these aliases are digipeated. More discussion of UIdigi, UIflood, and UItrace is included in the bottom of this text file. UIDIGI ON WIDE,RELAY,TRACE,LOCAL UIFLOOD WIDE,30,ID <- or WIDE,30,NOID UITRACE TRACE,30 Ctext and CMSG are settings to handle when someone connects to the MYCALL of the digi. As an alternative to CMSG DISC, CMSG PBBS will connect the user to the packet mail box in the tnc. I've done this before and left a detailed message about the digi etc, as a message to ALL. See you manual for PBBS settings. CTEXT not a node. for more info, email wa6ylb at theworks.com CMSG DISC Abaud isnt used in a standard digi setup. If your running a remote Wx stn, then set this to 2400 baud (typically for a Peet Wx stn). ABAUD 2400 AX25L2V2 ON <- should be on. CD INTERNAL <- alternative setting is CD SOFTWARE. CONOK ON <- kinda useful to have on if you ever want to connect to the digi. HID OFF <- turn off the ID beacon. Not needed by APRS at all. DAYTIME 981130212900 <-set your clock once the digi is installed. Will allow timestamps. DIGIPEAT ON <- really important to have on. INTFACE TERMINAL <- in a regular DIGI leave as Terminal. In remote Wx, use GPS. MYALIAS BLUE <- dont place any of the common aprs aliases here. Some versions <- of KPC firmware allowed the myalias to have priority digipeating <- of the MYalias callsign over the same callsign as listed in UIDIGI. <- the MYALIAS callsign doesnt do callsign swapping with MYCALL upon <- digipeating. MYCALL WA6YLB-2 <- callsign you want displayed on APRS maps. MYNODE WA6YLB-7 <- filled in by default when you fire up the tnc after a reset. change to <- suit. MYPBBS WA6YLB-13 <- default callsign. MYREMOTE BLUER <- callsign used here to remote connect to the digi to change settings <- while the digi is on the hill running. If you need to preserve your <- regular callsigns and SSID's, use an alias here. RETRY 15 <- doesnt hurt to set connect retrys to max value. TXDELAY 35 <- (350 msec) Try upping this value if your rig is a slow synthesized one. <- the extra time helps rigs receiving your signals if their slow to open <- their squelch circuits. Rtext Mary had a little lamb <- insert a text into Rtext so you may type in a password to gain <- access. When connecting to MYREMOTE callsign, the TNC will respond <- with three lines of six numbers. cmd:*** CONNECTED to callsign of MYREMOTE 2 8 2 3 8 6 1 3 4 4 4 4 2 3 8 4 2 1 <- There is a relationship between the <- numbers and the values of the letters. <- for example: <- Mary had a little lamb <- 1111111111222 <- 1234567890123456789012 <- You see that M in Mary is character 1, and the space between little and <- lamb is character 18. You need to make sure the case you reply in matches <- the Rtext you inputted. In case of character 1, M is correct where m is not. <- all the answers must be from the only one of the three lines of numbers. <- if you choose the third line, then select answers to match the requested <- characters. Space is a valid character. Dont add spaces between characters. XMITOK ON <- needs to be on. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Commands related to operation of a remote wx stn on this same digi. Basically the setup matches the above settings but a couple of settings are a little different. First off, you must make sure the baud rate is set up on the TNC serial port to match the baud rate of the remote Wx stn. ABAUD 2400 <- typical setting for Peet wx stns. Next we will be useing the GPS function built into the TNC to "capture" the raw data from the Wx stn and place it into one (or more) LT buffers. INT GPS <- was INT TERM in a regular digi. The TNC needs to know what kind of ascii string of data will be sent from the Wx stn, so it may match it, and then load the LT buffer. I personally use the Peet Wx stn "Packet" mode of wx data. The Peet station outputs a data string that starts with $ULTW followed by 52 more ascii characters. In the installation of the WA6YLB-4 wx digi [see http://www.theworks.com/~wa6ylb/wa6ylb4.htm] I set up two of the four LT buffers to capture the wx stn data and left two of the LT buffers alone, holding the position text. APRS needs to see a position packet for the raw data once in a while, else the station wont show up on a map. Set up the LT buffers as so: LT 1 !3617.23NN11850.23W_PHG5860/A=005726/ Blue Ridge WX Digi LT 2 LT 3 !3617.23NN11850.23W_PHG5860/A=005726/ Blue Ridge WX Digi LT 4 The LT 2 and LT 4 buffers will be filled in by the TNC using the GPSHEAD command GPSHEAD 2 $ULTW <- make sure you use Upper case for matching text. GPSHEAD 4 $ULTW GPShead 1 and 3 are not used, and you should leave them blank. If there is a character in them that matches data from the Wx stn, the WX stn data will over lay the position string you left in LT 1 and 3. Next set your BLT timers to send the posits and raw wx data at different times. BLT 1 EVERY 00:30:00 <- position packet - not needed often BLT 2 EVERY 00:04:45 <- this buffer sends raw data more often. BLT 3 EVERY 00:22:00 <- position packet - not needed often BLT 4 EVERY 00:04:50 <- this buffer sends raw data more often. I group the LT buffers into twos, with the same path as the data. LTP 1 APRS VIA WR6ABD,W6CX-3,WB6NFY-3 LTP 2 APRS VIA WR6ABD,W6CX-3,WB6NFY-3 LTP 3 APRS VIA K6IXA-3,W6UR-3,W6APA LTP 4 APRS VIA K6IXA-3,W6UR-3,W6APA The idea in the above scheme is to send a position packet along the same path as the raw wx station data travels. Set the Btext and Unproto, etc, as shown for a standard digi above. When the TNC is turned off then back on, the TNC will be looking for Wx data from the Wx stn. The Peet station only sends data to the TNC [in Packet mode] once every five minutes. This is why I send the data just before every five minutes. Packet mode has the data in it for 1 minute wind reading as well as max gust over the last five minutes. -------------------------------------------------------------------------- Version 8.2 Firmware Update Advanced GPS/APRS Digipeating Overview of new digipeating commands The following are new commands that support advanced GPS/APRS digipeating capabilities. The UIDIGI command may be used to set up to four additional aliases/call signs for "special" digipeating service. To-be-digipeated packets received containing one of these aliases will be repeated (once) with the call sign (MYCALL) of the digipeater substituted for the alias in the digipeated frame. See the example shown below and the command description for more detail. UIFLOOD and UITRACE are a bit more exotic. Each provides for multi-hop digipeating with just one digipeater address per packet, thereby keeping the transmission time short. For example, to digipeat through three TNCs supporting the UIFLOOD command, the reporting station might set a GPS position path as follows: LTP 1 GPS via wide3-3. (LTP is a path for a GPS beacon to take) A digipeater TNC supporting "wide" set by the UNIFLOOD command and hearing the reporting station's transmission would then digi the Ul location packet (assuming it had not done so already, within a preset time), using an address of wide3-2. In turn each similar digipeater down line would digi the reporting station's Ul packet and reduce (decrement) the ssid of the digipeater address again. A TNC using UIFLOOD has the option of inserting MYCALL, creating two rather than one digipeater addresses in each transmitted digi packet. With UITRACE, each time a packet is digipeated, each TNC adds its MYCALL, thus creating a "trace" or return path. In effect, the size of the packet grows by one digipeated address with each hop. Again, see the examples below and the command descriptions for detail. The current setting of UIDWAIT determines whether or not a delay is added to UI digipeat packets (those formed by UIDIGI, UIFLOOD, or UITRACE) before transmission, once the channel is clear. If UIDWAIT is ON, the delay is determined by slottime or persist settings. The purpose of the UIGATE (which is in muilti-port devices only) is to prevent heavy high speed UI frame activity front congesting ("flooding") the low speed (port 1) frequency. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Examples of New "UI" Digipeat Commands in Action The following are actual monitored outputs of a lab system consisting of one position reporting station and three digipeaters, where each digi is configured using the UIDIGI, UIFLOOD, or UITRACE command and where UIDWAIT is set ON. We set UIDWAIT ON to force the system to digipeat all or most of the Ul frames without collision. In all examples, the reporting station, NOGRG, is used to launch a Ul packet with the path set by the UNPROTO command. With UIDWAIT OFF, several digipeaters would transmit at the same time, resulting in corrupted packets. In actual on-the-air use, a system of digipeaters may work well with UIDWAIT OFF, depending upon their mix of location and transmitter power. In actual use, GPS/APRS (mobile) reporting stations would set their path with the LTP command. (4 separate paths a gps beacon could take). Configuring three digis using the UIDIGI command: Here, three digis, with MYCALLs of A, B, and C, are configured with aliases of RELAY, WIDE, and TRACE (using UIDIGI); and UIDWAIT is set ON. For example station A's UIDIGI aliases are set as follows: cmd: UIDIGI ON RELAY, WIDE, TRACE The reporting station path is then set to GPS via RELAY, WIDE, TRACE, and a Ul packet is launched. Any one of the stations monitoring will then display the resulting action as follows: cmd:NOGRG>GPS,RELAY,WIDE,TRACE: :5 NOGRG>GPS,B*,WIDE,TRACE: :5 NOGRG>GPS,A*,WIDE,TRACE: :5 NOGRG>GPS,B,A*,TRACE: :5 NOGRG>GPS,A,B*,TRACE: :5 NOGRG>GPS,C*,WIDE,TRACE: :5 NOGRG>GPS,B,C*,TRACE: :5 NOGRG>GPS,A,C*,TRACE: :5 NOGRG>GPS,B,A,C*: :5 NOGRG>GPS,A,B,C*: :5 NOGRG>GPS,C,A*,TRACE: :5 NOGRG>GPS,B,C,A*: :5 NOGRG>GPS,C,B*,TRACE: :5 NOGRG>GPS,A,C,B*: :5 NOGRG>GPS,C,A,B*: :5 NOGRG>GPS,C,B,A*: :5 All digis hear the first Ul frame and store it. Due to the setting of UIDWAIT, some stations may wait longer than others to digipeat; hence, when they do, they may have several frames stored up - for example, the original and a digipeat from another station. Trace station B as an example. It digipeats the original Ul frame from the "reporting station," swapping its MYCALL for RELAY (B) and marking it (*), then repeats a frame from A and one from C, and, finally, repeats two more (from A,C and C,A) - a total of five! Note that each repeater digis five times so the total number of digipeated packets is 15! Configuring three digis using the UIFLOOD command Here, three digis, with MYCALLs of A, B, and C, are configured with an alias of WIDE, and UIDWAIT is set ON. For example station A's UIFLOOD call is set as follows: cmd: UIFLOOD wide,30,ID The reporting station path is then set to GPS via WIDE4-4, and a UI packet is launched. Any one of the stations monitoring will then display the resulting action as follows: NOGRG>GPS,WIDE4-4: :5 NOGRG>GPS,A*,WIDE4-3: :5 NOGRG>GPS,B*,WIDE4-3: :5 NOGRG>GPS,C*,WIDE4-3: :5 Note that all three digis see the Ul frame addressed to GPS via WIDE4-4. They then, in turn digipeat that frame, inserting and marking as digipeated (*) their MYCALL, and include the new to- be-digipeated and decremented field of WIDE4-3. Note that each digi hears the UI frames repeated by the others but does not digipeat those in turn since a timeout of 30 seconds was specified by the UIFLOOD command. See the command specification for details. Configuring three digis using the UITRACE command Here, three digis, with MYCALLs of A, B, and C, are configured with an alias of TRACE; and UIDWAIT is set ON. For example station A's UITRACE alias is set as follows: cmd: UITRACE TRACE The reporting station path is then set to GPS via TRACE4-4, and a UI packet is launched. Any one of the stations monitoring will then display the resulting action as follows: cmd:NOGRG>GPS,TRACE4-4: :5 NOGRG>GPS,B*,TRACE4-3: :5 NOGRG>GPS,A*,TRACE4-3: :5 NOGRG>GPS,B,A*,TRACE4-2: :5 NOGRG>GPS,C*,TRACE4-3: :5 NOGRG>GPS,B,C*,TRACE4-2: :5 NOGRG>GPS,A,C*,TRACE4-2: :5 NOGRG>GPS,B,A,C*,TRACE4-1: :5 NOGRG>GPS,C,A*,TRACE4-2: :5 NOGRG>GPS,B,C,A*,TRACE4-1: :5 NOGRG>GPS,A,B*,TRACE4-2: :5 NOGRG>GPS,C,B*,TRACE4-2: :5 NOGRG>GPS,A,C,B*,TRACE4-1: :5 NOGRG>GPS,C,A,B*,TRACE4-1: :5 NOGRG>GPS,C,B,A*,TRACE4-1: :5 NOGRG>GPS,A,B,C*,TRACE4-1: :5 All digis hear tile first UI frame and store it. Due to the setting of UIDWAIT, some stations may wait longer than others to digipeat; hence, when they do, they may have several frames stored up - for example, the original and a digipeat from another station. Trace station B as an example. It digis first, decrementing the TRACE address to TRACE4-3; however, it does not digi again until nine UI frames later, when it repeats a digi from A and decrements TRACE to TRACE4-2. Since there are only three digipeaters in our example system, TRACE4-1 is the last digi address noted. Command Reference: Digipeating Commands Version 8.2 adds four digipeater commands for the single port TNCs (KPC-3Plus and KPC-3) and five digipeater commands for the multi-port TNCs (KPC9612 Plus and KPC-9612). Note: Digipeater priority for call signs is as follows: MYCALL, MYNODE, MYALIAS, UIDIGI, UIFLOOD, UITRACE (e.g. if you assign the same call sign to MYALIAS and UIDIGI, a to-be-digipeated frame with that call sign will be digipeated according to the rules that apply to MYALIAS.) UIdigi ON [+|-] call1[,call2[,call3[,call4l]] * * Multi-port command on multi-port devices default OFF NONE/OFF NONE Up to 4 call signs can be specified for special digipeater duty. If any of the UIDIGI calls appears in the to-be-digipeated field of a UI packet, and if MYCALL does not appear in the source field or any of the has-been-digipeated fields, the UIDIGI call in the to-be-digipeated field will be replaced by MYCALL with the H bit set and the packet will be digipeated. See also: dwait, persist, uidwait, unproto UIDWAIT [ON | OFF] * * Multi-port command on multi-port devices default OFF/OFF When UIDWAIT is OFF, "special" digipeat packets (those formed by UIDIGI, UIFLOOD, or UITRACE only) have their usual channel access; that is, there is no wait DWAIT or slottime added before transmission once the channel is clear. However, if UIDWAIT is set ON, the packets awaiting to be digipeated will be subject to the same wait times as not-to-be-digipeated packets awaiting transmission. By subjecting "special" to-be-digipeated packets to a delay determined by slottime and persist, it is more likely that to-be-digipeated packets of two or or more stations in the same vicinity would not collide. This may be good if one wants to guarantee that a digipeated packet will "make it out" of its neighborhood but bad if one wishes to limit the number of times a packet is redigipeated, such as in APRS applications. See also: dwait, persist, UIDWAIT UIFLOOD name, n,[ID | NOID] (name= 5 char max) (n=0-255) * * Multi-port command on multi-port devices default disabled,30,NOID/disabled,O,NOID When a UI frame is received with a call in the to-be-digipeated field of the form 4 'name'x-y where x is a number (1-7) appended to 'name' and y is a ssid (1 -7), the ssid is decrement and the UI frame is digipeated without setting the H bit. When the packet is digipeated, a checksum is formed over the source, destination, and data fields of the packet. This checksum is kept for n seconds (0-255). If an incoming UI packet is eligible for digipeatiiig as above, but its checksum matches one of those being saved, the packet is discarded (not digipeated). The buffer holds a maximum of 64 checksums. If the optional parameter ID is selected, the MYCALL call sign is inserted in an additional digipeater address field with its H bit set. See also: uidwait UIGAte ON |OFF * * This multi-port command is only present in multi-port devices. default OFF/OFF The purpose of this command is to prevent heavy high speed UI frame activity from congesting ("flooding") the low speed port (port 1) frequency. (300 baud port) UI packets with a to-be-digipeated address of MYGATE that enter a port with UIGATE ON will be digipeated out the other port. If UIGATE is OFF for a port, UI packets with a to-be-digipeated address of MYGATE entering that port will be discarded. See also: digipeat, mygate UITRACE name * Multi-port command on multi-port devices default disabled/disabled When a Ul frame is received with a call in the to-be-digipeated field of t he form 'name'x-y where x is a number (1 - 7) appended to 'name' and y is a ssid (1 - 7), and MYCALL does not appear in the source field or any of the has-been-digipeated fields, MYCALL with the H bit set is inserted before the to-be-digipeated field, the ssid of the to-be-digipeated field is decremented, and the UI frame is digipeated without setting the H bit of the to-be-digipeated field. If the packet should already have 8 digipeater fields, MYCALL is not inserted. See also: dwait, persist, uidwait