| |
ZL3AI > APRDIG 12.06.04 21:18l 684 Lines 26747 Bytes #999 (0) @ WW
BID : 3437-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 06, 5/9
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040612/1900Z @:ZL3VML.#80.NZL.OC #:25698 [Chch-NZ] FBB7.00i $:3437-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: New APRS Digi-Object-Maintenance format
From: Greg Kulosa <greg@kulosa.org>
Date: Sun, 6 Jun 2004 12:51:10 -0700
X-Message-Number: 61
>OBJECTIVE: A format to signal to a digipeater or other
>specialized APRS station to take over reporting responsibility
>for a given object:
>
>FORMAT: Identical to existing OBJECT format
>TOCALL: OBJxyz
>Where: x = expiration time in hours from now
> y=periiodiciy in minutes
> z=tbd
> where x and y are base 36 (1-9,A-Z)
Hmm. That means that the longest delay between re-transmissions of this
object is 36 minutes? Most objects that I think of doing this with are
re-broadcast every 60 minutes or so. 36 minutes seems kind of short.
Also, the TOCALL of 'OBJxyz' is an altnet, isn't it? What TOCALL will the
Digi use to re-transmit the object? For some objects you might care, since
the TOCALL is used to set the icon (GPSxy, etc.)
I can imagine wanting to put special locations on the map for special
events:
- For the Baker to Vegas relay race, I can see having the Digi re-transmit
the locations of the starting line, finish line, and all the stages in
between.
- For a marathon or bike race, or walk-a-thon, I can see similar objects
being useful. Also the medical tent, volunteer check-in location, etc.
Yes, I know that some of this we can do with overlay files. But everyone
seems to want to use a different version of APRS software, and maintaining
overlays for all the different versions is daunting (Also, I use PalmAPRS,
and I don't think it even supports overlays).
If I am walking around with my Kenwood D7, and a GPS at one of these
events, then I can find where I am supposed to check-in to volunteer. (And
yes, the organizers could put out a Way-points file with these locations
too, but then you'd need one for Garmin, Magellan, etc.....)
>RESTRICTIONS: The packet must be heard DIRECT.
Yes, this makes sense. Although, I can also see the case when I might want
to request a specific Digi on the network to re-transmit my objects (The
central Digi that all others see in a given area, for example). That Digi
might not even be able to hear me direct, I might need a bounce from where
I am to talk to it.
>The restriction on the packet that it must be heard direct
>is to limit the damage that APRS spammers can inflict
>to only their own neighborhoods.
Also, if I transmit my request with WIDE2-2, and 4 Digi's hear it and then
start re-transmitting my objects, it will actually create MORE traffic than
if I just sent them myself.
I think that we need a way to request a specific Digi to re-transmit our
objects.
And in another reply Bob said:
------------------------------
>Ah, good point. I think we need to add the restriction also
>that the regurgitated object may ONLY be sent back out
>of the digi DIRECT too to keep it within the local area
>it serves.
I can see why you want to do this, but it won't work for every network.
You basically want the objects to travel the same number of hops that they
would if you had broadcast them yourself. The idea is to reduce the
hidden-transmitter problem of doing it yourself. The Digi has a better
idea of when the channel is really free.
In my example of Baker to Vegas, we need to use 3 Digi's to get a packet
from the start line to Netcontrol in Vegas. Ideally, the re-transmitted
objects would cover the same territory. If I was at the start line I would
want to see the same objects on PalmAPRS in my truck that NetControl sees
on their computer.
If the Digi hears the request direct, then it can re-transmit with the same
path that the original station used. Or, it could truncate it at 3 WIDE's
or something (configurable per Digi/Network).
I think we need a way to negotiate the TOCALL, the unproto path, and which
Digi to re-transmit these objects.
-Greg Kulosa
N1NSY
----------------------------------------------------------------------
[commercial content deleted]
----------------------------------------------------------------------
Subject: B2V path
From: "Cap Pennell" <cap@cruzio.com>
Date: Sun, 6 Jun 2004 13:34:19 -0700
X-Message-Number: 63
>In my example of Baker to Vegas, we need to use 3 Digi's to get a
>packet from the start line to Netcontrol in Vegas.
No, 2 digi hops is plenty for B2V rf _and_ inet purposes. WIDE2-2 alone
works fine there and most of the Western US (at least). Those users
routinely exceeding two digi hops (and/or transmitting too often) are not
the best role models for our VHF network, nor demonstrating the best amateur
practice.
Some may disagree, some aren't paying attention to their own stations, and
some don't care. The amazing thing is that it still works so well. FB!
73, Cap KE6AFE
----------------------------------------------------------------------
Subject: RE: OPENtrack for programmers, APRS for users
From: Jeff King <jeff@aerodata.net>
Date: Sun, 6 Jun 2004 16:47:49 -0400
X-Message-Number: 64
SOOOOO.......Steve
What protocol problems did you observe first hand on the RF side?
Did you implement the APRS-IS/FINDU fix James suggested on the list?
But while we wait to hear back from you, on to this amazing message you just
posted to the APRS-SIG:
On Sun, 6 Jun 2004 15:35:30 -0400, Steve Dimse wrote:
>>On 6/6/04 at 12:04 PM Scott Miller <scott@3xf.com> sent:
>Geez, that really....
Indeed!
Do you realize you set a new record for the SIG? The highest I/CM ratio yet
observed on the APRS-SIG (Insult to Coherent Message length). You where
smoken!!
Congratulations!
But on to the highpoints:
---->
>Geez, that really sums up the difference between the people that
>built APRS and you
....
>It neatly explains why you
>show no concern about the problems you could cause to APRS
>users...
....
>you do not care about benefiting the users, so why should
>you care about hurting them???!!!
....
>No wonder you do not care about harming the APRS system.
....
>Yes, a person's position is not important to you
....
>You seem to totally lack the ability to understand the wants
>and needs of others.
....
>Do you realize how much of yourself you have revealed?
....
>Do you consider improving the forcasting of weather
>unimportant?
....
>Probably not, you'd probably blame people for living in
>the path of a storm.
....
>It is a shame you choose not to
>focus your skills on serving others, it has its own rewards.
<-----
WOW, what an accomplishment there Steve. Too bad the archives for the SIG
aren't working anymore. This is indeed one for the record books.
And since we are on the subject, Scott did write me off list, and sent me
a picture of his BLACK HELICOPTER I didn't quite understand the bumper
sticker on it that said "ELVIS IS MY CO-PILOT" but he assured me it had
nothing to do with OpenTrak.
----------------------------------------------------------------------
Subject: Re: Sounds like Programmers Convenience to me....
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Sun, 06 Jun 2004 16:17:54 -0500
X-Message-Number: 65
>At ANY HAM radio event I have ever participated in,
>the MAJORITY of volunteers that actually show up
>bring the equipment they have, and dont have time to
>download and debug new code at each event. They
>just want an assigment and want to help.
>
>PLANNING on events by PLANNING on Downloading
>the lastest whiz-bang at the start time, is a recipe for
>communications failure.
>
>Sounds like APRS for programmers to me...
Based on what I see being discussed here and the use that I see occuring,
it seems that some people need a form of telemetry that is simple and easy
to use from a programmers perspective and from a HAMs perspective. Scott
has created a telemetry device and has made it capable of sending out APRS,
OpenTrac or both format protocols. This means that people can use it for
multiple purposes. If they want to use it for their needs, because it
works well, I think that is a good thing.
When you first created APRS, you were the only source. People could come
as they are, but might need to update their APRSDOS installation to get a
particular feature or bug-fix. Over the years, you have continued to fix
bugs and update your software, and some of this could have affected
particular missions had they occured during the time your software was
deficient in feature or operation.
When APRS first started appearing on the air, was it the only packet radio,
AX.25 protocol on the air? I believe it was not. There was TCP/IP and
other similar things being routed over the air. People could have set at
their TNCs with terminals and typed in text likhave more required options for TNC
configurations, but it is possible to fix this issue in the vast majority
of operating TNCs.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: APRS in the field. Big step forward...
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Sun, 06 Jun 2004 16:37:13 -0500
X-Message-Number: 67
>And this is Progress????
>
>Is this going to help HAM radio get out in the field
>and provide practical real-time digital communications
>support to local events and needs?
>
>I dont think so... Its just going to guarantee
>job security for programmers.... does nothing to help
>HAM radio in the field...
Again, I think you are assuming that the specific mission of OpenTrac is
identical to APRS. It isn't capable of that yet. The software packages,
as they become capable of doing OpenTrac can switch to KISS mode support
and then the PID will be the distinguishing factor for protocol parsing.
Only when that infrastructure is in place, will OpenTrac have such a large
following that the non OpenTrac compatible software and hardware will be at
a disadvantage.
These guys are doing the respectable thing of recognizing that its not time
to just turn this stuff up, and are instead, asking everyone to help make
sure that it does not impact applications that are incorrectly having to
see this data when they are not ready for it.
And, in particular, the Converse mode problem of carriage control is a big
issue, no matter what protocol ID and first data character OpenTrac packets
are transmitted with. If binary data is passed in converse mode, carriage
control is going to mess everything up for converse mode comms between the
TNC and the software.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: DX spots on APRS!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 17:41:13 -0400
X-Message-Number: 68
>>><wes@johnston.net> 6/5/04 12:54:39 PM >>>
>Bob's own APRS DOS tx'es DX Cluster type packets
>for satellite spots for the benefit of the kenwood
>users. It would seem that the ends justify the means.
>
>I will write Bob and ask him to cease transmitting DX
>Cluster packets on the APRS_only_ channel.
>Wes
Sorry wes,
The DX spots format IS part of the APRS spec... ALL APRS software is
supposed to decode them. Kenwood read the spec and included them in their
APRS radio without complaining... THey are also called the RESOURCE
format because they are so handy at putting LIST type information on the
front panels of the Kenwoods and for making LIST type data on other
clients, independent of the standard POSITION and STATUS lists.
APRS can do a lot. Like I say, some authors are only using about 10 % of
its potential... and so most users using those programs are not even aware
of what they are missing...
Bob, WB4APR
----------------------------------------------------------------------
Subject: help with oncore gps
From: "nick pugh" <quadpugh@bellsouth.net>
Date: Sun, 6 Jun 2004 16:53:07 -0500
X-Message-Number: 69
I purchased a Oncore gps and a Mckinney rs 232 to ttl board at Dayton. What
software do I need to make the unit out put data?
thanks in advance
nick k5qxj
----------------------------------------------------------------------
Subject: KISS mode is not always the answer !
From: Neil Johnson <njohnsn@njohnsn.com>
Date: Sun, 6 Jun 2004 17:01:44 -0500
X-Message-Number: 70
I can't run KISS mode. Why ?
Because out here in the sticks I'm the only digipeater for 50 miles. I'm
also the only Igate for 50 miles.
So I use the same TNC to do both. It's a cinch with aprsd.
KISS is therefore not an option.
--
Neil Johnson
http://www.njohnsn.com
PGP key available on request.
----------------------------------------------------------------------
Subject: Re: [ Robert Bruninga ] OPENtrack for programmers, APRS for users
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Sun, 06 Jun 2004 17:07:15 -0500
X-Message-Number: 71
>So? Where is the PROGRESS FOR THE END USER?
>
>Why do we need to re-write all existing parsers, obsolete all
>existing code and obsolete all hardware just so we can
>have "Scotts" position format when APRS position format
>works just fine.
For years, Microsoft, MSDOS programmers and MSDOS users argued with the
Unix crowd. The MSDOS crowd said we don't need no stinking protected
memory access, no file ownership, or none of the kernel mode crap the slows
down my computer. We need programmers to write more robust software. Those
stupid programmers just need to do a better job.
Well, guess what? Microsoft has demonstrated to the world what happens
with complex programming environments. People make mistakes and we end up
with exploitable software bugs that result in billions of dollars in costs.
MSDOS was replaced with windows which has, over the years, added memory
protection, user level access control to the kernel etc. This protects the
users from the software and programmers.
APRS is not at this level of use at this time, and it hasn't been exploited
yet. But, what is happening is that I see programmers interested in doing
a better job for the users. They want to be successful, and have limited
time to spend on this volunteer effort. So, you bet, the programmers what
it easier.
What about the users? Well, they get to keep using APRS. Those who want
the 'users' to see their data, will keep transmitting APRS information as
long as the APRS audience can only be reached by transmitting APRS data.
The experiments will continue to happen, and if there is a leason to be
learned, I'm sure it will be learned. But, who will learn which leason is
left to the future...
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: APRS extensibility and OPENtrack
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 18:07:13 -0400
X-Message-Number: 72
>>>"Scott Miller" <scott@3xf.com> 6/5/04 1:11:29 PM >>>
>Now, designing a packet so that no one else can see it
>would be a pretty silly way to design a broadcast-based
>protocol, wouldn't it?
Yes, so why is OPENtrack putting all its efforts into making sure that
OPENtrack packets cannot be decoded by Kenwoods or any other existing APRS
network participant?
>If I was to uuencode... OpenTRAC traffic and place it in
>a user-defined APRS format, what's the difference?
I agree! If it is a position report, put it in the original APRS format so
that all the net users benefit! That is the purpose of the APRS network in
the first place.... Why are you going to so much trouble to make a
"Scott's-own" position packet format that benefits no one else on the net
when its only benefit is to make the job of programmers easy?
We keep telling you, dont make it a user-defined format unless you cannot
do it within what exists. So far, the only thing I have seen that APRS
cannot do is 1 centimeter precision. I dont think anyone on the air now
gives a hoot and could care less if you put that in a user defined format
thta no one can read. Just make sure that the original precision of that
same packet down to the foot REMAINS in the APRS protocol so that everyone
else can benefit to at least that precion without having to obsolete
everything.
Scott continues:
>[so] what's the difference? ... None, except that now
>anyone watching APRS is subjected to big strings of
>alphanumeric garbage that they can't read either, rather
>than being able to ignore the traffic completely.
So then why is this OPENTRACK alphabetic "garbage" as you call it so intent
on trashing the APRS network which tries to make as much of its formats
human readable as possible? Where is the value added? (except to
programmers)...
APRS was designed with the END user in mind. By striving to keep as MUCH
of the protocol HUMAN readable so that the end user can SEE any new data,
READ it with his own EYES and comprehend it WITHOUT having to download new
software each and every time someone wants to communicate a new data item
to an end user...
OPENtrack is designed to talk end-to-end with only other PC's. Even the
messages and any other TEXT cannot be read-or-understood unless EVERYONE is
always upgraded to the latest and greatest....
Where does this leave the end user who doesnt always upgrade to Scott's
latest and greatest?
Scott's example was so that he could add the voltage and temperature to his
position reports, but it REQUIRES you to have a compatible OPENTRACKER
software.
Where as, any APRS END-USER can add that to his position packet NOW with
EXISTING formats just by adding "13.8v, 75 deg F" to his position comment.
In fact, he can also add anything else. How about "dew point, 36 deg". I
think anyone on the APRS channel is smart enough to be able to understand
that. when he sees i t on his radio...
Bob
----------------------------------------------------------------------
Subject: DIGI-Object-Maintenance
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 18:13:24 -0400
X-Message-Number: 73
>>>"Scott Miller" <scott@3xf.com> 6/5/04 1:13:56 PM >>>
>>DIGIPEATER OBJECTS:
>>...But that having DIGIS repeat all OBJECTS heard
>>has all kinds of negative impacts on the net and is not
>>a wise idea.
>
>When did I say anything about having digis repeat ALL
>objects? If you'd read my proposal, you'd see that it
>would require a specific cache request from the
>originating station.
That's what it looked like to me and also you did not then discriminate
between OBJECTS and STATIONS. Int is sitll on
the air and PARTICIPATING in the net.
Having the DIGI regurgitate the positions of DEAD stations that are no
longer on the net is an anathma to the real time APRS network.
So I am glad that we have now found elemens of agreement and 0400, Robert Bruninga wrote:
>>>><wes@johnston.net> 6/5/04 12:54:39 PM >>>
>>I will write Bob and ask him to cease transmitting DX Cluster
>>packets on the APRS_only_ channel. Wes
>
>Sorry wes,
>
>The DX spots format IS part of the APRS spec...
What page is it on?
ftp://ftp.tapr.org/aprssig/aprsspec/spec/aprs101/APRS101.pdf
(as adopted by the APRS-WG August 29, 2000)
>ALL APRS software is supposed to decode them.
Again, what page?
>Kenwood read the spec and included them in their APRS radio without
complaining...
Yeah, I seem to remember that movie Jody Foster was in, called "Contact"
which was based on Carl Segan's book. It had to do with a device, built
from Alien plans, that allowed travel across time and space using worm
holes. Anyways, the device built in the U.S. got destroyed but then a
"secret device" was discovered that the Japanese built. It was this device
Jody used to visit the aliens across time and space.
Reason I ask, is the Kenwood radios where already RELEASED even before the
FIRST >DRAFT< APRS spec appeared!, let alone ratified spec.... maybe they
used this secret time travel machine to read the spec, you think?
BTW, in confirming some of the facts here, I ran across a interesting post
from 1999:
http://www.tapr.org/tapr/list-archive/aprsspec/9912/msg00059.html
Seems even some members of the now defunct APRS-WG had a few things to say
about Kenwoods and how they where holding back APRS. (Yes, the archives of
the APRSSPEC do work... isn't that a bear, Bob?)
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 18:22:01 -0400
X-Message-Number: 75
>>>Jeff King <jeff@aerodata.net> 6/5/04 1:32:33 PM >>>
>>But APRS is a distributed NETwork designed for
>>everyone to share the data for the mutual benefit of all.
>>APRS is a one-to-all NET. Everyone participates,
>>everyone expects to see the data.
>
>So too OpenTrak. Now it is really starting to look like a Duck
So then why all this attempt to make them NOT seen by the 20,000 existing
users on the APRS channel?
>>Adding incompatible OPENtrack packets to that
>>network at the expense of collisions
>
>Nope, sorry, CSMA is fully supported in OpenTrac,
>like I said, basic layer 1 stuff.
But it still takes up channel capacity that benefits none of the existing
network participants in their mission... When you take channel capacity
from an existing saturated net, you are causing damage, and missed packets.
The ALOHA channel can only take about 18% and only the DIGIS are fullly
CSMA, all of the end users NEVER hear all of the other users and thus are
NOT anywhere near fully CSMA! We have been down that road a thousand
times...
>Darn.... is that Duck poop on my antenna?
Sounds like it to me....
Bob
----------------------------------------------------------------------
Subject: RE: OPENtrack DIGIpeater Objects
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 18:36:40 -0400
X-Message-Number: 76
>>>"Scott Miller" <scott@3xf.com> 6/5/04 1:51:13 PM >>>
>>My point was that APRS protocols fully support your idea already.
>
>Here's my IGATE's beacon text:
>
>!3457.54NI12025.44W& SMX IGATE N1VG.NET
>
>Show me how I can format it to request my local digipeater
>to cache it and have it retransmitted every 15 minutes for
>the next 10 hours.
Easy, and using your TOCALL idea. Great idea by the way.
The TOCALL for the above packet would be OBJAE
Where OBJ says it is a request to the digi, A is the 10th letter in the
0-1,A-Z alphabet for 10 HOURS and "E" is the 15 minutes.
>Keep in mind that the digipeater most likely has no
>time-of-day clock, and that the decaying rate algorithm
>is meaningless in this case.
You dont seem to udnerstand the fundamental APRS decaying rate. It sends
NEW more frequently than OLD data to improve the probability that EVERYONE
gets it IMMEDIATELY and donest have to wait 30 minutes to see that the FIRE
TRUCK moved!
In ANY case of the decaying protocol, it starts high (for quaranteed quick
update of EVERYONE) and then decays down to the "set" netcycle rate. In
this case, 15 mminutes.
These FIXED rate algorithms completely undermine the rapidity of APRS. The
programs that stick to just a dumb once-every-15 minute rate for a NEW
object almost guarantee that HALF the users of that REAL-TIME NET wont see
thefire truck move until 30 minutes later if they miss the first
packet!!!!! This is absurd.
Where as in the decaying rate, the packet will have been tranwsmitted 3
times in the first minute or so when it is IMPORTANT to get that NEW info
to the end users. Then it eventually decays down to the final rate. Once
it is more than 15 minuts old, it is no longer real time and so the 15
minute rate (or whatever) is just fine for informaing late participants...
This is so fundamental to APRS it is a crying shame that none of the follow
on APRS-clones implemented it. That is wjhy so many end users of these
programs have no clue how UP-TO-DATE and rapidly moving OBJECTS can be used
in APRS. Because these dumb FIXED-RATE programs can take an HOUR to update
the movement of the fire truck if just one packet is missed!
>The system has been up for 165 days since its last
>reboot and hasn't moved - what would your
>decaying rate be at now?
If the requestor asked for 15 minutes, after the first 15 minutes he would
get 15 minuts for ever. The point' is that APRSdos and all PROPERLY
implemented APRS systems are aware that the channel is not perfect, thus
they send additioal redundant copies whenever something CHANGES to make
sure that EVERYONE is updated in REAL time, not an hour later....
>I'll offer one final proposal to bring OpenTRAC in line
>with APRS. I'm willing to modify the spec and all
>existing implementations such that all packets
>carried over AX.25 will be prefixed with a comma.
Find, just go do it on 145.55 or the national 145.01 network where it wont
interfere with a net already in progress. And you will have a completely
virgin frequency without all that APRS interferrence on it...
Though, I would much prefer you to stay on 144.39 and just use your
excellent tallents to make progress on APRS for end users, and not just for
the ease of programmers...
Bob
----------------------------------------------------------------------
Subject: RE: DIGIpeater OBJECTS
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 18:46:27 -0400
X-Message-Number: 77
>>>"Scott Miller" <scott@3xf.com> 6/5/04 2:12:50 PM >>>
>2) is noted that it has been built into all copies of APRSdos since 94
>
>Your interpretation. I've given you an example of what
>I want to do, I waiting for you to show me how to do it.
Its the DIGI that you want to do this, so its the DIGI that has to
implement it. What I am saying is that any station, including a digi can
take over an object at any time and ALL EXISTING APRS code will honor that
and hand it over.
Programming the digi to take it is up to you.
I liked your suggestion of using the TOCALL. I proposed the format OBJxyz
where "x" tells it how many hours to keep it up, and "y" provides the
fudamental rep-rate in minutes.
>Spec references, please. Show me where it's defined.
See the section on OBJECTS. It says that anyone can take over an object
just by transmitting it. The original sending station on seeing that copy
will cease transmitting it. Thus the new sending station, (in this case
your new digi) has control...
>If you're a message-capable station, then you don't
>need to be using this feature. It's for EOCs, fire stations,
>unattended systems...
Yes, and all excellent ideas. Now that we have decided on a mechanism
where we can do it within the existing APRS protocol, I am all for it! Lets
go with it!
As soon as you agree and if there are no objections, Ill add it to the APRS
SPEC errata page....
Bob, WB4APR
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
