| |
ZL3AI > APRDIG 12.05.04 10:27l 410 Lines 16287 Bytes #999 (0) @ WW
BID : 3224-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 23, 7/10
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040512/0740Z @:ZL3VML.#80.NZL.OC #:23803 [Chch-NZ] FBB7.00i $:3224-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: Everlasting discussions, Smart Move/Transition?
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 23 Apr 2004 14:43:08 -0700
X-Message-Number: 42
>>>>"Scott Miller" <scott@3xf.com> 4/23/04 12:57:30 PM >>>
>>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?
That wasn't me, but I agree with the statement...
>There is only one WX format in the APRS spec as far as I am
>concerned. The COMPLETE report. Yes, the spec had to
>allow for the unique WinAPRS positionless weather, but
>that was one of those compromises to get WinAPRS to sign.
Perhaps you can release a 'real' spec, then? I suppose we'd lose base-91,
but at least we'd have a simpler spec to implement.
>people finally converging on the ONE COMPLETE format,
>you want to still add another one for Opentrac? Sounds like
>forked tongue...
I've explained my motivations for creating a new protocol. If you still
don't get it, that's fine, but I'm not going to debate the issue further.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Additional thoughts on the
great debate....<LYR36507-195826-2004.04.22-12.06.35--m
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 23 Apr 2004 17:44:02 -0400
X-Message-Number: 43
>>>"Curt, WE7U" <archer@eskimo.com>>>>
>More money spent does not equal better equipped.
>Xastir is teaching people that, as is TinyTrak,
>PocketTraker, OpenTracker...
Those are all send-only trackers. None of them are two-way APRS capable
and none of them can display data back to their users... Excellent
trackers for sure, but they make no comparison to the Kenwood D7.
>Besides, I'm not purposefully excluding Kenwoods,
>I'm excluding Kenwoods at their current firmware level.
>I'm hoping that will change in the future.
Such blind hope is surely a poor way to design a system for use today by
volunteers that have no other choice... (no other choice for a handheld
all-in-one-do-it-all-APRS radio that is)...
Just go build your exclusive-no-existing-kenwood system, I'm tired of
hearing about it. When you have 4600 people using your system, come back
and tell me all about it... Then I am sure others will flock to your door..
Bob
----------------------------------------------------------------------
Subject: Re: Gaps in gated weather data
From: Steve Dimse <k4hg@tapr.org>
Date: Fri, 23 Apr 2004 17:47:15 -0400
X-Message-Number: 44
On 4/23/04 at 2:02 PM Scott Miller <scott@opentrac.org> sent:
>>Not true, you can get it with
>
>I figured there had to be a way. What's the difference between raw.cgi and
>rawwx.cgi?
rawwx is only the weather packets, raw is all the packets, though for this
station, there are only weather packets, so the two return the same
packets, but look at "K4HG" to see the different.
>That's my guess as well. Unfortunately it's a bit of a drive to this
>particular mountaintop and the owner probably won't have a chance to fix it
>for a bit.
Not a big deal, someone could just send an object for the station and it
will appear on maps, or set up a local becaon that give the -1 call and its
position.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Compromise proposal (was: Re: The APRS-WG and spec improvements.)
From: "Curt, WE7U" <archer@eskimo.com>
Date: Fri, 23 Apr 2004 15:18:40 -0700 (PDT)
X-Message-Number: 45
On Fri, 23 Apr 2004, Henk de Groot wrote:
>At 09:58 22-4-2004 -0700, Curt, WE7U wrote:
>>I have no problem with the datum thing, although I'd rather see
>>WGS84 used across the air in all cases. I'll go with the
>
>Maybe we can have a nice compromise here: Allow ASCII APRS posits and MIC-E
>to be in the predominat datum that is current for some country. Make WGS84
>mandatory for the high precision base-91 format. That way you only make the
>datum mandatory in conjuction with a format with a high precision and leave
>is open for the "recreational" formats where a high precision is less
>important.
>
>So if you want high precision in a defined datum use base-91, in all other
>cases use one of the other less accurate formats and live with the
>inacuracy of not knowing the datum.
>
>Does that sound like something we can live with and still keep the
>compatiblity?
It seems a reasonable idea to me. Here are some relevant facts regarding
compatibility:
Positive:
---------
*) Most APRS clients decode Base-91 compressed posits.
*) Kenwoods decode Base-91 compressed posits.
*) Kenwoods decode non-compressed Objects.
*) Kenwoods decode non-compressed Items. True?
Negative:
---------
*) Kenwoods cannot decode Base-91 compressed Objects.
*) Kenwoods cannot decode Base-91 compressed Items. True?
*) Most APRS clients don't handle Base-91 compressed Objects/Items.
*) Most APRS clients don't handle non-compressed Items.
*) Most APRS clients don't handle mixed-case Object/Item names
properly (per spec).
Ok, so I threw Items and Mixed-case Object/Item names into the discussion
too. They're all important when dealing with Objects.
My position is that most of the APRS clients already support Base-91
compressed posits, but not Objects. These programs are relatively easy to
change compared to the Kenwood, so they should be tweaked to add that
functionality. They already have the Base-91 code, so just apply it to
Objects as well.
While we're in there, implement:
--------------------------------
Items, which are very similar to Objects anyway.
Compressed Items.
Mixed-case Object/Item names, keeping different cases as different
Objects/Items.
All of these implementations would be per the ratified APRS spec that we
have had for years.
I could certainly live with the modifications you proposed above. It
appears that Bob doesn't want compressed Objects/Items used, as the
Kenwoods 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), so most users won't notice an occasional '?' on their screen.
We aren't planning to use Kenwoods for our SAR purposes. We are planning
to use lots of Base-91 compressed objects/items.
--
Curt, WE7U archer at eskimo dot com
Arlington, WA, USA http://www.eskimo.com/~archer
"Lotto: A tax on people who are bad at math." -- unknown
"Windows: Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: Compromise proposal (was: Re: The APRS-WG and spec improvements.)
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 23 Apr 2004 18:30:43 -0400
X-Message-Number: 46
>>>Henk de Groot <henk.de.groot@hetnet.nl> 4/23/04 3:40:33 PM >>>
>
>Maybe we can have a nice compromise here:
>Allow ASCII APRS posits and MIC-E to be in the predominat
>datum that is current for some country. Make WGS84
>mandatory for the high precision base-91 format.
If that were the case, then there is no need for a DATUM signifier byte and
it becomes !YZ! format. But I thought everyone wanted the datum. So I's
rather stick with the !XYZ! format.
By the way, from here on, I will refer to it as the !DAO! format which is
more discriptive where D is DATUM, A is LAtitude and O is LOngitude...
Bob
----------------------------------------------------------------------
Subject: Re: Additional thoughts on the great
debate....<LYR36507-195826-2004.04.22-12.06.35--m
From: "Curt, WE7U" <archer@eskimo.com>
Date: Fri, 23 Apr 2004 15:42:22 -0700 (PDT)
X-Message-Number: 47
On Fri, 23 Apr 2004, Robert Bruninga wrote:
>>>>"Curt, WE7U" <archer@eskimo.com>>>>
>>More money spent does not equal better equipped.
>>Xastir is teaching people that, as is TinyTrak,
>>PocketTraker, OpenTracker...
>
>Those are all send-only trackers. None of them are two-
>way APRS capable and none of them can display data
>back to their users... Excellent trackers for sure, but they
> make no comparison to the Kenwood D7.
Because we don't need/want a D7A. It's something much more expensivc 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
creditorg> 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
| |
