| |
ZL3AI > APRDIG 16.06.04 11:18l 742 Lines 29955 Bytes #999 (0) @ WW
BID : 3465-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 09, 5/8
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040616/0726Z @:ZL3VML.#80.NZL.OC #:25927 [Chch-NZ] FBB7.00i $:3465-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Tetroon collateral damage report, revision1
From: "Scott Miller" <scott@opentrac.org>
Date: Wed, 9 Jun 2004 12:44:00 -0700
X-Message-Number: 68
>>[there are] 5 different position [formats]... Bob, seems
>>to agree that... a new... more accurate format would be
>>a great candidate for a new user defined packet ..
>>This would then add a 6th choice to the mix...
>
>Unfortunately that is missleading. Here is where I stand:
>
>1) I do NOT want any NEW formats for position that cannot
>be decoded by existing users.
Speaking of number of formats... how many NMEA sentences are required to be
supported? I couldn't find a list in the spec. GPRMC and GPGGA of course,
and you've mentioned GPWPL before as well, I think, and what about GPGLL?
LORAN sentences?
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 9 Jun 2004 15:46:07 -0400
X-Message-Number: 69
On 6/9/04 at 3:09 PM Robert Bruninga <bruninga@usna.edu> sent:
>Throw out when Kenwood users are ASLEEP
>with their radios off, and the 16% becomes 25%.
>Throw out the HALF of all those packets that
>are from Europe (not part of my claim) and BINGO
>the 25% becomes 50%.
Well Bob, sorry to disappoint you, it has been nice to be on the same side
of an argument for once, but it doesn't go that high. Take the following
three lines and add them to the program I just posted (right before the
cnt++):
next unless (m/^[KNWA]/);
next if (m/TCPIP/);
next if (m/TCPXX/);
These discard any packet that does not start with KNWA or that originates
on the internet, which leaves US stations on RF, you get 2165 of 6975,
31.0%.
Still, nearly a third of the stations sending posits on RF in the US are
using Kenwoods, enough to make the point that this is not a trivial
minority.
A little more work would be to find what percentage of root callsigns used
a Kenwood...in other words, group K4HG, K4HG-5, and K4HG-8 together, and
count yes if any of them use Kenwoods. This would give the percentage of US
APRS hams that would be affected. Left as an exercise for the readers...
Steve K4HG
----------------------------------------------------------------------
Subject: Re: APRS TT
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Wed, 09 Jun 2004 15:48:30 -0400
X-Message-Number: 70
>>>"Scott Miller" <scott@opentrac.org> 6/9/04 11:46:08 AM >>>
>>I also believe that APRS TT did not take off because
>>no one offered any kits to build decoders...
>
>I'm working on a TNC/tracker project that'll have
>DTMF encode/decode support, but it's still several
>months off. I think a soundcard-based PC
>server application would be more practical.
Great! Yes, no hardware! Just implement the APRStt-to-APRS server in
Windows on a sound card. Then we can put them EVERYWHERE. I propose
145.55 as a possible APRStt user channel. Check to see if it is availabe
in everyon'es areea. But unlike APRS it doesnt have to be the same channel
anywhere. That only makes it convenient for traverlers..
And Scott, thats good news on your new device. Lets just work togehter to
see if we can make your DTMF codes compatible with the APRStt ones.
thanks
Bob
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: Danny <danny@messano.net>
Date: Wed, 9 Jun 2004 15:49:46 -0400
X-Message-Number: 71
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.
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.
Danny
KE4RAP
Wednesday, June 9, 2004, 3:12:37 PM, you wrote:
SD> On 6/9/04 at 1:06 PM Danny <danny@messano.net> sent:
>>The issue a LOT of us have is that the system for improving APRS
>>sucks.
SD> I think you are grossly overestimating LOTS. According to sourceforge,
there are
SD> "about 30" subscribers to the opentrack mail list. Last I heard, there were
SD> nearly 3000 on this list, there are many thousands more users of APRS not
on the
SD> list.
----------------------------------------------------------------------
Subject: Re: APRS Protocol - A Modest Proposal
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Wed, 9 Jun 2004 14:53:01 -0500
X-Message-Number: 72
Let's have different input frequencies for everything, then. That would
really take care of that collision beast. APRS is a tactical protocol.
It is designed that everyone have the opportunity to hear everyone else
real-time. Your proposal goes against that design. From the numbers in
the DFW area, this type of movement would reduce 144.39 load less that
1%! As I say, if that is how you want the OpenTrac protocol to work,
great, have at it. But it is not how APRS is designed nor would it
accomplish any significant benefit in the APRS world.
And your "clarification" of this sub-point still does not address your
major point of trying to support using a frequency shared for APRS
operation with a non-APRS protocol: "far more than eliminating a few
experimental packets". No one that I read (and I admit that most of the
posts over the past week have gone to the trash) has implied that
experimentation within the APRS protocol should be discouraged. In
fact, I think most have said that APRS has many features built in to
encourage experimentation.
I like how people try to jump on a sub-point to try to distract from
their primary point.
I am done. Flame away. I have better things to do than pursue petty
subjects like this.
73,
Pete Loveall AE5PL
>-----Original Message-----
>From: Scott Miller
>
>As I described the proposal earlier, you'd still be
>digipeating onto the primary 144.39 channel. It'd still let
>you eliminate a lot of collision-prone traffic, especially if
>you let it aggregate data for 10 to 30 seconds rather than
>retransmitting immediately.
----------------------------------------------------------------------
Subject: Re: [ Robert Bruninga ] Re: Tetroon collateral damage report, revision1
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Wed, 09 Jun 2004 14:52:12 -0500
X-Message-Number: 73
>Yet, we still just keep getting all this SAME carping....
>They identified a need (1 foot resolutioin), we came
>up with a solution that was pretty darn good, and
>fully backwards compatible to all users AND we
>simplified the spec in the process...
>
>Yet, the complainers, that don't even have a kenwood,
>that dont use APRS in the field anyway (or they would
>have one), and who just like to argue to hear themselves
>argue just keep on complaining...
Bob, I enjoyed your correcting my comment right up to these paragraphs. I
think this personal attack stuff needs to be stopped.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 9 Jun 2004 16:01:43 -0400
X-Message-Number: 74
On 6/9/04 at 3:49 PM Danny <danny@messano.net> sent:
>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 do not think so. Opentrack has made several appearances on this sig, and
its self-advertised mission is to fix all that was done wrong with the APRS
protocol. If I were dissatisfied with APRS and/or the way it was run, I
would certainly be on that list. Even if you want to say only 1 in 10
dissatisfied people are on the list, it still only amounts to a few percent
of all APRS users.
>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.
The difference is in what you and I consider a real issue. For Bob and I,
it is maintaining the utility of APRS for the USERS, not the programmers.
I've listened to all the suggestions presented, and while some would be
nice, a few even cool, when weighed against the trauma it would cause to
the users, I am unswayed. Your opinion obviously differs, and that is
certainly your right.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Tetroon collateral damage report, revision1
From: "Scott Miller" <scott@opentrac.org>
Date: Wed, 9 Jun 2004 13:12:35 -0700
X-Message-Number: 75
>But it is NOT compatible with anything that can currently
>receive only APRS!
It's not intended to be...
>Thus all KENWOOD users (4100 of them) that are using
>APRS in the field and where their Kenwood is their only
>view of the tactical-real-time local stuff going on around
>them will be DENIED the ability to see any OPENtrack
>users. This is sure a recipe for disaster at a comms event.
It would not only be a disaster, it'd be just plain stupid. You don't bring
an Appletalk machine to a DECNET network and expect it to work. But then,
one or two machines running Appletalk on the same network aren't going to
suddenly stop the DECNET machines from talking to each other, are they? But
wait... all those VAXen are being DENIED an opportunity to get the critical
information they apparently need from that Powerbook!
>I SAY AGAIN, it will DENY all existing users of the kenwoods
>the ability to see what is going on around them in their
>local real-time-tactical situation. These are the users inthe
If you're running OpenTRAC, it's because YOU DO NOT NEED APRS USERS TO SEE
YOU. If you need APRS users to see you, you use APRS.
God forbid someone should accidentally turn off their TinyTrak and DENY all
existing Kenwoods the ability to see where they are.
>I say again. If there is a specific need for the end
>user in the field that cannot be met within the current
>spec, let me know. Ill work with you to find a way to
That's a little like saying there's nothing on the Internet that can't be
done with email. It's true... you can book plane reservations using email,
get news, retrieve files from FTP sites (used to be the only way I could get
FTP), you name it. Does that mean email is the ultimate expression of what
can be done with the Internet, and that there's no need to experiment or
develop new protocols? I don't think so.
>the APRS network, and ALL Kenwood users just
>for the sake of a few programmer egos...
You think I like programming for the sake of programming? I'll tell you, I
can think of a lot more interesting things to do with my evenings and
weekends than writing a bunch of code to do something that's already been
done. There's no way I'd be doing any of this if I didn't think it was
laying the foundation for a system that WILL improve the user's experience.
I chose to develop a new protocol, because given the number of ideas I've
got for ways to add new capabilities and new applications to APRS, and given
the trouble involved in shoehorning any single one of those into the
existing protocol, it made more sense to make a clean break, and design a
new protocol to corrent the mistakes and kludges of APRS, provide room for
what I want to add, and leave plenty of room for future expansion beyond
that. What you see in the spec now is the initial effort to duplicate the
existing features of APRS within that framework. Before we can go adding
completely new features everywhere, we've got to iron out the protocol
details and make sure it works with what we've got now.
>3) I'd rather see all that great creative energy being
> expended on something we can all use, NOW rather
> than re-inventing the same wheel with a different
> name that by its very definition is iincompatible
As I've mentioned before, adding new features to APRS reaches a point of
diminishing returns. Each new feature takes more effort to add to the
protocol than the last, because we've got to make sure that it not only
coexists with the spec itself, but with all of the other features that have
been crammed in since then. I'd rather spent the time and effort now to
build a framework that'll promote innovation in the future.
By all means, go on adding to APRS. I've contributed some ideas myself.
But what if all those jet engine pioneers had decided it wasn't worth
wasting their creative energies on creating something new, and had just
stuck with designing piston engines that would have been useful right THEN?
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Tetroon collateral damage report, revision1
From: Doug Bade <dbade@clecom.com>
Date: Wed, 09 Jun 2004 16:20:21 -0400
X-Message-Number: 76
I had written a reply which was running on 2 pages, but decided to get
short, as it seems those of us who like to elaborate, get torn up the
most... really bizarre..
I used the same logic which seems to be used in the argument of "because no
one complained they were directly harmed", therefore no harm was
done...Because no one reported using the OT data, thus the data was not
used by anyone... same logic, same reasoning... Keep them both and really
confuse issues, or throw them both out and focus on real issues.
I vote drop them both as irrelevant and focus on the real issue of whether
OT should be encouraged on the APRS-IS ( as well as the dedicated RF
infrastructure ) or blocked.. The choice is very simple... one or the
other...The APRS-IS camp seems to have said their piece, I as a digi owner
agree... I think it belongs somewhere else and I choose to implement
safeguards to prevent further disruption in my area. If the OpenTrac folks
prove a better mousetrap and Kenwood or Icom or whoever buys in, they well
may be the ultimate winner, the future will decide that.
I love my D700, and APRS, I like to see what is happening, that is why I
own a radio with a display, not just an APRS encoder and a radio. It serves
my purposes as is, and I cannot agree it is even remotely obsolete, just
because there may be better ways to do what it does.... wideband FM is
obsolete, but we do not stop using it, as it does fill the role better than
many alternatives... A solution of convenience, but it works ... today.....
and very well....
Doug
KB8GVQ
----------------------------------------------------------------------
Subject: RE: APRS user beware part 2
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Wed, 09 Jun 2004 21:39:10 +0200
X-Message-Number: 77
I know I'm responding late to this, but I think something is overlooked.
>Yep, no problem with that. But let the USERS VOTE
>with their VFO's. Put OPENtrack on 145.55 or 145.01
>and let them come. But dont stick a knife in the
Bob wants to have OpenTrack on a different channel to avoid problems with
the existing APRS infrastructure. But there is a very practical problem
with this and that is locations.
Now at first glace you would say, just add another TRX and OpenTrack digi
as addition to the APRS digi. But that doesn't work, reception on 144.39
will be impaired a lot by the transmission on 145.01 and vice versa. In
Europe we discovered this quickly when we tried to co-locate APRS at the
Packet BBS sites.
So allocating a different channel will mean that OpenTrack has to find new
high-visibilty sites which is of course near impossible. Finding one site
was probably allready challenging enough. So to advocate for an alternate
frequency is comparible to saying "APRS seased all the best locations and
OpenTrack get lost". That is what it boils down to.
I only see one alternative and that is to move OpenTrack to 70cm; that way
co-location is no problem. Propagation on 70 is however much worse and also
70cm is not as common as 2m equipment.
Technially you could also add filters like used in repeaters, but I don't
think its feasible.
What bothers me the most is the lack of ham-spirit. The spirit to take
technical challenges and to try out new things. A minor change in the
network, just adding a TNC setting, seems to be too much to ask for
eventhough it would enable fellow hams to experiment with a new protocol
with only minor impact on the APRS infrastructure.
In Europe we have 144.800 for APRS and I know for sure OpenTrack is welcome
there. I am convinced that this will give not a single problems in the
infractucture and any APRS equipment connected to it (unless APRSdos is
used, which virtually nobody does overhere).
But reading Bob's messages it looks like the APRS folkes in the US are too
lazy to fix their network to a state it should have been in in the first
place and not to give-in an inch for people with different ideas. Don't get
me wrong, I know a lot of you are more than willing but this is just not
the impression I get by reading Bob's messages. I misjudged Bob, I thought
that he would be one of the first to fix flaws in the APRS network but I
assume keeping an alien protocol out is higher on his agenda.
Anyway, I'm not very insipered by all of this. But hey I'm just a whining
programmer so maybe I should just quit and leave all those wonderfull END
USERS to find their own software or to find another fool that is crazy
enough to write software for them. Let them suffer through the cumbersome
process of implementing an APRS parser and stumble though all the same
mistakes again because of its clucky implementation and the 1001 hidden
features that nobody heard of but were all in there from the beginning and
are more often than not FUNDAMENTAL for APRS.
Mmmm, reading this back I realy sound frustrated. Maybe I am? At least I
have got this of my chest.
Ok, enough, let's take a look at the Object caching idea and see if this is
something I can squeeze in into DIGI_NED...
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: APRS user beware part 2
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Wed, 09 Jun 2004 21:42:38 +0200
X-Message-Number: 78
At 01:16 7-6-2004 -0400, Christensen, Eric wrote:
>So, I guess you manually take APRS positions off your telnet screen and plot
>them on a paper chart, right?
Yea, after doing the math on MIC-E and compressed packets; their prositions
are not what I would call HUMAN readable...
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 9 Jun 2004 16:31:02 -0400
X-Message-Number: 79
On 6/9/04 at 3:46 PM Steve Dimse <k4hg@tapr.org> sent:
>Left as an exercise for the readers...
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%
The code:
------------cut here----------
#!/usr/bin/perl
$lastcall="x"; #in initialize last call
while (<>)
{
next unless (m/^[KNWA]/i);
next if (m/TCPIP/);
next if (m/TCPXX/);
if (m/\:[\'\`].{8}[\]\>]/)
{
$kw = 1;
}
m/([A-Z0-9]+)/;
$call = $1;
if ($call ne $lastcall)
{
$lastcall = $call;
next if ($call eq "x"); #Don't tabulate initial call
$cnt++;
$kwcnt++ if ($kw);
$kw=0;
}
}
$cnt++; #tabulate last call
$kwcnt++ if ($kw);
printf ("%d of %d, %3.1f%%\n",$kwcnt,$cnt,100*$kwcnt/$cnt);
----------------------------------------------------------------------
Subject: Re: APRS TT
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Wed, 09 Jun 2004 16:23:21 -0400
X-Message-Number: 80
EVERYONE, THIS IS IMPORTANT!
PLEASE read and understand this. This is about the APRS-TOUCH-TONE project
which I developed 2 years ago which intended to make ANY HT work just like
the D7 HT for sending and receiving APRS wtih TOUCH TONE one way and VOICE
RESPONSE coming back.
FUNDAMENTAL TO THIS PROTOCOL was the desire to keep the USER Touch-Tone KEY
sequences as close as possible to the KENWOOD D7.
Thus, to send a message on ANY HT with a TTpad you would do SIMILAR KEY
presses to accomplish the SAME thing. Thus, the APRStt spec which defines
these sequences was intended to make sure that WE ALL eneded up speaking
the same TTkey language.
BUT AS IS CLEAR, many people dont have a D7 dont realize how it is so
importnt to APRS and therefore we are going to see all kinds of DTMF to
VOICE applications, ALL OF THEM re-inventing the wheel.
There are two ways to encode the ALPHABET on a touch tone pad. Half the
cell phones do it one way, the other half do it the other way. THAT IS WHY
I WROTE THE APRSTT SPEC EARLY ON, to try to make sure we all ended up doing
ONE way for HAM radio.
And since the Kenwood is out there, and has a full ALPHABETICLY IMPRINTED
KEYPAD and since the APRStt was intended for APRS it only made sense to
choose the same (democrat or republican) DTMF alphabet method already in
use on every D7 and D700 for APRStt.
I explained this to ECHOlink folks, but they didnt have a D7 and said well,
shucks, they just did it the way one of their cell phones did it and so now
we are doing it TWO different ways.
ARGH!!!!!!!!!
Please, lets get on the same page NOW before it is too late. Here are the
differences.
In one system, QZ are on the 1 key and PRS on the 7 key. And you select
the letter by the number of presses. A is one press, B is 2 presses, and C
is 3 presses. The AVERAGE is TWO. But the advantage is your finger never
leaves the same key.
In the other system, PQRS is on the 7 key. and again you only use 2 key
presses for every letter. One press to select a key and the other to say
which of the 3 or 4 letters to use.
Clearly, in the MOBILE environment where you are trying to DRIVE at the
same time, it is far easier to use the first method. Because your finger
never leaves the key. AND when APRStt wants to abbreviate something, it
uses the FIRST letter often, so that a SINGLE key press is adequate to
spell that letter.
I worked on APRStt over TWO YEARS to optiimize all this stuff to make the
KEYBOARD entry as efficient as possible to match the needs of HAM radio
operators. Theprotocol was designed FROM THE BOTTOM UP to match the
detials of that user interface.
Now we see others starting off to re-invent this DTMF to VOICE use of HAM
radio and yet, nothing I have seen yet implies that ANY of these
applicaiotns have started from the basis of the fundamental USER interface
of the keypad to make sure the entry is efficient and easy.
These APPS are being designed from the top down and the DTMF user then just
has to type in what the programmer wants (not what was designed intot he
protocol to make the TTPAD entry easy.
Please, I BEG that we all get on the same page. I dont claim APRStt
protocol for DTMF encodeing of things is perfect, but I spent over a year
on it to try to serve as a starting point to make sure we STARTED froma
common user interface for HAM radio.
If you knw of ANYONE that is working on DTMF encoding for HAM radio, please
pass this to them. We dont want APRStt, Echolink and all these talking
weather stations, and now Scott's device all requiring dissimilar key
strokes not based on the KNOWN techniques of DTMF to Alphabet encoding...
>>>"Bill Vodall" <wa7nwp@jnos.org> 6/9/04 12:47:00 PM >>>
>Much of that functionality is in Echolink's parallel
>project - ECHOSTATION...
http://www.synergenics.com/sc/
>Think how cool that would be to tie it all together with APRS...
And how DUMB it would be if you have to SPELL WB4APR TWO DIFFERENT WAYS ON
TWO DIFFERENT HT's!
ARGH!~ The mind is fading....
Bob
----------------------------------------------------------------------
Subject: RE: Thoughts on a proposed replacement for D700
From: "sv1uy" <sv1uy@ham.depa.gr>
Date: Wed, 9 Jun 2004 23:31:01 +0300
X-Message-Number: 81
On Wed, 09 Jun 2004 13:17:00 -0400, Robert Bruninga wrote
>
>Also, in my area where we have APRSdata and APRStraffic
>running, my kenwood also flashes on the front panel
>these TINY-WEB-PAGES of information:
>1) Name, angle, distnace and freqeuency of any HAM
> satellite in view NOW. Make it fun to operate
> satellite mobile with NO APRIORI knowledge. Just
> use the data on the front panel to QSY and work it
>2) Automatic Location of any traffic slowdowns in the area
> showing the speed of traffic, the distance and direction
> from me and who's D7 or D700 automaticlaly repoted it.
Great ideas Bob, if only some programmers bothered to write some code in the
modern operating systems so that we can take advantage of the new hardware!
>True, we would only have TRACKERS, and then
>APRS/Internet couch-potatos just soaking it up.
>But no access to APRS in the field unless you bring
>along the PC and all the sphegetti wiring, which is
>unsafe at any speed (Have you seen the picture
>of my VAN fire due to rats nest of GPS/TNC and
>LAPTOP wires? hi hi... (actually it was a D700,
>but the wiring was th elaptop legacy from before the
>kenwood came out...]
Well trackers are OK for special applications, but how can one send SMS
messages from a tracker? How from an OPENtracker? By connecting a PDA to
it? No thank you very much. Not suitable for a portable/mobile environment
unless you have an extra person sitting next to you in the car who will do
all this operating.
So I prefer to stick with the KENWOODS. Wouldn't it be better if Kenwood's
next D7 also had a GPS built in? GARMIN and Albrecht already have them in
FRS and PMR radios. I do not want to add another box in my D7 or D700 and
if I could do with a new version with the GPS built in all the better.
>And that is the problem of operating DUAL PROTOCOLS
>on the APRS channel, since it will DENY all existing
>users (VIEWING THE DATA IN THEIR CARS) of
>access to what they thought was the APRS channel.
This is the most important CON against OPENTRACK operating in the same
channel that APRS uses today.
I wonder why don't you try OPENtrack on 2.4GHZ using the 802.II protocol
where you can take advantage of the high speed links? You can use the lower
channels which fall whithin the amateur band there! I think OPENtrack,
being a thing of the future is best suited to run in a futuristic
frequency!!! If it is better than APRS then it will take off there! But
then again you have to have everything fit in one box (and I mean one box
containing at least the radio, a decent display, a mini keyboard and even
better a GPS built in), just like the KENWOODS otherwise you will end up
having home users exchanging SMS messages with other home users, which I do
not think is the purpose of any decent tracking protocol.
Sorry guys, I do not think I like the idea of mixing APRS and OPENtrack in
the same frequency.
Oh did I forget to mention again? Remember this is only a HOBBY!!!
---
73 de Demetre SV1UY
e-mail sv1uy@ham.depa.gr
http://sv1uy.webhop.org
http://www.athnet.ampr.org/~sv1uy
http://www.qsl.net/sv1uy
----------------------------------------------------------------------
Subject: Re: [ Robert Bruninga ] Re: D700 - Yes mine has FLA SH and In-Circuit
Programming.
From: "Eric H. Christensen" <kf4otn@earthlink.net>
Date: Wed, 9 Jun 2004 16:31:57 -0400
X-Message-Number: 82
Gregg G. Wonderly said:
When the D7A(G) upgrade was installed, kenwood could have made it possible
for users to do future upgrades by extending the wiring harness into a
place where it was accessible. This is still an option for them if they
are interested in extending the life of the radio by increasing its
usefulness with new features (regardless of whether that might be OpenTrac
support or otherwise). I'd pay for something that was a real upgrade (as I
did for the first one).
----
Gregg,
I think this is a great idea. Maybe Kenwood could work around the warrantee
issue by issuing flash upgrades via the internet (charge $20 or whatever)
and download it and upgrade your D700 or D7A... Keeping the radio alive!
73s,
Eric KF4OTN
----------------------------------------------------------------------
Subject: Re: Tetroon collateral damage report, revision1
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Wed, 09 Jun 2004 16:46:35 -0400
X-Message-Number: 83
>Ok Bob, enough with your kenwood sales propaganda.
>I use APRS in the field, but NOT with a kenwood and
>I dont plan on purchasing one. I am quite happy with
>my laptop, TNC, and portable.
But you are a 5% minority and not exactly representative of the typical
APRS mobile DATA RECIEIVING AND DISPLAY mobile...
>I think it's important to point out, that so far in these
>threads, you have stated the following:
>1. Real APRS users use hardware, not software.
>2. Those that use software are home bound couch potatoes
>3. To be a REAL APRS user, you MUST be using APRS in the field.
>4. If you use APRS in the field, you MUST be using a kenwood (sales
pitch).
Distortions! For example, #4. I would say PROBABLY, not MUST. The
statistics from the APRS-IS prove that... You dont, but then you are 1 in
20 that all use something else...
>If you are worried about the image that APRS gets from
>the internet, think about the propaganda that is being
>spewed out by it's creator.
Not propaganda, just simple truths from the numbers that have been posted
here by others...
Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
