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.
>
> >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.
> 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?
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.
> >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.
> >
> 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.
>
> I don't think there is anything that needs to be fixed.
OK, well then I have obviously been wasting my time talking with you.
I thought since you admitted APRS was a collection of 100's of kludges
in a earlier message you might want to talk about this in a broader sense.
> You are the one
> convinced it is horrible and needs to be redone.
Yes, it could be done better. "Horrible" is your choice of words, I
don't feel that strongly about it. I understand the history of it and
why things were done the way they were.
>
> 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.
>
> the needs of APRS users are different than others ham radio has
> confronted. The challenge is for you to design and build an APRS RF
> network that is accepted by the APRS community.
These are two separate tasks. One technical, one political. If you are an
example of the APRS community, then I believe whoever does this
will fail politically. But then again, you did call it a challenge and I guess
for a very good reason.
> Forgive (or in your case, rejoice in) my ignorance, what does PAD stand
> for?
PAD stands for packet assembler/disassembler. TNC could have been used
in the context, but PAD was more well suited. I didn't explain it as it was
a fairly common term in the FADCA newletter at one time which I assumed
you might have been getting in the past.
BTW, can your attitude. I've got no problem with you asking a question,
I certainly have asked them of you. I don't think you need to be so
defensive about APRS and can be more opened minded.
-Jeff
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.
2. Compress the reports (like MIC-E, except more widespread)
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.
There is of course more, but this stuff is fairly easy to do.
