OpenBCM V1.07b12 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   08.05.04 23:06l 290 Lines 12275 Bytes #999 (0) @ WW
BID : 3194-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 19, 4/5
Path: DB0FHN<DB0RGB<DB0MRW<DB0WUE<DK0WUE<HA3PG<JK1ZRW<7M3TJZ<ZL2BAU<ZL2BAU<
      ZL3VML
Sent: 040508/1921Z @:ZL3VML.#80.NZL.OC #:23606 [Chch-NZ] FBB7.00i $:3194-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To  : APRDIG@WW

Subject: Re: Icom mobile APRS van thing???
From: Wes Johnston <wes@johnston.net>
Date: Mon, 19 Apr 2004 18:59:29 -0400
X-Message-Number: 23

Yep... I had to re-program their TNC at the Shelby NC hamfest.... someone 
had screwed with it and the drivers of the van didn't know enough to make 
the GPS / TNC work again.

Has anyone seen the ad for their 2800 2m rig... the one that (appearantly) 
does AMBRE digital speech and has enough bandwidth leftover to TX GPS data 
in real time while the mic is keyed?

Wes

At 07:19 PM 4/19/2004, you wrote:

>    Anybody remember what that Icom mobile van was called a few years
>ago?  The one that toured the country giving out door prizes and stuff...
>
>    Thanks,
>    Earl
>
>Earl Needham, KD5XB, Clovis, New Mexico  DM84jk
>SETI@Home:  11461WU/7.43yrs
>http://www.findu.com/cgi-bin/find.cgi?call=kd5xb-2

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

Subject: Re: APRS greater precision
From: "Spider" <spider@rivcom.net>
Date: Mon, 19 Apr 2004 16:02:43 -0700
X-Message-Number: 24

----- Original Message -----
From: "Robert Bruninga" <bruninga@usna.edu>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Monday, April 19, 2004 2:53 PM
Subject: [aprssig] Re: APRS greater 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...

If we could get that resolution, I would not know what to do with myself!
I dont think my GPS units are that capable but whatever they are capable
of, I want that!  APRS should not hinder that....and it doesnt....if we
could be 'forward' compatible and use what is in the spec without
disrupting the world!

Jim
WA6OFT

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

Subject: Re: APRS greater precision
From: Gerry Creager N5JXS <gerry.creager@tamu.edu>
Date: Mon, 19 Apr 2004 18:04:04 -0500
X-Message-Number: 25

You might want to remind your SAR team that, as the DRGs and quad sheets 
are updated, they will be referenced to NAD83, *NOT* NAD27.  They're gonna
have to convert.  USGS is pretty adamant about this.

The correct answer is, really for folks who are using their GPS receivers
for APRS, and most other activities, to set it to the WGS84 datum and only
set to something else when they're specifically seeking to use it with maps
or applications specifially tied to another datum.

There are good reasons for this.  We can talk about the US-centric 
solution:  NAD83 and WGS84 will never be more than 2m in disagreement in 
the CONUS.  We can also talk about the fact that DMA/NIMA/NGIA created and
tuned WGS84 to be as close an approximation to the real Earth as possible
for the vast majority of the surface of the planet.

Somehow, though, I don't think I'll convince some folks.

I'm working on a review of GPS-derived positions and their relative 
accuracy.  It's gonna take a few days, but it's coming to a SIG near you.

gerry

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

Subject: Re: APRS greater precision
From: "Spider" <spider@rivcom.net>
Date: Mon, 19 Apr 2004 16:10:40 -0700
X-Message-Number: 26

----- Original Message ----- 
From: "Scott Miller" <scott@opentrac.org>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Monday, April 19, 2004 3:12 PM
Subject: [aprssig] Re: APRS greater precision

>>>The easy solution is to do what we did in the OpenTRAC spec
>Ideally, everyone would run dedicated GPS receivers for their APRS needs,
>and leave them set to WGS84.  That's not likely to happen, though.  I've got
>to deal with the issue myself, since our SAR team uses NAD27 and any
>tracking solution I deploy in the near term is likely to use the team eTrex
>receivers, which also need to be used manually.

They use NAD27 now but with 'forward' thinking, the trend will be toward
NAD83 with newer maps. And WGS84 for electronic maps.  Our paper maps
currently are mixed...NAD27 and NAD83. On a search, it really does not
matter as everyone will be briefed and on the same page! I think in regards
to datum, we are in a transition period that will take many many years to
complete. Something we just have to understand and live with, I suppose.

Jim

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

Subject: Re: APRS greater precision
From: "Eric H. Christensen" <kf4otn@earthlink.net>
Date: Mon, 19 Apr 2004 19:10:14 -0400
X-Message-Number: 27

Well, Bob, then I should go and throw out my GPS and track myself when I'm
in my truck?  No!  Hey, I'm not staring at a computer screen to figure out
how to get somewhere without looking out for the pitfalls visually before I
get there.  I have no other choice than to accept the numbers coming out of
my GPS that is BLINDLY hooked to my D700 nor can I change the data once it
gets in that little black box...

So, I guess you don't want anything to do with APRS anymore?  It just hit me
that you said that you would support a system that "Users cannot just
manually insert it" and now you are telling me not to trust my GPS.  So, how
do I get the numbers onto the network?

Eric

-----Original Message-----
From: bounce-aprssig-36602@lists.tapr.org
[mailto:bounce-aprssig-36602@lists.tapr.org] On Behalf Of Robert Bruninga
Sent: Monday, April 19, 2004 09:40
To: TAPR APRS Special Interest Group
Subject: [aprssig] Re: APRS greater precision

This is exactly why I am concerned:

>If my GPS says it has me within 10 feet, then by golly don't
>show me somewhere else!  I know that my software
>might be a limitation, but that will only get better if the protocol is
>better!  If the protocol isn't better then why should the software?

This shows that people will -blindly- accept the numbers coming out of
their GPS device and act on it, becuse they have no clue as to the limits
of such accuracies.  That is why we have people that still run-aground, on
boats, because they think that because the GPS says I am "here" then they
must be "here" when in fact no two GPS's will even give the same answer,
much less the GPS and the chart, AND MUCH LESS that the ROCKS know where
they are supposed to be relative to either one of them.

Incorrect use of "precision" versus "accuracy" is one of the most
frustrating things to teach.   My kids just went through it in middle
school...  If the teacher asks, "The train is going at 20 MPH and it was
asked to slow to 1/3rd of its speed, how fast should it fo?" 

The correct answer is  6 MPH.  The wrong answer is 6.3333333 becasue it
shows that the student does not understand the limits of accuracy on the
original problem.

Written Numbers convey two things, not only the VALUE, but also and
indication of the DEGREE of precision to which they are known.  The
Calculator generation just never seems to get this....

Bob

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

Subject: Re: APRS greater precision
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 19 Apr 2004 20:16:45 -0400
X-Message-Number: 28

>>>"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? 

Well, in my opinion since they represent the most of APRS that we could
cram into a mobile and a portable radio, and actually fulfill exactly the
intent of APRS to put mobile data at the finger tips of the mobile and
portable operator, they help define the target of most of the data we want
to push to the end user.  There are 10's of thousands of them.

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.

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.

>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...

>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!

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...

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)...

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...

>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 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...

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...

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




Read previous mail | Read next mail


 26.11.2025 05:31:17lGo back Go up