| |
ZL3AI > APRDIG 12.06.04 21:33l 805 Lines 31065 Bytes #999 (0) @ WW
BID : 3438-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 06, 6/9
Path: DB0FHN<DB0RGB<DB0MRW<OK0PPL<DB0RES<ON0AR<7M3TJZ<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040612/1900Z @:ZL3VML.#80.NZL.OC #:25699 [Chch-NZ] FBB7.00i $:3438-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: OPENtrack incompatibilities
From: Jeff King <jeff@aerodata.net>
Date: Sun, 6 Jun 2004 18:49:51 -0400
X-Message-Number: 78
On Sun, 06 Jun 2004 18:22:01 -0400, Robert Bruninga wrote:
>>>>Jeff King <jeff@aerodata.net> 6/5/04 1:32:33 PM >>>
>>So too OpenTrak. Now it is really starting to look like a Duck
>
>So then why all this attempt to make them NOT seen by the 20,000
>existing users on the APRS channel?
You mean the decision to use PID 0x77 for OpenTrak? You'll need to ask
Scott the details there, but I suspect he has already gone over that. But
in any case, the broader goals of OpenTrak appear to closely mirror APRS,
just done in a much better way (20/20 hindsight as you called it).
Which is exactly why I said it was a DUCK, it just happens to be a DUCK
whose color you don't care for.
>>>Adding incompatible OPENtrack packets to that network at the
>>>expense of collisions
>>
>>Nope, sorry, CSMA is fully supported in OpenTrac, like I said,
>>basic layer 1 stuff.
>
>But it still takes up channel capacity
Hold on now.... I really can't deal with your chaotic thought process. You
said collisions Bob, I addressed this, now we fly off in some other
direction. But I'll run with it.
Yes, it takes up channel capacity. It takes up LESS channel capacity then a
similar APRS packet conveying the positional data! So given a choice, a ham
is BETTER OFF using OpenTrak then APRS if channel capacity is to be
optimized!
Now, can OpenTrak do everything that APRS can do? Certainly not, it wasn't
designed for this, but in particular mission types, it can do a much better
job.
I'm not sure what your goal is here, I suspect it is to scare folks away from
OpenTrak... If I were you, I'd focus on working with Scott to make sure there
are no protocol conflicts. You don't have to support OpenTrak, but trying to
get in the way, that is not in the amateur code of conduct.
>The ALOHA channel can only take about
>18% and only the DIGIS are fullly CSMA, all of the end users NEVER
>hear all of the other users and thus are NOT anywhere near fully
>CSMA! We have been down that road a thousand times...
Yes, we have, which is why I recommend those packet books to you. CSMA is a
channel access method, and is fully supported in OpenTrak.
>>Darn.... is that Duck poop on my antenna?
>
>Sounds like it to me....
Yeap, but for the same information, alot less volume then APRS!
----------------------------------------------------------------------
Subject: Re: DX spots on APRS!
From: Earl Needham <needhame1@plateautel.net>
Date: Sun, 06 Jun 2004 16:50:04 -0700
X-Message-Number: 79
At 03:18 PM 6/6/2004, Jeff King wrote:
>Anyways, the device built in the U.S. got destroyed
Actually, it was sabotaged -- for what it's worth...
Earl
Earl Needham, KD5XB, Clovis, New Mexico DM84jk
SETI@Home: 11589WU/7.52yrs
----------------------------------------------------------------------
Subject: Re: KISS mode is not always the answer !
From: Earl Needham <needhame1@plateautel.net>
Date: Sun, 06 Jun 2004 16:56:19 -0700
X-Message-Number: 80
At 03:01 PM 6/6/2004, Neil Johnson wrote:
>I can't run KISS mode. Why ?
>
>Because out here in the sticks I'm the only digipeater for 50 miles. I'm also
>the only Igate for 50 miles.
>
>So I use the same TNC to do both. It's a cinch with aprsd.
>
>KISS is therefore not an option.
It's a GREAT option, IF you try UI-View32. Does IGATE and digipeating
(WIDEn-N, TRACEn-N, RELAY, whatever you like) wonderfully, with the TNC in
KISS mode.
7 3
Earl
Earl Needham, KD5XB, Clovis, New Mexico DM84jk
SETI@Home: 11589WU/7.52yrs
----------------------------------------------------------------------
Subject: Re: DX spots on APRS!
From: "Spider" <spider@rivcom.net>
Date: Sun, 6 Jun 2004 16:04:37 -0700
X-Message-Number: 81
----- Original Message -----
From: "Robert Bruninga" <bruninga@usna.edu>
>APRS can do a lot. Like I say, some authors are only
>using about 10 % of its potential... and so most users
>using those programs are not even aware of what they
>are missing...
>
>Bob, WB4APR
Bob and I have had a small discussion on another Sig and there are indeed
issues that limit some of the uses of APRS.
For example, the TT3 which is a great little product from Byonics which
supports the NMEA type packets does not support the Destination Address
GPSxyz format for determining the symbol that is displayed. Part of this is
due to the Destination Address being fixed in software to identify the
device....and I am not pointing any fingers....only highlighting
a typical issue users run into. I understand the need for a manufaturer's
want to identify the product and I understand the users need to display the
correct symbol. In some cases the user is simply taken out of the picture
due to conflict within the spec. It is neither the fault of the user or the
manufactuer but it creates a major communication gap.
What is the suggested fix for this? Would it be to allow the user to
determine the Destination Address eliminating the manufacturers device id?
73
Jim, WA6OFT
----------------------------------------------------------------------
Subject: RE: KISS mode is not always the answer !
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 16:14:22 -0700
X-Message-Number: 82
>So I use the same TNC to do both. It's a cinch with aprsd.
>KISS is therefore not an option.
Sure it is. It just means a little more work to configure digi_ned. But
you get a much more intelligent digipeater for your trouble.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: KISS mode is not always the answer !
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Sun, 6 Jun 2004 18:14:59 -0500
X-Message-Number: 83
If you use aprsd, you could use the Linux ax25 kernel support which
allows multiple applications to share the same TNC running in KISS mode.
javAPRSIGate makes use of this so people can use much more powerful digi
software such as Digi_Ned. There are versions of aprsd that make use of
the Linux ax25 kernel support, as well.
So yes, KISS is an option and a powerful one, at that.
73,
Pete Loveall AE5PL
mailto:pete@ae5pl.net
>-----Original Message-----
>From: Neil Johnson
>Posted At: Sunday, June 06, 2004 5:04 PM
>Subject: [aprssig] KISS mode is not always the answer !
>
>So I use the same TNC to do both. It's a cinch with aprsd.
>
>KISS is therefore not an option.
----------------------------------------------------------------------
Subject: RE: APRS extensibility and OPENtrack
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 16:21:25 -0700
X-Message-Number: 84
>Yes, so why is OPENtrack putting all its efforts into making sure
>that OPENtrack packets cannot be decoded by Kenwoods
>or any other existing APRS network participant?
It's not an issue of making them undecodable. It's a DIFFERENT PROTOCOL.
It's playing by the rules, and making it very clear that it's not APRS, to
avoid causing undesired operation in devices that don't support it. A
user-defined message type WOULD NOT BE DECODED EITHER. Would you consider
that making an effort to make it non-decodable?
>I agree! If it is a position report, put it in the original APRS
>format so that all the net users benefit! That is the purpose
And here we go on this circular argument again. I've already asked that we
take the 'why' discussion off-list. Everyone here is sick of it, and I'm
tired of typing the same things over and over. I'll write a paper on my
position, you can do the same or not as you see fit.
>OPENtrack is designed to talk end-to-end with only other
>PC's. Even the messages and any other TEXT cannot
>be read-or-understood unless EVERYONE is always
>upgraded to the latest and greatest....
That level of support is trivial to code for any device that's already got
enough brains to decode AX.25. And it is most certainly NOT a PC-to-PC only
protocol - it's specifically designed to operate efficiently with embedded
devices, where APRS was not.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: OPENtrack DIGIpeater Objects
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 16:37:39 -0700
X-Message-Number: 85
>You dont seem to udnerstand the fundamental APRS
>decaying rate. It sends NEW more frequently than
>OLD data to improve the probability that EVERYONE
>gets it IMMEDIATELY and donest have to wait 30 minutes
>to see that the FIRE TRUCK moved!
And you don't seem to appreciate the fact that my house isn't moving. The
IGate has been sitting in exactly the same place, doing the same thing, for
167 days, 43 minutes since last reboot. That beacon hasn't been NEW
information in 167 days, yet the fact that the IGate is here is just as
relevant now as it was then.
>Then it eventually decays down to the final rate. Once
>it is more than 15 minuts old, it is no longer real time and
>so the 15 minute rate (or whatever) is just fine for
>informaing late participants...
Then what's the debate about, anyway? I'm not proposing a cache function
for moving objects/stations. That's silly, and counterproductive. The
proposal is only for STATIC information.
>can be used in APRS. Because these dumb
>FIXED-RATE programs can take an HOUR to update
>the movement of the fire truck if just one packet is
>missed!
Man, I WISH I only got one copy of every packet that hits this network...
>The system has been up for 165 days since its last
>reboot and hasn't moved - what would your
>decaying rate be at now?
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: DIGIpeater OBJECTS
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 16:42:38 -0700
X-Message-Number: 86
>Its the DIGI that you want to do this, so its the DIGI that has
>to implement it. What I am saying is that any station,
>including a digi can take over an object at any time and
>ALL EXISTING APRS code will honor that and hand it
>over.
I wasn't asking for a digipeater implementation. You said that it could all
be done with currently-defined message formats, specifically the object
expiration flag. I'm asking for an example of how you're suggesting that
would work.
>I liked your suggestion of using the TOCALL. I proposed
>the format OBJxyz where "x" tells it how many hours to
>keep it up, and "y" provides the fudamental rep-rate
>in minutes.
Isn't that an ALTNET? As long as you keep it an APxxxx call, it can still
be picked up by a dumb digipeater and no one needs to worry about the fact
that a cache request was made. The client will see that it wasn't honored
and keep transmitting as normal. A separate TOCALL would be used on the
digipeater side to indicate that the object had been cached, and the time
remaining till expiration.
>As soon as you agree and if there are no objections,
>Ill add it to the APRS SPEC errata page....
See above. I'd also like to hear if anyone's got further suggestions on the
matter - especially Henk, since he's probably the one I'm going to try to
con into writing an implementation. ;]
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: DX spots on APRS!
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 16:48:30 -0700
X-Message-Number: 87
>What is the suggested fix for this? Would it be to allow the user to
>determine the Destination Address eliminating the manufacturers device id?
This is my main objection to what I've proposed in the digi object caching
scheme. It eliminates the manufacturer ID. Not that I particularly care
about that - it's just that the TOCALL is a useful place to put such
information without affecting the packet payload. I think the cache
information is more important than the mfg ID, and a more appropriate use of
the slot since it's a digipeater function anyway.
The problem is, there's just the one slot. When something else useful comes
along, and putting it in the TOCALL makes the most sense for the same
reasons, now you've got to make a choice between mutually exclusive
features. Such is the nature of APRS.
I'm all for teaching an old dog new tricks, but you reach a point of
diminishing returns.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: The OpenTrac Debate and BS!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 19:51:49 -0400
X-Message-Number: 88
Eric, the software you say is needed to decode all of these existing APRS
hardware is APRS, not OPENtrack.. I dont see your point. APRS works for
users, OPENtrack is for programmers... Bob
----------------------------------------------------------------------
Subject: Re: APRS in the field. Big step forward...
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 19:59:34 -0400
X-Message-Number: 89
>>>"Spider" <spider@rivcom.net> 6/6/04 12:19:12 PM >>>
>Bob, your consistent defense of the Kenwoods is
>simply amazing! I really do use APRS in the field and
>have yet needed a Kenwood to do it, and I find
>them to be outdated and very limited.
Then why are 90+ % of ALL Mobiles and portables using them?
I only defend them becasue APRS users have them.
I see no reason to stop supporting them or their users just because some
programmers want to add a few tweaks to the protocol which they could
EQUALLY well do in a manner that would not obsolete the kenwoods...
>I'd really like to know because it's so obvious to me
>that these Kenwoods are a major factor in stopping
>forward movement of the State of the Art..
Programmer propaganda. How is a kenwood stopping you from doing what you
want? If you dont want to use a kenwood, dont use it. But dont set out
to purposefully OSOLETE those users just because you dont personally use
them...
Bob
----------------------------------------------------------------------
Subject: Re: DX spots on APRS!
From: "Spider" <spider@rivcom.net>
Date: Sun, 6 Jun 2004 17:04:42 -0700
X-Message-Number: 90
----- Original Message -----
From: "Scott Miller" <scott@3xf.com>
>The problem is, there's just the one slot. When something else useful comes
>along, and putting it in the TOCALL makes the most sense for the same
>reasons, now you've got to make a choice between mutually exclusive
>features. Such is the nature of APRS.
Not having a choice was my point. Bob was expressing that APRS and it's
features were barely used. This is a small very trivial example as to why.
Jim
----------------------------------------------------------------------
Subject: RE: OPENtrack DIGIpeater Objects
From: Curt Mills <archer@eskimo.com>
Date: Sun, 6 Jun 2004 16:03:23 -0700 (PDT)
X-Message-Number: 91
On Sun, 6 Jun 2004, Robert Bruninga wrote:
>Where as in the decaying rate, the packet will have been
>tranwsmitted 3 times in the first minute or so when it is
>IMPORTANT to get that NEW info to the end users.
>Then it eventually decays down to the final rate. Once
>it is more than 15 minuts old, it is no longer real time and
>so the 15 minute rate (or whatever) is just fine for
>informaing late participants...
>
>This is so fundamental to APRS it is a crying shame
>that none of the follow on APRS-clones implemented it.
What? Didn't I just send out a message a couple of weeks ago that Xastir
had it now? We do the decaying rate for objects/items, and a similar (but
not identical) setup for messages. I think we duplicate the algorithm that
is used in APRS+SA for messages, and we've had that in there for quite a
while. It's just the object/item stuff that is newer.
Check the APRS Client Capability Chart if you have any question about which
clients implement which feature. It's the only way I can keep track these
days.
--
Curt, WE7U. archer at eskimo dot com
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: KISS mode is not always the answer !
From: Curt Mills <archer@eskimo.com>
Date: Sun, 6 Jun 2004 15:47:03 -0700 (PDT)
X-Message-Number: 92
On Sun, 6 Jun 2004, AE5PL Lists wrote:
>If you use aprsd, you could use the Linux ax25 kernel support which
>allows multiple applications to share the same TNC running in KISS mode.
>javAPRSIGate makes use of this so people can use much more powerful digi
>software such as Digi_Ned. There are versions of aprsd that make use of
>the Linux ax25 kernel support, as well.
>
>So yes, KISS is an option and a powerful one, at that.
And aprsd handles AX.25 kernel mode interfaces now, right? Just upgrade to
a newer version. I understand the docs may be lacking regarding this newer
feature though.
--
Curt, WE7U. archer at eskimo dot com
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: The OpenTrac Debate and BS!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 20:09:26 -0400
X-Message-Number: 93
>>>db2fm <db2fm@jfsattv.de> 6/6/04 12:23:37 PM >>>
>> Of course, [APRS] can be put together more
>>streamlined with a total re-invention of the wheel,
>>but why? When it would sacrifice all existing users?
>That's big b***sh*t!... You americans normally tend to
>use hard words and propaganda...
>No, 20,000 users would not be obsolete! Nobody at all!
>Every application can be upgraded if needed, hardware
>still IS compatible (or could be made so).
When I see "every application can be upgraded" that means ALL EXISTIN USERS
MUST UPGRADE to get any of the OPENtrack advantages.
And when I see "hardware is still compatible(or can be made to be so)"
there is only one way to do this and it is that OPENtrack MUST still decode
ALL existing NMEA trackers, all Kenwoods and all trackers.
And this COMPLETELY eliminates any advantages of OPENTrack on the APRS
channel because it only adds YET ANOTHER format instead of eliminating ANY.
The ONLY way to get to the paradise of the OPENtrack "clean" spec is to
make a clean break and the ONLY way to do that is to OBSOLETE all 20,000
existing users.. or go to a different frequency...
Leave it to the users. If OPENtrack is better for them they will follow...
Bob
----------------------------------------------------------------------
Subject: Re: APRS in the field. Big step forward...
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 20:12:44 -0400
X-Message-Number: 94
>>>Henk de Groot <henk.de.groot@hetnet.nl> 6/6/04 12:27:05 PM >>>
>that a new protocol can co-exists with the old protocol
>without disrupting the existing service.
>Yes, this means that it can be developed alongside
>the existing APRS service and allows smooth migration
>to clients that know both protocols or in the future
>(over 10 years?) only know about OpenTrack.
I can assure you that if I was an OPENtrack programmer, the LAST thing I
would want to have to do is ALL Of APRS, PLUS the new OPENtrack. Besides
that is the whole advantage of OPENtrack so that those new p rogrammers
dont have to do APRS!
The only way to have the advantages of OPEN track for the programemrs is a
clean break. And that usually means a new frequency...
Bob
----------------------------------------------------------------------
Subject: Re: The OpenTrac Debate and BS!
From: Danny <danny@messano.net>
Date: Sun, 6 Jun 2004 20:20:14 -0400
X-Message-Number: 95
I think it's pretty simple.
You basically slammed APRS software, calling it's users "couch potatoes",
versus the majority of REAL APRS users that were using hardware out in the
field.
I think his point was that without software, all that precious transmitting
hardware has nothing to be decoded and seen on.
Danny Messano
KE4RAP
----------------------------------------------------------------------
Subject: Re: DX spots on APRS!
From: "Kurt O. Jauss" <kf6hjo@earthlink.net>
Date: Sun, 06 Jun 2004 17:25:28 -0700
X-Message-Number: 96
Question Jeff? I see a lot of e-mail from you about APRS and OT
however I haven't seen your position on my map or on FINDU. Do you run
APRS or just gripe about the way Bob implemented it?
----------------------------------------------------------------------
Subject: Re: The OpenTrac Debate and BS!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 20:26:21 -0400
X-Message-Number: 97
>>>Danny <danny@messano.net> 6/6/04 12:59:42 PM >>>
>If a newer specification were put into place, it would be
>years before anything would be obsolete. There is no
>reason we couldn't design dual mode hardware and
>software to make sure APRS 1.0 was around for years
>to come.
Ah, but you just eliminated all of the advantages of the
one-way-works-for-all advantage of OPENtrack.
People must understand, I am NOT against OPENtrack. I just dont think that
EXISTING APRS users should have it jammed down their throat with the STATED
INTENTION of OBSOLETING absolutely everything in APRS and then to have the
audacity to insist on doing it on an their (APRS) established and working
network...
OPENtrack's time has come. Just dont kill APRS while doing it. GO to
145.55 or 145.01. Remember 145.01 in many areas of the coutnry also has an
established base of DIGIS that anyone can use. and in fact probably no one
is using them!
>Those choosing to use the new APRS would be
>able to choose to do so, via their "toy".
Exactly, That is what a TUNE knob is for...
>Other than the precious kenwoods, most APRS toys
>can be ugraded by popping out an IC and popping a
>new one in. I do it all the time. Is it REALLY that hard?
It is even easier to adjust the TUNE knob to the OPENTrack frequency. And
STILL HAVE BOTH APRS for those that are slow to upgrade and OPENtrck who
want to always be chasing the latest upgrades...
>Secondly.. If this is such a great working system, why
>do we see people developing alternate protocols,
because they have no interest in supporting the existing user base and only
want to do new things easier. AND THERE IS NOTHING WRONG WITH THAT. Just
do the new things on a different frequency and leave the decision to
upgrade or not to the end user who has a working system now...
>why have an addendum page on your OWN web site?
Because I try hard to add things when the end user requests them...
>So far, nothing new has been added because everything
>needs to fit the spec built into the kenwoods. Enough said.
No, it hasnt been added, because those programmers have not taken the least
interest in seeing how to add it and yet still benefit the existing user...
Bob
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 20:30:31 -0400
X-Message-Number: 98
>>>"Scott Miller" <scott@3xf.com> 6/6/04 1:13:50 PM >>>
>You're going to have to point out in the AX.25 spec
>where it says that, Bob. I don't see it. The way I read it,
>the UI part is defined in the control byte and has nothing
>to do with the PID.
Common knowledge about the last 20+ years of AX.25 TNC's that all use F0
for UI packets. Read any TNC manual. ALl of them use F0 for UI packets.
Bob
----------------------------------------------------------------------
Subject: Re: APRS in the field. Big step forward...
From: Jeff King <jeff@aerodata.net>
Date: Sun, 6 Jun 2004 20:32:13 -0400
X-Message-Number: 99
Reality check
On Sun, 06 Jun 2004 19:59:34 -0400, Robert Bruninga wrote:
>>>>"Spider" <spider@rivcom.net> 6/6/04 12:19:12 PM >>>
>>Bob, your consistent defense of the Kenwoods is simply amazing! I
>I see no reason to stop supporting them or their users just because
>some programmers want to add a few tweaks to the protocol which they
>could EQUALLY well do in a manner that would not obsolete the
>kenwoods...
Bob, I wish every customer I had was like you. Customers that defend my
unwillingness to update my products, my bad design decisions and just
overall unwillingness to adapt to the times.
Why do I say this? Because KENWOOD is the manufacturer and we, as hams, are
the customers! If the customers want something better, it is KENWOOD's job
(or the market) to give it to them, not the customer's job to lower their
expectations.
'course, I am not a customer of Kenwood. I took this advice on the APRSSPEC
in 1999 to heart:
http://www.tapr.org/tapr/list-archive/aprsspec/9912/msg00059.html
>>I'd really like to know because it's so obvious to me that these
>>Kenwoods are a major factor in stopping forward movement of the
>>State of the Art..
>
>Programmer propaganda. How is a kenwood stopping you from doing
>what you want?
I don't believe it stopped OpenTrak from being developed, nor did it bother
the Kenwoods once it went live.
>If you dont want to use a kenwood, dont use it.
>But dont set out to purposefully OSOLETE those users just because
>you dont personally use them...
Wow.... I feel like I am looking at a Escher drawing after reading that.
First you say Kenwood shouldn't stop anyone, then when someone goes ahead and
does something, you scream about "20,000 APRS users obsoleted" by OpenTrak.
My head is hurting now.
Here is the drawing I was thinking of, "Relatively" by Escher, 1951:
http://www.mcescher.com/Gallery/back-bmp/LW389.jpg
----------------------------------------------------------------------
Subject: Re: APRS in the field. Big step forward...
From: "Spider" <spider@rivcom.net>
Date: Sun, 6 Jun 2004 17:39:37 -0700
X-Message-Number: 100
----- Original Message -----
From: "Robert Bruninga" <bruninga@usna.edu>
>Programmer propaganda.
How can that be? I am in no way a programmer.
>How is a kenwood
>stopping you from doing what you want? If you dont
>want to use a kenwood, dont use it. But dont set
>out to purposefully OSOLETE those users just because
>you dont personally use them...
>
>Bob
When I suggested support for using the compressed posits, your comments
were against it because people with Kenwood's would not be able to read
them, therefore the suggested use of compressed posits was not on 144.390.
That is just one example, there are numerous others. I do not know if you
realize it or not but every issue that seems to come up is argued against
because of the Kenwoods by you. Some people have recently done some data
mining and I do not think Kenwood use was near 90% of all users. Where did
this number come from? In my local area, there is 0% usage of the
Kenwoods.
Jim
----------------------------------------------------------------------
Subject: Re: OPENtrack for programmers, APRS for users
From: Wes Johnston <wes@johnston.net>
Date: Sun, 06 Jun 2004 20:39:19 -0400
X-Message-Number: 101
I will not name the kenwood programmer as a courtesy to him... but the man
I spoke to at DCC last year said the kenwood d7a could do alot more if so
much code were not required to deal with MIC-e format. Yes, it's short on
the air, but long in code.
Bob, what this is all boiling down to is: APRS clients which can't decode
open trac packets need to ignore them. If you use PID F0, then don't tell
me someone else can't use any of the other 254 PIDs. If it were not
opentrac causing the problem it could be a TCP packet or a netrom node
list. In either case, don't shoot the messenger because a few aprs clients
choke on a few non-aprs packets. When APRS started I remember reading the
"rules'.... no connected mode packets no TCP stuff.... because those
involved ACKs and since APRS relied on UI frames the connected mode stuff
would clobber the hell out of our APRS packets and we'd never know it. OT
in it's present form also uses UI frames, so it will not clobber APRS
packets anymore than any other APRS packet would. The two are compatible
on this level. I keep trying to point out how similar they are and you
keep screaming the sky is falling!
As you have said so many times in the past... APRS is a local thing. In my
LOCAL area, if and when OT reaches critical mass, everyone in my LOCAL area
will switch to it. Same for other LOCAL areas. No one is going to
blacklist 1000's of users overnight. It will be a gradual change along the
lines of the normal ebb and flow of anything. When I get tired of seeing
?? on my kenwood, I will send it in for the NMEA 2.0 update. Someday
kenwood will release a new firmware or a redesigned d7a which will include
what hamradio-dom wants. That may or may not include decoding OT
packets. The market will tell.
As an example.... I resisted the switch to digital cell phone because I had
this nifty dial tone adapter for an old analog bag phone. When I finally
switched to digital, I found out what all the talk was about... longer
battery life, clearer calls. I expect that as some clever programmer makes
some new gee whiz device, curiosity will get the best of many hams and they
will try it. Then they will "sell" their friends on the merits of this new
gadget. When all hell breaks loose we will fall back on the lowest common
denominator which for the time being is APRS (and scott's tracker actually
sends both APRS and OT formats). But some will push forward and eventually
_something_ new will replace APRS. I hate for it to happen that way, but
the really inventive people are growing weary of asking for some new
feature to be added and being turned down. How does not having the ability
to convey some piece of information which someone felt important enough to
ask for benefit the END USER? What ever the idea is/was, it was wanted to
make someone or some organization's life easier and now that
person/organization is without a tool which exactly fits their needs. APRS
WG hasn't convened in how long? Each and EVERY time someone comes up with
an idea, you say it will obsolete the kenwoods and the idea stops
dead. This (as Henk put it) is the death knell of APRS... and it's the
WG's own fault.
All the OT people want at this point is for the APRS clients to either
decode or ignore non-aprs packets. We (they) do not want to add or
incorporate anything into APRS spec (because it seemingly can't be
done). Just put on your blinders and act like we're not here.
I gotta say, it really saddens me to be on the opposite side of this as you
b/c I have come to respect your ideas so much.
Wes
At 01:24 PM 6/6/2004, Robert Bruninga wrote:
>I fear you are being sucked into the missleading propaganda
>of programmers again, and not looking at the value for the
>end user...
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
