4/20/04 -Borrowed from SOCAL APRS kc0bs
The major content for this page comes from the SoCal APRS group
The table below outlines the "quick 'n dirty" settings. Read the following text for the more detailed information.
|
Station Type |
Digipeater Path |
Position Timing |
Beacon Timing |
Notes |
| Home Stations | WIDE2-1 or named digipeater path. | 30-45 minutes | 30-45 minutes or greater. |
Try to set the first station in your path to a wide you know you can hit. EX: APRS V k0ham-10, wide2-1 Do not set your station to digipeat WIDE or WIDEn-N |
| Weather Stations | WIDE2-1, or named digipeater path | 30 minutes or as conditions dictate. | IF you are a member of the Citizens Weather reporting Group, NWS can use reports every 5 minutes. Consider putting your WX station on 446.175 | This frequency allows for higher beacon rates.
Data will be fed to the NWS via Igates in Independence & Shawnee. |
| Mobile Stations | WIDE2-1 or if necessary WIDE2-2
or insert "WIDE1-1" WIDE1-1,WIDE2-1 |
0-5 Watts: 1-2 minutes
5+ Watts: 5 Minutes |
15-30 minutes* | Some TNC's allow you to set different rates for moving/stationary modes,
see your TNC manual.
Use of WIDE1-1 may work against you in rural areas, and reduce your area of transmission. See text below. *Use "Beacon After" setting, rather than "Beacon Every" Consider using the shorter $GPGLL string for position reports. Turn digipeating off, unless helping to fill in for an Event D700 path does not require APRS first like ui view does Example D700 path: "WIDE1-1,WIDE2-1" |
| Special Event Stations | If localized event, use WIDE1-1, or a named digipeater. | Varies with event. | Varies. | For small events, consider installing a temporary digi for the event. Or moving APRS traffic to another frequency if many trackers - sending posits every minute or less - are involved. Please limit pre-event testing on 144.390 MHz to short periods of time. |
All Stations should set CWID OFF, HID OFF and any "node" commands disabled (Ka-Node, The-Net, Netrom, etc)
Radio Parameters: Make sure that your radio is operating properly, and is on frequency. Don't send excessive speaker audio to your TNC, as this causes the demodulator to overload, and your packets won't decode.
TNC Parameters: Set transmitter deviation to approximately 3 KHz. This can be done by ear, on most TNC's by putting the TNC into constant transmit mode, and sending "flags" (see your manual - this is usually called the "Calibrate" mode). While listening on another receiver, adjust the TNC's transmitter audio output until the audio sounds distorted. Then decrease this -by ear- to 1/2 the volume. This should get you close. Please consider using a dummy load on your transmitter when doing this.
A note on TNC timing, be sure to use the fastest TXD values that you know will work with your radio. Also check the FRACK setting (don't use PERSIST or PPERSIST timing) on the TNC. Most are set to a value of 4 and this usually needs to be more aggressive in the KCAPRS network.
To see the timing parameters in your TNC, and what they are set at, enter the command mode on your TNC, and then enter disp t (for "Display Timing) as below:
cmd:disp t <return>
If you don't understand the TNC's timing parameters, then it's time to crack that manual. Note that the parameters that have to do with the "connected" state are not important for APRS - as all APRS features, including messaging, happen in an un-connected state.
If you have to set your transmitter preamble timing (TXD or similar commands) to 50 or more for your packets to be digipeated, then you have a radio or TNC integration problem. Values of 30 to 45 (0.3 to 0.45 seconds) should be adequate.
Use true-DCD circuits or commands, so that you can run the radio "open squelch" into your TNC.
All High level digis in the Area respond to WIDE1-1, WIDE2-2, WIDE3-3, and block anything larger
Home stations should set their path to WIDE2-1.
Mobile Stations should set their path to WIDE1-1,WIDE2-1, or in rural areas to WIDE1-1, WIDE2-2
Please do not use GATE in your path. This was used to gate long distance 300 baud HF data to 1200 baud VHF data. Obviously when going the other way (VHF to HF) this would very quickly clog the HF channel virtually crippling it so NO data would get through. With the proliferation of the internet, iGATEs, and the aprs.net data stream, the HF mode to carry long distance APRS data is very quickly becoming obsolete.
Additional info on keeping the network healthy is available at Bob Bruninga's page
If you are using the messaging feature in APRS, between known stations (and by the map, you should know exactly where they are) use the above recommendation of naming and selecting the digipeaters (if any!) so you can send a message to a friend just 3 miles away without digipeating that message over an unnecessarily large area.
If you can communicate directly, or just through one digipeater, then change your path accordingly. Message traffic bouncing between three or more digipeaters, when not needed, clogs the network, and sometimes just creates more packet collisions, and can delay your message traffic. Really! I'm not making this up :-)
Note that when using WIDE1-1 or WIDEn-N in your path, you have little control (actually, no control) of where your packet traverses!
Mobile Stations: This really should be set based on your transmitter output power. Low power transmitters (1-3 watts ERP) can beacon once every minute, as most of their packets will collide with by the stronger stations, and never heard. Stations running 10-25+ watts ERP should send a packet once every 5 minutes, as a great majority of these will get through (at 60 MPH this still gives you 5 mile resolution). This can be more aggressive in rural areas, but please set timing accordingly when you are in the "metro" area and in view of many digipeaters.
Additionally, stationary mobiles should relax or halt their position reporting rate. Some TNC's have the ability to do this, and there are some hardware solutions that have been presented to the NE KS/NW MO APRS list previously.
Also, make sure that your system is actually working. I know this sounds, strange, but many times I have seen some TNC sending wrong, or "blank" GPS data -for days on end- because either the GPS was not on, connected, or the GPS was not receiving any satellites. These packets have many "commas" in them where numbers should be and they look like this:
KD0KQ-9>WIDE2>APRS:$GPGGA,,,,,,0,2,,,,,,,*54
If you are not running APRS software to monitor the network, you can use the www.findu.com site to see what your packets look like, and see if your mobile tracker is posting correctly. ie: map.findu.com/k0tvi-14
If you don't actively monitor your tracker, please consider putting your email address in your beacon text so someone can notify you if there's a technical problem.
Also, if you have a choice in which GPS string to transmit, and you don't want to broadcast your altitude, direction, speed and the temperature of that margarita you're trying to balance on your dashboard to any CHP officer that has internet access, consider using the $GPGLL string. This has minimal information, and results in a shorter packet that's much less apt to be "corrupted" by noise and other users on the channel.
Home Stations: Or any object that does not move - should not send position packets in less than 30 minute - or greater- increments. These are stations that, by definition, do not move and they carry little information other than "here I am".
Weather Stations: This is usually up to the operator. I use 15 minutes on mine, with alternating paths. During severe or unusual weather conditions, some operators could send their weather packets out more frequently. This also applies to stations running Direction Finding equipment, or other telemetry uses.
I won't go into all of the areas that are required to set-up and manage a digipeater, but here are a few suggestions:
The GATE was designed to route APRS position reports one way - from HF to VHF, and provide a two-way gateway for messaging. Stations on VHF running 1200 baud should never GATE position reports to 300 baud HF because this ties up and potentially overloads the 300 baud HF channel. Naturally, exceptions are made for weather, and other special purpose stations. To GATE from HF to VHF is OK, and in fact encouraged.
As the station below demonstrates, it has GATE in it's path, and since the attached GPS did not have lock, it sent several packets onto the HF network that carried no position information. In the second example, not only GATE but a path of WIDE5-5 is being used. Yikes.
K19RCT-9>WIDE1-1*>WIDE3>GATE>APRS:$GPGGA,,,,,,0,2,,,,,,,*54
NB1W>K1GIL-1*>WIDE5-5>GATE>3TUQST:'-\ml#Qu/]"<+}With student
Note that in many areas of the country, HF Gateway activity has been entirely replaced by iGATES, the Internet Gateway stations.
iGATE's automatically keep track of stations in the network, and when messaging, all one has to do is make sure that the iGATE can hear your packet. If your message is "un-acked" locally, the iGATE will find out if the destination station has been heard on the Internet. If so, your packet will then be routed to the area in which that station was last heard in.
Note that you do not have to do anything "special" to your path to have the benefit of the iGATE's... other than make sure your packets are being heard by that gateway (perhaps changing the path so that your packet gets digipeated by the digi that's closest to the iGATE).
ID's: The "HID" setting in your TNC should be set to "OFF" All your packets are ID tagged when they leave your TNC, and they stay that way throughout the path. Additionally, the "HID" packet will also follow whatever path you have set up. This is redundant ID information that clogs the network.
Also CWID should ALWAYS be set to off. The FCC does not require it, and it also eats up channel time - at least locally - as this is incapable of being digipeated.
Note that some of the APRS software packages now set HID to OFF so that you, the diligent operator does not have to worry about it.
An example of a "HID" packet: W1CSP-14*>WIDE3-1>ID:W1CSP-14/R WIDE/D W1CSP-1/B
Also note the above packet. The operator has set his digipeater to digipeat anything with a WIDE digipeat designation. Now his station - his MOBILE station - will now digipeat WIDE designated packets. This can act as a "black hole" digipeating a packet at low-level, that was really meant for a high-level digipeater station. This also applies if you enable your home station to respond to WIDEn-N digipeating.
Similarly, NET/ROM, KA-NODE, WILDnode, etc. digipeating/routing, should be turned off on your TNC.
A "bulletin" packet should not convey information of a purely generic nature. Many APRS programs alarm or beep when these messages are received. Information such as major traffic problems, fires, earthquake info, band openings, and even sometimes - meetings are A-OK. Please think before you send these out, especially using a long path (WIDE5-5) that covers hundreds, perhaps thousands of miles.
WA0XYZ-1>K0TVI-1*>WIDE5-2>APRS::BLNA :Welcome to Podunk! World's largest ball of yarn.
WA0XYZ-1>K0TVI-1*>WIDE5-1>APRS::BLNB :Happy Holidays... Please set path to WIDE2-1.