| |
ZL3AI > APRDIG 25.04.03 09:15l 232 Lines 9478 Bytes #999 (0) @ WW
BID : 1210-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 22, 4/6
Path: DB0FHN<DB0ZWI<DB0CHZ<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<WB0TAX<SP7MGD<
IK6PYS<VK3TE<ZL2BAU<ZL3VML
Sent: 030424/1339Z @:ZL3VML.#80.NZL.OC #:64484 [Chch-NZ] FBB7.00i $:1210-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Predatory Packets
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 22 Apr 2003 13:41:56 -0400 (EDT)
X-Message-Number: 20
On Tue, 22 Apr 2003, Miller Scott Contr 30SCS/FTI wrote:
>... allowing ECDSA signatures in OpenTRAC.... to.... at least make sure
>that all subsequent updates to an object came from the same source....
APRS is not unique here. Sorting and correlating multiple reported
objects from multiple reporting stations has been the number one
problem in Navy Combat systems from day one. For APRS, that's why I
purposefully chose for anyone with more recent data to update an
existing object (that replaces the other) rather than depending on only
the original source..
Limiting updates to objects to only the initial reporting station in most
cases creates more problems with old and missleading data than does the
approach we took and that is to let anyone with new data take over control
of the object. All APRS client software is supposed to do this and to
keep track of who is the current object originator.
>As for the duplicate naming..., OpenTRAC identifies every object by an
>8-byte ID formed from the callsign/ssid and a 16-bit unique ID...
Allowing for more and more unique lables for the SAME object is exactly
the problem that the Navy learned was the worst part of the problem.
Having 10 different objects on a map from 10 different reporting
platforms with 10 different designations at 10 different times guarantees
total confusion. Objects must be correlated and combined so thta only
the most recent and accurate is displayed.
This is why Dead Reckoning is absolutely essential for any tactical
display on moving objects. If all objects are DR'ed on receipt then they
are not all spread out on the map, but all the ones for the same object no
matter how long delayed (within reason) then are easy to see are the same
object..
A lot that went into APRS(dos) concepts came from 20 years of lessons
learned and experience in combat systems design and display of data
(objects) from multiply reporting stations in real time...
de WB4APR, BOb
----------------------------------------------------------------------
Subject: Re: Predatory Packets
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Tue, 22 Apr 2003 17:51:44 -0000
X-Message-Number: 21
Unless otherwise flagged, an object wouldn't be protected from third-party
updates. Hopefully clients would have the sense to notify you of duplicate
display names when you're creating an object, so you'd see that someone's
already created the object. At the very least, I think it's no worse than
APRS handling of objects. It still comes down to users paying attention to
what's already there.
Scott
----------------------------------------------------------------------
Subject: Re: Predatory Packets
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 22 Apr 2003 13:53:50 -0400 (EDT)
X-Message-Number: 22
The below considerations were taken for things like moving objects at an
event where the object passes in and out of view of different stations.
They do not apply for things like Hurricanes where we would want
to ignore all sources but the "right one"..
So dont missinterpret what I said below with respect to that thread. Bob
On Tue, 22 Apr 2003, Bob Bruninga wrote:
>APRS is not unique here. Sorting and correlating multiple reported
>objects from multiple reporting stations has been the number one
>problem in Navy Combat systems from day one. For APRS, that's why I
>purposefully chose for anyone with more recent data to update an
>existing object (that replaces the other) rather than depending on only
>the original source..
>
>Limiting updates to objects to only the initial reporting station in most
>cases creates more problems with old and missleading data than does the
>approach we took and that is to let anyone with new data take over control
>of the object. All APRS client software is supposed to do this and to
>keep track of who is the current object originator.
>
>>As for the duplicate naming..., OpenTRAC identifies every object by an
>>8-byte ID formed from the callsign/ssid and a 16-bit unique ID...
>
>Allowing for more and more unique lables for the SAME object is exactly
>the problem that the Navy learned was the worst part of the problem.
>Having 10 different objects on a map from 10 different reporting
>platforms with 10 different designations at 10 different times guarantees
>total confusion. Objects must be correlated and combined so thta only
>the most recent and accurate is displayed.
>
>This is why Dead Reckoning is absolutely essential for any tactical
>display on moving objects. If all objects are DR'ed on receipt then they
>are not all spread out on the map, but all the ones for the same object no
>matter how long delayed (within reason) then are easy to see are the same
>object..
>
>A lot that went into APRS(dos) concepts came from 20 years of lessons
>learned and experience in combat systems design and display of data
>(objects) from multiply reporting stations in real time...
>
>de WB4APR, BOb
----------------------------------------------------------------------
Subject: Re: Predatory Packets
From: "Spider" <spider@rivcom.net>
Date: Tue, 22 Apr 2003 11:18:06 -0700
X-Message-Number: 23
----- Original Message -----
From: "Bob Bruninga" <bruninga@usna.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 10:41 AM
Subject: [aprssig] Re: Predatory Packets
>On Tue, 22 Apr 2003, Miller Scott Contr 30SCS/FTI wrote:
>
>>... allowing ECDSA signatures in OpenTRAC.... to.... at least make sure
>>that all subsequent updates to an object came from the same source....
>
>APRS is not unique here. Sorting and correlating multiple reported
>objects from multiple reporting stations has been the number one
>problem in Navy Combat systems from day one. For APRS, that's why I
>purposefully chose for anyone with more recent data to update an
>existing object (that replaces the other) rather than depending on only
>the original source..
I have a suggestion.....
ITEMS. (Curt...jump in any time) Curt and I did some testing and
playing with OBJECTS and ITEMS here a while back. One thing I learned is I
could not "take ownership" of Curt's items made by Xastir. But he could
mess with my objects at will! UI-View does not do ITEMS to the best of my
knowledge...but if you can't take an ITEM as with what Curt was doing, one
easy problem solved. I would like to ask Roger to implement ITEMS for this
exact reason....but have not asked yet! He has done so much recently....I
am almost afraid to ask!
ITEMS seem to be very "not used" and maybe something to consider. In a
situation that something is "official", others should not have the ability
to change it...period.
Jim, WA6OFT
----------------------------------------------------------------------
Subject: New Earthmate USB ~ Will Work
From: Drew Baxter <droobie@maine.rr.com>
Date: Tue, 22 Apr 2003 15:53:35 -0400
X-Message-Number: 24
---
I do daily digests, so if there's any questions or whatnot about this
please either CC my email address in or send them to be directly if you
can. I don't really participate enough to justify switching to full
message format just yet, thanks.
---
I emailed Delorme to ask about their new Earthmate, because there were some
questions as to if it was crippled (braindead) or if for other reasons it
was too good to be true.
Well, it appears it works the way it's supposed to. I talked to SIRF (The
chipset maker for it) as well as talked to Delorme. There's a totally
other SIRF chipset that is braindead, however Delorme does not use that
particular model.
I can see me owning one for APRS eventually with the serial kit.
I've attached the e-mail from Delorme,. for anyone who has interest.
---Droo (K1XVM)
>Date: Tue, 22 Apr 2003 09:32:45 -0400
>From: Jonathan Braden <jonb@delorme.com>
>Subject: RE: New Earthmate USB
>To: 'Drew Baxter' <droobie@maine.rr.com>
>X-Mailer: Internet Mail Service (5.5.2653.19)
>X-Virus-Scanned: Symantec AntiVirus Scan Engine
>Original-recipient: rfc822;droobie@maine.rr.com
>
>Dear Drew,
>
>Thank you for your interest in our products.
>
>Our new Earthmate GPS will in fact produce the standard NMEA 0183 protocol.
>Please feel free to purchase the device in the comfort of our 30 day money
>back guarantee.
>
>Thank you for your inquiry.
>
>Sincerely,
>Jonathan Braden
>DeLorme Mapping
>Yarmouth, Maine
>www.DeLorme.com
>1-800-561-5105
>
>>-----Original Message-----
>>From: Drew Baxter [SMTP:droobie@maine.rr.com]
>>Sent: Thursday, April 17, 2003 4:14 PM
>>To: sales
>>Subject: New Earthmate USB
>>
>>The Sirfstar IIe-LP chipset in the new Earthmate appears to not require
>>the
>>computer to operate, unlike one of their other chipsets. Is it safe to
>>assume that with the serial cable, this device would output NMEA sentences
>>like a traditional GPS unit would? I realize that Delorme doesn't take
>>support responsibility for this kind of use, but a lot of Ham operators
>>have interest in the unit for tactical tracking operations. A low power
>>GPS receiver that shoots NMEA out without assistance of a computer, would
>>sell really well.
>>
>>Thanks.
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
