| |
ZL3AI > APRDIG 12.06.04 21:40l 742 Lines 32705 Bytes #999 (0) @ WW
BID : 3434-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 06, 2/9
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<7M3TJZ<ZL2BAU<ZL2BAU<
ZL3VML
Sent: 040612/1900Z @:ZL3VML.#80.NZL.OC #:25695 [Chch-NZ] FBB7.00i $:3434-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Sounds like Programmers Convenience to me....
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 09:03:45 -0400
X-Message-Number: 16
>>>"Scott Miller" <scott@3xf.com> 6/5/04 11:49:13 PM >>>
>...[lets] put together an API that'll make it as easy to
>integrate on non-Windows platforms.
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...
>... wrote a test program in Visual Basic to try out the
>decoder, and it takes about three lines of code to set it
>up and parse a position.
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:
1) Becasue most users never really use it in the field in special
real-time-local events
2) Followon programmers only concentrate on putting ICONS on the map
without even displaying the other 8 attributes of even such a symbol
3) nor implementing any of the other features that make it a general
purpose tool for the joy of HAM radio
In fact, it is implementing all the features of APRS is exactly what the
new programmers balk at and say is too hard... again, where does this help
the volunteer in the field. just sounds like programmers to me...
>Even better, let's convince a manufacturer to provide
>an interface API with full access to the user interface
>and back-end features of the radio and we can make
>the radios do what we want.
Souns like more programmers to me...
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 nothing works as planned, or you spend the entire
event chasing around with the latest code trying to get everything updated
to the latest bugs while only creating more...
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...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: RE: New APRS Digi-Object-Maintenance format
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 09:08:15 -0400
X-Message-Number: 17
>>>"Christensen, Eric" >>>>
>Yeah... What happens when one of these digis start \
>sending out 20 or so objects using WIDE5-5? Which
>unproto path will be used?
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.
Thanks for the useful feedback!
Bob
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 09:29:14 -0400
X-Message-Number: 18
>>>Bill Herrmann <bherrman@spro.net> 6/6/04 1:47:09 AM >>>
>The spec says that APRS uses a PID of 0xF0. Nowhere
>does it say anything about the use other than to say
>that it uses that PID. However, it also says: (on page 89):
>Packets that do not meet any of the formats described
>in this document are assumed to be non-APRS beacons.
>Programs can decide to handle these, or ignore them, but
>they must be able to process them without ill effects.
Thanks, Bill.
This paragraph is being interpreted in a manner that was NOT the original
intent. I wrote it. That sentence says NOTHING 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...
As we have said over and over. Filtering based on PID is BEYOND THE
CONTORL of APRS, it is a function of the TNC and APRS was designed with the
intent of allowing all existing TNC's that ALL used PID F0 at the time to
work.
Nothing more, nothing less. Knowing this, is why those with decades of
experience with actual AX.25 on the air recommended that OPENtrck is not
going to be able to share the common APRS channel easily by simply changing
the PID. Unpredictible results will occur.
Bob
----------------------------------------------------------------------
Subject: Re: Battery questions
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 09:35:07 -0400
X-Message-Number: 19
>>>"Scott Miller" <scott@3xf.com> 6/6/04 2:35:18 AM >>>
>Anyway, I've got a ton of questionable UPS batteries ...
>[My] smart charger/conditioner/maintainer... refuses to
>do anything with a battery at less than 10.5 volts charge,
>so to get 'em started I've got the dumb 2-amp auto/
>marine deep cycle charger.
Another method that works is to hook it in parallel with a good battery at
the beginning so that the charger will be fooled into running. After a
while, you can disconnect the good one, and then add the next one in
parallel and thus slowly work your way through the whole pile...
I had exactly the same thing happen below on one of them. Not sure. Came
back the next day and it was dead, but then the next change cycle it seems
OK... Bob
----------------------------------------------------------------------
Subject: Re: New National OPENtrack freq (How pathetic)
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sun, 6 Jun 2004 23:59:05 +1000
X-Message-Number: 20
I am sick and tired of hearing you silly yanks argue.
Grow up
----------------------------------------------------------------------
Subject: Re: 30 Meter Policing needed.
From: "Rich Garcia" <k4gps@arrl.net>
Date: Sun, 6 Jun 2004 10:03:17 -0400
X-Message-Number: 21
Hello to Arte and the gang... Peter W7LUS and I were a couple of them along
with W3ADO, I think there may have been a couple in the central states and
one in Half Moon Bay but god... that was years ago.
After having my TS-850S/AT on the air for over 7 years 24/7 and several rig
repairs I took mine off the air, I just could not afford to have more rig
repairs or needing to buy a new rig and the internet had finally come of
age.
So Peter and I are gone and I believe W3ADO is also. Speaking of Peter last
I heard he bought a new "RIG" has anyone heard from him ? I don't know if he
is back on the road or not but I don't see him on Findu.
Rich
K4GPS/N2CZF
-----Original Message-----
Hi all,
Glenn W. wrote:
>I've been running a 30m station for years. ... am I on frequency?
Years ago several HF APRS stations were designated to be "zero-beat",
that is, they were tuned accurately with stable rigs and could be used as a
tuning aid to others. Among these were W3ADO's 30-meter station. Do these
stations still hold to that standard, and can they still be used as such?73
----------------------------------------------------------------------
Subject: Re: New National OPENtrack freq (How pathetic)
From: "Kurt O. Jauss" <kf6hjo@earthlink.net>
Date: Sun, 06 Jun 2004 07:12:21 -0700
X-Message-Number: 22
Thanks for that! That added a lot to the discussion.
Andrew Rich wrote:
>I am sick and tired of hearing you silly yanks argue.
>
>Grow up
----------------------------------------------------------------------
Subject: The NEXT Greatest thing to APRS!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 10:19:57 -0400
X-Message-Number: 23
>Again, how does this serve the end user volunteeer that
>shows up to help at a public service event? ...
Actually, to me the most important contribution that new-blood programmers
could do for HAM radio today would be to implement the APRS-Touch-Tone
concept in Windows using only the sound card.
Such a programmer would REVOLUTIONIZE APRS in a way that HUNDREDS of
THOUSANDS Of users could take instant advantage of and serve HAM radio in
the field actually DOING something with APRS.
See http://www.ew.usna.edu/~bruninga/aprstt.html
Imagine, everyone with any old HT, or any old mobile could show up at ANY
event and be fully 100% APRS communications capable and able to support the
digital needs of the net.
This means 100% of every HAM can contribute to an APRS event, not just the
5% that have APRS! Even if Scott is 100% successful in developing a perfect
substitute for APRS, it still will never reach more than 5% of the
volunteers that show up at a HAM radio public service event.
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.
Remember, APRStouch-tone lets ANY HT, or mobile radio with a touch tone pad
do ANYTHING and MORE than any of the Kenwoods. But in a similar manner.
The user INPUTS his position, callsign, status, messages, email, queries,
bulletins, movements, ANYTHING via his Touch-Tone pad and he gets ALL of
his response via VOICE from the central APRS-Touch_tone server.
Think about it. Nothing to buy, nothiing to configure nothing to re-invent
or upgrade. No flash programming the latest whizbang in the field for
every event...
I implemented APRStouch-tone 2 years ago and it works well. But I did it
in basic and had to use an external TTdecoder chip and an external D/A
resistor string for speech. This clearly is NOT the way to go. I had
hoped that some slick programmer would take this idea forward and make a
really big name for himself.
The APRStt spec is fully developed. It just needs a winders programmer and
its only software!
I'd sure like to see all these recent programmer energies applied to this
fantastic APRS application... instead of trying to just invent another way
to do the same thing that will again, not really make that big a difference
in the field... The old-fud volunteers (bless them!) are always gonna
simply show up with an HT or a mobile rig and want to help...
And only 5% will ever have the latest and greatest. Thus why not just bring
one LAP-TOP to an event running APRStt and bingo, EVEYONE is a participant!
de Wb4APR, Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sun, 06 Jun 2004 16:23:33 +0200
X-Message-Number: 24
Hello Dale,
At 14:00 5-6-2004 -0700, Dale Blanchard wrote:
>What exactly is the difference between OpenTrack and APRS packets?
The difference in a nutshell is unification, structure and well defined
backward compatibility after whatever extension of the protocol.
>There are some of us out there using a product that we do not understand,
>because it was made easy to use. We kind of know what it does, but not how
>it does it..
This is one of the major problems since from a user point of view there is
at first glance no *functional* difference. The key is the way it is done,
where the structured approach of OpenTrack will allow much cleaner
implementations.
For the end-user this means less bugs in their programs and the ability to
get smaller and more feature-rich devices. If you read the SIG longer then
you will have read that both APRSdos as PocketAPRS have reached their
memory limit. When APRS would have been more structured both programs would
be smaller and would accommodate more features.
The approach of APRS has been - in my view - a process where new features
are added in an ad-hoc manner. Take for example the way a position is
reported. It started with a simple lat/long report. As time went by the
need rose for a more compact and accurate version, compressed positions.
Then Mic-E came to make the packet even smaller and pushing data in the
destination call. Besides that also raw GPS data was used by connecting a
GPS directly to a TNC, which adds another 2 formats. So now we have 5
formats all doing the same thing. Each APRSSPEC 1.0 compliant client has to
implement 5 decoding routines to get a position.
For the end user no problem, the client just plots stations on the screen
in all those cases. But it is a waste of code space and also error prone
since 5 algorithms need to be implemented and tested where it could have
been just one. The OpenTrack specification only has one way to report a
positions and by using a binary format it is both small and very accurate.
A client now needs to have only one parser and the code-space freed can be
utilized for other features, or one can choose to squeeze the client into a
smaller box.
The same story applies to WX data where APRS also has a whole load of
formats. The praised Kenwoods only has a small subset implemented because
of this, in a similar OpenTrack device there would have been only one
format and you would have had a fully compliant device instead of a small
subset.
APRS is not designed for extension, no matter what story Bob tries to pull
over your eyes. In the early days it was reasonably straight forward to add
things but all the later enhancements were kludges. It started with MIC-E,
which abused the destination call to convey data. But also strange
enhancements like the /A altitude flag en more such things that get added
to the comment field. It is human readable but so free-format that it is
hard to parse in a client.
For the end used again no problem, the client just has more code to filter
out the new bits and pieces - but at the end of the day the end user pays
the prise. Less functions fit into the client and more bugs creep in.
Coding resources are wasted on a complex parser instead of building new
functionality. Some programmers chose do not waste time on the complex
parser at your expense because their implementation breaks down at the next
addition or it crashes on mal-formed packets (and their cheap response it
to blame the new format instead of their own code).
So what you can say is, the long years with APRS lifted all the
requirements a good APRS system should have. In my vision APRS is a
prototype and proof of concept. Now that we know what it takes to make a
good APRS system, OpenTrack is the technical solution to get a sound
interface specification taking all the lessons learned into account. So we
go from a hacked-together prototype to an model that applies sound
engineering principles. Nothing strange with this, it happens in the
industry all the time.
This new protocol is engineered such way that it can co-exist with the
current APRS infrastructure. The current infrastructure has little problems
with OpenTrack and nothing that can't be fixed. The change needed to TNC
initialisation files is nothing different than the additional settings that
were required to enable MIC-E or to fix the ID/NoID issue. It is simple
known technology that has been applied many times before and hardly worth
to make a big fuzz about. The only difference this time is that Bob didn't
invent it.
The next step will be migration. First you will see dual-mode clients that
know both about APRS and OpenTrack. Besides that small trackers and devices
will appear that soly use OpenTrack to take advantage of the better
structure. I guess over the years more and more traffic will move to
OpenTrack and a client builder that is forced to make a choice what formats
too keep will opt more and more to kick out less-used APRS hacks first.
Meanwhile the struggle between APRS and OpenTrack will go on as long as Bob
is still convinced he has room to add more kluges and exotic extensions to
APRS, despite that his own program ran out of space long time ago to
implement it all.
There is still an evolutionary path; that is to start with APRS SPEC 2.0
and kick out all the obsolete formats, for example:
1) Only keep the most accurate compressed position format (despite that
base 91 calculation are hard to do in a PIC processor) and deprecate all
the others.
2) Only allow APRS type WX data and deprecate all the others.
But still, the room for improvement within APRS is limited. For example the
implementation of symbols is too simple and doesn't provide space for a lot
of symbols that some real-life applications need. Symbols in APRS are
a scarce resource, but despite that even here you find redundancy, for
example there are 2 ways to make a circled number...
I think APRS should be left what it is today and focus should be on the
next generation format, which will open a host of new applications and
possibility that can never be squeezed efficiently into APRS anymore.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: Battery questions
From: Doug Bade <doug@clecom.com>
Date: Sun, 06 Jun 2004 10:29:12 -0400
X-Message-Number: 25
At 02:35 AM 06/06/2004, you wrote:
snip....
>Anyway, I've got a ton of questionable UPS batteries around here (12 V, 7.5
>AH VRLA) constantly, and I've got two chargers. One's a smart
>charger/conditioner/maintainer with whiz-bang anti-sulfation features and
>such. But it refuses to do anything with a battery at less than 10.5 volts
>charge, so to get 'em started I've got the dumb 2-amp auto/marine deep cycle
>charger.
The smart charger probably recognizes that the cells are shorted
as it is unable to cause a rise in voltage which would be steady and
predictable on a normal battery. It is telling you they are bad.....because
the charge characteristics are abnormal... being a smart charger this is
quite likely..
A 2 amp charger will provide 2 amps or MORE to a battery. 2 amps
is normally at the float charge voltage, effectively when the battery is
full. In general you will toast a battery if you float charge it above 10%
of its rated AH, Nicad or Lead Acid/Gel Cells. Consequently sustained
charging of less than 20 AH batts with one will produce hot batteries, and
or toast them... sooner or later.
Most lead acid simple chargers are voltage controlled chargers,
somewhere about 14.5 under load. They will allow current values up to
winding capacity at lower voltages, meaning during discharged -recharge
conditions, lead acid batteries are much more tolerant of current while
they are in the heavily discharged condition, but as they charge their
voltage rises, and the current should drop to the float charge level at the
point the are full (~12.5 v +_ ) If you are float charging a 12v battery
shorted to 10 volts in all probability, with a 2 amp charger, you are
likely more than 2 amps and it is definitely becoming toast if it was not
already.
The fact it will not rise to 12 volts means it has shorted cells
already.
>Earlier today I checked on a battery connected to the dumb charger, and
>found it hot to the touch. I disconnected it of course, and now several
>hours later it's still warm. I can't imagine it's just held that heat this
>long. It's still registering around 10 volts.
>
>Is this a sign of a shorted cell? The battery's toast in any case, I've
>just never seen one do this.
As above, yes this is probably the case...the internals can absorb
a lot of heat in a shorted condition, in lead acid vented batteries,
hydrogen is boiled out, and could explode if open flame is present. Sealed
lead acid, gel cells or AGM batteries are used in risky environments, IE..
indoors...and even then they can blow vents if internal pressures rise too
high.
>Next question... the setup I'm using for my weather station test setup uses
>a couple of these 7.5 AH batteries. The batteries (as with the rest of my
>big deep cycle batteries) have a 50-amp Anderson single pole connector.
>Another single pole connector splits it out to 30-amp power poles. One goes
>to the load and one goes to a 5-watt solar panel with an internal blocking
>diode.
>
>I seem to remember hearing that this setup is allowable for panel sizes up
>to 10 watts or so. Is that correct? Does it start boiling off electrolyte
>after that?
10 watts at 14 volts is about 710 ma of current, this should be a
safe charge level for a sustained float charge of a 7.5 AH or higher gel
cell.. especially one with a continuous load... A series diode anode to
solar panel, cathode to battery is never a bad Idea unless you are
absolutely sure the solar panel has one.. one rated for 5 amps for most low
power solar cells should be fine. I think they are still available at radio
shack...
>Just for fun, I've now got the digipeater computer running off the big (84
>AH) battery, and a 5-watt panel. Not that that's going to help much, with
>the computer drawing up to 10 watts. Now, I've seen suggestions before on
>commercial solar charge controllers, but does anyone have a recommendation
>for a dual-mode charger? I'd like to set the thing to work off both a wall
>wart transformer and a solar panel.
I use Trace controllers like the C40 for site work for UPS
standby. We run a stack of AGM batteries and a 50 amp astron power supply
to charge the stack... The astron runs up to its current limit under heavy
tx load , and the batteries auto self load-feed as needed.. Float charge
adjustment level is absolutely critical to long term battery health.. to
much it boils off, even if slowly, and to little, they never fully charge.
Solar battery manufacturers publish float charge specs, following them is
good advice.
There are many good solar charge controllers .. the C40 is pretty
big ( capacity ) and versatile you can find others more suited to 10-15A
class lead acid/gel cells...
Doug KB8GVQ
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 10:45:47 -0400
X-Message-Number: 26
>>>Henk de Groot <henk.de.groot@hetnet.nl> 6/5/04 11:14:10 AM >>>
>1) No it is not. As Jeff clearly points out, the spec says APRS
>packets are to be transmitted with the PID of F0.
>
>Which means that all APRS applications should only
>accept packets with a PID of F0 since all the other
>packets are invalid for APRS.
Henk, the problem is the word "should". I dont know
how many times we have to go through this:
1) The spec was very clear in saying that APRS *TRANSMIT with a PID of F0
2) The authors of the spec and anyone with any experience over the last 22
year of AX.25 knew that it was IMPOSSIBLE to declare that APRS "should"
only RECEIVE same. Since the authors of the spec all KNEW that this is a
TNC function and the APRS spec was REQUIRED to only address APRS, and not
TNC's.
Hence, it was and remains impossible to put "should" receive only PID F0 in
the APRS spec. That is a TNC function and is outside of the realm of APRS
and out of the control of APRS!!!
Yes, "should" is one thing. But when it is outside of their control, it
was better to document what WORKS and was and remains common knowledge,
than to put in things like "should" which were impossible to control...
APRS was designed to work with what "is", not what "should be"...
Bob
----------------------------------------------------------------------
Subject: APRS in the field. Big step forward...
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 06 Jun 2004 10:50:52 -0400
X-Message-Number: 27
>>>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
----------------------------------------------------------------------
Subject: Re: The OpenTrac Debate and BS!
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Sun, 6 Jun 2004 10:56:35 -0400
X-Message-Number: 28
Gee Bob... And I am one of the first ones that are at the scene of
emergencies and I USE APRS during these events. I have actual field
experience and try to provide support to users out there and actually give
good information. What I wrote was not propaganda... Some of the things in
there were quotes from you, too! You know, you are correct... 90 to 95% of
ALL assets are hardware... But you need software to decode that hardware or
what are you doing? Having a hundred trackers out there sending out data
doesn't mean a thing if you don't have some software in there to decode it,
right??? Maybe I'm just looking at this wrong... But it seems to me that
there has been a lot of propaganda coming from you during this whole event.
73s,
Eric KF4OTN
kf4otn@amsat.org
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sun, 06 Jun 2004 17:49:10 +0200
X-Message-Number: 29
Hello Bob,
At 10:45 6-6-2004 -0400, Robert Bruninga wrote:
>Henk, the problem is the word "should". I dont know
>how many times we have to go through this:
>
>1) The spec was very clear in saying that APRS *TRANSMIT
> with a PID of F0
You can't control that either, you just throw data at the TNC and the TNC
knows when it is in converse mode to use Protocol-ID F0 for TEXT.
>2) The authors of the spec and anyone with any experience
>over the last 22 year of AX.25 knew that it was IMPOSSIBLE
>to declare that APRS "should" only RECEIVE same.
All TNC's know about the PID and as you may have noticed by now the monitor
of every TNC is either already are hard coded to parse only a PID of FO
(Kenwoods for example) or have an option to switch it on. This is logical
since the TNC already knows to transmit TEXT in CONVERSE mode with
Protocol-ID F0, so the complement of this would be to receive TEXT only to
avoid getting all kinds of binary junk in the conversation due to other
type of traffic.
The required change is not much different that adding the settings to allow
MIC-E to parse ASCII packets undamaged or to correct the ID/NOID setting;
those changes were never an issue, why make a big thing out of this?
I think your use of the word IMPOSSIBLE is just because it suits you in
this case. When operating a TNC in KISS you will get all the details of the
packet. But even if you want to stick to the beloved CONVERSE mode and
refuse to only listen to TEXT type protocol frames then you can still
enable tracing and get the packet in HEX. You can even receive OpenTrack
packets via your ASCII connection that way.
I have no idea what caused "the authors of the spec and anyone with any
expericience over the last 22 years" to declare that receiving a packet
with only a PID of F0 is IMPOSSIBLE. Most certainly they must have chosen
not to look at TCP/IP, APRP, NETROM and INP or any other binary protocol
over the last 22 years and also never took the time to read their TNC
manual all those years. It makes me wonder wat kind of experience you refer
to in this case. Most certainly you can't refer to experience with AX.25
technology and TNC's because in that context the statement is plain wrong
and could not have been uttered by somebody with experience in this field -
unless he/she was driven by other motives, unknown to me.
Of course I can't back it up, but I think you are bluffing and in fact the
question was never raised because it was obvious that packets with another
PID than 0F should never be parsed as APRS packets because they can't be
APRS packets. If not, then your experts may be experts in some field and
even hold a title or degree in that field, but thet are in that case most
certainly not experts on what you seem to imply.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: The OpenTrac Debate and BS!
From: db2fm <db2fm@jfsattv.de>
Date: Sun, 6 Jun 2004 17:50:49 +0200
X-Message-Number: 30
Am Sonntag, 06.06.04 um 03:13 Uhr schrieb Steve Dimse:
>On 6/5/04 at 7:42 PM Christensen, Eric <CHRISTENSENE@MAIL.ECU.EDU>
>sent:
>
>>What, exactly, needs to happen to get the APRS-WG back in operation?
>>
>The function of the APRS WG is to steward the APRS Spec. If someone
>outside the
>APRS WG has a change they wish to have made, they need to get someone
>within the
>APRS WG to champion the issue.
>
>The thing is, for better or worse, most people on the APRS WG place the
>integrity of the system first...there is strong emphasis on backwards
>compatibility. Since the spec was published, I do not recall seeing
>one proposal
>which I would have considered pressing enough to be worth the risk to
>the system.
There would't be backwards compatibility in using user defined data
either!
>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)
>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? You
can't be serious! What will happen is that there will be REAL problems on
the so called "working system", not this little thing that happenend mainly
by the excessive path used (not OpenTRAC itself) on a balloon some days
ago. I think that would really crash the "working system", which is in fact
an experimental radio service, which amateur radio is in the US, too,
AFAIK.
>The argument I see pressed most often from opentrack people is that the APRS
>spec is ugly, and their protocol is better designed and easier to
>parse. I admit
>I haven't looked closeely at it, it very well may be, but the fact is that
>unless you can upgrade everything in APRS simultaneously, adding parsing for
>their protocol worstens the parsing problem, as would any other attempt to
>modernize the system. No one I've talked to on the APRS WG has shown any
>interest in causing a period of upheaval that would affect all APRS users, for
>the benefit of making future programmer's lives easier.
>
>Despite the innuendo, no one is telling anyone they cannot experiment.
>All Bob,
>myself, and others are saying is that it is not appropriate to do this
>experimentation on top of a working system.
>
>And anyone that has a proposal for a change in the spec that cannot be
>accomodated by the user defined protocol needs to get someone on the
>APRS WG to
>sponsor the proposal...if you cannot get one person on your side, how
>can you expect to win a vote?
Nobody wants to become the new president, here ;)
>Steve K4HG
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. How could progress be made in such an environment? Every
programmer agrees, that parsing APRS is a nighmare and gets worth more and
more as new things are added. But nobody (of this circle of APRS-WG
members) likes the idea of changing anything fundamental.
Why not try the parallelity of both protocols as it happened accidentally
(without named problems - I didn't ever see an answer on the question "What
happened to you?" in the whole discussion, only repeating phrases ever and
ever again "It can be done in APRS! Why change?" May be because of the
parsing-nightmare???)?
The "accident" showed, that
- nothing serious happened
- the well-loved Kenwoods didn't have a problem (I also own a D-700,
using with an OpenTracker, as it doesn't do SmartBeaconing)
- only lock-ups of ONE SINGLE HH2 (because of a setting in it's TNC)
- both protocols can be used side by side on the same frequency
- every TNC, that is wrongly set up can be cured by just one command-line
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.
I proposed that a long time ago (not long enoug, sorry! I'm only 39
years old :).
And stop blaming people to not being here 1994 or 1999 or 1982 or whenever!
(I don't like to be blamed for things, that happened 60...70 years ago
or whenever!)
73 de Juergen DB2FM
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
