Showing posts with label wa8lmf. Show all posts
Showing posts with label wa8lmf. Show all posts

Saturday, January 22, 2011

Installing UI-View and Precision Mapping on Win7 and Vista

I have extensively updated the "UIview Notes" and "Using Precision Mapping 8" pages on my website, to reflect a new and improved installer for the Precision Mapping Server 7 plug-in for Uiview.

The new installer packaging for PMap Server 7.07 now works directly in Windows 7 (either 32 or 64 bit versions) without the clumsy and involved install procedure previously required. The same Precision Mapping Server Ver 7.07 is installed, but the installer program itself now works on these two newer versions of Windows.


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

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

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

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

Tuesday, August 24, 2010

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.

Wednesday, August 11, 2010

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

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

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


Saturday, September 5, 2009

New Writeup on HF APRS Posted...

by WA8LMF:

Subject: [aprssig] New Writeup On HF APRS Posted To My Website

I have finally got around to doing the guide/essay/set-of-notes on HF APRS operation that I have intended to to do for some time.

It is posted on my website at:

http://wa8lmf.net/aprs/HF_APRS_Notes.htm

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.