| |
ZL3AI > APRDIG 16.06.04 10:12l 781 Lines 30005 Bytes #999 (0) @ WW
BID : 3474-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 10, 4/8
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040616/0732Z @:ZL3VML.#80.NZL.OC #:25937 [Chch-NZ] FBB7.00i $:3474-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: Thoughts on a proposed replacement for D700
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 10 Jun 2004 14:44:36 -0400
X-Message-Number: 66
>>>"Curt, WE7U" <archer@eskimo.com> 6/10/04 2:04:40 PM >>>
On Thu, 10 Jun 2004, Robert Bruninga wrote:
>Depends on the word. I USE ham radio and I dabble
>around in BASIC to try to get PC's and radios to do the
>kinds of HAM radio stuff that I think needs doing.
>Back then, EVERY PC had basic on it and so I could
>share my hacks with others..
By "dabble", Bob means 322,218 lines of code... According to the utility
"wc" which just counted them for me.
Bob: Yes, and that is why I fully understand the sentiment
Bob: of new programmers who are upset at the complexity
Bob: of APRS and want to simplify it. I agree, took me
Bob: 10 years of my life... But unfortunately,
Bob: we are unwilling to sacrifice 38% of our existing users
Bob: just to make life easier for programmers...
Bob: Thanks! (I once guessed the lines of code near 30k lines
Bob: of code. Could there be a typo in your number above?
----------------------------------------------------------------------
Subject: Re: Compressed Positions
From: Drew Baxter <droobie@maine.rr.com>
Date: Thu, 10 Jun 2004 14:48:29 -0400
X-Message-Number: 67
If we have 60 feet granularity in position, shouldn't we have to use
ambiguity flag then? It's definitely more ambiguous than a traditional GPS
position.
This is really going to be a bad thing for my APRS-enabled coffee maker..
60 feet either way could be First Floor Toilet or 2nd Garage Bay..
I didn't realize that MIC-E was that ambiguous.. Explains why my Garmin
with an EPE of 7 feet can yield a different result once it hits the APRS
network.
--Droo, K1XVM
At 02:33 PM 6/10/2004, Jeff King wrote:
>And anyways, 60 feet granularity is good enough for anyone in ham radio,
>right? I mean, it saves you the cost of a WAAS enabled GPS, and you can
>pretend the SA was never turned off. Only a dummy would want accuracy
>greater then 60 feet, in a compact protocol, right?. ;-)
>
>73
>
>Jeff
----------------------------------------------------------------------
Subject: Re: Compressed Positions -was- Re: Tetrooncollateral damage report,
revision1
From: Danny <danny@messano.net>
Date: Thu, 10 Jun 2004 14:54:40 -0400
X-Message-Number: 68
I have a question.. Who is "WE"??
This still wreaks of Bob making decisions SINGLEhanded for all of APRSdom
based on what side of the bed he got up on and what the temperature is
outside.
This is tyranny at it's best.
Danny
KE4RAP
Thursday, June 10, 2004, 2:16:44 PM, you wrote:
CW> On Thu, 10 Jun 2004, Robert Bruninga wrote:
>>Yes, that is exactly what I meant. Thanks. We want to
>>"obsolete" some underutilized, or broken things in the
>>current spec so that future programmers are not
>>saddled implementing things that are just not used much.
----------------------------------------------------------------------
Subject: Re: Compressed Positions
From: "J. Lance Cotton" <joe@lightningflash.net>
Date: Thu, 10 Jun 2004 13:56:42 -0500
X-Message-Number: 69
Robert Bruninga wrote:
>Yes, I was. But after these same several years
>have *passed*, I have learned:
[...]
>2) Many implementaions are buggy and unreliable or incomplete
Do you have a list of programs that are unreliable and/or buggy with regard
to compressed packets? I'm really just curious about it, since I don't
remember reading complaints about software that doesn't support it. The only
part not quite implemented all the way had to do with compressed objects,
which not all clients support.
--
J. Lance Cotton, KJ5O
http://map.findu.com/kj5o-14
joe@lightningflash.net
----------------------------------------------------------------------
Subject: RE: Compressed Positions -was- Re: Tetrooncollateral damage report,
revision1
From: Danny <danny@messano.net>
Date: Thu, 10 Jun 2004 14:58:39 -0400
X-Message-Number: 70
Since when does Bob CARE what is easiest for the "programmers" that he has
been BASHING for days with claims that they don't care about the users and
just want what is EASIEST???
Ouch!
Sorry, fell out of my chair. I started laughing from the shock, blacked
out, and hit the floor.
Danny
KE4RAP
----------------------------------------------------------------------
Subject: Re: Compressed Positions
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Thu, 10 Jun 2004 14:03:53 -0500
X-Message-Number: 71
>-----Original Message-----
>From: Robert Bruninga
>
>Yes, I was. But after these same several years have
>*passed*, I have learned:
>
>1) Not all APRS clients implemented it
>2) Many implementaions are buggy and unreliable or incomplete
I apologize if this has been delineated before, but which clients have
not implemented compressed packets or have "buggy and unreliable or
incomplete" implementations? Xastir, APRS+SA, javAPRS, javAPRSFilter,
and UI-View all have compressed packets implemented. I assume that
APRSDos does too. Kenwood radios implement compressed posit decoding.
This sounds like the majority of clients in use today, not the minority.
>3) Having precision to 1 foot without Datum is pointless
I disagree. It is known that if a datum is not supplied, it is assumed
to be WGS84 per the spec. If a group uses another datum for their own
use, then the 1 foot precision is still maintained in context. In the
latter case, if a disinterested party is looking at the position, then
your statement is true, but only in that case.
>4) Progrrammers and users want a simpler spec and
> complain about complexity and duplication of formats
As a programmer, I think it is more important to have a consistent spec
than to have a spec that might have formats deleted or deprecated simply
because some people don't want to implement them or have a hard time
figuring out how to implement them. BTW, there are 3 things that
compressed format do that Mic-E doesn't:
1. Fixed station identification (Mic-E is always assumed to be providing
a speed vector.
2. Compressed full weather packets.
3. Compressed objects and items.
BTW, I believe the Kenwoods also don't decode items, just objects even
in standard format.
>Yes, so that is why we are responding to the consensus and
>recommending it not be used for new installations because
>there is no guarantee that recepients will see it properly.
I am with Curt and not part of that "consensus" you talk about.
>Sorry, the one good thing to come out of all of this is that
>we do need to go back and keep moving on the spec. I am
>getting the APRS-WG together now to try to issue APRS1.1 in
>the next few days that includes all the easy stuff to get the
>Spec up to date with what is common practice now.
Ok to move forward, but lets not start deprecating things because one
person or another has a hard time implementing a feature. Better IMO to
concentrate on making the spec consistent and clarifying places where
contradictory statements are made.
73,
Pete Loveall AE5PL
mailto:pete@ae5pl.net
----------------------------------------------------------------------
Subject: Re: Compressed Positions
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 10 Jun 2004 12:16:05 -0700 (PDT)
X-Message-Number: 72
On Thu, 10 Jun 2004, Robert Bruninga wrote:
>1) Not all APRS clients implemented it
But most have.
>2) Many implementaions are buggy and unreliable or incomplete
Incomplete: TH-D7A, TH-D7A(G), TH-D7E, and TM-D700A, as they don't
implement compressed objects/items. Of course very few APRS
programs have done so yet either, but at least that problem can be
rectified, without throwing the baby out with the bathwater.
>3) Having precision to 1 foot without Datum is pointless
True. So what. It's not a problem with Base-91 Compressed posits
per se, just that the additional datum info must be added if it is
needed in a particular situation. I proposed adding datum info to
the packet years ago, and it is only recently being championed by
you. If we had done it years ago it'd probably be implemented in
more clients by now and it wouldn't be a problem currently.
>4) Progrrammers and users want a simpler spec and
> complain about complexity and duplication of formats
So... Let's throw out the inefficient long-format lat/long packets
instead, and just keep the efficient Mic-E and Base-91 Compressed
formats. It'll save a LOT of air-time if we do that...
>I am only responding to the programmers and users and
>trying to solve problems 1, 2, 3 and 4, while also providing
>them a new !DAO! version that is 100% backwards
>compatible, and will give Datum as well as the other a
>dvantages I enumerated earlier.
100% backwards compatible, nearly 0% implemented in the current
clients (client count = 1).
>It seemed like the consensus of the requests I have seen.
Not to me.
>>I was reasonably happy with the Compressed packets,
>>as they were ... [but], Because nobody else saw it
>>other than Kenwoods and Xastir users, I eventually
>>switched back to Mic-E for my mobile so that more
>>people would see my mobile.
>
>Yes, so that is why we are responding to the consensus
>and recommending it not be used for new installations
>because there is no guarantee that recepients will see
>it properly.
Xastir will continue to support it. That is the only currently implemented
mode that gives us the object/item positioning that we currently need. It's
also in the spec, and has been from it's ratification by the working group.
>Sorry, the one good thing to come out of all of this
>is that we do need to go back and keep moving on
>the spec. I am getting the APRS-WG together now
>to try to issue APRS1.1 in the next few days that
>includes all the easy stuff to get the Spec up to date
>with what is common practice now.
Who's on it?
>Sinc ethe 1 foot preciion
>for SAR OBJECTS is what precipitated all of this
>month long session on the APRSSIG and since
>that kind of precision is worthless without datum
>information it was clear that the compressed spec
>should not be used for objects.
Clear to whom? There are instances where all of trackers and map programs
are under the control of a particular group. We can specify what datum to
use for the trackers. The datum is therefore known to all involved, and
the correct position appears on the map. I'm in this case speaking of our
local SAR group.
>And if it iis not
>used to 1 foot, then why use it at all, since it is
>LONGER than the Mic-E format and provides
>no benefit.
Because it is allowed by the spec for objects/items, and Xastir implements
it. Take that away and we have to use longer packets to do the same thing,
made even longer by your datum extension. We have a working implementation
currently, why remove it?
>Thus responding also to getting rid of under-
>used stuff in the spec, it just seems logical to me
>to recommend its obsolescence...
And I've been striving to get compressed objects/items implemented by more
clients (mostly UI-View) for quite a while, so it appears that our goals
are rather at odds here.
--
Curt, WE7U 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: Compressed Positions
From: Danny <danny@messano.net>
Date: Thu, 10 Jun 2004 15:22:19 -0400
X-Message-Number: 73
RB> Sorry, the one good thing to come out of all of this
RB> is that we do need to go back and keep moving on
RB> the spec. I am getting the APRS-WG together now
RB> to try to issue APRS1.1 in the next few days that
RB> includes all the easy stuff to get the Spec up to date
RB> with what is common practice now.
RB> Then APRS1.2 will be the more controversial issues.
Why the ______ have you spent DAYS arguing AGAINST updating the APRS spec,
and now this???
I am BEYOND SHOCK... or this some more smoke and mirrors?
This is utterly insane.
I need some ritalin to help me focus on what just happened here.
Danny
KE4RAP
----------------------------------------------------------------------
Subject: Trains, planes and APRS automobiles. was: Kenwood APRS radio
From: Jeff King <jeff@aerodata.net>
Date: Thu, 10 Jun 2004 15:36:01 -0400
X-Message-Number: 74
Economists here, please correct my analogy here if it is wrong. In any case,
please read to the end. This is mostly about physical layer one, and why
OpenTrak and APRS are just two ducks, with different colors.
On Thu, 10 Jun 2004 14:10:13 -0400, Steve Dimse wrote:
>>So nothing to worry about here.
>>
>Wrong. There is the issue with the hamhud, the single packet type
>being transmitted this time is not a guarantee there won't be any
>problems with other clients and other opentrack packet types.
There are no guarantees in life Steve, just remember all the problems the
APRS SPEC compliant MIC-E caused the APRS-IS, and the hoops you and others
had to jump through to fix it. Good news is, out of a coverage area of about
400,000 sq. miles, only one single protocol problem was reported, and I
believe the problem is either solved or resolved.
Jason, want to give us an update?
>And on top of everything else, in most areas 144.39 is heavily
>loaded, and and not capable of supporting another service besides
>APRS.
Thank you, I was hoping someone would chime in that understands packet radio
and also has a higher education so I wouldn't be wasting my time making this
analogy.
First, lets compare market/economic theory with APRS and move the analogy
over to highways (route 439) and call our protocols "automobiles". Each "ham"
would be the driver of the APRS automobile. I find using analogies can often
allow people to think past their narrow view of things.
Anyways, do we agree, that the "market" for APRS is similar to the market for
OpenTrak? That they can do similar things? That the market is in fact
saturated, everyone already has a APRS car in their garage? That the
"market", for OpenTrak primarily will draw from the APRS driver pool? Not
completely mind you, just the majority (and has anyone here bought a
OpenTracker without first having some APRS gear?)
And it has been spoken, that there are 20,000 APRS automobiles on Route 439.
And while this will not happen, lets say tomorrow, there will be 20,000
OpenTrak automobiles purchased (Scott, you owe me a commission!).
So, now we have 40,000 automobiles on Route 439, right? Nope, we don't
because, each automobile needs a driver (ham) and for each OpenTrak auto put
on the road, that means a APRS automobile had to be parked in the garage. So
the net increase is zero.
Now, lets talk about highway usage. This is distinctly different then our
automobiles, which can be thought as applications, such as APRS and OpenTrak.
The highway, and more to the point, its capabilities, is defined by the
loading and way the automobile treats it.
My packet formative years happened 5-20 years ago in Detroit area, so I will
name the highways after the frequencies there.
First, highway 756. TCP/IP. Big big UI frames, file transfers, but on a
limited scale lan (no digis). Lets call this vehicle the Saturn 5 transporter
vehicle. Needs a serious highway, but not a real long one.
Highway 505. Connected mode PBBS user traffic. Limited user lan, but still
heavy traffic. Lets call this 18 wheel truck traffic. Weight alot. Will tear
the road up, it if is not built strong enough.
Highway 503. Connected mode chat. Fast response needed for guys talking back
and forth. A protected race track, lightweight, go-carts maybe?
Highway 501 AdHoc Netrom and some PBBS forwarding. At least in the case of
Netrom, they act like Ants, always touching each other and communicating
signals back and forth. No car analogy, maybe other then bumper cars?
Highway 495. DX Clusters. Connected mode, one to many. Reminds me of control
line racers chasing each other. Very coordinated action, no digi's
Anyways, my point is, there is quite a justification for each of those
applications, to be on a different highway, because the way they use the
highway is distinctly different. That is, the way they access the highway.
So, lets compare the automobiles APRS and OpenTrak relative to highway 439
1. Both OpenTrak and APRS are UI frames
2. Both OpenTrak and APRS are designed to carry positional data
3. Both OpenTrak and APRS take advantage of flood routing (wides)
4. Both OpenTrak and APRS use CSMA
5. Both OpenTrak and APRS use Bell 202 modems, with AX.25
6. Both OpenTrak and APRS support SmartBeaconing
7. Both OpenTrak and APRS support telemetry
Some differences:
8. While both OpenTrak and APRS have similar size packets, OpenTrak can
compress more resolution into a similar size packet.
9. There currently are less then 100 OpenTrak trackers on highway 439, where
as there are ~20,000 APRS trackers on the highway
Conclusion:
In other words, protocol colors aside aside, there is no real difference, at
the physical layer, between OpenTrak and APRS. Usages and impact on the
highway are identical. In fact, one could make the argument that OpenTrak
treats the highway BETTER then APRS due to the more efficient payload
compartment. Meaning, more payload can be transported across the same highway
I hope the above made a few think. And don't forget, there are less then 100
OpenTrackers in the wild, and at this point I think it best not to overreact,
but instead carefully watch the situation.
Thank you for reading this.
73
Jeff wb8wka
p.s. Steve, would it help you if Scott disabled simultaneous dual protocol
mode at some point in the future? I can see this as a problem once usage
starts to pick up. I'm not saying he would do it, but I can see your point
here.
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: Keith Allen <kallen2@bellsouth.net>
Date: Thu, 10 Jun 2004 12:01:21 -0500
X-Message-Number: 75
Danny wrote:
>A vote for change is not a vote for Opentrack, it is a vote for change.
>That is where the problem lies in all these "opentrack vs APRS" arguments.
>
>Problem is, it doesn't really matter. Neither you or Bob care to listen
>to any of the arguments, dismissing them as "Opentrack propaganda" or in
>this case as coming from a minuscule part of the APRS population.
I would rather think that the folks who are using OPentrack at this
point are more minuscule, wouldn't you.
>Yep. Like I said though, it really doesn't matter, does it? Once again,
>another discussion pushing for APRS change is beat down by name calling and
>kenwood propaganda, and claims of "defense of the user base". What
>happened to the opinions of the users that agreed with a lot of the points
>being made AGAINST the APRS establishment?
and approximately how many were voicing those opinions??
>They were dismissed as being "Opentrack supporters", "programmers", and
>"argumentative".
I don't think anybody objects to change, as long as it doesn't leave
the current equipment and user base obsolete in the process. The
current APRS protocol is very useful and functional at a minimum of
investment for us lower income folks and can be more fun for folks who
can invest a little more. Once again, if you entirely change the
protocols and leave it where the many current APRS users can no longer
read the data on their existing systems, where is the benefit?
>It's really sad to see APRS being managed the way it is. I hope this
>bureaucracy pays off in the long run, and doesn't obsolete APRS due to
>inability to change.
We just implemented APRS on an experimental basis just a month ago for a
bicycle event involving around 600 cyclists. Worked like a charm. We're
looking at widespread implementation next year. I guess if a new format
pops up and is not backwards compatible with what we're using, we'll just
find our own freq and go for it. It would be a shame though, because our
current digipeaters in the area will change too, leaving many users in this
immediate area without one on 144.39. Food for thought. 73. Keith.
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: Keith Allen <kallen2@bellsouth.net>
Date: Thu, 10 Jun 2004 12:02:29 -0500
X-Message-Number: 76
Thanks Steve. :-) Keith.
Steve Dimse wrote:
>Oh, hell, I'll do it.
>
>For the US only, 1914 of 4993, 38.3% of root callsigns used Kenwoods
>
>For the world (removing the KNWA filtering) 3368 of 10858, 31.0%
>
>For all the packets in the raw.txt file (removing the TCPIP/TCPXX filtering)
>3369 of 12299, 27.4%
----------------------------------------------------------------------
Subject: Re: APRS Protocol - A Modest Proposal
From: Keith Allen <kallen2@bellsouth.net>
Date: Thu, 10 Jun 2004 12:06:34 -0500
X-Message-Number: 77
>I hope that never happens! As a weather spotter for ARES, I appreciate
>having quick access to various area weather station info in my mobile.
>I hope we never get to the point of saying "this type of station is ok
>on the APRS frequency but this other kind isn't". That would, IMO,
>defeat one of the major benefits of APRS.
I concur 100 percent on this one. With APRS, we can see what's going on
all over the area as well as where spotters are (if we choose to do so).
>I hope we do not as a group try to
>defeat one of the key benefits IMO of APRS: all area stations are
>directly seen on a single frequency.
One hundred percent agree here.
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: Keith Allen <kallen2@bellsouth.net>
Date: Thu, 10 Jun 2004 12:16:54 -0500
X-Message-Number: 78
Danny wrote:
>Steve,
>
>Although Bob has decided to make this an "APRS/Kenwood VS Opentrak"
>argument, I would have though YOU of all people would not be so
>nearsighted. Pointing out that there are 30 people on the Opentrak list is
>ENTIRELY irrelevant.
I'm not so sure about that.
>This may have started off as an Opentrak "problem" but most of what is
>being discussed here is what Opentrak represents. Opentrak represents
>CHANGE. CHANGE is something we have seen little of in APRS and something
>that is opposed greatly. The system for CHANGE is broken, political,
>riddled with commercial interest, and CLOSED.
>It's a shame that what is ACTUALLY being said is being twisted around and
>used for personal attacks, instead of the real issues being addressed.
Okay let's keep personalities out of it. Let's use the example of
another mode of communication in Amateur Radio. Let's look at CW. Now
don't start laughing and holler something about CW being obsolete and
history. CW has all the time used the same set of DITS and DAHS to
represent the same thing for each letter of the alphabet and the
prosigns. Now there have been developed various keyers, readers,
keyboards and such that facilitate the ease of reading and sending of CW
for those interested in it. But as of yet, I have not seen anybody
change the code, which is the basis for CW. Morse code is still
internally recognized as the basis. I haven't seen a Jones or Smith
code come out changing dih-dah from A to L or Z or something. And, CW
still is the one mode of operation allowed most anywhere on the bands.
In other words, the basis is valid and proven and isn't being changed.
I feel the same to be true for the protocol of APRS, which actually
allows more flexibility in it than CW does. It's been proven and
effective. It continues to be effective. And it works. So, why throw
out the baby with the bath water?
73. Keith.
----------------------------------------------------------------------
[duplicate]
----------------------------------------------------------------------
Subject: Re: Compressed Positions
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 10 Jun 2004 15:48:49 -0400
X-Message-Number: 80
>>>Danny <danny@messano.net> 6/10/04 3:22:19 PM >>>
RB> the spec. I am getting the APRS-WG together now
RB> to try to issue APRS1.1 in the next few days that
>Why the ______ have you spent DAYS arguing
>AGAINST updating the APRS spec, and now this???
You seem to have no clue. READ MY LIPS! I have NO OBJECTION TO UPDATING
THE SPEC! Where on earth have you been...
What I Object to is
1) OPENTrack wanting to run BINARY on the APRS channel against all
recommendations to the contrary
2) OPENTrack wanting to add yet a 6th position format to the APRSspec on
one hand and bitching at the complexity on the other hand.
3) Every programmer FIGHTING for his own little pet project to be crammed
into the spec with the STATED PURPOSE of not being backwards compatible
with the 38% of all users
4) At the same time every other progrrammer BITCHING becuse it already has
to much in it
5) None of these programmers working towards stability, or consensus and
working together for the good of all.
If you follow the threads on the APRSSIG over the last several years, you
will see that we are FULLY willing to add things to the spec, when
1) They wont BREAK anything
2) They will not prevent existing users from working
3) There is a compelling need.
And we have added many things when users request. We DO stive to satisfy
the needs of the users. But not at the expense of other users...
>I am BEYOND SHOCK... or this some more smoke
>and mirrors?
No, it clearly shows that you have no clue what the issues are, and are
just jumping on a bandwagon that you have no idea where it is going...
Bob
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 10 Jun 2004 12:57:34 -0700
X-Message-Number: 81
>Wrong. There is the issue with the hamhud, the single packet type being
>transmitted this time is not a guarantee there won't be any problems with
other
>clients and other opentrack packet types.
In case you haven't been following developments, it's looking now like it
was the APRS format packet that was causing lock-ups. We'll know for sure
soon... I just send an OpenTracker off to one of the developers for testing.
Scott
N1VG
----------------------------------------------------------------------
Subject: APRS v. OT argument
From: <jrsmith2@cableone.net>
Date: Thu, 10 Jun 2004 12:52:53 -0700
X-Message-Number: 82
First, let me say that while it was interesting at first, I've become weary
of all the hundreds of messages.
Next, let me also say that the argument regarding APRS digi users switching
their hardware to support OT is (mostly) a pipe dream. I for one cannot
afford to do this swap, both monetarily and time/effort wise. I'm happy
with APRS as it is, and the UI-Digi and UI-View systems that I have fully
support digipeating of this, and so far any additions or changes that have
been made to the spec.
Thirdly, the de-facto APRS WG has been very good about supporting users
needs, and the comment field allows users to custom add information as
needed. I have yet to see anything added in OT that would exceed this.
The high accuracy positions are for the most part useless, as commercial
(except for survey units) GPS systems, even with WAAS or DGPS are not
accurate enough to warrant this.
I believe that OT applications, should exist on a seperate frequency, at
least for now. Maybe one day there can be a mutual frequency designed to
accomodate dual protocol digis. But until that day comes, I just can't
affored to change hardware/software. Even if such a change is at a minor
cost. With mouths to feed and bills to pay, my hardware upgrades come
slowly and grudgingly. Don't misunderstand this for a bias against OT.
Just a statement of economic facts for myself, and I believe, others.
So, having said that, I'm going to leave the SIG for a while until all this
commotion ceases.
Jack KE4LWT
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Thu, 10 Jun 2004 21:11:10 +0200
X-Message-Number: 83
At 17:20 9-6-2004 -0700, Mark Fellhauer wrote:
>At 04:30 PM 6/9/2004, Danny wrote:
>
>>Because if a *KENWOOD* can't decode it, it's non-aprs-channel-interference?
>>
>>DM
>
>No because over 1/3 of the existing user base can not decode it. Brand
>names have nothing to do with it.
You mean just like 99% of all APRS stations could not decode MIC-E when it
was introduced? I see, I think that issue was solved over time...
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: I AM OUTTA HERE! (38% is good enough for me!)
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Thu, 10 Jun 2004 21:38:36 +0200
X-Message-Number: 84
At 19:31 9-6-2004 -0500, Kurt A. Freiberger wrote:
><small voice> So, is it safe to mention Hitler now, or is that just UseNet
>protocol? </small voice>
-------------------------------------------------------------------
Godwin's Law
Godwin's Law /prov./ [Usenet] "As a Usenet discussion grows longer, the
probability of a comparison involving Nazis or Hitler approaches one."
There is a tradition in many groups that, once this occurs, that thread is
over, and whoever mentioned the Nazis has automatically lost whatever
argument was in progress. Godwin's Law thus practically guarantees the
existence of an upper bound on thread length in those groups.
-------------------------------------------------------------------
I guess it can be applied to mailing-lists as well...
Ref: http://c2.com/cgi/wiki?GodwinsLaw (and lots of other sites...)
Kind regards,
Henk.
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
