WIDEn-N DIGIPEATER SETTINGS KANTRONICS KPC-3 (VER 8.2 or newer), or KPC-3 Plus (any version eeprom)
Revised April 2007 (latest changes in RED)

• BLT: The BLT parameter controls the timing of when the LT buffers are sent. We can control how often the buffers are sent, and also when they start.
  • BLT 1 E 00:30:00 START 00:00:00 Here we are setting BLT 1 up so that the TNC sends LT 1 (a position report) once every 30 minutes at the top and bottom of the hour.
  • BLT 2 E 00:30:00 START 00:00:10 CLEAR Here we are setting BLT 2 up so that the TNC sends LT 2 (weather data) once every 30 minutes at 10 seconds after the minute. This will ensure that the wx data persists on the D7 and D700 screens. The CLEAR parameter clears the LT buffer as soon as the buffer is sent. If the buffer is empty, nothing will be sent. This keeps us from sending stale data if something happens to the incoming weather data stream from the weather station.
  • BLT 3 E 00:30:00 START 00:15:00 Here we are setting BLT 3 up so that the TNC sends LT 3 (a position report) once every 30 minutes at 15 minutes past the hour, and then again at 45 minutes past the hour.
  • BLT 4 E 00:30:00 START 00:15:10 CLEAR Here we are setting BLT 4 up so that the TNC sends LT 4 (a weather report) once every 30 minutes at 10 seconds after the minute. This will ensure that the wx data persists on the D7 and D700 screens. The CLEAR parameter clears the LT buffer as soon as the buffer is sent. If the buffer is empty, nothing will be sent. This keeps us from sending stale data if something happens to the incoming weather data stream from the weather station.
    
• GPSHEAD: You determine which weather string will be stored in the LT buffer by entering the string header with the GPSHEAD command. The TNC searches for specific strings of data from the weather unit and stores it in the LT buffer.
  
• LT: LT buffer 2 and 4 are filled with weather data which is captured by the GPSHEAD routine. The other LT buffers are programmed with position data. They contain an APRS position packet that describes the location of the digipeater, and also contains some descriptive information. We can include information that describes the configuration of the digipeater. In the packet below, we are letting users know that the digipeater supports the WIDEn-N paradigm, and also statewide paths with the "S' overlay character. We also indicate the WIDEn-N capabilities, and the local suggested number of hops with the 'W2'. 'WAn' tells users that the digipeater is part of the Washington digipeater network, and supports WAn-N. Following that is descriptive text for the location, followed by the assigned callsign of the digipeater control operator. With approximately 85% of the mobile stations with display capability being the Kenwood TH-D7a and TM-D700, it's a good idea to format the text to fit their screens. The TH-D7a display will show two lines of 10 characters. The TM-D700 will display two lines of 10 characters and one line of 8 characters. Information of most importance to mobiles should appear in the first 20 characters. Positionless weather data should be sent after the position report to allow Kenwood radios to display the weather data. PHG and comment text is displayed in the same area as WX data. If we send weather data then position data, the weather data is overwritten by the PHG and comment text. It is very important to include a callsign here if you are using a descriptive alias in the MYCALL parameter.

  All current versions of APRS support the OVERLAY character feature on some symbols. This feature is encouraged all of the APRS digipeater sites. To use an overlay character, just insert it in place of the "/" that separates the LAT/LONG in the LT lines as follows:
  L if using the paradigm settings but NOT supporting SSn-N
  S if using the paradigm settings and also supporting SSn-N
  1 if OK'd to enable home station WIDEn-N digipeater using WIDE1-1 (very rare use only)

  • LT 1 !4720.20NS12320.45W#PHG5660/W2,WAn,WillapaValley WA7RW

• TH-D7a W2,WAn,Wil lapaValley

  TM-D700 W2,WAn,Wil lapaValley  WA7RW

• LTP: The LTP parameter tells the TNC where to send the LT buffers. Each LT buffer can be sent to different destinations if so desired. Since in the APRS concept, objects that are further away are of less importance that objects that are closer, we can tailor the output of the digipeater so that we tell users close by about the digipeater often. Users further away get informed less often, and users even further get informed even less. This is done by the combined effects of the BLT and LTP parameters. Remember that packets originated from a digipeater effectively get an extra hop since they start out from a digipeater. Local users sending via WIDE2-2 hit the digi for their first hop. The second hop is acted upon by the next layer of digis. When packets are originated by a digi, the first hop is acted upon by the same digis one layer out that were handling the user packets as a second hop. The digipeater originated packets in effect get an extra hop.
  • LTP 1 APN390 VIA WIDE2-2 This sets a destination address with two hop enabled. This combined with the BLT 1 timing makes this position packet go out the desired distance at the top and bottom of the hour.
  • LTP 2 APN390 VIA WIDE2-2 This sets a destination address with two hops enabled. This combined with the BLT 2 timing makes this weather packet go out the desired distance ten seconds after the top and bottom of the hour.
  • LTP 3 APN390 VIA WIDE2-1 This sets a destination address with one hop enabled. This combined with the BLT 3 timing makes this position packet go out the desired distance at 15 and 45 minutes after the hour.
  • LTP 4 APN390 VIA WIDE2-1 This sets a destination address with one hop enabled. This combined with the BLT 4 timing makes this weather packet go out the desired distance at ten seconds after 15 and 45 minutes after the hour.
    
• MYCALL: The NWAPRS group suggests that a descriptive alias be used rather than a callsign. When the MYCALL is substituted into a packet, it is easier for the end user to see where packet has been. It is easier to figure out where a packet has been when the list shows KOPEAK,SIGNAL,MOXIE*, rather than WA7RW,N3EG-10,KC7WFD-10. Just remember to include the control operator callsign in the LT buffer if you use a descriptive alias to stay legal.
  
• UNPROTO: This sets the destination address and path that any UI packets ORIGINATED from this station follow. In this configuration only the BEACON packets will follow this path.
  • APN Network nodes, digis, etc
  • APN3xx Kantronics KPC-3 rom versions (ver 8.2=APN382, ver 8.3=APN383, ver 9.0=APN390)
  • APN9xx Kantronics KPC-9612 Roms
  • APNAxx WB6ZSU's APRServe
  • APNMxx MJF TNC roms
  • APNPxx Paccom TNC roms
  • APNDxx DIGI_NED
  • APNUxx UIdigi
    
• UIDIGI: This routine allows up to 4 aliases to implement simple callsign substitution digipeating. UIDIGI implements a rudimentary anti-duping routine. The TNC will check to see if this packet originated from or has already been digipeated by itself by looking for its MYCALL anywhere in the packet. Because the UIDIGI routine is run before UIFLOOD and UITRACE, we can use UIDIGI to trap paths that are considered abusive. By including the high value WIDEn-N aliases here, we still digipeat the user's packet once, but it gets marked as complete, and will not activate any more digipeaters.
  • UIDIGI ON WIDE4-4,WIDE5-5,WIDE6-6
  • If you have a KPC-3 v8.2 TNC with release xxxx-7265 or earlier, as many of you have, you need to set:
    
    UIDIGI ON WIDE1-1,WIDE4-4,WIDE5-5,WIDE6-6
    
    You can check the version of TNC firmware by connecting to the TNC, and issuing the command: Version
    
    The TNC will respond with something like this:
    
    KPC3-3F427265-8.2
    
    Where:
    
    XXXX-XXXX7265 v8.2
    
    is the important part to check. Any version of 8.2 prior to and including 7265 exhibit this bug.
    
    These versions of firmware have a small bug in the UITRACE routine that can be overcome by changing the UIDIGI setting.
    
    The bug causes the TNC to insert it's callsign has-been-digipeated bit set on the name of the digipeater instead of on the used up WIDE1 path.
    
    You can find evidence of the bug when monitoring the RF stream
    
    Incorrect behavior looks like this: KOPEAK*,WIDE1,WIDE2-2
    Proper behavior looks like this: KOPEAK,WIDE1*,WIDE2-2
    
    This bug does not appear in any version of the KPC-3+ firmware.
    
• UIFLOOD: This routine used to support the old WIDEn-N alias. It is now being used to implement the SSn-N alias. The ID tag is now enabled to allow limited tracing of digipeater paths. The 30 parameter sets the time that a packet checksum is kept in memory to eliminate duplicates. The anti-duping routine used here is totally separate from the one used by UIDIGI. A GPS equipped Mobile running with position reports every 15 seconds will not get blocked by this, as the packet payload has changed.
  • UIFLOOD WA,30,ID
    
• UITRACE: This routine used to support the old TRACEn-N alias. It is now being used to implement the WIDEn-N alias. This allows full tracing of digipeater paths. The 30 parameter sets the time that a packet checksum is kept in memory to eliminate duplicates. The anti-duping routine used here is totally separate from the one used by UIDIGI. A GPS equipped Mobile running with position reports every 15 seconds will not get blocked by this, as the packet payload has changed.
  • UITRACE WIDE,30
    
• GPSPORT: This field sets up the TNC DE-9 radio port (pins 2 and 5) to accept data from a connected weather station. This allows the DB-25 port to remain open for connection to a computer. You'll need to know the port data rate which the weather data is transmitted, usually 2400 or 4800 baud.
  • GPSPORT 2400 NORMAL NOCHECK
    
• GPSHEAD: This field allows the weather data flowing from the weather station into the corresponding LT buffers for transmission. The weather data only needs to fill two buffers, LT 2 and LT 4.