On 4/5/99 12:53 PM Jeff King ([EMAIL PROTECTED]) wrote:
>
>
>Steve Dimse K4HG wrote:
>
>>
>> >Well, what is wrong with my attitude? Just because I won't cut hams a break
>> >that won't LEARN the technology. So what? Hey, its not like I
>> >am on the APRSSIG user list doing this so cut me a break.
>> >
>> I didn't say there was anything wrong with it. You just keep changing
>> your position. It was to show vaccilation, not pomposity, that I quoted
>> you. One message you say screw the average Joe Ham, the next message you
>> say you want to make something that they can use. You are free to take
>> either position, it doesn't matter to me, but pick one. Which is it?
>
>As you quoted me out of context, you'll see what you want to see. I made
>my position clear enough, not that it matters to you as you said. Even so,
>I didn't see any vacillation at all in the quotes you cited from me. Thats
>exactly why I called them pompous on my part. You appear to be seeing
>what you want to see.
>
Well, OK. Maybe I'm just dense. I don't understand your position, so if
you don't mind, perhaps you can make it clear for me. You want to design
a better network for transport of tracking data. What is more important
to you...a system that the average ham can set up their mobile trackers
and digis cheaply and easily, or a more complex system that requires
multiple radios or dual band radios, perhaps surgery to the radios, but
one that is elegant to you and your elite peers?
>>
>> >Is it such a crime to think it could evolve? Better or complex does not
mean
>> >it has to cost more or be hard to use. I have a duplex spread spectrum
radio
>>
>> Perhaps it could evolve, perhaps it could be better. I definitely admit
>> the possibility exists. I know I'm not the one to do it, and I'm
>> pesimistic about your, or anyone else's, ability to do it.
>
>Recall this conversation, at least on my part, started with the suggestion
>that the APRS author's should pay more attention to the lower (rf)
>layers of APRS. I still stand by this opinion.
>
If I understand what you mean, you are talking about the use of AX-25,
rather than developing some other means for transmitting the data. As you
love to point out, APRS is an applcation. A person decides to write
application level programs because they are interested in doing that
rather than designing a new low level communications protocol. When Bob
designed APRS, AX-25 had a big advantage over any other digital
communication mode. It was available then, and it was cheap. It still has
that advantage. It works as well as it needs to in this application. So
I'm not saying that it isn't possible to design a better means, only that
unless there is a perceived need that is greater than the trouble in
implementing it, people will not use it.
>> I've said, and
>> I truly mean it, prove me wrong. I'm just really getting bored of
>> theoretical discussion. Prove me wrong and earn gloating rights if you
>> can!
>
>Maybe this is the problem with the APRS transport level..... the authors have
>a short attention span and get "bored" talking about the theory of packet
>radio?
>
You could look at it that way. As I said, the people that have
self-selected to write application do it because they like it. Regardless
of what you think about Bob, he would have made more money flipping
burgers these last 7 years than he has gotten from APRS. They all have a
hundred things on their lists of enhancements they want to do. Why should
they spend their time doing something they don't want to do. That is like
me saying that you do not spend enough time thinking about XMLserve. If
you have other things you are more interested in, good for you!
I return to my theme. Build something that serves the needs of APRS users
better than the present system, that isn't too much trouble to them, and
they will use it. Though there are a lot of places where I think the APRS
authors have over-controlled the system, the RF side is not one of them.
There has always been room there for innovation. But don't expect the
authors to take the lead...
>BTW, you done very little discussion and mostly arguing and claiming
>everything
>I propose is to complicated for the APRS ham. This isn't what I was hoping
>for. I was hoping to have a opened minded technical discussion with one of
>the authors of the APRS program.
>
Well, I'm a pragmatist. I hear a lot of ideas, some simpler than others,
but they share one thing in common. They are not yet solutions. What all
the APRS authors need is a conduit to transmit ASCII data. There are lots
of other things that we would rather do. That isn't a character flaw!
>> >BTW, I remember when you were first writing the
>> >APRServe I suggested you look at the convers code on NOS. You hadn't
>> >even heard of this and apparently didn't even bother. It's fine with me
>> >if you constantly want to reinvent the wheel, but don't call it "talk"
when
>I
>> >cite the large amount of prior art that exists for this field and you chose
>> >to ignore it.
>> >
>> >From what you told me at the time I knew it wasn't going to be the
>> simplest, most reliable way to implement my plans. I was designing an
>> internet based client/server system, so I wrote one using my own TCP/IP
>> connections. Sure, I could have added NOS to the server (and which would
>> in turn do the TCP/IP connections), but it would have been slower, less
>> reliable, and more complex to implement.
>
>You don't recall the conversation then. I never suggested you add NOS to your
>server. Your aprserve is basically a "chat" server. I just suggested you
>take a
>already documented, open source "chat server" (the conversd daemon) and
>use that to start with. You didn't want to, thats history and your choice.
>
APRServe was never just a chat server. There are a number of functions
like duplicate filtering, buffering, position parsing, and web serving,
that are in no chat servers I know of. Like I said, I could have used NOS
and built on modules to accomplish all this, but it is NOT the simplest,
most efficient, most reliable method to accomplish what I wanted. Why
can't you accept that?
>
>> >
>> No. What I say is all this prior art can't be merged into a system that
>> is better for the APRS user, or the digi owner, than exists now. I'll be
>> happy to have you prove me wrong. But for God's sake, stop talking and
>> get on with it!
>
>Oh bullshit. APRS is still packet radio no matter how much you want to
>argue about it. Prior art means the stuff has already been
>implemented and/or proven. So there is nothing to "get on with" as it has
>already been gotten on. Just not by the APRS folks. I was just suggesting
>that you would be well served by educating yourself in these areas.
>
And again, APRS is not just like other packet radio. But lets just drop
it, OK. Neither of us will ever convince the other.
>
>> I don't want prior art,
>
>Well, then you are condemned a life of re-inventing the wheel. I wish
>you luck. Of course, I was talking about prior art which could be applied
>to the APRS application (RF lower layers) of which there is a great deal.
>
You took that right out of context, didn't even quote the enire sentence.
What I'm saying here is I don't want a theoretical discussion of prior
work, which despite your protestations to the contrary, I don't feel
apply. What I want is proof that you can do better.
>Anyways, to sum things up for those that are still with us, these are
>some suggestions, in my opinion, that might make APRS more reliable:
>
>1. APRS is a broadcast protocol (no end to end acks). It would benefit
>greatly with some sort of FEC on the end user terminals. PIC-E could
>be a start here.
>
I agree it would be nice. I wish it had been part of the AX-25 spec.
Trouble is, adding means a wole lot of upheaval in the present network.
It would be nice for someone to develop this, get it put into TNC ROMs or
write PIC code to do it. And eventually it could reach critical mass...
>2. Compress the reports (like MIC-E, except more widespread)
>
This has already been added to the protocol. Before we use it to transmit
we have to put it in the programs as a recieve capability for a few
months. We know we need to use long lead times from prior bad experiences.
>3. High digi's would benefit from a "busy tone", especially near metro areas.
>As a side benefit, DGPS data could be overlaid on this.
>
Well, since everyone using this system would need to add an additional
receiver to their station, I'd maintain this would not be perceived by
the users to be worthwhile. Still it would be a neat use of the Pic-E,
and I'd love to see someone do it.
Steve K4HG
