| |
ZL3AI > APRDIG 10.05.04 08:27l 256 Lines 9369 Bytes #999 (0) @ WW
BID : 3173-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 20, 2/17
Path: DB0FHN<DB0RGB<DB0AAB<DB0FSG<I4UKI<IK5CKL<IK1ZNW<VE3FJB<ZL2TZE<ZL3VML
Sent: 040510/0647Z @:ZL3VML.#80.NZL.OC #:23686 [Chch-NZ] FBB7.00i $:3173-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: KPC-3+ Tracker Question
From: Derek Koonce <derek@dkoonce.com>
Date: Mon, 19 Apr 2004 23:01:22 -0700
X-Message-Number: 5
Phil,
You can find the KPC3+ documentation at
http://www.kantronics.com/schematics/KPC3Plus.pdf
This will have the pinout and all other data desired.
Derek
KE6JTP
----------------------------------------------------------------------
Subject: 7-Channel NWR-SAME Weatheradio with USB Interface
From: "Mark Fellhauer" <sparkfel@qwest.net>
Date: Tue, 20 Apr 2004 00:02:14 -0700
X-Message-Number: 6
Has anybody purchased this device yet?
7-Channel NWR-SAME Weatheradio with USB Interface
Catalog # : 12-258
Thoughts? Comments?
It looks interesting...
Mark
KC7BXS
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: db2fm <db2fm@jfsattv.de>
Date: Tue, 20 Apr 2004 11:33:43 +0200
X-Message-Number: 7
Am Dienstag, 20.04.04 um 02:16 Uhr schrieb Robert Bruninga:
>>>>"Scott Miller" <scott@opentrac.org> 4/19/04 6:36:54 PM >>>
>>I haven't used the Kenwood rigs myself.
>>How well do they deal with the extra extensions?
>If you are writing a new spec, I would think you should be 100%
>famiiliar with the kenwoods, how they operate, their strengths
>and weaknesses, how users use them, and how best to
>format things to fit on the small displays.
So, when inventing a new car you only look at dirt-tracks, not
at high-ways? The new car can also use the same roads as the old one...
>They provide a solid foundation for the type of information
>we are trying to push to the mobile...
>I'd suggest you invest in one...
>
>>A major focus of the OpenTRAC protocol has been data
>>tagging, so you know what's what and what you can ignore.
>>User interface is always going to be difficult on a small
>>device, and providing some meta-data gives you a little
>>more flexibility in how you present the information.
>
>I'd suggest that before you go too far afield in inventing
>a new protocol for mobile data, it would be worthwhile for
>you to gain experience with what is out there and already
>in use... by the majority of mobile APRS users.
The new protocol is already there in big parts...
>>I understand why APRS is the way it is. I probably would
>>have made many of the same design decisions myself ...
>>I'm not advocating an immediate switch, I just want to develop
>>an alternative and spend some time getting things 'right'
>>as much as possible.
>
>I think the best thing you could do to make it right,
>would be to experience what APRS is using, that is,
>the one product that made it an off-the-shelf commodity...
What is ham-radio? Buaying ready-made units? Or more likely
experimenting and building and developing new stuff?
>>There's a lot of cool stuff that could be done with a
>>pervasive UI-frame network that's just not going to fit
>>well in the existing APRS schema. I really want to
>>pursue the auto-programming ideas some more -
>>being able to have radios learn local repeaters,
>>BBSes, and so on automatically, having flags to
>>trigger icons on the radio display like 'net in progress',
>>'emergency use only', 'on backup power',
>>'autopatch available', 'IRLP enabled', and so on.
>
>Wow, but ALL OF THAT CAN BE DONE with the
>existing Kenwoods if someone would just sit down,
>look at the existing display, and decide how you want
>to present that data on the existing screen and then
>write a micro-processor to receive the stuff, and then
>handshake it back into the radio for display!
I can't agree here! The Kenwoods show some of that information
on their screen, but the are not automatically programmed by
information over the air. And - they CAN NOT BE UPGRADED by the
(experienced) user: That's the worst thing they could do with
such a fantastic unit (I own one), capable of a lot more then
enwood engineers expected when building it.
By the way: a HamHUD can be re-programmed with new code by the
user... (with more features in less code-space by using OT)
>That is my whole point. We have a radio, we have
>a display, we have the modems and channel and
>the network. What we need are people like you to
>write the uProcessor code to add the bells and
>whistles to what we have... We arent using these
>radios to their full potential because of the lack
>of people writing this application stuff and putting the
>needed data on the air... targeted to the front panel
>of an off-the-shelf existing display...
So, again, we have to build thing aroud the Kenwoods instead of
incorporating them into the Kenwood's code itself...
>No need to invent a new protocol. Just use what
>we have...
>
>>Pull into town and your radio beeps and pops up with a
>>new channel labelled 'Hamfest talk-in', or 'Disaster health
>>and welfare net', or whatever.
>
>Wow! It already does! Just put an object on the air and
>all Kenwood s that come in range will do exactly that!
>In my area, we have the local IRLP and ECHOlink nodes
>showing up on the Kenwood displays. Along with Hamfests,
>club meetings, and any other special event. ALso someone
>has written an INFOKIOSK that shows up and select it
>and send it a message and it responds with a list of
>all the local info you could ask for. Again ALL ON THE
>FRONT PANEL OF THE KENWOOD RADIO (or HT)...
Again, it only shows it, nothing more
>Also, my APRSdata application puts the location, Distance
>asimuth and frequencies of any satlelite in view ON THE FRONT
>PANEL of all Kenwoods in the area. It also puts a list of
>all future contacts in the next 80 minutes into the DX list
>on the radio. It also causes the Kenwood to SPEAK the
>satellites in view and their elevation. (if the kenwood
>hsa the speech chip).
>
>Wow, if you are not taking advantages of alll this capability,
>they you should really slow down and find out what we
>are doing now, before inventing a new protocol...
Slowing down is the enemy of all developing and movement to new
(not everytime better, but you can't know before) things
>>Certainly there's still stuff that can be done to make
>>APRS better.
>
>It sounds to me that you are missing an awful lot of
>what APRS is and can do. Maybe that is why you
>keep thinking you can make it better, becasue you
>are missing all that it can do...
I don't think so. Scott tries to do it right from the beginning
instead of changing thingswhen time comes. What wrong with that
attitude?
>>I should probably take a break from programming
>>and do some powerpoint slides on what I see the
>>whole thing eventually doing.
>
>Maybe what you should do is quit trying to re-invent the
>wheel until you understand what that wheel CAN do now...
It's like proposing to use an old car and try to check, what else
could be built in instead of buying a new one, which, right now
takes less fuel (you would know what I mean if you had european
fuel-prices in the US :)
>I'm trying hard not to sound critical, but if someone is not
>intimately familiar with the Kenwood, and at least what it
>can and cannot do, then I dont see how you have a basis
>for running off to invent a new protocol to do better things
>when you are not even familiar with what we can do
>now...
>
>Bob...
73 de Juergen
P.S. Why not use both protocols in parallel?
First step: sending both protocols each time
Second step: sending OT only, every Repeater converts and sends
both
...
999th step: only OT left over... (just kidding)
----------------------------------------------------------------------
Subject: Re: 7-Channel NWR-SAME Weatheradio with USB Interface
From: Claude Head <k5dtn@swbell.net>
Date: Tue, 20 Apr 2004 09:16:36 -0500
X-Message-Number: 8
I've had one for a couple of months. It works well. The USB allows
programming of the receiver (fips codes, frequencies, etc) from the
computer and provides a popup screen with the text message for any watches
or warnings. A summary file of these watches and warnings stays on the
computer until you delete it. The display on the receiver itself keeps a
count down timer going for any watches or warnings until they expire. With
no watches or warnings it shows the channel it is tuned to. The manual is
pretty good.
All told, I'm happy with it. Let me know if you have further questions
about it.
73, Claude Head
K5DTN
Dallas, TX
----------------------------------------------------------------------
Subject: Re: KPC-3+ Tracker Question
From: Robbie - WA9INF <mwrobertson@comcast.net>
Date: Tue, 20 Apr 2004 09:54:11 -0500
X-Message-Number: 9
Yes Phil,
I have been using that setup since the KPC3+ first came out. I have a
Yaesu 5 watt handheld, KPC3+, and TripMate in my trunk, and the gps was
modified for 12vdc. The patch antenna was replaced with powered antenna
mounted on my dash.
If I want to monitor my self and others, I plug the laptop into the
db25, cable also up in the front of the car. Making changes to UNPROTO
and stuff can also be done on the fly so to speak.
I really need to get back into that a little more, and see how it all
works with UI-View32 running the show with the shared port stuff. So
far, I have only used WinAPRS with the Control Q thingy I think. Its
been too long, :-)
Good luck Phil,
Robbie
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
