| |
ZL3AI > APRDIG 10.05.04 19:34l 200 Lines 9111 Bytes #999 (0) @ WW
BID : 3200-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 21, 4/10
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0ACC<DB0GOS<ON0AR<ON0AR<WB0TAX<ZL2TZE<
ZL3VML
Sent: 040510/1814Z @:ZL3VML.#80.NZL.OC #:23730 [Chch-NZ] FBB7.00i $:3200-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: APRS Kenwood Radios
From: "KC2MMi" <kc2mmi@verizon.net>
Date: Wed, 21 Apr 2004 13:57:36 -0400
X-Message-Number: 13
Bob?
<Name me ONE thing that you think the Kenwood Mobile Radio APRS capability
is "holding back" for the mobile or hand-held user? And I bet I can think
of a way to do it with a little ingenuity instead of a lot bitching...>
One thing. Well, two things if you can do them both.
When the D7 is used with a headless GPS (i.e. hockey puck) can you make it
display the position data and EPE data from the GPS?
All I want is to see the same DDD.MM.mmm that my GPS is putting out, on the
radio.
Can you do that one thing? That should be simple, just take the data from
the serial port and move it to the screen.
Displaying compressed posits would do equally well...but I don't think the
D7 can do that either, that would be harder still.
----------------------------------------------------------------------
Subject: Kenwood radios [was Re: APRS greater precision]
From: "KC2MMi" <kc2mmi@verizon.net>
Date: Wed, 21 Apr 2004 13:57:51 -0400
X-Message-Number: 14
Jim-
<Is it possible that Kenwood believed that by developing the D-7 and
D-700 radios >
I suspect the situation is far more complex than it seems to be. The D7
does many things and APRS is just one of them. Kenwood's "SKY COMMAND" and
SSTV features are also packed in that radio. It seems to be their "let's see
what else an HT can do" product, not at all a dedicated APRS toy.
On those three scores, they've dropped the SSTV unit, no idea why.
They couldn't sell Sky Command, it violated FCC rules which I understand
have only just now changed to allow it.
And APRS...Well, I don't know how many users bought it for APRS, but it
only supports the Mic-E subset anyway. I don't see that it is difficult to
use with APRS. The "paddle" text entry is not unusual for similar devices.
The radio stores three strings that can be selected without typing. And
considering the short comments it supports in MicE mode, there's no much
typing to be done anyway.<G>
Perhaps more to the point, the requirement for an external GPS with wires,
antenna, etc., might make it a bit kludgy.
But I think APRS is just riding piggyback on the extra capacity of whatever
chips they added to do Sky Command--which seems like a more Japanese idea,
remote controlled HF rigs<G>. Of course APRS would also give you a nice way
to know where your rig and yourself were.
<Both radios are difficult to use unless you have a computer tied to them>
Ever seen a Blackberry? A Palm? A cell phone? Nokia makes one with a full
keyboard now, keyboards and tiny computers are small and cheap. $29 for a
Palm IIIxe on clearance these days, and you've got a control computer. $29
more and you've got a full keyboard. Keep the wallet out, and you can use a
PocketPC or Palm with keyboard built in.
I think more to the point, folks would be unwilling to experiment with the
D7 because it is, well, a bit klunky. The battery pack is shared with other
models and isn't a good fit in the hand--or a logical configuration. There's
no good AA alternative for it. With the SSTV gizmo off the market and the
Sky Command in limbo, the D7 was a bit pricey for curious hams, you'd have
to want APRS in your handheld to gamble the extra price of the unit. A
limited market, for the limited APRS capabilities. Just the subset, and with
limited power options.
Worse, it has cords and plugs all over the place, i.e. use it with an
external antenna and power cord, then try to hold it in your right paw. Now
plug in a GPS or PC and try again, with either paw. And a dim display with
poor backlighting, that would have been unmarketable on consumer goods five
years ago.
Now, I'm sure there are real reasons why it was designed this way, and maybe
when it first went on the drawing board it was the best that could be done.
I'm just saying that in today's market, someone really has to WANT APRS IN
HAND in order to consider this unit versus all the other ht's out there.
The fact that no other manufacturer has offered an APRS-capable HT seems to
say more about what the manufacturers think of APRS in general. Of course
now, if you want location finding, you can buy a Benefone in the rest of the
world (the US always lags) or a service like AT&T's "Find Friends" and track
other cell phone customers on your own cell phone or computer. Not quite the
same--but similar to APRS, and deployed on the "national 850 and 1900MHz
repeater system". There's interest, and people are buying it. They're just
not hams, not buying APRS.
----------------------------------------------------------------------
Subject: Re: Kenwood MObile APRS
From: "KC2MMi" <kc2mmi@verizon.net>
Date: Wed, 21 Apr 2004 14:09:47 -0400
X-Message-Number: 15
<I dont think that your desire to obsolete the 70% of all APRS mobile
operators who are actually USING APRS for something besides weather will
appreciate your desire to obsolete them.>
There's probably a better way to do this, but offhand it strikes me that
there's a very simple way to support all the old users AND provide a newer
version of APRS with a larger feature set. And it's nothing new.
With APRS now even a TT3 can support sending a status string once every ##
transmissions. And both a primary and secondary configuration, with totally
separate parameters.
Suppose I send my primary in "APRS1.0" form, and alternate transmissions
with every alternate sending in "APRS3.0" format instead? The old equipment
gets to read half my squawks, the new equipment gets them all. An event
organizer can choose which to support as needed.
And if the new spec provides for an APRS version identifier, then new
receivers can also parse that and make their decisions based on the version
and contents, rather than continuing to obsolete themselves.
Or, we could all throw out our GPSes, because they've made LORAN-C
obsolete.<G>
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: Jeff King <jeff@aerodata.net>
Date: Wed, 21 Apr 2004 13:21:48 -0500 (CDT)
X-Message-Number: 16
Quoting KC2MMi <kc2mmi@verizon.net>:
>That's the APRS situation, in that not all of the hardware and software
>really supports all of the APRS spec now, and there is no "compliance
>certification" so the customers don't know if what they are getting should
>actually be expected to work.
....
> Microsoft addressed that somewhat, with the Windows Logo Certification
>program. APRS has nothing comparable.
FYI, that was supposed to have happened as part of the APRS spec process in
1999/2000. I realize it didn't, but just wanted to point out the good idea
you where suggesting was not overlooked. It just never happened.
That much being said, I'm now of the firm opinion anyone wanting to develop
for APRS or "APRS like" protocols has to take a completely organic approach
to it. There is no-one at the helm, and as such, whatever one develop's
needs to serve a specific need of that individial. While on the surface
this might appear to discourage mass production (since the "spec" is not
really the spec) it might have the positive effect of making the protocol
portion of the product more open for end user development. Many hams can
write APRS software and firmware, not many hams can produce a small surface
mount HT.
All the HT makers need to provide is small interface socket or bay, that
provides all the needed signals, including the ability to change frequency
and control the radio's display.
As others have already suggested, that would be a win win for the amateur
community and reduce the business risk for the manufacturer.
----------------------------------------------------------------------
Subject: Re: APRS Kenwood Radios
From: "Scott Miller" <scott@opentrac.org>
Date: Wed, 21 Apr 2004 11:23:20 -0700
X-Message-Number: 17
>All I want is to see the same DDD.MM.mmm that my GPS is putting out, on the
>radio.
You know, I just checked my OpenTracker GPS parsing code, and it's set up to
work with DD.MM.mmmmm. I don't think I've ever actually tested it, though.
I'll put that on my list of things to try. That still comes out to about
half the resolution (granularity?) available in OpenTRAC format, though it
loses a bit in rounding error. At a glance, I think max rouding error in
this implementation could be no more than about 10 cm. In reality I think
it's probably less than 4, worst case.
APRS compressed format is calculated from this value, potentially adding a
bit more rounding error, but probably not enough to be noticeable. Plain
old APRS data is pulled straight from the GPS data stream.
What gets me about the Kenwoods is that they apparently didn't follow the
NMEA spec, at least not initially. Apparently they were assuming fixed
sizes for the fields, rather than looking at the comma delimiters. I've
tried to avoid that mistake and gracefully handle extra digits where they're
not expected.
Scott
N1VG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
