| |
ZL3AI > APRDIG 11.06.04 10:05l 404 Lines 16803 Bytes #999 (0) @ WW
BID : 3427-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 05, 3/8
Path: DB0FHN<DB0RGB<DB0MRW<OK0PPL<DB0RES<ON0AR<LU6DTS<W4JAX<VK4TUB<ZL2BAU<
ZL2BAU<ZL3VML
Sent: 040611/0700Z @:ZL3VML.#80.NZL.OC #:25628 [Chch-NZ] FBB7.00i $:3427-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: WinAPRS/TNC-X Questions
From: Robbie - WA9INF <mwrobertson@comcast.net>
Date: Sat, 05 Jun 2004 08:15:53 -0500
X-Message-Number: 41
My first thought would be to look at Settings/TNC and check that you
have it configured properly, such as, make sure there is not a tick for
Receive Only...
Good luck,
Robbie
Rick Stoneking wrote:
>All,
>
>I am trying to get a portable APRS station running using a Libretto 30 PC
>(Win95), TNC-X, and an HT. I am trying to use WinAPRS 2.7.5. On the
>receive side all is well - stations are showing up on the map just fine. On
>the transmit side the packets are not being 'received' by my home station
>TNC. I am using Hyperterm to simply monitor the output from my MFJ-1270C
>TNC and I see all of the other APRS traffic. I downloaded the TNC-X TX Test
>program and it works fine. The test packets show up on my Hyperterm screen
>no problem. So I must have something messed up in my WinAPRS setup but I
>can not figure out what. Does anyone who has used WinAPRS in KISS mode have
>any suggestions?
>
>Thanks,
>Rick
>W2RDS
----------------------------------------------------------------------
Subject: Re: Too many personalities
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sat, 05 Jun 2004 09:17:37 -0400
X-Message-Number: 42
>>>Wes Johnston <wes@johnston.net> 06/04/04 10:07 PM >>>
>Bob, I can remember...
>It's time to stop shoe horning more and more into the
>comment field.
Its not shoehorning. Adding any kind of new information was always
intended to go there so that ANYONE could add ANYTHING they wanted to
APRS...
>Presently, the comment field has to use contextual
>clues to decode a packet.
1) No it doesnt. Its HUMAN READABLE
2) But there are 37 characters there for anyone to use for anything
3) Both Scott and I can do a lot in 37 free bytes!
4) There is nothing at all that prohibits flagged fields in there
5) Though, I would suggest putting any human readable text
in the first 20 bytes to that all kenwood readers can see it.
6) And doing this makes anything fully 100% backwards
compatible with ALL previous and existing code...
>Open trac also strives to not use any ax25 tricks...
>because it is intended to be easily transported over
>TCP/IP or ax25, or the Next Big Thing.
Oh, like Email? I hope you noticed how impossible it was for Scott to put
his 66 byte OPENtrack version of his packet into email? It took what, 20
lines to convey it, where as the APRS version is printable ASCII and fit on
half a line.
>I will define what aprs is... It is a real time, tactical
>asset tracking system which uses unconnected frames and
>redundancy to convey information. Open trac is the same...
You are wrong on several key points:
1) it is a distributed network intended to update EVERY participant in the
net to the CURRENT real-time tactical info. Thus it assumes everyone on the
net has implemented the APRS protocol and that EVERYONE is privy to the
SAME and to ALL information transmitted. When someone transmits the data
in a real event, he has to ASSUME that everyone had a reasonable chance of
getting it.
2) Thus, it assumes an on-air STANDARD and that a sender has resaonable
expectations that everyone participating in the net got it.
3) It has flexibility so that new stuff can be added without obsoleting
existing code, and so that the new info can still get to existing users
without upgrades.
4) APRS is NOT juat an AVLS system tracking moving GPS stations. It is a
tactical real-time-digital-communications system to serve real-time DIGITAL
communications needs to augment communications at local real-time events.
This is CLEARLY worded in the SPEC.
5) OPENtrack is not in keeping with #1 and #2 and #3.
>To say that APRS always sends packets with F0, but
>that doesn't mean it has to only RX 0xF0 packets is crazy.
Yep, thats exactly the point. What a TNC receives is beyond the control of
APRS, and that is why we told scott from the beginning that using a PID as
a discriminant on the existing APRS channel with all the thousands of
existing TNC's out there is not a good idea..
>And those of us who think these packets don't belong on
>APRS... if a packet can't be decoded by every client, does
>that mean it does not belong on APRS?
No, but if it is on APRS, it should be at least HUMAN READABLE to some
degree so that the ORIGINAL OBJECTIVES of APRS as a come-as-you-are
human-to-human communicatiosn system are met, and that is that ANYONE can
come on APRS and send tactical real-time information to all NET
participants and have a reasonable assurance that the MEANING got
through.. and with whatever they brought to the event.
APRS planned from the beginning so that it was extensible but at no time
would it intentionally abandon existing users. HAM radio is an evolving
thing. A successful communicatiosn system and STANDARD must always allow
for smooth transition and recognize that it owes all existing users the
ability to get the message.
>Just as the APRS spec has evolved to include new
>methods..., so can it take in and include opentrac when
>OT is mature and settled enough to have worked out all or
>most of the kinks.
Sure,
1) APRS has always strived to introduce new things in a way that was
backward compatible with existing users.
2) Nothing I have yet seen in OPENtrack cannot be done already within
existing APRS protocols.
3) the few new-concepts are easy to add to the custom user mechansm.
>I say again: There is no reason APRS SPEC cannnone of them need to be processed by end users.
>>Again, it's not in any way obfuscated. I like to think the
>>[OPENtrack] protocol is fairly clearly laid out.
No quibble there. It has the advantage of 20/20 hindsight. But why is it
"needed"? What does it do that APRS does not do, or cannot add in a
backward compatible manner, or that cannot use a user format for?
>>Typical Mid-E (and kenwood) packet:
>>K4HG>SN0YX2:'abcdef/>
>
>Next, that's hardly an average APRS packet. When I look
>at my console, I see NMEA and regular uncompressed
>format. I see only one guy running Mic-E without an absurd
>comment string.
I dont know where you live, but here, 90+% of all mobiles are running the
very effficinet APRS Mic-E protocol.
>I see only one guy running Mic-E without an absurd
>comment string. That's an 11-byte payload.
Yep, and if the guy wants to include those 11-Bytes that says "enroute to
Alabama", that is HIS choice. It is not the fault of APRS. The COMENT
field is optional by the SENDER and we even designed it so that it could be
sent every other, every 3rd or even every 5th packet, or none at all.
>10 bytes in OpenTRAC gets you position to 1 centimeter,
>with no data in the AX.25 header. Altitude adds 3 bytes...
So? APRS Mic-E does it in 9 and only adds 4 bytes for altitude? And the
AX.25 header wastes 7 bytes in the too field so why not use them?
I ask again? SO WHY DO WE NEED OPENTRAK?
>Yes, it's possible to construct smaller APRS packets.
>tocol, then I suggest ways for you place it in the user-defined
formats. If its a stupid idea or one that has been TOTALLY thrashed about
before, I tell you that also.
Sorry you have to read so much to keep informed. But it is keeping informed
that is the key to keeping us from having to go through all the same half
baked ideas over and over again that simply wont work, or are just ego
trips to do the same thing a different way ....
In the same context, I love new ideas for APRS... Keep them comming and I
promise I will address each of them fairly in the same manner I address
everyone elses. Though I do appologize for when I get beat down after 200
identical emails from the same 2 people...
I'm only human, and don't have infinite time...
Enjoy,
Bob, Wb4APR
----------------------------------------------------------------------
Subject: Re: Too many personalities
From: Wes Johnston <wes@johnston.net>
Date: Sat, 05 Jun 2004 10:46:03 -0400
X-Message-Number: 47
Comments below....
At 09:17 AM 6/5/2004, Robert Bruninga wrote:
>Its not shoehorning. Adding any kind of new information was
>always intended to go there so that ANYONE could add
>ANYTHING they wanted to APRS...
If tieing a location system into a transportation layer (mic-e and ax.25
WRT "tocall") isn't shoe horning, I dunno what is.
>1) No it doesnt. Its HUMAN READABLE
Human readable packets went out the window with the peet bro's WX station
and MIC-e packets. If I can't read 100% of the packets by hand, then I
must have a computer to interpret them for me, and I may as well use the
computer to decode all of them since it's running. Also, packet, unlike CW
is not human readable. Guess what? I have no freaking idea where my
Kenwood radio is by looking at the packet it sent.. but I can read the
comment at the end, so at least part of it is human readable. OT will be
the same way... you will have no idea the location but you will be able to
read the comments in the packet. And a trained eye (just as in APRS) will
be able to "see" things like status and icons... just as we have memorized
that - is a house and # is a digipeater.
>2) But there are 37 characters there for anyone to use for anything
>3) Both Scott and I can do a lot in 37 free bytes!
RE: context clues in the comment field... it is a free for all in there.. a
mix match of comments, plain text status, altitude, voltage and what not
which is so convoluted that it is not machine interpretable. Only the
human mind can make sense of the comment field in every case.
>Oh, like Email? I hope you noticed how impossible it was
>for Scott to put his 66 byte OPENtrack version of his packet
>into email? It took what, 20 lines to convey it, where as
>the APRS version is printable ASCII and fit on half a line.
In so far as transporting a packet in email, the binary packet scott send
to this sig was expanded hex with the output decoded in plain text... this
is similar to the phrase a picture is worth 1000 words. It could have been
sent in email as a 56 byte attachment.
>You are wrong on several key points:
>
>1) it is a distributed network intended to update EVERY
>participant in the net to the CURRENT real-time tactical info.
All i was trying to do was point out the similarities in APRS and OT. Grill
me.
>Thus it assumes everyone on the net has implemented the
>APRS protocol and that EVERYONE is privy to the SAME
>and to ALL information transmitted. When someone transmits
>the data in a real event, he has to ASSUME that everyone
>had a reasonable chance of getting it.
>
>2) Thus, it assumes an on-air STANDARD and that a sender
>has resaonable expectations that everyone participating in the
>net got it.
You also make the valid point that new protocols should not obsolete the
old ones... very true... and OT does not... let's see... If I wrote a
parser for a KISS tnc, it would first check the PID byte. If I wrote a
parser for a converse mode TNC it would look for the TOCALL <> OPNTRK and
decode as a normal APRS packet. Or I could "flip a switch" in my TNC and
be completely oblivious to OT packets... just as the users of BBS
frequencies were oblivious to the net/rom routing tables.
>3) It has flexibility so that new stuff can be added without
>obsoleting existing code, and so that the new info can
>still get to existing users without upgrades.
That's insane... if this were true, there would have only been one release
of APRS DOS. All the features present today would have been available in
one download in 1994. In as far as standards go... OT is only decodable by
XASTIR today. But how long did compressed packets (was it called CST? I
can't remember) exist before adoption by all aprs clients? You yourself
have come up with new ideas which took some time to implement or never did
get implemented. But most were adopted and we call them a standard
_now_. OT has not seen widespread adoption _yet_.
>4) APRS is NOT juat an AVLS system tracking moving GPS
>stations. It is a tactical real-time-digital-communications
>system to serve real-time DIGITAL communications needs
>to augment communications at local real-time events. This
>is CLEARLY worded in the SPEC.
And this is the very reason we need things like CM precision for altitude
even though GPS receivers can't provide it. If I want to place an object
on a map by hand, I dont want to see it jump 60feet... Heck , the fire
truck could go to the house on the other side of the street if the object I
had created jumped 60 feet.
>5) OPENtrack is not in keeping with #1 and #2 and #3.
Only because it is only supported in XASTIR today.
>>To say that APRS always sends packets with F0, but
>>that doesn't mean it has to only RX 0xF0 packets is crazy.
>
>Yep, thats exactly the point. What a TNC receives is
>beyond the control of APRS, and that is why we told
>scott from the beginning that using a PID as a discriminant
>on the existing APRS channel with all the thousands of
>existing TNC's out there is not a good idea..
Come on.. it's a simple software setting just like CD INTERNAL or MON ON.
>APRS planned from the beginning so that it was extensible
>but at no time would it intentionally abandon existing
>users. HAM radio is an evolving thing. A successful
>communicatiosn system and STANDARD must always
This is the real problem... the double edged sword... Kenwood bought into
APRS and sells a very popular radio (and I really love mine). But at the
same time, they did not release their source code nor provide a dev kit, so
we are stuck. APRS will and cannot evolve until the last of these radios
quit working or Kenwood releases a new firmware. What some of us will do
is make a hamhud like devices
David
----------------------------------------------------------------------
Subject: Re: updating databases over aprs?
From: Steve Dimse <k4hg@tapr.org>
Date: Sat, 5 Jun 2004 11:26:49 -0400
X-Message-Number: 50
On 6/5/04 at 4:03 PM David John Walsh <david.walsh@vodafone.net> sent:
>I am about to start to build a database that will need to have multiple
>clients attached to the server (for a Scout hike, over amateur radio).
>It is my intention to use APRS as the backbone structure, as its layer 2
>structure is perfect for the geographical size of the event.
>
>I guess my first question is simply "is there a protocol document for
>APRS, and if so where? Whats the latest version etc"
Yes, it is on tapr.org, and there is an errata page at aprs.org
>My second question is how would you go about it, has anything been done
>like this before
You can do this completely within the spec. You simply create a user defined
packet, which looks like:
K4HG>APRS:}xy(your data here)
where xy are two characters that identify the type of packet, these are
largely self-defined, just look in the errata page for ones not taken (very
few are) and pick an unused one. Once you have defined your format, provide
it to Bob so it can be added to the errata page.
Using this method, you can send any sort of data you like, and have the
database connect to the APRS IS just as findU does. Or, you could use findU
to collect the packets for you, using the raw.cgi to grab the raw data for
the callsigns that are sending it.
findU puts user defined packets into a table, fairly high on my do-list are
the query cgis for this, if you have a need I can prioritize them, so you
could get all the userdefined packets of a single type over a certain time
frame with a single query.
I suspect APRSworld also parses them out, and with him you can get direct
access (I also offered it, but only on the backup server, which at this
point seems unlikely to come back online, the primary server is too
important to me to risk problems from slow querys).
----------------------------------------------------------------------
Subject: Re: commercial
From: Curt Mills <archer@eskimo.com>
Date: Fri, 4 Jun 2004 21:21:51 -0700 (PDT)
X-Message-Number: 51
On Wed, 2 Jun 2004, Kevin Deckert wrote:
>I am looking for info on APRS in the commercial realm, I have heard that
>kenwood and icom have some sort of commercial radios for APRS and some
>specializied software..anyone hear of such?
In the commercial realm, I think it is usually referred to as AVL,
for automatic vehicle location? Do a search on google for that and
you should get quite a few hits.
--
Curt, WE7U. archer at eskimo dot com
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!"
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
