[aprssig] Re: Your mobile path - Reply
bruninga at usna.edu
Wed Jun 22 10:51:44 CDT 2005
Regarding wide area WX capture and back-bone
on RF to regional NWS WX sites. Here is how I
would do it.
1) Make a HIGH UHF aprs digi in the middle
of the large region of interest. Using the
alias of WXrrrr where rrrr is something that
identifies this particular central NWS area of
WX interest. (any TNC can be used)
The first tier out (maybe 4) install any additional
UHF APRS digis with the simply the allias of WX
(any TNC can support this single alias digiepating).
THe 2nd tier out is where you install at the important
existing 144.39 digis an added TNC hooked up to
listen to the existing 144.39 receiver but hooked to
a UHF HT transmitter on the UHF WX backbone.
These are also simple TNCs with just the WX alias.
Now then, any packet from any WX station or storm
spotter that is intended for the entire area and
forwarding to the central NWS site would
use a path of WX,WX,WXrrr.
The first hop would get the packet from the local
144.39 digi onto the UHF backbone. There it is
2 hops to the central NWS site and so the remaining
WX*,WX,WXrrr packet will get delivered.
The advantage of this technique is:
1) it uses existing (any) TNC
2) It is simple, and the UHF digis can be widely
a) They dont have to hear users, just the central one
b) Therefore they can use Beams
3) with this 3 hop approach there are no dupes
becuse of the crossband hop, and the final hop
is different alias.
No, it is not perfect, and there are other higher tech
and higher speed and other ways to do it, but the
one advantage of this approach is you can do it with
any old TNC and an $88 UHF HT in many cases.
Yes, 1200 baud can easily handle it because the
traffic load will be so light and the lack of CSMA
at the first tier will be hardly noticible...
And finally, since it is just a WX only channel on UHF,
then anyone else that wants to monitor it just tunes
to the UHF backboen frequency and thier 1200
baud system will let them see eveyrthing all the
other WX stations are seeing...
But the original reports are on 144.39 so the locals
can see them too...
A laudable effort. But I think you run into the
brick wall of needing the 9612 TNC and people
to do radio surgery to make it work.
I have kind of given up on that approach and
suggest accompoishing the same objective
by just staying at 1200 baud and simply
making the backbone be on another frequency.
It is simple, it works, and if it only passes WX
packets, it can support more than you will
ever get on the air anway. And if you make
it crossband then the backbone does not
interfere with the digi where it is located.
AND being at 1200 baud you can use ANY
old TNC. Just hook it to listen on 144.39
and TX on your chosen UHF backbone.
Make it a star and hub. With the HUB at the
main WX site listening on UHF backbone.
Surround this central site with UHF digis using
simple TNC's. Then surround those digis
with the simple cross band TNC's at the
removte 144.39 digis so that they pull off
only the WX packets
>>> Larry Keeran <lmkeeran at mac.com> 06/22/05 10:15 AM >>>
Pre PS - I don't check k9orp at netscape.net email very often. It is for
public contact with me not for day to day APRS comments. Sorry about
the delay Bill.
Following is the reply sent to you (Bill) and to the SM-IL Pat Ryan:
We are testing the reliability of the 9600 baud backbone to Lincoln (
on 445.925 ).
Bill, the APRS digi has a KPC-9612 with a GATE alias of WX3. When WX3
( http://www.qsl.net/k9orp/wxnetdia.html )
is in the path the packet crosses between VHF and UHF and vise-versa.
The double bounce is to see if the packet is reliably getting making it
on the UHF side.
The mixture of WIDEx-x is to see the result of support of WIDEx-x
through out the area (statewide as I travel).
We do see traffic at ILX via UI-View from mobiles but this RF side test
is for the UHF link prablem determination for ILX.
The purpose is to see weather objects (manually entered TOR and
Thunderstorm objects that are entered by one station per county that
would traverse the backbone and end up at NWS-ILX) Those objects do
not pass through FindU therefore RF testing is necessary.
Study the RF backbone link mentioned above and see if you understand it
and pick it apart as to the better path that can be used to accomplish
the task of displaying local weather objects that aid each local county
as well as traverse the NWS-ILX backbone to NWS-ILX so they can see
what is being reported.
The purpose is to provide a record of sightings of severe weather in
NWS-ILX CWA as well as the non-verbal support of location of dangerous
As you study the wxnetdia.html you will see the spoke wheel pattern of
the backbone uniquely designed to put NWS-ILX in the center of the path
so that traffic is directed to and from NWS by specifying WX# for
weather designated traffic. The path for participating stations would
have a decreasing number in the WX# going to NWS and likewise an
increasing number going away from NWS.
NWS utilizes VHF for voice weather net support so UHF is necessary for
APRS digital information. A small fact - there aren't two digi's on
UHF that make the backbone fully operational beyond the the 30 mile hop
(WX3). I have been promoting the project since 1996 (using the
KPC-9612 TNC) and have found very few technicians (actually none) to
install a dual port TNC and dual radios to accomplish the original
task. As the APRS network has grown over the years, it is necessary to
use a backbone to traverse any distance with timely packets. If I
listen on the speaker at the local digi, I never hear "dead air" (the
squelch doesn't set)... and you know what effect that has. I have been
promoting low height 2 meter local digi's that just cover the area to
allow the local digi to repeat the local weather object immediately and
ultimately use the backbone to pass the spotted object on the NWS-ILX
by using a higher UHF antenna.
Thank you Bill for your observation and I welcome questions and
possible solutions to improving the CWA to NWS relaying of dangerous
weather via APRS and thusly making it safer for spotters/public during
PS - I did not receive your email explaining the problem. I am on
vacation this week so a response from me is not going to be very
timely... as you may have seen me mobile in St. Louis or Chicago this
week so far.
On Jun 21, 2005, at 10:58 PM, R. Patrick Ryan wrote:
> Larry Keeran K9ORP could be running the peculiar path noted for good
> reason, and is a member of the NWS ILX Communicators at Lincoln that
> enjoys exceptional packet service, and Larry is one of our ARRL
> Official Emergency Stations. If your guidance is needed, I would be
> surprised. Please visit his web page at http://www.qsl.net/k9orp/ to
> learn more.
> On Sun, 19 Jun 2005 22:30:43 -0500 "Bill Diaz"
> <william.diaz at comcast.net> writes:
> > Pat,
> > I noticed a mobile come thru here today with a particulary bad
> > (and
> > defective path).
> > K9ORP-9>TQ4P0P,WIDE1-1,WIDE1-3,K9ORP-1,K9ORP-6,K9ORP-1,WX3 <UI R>:
> > I sent him an email explaining the problem and offered to help or
> > answer any
> > questions he might have.
> > Contrary to what is posted on the page, WIDEn-N is not being phased
> > out. In
> > fact, RELAY,WIDE and TRACE have been declared obsolete and should no
> > longer
> > be used. Mobiles should use WIDE1-1 in place of RELAY and former
> > RELAY
> > digis should change MYALIAS from RELAY to WIDE1-1. A typical mobile
> > path
> > should be WIDE1-1,WIDE2-2 and a typical fixed station path should be
> > WIDE2-1
> > or WIDE2-2.
> > See http://web.usna.navy.mil/~bruninga/aprs/fix14439.html for a
> > complete
> > description of the current N-N recommendations. Note that this has
> > changed
> > considerably since you posted the link on
> > http://www.qsl.net/ares-il/APRS.html
> > We need to get all Digis and stations to use the new WIDEn-N method
> > ASAP.
> > Currently, about half the stations in the state are using RELAY,WIDE
> > and
> > half are using WIDEn-N. I don't have to tell you what kind of
> > problems this
> > could cause during an emergency.
> > Thanks,
> > Bill KC9XG
Larry M. Keeran K9ORP - OES - NWS ILX APRS Coord
Life ARRL TAPR dosAPRS MacAPRS WinAPRS APRS+SA UI-View
More information about the aprssig