| |
ZL3AI > APRDIG 25.04.03 09:13l 269 Lines 10849 Bytes #999 (0) @ WW
BID : 1209-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 22, 3/6
Path: DB0FHN<DB0ZWI<DB0CHZ<DB0ERF<DB0ROF<DB0CWS<DB0SIF<DB0MRW<OK0PKL<OK0PPL<
RZ6HXA<SP7MGD<VK7AX<ZL2BAU<ZL3VML
Sent: 030424/1337Z @:ZL3VML.#80.NZL.OC #:64483 [Chch-NZ] FBB7.00i $:1209-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: [aprssig] RE: a few basic questions....
>The point I was trying to make was not just having radios on the air, its
>finding ways to put the capability to good use such as in support of your
>local EOC, Ham Club, Kids Club, Scouting events, Weather spotting, Search
>and rescue, Direction finding every obnocious signal, Putting traffic
>accidents and traffic jams on the map, March of dimes, parades, biking,
>hiking, boating, cruising, flying, Ballooning, Radio remote control,
>Science projects, etc..
You forgot Fishing! On FireNet, we've had the request for lake water
temperature so that fisherman could gather MORE DATA to ingest so that they
may have a better chance at catching something! More is Better!
However....changing the subject a little.....
Tell me your thoughts and the history on ITEMS....no objects....but ITEMS.
Jim, WA6OFT
----------------------------------------------------------------------
Subject: Re: WinAPRS & UTM Coordinates system
From: Keith Sproul <ksproul@rci.rutgers.edu>
Date: Tue, 22 Apr 2003 09:37:34 -0400
X-Message-Number: 13
WinAPRS displays UTM for the stations in the POSITION LIST. It has done
that for years.
There have been very few requests for UTM, except maybe from a military
interest MANY years ago..
Since we already have UTM in the program, making it display UTM in other
places would be very easy.
We also have some ongoing work for UTM in conjunction with map data.
(This is stuff the user doesn't see and doesn't WANT to see).
If people would like more UTM stuff, let us know where (and how) you want
it used and we will incorporate it.
Please send suggestions to me privately and not to the list. Also, PLEASE
use the email address below and not this one.
wu2z@amsat.org
Keith Sproul
--
Keith Sproul ksproul@rci.rutgers.edu WU2Z
Student Housing Network Coordinator 732 445-3695 W
Rutgers University Computing Services
----------------------------------------------------------------------
Subject: Re: WinAPRS & UTM Coordinates system
From: "Spider" <spider@rivcom.net>
Date: Tue, 22 Apr 2003 07:15:08 -0700
X-Message-Number: 14
----- Original Message -----
From: "Keith Sproul" <ksproul@rci.rutgers.edu>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Cc: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Tuesday, April 22, 2003 6:37 AM
Subject: [aprssig] Re: WinAPRS & UTM Coordinates system
>There have been very few requests for UTM, except maybe from a
>military interest MANY years ago..
>
>Since we already have UTM in the program, making it display UTM in
>other places would be very easy.
>
>We also have some ongoing work for UTM in conjunction with map data.
>(This is stuff the user doesn't see and doesn't WANT to see).
>
>If people would like more UTM stuff, let us know where (and how) you
>want it used and we will incorporate it.
Keith,
Any type of Search and Rescue operation can easily use UTM. It's very easy
to learn for the typical searcher and requires a minimum amount of
training. Lat/Long is easy too, but for 99% of the people out there tools
are very necessary to plot a point on a map. Many times a searcher has
nothing but a pencil and a map, which makes UTM possibly a better choice.
Most everyone can figure out right angles and draw them! Trying to get the
correct diagonal for determining longitude with out the correct slider for
the map you are using is not easy nor is it practical. Politics do come
into play. For example, I've been told the "powers that be" in SAR in
Arizona...probably law enforcement...voted to use lat/long as their
standard. And because of the that we have to live with it. During a
recent multi-county search, my county learned other counties in Arizona did
not stick to the ruling and use UTM. In the IC we were receiving reports
in UTM and Lat/Long and it challenged us somewhat. We overcame the
challenge but at a point in the exercise we ending up using a commercial
based mapping program...and I headed for my paper maps!
It's VERY difficult for me to explain what is needed to a programmer that
has no experience in the field that he is programming. APRS programs are
growing slowly in the right direction...but if the programmers were out
their in the field with us grunts....the programs just might change a tad!
I mean no dis-respect when I say this....I just have a very hard time
explaining what changes I see are needed.....you have to be there and be put
into situations that require specific applications in order to know what you
need to do. Curt and Roger have been busting butt making some very nice
changes and the programs are just out of this world! Hopefully, you've been
watching and listening!
Jim, WA6OFT
----------------------------------------------------------------------
Subject: Re: Recommended Standalone TNC for APRS
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Tue, 22 Apr 2003 15:32:50 -0000
X-Message-Number: 15
I found a good soundcard-based scope/analyzer program to test my FSK
generator with. I still need a 20MHz or better scope for non-audio stuff,
but the soundcard works just fine for now.
Just about got a prototype working - it's doing much better now that I
installed the resistors for the D/A ladder in the right order. =] I've
still got a bit more noise than I'd like in my 2200 hz tone - I think
round-off errors are causing some phase noise. The 1200 hz tone is an even
multiple of the clock rate, though, and comes out pretty clean.
Fun stuff... quite a learning experience.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Predatory Packets
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Tue, 22 Apr 2003 10:51:13 -0500
X-Message-Number: 16
>Just because those objects are on the air, doesn't
>mean that your client software has to display them. You could select to
>plot only ANA from the known good source, and not N4BAD or KD4LID's
>representations of ANA. (are those real callsigns??, hoping not to pick on
>anyone too badly) ;-) In this way, not just storms, but hey, how many WATER
>trucks, or POLICE1, or RUNNERs are there at any one time?
For those just misreporting information accidently, this would work. The
devious or mischievious would just use the official call in their packet...
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: RE: a few basic questions....
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 22 Apr 2003 11:58:29 -0400 (EDT)
X-Message-Number: 17
On Tue, 22 Apr 2003, Spider wrote:
>Tell me your thoughts and the history on ITEMS....no objects....but
>ITEMS.
The OBJECT format included a 7 byte date/time stamp and a fixed length 9
byte name. When I came up with .POS files for placing non-time dependent
items on the APRSdos maps (like Hospitals, EOC's, Shelters, HAM stores,
etc), I dropped the time stamp and made the name be variable length. (See
any .POS file.
So then, having the .POS file format, why not transmit it over the air for
objects that have no time significance. and save an average of about 10
bytes. Only one problem, some clinet software does not decode it
properly, so I dont use it on the air much.. cuz its just too hard to
figure out who can see it properly and who cant.
Bob
----------------------------------------------------------------------
Subject: Re: Predatory Packets
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Tue, 22 Apr 2003 17:15:39 -0000
X-Message-Number: 18
I've been looking at the possibility of allowing ECDSA signatures in
OpenTRAC. Without a real public key infrastructure you wouldn't necessarily
be able to validate someone's identity, but you could at least make sure
that all subsequent updates to an object came from the same source. Or
someone who'd been given the private key, anyway.
As for the duplicate naming thing, the current version of the OpenTRAC spec
identifies every object by an 8-byte ID formed from the callsign/ssid and a
16-bit unique identifier. In most cases you don't actually need to provide
the whole ID - just a tag saying 'next object begins.' Display names are
specified separately. A client might choose to show both the ID and display
name... maybe '32RESCUE2' in big letters, and 'N1VG-2:003a' in smaller
print. Or just the callsign/ssid part.
Not sure how any of this helps APRS, but it's being given some thought on
the OpenTRAC side anyway.
Scott
N1VG
It is by caffeine alone I set my mind in motion,
It is by the beans of Java that thoughts acquire speed,
The hands acquire shaking, the shaking becomes a warning,
It is by caffeine alone I set my mind in motion.
----------------------------------------------------------------------
Subject: Re: Digi bulk retransmits again
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Tue, 22 Apr 2003 17:34:36 -0000
X-Message-Number: 19
I don't know about your area, but from watching traffic around here, I think
you're going to be doing a lot of scrolling on your Kenwood anyway if you
want to see anything.
Here's how I'd implement this:
On receive, a client checks to see if the packet is from itself, to APSTRD
(for example). If so, it saves the packet and a timestamp.
On transmit, the client checks the saved packet to the outgoing packet. If
the packets are identical in content, and the timestamp's less than one
network cycle old, it supresses the outgoing packet.
If it's not supressed, it goes out to APSTOR (for example). A wide digi
configured appropriately would add the packet to its cache, as well as
passing it on as usual. Retransmits would use a preprogrammed path
(probably none), and the APSTRD tocall.
Wide digis could also choose whether to store the packet or not based on how
many digis are already in the 'used' portion of the path (i.e., store only
local or semi-local traffic).
It's backward compatible with everything and fails gracefully... within a
network cycle of the wide digi ceasing retransmits, the client picks it up
again.
One other suggestion I'd make is an 'APQRT' tocall to indicate a final
report before going off the air. That'd let you clear the cache from the
wide, or maybe the wide could retain it for some time so everyone knows
you're QRT.
Yeah, it's not suitable for all circumstances. But I don't think there's
anyone out there who can hear my home station and NOT one of the local
WIDEs. I'm certain there are mobiles out there I can't hear directly,
though, that I'm going to step on (or get stepped on by) that I could avoid
using a digi-based retransmit.
Scott
N1VG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
