5/19/02 - KD6KQ
(Note: The callsigns appearing herein have been changed to protect the semi-innocent)
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-2 or named digipeater path. | 30-45 minutes | 30-45 minutes or greater. | Avoid the use of RELAY in your path.
Consider disabling RELAY as a digipeater alias if not needed in your local area. Do not set your station to digipeat WIDE or WIDEn-N |
| Mobile Stations | WIDE2-2 or if necessary WIDE3-3
or insert "RELAY" RELAY,WIDE2-2 |
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 RELAY 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. |
| Weather Stations | WIDE2-2, or named digipeater path | 10-15 minutes or as conditions dictate. | ~30 minutes | Unusual weather conditions allow for higher beacon rates, and longer
digipeater paths.
Make sure that your station and APRS clock offsets are correct. |
| 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 SoCal 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.
The use of RELAY and WIDE as an "alias" by high level digipeaters in the So. Cal area has been widely discouraged for a number of years now. Digipeaters that support these aliases, by definition, are "dumb" and will digipeat anything that they receive with these paths inserted.
The biggest problem with RELAY and WIDE (as opposed to the WIDEn-N system below) is that the digipeaters do not keep track of which packets have been digipeated, and this can lead to packets "ping-ponging" between two or more digipeater stations.
RELAY, while NOT supported on most of the hilltops, is supported in most - if not all, of the home stations. This is normally set by the APRS software you are running at home. The idea behind home stations running RELAY, is that if your mobile tracker path was set to RELAY,WIDE2-2, that if you were not near (or not heard by) the hilltop station that supported WIDEn-N digipeating, then the home station would, of course, RELAY you.
If you set up your path this way, (using RELAY) a home station MUST hear and "relay" your packet before you can be heard - and digipeated - by the high-level digi.
RELAY should NEVER-EVER be used in anything but the first place in the path. If a hilltop digipeated RELAY, then hundreds of low-level home stations would attempt to digipeat that packet. Similarly, if you live in an area that is high in altitude, or well-served by local stations, I would inhibit RELAY digipeating in your home station - as I have in mine.
One word of caution. If you are "in the boondocks" and you have RELAY in your path, and a home station isn't nearby to hear your packet, you can be right under a WIDEn-N digipeater and YOU WILL NOT BE DIGIPEATED. Consider dropping the use of RELAY in your mobile tracker's path.
For obvious reasons, mobile stations should never support RELAY, WIDE, or WIDEn-N digipeating. Setting DIGIPEAT OFF (or DIGIPEAT 0 - - zero) in most TNC's the initial default values will take care of this.
For most mobile stations, a path of RELAY,WIDE2-2 should get you into the digipeater of choice and a couple of hilltop stations and into one or more internet gateways. In most areas of SoCal, a path of simply WIDE2-2 or WIDE3-3 (dropping the use of RELAY) is more than enough.
For home stations, there is RARELY a reason to use RELAY at all. With 10W+ ERP you should be able to get into one (and usually, lots more) of the hilltop digipeaters. A path of WIDE2-2 should be more than sufficient. In fact, you can select the digipeaters by naming them in your path - instead of WIDE2-2, enter N6EX-1,WB6JAR-10, etc.
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.
The "WIDEn-N" protocol is now used in the SoCal network. This is where you would set WIDE3-3 as the path to use, and as your packet transverses the system, each digipeater would subtract the last numeric until your packet looked like WIDE3.
Each number is always the same as you enter it as your path. (ie: WIDE1-1 for one digipeater hop, WIDE2-2 for two hops, and so-on)
The main "system wide" benefit of WIDEn-N digipeating, is that it usually avoids the same packet being digipeated twice by the same digipeater.
Note that THE RECOMMENDED PATH IS WIDE2-2. Based on the channel loading, and the availability of high-level digipeaters and internet gateways, I would suggest that using WIDE4-4 and above is abuse in our network.
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 RELAY 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 California 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:
KD6KQ-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/k6tvi-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>RELAY*>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. While WIDE is not used in So. Cal (except by a couple of high level digipeaters) 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.
WA6XYZ-1>K6TVI-1*>WIDE5-2>APRS::BLNA :Welcome to Podunk! World's largest ball of yarn.
WA6XYZ-1>K6TVI-1*>WIDE5-1>APRS::BLNB :Happy Holidays... Please set path to WIDE2-2.
2) I-15 from Elsinore to Valley Center.
3) I-10 & 60 Fwy from Yucaipa to roughly Cathedral City.
4) I-5 from Grapevine to just north of Castaic (tnx Dave, ad7db)
5) Highway 395 north of Olancha. Don't know how far north this extends but would assume APRS coverage would pick up again around the Topaz Lake area by the Nevada/California state line.
6) Highway 152 between I-5 and Gilroy (tnx Steve, kf6wax)
Note: If anyone has information for sites to add coverage to these areas, please email me: k6tvi.
Also, if you find a dead area, let me know: k6tvi
APRS Protocol Specification Version 1.0.1 (pdf format 4.0, 3.2MB)
Digipeater Overlay file:
Latest APRS Digipeater Overlay file
FCC Database:
FCC Database (72MB download!) that works with Win/MacAPRS version 2.4.4/3.4.4 or later and Xastir version 0.1.3 and later. Check your documentation for specifics on using this data!
Join the California APRS Mailing list:
There is a mailing list that covers APRS use in California. Please feel free to join the list and take part in the discussions. This is NOT to be confused with the Nationwide TAPR mailing list, which some feel has too much activity on it - and little to do with operating in Southern California.
 |
This RingSurf APRS Webring Net Ring owned by Southern California APRS Guidelines. [ Skip Next | Next 5 | Random | List Sites | Join] |
|
Last Updated September 16, 2005
k6tvi