May I be permited to speak?
As a relative newcomer to APRS here in Manahattan, I can see that it has
its place in the order of ham radio activities.
There is just one thing that bothers me though; when is all the fighting
going to stop and when will someone do something usefull with it?
Here in Manhattan I have started a APRServe thing using Dales aprsd but
as yet I'm unable to do anything usefull with the data under Linux as
there is no client end.
As for DGPS, why aren't we using the same qrg for it as aprs (I may have
missed the explanation for this)? DGPS is available over the net and
people like me and Dale have access to it without too much hassle. Why
can it not be made available via something like aprsd (sorry Dale, I'm
not taking a pop at you)?
Mark Phillips, G7LTT/KC2ENI
>From: Steve Dimse K4HG <[EMAIL PROTECTED]>
>To: "Jeff King" <[EMAIL PROTECTED]>
>CC: <[EMAIL PROTECTED]>
>Subject: Re: APRS for Linux?
>Date: Mon, 5 Apr 1999 03:40:26 -0400
>
>On 4/5/99 1:53 AM Jeff King ([EMAIL PROTECTED]) wrote:
>
>>Steve Dimse K4HG wrote:
>>>
>>> >So what is wrong with making something that is both technically
sound
>>> >*AND* that the average ham can use? You know, they are not mutually
>>> >exclusive.
>>>
>>> Nothing is wrong with that, but that isn't the attitude you have
>>> expressed over the last week:
>>
>>(examples of my pompous attitude deleted)
>>
>>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 I have stated on a number of occasions, the authors of the
various
>>> >APRS flavors should put some consideration into the transport
layer.
>>>
>>> I think this is a bit harsh. Bob, Kantronics, PacComm, and others
have
>>> put a lot of thought into the "network" design.
>>
>>Well, you basically said this yourself already. BTW, I never mentioned
>>PacComm or Kantronics so I don't know why you are bring this up.
>>
>I'm talking about WIDEn-n, callsign substitution, and other features
they
>have added to the TNC's for APRS "networking".
>
>>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. 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!
>
>>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.
>
>>> >I don't think this has been done. If they don't wish to do this,
then they
>>> >shouldn't stand in the way, or attempt to suppress the efforts of
those
>>> >that in good faith wish to improve things.
>>> >
>>> I haven't seen or heard anyone suppressing or standing in the way of
any
>>> transport layer development. But then, I haven't seen any working
>>> systems. A lot of talk the last week, but talk is cheap. If you
produce
>>> something that works, and it gets unfairly trashed by someone, then
you
>>> have a reason to complain. But to throw out a bunch of ideas and
expect
>>> people to adopt a technology that doesn't yet exist is a little
>>> unrealistic, don't you think?
>>
>>Of course it would be unrealistic. Problem is, the so called "new"
ideas have
>>been around since the 70's and 80's and many hams have already
implemented
>>them. You only need look around or read some of the papers that have
>>been published. 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.
>>
>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!
>
>>> I would love to see you or someone else come up with something
better
>>> than exists now. I just don't think you can do it without requiring
more
>>> time, money, and skill than hams are willing and able to expend.
Please,
>>> prove me wrong! (Hint...words aren't going to prove it, at least to
me!)
>>
>>OK, so
>>tell me what "better" means to you, and then I will consider taking
you
>>up on your challenge or find the prior art that backs up my "words". I
>>already
>>have something in mind, but it seems we have different realities of
"better".
>>(see the DGPS/BUSY tone suggestion above)
>>
>I don't think there is anything that needs to be fixed. You are the one
>convinced it is horrible and needs to be redone. I don't want prior
art,
>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. They are the ones that
>ought to judge if your system is "better", and if so if it is better
>enough to justify any additional complexity and cost. God bless the
Free
>Market and Alan Greenspan!
>
>>
>>> >What would be involved in supporting it would be disclosing the
APRServe
>>> >protocol
>>> >
>>> There is no separate protocol for APRServe. It is simply lines of
text as
>>> they come out of the TNC's, the usual APRS format packets that the
client
>>> programs already understand. KISS...
>>
>>> discussion. I spent a long time with Dale going over the inner
workings
>>> of APRServe so that his program was fully compatible, as he includes
the
>>> bidirectional messaging and filtering functions of APRServe which
are not
>>> particularly easy to understand.
>>
>>OK great, so this is documented somewhere?
>
>Yes, there are a number of documents on my web site that discuss the
>filtering algorithms and the third party messaging. Also see my paper
in
>the 97 DCC procedings.
>
>>I'd guess your using a token
>>server of some sort for the third party messaging.
>>
>Actually not. APRServe is designed to be redundant. You can take down
>either of the two (three if I ever get around to it) primary servers
and
>the other(s) take up the load without any intervention. The client
>programs even switch servers automatically. A token server would
increase
>the complexity. I move the transmit decision outward to each IGate. The
>full time ones are connected to both servers, so there is no lag if one
>goes down. Each incoming packet is checked to see if it is a message or
>position report that should go out on the local RF net, and transmits
it
>if needed.
>>
>>> However if your data is not compatible, then it is better placed on
>>> another server.
>>
>>At the level of the server, there is no reason for it not to be
compatible.
>>I've been discussing RF networking, hidden terminals and other lower
>>layer RF transport issues. I'd hazard to guess your server isn't even
>>compatible
>>at this level with real APRS. It requires a PAD between it and the RF
medium
>>at a minimum.
>>
>Forgive (or in your case, rejoice in) my ignorance, what does PAD stand
>for?
>
>It requires a TNC and radio. Those damn twisted pairs on the eithernet
>cable just don't radiate RF effectively enough to have them feed
directly
>from the internet to RF ;-). The TNC is connected directly to the IGate
>computers, no additional hardware is needed.
>
>Steve K4HG
Get Your Private, Free Email at http://www.hotmail.com
