| |
ZL3AI > APRDIG 12.06.04 21:40l 819 Lines 32475 Bytes #999 (0) @ WW
BID : 3435-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 06, 3/9
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<7M3TJZ<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040612/1900Z @:ZL3VML.#80.NZL.OC #:25696 [Chch-NZ] FBB7.00i $:3435-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: updating databases over aprs?
From: "David John Walsh" <david.walsh@vodafone.net>
Date: Sun, 6 Jun 2004 16:55:29 +0100
X-Message-Number: 31
First rule of any important comms : keep it simple
>From looking at the APRS specifications, keeping it within the message
protocol keeps it simple. The idea is to send a string as follows:
:M9AAADB00:T999#1234#9999#----------#----------#-SECTION FOR
NOTES--#?ABCDE?#{XXXXX
To explain some of these away:
M9AAADB00 - "Call" of the database system (Station call + database
number)
T999 - Team number reference
1234 - Time in
9999 - Time out / retirement code (8888 still at base, 9999 retired etc)
---------- - Data space
---------- - Data space
-SECTION FOR NOTES-- - 20 character message space (comment field)
?ABCDE? - Hash of message (for acknowledgement purposes)(hashes from
first letter of destination call to the last gate [#])
The ":"'s and the "{XXXXX" are as per the APRS specification document
and there for reference.
Unless I have miscounted this fully uses the 67 characters limit
Other than keeping away from the ~{ or pipe ASCII character can anyone
see how this format would affect service? Is the design of the
destination address ok? Can I put a # or % sign in the destination
address (make M9AAADB00 to M9AAA%000) to ensure the callsign is able to
be noted without ambiguity or is there a technical / morel / APRS
compliance / legal issue with this
Thanks
David
----------------------------------------------------------------------
Subject: Re: APRS in the field. Big step forward...
From: "Spider" <spider@rivcom.net>
Date: Sun, 6 Jun 2004 09:19:12 -0700
X-Message-Number: 32
From: "Robert Bruninga" <bruninga@usna.edu>
>>>>Henk de Groot <henk.de.groot@hetnet.nl> 6/5/04 12:23:31 PM >>>
>>Kenwoods, safely ignores all OpenTrack packets,
>>so no problem here.
>
>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...
>
>Bob
Bob, your consistent defense of the Kenwoods is simply amazing! I really do
use APRS in the field and have yet needed a Kenwood to do it, and I find
them to be outdated and very limited. Yesterday, I did 4 rescues and APRS
was there in support of that (well, until my CommTrak died in the heat!) The
Rino's where there in force and worked well, btw.
Is there some underlying reason that you so strongly defend Kenwood and
their aged product? I'd really like to know because it's so obvious to me
that these Kenwoods are a major factor in stopping forward movement of the
State of the Art simply because you are so wrapped up with them. I
understand that "change" is very hard to accept but GEEEEEZE LOUSEEEEE this
is getting old hearing about these Kenwoods and their lack of ability! What
Gives? What am I missing here?
What would help the ham in the field is for the programming community and
the manufacturers to shut up for a minute and listen to us tell you about
the things we need and support those that are truly out in the field trying
to use this stuff. Some of us tell you guys what we need , we ask, we
plead, we d*mn near beg , we find problems, etc., some of us have even
invested money into certain softwares to get things implemented (for the
good of all) and pretty much get slapped down everytime we make an effort at
improving things....even using things within the existing spec! How long
to do think that is going to last with anyone that has half a brain? Now,
to be fair, many things have been implemented within the last few year to
help support the 'hams in the field' and without a doubt, it is very much
appreciated.
There is a big difference between what is considered an argument and what is
a discussion. This OpenTrac issue is not a discussion. Please STOP arguing
and do something constructive and positive for the advancement of the art.
I doubt OpenTrac is going away. Actually these arguments make me want to
support it more.
Blocking it or discouraging it's use on a UI-Network is, IMHO, just plain
over-reaction, really based on no real measurable effect or result that
can't be over come when working together.
Life is too short for all this bull. What new opportunities and challenges
do we have to look forward to, as hams in the field, using APRS in the next
few years? It is NOT Kenwood...they've already said that. What new and
challenging opportunities do we have to look forward to with OpenTrac in the
next few years? Scott and probably better answer that.
Gawd, I am happy just to be able to use compressed APRS posits with the
OpenTrak product!
Jim, WA6OFT
----------------------------------------------------------------------
Subject: Re: The OpenTrac Debate and BS!
From: db2fm <db2fm@jfsattv.de>
Date: Sun, 6 Jun 2004 18:23:37 +0200
X-Message-Number: 33
Am Sonntag, 06.06.04 um 13:52 Uhr schrieb Robert Bruninga:
>>>>Danny <danny@messano.net> 6/5/04 10:40:04 PM >>>
>>There are flaws in the APRS system.
>
>I wouldn't call them flaws, but hindsight. Of course,
>things can be put together more streamlined with a
>total re-invention of the wheel, but why? When it
>would sacrifice all existing users?
That's big b***sh*t! Sorry to say that as hard as I did! You americans
normally tend to use hard words and propaganda (a word very rarely used in
Germany because of things in the last century!). Bob, please please please
be objective and stop rephrasing the same things again and again! My YL
works in a kindergarden (funny! German word! :) and the kids (3-6) are more
grown up than some members of this SIG!
We are not in the military here, just a community (comes from Latin
language, first part is 'con', which means 'together'!)
>If you think there
>are insurmountable flaws, please list them so we
>can see what you are talking about?
>
>>Much of it could be improved with an APRS Spec 2.0.
>
>Like what? And what would be the disadvantage
>of obsoleting 20,000 users. Probably 10,000 of
>which have hardware THAT WOULD NOT WORK
>ANY LONGER?
Stupid phrase, propaganda, again, sorry! No 20,000 users would be obsolete!
Nobody at all! Every application can be upgraded if needed, hardware still
IS compatible (or could be made so). It's NOT as you say! Keep to the
truth! There are no mass-dkilling weapons in OpenTRAC!!! (Heard of a war
began of that info, which couldn't be proven truth...)
>APRS is not for basement couch potatos to just command a global map.
>Its for people to get off their duff, get out into their local community
>and DO something. Couch potato's can upgrade their latest software toy
>in about 1 minute. The rest of the APRS network and most of those that
>actually do something with it cannot "change" without ABANDONING what
>they have worked so hard to build and going out and buying new toys.
>They are the silent majority.
Everybody can speak up, and would, if your phrases were true!
Why don't you ever listen to other other people or try to understand, what
they want?
I heard no programmer say: "hey, APRS is better to parse!" or whatever.
They all try to keep up to the errata-page or whatever to keep their
aplications up-to-date, using tons of code because APRS is what it is!
Don't try to convince them with propaganda! Try it with REAL arguments!
Neither you nor any other person could answer the questions what really
didn't work in this 'accident#, asked repeatedly.
Everytime I only red the same phrases again and again. No REAL arguments at
all!
That's not progress! I don't know what to call it!
>Newcommers who just want to add new bells and
>whistles without having to study the spec and figure
>out how to add the bells and whistles within the
>existing FULLY EXTENSIBLE structure are the ones
>that are willing to sacrifice the majority who are
>doing just fine with a working system for the sake
>of the basement couch potatos with an attention
>span of about a day...
It still IS a nightmare! (Some bytes here, something there)
>>Perhaps it would be incompatible with APRS 1.0.
>>Perhaps authors would have to do some rewrites for 2.0.
>
>And all 10,000 owners of Kenwoods and HAMhuds
>and all the owners of existing trackers would have
>to start over...
I own a TM-D700, too. I would be fine to use something external to it, to
keep it up-to-date, like a HamHUD or whatever needed.
>That is the purpose of the APRS-WG, to make sure that
>things continue to work and that any thing that is new
>that cannot be done within the existing strcuture is
>added to the spec. So far, nothing we have seen
>cannot already be done within the flexibility already
>built into the existing spec.
Is I stated in an other mail:
Everything will still work, also, if OpenTRAC shares the frequency!
>Bob
Again: please, please, please calm down and show us REAL arguments that
would be of any reason to not share the 144.390 (144.800) for the two
protocols APRS _AND_ OpenTRAC!
I'm really done with that discussion now!
73 de Juergen
P.S. Bob, your work could be honored in foreword of the OpenTRAC spec
as a former spec that leads to the new one.
Or is the problem, that it isn't right now (because there's no
foreword at the moment)? ;)
P.P.S. The world speaks SI units, not knots or whatever the military does!
----------------------------------------------------------------------
Subject: Re: APRS in the field. Big step forward...
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sun, 06 Jun 2004 18:27:05 +0200
X-Message-Number: 34
At 10:50 6-6-2004 -0400, Robert Bruninga wrote:
>>>>Henk de Groot <henk.de.groot@hetnet.nl> 6/5/04 12:23:31 PM >>>
>>Kenwoods, safely ignores all OpenTrack packets,
>>so no problem here.
>
>And this is Progress????
Yes, it shows that a new protocol can co-exists with the old protocol
without disrupting the existing service.
What would you expect? I would have been very suprised if the Kenwoods were
able to decode this brand new protocol, did you realy expect that?
>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?
Yes, this means that it can be developed alongside the existing APRS
service and allows smooth migration to clients that know both protocols or
in the future (over 10 years?) only know about OpenTrack.
This means that for the near future it is possible to get a higher
accuracy, smaller devices and g clients (with the exception
of Xastir) don't know about it and ignore it just like when those new APRS
features were introduced. When the data is there, clients will addapt, just
like they have always done with every extention over the years (however
some faster than others).
Rest assured, it will be a long time before OpenTrack replaced APRS, by the
time that happens, most Kenwoods will be dead and gone. Tell me, how fast
did the TH-D7A vanish when the TH-D7A(G) was introduced. The TH-D7A cannot
even read todays NMEA GPS data streams anymore. Maybe in a few years
Kenwood will have an OpenTrack TH-D7A(O) (which will be a hell of a lot
easier for them than the current APRS experiment)...
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Looking for a few NC APRS Users...
From: "Rich Garcia" <k4gps@arrl.net>
Date: Sun, 6 Jun 2004 12:37:21 -0400
X-Message-Number: 35
Need to speak to some hams in various parts of NC for some help.
Can some of you please contact me off list ?
Thanks,
Rich
----------------------------------------------------------------------
Subject: Kenwood and KISS mode
From: Wes Johnston <wes@johnston.net>
Date: Sun, 06 Jun 2004 12:40:17 -0400
X-Message-Number: 36
Can someone explain to me the nuances of getting a kenwood radio's TNC into
/ out of kiss mode with regard to what it takes to get out of kissmode and
talk to the radio itself (QSY, memory read/write) and back into KISS mode
again.
Wes
----------------------------------------------------------------------
Subject: Re: The OpenTrac Debate and BS!
From: Steve Dimse <k4hg@tapr.org>
Date: Sun, 6 Jun 2004 12:43:16 -0400
X-Message-Number: 37
On 6/6/04 at 5:50 PM db2fm <db2fm@jfsattv.de> sent:
>There would't be backwards compatibility in using user defined data
>either!
No, APRS programs are program to expect the user defined formats, and to
ignore ones they do not decode. This is very different than opentrack,
which appears as random characters to APRS.
>>Other than these rewrite proposals, most people want to add something
>>to the spec.
>Why ony addition, no change? Too much settled down? Too lazy? (kidding)
I did say most, and that is what I meant. I cannot recall (though there may
well have been) a proposal that was neither a clean-up or addition.
>>The user defined format provides a means for anyone, without APRS WG
>>approval, to add their own data to the system. This was done
>>specifically to
>>encourage experimentation and to prevent the APRS WG from holding it
>>back in any way.
>So, you propose to use the user defined datum and test OpenTRAC there?
No, they have made it clear they want no part of APRS. What I said was
anything that they wanted to do they could have done with the user definied
format. I most certainly do not expect them to start using it now.
>As I see it from across the big pond is that there are some <kidding>
>old </kidding> men sitting on THEIR spec and don't like ideas not coming from
>themselfes.
Exactly, what I'm trying to point out is this is not the case, we are
trying to maintain backwards compatibility, so that the vast majority of
APRS users that are satisfied with the current system are not adversely
affected.
>My proposal would be (and was some time agon on this SIG):
>- keep APRS as is (without extending and extending - shouhorning IIRC)
>- try OpenTRAC in parallel on the SAME nationwide (in EU even more)
>frequency
> and put new development-ideas in this easier to parse and handle
>protocol.
The problem is first, the two protocols are not compatible, and second, the
APRS network, at least in the US is heavily loaded.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: The NEXT Greatest thing to APRS!
From: Wes Johnston <wes@johnston.net>
Date: Sun, 06 Jun 2004 12:44:48 -0400
X-Message-Number: 38
I was really hoping the guy who wrote echolink and echostation would have
implemented it.
Wes
At 10:19 AM 6/6/2004, Robert Bruninga wrote:
>See http://www.ew.usna.edu/~bruninga/aprstt.html
>
>But if some brilliant programmer put those energies
>into APRS-Touch-tone, he would REVOLUTIONIZE
>APRS and HAM RADIO make it indespensible at
>all ham radio activities.
----------------------------------------------------------------------
Subject: OPENtrack Binary Versus ASCII
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 12:50:41 -0400
X-Message-Number: 39
>>>Henk de Groot <henk.de.groot >>>
>>4) APRS allows extensions just just fine.
>
>Not true, APRS relies on ASCII... You can't extend APRS
>with a pure binary protocol...
Programmers whining again. And why would the END USER in the field care if
its ASCII or BINARY as long as it works?
>I don't know how you envision to squeeze in a binary
>protocol..
We dont, APRS never planned on using binary and never will. It was
fundamental to APRS that all packets were 7 bit ascii to avoid any problems
with Binary, ASCII works everywhere. Binary does not. Remember, APRS is
supposed to work for users, not make the job simple for programmers...
>You used to be a man of vision, did you loose that?
Nope, my vision is that APRS works for the end user, now and forever. It
can do just about anything and it can be extended WITHIN THE PRESENT SPEC
to do just about anything we can think of... for the END USER.
>Why can't you see futher than you nose-length anymore?
Because APRS is a standard communications system for end users in the
field, It is not to be jerked around every-which way for programmers...
>Or... are you just not willing because OpenTrack is not
>your idea?
Nothing wrong with OPENtrack, Its just not compatible with APRS and
shouldnt be interferring with the national APRS channel or its objectives.
If there is something for the end user that is missing in APRS and is
REQUIRED at a tactical real-time local events, and that cannot be done
within the current spec, please let us know. We are happy to address it..
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: The OpenTrac Debate and BS!
From: Danny <danny@messano.net>
Date: Sun, 6 Jun 2004 12:59:42 -0400
X-Message-Number: 40
RB> Like what? And what would be the disadvantage
RB> of obsoleting 20,000 users. Probably 10,000 of
RB> which have hardware THAT WOULD NOT WORK
RB> ANY LONGER?
If a newer specification were put into place, it would be years before
anything would be obsolete. There is no reason we couldn't design dual
mode hardware and software to make sure APRS 1.0 was around for years to
come. Those choosing to use the new APRS would be able to choose to do so,
via their "toy".
RB> APRS is not for basement couch potatos to just
RB> command a global map. Its for people to get off
RB> their duff, get out into their local community and
RB> DO something.
What does that have to do with anything?
RB> Couch potato's can upgrade their latest software
RB> toy in about 1 minute. The rest of the APRS network
RB> and most of those that actually do something with
RB> it cannot "change" without ABANDONING what
RB> they have worked so hard to build and going out
RB> and buying new toys.
So, APRS software is for non-active couch potatoes, and APRS hardware is
for REAL APRS users?
Other than the precious kenwoods, most APRS toys can be ugraded by popping
out an IC and popping a new one in. I do it all the time. Is it REALLY
that hard?
RB> They are the silent majority.
Very silent. Whenever protocol discussions come up, we never hear from
them. I suppose they are still using OLD computers without internet
connections?
RB> Newcommers who just want to add new bells and
RB> whistles without having to study the spec and figure
RB> out how to add the bells and whistles within the
RB> existing FULLY EXTENSIBLE structure are the ones
RB> that are willing to sacrifice the majority who are
RB> doing just fine with a working system for the sake
RB> of the basement couch potatos with an attention
RB> span of about a day...
First off.. The whole slamming of newcomers is a little ridiculous. Sounds
like one of those "Damn no-coder" arguments to me. First "basement couch
potatoes", then "newcomers".. Come on, Bob.
Besides, lets not get into a discussion about how just because I bought I
kenwood, that is non upgradable, the world should revolve around me.
Secondly.. If this is such a great working system, why do we see people
developing alternate protocols, and why have an addendum page on your OWN
web site?
>>Perhaps it would be incompatible with APRS 1.0.
>>Perhaps authors would have to do some rewrites for 2.0.
RB> And all 10,000 owners of Kenwoods and HAMhuds
RB> and all the owners of existing trackers would have
RB> to start over...
As stated before.. This is about the kenwoods. I can't believe we are
alienating the tens of thousands of OTHER APRS users because of the
kenwoods.
RB> That is the purpose of the APRS-WG, to make sure that
RB> things continue to work and that any thing that is new
RB> that cannot be done within the existing strcuture is
RB> added to the spec. So far, nothing we have seen
RB> cannot already be done within the flexibility already
RB> built into the existing spec.
So far, nothing new has been added because everything needs to fit the spec
built into the kenwoods. Enough said.
Danny
KE4RAP
----------------------------------------------------------------------
Subject: Re: 30 Meter Policing needed.
From: "Clayton H. Owen" <aa3jy@winlink.org>
Date: Sun, 6 Jun 2004 12:4:33
X-Message-Number: 41
I believe W3ADO's APRS HF beacon station fell from priority and was
replaced by the APRSSAT project..
----------------------------------------------------------------------
Subject: RE: New National OPENtrack freq
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 10:05:15 -0700
X-Message-Number: 42
>A good idea to allow OPENtrak to grow unimpeded
>by concerns for backwards compatibility and the needs
>of existing users would be to find a national OPENtrak
>frequency. I suggest 145.55 MHz
Frankly, OpenTRAC doesn't at this point need a totally separate nationwide
channel. It'd be a waste of bandwidth. I'd rather see that QRG allocated
to a secondary input-only APRS channel for transmit-only trackers, weather
stations, and so on. Especially for weather stations - they're not moving,
so you know exactly what areas would benefit from the channel coverage, and
you don't have to worry about trackers moving outside of covered areas.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: Sounds like Programmers Convenience to me....
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 10:11:47 -0700
X-Message-Number: 43
>Again, how does this serve the end user volunteeer that
>shows up to help at a public service event? Sounds
>only like programmer convenience to me...
Well, yeah... that was the point. Common libraries aren't generally written
for the user's benefit. They shouldn't have to worry about it. Writing an
OpenTRAC parser is far easier than writing an APRS parser, but there's still
no reason to force everyone to reinvent the wheel. Those who don't want to
write their own can use the library and avoid the issue completely.
>Ah, what most people dont realize is that APRS is far, far
>more than just decoding a position and putting it on the
>map. That is why most users have never even used but
>about 10% of its capabilities:
I was illustrating a point about the simplicity of the library.
>too hard... again, where does this help the volunteer
>in the field. just sounds like programmers to me...
Writing good user interfaces is up to the application programmers. A common
parser library lets them focus on doing that, rather than debugging a
parser.
>Souns like more programmers to me...
Are you saying that having the ability to distribute new, customized code
for the Kenwood radios would benefit no one but the programmers?
>And that is a communications planners biggest nightmare.
>Everyone shows up with a radio with a different version
>of the lastest and greatest toy and so wtithout compatibility
Which would be different from the situation with APRS on the PC now?
>PLANNING on events by PLANNING on Downloading
>the lastest whiz-bang at the start time, is a recipe for
>communications failure.
I don't think you're understading what I'm suggesting.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 6 Jun 2004 10:13:50 -0700
X-Message-Number: 44
>about PID's. It was referring to all other UI packet formats.
>And UI packets ALL have a PID of F0. The same as APRS...
You're going to have to point out in the AX.25 spec where it says that, Bob.
I don't see it. The way I read it, the UI part is defined in the control
byte and has nothing to do with the PID.
Scott
N!VG
----------------------------------------------------------------------
Subject: Re: APRS in the field. Big step forward...
From: Jeff King <jeff@aerodata.net>
Date: Sun, 6 Jun 2004 13:22:17 -0400
X-Message-Number: 45
On Sun, 06 Jun 2004 10:50:52 -0400, Robert Bruninga wrote:
>>>>Henk de Groot <henk.de.groot@hetnet.nl> 6/5/04 12:23:31 PM >>>
>>Kenwoods, safely ignores all OpenTrack packets, so no problem here.
>
>And this is Progress????
The Kenwood also ignores PSK31 Bob, when you go forward, by implication, it
means some vehicles also have to press the gas peddle to catch up. Otherwise,
we'ed all still be running spark.
73
jeff wb8wka
----------------------------------------------------------------------
Subject: OPENtrack for programmers, APRS for users
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 13:24:39 -0400
X-Message-Number: 46
Everyone, PLEASE READ this one, it says it all!
>>>gregg@skymaster.cytetech.com 6/5/04 12:57:11 PM >>>
>If Scott reformatted his packet to be a user defined
>packet to hide it from parsers that had problems, then
>it would still not be useable by existing APRS clients.
>If Scott encoded new types of data into a comment field, it would
>still not be recognized by existing APRS clients.
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. I have not seen one single
person demanding 1 centimeter accurracy. So far, that is the only
difference in his position reports. APRS can do one foot already...
>By using the PID of 0x77, he has made it possible for
>KISS based software packages to integrate new parsers
>that make use of a different structure of data.
Programmers whining again. Where is PID 77 of any benefit to the END USER
IN THE FIELD?
>We have is the ability to operate at the same time. If a
>station transmits only opentrac data, it will be, on the average,
>less channel use than if it transmitted APRS data.
I dont see that at all. 95% of all mobils are Kenwoods using the very
short Mic-E format that works just fine. As noted in Scott's example, he
challenged us to comare packets and his was 66 bytes compared to the 38 or
so in APRS todo the SAME THING.
I fear you are being sucked into the missleading propaganda of programmers
again, and not looking at the value for the end user...
>Instead, he used 0x77 PID which adds no channel
>overhead, and still allows conforming TNC configurations
>...to ignore the data in the same way that APRS
>applications would ignore the {T packets.
Where is the benefit to the END USER IN THE FIELD? To him every single
OPENtrack packet and its 66 bytes is channel overhead, on the APRS channel.
The APRS channel is for letting EVERYONE ON THE CHANNEL participate in the
net and to SEE ALL IMPORTANT data of interest in the event.
Where does OPENTRACK fit into this picture?
>I think that it is interesting to try and find ways to continue
>to shoehorn more functionality in to our APRS design.
>But, what I and apparently other software authors are
>finding is that it is problematic in software design to
>use such complicated formatting rules.
Programmers whinning again. No one said it was easy, but shucks, I did it
in BASIC for gosh sakes...
>From a formal language design perspective, there are
>context issues that make it possible for programmers to
>misunderstand the true position or context that they will
>find a particular item in. Conditional processing becomes
>very cumbersome in embedded software in particular,
>where such things add considerable code space in
>a restricted environment.
Programmers again. Its not a slam dunk-instant-gratification easy spec to
follow, but ANY programmer can do it that wants to contribute to the APRS
goals of a common standard for END user digital communications...
>OpenTrac makes it very explicit where data items are and
>how they are structured. This makes it very trivial for
>embedded software applications to extract exactly the
>items they can handle without having to conditionally search.
Programmers again. Where is the benfit to the end user?
>Dynamic memory allocation in embedded applications
>can be very problematic. So, APRS specifying the maximum
>length of fields is a good thing. But, what it does is cause
>people to allocate fixed length buffers that will overflow
>when improperly formed packets are on the air. This will
>then crash these software systems, typically.
Yes, these programmers have to be careful and know what they are doing
instead of just churning out easy code that does nothing new for the end
user...
>OpenTrac specifies the length explicitly, so that there
>standing programatic requirement to deal with the length
>issue. It becomes a theme of the software design, and
>this makes for more robust software.
Programmers again. Gosh, we all know APRS evolved over the last 12 years
to a very feature rich applicaiton that has swept the world. The code is
not slam-dunk easy to follow. That is why the SPEC was written, to help
them catch up on the last 12 years of growth.
>We have a lot of people that seem interested in the
>transmit only telemetry devices. There are less issues for
>software stability when you are constructing packets.
>But, there are devices that handle data receipt (such
>as the HamHUD) which have had problems with poorly
>formed packets for years on end, because of the nature
>of APRS packets non-rigid format design (the spec
>spells things out, but people can transmit anything).
But the only thing you offer with your arguements is that OPENtrack would
simply make the HAM-HUD programmers job easier EVERY TIME it added a new
feature. It still requires NEW CODE EVERY SINGLE TIME YOU ADD A FEATURE!.
APRS avoids this issue by targeting the END USER, not the end programmer.
Thus, APRS can add anything that the end HUMAN USER CAN READ and it never
requires new code. If you want to display to the HAM HUD user that a
packet is saying the termperature is 102 degrees and the battery ovoltage
is 12 volts, then simply send this:
12v / 102 deg.
In OPENTRCK, Every single HAMHUND will have to download and install NEW
CODE to parse it and EVERY OTHER single change as well. This is why APRS
targets the END USER. No upgrades required...
>The more rigid structure of OpenTrac is truely a benefit to
>the software design and writing process. ... <snip>
Programmers again....
>Languages such as Java and your favorite, QBASIC,
>help the user by making these length issues explicit
>in the constructs of the language and its library
>of built in functions/methods/operations.
Programmers again, not users....
>There are PIC-BASIC environments, and there are Java
>based microcontroller environments. But, I think that
>the fundamental issue is still that the structure of APRS
>packets doesn't provide the programmer with enough fixed
>pieces of information to make sure that they can be successful.
So, who cares? Compatibiity with 20,000 END USERS or just easyniess for
programmers...?
>OpenTrac's use of binary data for everything eliminates
>transformations that can be coded incorrectly. <snip>
>This is where OpenTrac is comming from. Scott found
>problems in the existing Amatuer Radio packet telemetry
>system, APRS, and is trying to do some investigation to
>design a new way that doesn't have the same problems that he
>found in APRS.
Problems for programmers. Nothing that impacts the end user. I have more
faith in programmers that they can easily solve any "problems" they might
find in APRS. Again, if I can do it in BASIC that every kid learned in
High School 10 years ago, I'mm sure these bright guys can figure it out,
especially since we wrote it all down in the spec!
>The whole evolution of the HF digit modes from CW
>through PSK-31 (and the like) shows that there are
>better ways to do digital mode exchanges. There
>are portions of the bands preallocated to particular
>modes on HF, because of the propigation ,...
EXACTLY AND NOWHERE will you find that PSK-31 is WELCOME on CW nets, nor
CW welcome on PSK-31 nets...! PSK-31 succeeded because it offered
something new for the END USER, not the newbee programmer.
>Again, this doesn't increase the channel load, it just puts
>the same data on the same channel with a different
>format.
[that nobody on there already can read!] To me that is called
interference in an existing net...
Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
