| |
ZL3AI > APRDIG 14.05.04 21:06l 235 Lines 9000 Bytes #999 (0) @ WW
BID : 3242-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 26, 3/3
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<7M3TJZ<SP7MGD<ZL2TZE<ZL3VML
Sent: 040514/1923Z @:ZL3VML.#80.NZL.OC #:24022 [Chch-NZ] FBB7.00i $:3242-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Objects and D7 are easy.
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 26 Apr 2004 13:07:25 -0400
X-Message-Number: 9
*Bob showed how to use a D7 to send an object...
*Brian noted it wasnt really an object but a station simulating an object
*Curt said:
>The major differences are that other people wouldn't
>be able to manipulate the object like they can objects/
>items, and that you wouldn't necessarily know who sent
>the packet out.
Ah, thanks. But this concerns me a little bit. There should be no
difference between the handling of "objects" and stations. They were
intended to be identical, that is, something that has a position and can be
plotted by APRS.
The only difference is that for a Station, the NAME of the "thing" does not
need to be included because it is the AX.25 callsign that is already there
in the header. An OBJECT is just something else (of equal stature) that
just happens to have a name differnet from what is in the sending TNC.
So, it was never the intent of APRS to have any distinction between
stations and objects, they are the same thing. Its just that one uses a
different format to be able to carry the name if it is different from the
TNC. On receipt and after identificaiton of the sender, they should be
treated identically...
I think many implementations of APRS mistake this fundamental lack of
distinction...
Also, Yes, you are correct that the one thing missing in using the D7 or
D700 to make a "pseudo" object is the identificaiton of the sending
station. But this can easily be done in the comment or status text...
Thanks for pointing this nuance out...
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: Timeslotting
From: "Curt, WE7U" <archer@eskimo.com>
Date: Mon, 26 Apr 2004 10:45:22 -0700 (PDT)
X-Message-Number: 10
On Mon, 26 Apr 2004, Scott Miller wrote:
>Timeslotting support is one of those things that's been on my to-do list for
>the OpenTracker for some time, and I'm finally getting a chance to start
>working on it. I know that the TT3 at least supports timeslotting - not
>sure what other devices might do it as well. I want my implementation to be
>as compatible as possible with what's out there already, but this means
>being in agreement with other devices as to exactly what time it is.
>
>Now, on the surface this doesn't seem like a big problem, since the GPS
>receiver provides a very accurate time reference. Trouble is, fractional
>seconds are not indicated in the NMEA sentences, and I can't find any
>documentation to indicate if the time is valid at the start of the sentence,
>the end of the sentence, the start of the paragraph, or some other point.
>If it's referenced to the sentence, it shouldn't be a big deal since it only
>takes maybe 1/6 second to send it. But if it's referenced to the start of
>the paragraph, it might be a second or two.
>
>I've used GPS receivers for precision timing before, but they're specialized
>units with 1PPS and IRIG outputs. And really, being 'right' isn't as
>important in this case as just being in agreement with other trackers. So
>if anyone knows exactly how the timeslotting time is derived in existing
>implementations, please let me know.
Because you don't have that accurate of time coming out, and because real
time and NMEA-sentence-time vary also based on the baud rate of the NMEA
data, you're basically screwed if you're trying to do anything too accurate
with it. Also remember that the time difference between the NMEA data and
the data displayed on the GPS screen can easily vary be 2 or 3 seconds.
Just assume that the data is accurate coming out. Also assume that anyone
using this for time-slotting will have control over other units set up
similarly, and that they will put a buffer in there of at least a few
seconds so that they'll get the desired operation.
For SAR, if we give each one a 5-second window, we should be good.
--
Curt, WE7U archer at eskimo dot com
Arlington, WA, USA http://www.eskimo.com/~archer
"Lotto: A tax on people who are bad at math." -- unknown
"Windows: Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: neat GPS, but not for the faint of heart
From: wes@johnston.net
Date: Mon, 26 Apr 2004 13:51:33 -0400 (EDT)
X-Message-Number: 11
With this GPS:
http://www.garmin.com/products/gpsmap3010c/
And this add on:
http://www.garmin.com/products/gdl30/
you can receive live weather radar maps on your GPS screen from XM radio.
Wes
----------------------------------------------------------------------
Subject: Re: Timeslotting
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 26 Apr 2004 11:16:09 -0700
X-Message-Number: 12
>Just assume that the data is accurate coming out. Also assume that
>anyone using this for time-slotting will have control over other
>units set up similarly, and that they will put a buffer in there of
>at least a few seconds so that they'll get the desired operation.
>
>For SAR, if we give each one a 5-second window, we should be good.
Yeah, I think that's the best I'm going to get. Just update the internal
counter at the end of each sentence after the CRC is verified. There's
bound to be some slop.
Now, what's the desired behavior if the channel is in use during the time
slot? I wonder if a time slot duration parameter might be of use.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Timeslotting
From: "Curt, WE7U" <archer@eskimo.com>
Date: Mon, 26 Apr 2004 12:26:00 -0700 (PDT)
X-Message-Number: 13
On Mon, 26 Apr 2004, Scott Miller wrote:
>Yeah, I think that's the best I'm going to get. Just update the internal
>counter at the end of each sentence after the CRC is verified. There's
>bound to be some slop.
>
>Now, what's the desired behavior if the channel is in use during the time
>slot? I wonder if a time slot duration parameter might be of use.
Yea, treat it like a hash-table hit: Transmit at the next available free
time. Use the same parameters you do if you're not time-slotting in that
case, some hold-off after the channel goes clear then transmit. Perhaps
p-persistence and slottime?
--
Curt, WE7U archer at eskimo dot com
Arlington, WA, USA http://www.eskimo.com/~archer
"Lotto: A tax on people who are bad at math." -- unknown
"Windows: Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: Re: Objects and D7 are easy.
From: "Curt, WE7U" <archer@eskimo.com>
Date: Mon, 26 Apr 2004 13:36:38 -0700 (PDT)
X-Message-Number: 14
On Mon, 26 Apr 2004, Robert Bruninga wrote:
>So, it was never the intent of APRS to have any distinction
>between stations and objects, they are the same thing.
>Its just that one uses a different format to be able to carry
>the name if it is different from the TNC. On receipt and
>after identificaiton of the sender, they should be treated
>identically...
>
>I think many implementations of APRS mistake this
>fundamental lack of distinction...
Per the spec, Objects/Items are allowed to be "taken over" by another
station.
I don't believe there's a provision for that in terms of stations. It's
been a while since I read the entire thing though.
--
Curt, WE7U archer at eskimo dot com
Arlington, WA, USA http://www.eskimo.com/~archer
"Lotto: A tax on people who are bad at math." -- unknown
"Windows: Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: Re: Objects and D7 are easy.
From: Robbie - WA9INF <mwrobertson@comcast.net>
Date: Mon, 26 Apr 2004 17:52:06 -0500
X-Message-Number: 15
Group,
I don't think UI-View32 whould have had these capabilities incorporated if
it wasn't true Curt.. I have had occasion to play with the objects, and
would be very surprised if I could take ownership of someone's home station
and then move it?? That would be plain terrible.. I was going to make this
comment after reading Bob's post and forgot, :-)
So, what's this all about? I will see if I can take over a few stations and
move them...
Robbie
----------------------------------------------------------------------
Subject: Re: Objects and D7 are easy.
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 26 Apr 2004 20:54:16 -0400
X-Message-Number: 16
It was my original intent that stations can also be taken over. Say a
stations GPS and or radio dies, yet we still know where he is and where he
has moved to by other means. We shoul dbe able to hook him and drag him to
his new postiiion for all to see...
Bob
---
END OF DIGEST
Read previous mail | Read next mail
| |
