| |
ZL3AI > APRDIG 12.06.04 21:15l 533 Lines 21468 Bytes #999 (0) @ WW
BID : 3441-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 06, 9/9
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040612/1901Z @:ZL3VML.#80.NZL.OC #:25702 [Chch-NZ] FBB7.00i $:3441-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: [ Robert Bruninga ] APRS upgrades to accomodate OPENtrack
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Sun, 06 Jun 2004 22:11:51 -0500
X-Message-Number: 137
>OK fine. As soon as we get this done we will let you
>know. Until then, honor the existing users of APRS
>by not transmitting BINARY on the APRS channel...
Bob, you know this is a simple text file change for most APRS software
implementations. There are some APRS applications that might need to do
something in software, but I think that would be very very small minority.
You didn't jump up and down and tell all the IGATES to stop sending packets
until everyone of them had a fix for MIC-E decoding did you? It did cause a
lot of discussion and a lot of people had to do a lot of investigation and
work to get rid of that issue.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: RE: APRS extensibility and OPENtrack
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 20:17:05 -0700
X-Message-Number: 138
>We told you it would cause problems for us, and it seems
>unfair for you to then insist that we all must quit
>using APRS or write new APRS code so that it wont
>be harmed by OPENtrack on the APRS channel...
Bob, you're grossly exaggerating the situation and you know it. Aside from
the user who CHOSE to run OpenTRAC, ONE SINGLE USER has reported ill effects
from the event. We've identified the problem, presented the solution, and
contributed a bug fix to the HamHUD code for good measure.
A significant percentage of APRS users in that portion of the country were
exposed to more OpenTRAC traffic than has ever been seen on 144.39 before,
and one user was inconvenienced because of a pre-existing firmware bug.
To suggest that I'm insisting APRS must be abandoned or changed to coexist
is absurd. NO APRS code need be changed at all - it's a simple TNC
configuration change to ensure complete immunity to cross-protocol
interference. Even with that simple step neglected, it still requires an
error in the parser to cause a problem.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: B2V path
From: Greg Kulosa <greg@kulosa.org>
Date: Sun, 6 Jun 2004 20:16:12 -0700
X-Message-Number: 139
>>In my example of Baker to Vegas, we need to use 3 Digi's to get a
>>packet from the start line to Netcontrol in Vegas.
>
>No, 2 digi hops is plenty for B2V rf _and_ inet purposes. WIDE2-2 alone
>works fine there and most of the Western US (at least). Those users
>routinely exceeding two digi hops (and/or transmitting too often) are not
>the best role models for our VHF network, nor demonstrating the best amateur
>practice.
Really? Can you show me the 2 Digi's that will get a packet from Baker, CA
into Las Vegas, NV? (An RF-only path, not including the Internet). I know
the terrain, and I imagine it would be tough (lots of tall mountain
ranges).
Besides, I was making a general point about having the new
Digi-maintained-object thingy support a large geographical network where
maybe you need more than one Digi to cover the area involved.
If the Digi only re-transmits the object DIRECT, then every participant may
not see it, if the area is large, and you can't hear that particular Digi
directly.
Cap, were you at B2V this year? What team do you support?
Greg Kulosa
N1NSY
----------------------------------------------------------------------
Subject: Re: DX spots on APRS!
From: Jeff King <jeff@aerodata.net>
Date: Sun, 6 Jun 2004 23:29:09 -0400
X-Message-Number: 140
On Sun, 6 Jun 2004 22:48:26 -0400, Steve Dimse wrote:
>On 6/6/04 at 9:19 PM Jeff King <jeff@aerodata.net> sent:
>
>>You want to see me on a map, type my call into aprsworld. I don't
>>transmit enough on 144.39 for FINDU to typically hold it, + no
>>gateways near me, and more often then not, I am just puttering
>>around.
A true statement, don't you agree?
>You are right, findU does not hold positions for at least 18 months
>as APRSworld does, the last time wb8wka was heard there was January
>11, 2003!
That is my APRS position of 802.11b station and was hand entered. Please
see the sidebar I authored in HSMM article QST April 2003 for more info.
http://www.arrl.org/tis/info/pdf/0304028.pdf
>findU does, however, hold positions for 120 days, raw packets for 70
>days, and weather since April 2001. There are no packets, other than
>the obsolete, unregistered version of WinAPRS (2.51) that just fired
>up on TCP as wb8wka-1...but that must be someone impersonating
>you..
Nope, that is me, and it is a >paid< registered copy that I use every so
often. I put it on the internet tonight to jerk some chains, and apparently
I succeeded!
>.surely an enlightened soul such as yourself would not use
>WinAPRS!
Why the obtuse attack on WinAPRS? I certainly haven't attacked the Sprouls
and I don't see why you would. Keith and Mark have always treated me well,
so I just don't see your reason for trying to slam their program, unless of
course that is your opinion... it certainly is not mine.
>True enough, you do live in an APRS hole, but there is activity
>within 30 miles of you in nearly every direction, I find it hard to
>believe you haven't driven 30 miles in the last 4 months.
I drive 100's of miles each week. Remember the FINDU privacy debates some
years back? NOGATE? How am I not being consistent here? I CHOSE not to, and
it is none of your business. Having a intense professional interest in
GPS/AVL and wanting to play kissy face with FINDU, are mutually exclusive,
thank you.
>Don't blame findU or the APRS network...
I wasn't "blaming" anything FINDU or APRS network in this thread. I was
trying to stop the flow of misinformation regarding OpenTrak.
BTW, what you and a few others are doing is a common tactic, if you can't
defend your position, then get personal. You last message to Scott is a clear
example of that.
>you simply find more
>pleasure in attacking the APRS establishment than in using APRS.
Ya know, your right. I think the establishment needs someone to shake it up.
I'm glad to see alot more then me are doing that now!
>You
>shouldn't be ashamed of that, my life would be boring without you to
>spar with!
I'm not ashamed of it, I do it on purpose, learned alot in the process and
even change my mind about some stuff. Don't mistake technical interest in ham
radio to an egotistic or social interest in ham radio. APRS is mostly about
social interest, I'm more on the technical end, and am not at all worried
about deflating some of the sacred cows on here. I've really got nothing to
loose, do I?
Read Fountainhead from Ayn Rand if you want a little insight here.
Now tell me how this relates to the OpenTrak discussion?
Did you observed first hand, any RF side problems with OpenTrak?
How did the fixes to FINDU work out, that James relayed the other day?
Thanks
Jeff
----------------------------------------------------------------------
Subject: RE: The NEXT Greatest thing to APRS!
From: Sean Jewett <sean@rimboy.com>
Date: Sun, 6 Jun 2004 21:57:00 -0500 (CDT)
X-Message-Number: 141
On Sun, 6 Jun 2004, Scott Miller wrote:
>>WHy do it the hard way when EVERYONE already
>>has a TOUCHTONE in their hands and can HEAR
>>the VOICE responses of the APRStt server...???
>
>Because it's freaking tedious! My cell phone lets me use shortcut macros,
>it's got the letters printed on the keys, I can see exactly what I'm typing,
>and I still find it horrendously inefficient and annoying to send more than
>a'yes' or 'no' response.
Having just read thru the APRStt overview...
>I'm not saying APRStt is without merit. By all means, keep working on it if
>it works for you. I just haven't seen enough utility in the system to make
>it worth messing with. Either you're making people enter long strings of
>DTMF digits, or you're making them figure out obscure message features of
>their radios.
I agree. I'd never remember half of what I was wanting to do. I'd find
myself in the middle of a DTMF-fest and forget where I was going.
My thoughts on ways to make it easier (at least useful) are as follows:
Allow everyone that wants to play to register for their own tt-id, ala
IRLP. This info would be kept on a central website. At a minimum a 4
digit id, at worst 5 digits. The idea is that we cut down on the DTMF
that a person has to press.
Allow users to define their codes. Allow users to have up to say, 99
codes. These codes could be triggers (ie, send an email), posits,
messages, etc. The users defines what they are going to be.
Thus, a user can access the TT system anywhere it's available and use
their codes. All they would need to do is make sure the freq is clear,
punch in their tt-id and then their two digit code.
So, if I were user 901 and had a predfined code of 73 to indicate I was
turning off the radio (say, for a special event) I could enter
090173
And of course, voice id to keep it legal.
We could even put a star in there to delineate the tt-id from the message
number.
The downside is that it will rely on the internet or a system with a
mirror of the central server. It's quite possible to mirror the server so
that there's no single point of failure. That said, I don't see that as a
major downside.
The problem with this and APRStt is the overall usefullness. I like the
idea but I'm not quite convinced that if people are willing to be as cheap
as to avoid a D700 or D7 that this is really the app for them. Likewise,
email or phones are just as handy, especially if there's no tt gateway
(APRStt or my proposal).
I could see where this would be good for a special event but making my
proposal work for something like this would be way more work than someone
checking in simplex or via a repeater saying 73.
>Granted, the barcode idea has issues, but I think it's workable. I'm pretty
>sure you could even hook up an off-the-shelf barcode wand to a KPC-3+ and
>make it work with no software changes - just use the gps head features to
>extract pre-formatted APRS packets from an appropriate barcode. Just
>something to think about...
I thought about doing it with Hansen's D700 interface and realized one
thing, he encourages people to type slowly because he's emulating
keypresses (ala Bob's APRStt though not the same) on the D700 microphone.
Keyboard wedges would overflow the buffer so to speak. You're right, it
could be done with a KPC3+ but I'm not going to go out and buy one new
when I could double my money and get a D700.
Sean...
--
The punk rock will get you if the government don't get you first.
--Old 97's
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
KG4NRC http://www.rimboy.com Your source for the crap you know you need.
----------------------------------------------------------------------
Subject: RE: DIGIpeater OBJECTS
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 20:33:51 -0700
X-Message-Number: 142
>>I wasn't asking for a digipeater implementation.
>Now I am totally confused. I thought the whole idea was
>for the digi (which can hear everything and is the only
You understand that part right, I'm referring to the fact that you stated
this goal could be accomplished with no changes to the spec, using only the
object expiration feature and decaying transmit algorithm. Maybe you
misunderstood what I was suggesting - in any case, there's no further point
in arguing that point. So let's move on...
>No, nothing to do with messages. The originator simply
>transmits the "cache request" using the existing APRS
>object format, only use your idea of the special TOCALL
>Yes, on the output of the digi, the digi version of the object
>would now use the common APxxxx TOCALL. Or maybe
>even better to have the digi retransmit it now using APOBJ
>so that it is obvious to all observers that it is a DIGI object now...
But by having the client transmit with an APxxxx tocall, we can still be
sure that a non-caching digipeater will still retransmit a packet and have
it displayed as normal.
Here's how I see it working:
Case 1:
Client transmits a posit/object/whatever to APxxyz
Dumb digi picks digipeats packet as usual
Other clients see the packet as usual
Originating client doesn't cached response, continues beaconing as normal
Case 2:
Client transmits a posit/object/whatever to APxxyz
Caching digi stores packet, digipeats it to APqqyz
Other clients see the packet as usual
Originating client sees APqq response, stops beaconing and just listens
And later, any of the following happens:
a. Client sends updated packet to APxxyz and has new data cached
b. Client sends updated packet to normal TOCALL and data is removed from
cache - useful if the data becomes dynamic
c. APqqyz counter shows expiration near - client resends packet to have it
cached again
d. Digi dies. Client no longer sees cached transmissions, starts sending on
its own again
Now, I just wish we could get Kantronics to support this sort of thing to
start making use of all that RAM they've got.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: [ Robert Bruninga ] Re: [ Robert Bruninga ] OPENtrack for
programmers, APRS for users
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Sun, 06 Jun 2004 22:33:58 -0500
X-Message-Number: 143
>Ah so now we double the load on the APRS channel
>by transmitting BOTH open track and APRS! Wow,
>how that will do great things for an already saturated
>channel..!
Bob, you are so emotional charged about this issue that you just can't let go
of the fact that regional packet radio users will make decisions themselves
about how to use their resources. Different things will happen at different
rates in different places. People that need to work together will work
together. They might work together with APRS, maybe OpenTrack, or maybe even
both running simultaneously.
My local network is not saturated. If yours is, you need to work that issue
based on how the channel will be used in your area. If you need a second
frequency, so be it.
>>The experiments will continue to happen, and if there
>>is a leason to be learned, I'm sure it will be learned.
>>But, who will learn which leason is left to the future...
>
>Good, when you learn all those lessons and will no
>longer crash or interfere with existing users, come let
>us know. Then we will see if we are ready to throw
>away all our kenwoods, our trackers, our Mic-E's
>and out KPC-3 trackers... and invite you onto the
>APRS channel.
I'm not going to get emotional about this Bob. Its not the APRS channel. It
is 144.390mhz. The presense of OpenTrac on that frequency is not going to
keep you from using APRS on that frequency, in any way. The presense of
OpenTrac will be completely invisible as being OpenTrac traffic to those who
have properly configured their TNCs.
>In the meantime, do not interferer with an existing
>net with a known and published protocol, and with
>known problems with non-compatible packets..
The OpenTrac packets are completely compatible with the network on 144.390mhz.
They are not compatible with some stations which have not taken the PID
features of AX.25 seriously. Some users of 144.390mhz have TNCs configured to
receive all packets in text mode. We've figured out how to make this a
non-issue for those users that were affected and have reported the issues
known so far.
Apparently for the past 22 years, everyone has not been reading the AX.25 spec
and providing TNC configurations in their APRS software distributions that
make sure that the PID handling was correctly setup. Luckily, the kenwood
engineers are smarter than the average bear and did properly handle the PID in
the packet.
The TNC manuals are highly technical in nature. One needs to understand the
ins and outs of the AX.25 protocol and how it has been used for TCP/IP and
other network protocols, so that you can understand where all the options have
come from. It doesn't surprise me that we've got this far with this issue
still present in the design of a system thats been around for more than 10
years. But, I am glad that this issue came to a head. Now, we can have a
more robust APRS system.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: [ Robert Bruninga ] OPENtrack for programmers, APRS for users
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Sun, 6 Jun 2004 23:44:22 -0400
X-Message-Number: 144
Bob,
Why is implementing both in the same software shooting one's self in the
foot??? I don't get it?
Eric KF4OTN
-----Original Message-----
From: Robert Bruninga [mailto:bruninga@usna.edu]
ABSOLUTELY, so they should NOT be required to have to implement both APRS
***AND*** OPENtradk.. To do BOTH is shooting one's self in the foot. THus,
there is no way to do a clean transistion.
----------------------------------------------------------------------
Subject: Re: DX spots on APRS!
From: Jeff King <jeff@aerodata.net>
Date: Sun, 6 Jun 2004 23:37:09 -0400
X-Message-Number: 145
On Sun, 6 Jun 2004 22:02:54 -0400, Steve Dimse wrote:
>On 6/6/04 at 8:12 PM Bill Diaz <william.diaz@comcast.net> sent:
>
>>Haven't seen Jeff on APRS in years. Doubt that he has anything on
>>144.39, not even mobile. Yep, just looked on the map, no Jeff.
>>Can't find him on FindU either Wonder if he will even bother to
>>run OT?
>>
>Doubt it, but you can bet once opentrack has enough users he'll
>start giving Scott a hard time ;-)
Actually, if you check the OpenTrac-spec archives, I believe I already have.
Interesting how some people can bounce ideas off each other, and even agree
to disagree, without it getting personal.
Scott doesn't run the OpenTrak process like the APRS "process". Parties can
make input, and are taken seriously. None of the shucking and jiving we see
here, a friendly group of guys who have a sincere technical interest in AVL
and the hobby. Now, once he has "20,000" users, maybe it will go to his head
and it will be different, but I kinda doubt that.
Lets check back in a year or two and ask him, OK?
Thanks Steve
----------------------------------------------------------------------
Subject: RE: DIGI-OBJECT-MAINTENANCE format
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 20:46:00 -0700
X-Message-Number: 146
>Not at all. Nothign limiting about APRS at all!
>Every single packet the DIGI digipeats uses a
>different TOCALL. It is just as trivial for it to
>insert APOBJx for cached Objects and APDIGI
>whatever when it sends its own ID packet...
What I'm saying is that you can only use TOCALL for one thing at a time. It
can't be a mfg ID, symbol specifier, and cache request at the same time.
Not a big deal for now, but it's a handy place to put things - only one
thing at a time.
Back to the subject at hand...
One further thing I think needs clarification is the from-call used. I'd
assumed the digi would continue transmitting the cached packet using the
original from-call, not its own - and not using object format. Are we on
the same page, or did you have something else in mind?
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: APRS Users beware (part 1)
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Sun, 06 Jun 2004 22:46:38 -0500
X-Message-Number: 147
>THe answer is NONE. And SCOTT fully knows this,
>thus he has said he will continue to support all of these
>existing formats! So then where is this grand-unification
>theory? Its all HYPE. In fact, he just wants to add his
>OWN SIXTH format. Now his OPENtrrack porgrammers
>have to support 6.
>
>There is no advantage even to PROGRAMMERS,
>unless you ABANDON and instantly OBSOLETE
>all existing users, applicaitons, hardware and firmware.
Here's how I see it. Adding OpenTrac support to my APRS softwares is so
trivial compared to the APRS parser, that I've aleady done it (as has Curt for
Xastir and I've heard of others playing with OpenTrac). If I just had an
OpenTrac application, it would be very complicated to add APRS support. You
are going to have a royal pain in basic to pick out the bits and reconsitute
values because basic doesn't excel at that!
But, the presense of OpenTrac doesn't guarentee anything more that a choice.
If people want to use OpenTrac, it's been designed to operate with APRS on the
same frequency using the same UI digipeater infrastructure where the digis
just repeat UI frames. UIDIGI, and other software/hardware that does only
digi 0xf0 packets, will ignore OpenTrac packets.
When the users have decided, then we'll know. Maybe you can get Kenwood or
another manufacturer to release a new APRS device that finishes filling out
the missing features in the Kenwood implementation we have today. If a
manufacturer has a choice between implementing APRS or OpenTrac, and their
radio can use the same infrastructure, then I think that adds value to the
proposition and makes it possible for there to be more competition for such
devices.
-----
gregg@cytetech.com (Cyte Technologies Inc)
---
END OF DIGEST
Read previous mail | Read next mail
| |
