All I want for Christmas.....

I have my two front teeth, so here's what I want:

Uniden HomePatrol 1 Scanner.....OK, couldn't wait, and got it. Love it. Got the GPS cable which will auto adjust scan area based on GPS location. Anxiously awaiting Uniden mobile mounting bracket.

Kenwood TH-D72..... OK, ordered it from HRO $499 and hoping it will arrive by Christmas. Fingers crossed.

Mobile Emergency APRS Digipeater.....With intent on putting everything in a Pelican case..... Kenwood D710 transceiver with Green Light Labs GPS-710 GPS receiver, KPC-3+ TNC. Would configure this for 9600bd APRS one side of radio 144.35, and 1200bd APRS other side of radio 144.39 using KPC-3+ as external TNC. Would support both 12kbd/9600kbd APRS for emergencies or site survey for future WIDEn-N digipeater location.

BeeLine 2M tracker @ 9600baud. This would be the redundant tracker for my balloon satellite capsule on 144.35, no path, and supplement the primary tracker, a BeeLine 2M tracker @1200baud on 144.39, the primary APRS frequency, for balloonsat tracking.

A job...starting in January. I'm booked till then.

Kenwood D710A Failing Filter Explanation and Fix..

It appears the mystery of the Kenwood D710 going deaf is solved...

This blog:

http://www.amateurradio.com/kenwood-filter-fault-fix/

has a link to the withering filters explanation:

http://sv8ym.blogspot.com/2010/07/mysterious-case-of-withering-filters.html

and a link to the solution:

http://sv8ym.blogspot.com/2010/10/lift-withering-spell-off-those-ceramic.html

73

Bill - WA7NWP

BALLOON LAUNCH SAT OCT 16 FROM RITZVILLE

The as-yet-unnamed Inland Empire Near Space Enthusiasts (IENSE) group has completed final preparations for the launch, tracking, and recovery of a high altitude balloon scheduled for launch Saturday morning from the Ritzville, WA area. Final launch preparations were discussed in a leadership meeting this past weekend.

Details follow:

Launch: Saturday, October 16, 0800-0830PDT, weather dependent (forecast is a go for launch)

Launch Site: Ritzville High School. Launch team on-site by 0730. Breakfast at Ritzville Perkins 0645PDT.

Flight profile: Wind predictions are to the East.

Projected LZ (landing zone) is 65-90 miles (LZ will be refined and identified on www.findu.com upon burst detection).

Projected altitude is 90k feet on a two hour flight.

Tracking callsign: Two APRS trackers: K7GPS-11 and KG5AO-8. (Tracking also available on www.aprs.fi)

Package: 1000g latex balloon with helium fill, 6' parachute for recovery after burst, capsule is 15"x12"x9" styrofoam container with two APRS trackers (KG5AO-8 and K7GPS-11), vertical SD color video camera with GPS overlay to record balloon expansion and burst), SD color video camera on diagonal alignment, and two SD Canon A470 cameras with CHDK-hack recording horizontal imagery every 10 seconds.

Tracker details: K7GPS-11 is a BigRedBee BeeLine 2M all-in-one APRS tracker. KG5AO-8 is a Yaesu Vertex 2M HT, Byonics TinyTrak3 controller, and Garmin E-Trex GPS. Both GPS devices are certified for flight above 60k ft.

Credit: Thanks to members of the Spokane Astronomical Society for their interest, support, and enthusiasm with this project.

PAO Note: KHQ has been contacted and may attend the launch activities.

Related links:

• Tracker 1 K7GPS-11: http://www.findu.com/k7gps-11
• Tracker 1 K7GPS-11: http://aprs.fi/?call=k7gps-11
• Tracker 2 KG5AO-8: http://www.findu.com/kg5ao-8
• Tracker 2 KG5AO-8: http://aprs.fi/?call=kg5ao-8

Regards, David K7GPS

APRS Messenger v2.89 with many changes released

Date: Thu, Oct 7, 2010 at 3:26 AM
Subject: [cross_country_wireless] APRS Messenger v2.89 with many changes released


I've just uploaded v2.89 to the website and Files section.

This version has a lot of changes:

Separate transmit and receive sound cards can now be configured.

Sound card sample rates of 48000 Hz and 11025 Hz can now be selected.

Fast and slow CPU options can now be selected.

It has the latest version of the MMVARI sound card engine (first update in 5 years).

The program can with fast CPU selected run 24 simultaneous receivers receiving a selection of modes including PSK-63, PSK-250, QPSK-63, QPSK-125, QPSK-250, GMSK-63, GMSK-125 and GMSK-250. The CPU load is higher and it will only run on PC's faster than 500 MHz due to the amount of number crunching and text string munching that the program is doing.

With slow CPU selected the CPU load is similar to earlier versions with only PSK-63, PSK-250, GMSK-63 and GMSK-250 being received. The slow version will also send on any selected mode but will only receive on the centre frequency with slow AFC.

The check before transmitting routine has also been changed to stop transmitting over other signals.

The delay before an ACK is transmitted has also been extended by 300 microseconds as it was too fast for some transceivers.

73,

Chris, G4HYG

Summary on UIView and IGates by WA8LMF

1) UIview does an excellent job as an igate. Contrary to the previous posting on this thread that two-way igates are difficult to set up, the default settings in UIview make it almost trivial to place a two-way igate on the air with next-to-zero impact on the RF channel.

2) Two-way igates DO NOT indiscriminately flood the RF channel with traffic from the APRS Internet System. Unless you go out of your way to explicitly edit a control file in UIview, the program only "reverse-gates" (i.e. Internet-to-RF) messages addressed to specific callsigns --- NOT generic APRS traffic such as WX beacons and position reports that are "broadcast" to everyone, and not reverse-gate to stations that are not in the immediate area.

3) On the "Setup, APRS Server Setup" dialog, locate the area in the upper right of the dialog that says "Gate RF To Interenet". Check "Open the gateway" and "Insert station callsign". In the area just below this ("Gate Internet To RF"), check "Gate local messages" and "Use reverse digi path" .

4) The option "Use reverse digi path" causes UIview to override the normal "Unproto Address" digi path set in "Setup, Station Setup" for the station's own beacons, when reverse-gating messages. Instead, messages sent to stations heard by the igate directly (i.e. not via digipeaters) will be transmitted to RF with NO DIGIPEATER PATH AT ALL.

5) Messages will be reverse-gated IF and ONLY IF the destination station has been heard on RF locally (either direct or within one digi hop) --- and --- if the destination station has been heard on RF by the igate recently (within the last half hour).

6) This process of selectively reverse-gating on a minimal path works both for messages originated by the RF (mobile) station, and for messages originated by the Internet party.

7) It even works for a station on RF in one part of the world (say on the East Coast or in Europe) working a mobile on RF in another part of the world (say the West Coast). That is a message path can go RF<-->Internet<-->RF in a manner similar to a station on RF in California talking to a mobile in Europe via EchoLink or IRLP.

The same reverse-gating rules apply: If the RF stations on each end are both local to their respective igates, and have both been heard by their respective igates recently, then two-way messaging will work. Otherwise, reverse-gating will not happen.

8) As a mobile travels cross-country, it will move out of the local range of a given igate, and into the range of another one. When an igate stops hearing the mobile LOCALLY (it might still hear the mobile via several digi hops), the digi will then age the mobile's call out of it's table of "recently heard stations" and will stop reverse-gating any messages to/from that mobile. Hopefully by this time, the mobile is now within the "local" range of another igate which will take up the task of reverse-gating. [This process is very similar to a traveler with a cellular phone moving from one cell site to another.]

Note that the stations in question don't have to be messaging for these decisions to be made. The igates make the determination of "local" and "recently heard" based on the periodic "one-way" position beacon transmissions the station is normally making anyway.

8) One-way igates break this symmetry of send/receive. A mobile originating a message will get INTO the Internet system through a one-way igate, but the reply (ack) can't get BACK to him. The originating mobile responds by cluttering the RF channel with endless automatic repetitions of the message in a vain attempt to get an ack back. In other words, one-way igates can create MORE congestion than two-way ones!

Further the Internet (or remote RF station) being messaged can't reply to the incoming message he just received.

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

Suggested KY APRS Path and Beacon Rates

(This may be aimed at Kentucky but the excellent advice given fits anywhere.. BV)

Suggested KY APRS Path and Beacon Rates.
by wa4zko
from: suggested-ky-aprs-path-beacon-rate

The 144.3900 MHz APRS frequency is very busy in most areas. Most parts of Kentucky are no exception to this rule. In N. Kentucky, where local digipeaters hear several other digi’s in very active parts of 2 other states (OH & IN), the channel is extremely busy. We all have to share the frequency and thus act/operate accordingly. What you do on the channel WILL impact the other users, so give that due consideration.

Since it’s a pretty common question, below are some suggestions for APRS operations within Kentucky. These are not my ideas, they are pretty commonly accepted in most areas of the country. In fact many areas are more restrictive. These suggestions should work fine in and be reasonably compatible with most areas of the US and Canada:

First, your path should be restricted as much as possible. Most digi’s in Kentucky will only support up to WIDE3-3 (3 hops), but that doesn’t necessarily mean you should use a 3-hop path. Normally you should strive to keep your hop count down to no more than what is needed to hit your local I-Gates with reasonable reliability.

I’ve traveled a lot across the country and I never saw a coverage situation that would of benefited much (if at all) from more than 2 hops. Plus with today’s channel congestion, a UI packet is going to be lucky to survive more than two hops.

In many metro areas, there is a trend toward supporting only WIDE1-1 paths. I don’t think this is in place anywhere within Kentucky…yet. This makes the suggested mobile path of WIDE1-1,WIDE2-1 very important if you travel a lot.

Second, keep your beacon rate in check. In normal usage, there is rarely a legitimate need to beacon more often than every 3 minutes for mobile objects/stations. Even at 60 MPH, 3 minutes is only 3 miles….so do you really need more track resolution for day to day usage? I seriously doubt it. Many sysops perform channel analysis from time to time and will filter you off if you’re using a very disproportionate amount of RF airtime.

If your tracker supports decaying beacon rates, set your high speed rate no less than every 3 minutes and your stationary/slow rate to 20-25 minutes. If you’re stuck in traffic, at the grocery store, or otherwise not moving there is no need to be beaconing as if you’re mobile. Take a moment and give the above serious consideration and operate accordingly.

Be careful with the “default” decay/corner pegging settings in many trackers. The defaults are usually way too aggressive for our very curvy roads. Dial them back considerably. Hint, you don’t need to be beaconing every time you go around a sharp curve on the same road. Use sites like aprs.fi to review your tracks and make adjustments to get reasonable track resolution without hammering the channel with too many updates. TinyTrak users may find that using a “manual” beacon switch in conjunction with the automatic settings can be very handy to force updates as needed.

Third, for special needs/events, you should work with your local APRS digi sysops. If it’s a special drill/event where you want finer (more detailed) track resolution, it’s best done on an alternate APRS frequency (144.9900, 445.9250, or 446.1750 MHz) or using a 1 hop path max if your beacon rate will be <3 minutes.

Use of an alternate APRS frequency will allow you to beacon as fast as you wish without negative impact on the local/adjacent area APRS network. Using an alternate frequency will provide better coverage since your mobile trackers will not have to compete with distant signals at the APRS digipeater’s receiver. This approach is ideal for special events/drills, but requires coordination with your local APRS digi sysop(s) and maybe an I-Gate.

For stationary objects you really only need to keep yourself “fresh” in the APRS-IS system. While I get some slightly conflicting info on this, picking a random value somewhere between 20-30 minutes is a good approach. Sorry, but beacon rates shorter that are probably abusive and inconsiderate. Your house doesn’t move, so it doesn’t need to be beacon like a mobile object.

Weather stations can add significant loading to the channel. Please throttle back the update rates as much as you can. If someone needs dead current weather data there’s the WX Query option to get current data as needed. No need to be clobbering the channel 24 hours a day. If you must run a WX data rate faster than every 15-20 minutes, then consider a 1-hop or maybe even 0-hop if you’re hitting an I-gate direct.

Even digipeater sysops need to be cautious about beacon rates/paths. Since a properly configured WIDEn-n “S-Class” digipeater could potentially go for more than 10 minutes without proper ID, they will need to beacon an “ID” packet every 10 minutes. This is not to be confused with HID (hideous on APRS, leave it off). This “ID” packet should be local only, AKA 0-hops. Also you should program the digi to keep most of it’s “chatter” to 1-hop or 0-hop paths. This is especially true if you’re broadcasting local object data too (aka repeaters).

Also keep your digipeater’s beacons as short and to the point as possible. There is little need for email addresses in beacons (hint, they’ll wind up cached on the search engines for the spammers to find) and websites. If anyone truly needs to contact you, they can usually find your email address easily (hint, QRZ.com). Same if they’re really interested in your website. Few if any folks will see that stuff anyways and it just adds up to a big waste of channel airtime.

The above suggestion applies to mobile beacons. Remember that the shorter you keep your beacon packet…the better the odds of it wiggling through all the channel congestion.

SUGGESTED PATHS:

MOBILE: 2 hops - WIDE1-1,WIDE2-1

BASE: 1-2hops - WIDE2-2 or WIDE2-1

SUGGESTED BEACON RATES:

MOBILE: normally no faster than 3 minutes. Preferably with a decay rate that dials things back gradually to 20-25 minutes when stationary or traveling at very low speeds. Think twice about leaving your tracker beaconing all day long when your car is parked.

BASE: Typically you should just pick a random value between 20-30 minutes. Simple enough?

DEFUNCT PATHS:

A great deal of the older APRS software (and even some of the newer) will have some form of RELAY,WIDE programmed as the default paths. In most areas, RELAY and WIDE are no longer supported on the digipeaters. Use an appropriate WIDEn-n path or you will be wondering why your coverage sucks.

If in doubt, contact your local APRS digipeater sysop for their suggestions/best practices.

WA4ZKO

Vicinity Tracking

Any TNC or tracker that transmits a periodic beacon can be tracked all across the
country without a GPS. But only to the nearest town or city or so. This is because you can use the "vicinity" tracking feature of APRS to see what was the Digipeater that the device first used most recently.

This is very powerful, because without the GPS, a few AA batteries and a low power tracker can operate for a year or more by sleeping in low power mode for 9.99 minutes out of every 10 and then only waking up to send out a packet (not a position packet, but a Status or other APRS packet) once every 10 minutes.

You can either check their position manually by looking at the packet and the PATH used or FIND.COM has a special CGI "&vicinity" that will plot a map of the last digi that heard it.

Hopefully all of the other APRS sites such as APRS.FI and Oaprs.net have it as well.

This Vicinity tracking was fundamental to the original APRS as a means of identifying somewhere on the planet the source of a packet that entered the APRS system. With a global system like APRS, it is nice to be able to locate any packet (even without a position report) to a given digipeater footprint...

Bob, Wb4APR

Monitoring Packets

On 8/24/2010 9:45 AM, Robert Bruninga wrote:

With today's sound cards in every PC, surely there is a free O-Scope display.  If so, then there is no excuse for any ham to not use this tool for cleaning up some of the trash we see on 144.39. 

There is a very simple and FREE app for this on my website.

Go to wa8lmf.net/miscinfo

Scroll down the list of downloadable stuff and look for WaveTools.exe .

Right-click and download this self-extracting archive of 4 audio applets for your sound card.

Four separate small programs turn your sound card into a dual-trace audio scope -or- a sine/triangle/square-wave audio generator -or- a volume-unit meter -or- an audio spectrum analyzer switchable between a linear and log scale.

Note that the dual-trace scope function requires that you have a stereo input sound system -- most computer MIC inputs are MONO. If the machine has a LINE level input, it will be stereo. Or use the inexpensive USB-connected "iMic" external audio system described here:

http://wa8lmf.net/ham/imic

which provides a stereo low-level MIC input.

I've used WaveTools in the field with my mobile laptop connected to the mini-DIN "data" jack output of my D700's discriminator output many many times to troubleshoot packet audio issues.

Some further observations on the WaveTool utilities.

1) These are actually 16-bit Windows 3.1 programs, but they work well on 32-bit Windows 2000 and Windows XP systems. They will NOT work on Windows Vista or Windows 7, since the 16-bit compatibility layer (a.k.a. the "thunker") that has existed in 32-bit Windows since Win 95 was quietly dropped in Vista and beyond.

Note that this breaks many older supposedly 32-bit programs. Many early Win95/Win98 "32-bit" programs contained chunks of 16-bit code (especially device drivers) recycled from their 16-bit Windows 3.1 predecessors. Such programs depend on the thunker to seemlessly run the mix of 16- and 32-bit code.

2) Windows XP allows multiple applications to access the sound card simultaneously. The WaveTool scope or spectrum analyzer can run AT THE SAME TIME as the AGW Packet Engine, APRS Messenger, mmSSTV, MixW or other other sound card app for a REAL TIME display of the incoming signals being fed into these apps.

3) The WaveTool scope in dual-trace mode can do the tricks "real" scopes do of displaying A-only, B-only A and B, A-B, A+B and A vs B vector displays.

Lighthouse Weekend

> Almost 300 lighthouses will be on the air for the 2010 International Lighthouse/Lightship weekend, 8/21- 8/22.

If they have an APRS radio and change their SYMBOL to the lighthouse symbol, then we can see them on http://aprs.fi

Or, if enough of them select the Lighthouse symbol, then you can see them on:

http://www.findu.com/cgi-bin/symbol.cgi?icon=\L&limit=200

And, they can all communicate with each other and anyone else on the planet's APRS radio by sending an APRS message to CQSRVR with the first two words of the message being "CQ LOTA ..."

See how www.aprs.org/cqsrvr.html

An easy way to make contact.
Bob, Wb4APR

SSID Recommendation Update

Bob Bruninga has updated his recommended SSID suggestions. The big change is that before it was keyed mainly to choose the symbol and now it is purpose driven. For example, it's not that -9 is a car, now it's the main mobile.

The complete publication is at : http://aprs.org/aprs11/SSIDs.txt

Here's the main content.

----

APRS SSID Standard Applications                           9 June 2010

---------------------------------------------------------------------

Updated 9 June 2010 for more flexibility

Revised 2 June 2004 to add -10, -11, 12 and -15

SSID's have seen two different uses in APRS.  Initially as an ICON indicator back in the early 1990's.  But that is obsolete for over a decade.  Now SSID's are used as an informal way of indicating one of several different typical APRS applications.

Since many small displays for the handheld and mobile operator show nearby APRS station callsigns that flash up on the screen, it is nice to have some idea of what type of station or activity might be involved simply from the callsign SSID without having to push buttons, search lists, or look at maps to find out more about them. 

 SSID RECOMMENDATIONS:  It is very convenient to other mobile operators or others looking at callsigns flashing by, to be able to recognize some common applications at a glance.  Here are the recommendations for the 16 possible SSID's (the limit of 16 comes from the 4 bits available in the AX.25 protocol.  Note, The SSID of zero is dropped by most display applications.  So a callsign with no SSID has an SSID of 0.

-0 Your primary station usually fixed and message capable
-1 generic additional station, digi, mobile, wx, etc
-2 generic additional station, digi, mobile, wx, etc
-3 generic additional station, digi, mobile, wx, etc
-4 generic additional station, digi, mobile, wx, etc
-5 Other network sources (Dstar, Iphones, Blackberry's etc)
-6 Special activity, Satellite ops, camping or 6 meters, etc
-7 walkie talkies, HT's or other human portable
-8 boats, sailboats, RV's or second main mobile
-9 Primary Mobile (usually message capable)
-10 internet, Igates, echolink, winlink, AVRS, APRN, etc
-11 balloons, aircraft, spacecraft, etc
-12 APRStt, DTMF, RFID, devices, one-way trackers*, etc
-13 Weather stations
-14 Truckers or generally full time drivers
-15 generic additional station, digi, mobile, wx, etc

* One-way trackers can use any symbol the owner desires, -9, etc but if the owner wants to indicate that a particular mobile is not message capable and he cannot receive message traffic, then he might want to use the -12 indication.

SV2AGW Packet Engine Freeware Update

After about 5 years, a new version of the FREE version of the AGW Packet Engine has been released.

Version 2010-805 just went up on SV2AGW's web site a few days ago. According to the site, changes have been made to address new sound cards and to work better with USB -- serial dongles for PTT keying.

I can't say I saw any difference in performance in 4 installations on my various computers, but the setup dialog does make it a bit simpler to select between multiple sound cards if you have more than one on your computer.

Get it here:


http://www.sv2agw.com/downloads/default.htm

Scroll down below the "Pro" version at the top of the page.

[ Note that the freeware version of AGWpe only supports the high (2100/2300 Hz) "PK-232" tones on HF 300-baud packet, while the pay-for "Pro" version also supports the standard (1600/1800 Hz) KAM/TNC2/MFJ-127x tones on HF. ]

*** IMPORTANT*** The AGW sound card TNC works well, --BUT-- is very sensitive to sound card sampling rate errors. Many cheap motherboard-based sound systems have MAJOR errors in their sampling rates which will keep AGW from working. (You will see the incoming audio on the built-in scope or waterfall display, but nothing ever decodes.)

Verify your soundcard's sampling rate with the CheckSR.exe test utility bundled with the MixW multi-mode soundcard program at:

http://mixw.net/index.php?j=downloads

Download and install the latest version of MixW as a trial. The CheckSR utility is a completely separate single-file-exe program placed in the MixW folder during the setup. It will function by itself, even if you don't purchase and activate MixW after the trial period.

If the 11025 Hz sampling rate is off by more than 50-100 Hz, you may want to consider an alternative sound system. An inexpensive USB-connected external sound system that works well is the Griffin Electronics "iMic" reviewed here on my web site:

http://wa8lmf.net/ham/imic.htm


Stephen H. Smith wa8lmf (at) aol.com

APRS Links

We have a full list of links on the NWAPRS homepage. Here's some links to new and interesting projects.

• HF APRS with PSK63 - finally something better than 300 baud packet for APRS on HF.
• APRS Messenger - the program for HF APRS with PSK63
• APRSLINK - APRS interface to WINLINK2000 Email
• SV2AGW Software Downloads - including update of freeware version of AGWPE

APRS Link to Winlink2000

I'm trying to understand why my I-gate is getting packets from WLNK-1. It appears that WLNK-1 (no call sign?)
is in Halifax, NS! Why would these packets route there my system?

That is the APRS link to the WinLink 2000 system. Hams can preregister their callsigns with the WinLink system and use the APRS system to check and/or pull emails off the system. It's actually a great system that gets very little use.

http://www.winlink.org/aprslink

Brian N2KGC

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