| |
ZL3AI > APRDIG 12.05.04 10:19l 255 Lines 10257 Bytes #999 (0) @ WW
BID : 3219-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 23, 2/10
Path: DB0FHN<DB0RGB<DB0MRW<DB0ERF<DB0FBB<DB0BI<DB0NOS<DB0EA<DB0RES<ON0AR<
ZL2BAU<ZL2BAU<ZL3VML
Sent: 040512/0740Z @:ZL3VML.#80.NZL.OC #:23798 [Chch-NZ] FBB7.00i $:3219-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: APRS station setup information page is up
From: Clair Dunn <cadunn@vt2000.com>
Date: Fri, 23 Apr 2004 05:24:01 -0400
X-Message-Number: 5
Hi all --
Thanks to Curt, WE7U, I now know what a WIKI page is and have set one up
to be used for passing on information about your particular APRS station
setup. Maybe we can save many hours of frustration by getting this info out.
PLEASE read the info on the first page the first time you visit. It will
help you if you haven't used one of these pages before (I know I had
never used one before!).
When you get a few minutes, please go to the following URL
http://www.vt2000.com/cgi-bin/wiki.pl/HomePage
and *after* reading the Home Page info, enter your information.
Remember, you can always go back and make changes to your page.
Thanks so much for participating!
Clair, W1CQD
----------------------------------------------------------------------
Subject: Re: Additional thoughts on the great debate....
From: "Jordi Costa" <bvjordi@bitsnvolts.com>
Date: Fri, 23 Apr 2004 11:40:53 +0200
X-Message-Number: 6
Hi all,
Just my thoughts after reading your comments.
Seem to be 3 possibilities for APRS.
1 - Leave it as is. No improvements. It will dead in a more long or short
time.
2 - Study compatible improvements.
3 - Move to new standards not back compatible = "New APRS generation".
(3) is attractive, but we should probably wait a long time and throw it away
"old" equipment, while (2) will allow to add and experiment some new
possibilities not excluding the migration to (3) in the future.
(2) does not exclude (3). Why not work in (2) now and carefully plan step
(3) ?.
Regards,
Jordi - EA3CIU
----------------------------------------------------------------------
Subject: RE: Everlasting discussions, Smart Move/Transition?
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Fri, 23 Apr 2004 06:50:12 -0500
X-Message-Number: 7
>-----Original Message-----
>From: db2fm
>Posted At: Friday, April 23, 2004 3:45 AM
>Subject: [aprssig] Everlasting discussions, Smart Move/Transition?
>
>2. use only new protocol on new devices (smart applications
> like Xastir (hopefully UI-View, which I use, too) can
> translate for the older ones.
This can be very problematic as demonstrated by IGates doing Mic-E
translation for similar reasons. The Mic-E translations caused
inaccurate translations, multiple duplicate packets, etc. to appear on
APRS-IS and also on RF.
>What shouldn't be done, is to use OpenTRAC on a complete seperate
>frequency with a seperate IS, That would never make a smooth
>transition possible.
The APRS-IS servers are designed to pass APRS packets. To that end,
they take the from-call, the unproto-call, and data-type character into
account. They only accept TNC-2 and AEA formatted lines. If OpenTRAC
is not compatible with these requirements, then those packets will not
be passed properly on APRS-IS. I have not read the OpenTRAC spec so I
cannot answer these questions, but from what has been posted on the SIG,
I would guess that OpenTRAC is not compatible with the current APRS-IS
servers.
These threads remind me of a decision IBM made about 15 years ago. They
thought that they could create a better piece of hardware and a better
operating system than the PC and DOS. They did, the PS/2 and OS/2.
However, they made them incompatible with the PC and DOS architectures.
It took IBM 10 years to recover from that mistake.
I have seen comments about how "difficult" the APRS protocol is to
understand, how "inefficient" the APRS protocol is, how APRS is "dying"
(a claim not supported by APRS-IS data, anyway) because of the protocol,
and how it is "impossible" to modify or expand the APRS protocol. All
are used as excuses to try to develop a new, incompatible protocol which
is "better". So far, I have seen nothing on this SIG to indicate where
OpenTRAC will be able to do anything that APRS can't do in a tactical
communications environment. Bob has presented a method for adding
further precision and datum to a posit. While his algorithm is a bit
simplistic (need to look for a second ! within 3 characters), it does
extend APRS to handle those issues.
The key is that the APRS protocol is not limiting to people who wish to
work with it, not just bash it. It certainly is not limiting to those
thousands of hams who want to use it in their everyday and special event
activities. Are there improvements that can be made? Yes. Have there
been compatible enhancements proposed on this SIG? Yes. As an APRS
client author, I can assure you that all of the APRS spec can be
supported without too much headache. Are there enhancements to the
clients that can be problematic? Yes, but that is the nature of any
software.
The belief that simply because a protocol is "better" without delivering
any features which can be incorporated into the existing protocol will
cause that new protocol to be adopted is not based in any historical
fact. Quite the opposite is true. If the existing protocol is
adaptable to the new requirements, which APRS has proven itself to be,
then the users will be slow, if not totally immobile towards changing to
a new protocol.
One only needs to look at IP4 vs. IP6 to see that in action. IP6 will
be adopted (about 10 years after it was intended), but only because it
provides for greater addressing than IP4 could be made to accommodate.
All of the other IP6 bells and whistles have done nothing to get it
adopted faster.
I encourage those developing OpenTRAC to continue, but don't be
surprised if everybody doesn't just jump onto your bandwagon. I would
hope that those putting so much effort into OpenTRAC might consider how
any unique features might be incorporated into APRS.
73,
Pete Loveall AE5PL
pete@ae5pl.net
PS: javAPRS (an APRS client) fully supports Mic-E and compressed
position packets.
----------------------------------------------------------------------
Subject: The Kenwood TH-D7 is obsolete ?
From: "K. Mark Caviezel" <kmcaviezel@yahoo.com>
Date: Fri, 23 Apr 2004 06:27:46 -0700 (PDT)
X-Message-Number: 8
Gentlemen:
Seems like I've read 'the kenwood d7 is obsolete' half a dozen times in the
last week here. Pray tell, what has it been replaced with ? I'll first
say I would love to be able to upgrade it- but the firmware is fixed so no
joy there. If my supposed 'upgrade' involves duct-taping a dual band HT
to a palm pilot and a TNC to my wrist- count me out. Sure there are a ton
of things we'd all love to change on it but I would submit that it's not
obsolete until it has been replaced by something better.
- KMC acoak (<-----got my own call sign right today)
----------------------------------------------------------------------
Subject: APRS+SA programming
From: "John Troutman" <w4dcr@ctc.net>
Date: Fri, 23 Apr 2004 09:53:54 -0400
X-Message-Number: 9
I am having a problem with the Map option on my APRS+SA. Each time the map
refreshes it goes to the USA size and I have to zoom in to get my location
and then when it changes maps it goes back to the same thing USA size. How
can I stop this and in the box next to enable at the top I put (30) and
check the box so the map will refresh every 30 second. What am I doing
wrong? John
----------------------------------------------------------------------
Subject: Re: Everlasting discussions, Smart Move/Transition?
From: wes@johnston.net
Date: Fri, 23 Apr 2004 10:27:14 -0400 (EDT)
X-Message-Number: 10
Juergen, Idea two is sort of what we started with... The idea that a
small black box attached to the kenwood serial port could manipulate the
station list to do the translation. But that idea has not panned out
because there are no software hooks in aprs mode to tell us when a packet
has come in, and no way to control the screen in APRS or packet modes. That
radio's lifecycle could be extended if there were at least some software
commands to control the aprs aspects of the radio better.
Has anyone been able to make the display change from the serial port at all?
How can we know when a packet has been placed in the station list?
Um einen Freund von mein zu plagiieren, mit Wissenschaft und Technik, was
noch nicht ist, kann sein.
Wes
----------------------------------------------------------------------
Subject: RE: Everlasting discussions, Smart Move/Transition?
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 23 Apr 2004 09:57:30 -0700
X-Message-Number: 11
>There were too many different possibilities to encode things: position
>can be send as raw NMEA, "generic" APRS-format, compressed (Base-91)
>and MIC-E encoded data.
My thoughts exactly the first time I read the spec.
>Next thing: wheather reports. The same thing! How many different formats
>do we have now, because weather-stations of any kind should be on-air
>with using just the old TNC?
Weather's got to be the worst part of it. I wanted to build a handheld
decoder for local hang glider and paraglider pilots that'd let them decode
local weather station data, but there's no way I'm making such a device
compliant with every funky proprietary weather format out there.
>An easy solution would have been to use a small PCB with a PIC and
>modify the data from the weather-station to ONE GENERIC format!
And now we've got that. The WXtrak does it, and if I ever get some free
time, the OpenTracker will do it too. Well, at least for OpenTRAC format,
and maybe one APRS format.
>My vision is a smooth move or transition to a new REAL STANDARD.
>As I proposed two days ago:
I'm not pushing for this myself. My philosophy is to concentrate on
building the best system possible. If and when the system shows itself to
be significantly superior to APRS, people will adopt it. Or maybe this
effort itself won't be integrated into mainstream use, but the lessons
learned could be applied toward a future APRS incarnation.
Where I DO intend to actively pursue OpenTRAC use is in closed settings,
especially SAR team use and special purpose telemetry applications, balloons
included. By the time the protocol matures, the whole Kenwood issue might
be moot.
Scott
N1VG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
