| |
ZL3AI > APRDIG 12.05.04 10:27l 263 Lines 11166 Bytes #999 (0) @ WW
BID : 3225-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 23, 8/10
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040512/0740Z @:ZL3VML.#80.NZL.OC #:23804 [Chch-NZ] FBB7.00i $:3225-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Everlasting discussions, Smart Move/Transition?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 23 Apr 2004 18:41:34 -0400
X-Message-Number: 48
>>>Henk de Groot <henk.de.groot@hetne >>>
Concerning an external PIC to add new features to the Kenwood:
>With the "AI 1" command the TH-D7 spits out newly
>received data from the list all by itself, no need to poll
>any list at all! The only problem is that the data which
>the TH-D7 does not recognize will never enter the list
>in the first place....
*** Which is exactly why if we keep backwards compatiblity in the basic
packet and add any new feature ONLY to the free field comment as I have
suggested, (and as APRS was always intended) then an external PIC can do
anything it wants with it and send it back into the radio:
As I posted years ago, My list for what to do with an external PIC are:
1) Be able to auto-QSY the radio via packet
2) Be able to send LOCAL Freqs to the radio memories
3) Be able to update the outgoing STATUS text to show the current frequency
in use on the B side
4) Be able to QSY the radio to take a SIGNAL measurement and report the
value back to the interrogator
5) Be able to alert the Driver of nearby stations which are on an
approximate intersecting course (this is not collision avoidance, but to
alert you when you are on a long drive that someone 120 miles away is
probably eventually going to pass you and to be alert for a direct QSO on
those long interstates...
And many more...
Lets get those PIC programmers busy doing what can be done with what we
have rather than trying to re-invent another APRS wheel.... that
intentionally obsoletes what we have...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: Compromise proposal (was: Re: The APRS-WG and spec improvements.)
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 23 Apr 2004 18:55:43 -0400
X-Message-Number: 49
>>>"Curt, WE7U" <archer@eskimo.com> 4/23/04 6:18:40 PM >>>
>It appears that Bob doesn't want compressed Objects/Items used, as
>the Kenwoods [and many other current implementations]
>don't currently support it. My take on that is that
>objects/items are not that prevalent so far in the scheme of things
>(unless you hook up to Firenet).....
Yes, and that is one of my biggest dissappointements in the use of APRS by
the general HAM user. The ability to let everyone instantly see where
things are (not just trackers) is the true value of APRS to actually doing
real world practical things with APRS.
Objects are just a click away. We should be using them a LOT more. (maybe
now that we are getting people to cut back from BROADCAASTING their
personal favorite objects out over 3 states (which makes everyone HATE
objects), we will get back to using them as intended and that is in the
LOCAL area where they REAL and IMMEDIATE value to the user...
But I rant....
oh well.
Oh, so again, just because people dont use objects much is not a good idea
why you should exclude Kenwood users from seeing them.
hopefully people dont use 911 much either, but that is not a good reason
for getting rid of it...
Bob
----------------------------------------------------------------------
Subject: RE: Everlasting discussions, Smart Move/Transition?
From: "Daron J. Wilson" <daron@wilson.org>
Date: Fri, 23 Apr 2004 16:02:08 -0700
X-Message-Number: 50
>>>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.
As much as I like the WXTrak, we found that it wasn't quite that seamless.
Currently it does not transmit the position and weather data in the same
packet, which I understand is what the spec says should take place. Thanks
to the receptiveness of Byon, he has that on his list to work on, and
perhaps that will grow.
In the mean time we are plotting a pic based solution that takes weather
data from any number of devices and converts it into the correct format to
be forced in to the KPC3+ digipeater so that the transmission comes out
compliant. It's a fair amount of work based on many different weather
stations, but a worthwhile goal.
In the interim we paralleled a WXTrak to the KPC3+, made a couple
modifications and at least have weather transmissions from the hill now
that are readable on the Kenwood. I think the long term answer to some of
this stuff is just going to be PIC devices between somewhat incompatible
devices to force them to be compliant.
It seems like rather than develop something that way, the software authors
adapted to display some weather transmissions that were not spec compliant.
Tough call, that meant their software worked good, but kind of left the
Kenwood group behind a bit and made less of a perceived need for 'proper'
formatting.
73
N7HQR
----------------------------------------------------------------------
Subject: Comments on the D7
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 23 Apr 2004 20:13:26 -0400
X-Message-Number: 51
Kenwood D7 itemized list:
Here is the itemized list I received privately from one of the persons who
made the post about the obsolescence of the Kenwood D7. He was nice to
take the time to compile this list. Interestingly, NONE of his
obsolescence items had anything to do with APRS except the lack of FLASH
upgrade (but no mention of anything in the protocol that needed
upgrading)...
Here are his complaints and why he feels the radio is obsolete: And I
quote:
1) Lousy ergonomics. It just does not fit well in my paw...
2) When add an antenna or antenna cable, an external power cord, and
[optional] PC or GPS or ear/mic cords ... What you get is a porcupine
with wires and fittings coming out all over...
3) The only decent battery pack for it is the stock "hi volt" 9.6V pack,
which contains 8x 1/2A cells in it. If the radio was only 4mm wider, they
could have used AA cells with 3x the capacity. And offered an AA tray that
took 6 instead of 4 cells, so the AA tray would provide full power. Nope,
they didn't do that either.
4) They [should have] just make the radio fit in the hand, make it slimmer,
and hang the batteries at the bottom of it,
5) The duty cycle is something like 25%. If you use the radio as half of a
conversation, you need 50%. Since the heat sink for the finals is the
metal plate UNDER the battery pack... it can't shed heat and the radio
rapidly overheats during TX. Moving the battery pack below the radio would
allow all the other issues to be solved.
6) So, APRS aside...the D7 is a lousy design from the start, and needs
replacing. \
7) The display is also decade-old LCD technology, even in daylight the
contrast stinks. I couldn't give away a cell phone with a display like that
today, and the LED backlights are terribly spotty, they don't illuminate it
well either.
8) The radio is designed for broad multi-band use, so the antenna is ships
with is functional from 113MHz-175(?)MHz, and something like 420-479 on the
UHF side.... WHich also makes the antenna about 6db WORSE in the primary 2m
FM band...
Meantime, it is still the only way to track an APRS device with one
handheld device. And that's the reason I bought it, sight unseen,
regardless of other issues. There's nothing else that does the job the same
way, regardless of how much better the radio can be. So I give Kenwood
credit for building it--and encourage them to give me a better reason to
replace it.
While they're at it...<G>...they could update the CPU and make it flash
programmable.<G> For APRS3.0.<G>
Further he went on:
Bob, my D7 is the only handheld that implements APRS in any way, so I'm
glad it is out there. If I needed to buy ten more today, I'd order ten more
of them. Fortunately or not, I'm one of those guys who is always wondering
how things work, and how the things I'm working with can be made better. So
when I say I see shortcomings or flaws in something, that doesn't mean I'm
attacking it, just that I think it can be improved.
END QUOTE.
So although he threw a lot of gasoline onto the fire concerning the APRS
Specification and Protocol, I was relieved to find that he was not talking
about those issues at all. Just that the radio is too big, and clumsy...
etc, etc...
I think we all agree. But still its the only one that has APRS and we
bought it for that. and that alone.
de WB4APR.
----------------------------------------------------------------------
Subject: More Positionless Weather!!!!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 23 Apr 2004 20:26:14 -0400
X-Message-Number: 52
>>>"Daron J. Wilson" <daron@wilson.org> 4/23/04 7:02:08 PM >>>
>As much as I like the WXTrak, we found that it wasn't
>quite that seamless. Currently it does not transmit the
>position and weather data in the same packet, ...
Oh no! Not more positionless weather data. Gosh can we never get away
from that abomination! ARGH!!! I am truely saddend to hear this...
LET ME SAY WHY: APRS is a real-time system. It assumes that ALL packets
contain COMPLETE data. This is because the network cannot be relied on to
deliver all packets all the . So when you do get a valid packet, YOU WANT
IT TO CONTAIN everything you need to udnerstand it!!!!!
Positionless Weather is an abomination. Sure it works fine in fixed
networks to people monitoring 24 hours a day. BUT THAT IS NOT
APRS!!!!!!!!!!!!!!!!! APRS is supposed to deliver to ANYONE who just turns
on a radio, everything he needs immediately within one net-cycle time
(about 10 minutes for all local data and 30 minutes for regional data.
THIS SHOULD BE TRUE if he is just visiting or if he has lived there all his
life. As a MOBILE APRS system, I am actually more concerned for the
MOBILES that drive through or visit the area to get good WX data in just
one packet, without having to MONITOR for an HOUR to find out where the WX
reported IS...
Oh I ache......
And for a WX station that only sends its position once an hour you have a
good chance of missing that one packet, so now you have to wait 2 HOURS
before the WX data that you got only 5 minutes after arriving has any
value...
Please, please tell me that you are joking and that this new device did not
make the mistake of designing to positionless weather!!! What an
abomination!
>In the mean time we are plotting a pic based solution
>that takes weather data from any number of devices and
>converts it into the correct format to be forced in to the
>KPC3+ digipeater so that the transmission comes
>out compliant. It's a fair amount of work based on many different
>weather stations, but a worthwhile goal.
I LOVE IT, I LOVE IT, I LOVE IT. Please promise me it will include the
position in EVERY packet so that EVERY packet has value the INSTANT it is
received!!!!! to anyone at any time....
de WB4APR
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
