| |
ZL3AI > APRDIG 15.05.04 20:59l 277 Lines 10665 Bytes #999 (0) @ WW
BID : 3260-ZL3AI
Read: GUEST
Subj: TAPR Digest, May 01, 1/5
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0NOS<DB0BI<DB0FBB<DB0GOS<ON0AR<ON0AR<
ZL3VML
Sent: 040515/1922Z @:ZL3VML.#80.NZL.OC #:24105 [Chch-NZ] FBB7.00i $:3260-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Saturday, May 01, 2004.
1. On digipeater naming conventions
2. Re: D7 Antenna mods
3. Updated APRS and Programming projects
4. Re: UIview object transmission vs APRSdos
5. Re: On digipeater naming conventions
6. Using the D7 for updating Objects and indoors...
7. Re: [ui-view] Re: UIview object transmission vs APRSdos
8. Re: On digipeater naming conventions
9. Re: GPS Watch -- does anyone know anything about it??
10. Re: On digipeater naming conventions
11. Re: GPS Watch -- does anyone know anything about it??
12. Re: [ui-view] Re: UIview object transmission vs APRSdos
13. APRS Pizza Bash - Dayton
14. Re: APRS Pizza Bash - Dayton
15. Reminder: 2004 TAPR Digital BASH at Hamvention
16. Odd behaviour w/ Etrex
17. Re: On digipeater naming conventions
18. Re: GPS Watch -- does anyone know anything about it??
19. Re: On digipeater naming conventions
20. Re: On digipeater naming conventions
21. Pizza Bash
22. Re: APRS Pizza Bash - Dayton
23. dayton
24. ARRL virus
25. Re: ARRL virus
26. Re: ARRL virus
27. FW: Silent Key
28. Re: On digipeater naming conventions
----------------------------------------------------------------------
Subject: On digipeater naming conventions
From: "John Langtry, VE3NEC" <ve3nec@sympatico.ca>
Date: Sat, 01 May 2004 00:39:42 -0400
X-Message-Number: 1
Folks,
Jim, WA6OFT has an interesting idea, which we looked at many years ago;
that is using the CLLI (pronounce "silly") code for our machines.
Problem # 1 is I *think* that we have to pay to use this convention.
(Maybe, don't know.)
Problem # 2 and more to the point, we have only 6 bytes to play with. Two
of which are kinda useless.
For an example, one of our many nodes is located in Georgetown, Ontario
(VE3PKG); so it's CLLI is "GTWNON" which is true for the telephone
exchange. However, with the "VE3" part, it's kinda obvious that we're in
Ontario, Canada. (Thus the last two bytes are useless.)
As to the first 4, you'd have to go the CLLI index to see where "GTWN" is.
I defy you to find this on anything other than a local map. We're now part
of "Halton Hills" (I hate the name, but there it is.)
Given that we have only 6 bytes to play with, and the above hideous name,
the obvious "name" for this machine was "HALTON". The call sign (VE3PKG)
should hopefully tell you, that we're in Ontario, Canada ... and possibly,
if you checked a map in the (say) U.S., you might actually find "Halton"
(Region of).
Jim, good idea, if we had more bytes to play with; We did look at this
about 20 years ago, when Dave VE3FGK was the CLLI co-ordinator for Bell
Canada; We debated the point, and "HALTON" it is - for the reasons above.
For those of you outside the telephone industry, I've seen CLLI's as long
as 22 bytes; this describes the City, State (Province), building, remote
exchange, and even down to specific equipment used in that exchange /
remote, or at a Cutomer's premise. It's a fine system for the "telcos", but
I don't think it's quite what we need in the Amateur world. We need to find
something more "granular".
With now 31+ years of service,
vy 73 de John VE3NEC
TPA Chapter 100 (Maple Leaf)
905-873-8715
----------------------------------------------------------------------
Subject: Re: D7 Antenna mods
From: James Jefferson <jj@aprsworld.net>
Date: Sat, 1 May 2004 00:34:14 -0500
X-Message-Number: 2
I actually also suffered from a broken battery retaining clip. It is on a
TH-G71 which is uses the same battery and similar chassis to a D7. I dropped
the things from a few feet high onto carpeting and the plastic surrounding
the clip broke.
The battery usually stayed in place so I continued using it. Then I was
crossing the street one day and the radio popped off the battery. I didn't
notice until I was across the street and on the sidewalk, at which point I
turned around just in time to see a UPS trucking running the radio over.
I dashed out, grabbed the radio off the street, and discovered ... absolutely
nothing wrong with it. A few scratches on the face, but I snapped it back on
the battery and it worked fine. An amazing piece of hardware, no doubt about
it.
Since then the radio has spent a year being the transmitter for the KB0THN-2
solar APRS weather station on Madeline Island. While inspecting the weather
station I discovered that some sort of animal had chewed most of the rubber
keys on the keypad off. And the radio is still working.
So yeah, nice work Kenwood.
:-)
-Jim KB0THN
>DUCT TAPE!
>
>wes@johnston.net wrote:
>>Now we need a fix for when you drop it and break the battery retaining
>>clips off the back... :-(
----------------------------------------------------------------------
Subject: Updated APRS and Programming projects
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sat, 1 May 2004 16:25:08 +1000
X-Message-Number: 3
Howdy,
I have done a re-arrange of my web site and added some new projects and
info.
Been working HF APRS 1500 Km just on a piece of wire.
Cheers Andy
Andrew Rich (VK4TEC)
www.tech-software.net
vk4tec@hotmail.com
space - electronics - radio - aviation
----------------------------------------------------------------------
Subject: Re: UIview object transmission vs APRSdos
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sat, 01 May 2004 10:14:01 -0400
X-Message-Number: 4
<<<K3for@aol.com> 4/30/04 11:10:33 AM >>>
<We were planning on using UIview for our next scout
<event to keep track of about 50 troops...[as objects]...
<We abandoned UIview and went back to APRSdos, which
<uses... the original APRS "new-info-quickly/old-info-
<decays" algorithm.
We had the same problem. Any stations that are moving lots of objects
around should use a decaying algorithm (like APRSdos) or the channel
becomes saturated with a large number of objects.. But we did still use
UIview at the HQ but just planned on not using it for *sending or updating*
any objects.
See my next post about how we used D7's for both objects and tracking many
many foot portable users. de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: On digipeater naming conventions
From: Earl Needham <needhame1@yucca.net>
Date: Sat, 01 May 2004 09:06:04 -0700
X-Message-Number: 5
I haven't followed this discussion too closely, but didn't the old packet
system have MANY nodes that used the telephone area code along with an
abbreviation for the name of the city?
Like 305MLB for Melbourne, Florida...
7 3
Earl
Earl Needham, KD5XB, Clovis, New Mexico DM84jk
SETI@Home: 11491WU/7.45yrs
http://www.findu.com/cgi-bin/find.cgi?call=kd5xb-2
----------------------------------------------------------------------
Subject: Using the D7 for updating Objects and indoors...
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sat, 01 May 2004 11:17:08 -0400
X-Message-Number: 6
This post shows how you can use the D7 to update the location of OBJECTS
and to report positions even indoors.
Our event is to keep track of 30 platoons of students over a 5 square mile
campus, plus 6 buses, 2 boats and a few food and water trucks.
We used UIview at HQ and at a few other places where VIP's are watching and
APRSdos and D7's everywhere else. To avoid the damage from having studnets
carrying HT's and GPS's and wires and cables (which will all get destroyed
in this very physical activity), we overlayed a GRID on the UIview map of
the area. See the UIview map:
http://www.ew.usna.edu/~bruninga/photos/USNAgrid.jpg
The LAT/LONG for the whole campus is 38-59.xx and 076-28.yy and so a
student can locate himself or any object he wants to post by simply
entering the .xx or .yy into his D7. Not only can he update his own
position, but any other objects as well. To update an object (another
platoon), he simply changes his MYCALL to PLx then the .xx and.yy
coordinates from his paper map, and then presses the BCON key.
Once he sees the MYPOSIT showing that the central DIGI has digipeated him
(to everyone else and all other D7's), then he can move on to update the
other 5 platoons in his company..
This works Indoors and out, and since many of these events are in the gym,
the pool, the field house, this solves the GPS problem. The only things
with trackers were the buses, boats, and trucks.
The Captain in charge was blown away. Seeing over 40 things all updated in
real time on the UIview map in the HQ press box was fantastic.
DETAILS. Actualy it wasnt quite that simple. Look at the map and you
will see that actually the variable digits in LAT and LONG were 38-5X.xx
and 76-2Y.yy so that is why we designed the GRID area into six difference
blocks for the combos of X and Y that also had to be changed if you went to
another block.
PREFORMATTED POSITS.
But it was even easier actually. We put D7's at key locations and their
job was to report the arrival and departure of platoons in their general
vicinity. Thus that operator would pre-enter the LAT/LONG of the three
events within his view into the 3 POSITS of the D7 and then simply change
the Platoon PLn number and select the right POS and hit BCON.
Users were also told to randomize the LSB a little bit so that multiple
platoons at one site could be resolved. Most of these venues covered many
hundreds of feet so this was entirely consistent..
Anyway, think outside the box. APRS is a position reporting system for
special real-time events. It was always assumed that OBJECTS would be the
majority of moving things on the maps and that trackers were only used for
things that couild actually carry them. That is why APRS was supposed to:
1) Treat OBJECTS and STATIONS identically so that they can be moved as
needed by anyone with current knowledge.
2) Dead reckon anything that was moving so that they didnt need updating
until they generall changed course or speed or reached their
destination.
3) All objects would be transmitted on a decaying algorithm so that freshly
moved objects were freshly transmitted and older objects used less and
less air time.
Since we found that UIview had too simplistic of an object transmission
algorithm that would either flood the channel all day long withh too many
retransmissions or would have too much latency if we reduced it (fixed
rate). We used APRSdos for moving and updating objects. In APRSdos the
update rate halves after every transmission per object So that in just a
few minutes, the rate is down to one packet per10 or 30 minutes depending
on how long since it was last updated...
Bob, WB4APR
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
