OpenBCM V1.07b12 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   10.05.04 08:23l 238 Lines 9748 Bytes #999 (0) @ WW
BID : 3179-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 20, 8/17
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<7M3TJZ<JK1ZRW<WB0TAX<ZL2TZE<
      ZL3VML
Sent: 040510/0647Z @:ZL3VML.#80.NZL.OC #:23697 [Chch-NZ] FBB7.00i $:3179-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To  : APRDIG@WW

Subject: RE: APRS Kenwood Radios
From: "Daron J. Wilson" <daron@wilson.org>
Date: Tue, 20 Apr 2004 10:35:30 -0700
X-Message-Number: 35

>>Ever tried to send any kind of a text message using
>>the D-7 keypad or the D-700 mic??? 5 WPM MORSE
>>CODE IS FASTER!!!!

I for one am very glad for this.  When bandwidth is limited, using the
positioning setup to fire worthless messages back and forth frustrates me.
It should be usable, but if it had a keyboard on there, some of these LIDS
would be typing paragraphs back and forth while the rest of us were trying
to see weather and issue position reports.  It is almost a perfect mix,
functional for what the channel will bear, IMHO.

5WPM code..yeah, that would be great, but hey lots of the new hams can't
copy code, remember it was outdated and all.  Not my opinion, but wasn't my
decision either.

>>Let's do something to make APRS virtually indispensable
>>to EVERY ham. Something that every ham will HAVE to
>>have as a part of a complete station. Right now we're
>>about as exciting as sitting around and watching the grass
>>grow!

Personally I favor APRS over watching the grass grow, and one reason is for
our area we doing a fair amount with weather.  There is so much more than
can be done, and as I learn more I'll try to do it.  What won't make
progress is sitting on your thumb and demanding that the radio
manufacturers figure out (for you) what you should have and present it to
you.  At which time you will likely complain that it is not what you
wanted, and it costs too much.

>Yes!  So get busy.  Define and write application software to
>send to the mobile user the kind of info you would like
>to see.  You can format it for quick head's up display
>on the radio, or for more elaboirate display on the mobile
>laptop...

We're working locally to do better on weather first.  First step was to
integrate things so that our mountain top weather stations output in a
format that the kenwood users can see on the screen.  We did one last week
and it looks like it will work well, now we'll tackle the rest of the
nodes.  After that we'll pick another area of concern and address it.

I'm not a kenwood user or owner, I don't particularly like the limitations
on beacon rate (no smart beaconing) and the 'all in one box designed by
someone else' approach.  I enjoy my HamHud, it's more hands on building and
programming, which is what amateur radio is really about (not just buying
and appliance and complaining about how it works).  If someone comes out
with a new wizbang radio/TNC, I hope they consider good hardware, and
upgradeable (customizable) firmware.  I'd enjoy a video display that
allowed me to upload maps to the screen, and choices of firmware that were
open enough to move on with new things.  

73 N7HQR

----------------------------------------------------------------------

Subject: Re: APRS version2.0 spec, was Re: APRS greater precision
From: "Curt, WE7U" <archer@eskimo.com>
Date: Tue, 20 Apr 2004 10:39:54 -0700 (PDT)
X-Message-Number: 36

On Mon, 19 Apr 2004, Jeff King wrote:

>Since you admit to the above, it makes sense to drop it from the spec. Replace
>it with OpenTrack for that subsection. It gives the compression as well as the
>precision here. We certainly would be no worse off then with the compressed
>format in the spec, and since it is easier to implement, we could end up ahead
>with a larger buy in, in particular with the embedded trackers.

If we added a new chapter to the spec that used just the OpenTrac binary
posits, I'd be ecstatic!  The posits would be very short and resolution
would be high enough for my needs now and in the forseeable future.

I'll use OpenTrac protocol for the times I need more facilities which that
protocol provides.

--
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: Re: APRS Kenwood Radios
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 20 Apr 2004 10:41:50 -0700
X-Message-Number: 37

>How about making it possible for end users to install new firmware, or
even (gasp) open source?

I wasn't even going to say it, for fear of a flame war.  =]

Even without user-upgradeable firmware, if we at least had a more capable
TNC, radio control protocol, and the ability to take over the display and
keypad, we could do a LOT externally.

Scott
N1VG

----------------------------------------------------------------------

Subject: Re: APRS greater precision
From: "Laurie - g6isy" <g6isy@dsl.pipex.com>
Date: Tue, 20 Apr 2004 18:43:13 +0100
X-Message-Number: 38

Curt, WE7U wrote:
>
>The spec says that WGS84 is to be used in all cases.  Has that
>changed?

The spec actually says that the *default* datum is WGS84. Which I believe
is subtly different to saying WGS84 is to be used in all cases. Here in the
UK many of us have good reasons for using a datum that is not WGS84. This
is due to the fact that there has been virtually no mapping data available
to WGS84 (its nearly all OSGB36). I feel the addition of a datum identifier
would be a great help as we will (I think) go through a long transition
period where different users will be using different datums depending on
their source mapping data as WGS84 mapping slowly becomes available. As an
example, all paper maps from our mapping agency (Ordnance Survey) are to
OSGB36 for land areas but coastal charts are a mixture of OSGB36 and WGS84
(my local area's coastal chart has just been revised and re-issued using
WGS84. In an SAR scenario we therefore need to use OSGB36 while on the land
but WGS84 on the water to be able to accurately plot a position on the
relevant maps.

73 Laurie - G6ISY

----------------------------------------------------------------------

Subject: Re: APRS Kenwood Radios
From: David VanHorn <dvanhorn@cedar.net>
Date: Tue, 20 Apr 2004 12:46:25 -0500
X-Message-Number: 39

At 10:41 AM 4/20/2004 -0700, Scott Miller wrote:

>>How about making it possible for end users to install new firmware, or
>even (gasp) open source?
>
>I wasn't even going to say it, for fear of a flame war.  =]
>
>Even without user-upgradeable firmware, if we at least had a more capable
>TNC, radio control protocol, and the ability to take over the display and
>keypad, we could do a LOT externally.

Yes. 

Unfortunately, they didn't design either radio with this in mind, so I'd
guess we're stuck.

I've been designing user-upgradeable software into products since '83. 

----------------------------------------------------------------------

Subject: Re: APRS greater precision
From: "Curt, WE7U" <archer@eskimo.com>
Date: Tue, 20 Apr 2004 10:54:08 -0700 (PDT)
X-Message-Number: 40

On Mon, 19 Apr 2004, Robert Bruninga wrote:

>>>>"Scott Miller" <scott@opentrac.org> 4/19/04 4:36:03 PM >>>
>>So we're talking about another four or five bytes,
>>and more obfuscation of the spec and the parsers
>>that have to implement it, for how much of a gain in precision?
>
>To the nearest foot and a half or so.  I would think that
>that resolution is good enough for SAR unless they are
>looking for lost jewelry...

It's funny, most people think we're out there looking for the lost
subjects...  In reality we're supposed to be looking for clues to the lost
subjects, as those are more plentiful.  Marking where the clues and other
objects of interest are on the map is important, as you can do statistics
based on lost subject behavior, and you can see trends in the clues. That's
why we need higher resolution than DDMM.MM provides for SAR.

>Yes, and if I had it to do all over again, that would be a
>good approach.  I just worry about obsoleting 10,000
>users of the ONLY mobile radio that does display APRS
>for a few bytes of advantage and precision to 1cm that
>is not of much value to the mobile or SAR operator...

It will be a temporary setback.  Ten or twenty years down the road, people
will thank you for making the change.  I know you can handle the criticism
until then, as you've done well at it for all this time so far.

>You have borught great creativity to APRS, and I do
>truely appreciate that.    I sure wish you had been around
>earlier, because then we would be  further ahead now...

I see no reason not to advance the state of the art, no matter when the
ideas are presented.  If they're good ideas, they should get implemented.

--
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: Re: APRS Kenwood Radios
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 20 Apr 2004 10:54:37 -0700
X-Message-Number: 41

>Unfortunately, they didn't design either radio with this in mind, so I'd
guess we're stuck.
>
>I've been designing user-upgradeable software into products since '83.

Yeah, it's really not that hard to do.  Even if it involves swapping out
chips, at least the end user has an option.  People are so used to doing
that with the KPC-3+'s and TinyTraks I have to keep explaining that there's
no need to remove the chip in the OpenTracker, that you don't need a
programmer, and that all of the upgrade functions are done from the config
program.

Scott
N1VG

----------------------------------------------------------------------




Read previous mail | Read next mail


 26.11.2025 04:28:23lGo back Go up