The annual Operation ON-TARGET consist of scouts and hams all over the country going to mountain tops and attempting to communicate by signal mirror (assisted by HAM contact to know where to point). This is Saturday July 21st, 1100 to 1400 LOCAL TIME.
See www.ldsfacts.net/ontarget.htm
Take along an APRS HT or radio, since then everyone can see on their attached GPS where everyone else is and can globally text message in real time for coordination. In addition, everyone back home can watch it all LIVE and see on maps where everyone is and what links are successful on http://aprs.fi
Operation on target has hundreds of participants out west because of the accessible mountains and clarity of distance. The goal is mountain top connectivity across the entire US north to south.
Similarly, APRS has had an annual event (Golden Packet attempt) on the 3rd weekend in July to do the same thing but with APRS and packet. We have been successful in linking 15 mountain tops from Georgia to Maine with APRS and will do it again this year. But by joining with Operation On Target, at least out-west, the APRS folks out west get to leverage the many more hams that are involved already. See all about the Golden Packet event:
http://aprs.org/at-golden-packet.html
At this time, we WILL plan on operating the APRS Golden Packet event out west on the 21st with the Operation on Target. We are still trying to decide for the Appalachian trail group, originally planning on the 22nd, Sunday, to move to the 21st Saturday to match up our efforts with East coast Scouts that might be doing Operation On Target along the Appalachians.
So far, we have not found any east-coast OT plans. So if anyone knows of any, please let us know. We will carry mirrors if there are scouts watching...
Oh, and the CQ Worldwide VHF contest is that same weekend! That starts at 1800z on Saturday (1400 EDT on the east coast). The mountains will be crawling with hams! (and QRM)...
For the 4 hour event, APRS will use 144.34 MHz. Please join the at-golden-packet@yahoogroups.com if you will participate so we can coordinate. And review APRS Details on the web page above. We will all use the EYEBALL symbol to make it easy to identify participants.
Bob, Wb4APR
https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
Showing posts with label aprssig. Show all posts
Showing posts with label aprssig. Show all posts
Thursday, July 5, 2012
Sunday, January 23, 2011
APRS Messenger v2.98
I've just uploaded APRS Messenger v2.98 to the webpage:
http://www.crosscountrywireless.net/aprs_messenger.htm
This version now has a remote control feature to allow the APRS over HF digimodes and VHF TNC transmit functions to be enabled or disabled by an APRS message.
In the initial set-up screen you can enter the callsign and SSID of the remote control station. You can also enter the remote control messages to stop and start the igate transmit function. The defaults are "Igate transmit ON" and "Igate transmit OFF" but these can be changed to any 18 character message.
Remote control messages can be set over VHF (if a TNC is used), APRS over HF digimodes or the APRS-IS. A confirmation message "Confirm igate transmit ON" or "Confirm igate transmit OFF" is sent out to the remote control station over the APRS-IS if connected. When transmit is disabled the program still functions as a receive only Igate.
On HF digimodes the sound card transmit is enabled or disabled. Using a VHF TNC the comm port RTS output is enabled or disabled to control the TNC.
This is useful in countries where closedown arrangements have to be made for unattended use or where APRS igate operators would like a remote control facility when away from home.
73,
Chris, G4HYG
--
Chris Moulding
Cross Country Wireless Ltd
Website: http://www.crosscountrywireless.net
https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
http://www.
This version now has a remote control feature to allow the APRS over HF digimodes and VHF TNC transmit functions to be enabled or disabled by an APRS message.
In the initial set-up screen you can enter the callsign and SSID of the remote control station. You can also enter the remote control messages to stop and start the igate transmit function. The defaults are "Igate transmit ON" and "Igate transmit OFF" but these can be changed to any 18 character message.
Remote control messages can be set over VHF (if a TNC is used), APRS over HF digimodes or the APRS-IS. A confirmation message "Confirm igate transmit ON" or "Confirm igate transmit OFF" is sent out to the remote control station over the APRS-IS if connected. When transmit is disabled the program still functions as a receive only Igate.
On HF digimodes the sound card transmit is enabled or disabled. Using a VHF TNC the comm port RTS output is enabled or disabled to control the TNC.
This is useful in countries where closedown arrangements have to be made for unattended use or where APRS igate operators would like a remote control facility when away from home.
73,
Chris, G4HYG
--
Chris Moulding
Cross Country Wireless Ltd
Website: http://www.
https://www.tapr.org/cgi-bin/
Sunday, October 3, 2010
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
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
Wednesday, September 15, 2010
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
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
Thursday, September 9, 2010
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
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
Tuesday, August 24, 2010
Monitoring Packets
On 8/24/2010 9:45 AM, Robert Bruninga wrote:
There is a very simple and FREE app for this on my website. 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.
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.
Friday, August 20, 2010
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
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/
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
Tuesday, August 17, 2010
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.
Wednesday, August 11, 2010
SV2AGW Packet Engine Freeware Update
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/
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=
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.
Stephen H. Smith wa8lmf (at) aol.com
Tuesday, August 10, 2010
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?
is in Halifax, NS! Why would these packets route there my system?
http://www.winlink.org/
Brian N2KGC
Monday, August 9, 2010
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
Friday, August 6, 2010
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
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
Saturday, July 31, 2010
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
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
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/
Universal HF/VHF/UHF Antenna Mounting System
http://wa8lmf.net/mobile/
"APRS 101" Explanation of APRS Path Selection & Digipeating
http://wa8lmf.net/DigiPaths
Friday, July 30, 2010
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
Wednesday, July 14, 2010
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
Friday, June 18, 2010
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:
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.
Bob, WB4APR
- APRS-107 <== Muted APRS witch CTCSS 107 (with calling)
- APRS-VA <== Normal APRS with CTCSS 100 for voice alert
- APRSmute <== Muted APRS with DCS xxx
- 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.
- 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.
- 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.
- 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.
- APRS-raw Choose this channel to quickly listen to the APRS channel for any kind of troubleshooting without having to go to TONE menues.
- Have a default for the radio to power up that is quiet
- Make sure no one ever has to touch the SQUELCH or VOLUME settings.
- But the APRS operator in the EOC can be reached if needed
- 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
Wednesday, November 26, 2008
APRS Travel Season
The Travel seasons are upon us. Is your local APRS network ready to serve travelers? Is your network properly configured for new-N? See www.aprs.org/fix14439.html.
Is your network providing the local recommended FREQ object for travelers passing through? (see www.aprs.org/localinfo.html). Are you monitoring that voice repeater to help fellow travelers?
While traveling do you have Voice Alert enabled and the volume up? See www.aprs.org/VoiceAlert3.html
Is your local IRLP/Echolink node showing up on APRS in the simplex range where it can be used? See www.aprs.org/info/echo-irlp-win.txt
Are you configured to receive messages? Do you know how to send email from your mobile? See www.aprs.org/aprs-messaging.html
Does your Beacon contain your typical monitoring voice frequency?
Is your channel quiet more than half the time? It should be for best reliability. In fact, it should be quiet more than 2/3rds of the time. If not, your network is overloaded. See www.aprs.org/aloha.html. Spend 30 minutes monitoring your local channel looking at PATHS. Is everyone using an appropriate path and rate?
Get out your radio. Communicate. Let APRS help you get "connected"...
Bob, WB4APR
Is your network providing the local recommended FREQ object for travelers passing through? (see www.aprs.org/localinfo.html). Are you monitoring that voice repeater to help fellow travelers?
While traveling do you have Voice Alert enabled and the volume up? See www.aprs.org/VoiceAlert3.html
Is your local IRLP/Echolink node showing up on APRS in the simplex range where it can be used? See www.aprs.org/info/echo-irlp-
Are you configured to receive messages? Do you know how to send email from your mobile? See www.aprs.org/aprs-messaging.
Does your Beacon contain your typical monitoring voice frequency?
Is your channel quiet more than half the time? It should be for best reliability. In fact, it should be quiet more than 2/3rds of the time. If not, your network is overloaded. See www.aprs.org/aloha.html. Spend 30 minutes monitoring your local channel looking at PATHS. Is everyone using an appropriate path and rate?
Get out your radio. Communicate. Let APRS help you get "connected"...
Bob, WB4APR
Thursday, July 31, 2008
Voice Alert Summary
A good summarization of Voice Alert as posted by Joseph/NE3R on APRSSIG...
----
I've come across a lot of hams who don't have a good understanding of APRS Voice Alert. While Bob Bruninga, WB4APR explains it well on his voice alert page, I'll try to explain it in just a few lines.
Voice alert is essentially adding a 100hz CTCSS tone to the transmitted APRS packets on 144.39 (US), just set the tone as if you needed it to access the repeater and setting the radio to tone squelch (CT on the D700) and leaving the volume on the data channel up. When a packet is received with the 100hz tone, you'll hear it on the radio, and you should also see the call on whatever APRS display you are using. The radio will still decode packets that don't have the 100hz tone, you just won't hear them. This works with most rigs/tncs that don't rely on the speaker output to feed audio to the TNC.
The full details can be found:
http://aprs.org/VoiceAlert3.html
http://www.ew.usna.edu/~bruninga/VoiceAlert3.html
Even hams that don't use APRS can take advantage of voice alert, just listen to 144.39 with your tone squelch set to 100hz. When an APRS mobile is in the area, you'll hear them, and you can give a general call for APRS voice alert stations.
Once contact is made on the voice alert channel, the conversation should be moved to another frequency to keep the channel clear for packets, and to keep the packets from crashing your QSO.
One thing that makes voice alert less useful is when the tone is transmitted with the packet, but nobody is listening (unattended, volume down, etc). That is one disadvantage to the D710, it isn't as easy to turn off voice alert once you have it on, which leads to folks just turning down the volume.
I hope this helps spread the word regarding APRS voice alert.
Thanks & 73 de Joseph Durnal NE3R
----
I've come across a lot of hams who don't have a good understanding of APRS Voice Alert. While Bob Bruninga, WB4APR explains it well on his voice alert page, I'll try to explain it in just a few lines.
Voice alert is essentially adding a 100hz CTCSS tone to the transmitted APRS packets on 144.39 (US), just set the tone as if you needed it to access the repeater and setting the radio to tone squelch (CT on the D700) and leaving the volume on the data channel up. When a packet is received with the 100hz tone, you'll hear it on the radio, and you should also see the call on whatever APRS display you are using. The radio will still decode packets that don't have the 100hz tone, you just won't hear them. This works with most rigs/tncs that don't rely on the speaker output to feed audio to the TNC.
The full details can be found:
http://aprs.org/VoiceAlert3.
http://www.ew.usna.edu/~
Even hams that don't use APRS can take advantage of voice alert, just listen to 144.39 with your tone squelch set to 100hz. When an APRS mobile is in the area, you'll hear them, and you can give a general call for APRS voice alert stations.
Once contact is made on the voice alert channel, the conversation should be moved to another frequency to keep the channel clear for packets, and to keep the packets from crashing your QSO.
One thing that makes voice alert less useful is when the tone is transmitted with the packet, but nobody is listening (unattended, volume down, etc). That is one disadvantage to the D710, it isn't as easy to turn off voice alert once you have it on, which leads to folks just turning down the volume.
I hope this helps spread the word regarding APRS voice alert.
Thanks & 73 de Joseph Durnal NE3R
Thursday, July 17, 2008
Publish Hamfests with APRS (updated)
Come on APRS!
Surely we can put HAMFEST objects on the map to help alert and remind our fellow hams of such important upcoming events! I just checked, and not a single HFEST is showing. There is one HAMFEST object, but it is in New Zealand!
Please use this format for the name of your HAMFEST object:
HFEST-ddx
Use the "\h" symbol which is a bright red object...
This not only makes them stand out on the map, but also includes the DATE (dd) in the object name to make it clear this is a future object. The "x" on the end makes it unique so that FINDU
can find them all:
http://map.findu.com/HFEST*
For details of this format, see the LOCAL INFO page about 30% down the slider:
http://www.ew.usna.edu/~bruninga/localinfo.html
It's the season, lets show what APRS can do...
Bob, WB4APR
----
APRS EVENTS application for generating this info... Thanks to Stephen H. Smith wa8lmf
---
The application, APRS Events, is available from M0CYP's UI-View add-on pages
It actually doesn't depend on UI-View or it's settings at all. It is a standalone application that uses the AGW Packet Engine as an interface to access one or more TNCs. You specify a callsign and path completely independently of UI-View.
Currently at my station, AGWpe is arbitrating access to both the HF and VHF ports of a classic original KAM, and access to a second KPC3+. It allows 4 copies of UI-View, UI-Traffic Monitor, UI-Network Analysis and APRS Events to access/share both TNCs.
APRS Events is controlled by a text file "APRSevents.csv" that contains lines like these (these are single lines that may wrap in email):
#2008-07-11 15:05:00#,#2008-07-12 10:00:00#,"Inland Empire ARC Swapmeeet 8AM Sat - Cable Airport in Upland",28
#2008-07-21 15:05:00#,#2008-07-22 21:00:00#,"Pasadena ARC Meeting 7:00 PM Tuesday at Kaiser in Pasadena",28
#2008-07-25 15:05:00#,#2008-07-26 10:00:00#,"TRW Swapmeet Saturday 8:00 AM Manhattan Beach",28
The final set of digits is the repetition rate in minutes. I purposely set the rep rate slightly faster than 30 minutes so that if my "half-hourly" beacons happened to coincide with someone else's, the beacons would gradually drift out of phase over time. The application has a fill-in template to add events, but the user interface is so clumsy and erratic when it comes to editing existing events that I find it easier to edit the .CSV file directly outside of UI Events. (On most Windows systems with MS Office installed, double-clicking the APRSevents.csv file makes it open in an Excel spreadsheet where it is neatly columnated and easy to edit. )
The application is hardwired to transmit in bulletin format. (I wish it could transmit objects as well -- perhaps in a future revision it will). It stores it's own path and originating callsign independent of any other application using AGWpe.
I have set a single-hop path using the actual callsign of a single digipeater (N6EX-1) that covers the area of interest (the San Gabriel Valley -- the area between 5 and 20 miles east of downtown Los Angeles that includes Pasadena, Alhambra, Monterey Park, Arcadia, Monrovia, El Monte, etc). This avoids setting off 4 or 5 digipeaters all over the greater Los Angeles basin simultaneously with the generic WIDE2-2 path normally used around here.
Surely we can put HAMFEST objects on the map to help alert and remind our fellow hams of such important upcoming events! I just checked, and not a single HFEST is showing. There is one HAMFEST object, but it is in New Zealand!
Please use this format for the name of your HAMFEST object:
HFEST-ddx
Use the "\h" symbol which is a bright red object...
This not only makes them stand out on the map, but also includes the DATE (dd) in the object name to make it clear this is a future object. The "x" on the end makes it unique so that FINDU
can find them all:
http://map.findu.com/HFEST*
For details of this format, see the LOCAL INFO page about 30% down the slider:
http://www.ew.usna.edu/~
It's the season, lets show what APRS can do...
Bob, WB4APR
----
APRS EVENTS application for generating this info... Thanks to Stephen H. Smith wa8lmf
---
The application, APRS Events, is available from M0CYP's UI-View add-on pages
It actually doesn't depend on UI-View or it's settings at all. It is a standalone application that uses the AGW Packet Engine as an interface to access one or more TNCs. You specify a callsign and path completely independently of UI-View.
Currently at my station, AGWpe is arbitrating access to both the HF and VHF ports of a classic original KAM, and access to a second KPC3+. It allows 4 copies of UI-View, UI-Traffic Monitor, UI-Network Analysis and APRS Events to access/share both TNCs.
APRS Events is controlled by a text file "APRSevents.csv" that contains lines like these (these are single lines that may wrap in email):
#2008-07-11 15:05:00#,#2008-07-12 10:00:00#,"Inland Empire ARC Swapmeeet 8AM Sat - Cable Airport in Upland",28
#2008-07-21 15:05:00#,#2008-07-22 21:00:00#,"Pasadena ARC Meeting 7:00 PM Tuesday at Kaiser in Pasadena",28
#2008-07-25 15:05:00#,#2008-07-26 10:00:00#,"TRW Swapmeet Saturday 8:00 AM Manhattan Beach",28
The final set of digits is the repetition rate in minutes. I purposely set the rep rate slightly faster than 30 minutes so that if my "half-hourly" beacons happened to coincide with someone else's, the beacons would gradually drift out of phase over time. The application has a fill-in template to add events, but the user interface is so clumsy and erratic when it comes to editing existing events that I find it easier to edit the .CSV file directly outside of UI Events. (On most Windows systems with MS Office installed, double-clicking the APRSevents.csv file makes it open in an Excel spreadsheet where it is neatly columnated and easy to edit. )
The application is hardwired to transmit in bulletin format. (I wish it could transmit objects as well -- perhaps in a future revision it will). It stores it's own path and originating callsign independent of any other application using AGWpe.
I have set a single-hop path using the actual callsign of a single digipeater (N6EX-1) that covers the area of interest (the San Gabriel Valley -- the area between 5 and 20 miles east of downtown Los Angeles that includes Pasadena, Alhambra, Monterey Park, Arcadia, Monrovia, El Monte, etc). This avoids setting off 4 or 5 digipeaters all over the greater Los Angeles basin simultaneously with the generic WIDE2-2 path normally used around here.
Friday, July 11, 2008
APRS Symbols - current list
The complete symbol set (and the codes that create them) is here:
<http://wa8lmf.net/aprs/APRS_symbols.htm >
Other APRS resources by WA8LMF:
<http://wa8lmf.net/aprs/APRS_
Other APRS resources by WA8LMF:
- World Digipeater Map
- APRS maps
- JavAPRS Filter Port 14580 Guide
- APRS 101 Explanation of APRS Path Selection & Digipeating
Subscribe to:
Posts (Atom)