TEMP Digipeating for SAR and other Activities

Bottom line - your D700 or D710 mobile should have TEMP configured as one of the digipeater aliases.

-----

Yes position reporting is perfect for SAR, but what most Hams are not training for is text messaging too. APRS text messaging provides the ability to do AD-HOC comms ANYWHERE and beyond simplex range.

You can extend the range of any APRS HT (for text comms and positions) as far as you want with mobile D700/D710 radios. (I was suprised to see that the FTM-350 does not appear to digipeat?). AD-HOC Rnage extension of packet is far easier than setting up an AD-HOC voice repeater for wilderness coverage.

Yes, a mobile D700/D710 can also serve as a voice cross band repeater, but only one hop. With DIGIPEATING, the range can be extended indefinately by additional mobiles. AND ALL D700/D710 mobile should already be fully configured for always-on digipeating via TEMPn-N, so as long as there are D700's at the event, text messaging should work as far as they travel.

If every D700/710 you know of is not configured this way, why not!??? Who will help make it happen if not you. (I think the D710 digipeater defaults to TEMPn-N enabled.

All SAR teams have to do is use the path TEMP3-3 or so to go three hops back to HQ via ANY availalbe D700/710. Try it next time you are simplex-near a D710...

SAR teams and other Ham response groups should include text messaging (and TEMPn-N mobile digis) as a routine COMMS RANGE EXTENDER in wilderness terrain and practice its use!. See www.aprs.org/TEMPn-N.html

Bob, WB4APR

IGates on Default APRS-IS User-Defined Port

The javAPRSSrvr sysops (aprs.net core servers and aprs2.net servers) use port 14580 as a user-defined filter port (no default filter). If no filter is applied by the client, it functions properly for IGates (maintains a last-heard list for the client and performs proper message and related posit passing in addition to any messages and related posits for the logged in client). A filter is not needed for proper IGate operation and will make your IGate software use much less resources than a full feed simply because there will be very few packets your IGate will have to process.

Adding filters is best suited for GUI clients because you want to see more than just what you might see on RF. Standalone and non-GUI IGates are best used on a user-defined port as you describe (port 14580) with no filter specified. This will provide proper IGate operation while minimizing impact on your system and your bandwidth to the Internet.

Hope this helps.

73,

Pete AE5PL
pete at ae5pl dot net

UI-View32 Meteor Mode

Hunting meteors with APRS is an interesting twist. Here's some info from the manual of UI-View32

UI-View32 Meteor Mode is a special mode in which the program can be used to transmit beacon frames very frequently. It is designed to be used for meteor scatter propagation tests.

Two different modes of operation are possible - "Interval" mode and "Burst" mode.

• Interval Mode - A single beacon frame is transmitted at a specified time interval.
  
  
• Burst Mode - Beacon frames are transmitted continuously for a period of seconds. You can specify how long the burst should be, and when you want it to start in terms of the number of seconds into each minute
  .
• Port - The port on which you wish to use Meteor Mode.
  
  
• Unproto address - The address to which you want to send the beacon frames, including any digis. The destination address and digis should be separated with commas, do not used 'V' or 'VIA'. Examples - CQ would address the beacon frames to CQ, CQ,RELAY would address the beacons to CQ via RELAY.
  
  
• Beacon - The text of the beacon you want to send. For meteor scatter use, the beacon should be as short as possible. The shortest beacon that can usefully be interpreted by APRS software is probably your IARU locator surrounded by square brackets, e.g. "[IO92XX]", and that is the beacon you are recommended to use.
  
  

NOTE - The following four automatic beacon input buttons cannot be used until you have input your latitude and longitude in Station Setup.

• Grid - Automatically input a grid square beacon.
  
  
• Grid-in-status - Automatically input an APRS "grid in status" format position beacon.
  
  
• Posit - Automatically input a normal APRS position beacon.
  
  
• Comp'd - Automatically input a compressed APRS position beacon.
  
  
• Interval (only used in Interval mode) - The interval, in seconds, at which you wish to transmit a single beacon.
  
  
• Start (only used in Burst mode) - The number of seconds into each minute at which you want the burst of beacon frames to start. You can specify more than one time, e.g. "0,30" would mean "start a burst at 0 seconds into each minute and another burst at 30 seconds into each minute". If you were conducting a trial with someone, then they might specify "15,45", so that your transmissions interleaved.
  
  
• Duration (only used in Burst mode) - The length in seconds of each burst of frames. UI-View converts the specified duration into a number of frames to send. The calculation is accurate, but it makes two assumptions - (a) that you are using 1200 baud, and (b) that your TNC will transmit continuously when fed with a stream of frames. If your TNC releases the PTT every few frames (the TH-D7 appears to behave in this way.), then you will need to make allowances for it, because a specified duration of, say, 10 seconds, will result in an actual burst length of perhaps 15 seconds.

History and Working of Wide1-1,WideN-1

Under the current "New Paradigm" standards, WIDE1-1 IS treated differently from higher orders of N-N

The whole WIDE1-1, WIDE2-1 construct was invented (it was my proposal years ago) to work around the "brain-dead" firmware limitations in Kantronics KPC3 TNCs. These TNCs are by far the most widely-used piece of hardware for stand-alone digis without a computer in the US. [It's hard to beat the simplicity and low power consumption (15mA at 12 VDC) of a KPC3+radio digi at a remote site.] The problem is that KPCs do dupe suppression on WIDEn-N paths but NOT on plain RELAY or plain WIDE.

On the other hand, many home users operating first-tier low-level digipeaters (that in the past responded to "RELAY") use old TNCs (such as PK-232s, TAPR TNC-2s, MFJ 1270s, etc) that do not have APRS-aware firmware in them. These older devices CAN NOT do n-N decremented SSIDs.

With rapid APRS growth in the early '2000s, the volume of unnecessary APRS traffic due to RELAY and plain WIDE not supporting dupe checking just exploded. A lot of discussion followed on how one could migrate to an exclusively WIDEn-N network (with effective dupe control) while still allowing non-N-N-aware home fill-in digis to remain part of the APRS infrastructure. At the same time, one wanted to prevent home digis from acting on anything but the very first hop of a path.

The solution was the two-part WIDE1-1,WIDE2-n path I proposed.

All home low-level digis set WIDE1-1 as a simple alias to be treated as an ordinary callsign of WIDE1 with an SSID of -1. When a "dumb" home digi hears WIDE1-1 as the first hop in a path, it digipeats it just like any other fixed callsign, marks it as used, and passes the second WIDE2-1 or WIDE2-2 part onward to the next tier of "real" N-N digis. (The home digis completely ignore WIDE2-anything or higher since only WIDE1-1 is set as an alias to digipeat on.)

True high-level WIDEn-N will respond to any value of WIDEn. If a high-level digi (that DOES have proper WIDEn-N support) happens to hear the initial transmission, it will process WIDE1-1 as a decremented n-N, mark it used up and hand the second half WIDE2-n to the next (high-level) digipeater(s).


The difference when monitored off the air after the first hop is that a home fill-in digipeat of the first hop would yield

WA8LMF to APRS via WIDE1-1*,WIDE2-1

while a first hop captured by a "real" decrementing WIDEn-N digi, would produce

WA8LMF to APRS via WIDE1-0*,WIDE2-1

or possibly

WA8LMF to APRS via *WIDE1*,WIDE2-1

if the monitoring TNC's firmware treats an SSID of "zero" as effectively no SSID at all for display purposes.


The low-level WIDE1-1 home digis far outnumber the WIDE2-n "true wides". Beaconing WIDE1-1 as the first hop from aircraft (that have a range of hundreds of miles/km line-of-site) can potentially trigger hundreds of home WIDE1-1 digis simultaneously, when then ALL retransmit to the nearest true WIDEn-N systems. If the first hop from an airborne station is a WIDE2-n only (which the home digis just ignore) a few "true wides" rather than hundreds of home stations will be triggered.

Yes, the whole scheme is a kludge to work around the limitations of 20-year-old "clunker" TNC hardware, but it does kinda' sorta' work.........

--

Stephen H. Smith wa8lmf (at) aol.com
Home Page: http://wa8lmf.net

NEW! *** HF APRS over PSK63 ***
http://wa8lmf.net/APRS_PSK63/index.htm

Universal HF/VHF/UHF Antenna Mounting System
http://wa8lmf.net/mobile/UniversalAntMountSystem.htm

"APRS 101" Explanation of APRS Path Selection & Digipeating
http://wa8lmf.net/DigiPaths

Airborne APRS Suggestions

> Above altitude of 3000 feet one should use at most WIDE1-1, preferrably no via paths at all.

>> Bob should really write some new guidance on path definitions for flyers.

The recommendation has never changed in the last decade.

NEVER-EVER USED WIDE1-1 !!!! There is no DUPE suppression in APRS for WIDE1-1!.

For BALLOONS, the recommendation is to use a payload with variable paths and rates at altitude and on the ground * OR * if a less-smart payload is used, use WIDE2-2 and no more often than 1 minute. This is not as bad as it sounds. Every digi will ONLY DIGIPEAT IT ONCE (not twice or more) because the New-N paradigm eliminates dupes. And having a new "vehicle" appear in every digi area for a 3 hour mission special event, is no worse than another driver driving though the area.

If a DIGI is causing dupes, FIX THE DIGI! Update to the 2004 New-N Paradigm!!! See http://www.aprs.org/fix14439.html

For Aircraft, the PATH is WIDE2-1. There is no reason to need 2 hops on the ground. The plane should not be lost...

NEVER USE WIDE1-1 on any airborne mobile.

Bob, Wb4APR

2010 APRS Golden Packet Attempt

On 25 July please consider participating in this year's APRS Golden Packet Attempt along the Appalachian Trail (and Pacific Coast Trail). Please see www.aprs.org/at-golden-packet.html and also page 99 in July's QST. There is also an effort being made this year on the West Coast see www.aprs.org/pct-golden-packet.html.

All it takes is a mobile with a D700 or FTM-350 to drive up to the top of the mountain and park for 4 hours.

Many teams have formed, but the New England area has many gaps from New York to Maine:

• Sam's pt NY (not manned in 2009)
• Mt Greylock
• New Hempshire (innop in 2009)
• Mt Washington (2009 team all moved to texas)
• Middle Maine (not manned in 2009)
• Mt Katahdin (not manned in 2009)

We still have not formed solid teams from these southern sites:

• Huntsville AL
• Lookout Mountain TN
• Roan Mountain NC (maybe)
• Comer's rock VA (not operational in 2009)(near Wythville)
• Apple Orchard Mtn (near Roanake

It's a 4 or 5 hour event on Sunday Afternoon and a great way to escape the heat down below by getting up there on the mountain top. If you cannot participate, spread the word, and find an out-doors type that can. Most sites are DRIVE-UP sites, so just about anyone with a car and a D700 or FTM-350 can participate as a temporary digi site after proper set-up.

Think of it as APRS Field Day.

Bob, Wb4APR

https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig

APRS Channels - Kenwood D700's at EOC

At our local EOC (emergency Operations Center), they have two D700's and and additional four in GO-kits which we will be programming FOUR channels for APRS use on side A with these 4 names and settings:

1. APRS-107 <== Muted APRS witch CTCSS 107 (with calling)
2. APRS-VA <== Normal APRS with CTCSS 100 for voice alert
3. APRSmute <== Muted APRS with DCS xxx
4. APRS-raw <== APRS with no squelch for channel assessment

With the above 4 channels, there should never be any need to touch the volume control on the APRS radio side A. It should always have the volume up to normal volume to receive calls. The operator can select any degree of noise free operation with those 4 channels.

1. APRS-107 Normal setting is APRS 107 which is basically APRS with voice alert, but with the local PL tone for our club. This keeps the radio QUIET, but if someone really did want to get the attention of the crew at the EOC (no matter where they were listening, they could key up on APRS with PL 107 and call them.
2. APRS-VA For knowledgible operators, they can set normal Voice Alert if they want a proximity detector to know when other Voice Alert stations are in range. I would call this channel APRS-VA except that since we are adjacent to the State of Virginia, too many people will think it has something to do with that state instead of Voice Alert. SO in our case, I will label this channel as APRS-100.
3. APRSmute Using the APRS channel with a random DCS basically means the speaker squelch will NEVER Open. SO in effect, this is APRS MUTED operation without having to touch the volume control.
4. APRS-raw Choose this channel to quickly listen to the APRS channel for any kind of troubleshooting without having to go to TONE menues.

Again, the purpose of these 4 channels are to make sure that the APRS radio always powers up in the best configuration for immediate use.

1. Have a default for the radio to power up that is quiet
2. Make sure no one ever has to touch the SQUELCH or VOLUME settings.
3. But the APRS operator in the EOC can be reached if needed

THen we will have the following PM Program Memories:

• PM1 - APRS using the front panel. Band B on local UHF channel
• PM2 - APRS packet mode to PC client software. Band B on UHF
• PM3 - Voice Operation. Band A and Band B set for desired channels
• PM4 - Voice and BAND SCAN
• PM5 - Still thinking... About this one..?

Bob, WB4APR