| |
ZL3AI > APRDIG 16.06.04 10:15l 785 Lines 31705 Bytes #999 (0) @ WW
BID : 3473-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 10, 3/8
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040616/0732Z @:ZL3VML.#80.NZL.OC #:25936 [Chch-NZ] FBB7.00i $:3473-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Kenwood APRS radio...
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 10 Jun 2004 09:26:10 -0700
X-Message-Number: 46
Bill, this is hardly a fair comparison. Now, if I came in and started using
the F0 PID, and redefined APRS format specifiers to mean something
different, I think that'd be pretty close to what you're describing.
OpenTRAC uses the mechanism that was established in AX.25 more than 20 years
ago for separating protocols, and is implemented in every TNC out there, as
far as I can tell. It's been part of the underlying protocol design from
the very beginning, and packet radio would never have been good for anything
more than keyboard-to-keyboard QSOs without it.
Scott
N1VG
----- Original Message -----
From: "Bill Diaz" <william.diaz@comcast.net>
What would happen if someone in the future decides to create an "improved"
OpenTrak protocol that corrects its shortcomings and obvious design
deficiencies.
----------------------------------------------------------------------
Subject: RE: Compressed Positions -was-Re: Tetroon collateral damage report,
revision1
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 10 Jun 2004 09:27:37 -0700
X-Message-Number: 47
>There he is again, determined to Force ALL D7
>and D700 users off the air.... 38% of all users...
Just mark it as 'not recommended for new implementations' or 'depreciated'
or something. No need to force it off the air. We'll get there someday...
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Not all of us use Kenwoods in the field -was- Re: Tetroon
collateral damage report, revision1
From: Drew Baxter <droobie@maine.rr.com>
Date: Thu, 10 Jun 2004 12:27:42 -0400
X-Message-Number: 48
I think it's fair for Kenwood to charge for upgrades after the warranty
period, and I'm willing to pay for them if they provide tighter code and
improve the unit.
Based upon the information I read at the time regarding the D7A(g) software
upgrade, I think it would've been worth the 60 bucks.
Course - I think that more handhelds with built in TNCs would go a long
way. You seem to have proved that with your Palm+D7 combo. Are there any
other companies that have TNC-enabled handhelds? I know that Alinco has
several mobile radios that have a built in TNC, but not sure about
handhelds. If they make a handheld with a TNC, then well, I'd probably buy
that over the D7..
I'm not at that point yet that I'd give up my Kenwood screen in favor of a
laptop or yet another dash ornament.
--Droo, K1XVM
At 04:07 AM 6/10/2004, Jason Rausch wrote:
>I have to agree to this...
>
>Kenwoods are nice, don't get wrong. But when it comes to mobile use, my
>HamHUD II is far superior in my eyes, I could'nt imagine trading it in on a
----------------------------------------------------------------------
Subject: Re: [ Robert Bruninga ] Re: [ Robert Bruninga ] Re: D700 - Yes mine
has FLASH and In-Circ
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 10 Jun 2004 09:29:44 -0700
X-Message-Number: 49
>Show us the business model that makes sense.
>We dont see it. HAMS can use the RINO with
>no restrictions. WHy make a unique product
>etc...
Does Garmin make the Rino RF stuff themselves?
I think a better approach might be to get one of the ham radio manufacturers
to license the GPS and mapping stuff from Garmin.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: [ Robert Bruninga ] Re: [ Robert Bruninga ] Re: D700 - Yes mine
has FLASH and In-Circuit Programming.
From: Drew Baxter <droobie@maine.rr.com>
Date: Thu, 10 Jun 2004 12:39:05 -0400
X-Message-Number: 50
But yet there was a high demand for a 14,000$ HF rig that can shoot the
screen of the unit out to a TV? :)
ICOM's IC-2200H is APRS enabled (according to their ads), supposedly. It's
under my impression that it's solely in the way the DR-135TP Alinco is APRS
enabled (it can act as a standalone tracker). But that still means they
seem to think there's enough market to do such a thing. They must think
that people use APRS.
Icom seems to have a fair deal of money to throw around. If the last time
you suggested that to them was Pre-D7/D700 days, it's quite possible the
parameters have changed.
Not to suggest they will come out with the next all-in-one APRS radio. But
I thought the potential was there based on their desire to be
technologically motivated in the market. I'd have expected an APRS radio
from them long before Kenwood. But the Icom of today seems different than
the Icom of yesterday.
Just my impression. I don't own any Icom gear. Yet anyway. :)
--Droo, K1XVM
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 10 Jun 2004 12:43:28 -0400
X-Message-Number: 51
On 6/10/04 at 4:54 PM db2fm <db2fm@jfsattv.de> sent:
>The most important guideline, as I read it, of OpenTRAC is, that new
>things can be added easily and if time shows that something is
>obsolete, it can be left out without any harm to the network (only
>this parameter isn't shown any more, nothing else).
Sure, they can be dropped from the protocol, but then any data sent in that
protocol is lost. The fact is, it is just as easy for APRS to drop portions
of the APRS spec on those terms. The difference is we don't, because it is
bad from the user's perspective. You are not understanding our view of the
APRS world, let me try once more to explain.
The experience we want APRS users to have is when a user runs an APRS
program, it simply works. Any packet that is sent, is received and
understood by everyone, because everyone speaks the same language. APRS
ends up being one big interoperative network, not a bunch of partially
compatible sub-nets. We don't succeed 100%, but we do try our best. An
important component of that effort is a stable protocol...all of the APRS
developers have other lives, and cannot devote all of their time to this
hobby. Chasing an eternally changing protocol is not the way we want to
spend the time we have available to work on our code, especially when it
does nothing to enhance the usefulness of the system.
Suppose I'm an opentrack developer, and I want to add a new format for
position, the present one doesn't suit me. So I add it, and now my program
is using it, instead of the other one. Until and unless the other
programmers support my new format, only my users can see position from my
program. This is fine for a programmer that wants to lock his users into
his program, but it is not good for the users.
Under this scheme, the difficulty of keeping different programs in sync is
shifted to the users, who now may need choose between versions without good
interoperability, and embark on a never ending cycle of upgrades, fearing
if they miss one they will cut off from the network. Certainly, this makes
the programmer's job easier. However, this does not make the system better,
and it certainly worstens the user experience.
Now, I understand this isn't an issue for you and for some other people.
However, the majority of people on APRS are not people that want to spend
all day fiddling with their system and worrying about who is able to
receive what they are sending. They want to turn their machine on, send a
posit, weather report, message, or whatever, and know it will be readable
by everyone else on APRS. To most people, APRS is a tool to get something
done, not an ends in itself.
A different mindset, that is all. There is nothing wrong with what
opentrack is doing, but it isn't APRS, and we do not want it interfering
with APRS. Go off and do your experimenting someplace where it will not
affect APRS users. Why is protecting our users such a bad thing?
Steve K4HG
----------------------------------------------------------------------
Subject: Re: How to Run ZTerm on Mac OS X?
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 10 Jun 2004 10:09:50 -0700 (PDT)
X-Message-Number: 52
On Thu, 10 Jun 2004, Jason Winningham wrote:
>On Jun 9, 2004, at 7:03 PM, Matthew Stennett wrote:
>>
>>Not familiar with what Panther will do, so don't know how to run
>>simple terminal program to MFJ-1270C on OS X?
>
>I download and use kermit. The old unix standby tip is already on the
>system, too.
For Unix I prefer "Minicom". If they have a version of that for OSX, try
that. You'll definitely like that better than kermit or tip, although I've
used those in a pinch as well.
Another possibility is "Seyon", but it is nowhere near as lightweight, and
is a full-blown X11 program.
--
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: Kenwood APRS radio...
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 10 Jun 2004 10:13:13 -0700 (PDT)
X-Message-Number: 53
On Thu, 10 Jun 2004, Robert Bruninga wrote:
>>>>"Eric H. Christensen" 6/9/04 8:46:55 PM >>>
>>The Kenwood can't decode the Peet Brothers packets,
>>either...
>
>But No amount of software can keep up with the plethoria
>of WX stations interfaces. That is why APRS1.0 has only
>ONE WX format (2 variants). So that software could be
>written ONCE and it would always receive all weather.
>I know thta make it boring for programmers, but it is that
>kind of forsight by the APRS-WG that makes APRS work.
Do the Kenwoods decode weather out of object/item packets, like those
packets that are flying across firenet? That is allowed by the spec, but I
know some of the clients had to be tweaked to parse the weather info out of
them. Can somebody check this if the answer isn't known already?
--
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: Kenwood APRS radio...
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 10 Jun 2004 10:33:55 -0700
X-Message-Number: 54
>Suppose I'm an opentrack developer, and I want to add a new format for
position,
>the present one doesn't suit me. So I add it, and now my program is using it,
>instead of the other one. Until and unless the other programmers support my
new
Of course you can't support formats that haven't been created yet. It's
easy to add things, and we're putting a lot of effort into making sure that
you won't need to replace things often. That's why we've got position
defined with centimeter resolution, and telemetry available in everything
from 8-bit integers to IEEE double-precision floating point. And to take
the example of the position format, you could extend it another couple of
bytes for sub-millimeter resolution. A properly written client would see
that the length of the element was longer than expected, and correctly
assume the added portion was optional data.
We've only half-jokingly discussed support for coordinates on other
planetary bodies. I gave up when trying to figure out how to handle
coordinates on irregular bodies like Phobos or 433 Eros...
My point is, we're trying to future-proof as much of the spec as possible.
We'll never anticipate everything, but leaving room for graceful expansion
is one of the central goals of the project.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: [ Robert Bruninga ] Re: [ Robert Bruninga ] Re: D700 - Yes mine
has FLASH and In-Circuit Programming.
From: Danny <danny@messano.net>
Date: Thu, 10 Jun 2004 13:46:42 -0400
X-Message-Number: 55
Ugg.. For anyone that ever complained about the price of the Kenwoods
(which are a good deal, BTW), imagine what ICOM would charge for an APRS
radio..
Right now, there is little room for another APRS radio. If we are DEAD SET
on calling APRS 1.0 the first and last version of APRS, there really is no
need for flash upgrades or included improvements. If the Kenwood is APRS
and APRS is the Kenwood, all another company could do is copy the
Kenwoods... why bother?
Of course, who KNOWS what hand-greasing legal or gentlemans agreements were
made with Kenwood by the APRS-WG. There may be no motivation or it may
even be prohibited to work with another manufacturer on the creation of an
APRS radio...
Danny
KE4RAP
Thursday, June 10, 2004, 12:39:05 PM, you wrote:
DB> But yet there was a high demand for a 14,000$ HF rig that can shoot the
DB> screen of the unit out to a TV? :)
DB> ICOM's IC-2200H is APRS enabled (according to their ads), supposedly. It's
DB> under my impression that it's solely in the way the DR-135TP Alinco is APRS
DB> enabled (it can act as a standalone tracker). But that still means they
DB> seem to think there's enough market to do such a thing. They must think
DB> that people use APRS.
DB> Icom seems to have a fair deal of money to throw around. If the last time
DB> you suggested that to them was Pre-D7/D700 days, it's quite possible the
DB> parameters have changed.
DB> Not to suggest they will come out with the next all-in-one APRS radio. But
DB> I thought the potential was there based on their desire to be
DB> technologically motivated in the market. I'd have expected an APRS radio
DB> from them long before Kenwood. But the Icom of today seems different than
DB> the Icom of yesterday.
DB> Just my impression. I don't own any Icom gear. Yet anyway. :)
DB> --Droo, K1XVM
----------------------------------------------------------------------
Subject: Re: Compressed Positions
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 10 Jun 2004 10:47:52 -0700 (PDT)
X-Message-Number: 56
On Thu, 10 Jun 2004, Bill Herrmann wrote:
>At 02:42 PM 6/9/2004 -0400, Robert Bruninga wrote:
>>4) In addition, I now propose that the APRS-WG REMOVE
>> the problematic compressed protocol form the APRS
>> spec to help simplify the protocol for future programmers.
>
>Permit me to point out that that is a really, really bad idea unless you
>can guarantee that nobody is sending compressed protocol form on the air.
>If you remove it then future programmers won't have the documentation to
>decode it.
>
>Instead of removing it you would want to mark it as obsolete, not to be
>transmitted etc. but leave the information in the specification so that it
>can be decoded.
Sorry, but I just have to ask: Bob, weren't YOU the one that suggested a
few years back that I implement Compressed protocol in the HC11 tracker I
was working on, in order to encourage its use on the air, and therefore
encourage the APRS client writers to implement it? By the way, it worked!
Eventually.
I was using an HC11 board connected to a GPS and a PK-88 to generate mobile
packets. This was so that I didn't have to buy a new TNC to run mobile
APRS. I started out with GPRMC packets, then went to Mic-E, then to
Base-91 Compressed packets.
GPRMC was too long, and didn't get digipeated much.
Mic-E was short and got digipeated much more easily. Mic-E suffered from
both the Mic-E expansion problem at the igates, from some TNC's filtering
out the non-printable Mic-E characters, and from a bug in one of the
clients that made me appear in the Atlantic (I'm north of Seattle).
I was reasonably happy with the Compressed packets, as they were short, got
into the digi's better than and didn't suffer from the Mic-E expansion
problems. At the time though, nothing else would decode it, so I added
decode for it (and later encode) to Xastir so that I could track my mobile.
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.
Since then, the world has changed. More clients now have Compressed
encode/decode built-in, and a few have Compressed objects/items in them
now, which is also in the spec, but not in the Kenwoods.
Are you suggesting changes to the spec for good reasons now, or just on a
whim? Those of us who are trying hard to implement what's in the spec are
a little discouraged by this turn of events. It makes no sense.
--
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: Kenwood APRS radio...
From: Jeff King <jeff@aerodata.net>
Date: Thu, 10 Jun 2004 13:58:13 -0400
X-Message-Number: 57
Hi Steve:
On Thu, 10 Jun 2004 12:43:28 -0400, Steve Dimse wrote:
>A different mindset, that is all. There is nothing wrong with what
>opentrack is doing, but it isn't APRS, and we do not want it
>interfering with APRS. Go off and do your experimenting someplace
>where it will not affect APRS users. Why is protecting our users
>such a bad thing?
Already done. That is what the PID 0x77 was all about. OpenTrak is not the
APRS protocol. For stuff inadvertently getting on APRS-IS, due to user
misconfiguration, I believe Pete is, or has implement, filtering in his
java-aprsserve, which I understand would help.
So nothing to worry about here.
73
Jeff
----------------------------------------------------------------------
Subject: RE: Thoughts on a proposed replacement for D700
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 10 Jun 2004 11:04:40 -0700 (PDT)
X-Message-Number: 58
On Thu, 10 Jun 2004, Robert Bruninga wrote:
>>>>John Hall <n5jrh@houstonhams.org> 6/10/04 12:57:12 AM >>>
>>Aren't you a programmer Bob, as in APRSDos?
>
>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.
--
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 -was- Re: Tetrooncollateral damage report,
revision1
From: "Spider" <spider@rivcom.net>
Date: Thu, 10 Jun 2004 11:08:18 -0700
X-Message-Number: 59
----- Original Message -----
From: "Robert Bruninga" <bruninga@usna.edu>
>>>>"Eric H. Christensen" <kf4otn@earthlink.net> 6/10/04 9:56:21 AM >>>
>>Are we seriously talking about removing the one format
>>in APRS that actually gives us precision to 1 foot???
>
>Yes, that is the proposal.
>
>1) Because it has been replaced with the !DAO! constuct
> a) Which gives resolution to 7"
> b) INCLUDES Datum (so it is meaningful)
> c) can be human readable to 6 feet
> d) is 100% backwards compatible to all HW and software
So take one away that is not supported to another one that is not supported.
Who supports !DAO! whatever that is?
Who supports it now...right now??? What is it compatible with???
Datum IS defined within the Device and DOES NOT need to be reintroduced in
most all cases. If you are going to start sending DATUM, then why mickey
mouse it? Go straight to Meta files and reduce at least 50% of the APRS
bandwidth.
>3) And since the #1 complaint of all programmers is at
>the complexity and duplicity within the protocol and since
>the compressed protocol is broken in many applications,
>it seemed like it was a good one to phase out.
I would really like to know which programmers are complaining. Can you
share that list with us?
Xastir, and UI-View support it, don't know about the others. It is just now
starting to be used and Bam!
You slam the door! Unbelievable!
Jim, WA6OFT
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 10 Jun 2004 14:10:13 -0400
X-Message-Number: 60
On 6/10/04 at 1:58 PM Jeff King <jeff@aerodata.net> sent:
>>A different mindset, that is all. There is nothing wrong with what
>>opentrack is doing, but it isn't APRS, and we do not want it
>>interfering with APRS. Go off and do your experimenting someplace
>>where it will not affect APRS users. Why is protecting our users
>>such a bad thing?
>
>Already done. That is what the PID 0x77 was all about. OpenTrak is not the
>APRS protocol. For stuff inadvertently getting on APRS-IS, due to user
>misconfiguration, I believe Pete is, or has implement, filtering in his
>java-aprsserve, which I understand would help.
>
>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.
And on top of everything else, in most areas 144.39 is heavily loaded, and
not capable of supporting another service besides APRS.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: [ Robert Bruninga ] Re: [ Robert Bruninga ] Re: D700 - Yes mine
has FLASH and In-Circuit Programming.
From: Drew Baxter <droobie@maine.rr.com>
Date: Thu, 10 Jun 2004 14:11:54 -0400
X-Message-Number: 61
I disagree.
The way the data is displayed and the organization of the user interface is
what would make all the difference. This is why some people prefer certain
software packages over others. It boils out to features and doing what
people want. The Kenwood does not support some things, such as comments
that exceed 22 characters. There's also no way to switch MIC-E on and
off. As a matter of fact, you can't even add your APRS position packet to
the end of each repeater contact, as far as I know. Those are just a few
things, I'm sure someone else could pick it apart more. Not to say that
the Kenwood is garbage because of it, just to say there is 'room for
improvement'. In this age of Embedded Microcontrollers being used for
everything from Tinytrak to Video Game Mod Chips, I don't think anyone
would have to make a multimillion dollar investment. The HamHud folks
don't have multimillions, I'm sure.
I think the Kenwood is a good deal as well.. But I would've been more than
happy to pay a little more for some assurance of longevity. My D700 was a
gift, but, you get the idea.
ICOM would likely go overboard though, with a full TFT color mapping
display or something crazy like that. But I really think Kenwood is very
backwards when it comes to innovation in transceivers. Likewise I think
ICOM goes entirely too far.. :)
--Droo, K1XVM
At 01:46 PM 6/10/2004, Danny wrote:
>Ugg.. For anyone that ever complained about the price of the Kenwoods
>(which are a good deal, BTW), imagine what ICOM would charge for an APRS
>radio..
>
>Right now, there is little room for another APRS radio. If we are DEAD
>SET on calling APRS 1.0 the first and last version of APRS, there really
>is no need for flash upgrades or included improvements. If the Kenwood is
>APRS and APRS is the Kenwood, all another company could do is copy the
>Kenwoods... why bother?
>
>Of course, who KNOWS what hand-greasing legal or gentlemans agreements
>were made with Kenwood by the APRS-WG. There may be no motivation or it
>may even be prohibited to work with another manufacturer on the creation
>of an APRS radio...
>
>Danny
>KE4RAP
----------------------------------------------------------------------
Subject: Re: Compressed Positions -was- Re: Tetroon collateral damage report,
revision1
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 10 Jun 2004 11:16:44 -0700 (PDT)
X-Message-Number: 62
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.
So, just when small devices are coming out that implement the compressed
protocol (shall I mention the name "OpenTracker"?), and most of the clients
have implemented it, you want to kill that part of the protocol.
Sorry Bob, but that makes no sense at all.
>They can sitll implement them on receive, but if they
>transmit them, they should not EXPECT others to
>necessarily decode them.
Look at the Client Capabilities Chart, and tell me why you think
Base-91 Compression is under-utilized:
http://www.eskimo.com/~archer/aprs_capabilities.html
--
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 -was- Re: Tetroon collateral damage report,
revision1
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 10 Jun 2004 11:19:52 -0700 (PDT)
X-Message-Number: 63
On Thu, 10 Jun 2004, Robert Bruninga wrote:
>>>>"Eric H. Christensen" <kf4otn@earthlink.net> 6/10/04 9:56:21 AM >>>
>>Are we seriously talking about removing the one format
>>in APRS that actually gives us precision to 1 foot???
>
>Yes, that is the proposal.
>
>1) Because it has been replaced with the !DAO! constuct
> a) Which gives resolution to 7"
> b) INCLUDES Datum (so it is meaningful)
> c) can be human readable to 6 feet
> d) is 100% backwards compatible to all HW and software
Speaking of under-utilized... I know of no APRS client program that has
implemented it, save perhaps APRSdos. Compare that with Base-91
Compression implementation in the clients (and the Kenwoods I might add!).
>2) Use of that kind of precision without control of DATUM
>at the receiving end is a recipe for disaster
>
>3) And since the #1 complaint of all programmers is at
>the complexity and duplicity within the protocol and since
>the compressed protocol is broken in many applications,
>it seemed like it was a good one to phase out.
Not my main complaint.
>4) AND since the compressed is LONGER than the
>Mic-E format, it just has no advantages. Only disadvantages...
Some people prefer Base-91 compression of Mic-E. Mic-E does some extreme
hacks to get its short packets, including using non-printable ASCII
characters, which have caused several problems through the years. Base-91
compression is simpler to implement and widely supported now, plus the tiny
little OpenTracker devices implement it, and currently DON'T implement Mic-E.
--
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: Jeff King <jeff@aerodata.net>
Date: Thu, 10 Jun 2004 14:33:31 -0400
X-Message-Number: 64
Curt:
On Thu, 10 Jun 2004 10:47:52 -0700 (PDT), Curt, WE7U wrote:
>Sorry, but I just have to ask: Bob, weren't YOU the one that
>suggested a few years back that I implement Compressed protocol in
>the HC11 tracker I was working on, in order to encourage its use on
>the air, and therefore encourage the APRS client writers to
>implement it?
That is how I remember it as well. But did you ever market that tracker to
the general ham population? AFAICT, OpenTracker (which also supports APRS
compressed format) is the only tracker being marketed to support this.
(If TT3 does, it is not on the web page as such).
Curt, what you are missing here is removing a compact 1 foot granularity APRS
compressed format from the SPEC, is a small price to pay to lessen people's
interest in Scott's product. Don't forget, OpenTracker ALSO supports APRS
year 2000 Spec compliant compressed format:
http://n1vg.net/opentracker/features.php
http://n1vg.net/opentracker
http://n1vg.net/opentracker/downloads.php
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
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 10 Jun 2004 14:37:21 -0400
X-Message-Number: 65
>>>"Curt, WE7U" 6/10/04 1:47:52 PM >>>
>>4) In addition, I now propose that the APRS-WG
>> REMOVE the problematic compressed protocol
>> from the spec to help simplify the protocol...
>
>Sorry, but I just have to ask: Bob, weren't YOU the
>one that suggested a few years back that I implement
>Compressed protocol in the HC11 tracker I was working on...
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
3) Having precision to 1 foot without Datum is pointless
4) Progrrammers and users want a simpler spec and complain about
complexity and duplication of formats
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.
It seemed like the consensus of the requests I have seen.
>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.
>Are you suggesting changes to the spec for good
>reasons now, or just on a whim? Those of us who
>are trying hard to implement what's in the spec are
>a little discouraged by this turn of events. It makes
>no sense.
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.
Then APRS1.2 will be the more controversial issues.
but we ALL know that it is complex and does have some evolution in it and
duplication such as the compressed protocol. 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. 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.
Thus responding also to getting rid of under-used stuff in the spec, it
just seems logical to me to recommend its obsolescence...
Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
