|
ZL3AI > APRDIG 10.06.04 10:56l 508 Lines 17051 Bytes #999 (0) @ WW
BID : 3424-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 04, 8/8
Path: DB0FHN<DB0FOR<DB0MRW<DB0WUE<DK0WUE<DB0RES<ON0AR<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040610/0805Z @:ZL3VML.#80.NZL.OC #:25593 [Chch-NZ] FBB7.00i $:3424-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: OPENtrack incompatibilities
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 22:20:22 -0400
X-Message-Number: 166
>>>"Scott Miller" <scott@3xf.com> 6/4/04 9:41:23 PM >>>
>>1) store-and-forward: Not applicable on APRS which
>>is a real-time system for tactical real-time local events.
>Not a problem, because OpenTRAC's not APRS. See,
>I couldn't have done that at all in staying within APRS.
Its not APRS we are talking about here it is the use of the NATIONAL
REAL-TIME APRS infrastructure we are talking about in the above quoted
text! And you just made my point. Store-and-forward does not mix with
the APRS real-time network!
>Consider the example of multiple SAR teams covering
>their assigned search areas. Thanks to the terrain,
>they're out of direct contact 80% of the time. With this
>implemented, they'd be able to forward on track histories
>of their out-of-contact time...
>Useful, yet not within the bounds of what you'll allow in APRS.
Ah you give up too easily. All of that can easily be incorporated into an
APRS user format. Just ask and we will be happy to assign you a user TYPE
character for such an APRS packet.
>>2) backbone routing: No one ever opposed this.
>>APRS can do this just fine. In fact, we have propsed
>>many methods that will work. In fact, Steve's APRS-IS
>>does that very well right now...
>>Can it allow digis to negotiate filtered links along RF
>>backbones? Or allow a station to request that it be
>>gated to a given geographic area?
Sure APRS could do that. Just write the digi code and define a user format
packet for communicating the required information...
>>3) digipeater-maintained objects: Crazy idea. OBJECTS
>>in APRS are supposed to be live, vibrant, moving things
>Bob, how many of the things on your APRS screen are moving right now?
Not nearly enough...
>How many of them never move at all?
Too many!
>This is EXACTLY why I can't work within the framework
>of APRS, because if it doesn't have your stamp of
>approval, we can't even experiment with it.
That makes no sense. The reason houses done move is because nobody right
now is uising APRS for a special event. APRS is designed to do that under
stress, not watch houses grow weeds.
And also nothing in the above is in any way restrictive to you...
>same non-moving objects, then they probably shouldnt
>be APRS objects but should be map features that should
>be applied with local map overlays.
>Your opinions. Not necessarily bad ones, but opinions
>that mean I can never reasonably expect to try the
>things I want to try within APRS.
I dont see how you draw that conclusion. You are welcom to use the APRS
protocol for experimenting. I love to see new applications taking
advantage of the tremendous flexibiility offered within the APRS
protocol...
Bob
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: Wes Johnston <wes@johnston.net>
Date: Fri, 04 Jun 2004 22:20:08 -0400
X-Message-Number: 167
NOt sure of the context Scott intended here, but "store and forward" in the
eyes of the FCC includes digipeating. I asked them about this specific
question in regard to MURS. Store and forward means not simultaneously
retransmitted (like a voice repeater). I can post their response if needed.
Wes
At 06:19 PM 6/4/2004, Robert Bruninga wrote:
>1) store-and-forward: Not applicable on APRS which
>is a real-time system for tactical real-time local events.
----------------------------------------------------------------------
Subject: BS
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 22:23:22 -0400
X-Message-Number: 168
Im outta here.
I have a life.
Bob
----------------------------------------------------------------------
Subject: Re: TNC vs PID
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 19:26:33 -0700
X-Message-Number: 169
>Scott, didn't you tell me you pilot a black helicopter for the Army? I'd
like a
>ride if so.
No problem. I'll pick you up after the Illuminati meeting.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: Fw: RE: How about making OpenTrak part of APRS SPEC?
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 19:33:31 -0700
X-Message-Number: 170
>We welcome additions to the protocol that are intended
>to provide new positive aspects to APRS and that dont
>instantly obsolete thouands of users overnight...
You mean the way the introduction of IP v6 has obsoleted all of the IP v4
systems on the Internet?
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: The new MicroTrak project based on the SMT TinyTrak3!
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 19:32:27 -0700
X-Message-Number: 171
Curses, he's beat me to it! =] I proposed a similar board a couple of
months ago... didn't know Byon already had one in the works. Looks like
he's got my new SMT board (or the first prototype at least) beat by a bit
for size.
The Microtrak project in the GPS case looks awesome.
I've still got him beat for upgradability and on-board sensors, at least.
Scott
N1VG
-----Original Message-----
Hi everyone,
We've been beta testing the Surface Mount version of the TinyTrak3 for Byon
for some time.
We've built this into yet another project, and put a website about it up.
We've called this one the Microtrak.
http://www.aprsfl.net/microtrak
If you have questions about the design, let me know.
Seeya,
Dave
KG4YZY
www.aprsfl.net
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 19:41:27 -0700
X-Message-Number: 172
>(On its own network, I would consider OpenTrack a an interesting and even
>worthy innovation.)
We've done very limited experimentation on 144.39. A few land mobile
stations, and two balloons.
Voice Alert isn't APRS either, and it manages to avoid destroying the APRS
network. No one's taking over the network.
Yesterday's flight, thanks to an unusually wide path and short beacon
interval, sent more OpenTRAC packets than have been sent by every other
OpenTRAC station on the planet in the past year, and what did we get? One
flaky HamHud, and a slightly garbled FindU entry.
N6CP-11 flew to over 95,000 feet transmitting OpenTRAC data and no one even
noticed. Let's keep this in perspective, shall we?
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 19:42:24 -0700
X-Message-Number: 173
>>You have the advantage of the HamHud software being easily upgraded,
>>with several active developers. Use that advantage.
>Could probably be upgraded to even handle the Opentrac format as well
>as regular APRS.
If HamHud gets KISS support, I'll be happy to provide the code.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 19:44:08 -0700
X-Message-Number: 174
>>Can you name 3 people that had a problem?
>Or scan for all kenwoods, That should give you
>about 3 thousand on any given day... is that enough?
Funny that none of those 3,000 that 'had a problem' didn't mention it on the
SIG.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Bill Diaz" <william.diaz@comcast.net>
Date: Fri, 4 Jun 2004 21:44:28 -0500
X-Message-Number: 175
Scott,
You claim that OpenTrac can do store and forward, backbone routing, and
digipeater maintained objects yet I can find no documentation for these
features on your site. Do they actually exist? Have they been actually
implemented and tested on the air?
Bill
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 19:47:17 -0700
X-Message-Number: 176
>That was 1998. Few authors honored that request so
>I gave up and teamed with TAPR to help write the spec
I indicated that. I'm aware that things have changed. I'm trying to
present the differences in design philosophy.
>And I even released my SOURCE!
An admirable move.
>And since you can do just about anything within the
>APRS protocol, I dont see why you need to invent your
>own and insisit on obsoleting everyone on the air...
Now, if I was the head engineer at Kenwood, deciding that the next batch of
radios to come out wouldn't support APRS, I can see how you might say I'm
obsoleting people.
Unless you mean by 'obsoleting' making their equipment obsolete by virtue of
the fact that there's a clearly superior alternative. I'll buy that. =]
We've been over a number of points, critical to OpenTRAC's development path,
that you've said outright will never be part of APRS.
Scott
N1VG
----------------------------------------------------------------------
Subject: Compressed posits with wx data
From: "Matt Werner" <kb0kqa@arrl.net>
Date: Fri, 4 Jun 2004 21:45:37 -0500
X-Message-Number: 177
I've asked this before and I don't think I got anywhere on it so I'll ask
again.
xastir allows the transmission of compressed posits. When combined with wx
data, you get a packet like this:
KB0KQA>APX132,WIDE3-2,qAo,W0TVD-10:=/6d9G70,R_{;C216/000g000t061r000P000p000
b10167XU2k
The problem is that findu nor aprsworld will correctly decode that packet.
They will both decode the position correctly but will never continue to
parse to find the trailing wx data. Is the problem in the packet or the
parsers for each site?
Thanks and 73 - Matt
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Brian Riley (maillist)" <n1bq_list@wulfden.org>
Date: Fri, 04 Jun 2004 22:58:59 -0400
X-Message-Number: 178
On 6/4/04 7:15 PM, "Jeff King" <jeff@aerodata.net> wrote:
>WOW.... catching up on some of the posts, and talk about DejaVu! Those are
>EXACTLY some of the complaints when our group first started running TCP/IP on
>the amateur bands back in the mid to late 80's, using Phil Karn's "NET" and
>then later NOS and all its varients.
>
>Somehow, we got by all that, and the hobby was much better because of it. This
>exercise (NET/NOS) even spawned quite a few commercial spin-off's, such as
>Tetherless access, numerous PPP stacks, and other things that hams gave back
>to
>the world.
>
>What heady days!!
>
>All I can say, to Scott, Robert, you and all the other experimenters, is keep
>at it! This is what this hobby is all about, experimenting and advancing the
>state of the art.
Back when I was coding the PRMBS Packet BBS software I included a feature
that let CONVERSE mode users enable in their user profile the sending of
ANSI color escape sequences when they were listing and reading messages,
etc. I was inundated with email from a small group of reactionary users who
said "how dare you cause my screen to turn colors" I want to watch what
other guys are reading but I don't want your colors ... Of course my answer
to that was to add some special code to my own personal copy of the code
that sent a blinking text attribute over the air after a user logged off and
disconnected then turned it off on my own screen. That really got them mad!
Time marches on!
cheers ... 73 de n1bq
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 19:58:38 -0700
X-Message-Number: 179
>I think just about anything can be done within the
>APRS spec, be compatible with existing systems and
>still not break anything.
But only those things that YOU approve of. I stand by my statement that
digipeater-cached objects would be beneficial to the network. You have
absolutely refused to allow work on this, even within the established APRS
specification.
If that's not the case, prove me wrong. Let's start work on the concept
now.
We need:
- A way for the originating station to indicate a cache request, with
expiration and interval
- An acknowledgement indication from the digi, also showing the time till
expiration
- A 'cancel' mechanism to purge the object from the cache
I propose an encoded TOCALL field to indicate cache requests. This means
you can send a packet in an existing format without having to append more
stuff. Cached packets should be digipeated with a different TOCALL, but
with similar encoding, to indicate time remaining.
Any packet sent from the originating station without the cache TOCALL should
flush that station's cached packets.
Comments anyone?
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 20:09:14 -0700
X-Message-Number: 180
>Nope, I dont shoot down anything. But when I see ideas that
>are not well thought out, or that overlook common sense, or
>that are not aware that they already are fully supported in APRS,
One man's opinion.
>And there is nothing in the existing protocol that prohibits
>this. In fact, it is fundamental to the protocl that anyone
>or thing can take over reporting of an object.
See the proposal I sent a minute ago. There's no added traffic, not even to
kill the object. Static objects will always be found in APRS, so getting
rid of them is not a realistic option. As for the decaying rate, why would
the position of a hospital or EOC be any less important or relevant tomorrow
than today? Static objects should have static rates. And the digi's not
fighting so hard to make its traffic heard. Assuming you don't increase the
rate, you're cutting channel load for static objects in half.
>Why? Because you havent taken the time to see how
>to do these simple things in APRS?
Getting something by you that you don't approve is far from simple, Bob.
Someone counted about 50 messages from me in the past day and a half, and
probably at least as many from you, and we aren't any closer to agreement on
anything.
>you can do it anway. The existing APRS object format
>already INCLUDES these capabilities...
It's not just a format change, it's a digipeater behavior change. If it was
solely a matter of formatting at issue, I never would have started the
OpenTRAC project.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: APRS additions to the spec
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 20:16:56 -0700
X-Message-Number: 181
>So why isnt he taking advantage of it instead of trashing
>everything and trying to re-invent the wheel?
>Using the user defined protocols the following
>additions have been implemented on APRS:
Bob, for the sake of everyone here, I suggest that we drop for now the issue
of 'why'. We've gone around and around on the issue. I'll work on a white
paper to give my reasons for the project. You're welcome to write your own
on why it's not needed, or to post a rebuttal on your own site.
Hell, maybe we can do a debate at DCC. Or just rent some of those
inflatable sumo costumes and fight it out - we'll probably accomplish about
the same amount.
Let's spare the SIG the circular arguments and emails every 90 seconds.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: OPENtrack verus APRS format example
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 20:21:36 -0700
X-Message-Number: 182
>Shucks, I can do that in about 3 lines of BASIC. I
>would think anyone could do it... And besides
Been through this, too. Even got some BASIC out of you last time. My
arguments from last time still stand. I'll write my paper, you write yours
if you want.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 20:29:34 -0700
X-Message-Number: 183
I think I sent this reply privately before, forgive me if it's already gone
out... I lost track 30 messages back.
I did not claim that OpenTRAC does that yet. Those are all stated design
goals of the project, relevant to this discussion because they're goals that
Bob doesn't share and opposes in APRS.
On the subject of backbone routing, you should check out PE1RXQ's work on
the subject. His content distribution project was already in the works when
OpenTRAC came along, but he proposed a pretty elegant solution to the
backbone distribution problem. I'm not sure how far he's gone with testing.
Scott
N1VG
---
END OF DIGEST
Read previous mail | Read next mail
| |