On 3/31/99 2:32 AM Jeff King ([EMAIL PROTECTED]) wrote:
>> In APRS, it is no big deal if a position packet gets
>> dropped...
>
>It *is* a big deal to me if a position report gets dropped. APRS
>should support some sort of fill method. Its clearly a shortcoming if
>it doesn't and leads me to believe APRS is a kludge, its not , is it?
>
I maintain it isn't a big deal, the next position report will get
through. If you must move data from point A to point B completely intact,
then you do need to use something other than APRS. That wasn't what it
was designed for. If you want to know where a certain station is at this
moment, there is a way to query them (a message to them with the contents
?APRS?).
No APRS isn't a kludge. It is hundreds of kludges tied together into a
working system. As I said before, if you could throw everything out and
start all over, you could to a lot of things better. But unless you hit
the lotto and are willing to share, it isn't likely to happen.
>>
>> >You might want to refer to some of the article written in PSR back in the
>> >later 80's, early 90's that went over some of these issues. Tom Clark wrote
>> >a number of them.
>> >
>> Please give me some specific references for papers dealing with
>> one-to-many networking, I'd love to read them!
>
>Well, that's not what I was referring to. I was referring to a series of
>papers
>dealing with level one and level two issues, but those apparently don't apply
>to APRS it seems.. So don't worry about them. You might want to
>look in the DCC papers of a few years ago as John Hansen did some stuff
>on multicasting.
>
Yes, I was there, I heard his paper. There is a similar system Bob wrote
last year called APRSnet that feeds the full internet APRS stream on a
9600 baud channel. Of course, since most hams are too cheap or unskilled
to make the leap to 9600, it hasn't caught on.
>>
>> >wouldn't affect your applications much). Just because the registered
>> >APRS authors do it a certain way doesn't mean innovation should be stifled.
>>
>> I don't see any innovation being stifled.
>
>Now hold on a minute. Didn't you just say in a message a bit ago to
>Bob Lorenzini that the APRS Gestapo tried to discourage you when
>you originally came out with APRServe?
>
Yes, but my innovation wasn't stiffled, was it?
>>
>> >
>> >So here are a few things I have considered for Amateur AVL (AAVL):
>> >
>> >A real addressable connection less protocol (to much overhead with AX.25)
>>
>> The whole point of APRS is that it isn't addressable. Everybody gets
>> everything. If I need to address who is going to see my position report,
>> then that is a very different system than the present APRS.
>
>Do you even bother to read what I am saying? Each APRS packet ALREADY
>has a address on it. Its called a callsign. But AX.25 is a connection
>orientated
>protocol. APRS has tried to convert it to a connectionless protocol by
>running
>it unproto (UA) mode. I'm talking about making a protocol more suited to what
>you are trying to do. You'd still be able to monitor everyone and also
>monitor
>a single user in real time.
>
So what exactly would you do different? I can monitor everyone now, and
by adjusting MacAPRS or javAPRS, I can monitor a single user. What is the
difference you are proposing?
>> >Simple FEC (so a PIC could deal with it)
>>
>> Sure, this would be nice. There are much better modulation methods than
>> AX-25. Of course, you are talking about replacing or upgrading many
>> thousands of TNCs.
>
>Least common denominator factor again, aye? Tough. This is supposed to
>be a technical hobby so I have no pity for those that want to remain in the
>backwaters. Just get out of my way.
>
I'm not standing in your way, I wish you nothing but the best. Clearly
I'm different that you, I am a pragmatist. If I'm going to spend hundreds
or thousands of hours developing something, I want it to be used by a lot
of people. I aim to make my systems as simple to the user as possible.
That is why all the internet routing of messages is completely
transparent to the user.
>>
>>
>> >Broadcast rate adjustable for speed (faster doing 60mph, slower doing
20mph)
>>
>> This can be done right now in the Pic-E, no need to wait for a new
>> protocol.
>
>I didn't see that in the code, I figured I'd have to write it. Glad someone
>already
>did it. Is in in Byron's or John's code?
>
I didn't say it was done, just that it can be done. Byon's code supresses
the null posits before the GPS locks on, and has a fall-back rate when
the velocity is below a few MPH. It would not be hard to extend that to
another tier at 20 MPH or whatever you wanted.
>> >A control channel (maybe 144.39??) to tell users about local lans and for
>> > handoffs for mobiles going between LAN's.
>> >Buffering POSITS received on the LAN channel to be sent in one
>> >transmission on
>> > the hand-off and/or backbone channel
>> >
>> What I see here are plans for a needlessly complex network.
>
>There is no RF network in place for APRS to speak of, other then a single
>frequency digipeater network. So of course, any suggestion to improve things
>will be meet with cries of "needlessly complex'. Been there, done that. They
>were wrong, you are also. Maybe not my way, but the APRS network is
>severely capacity limited (on RF) so I will be proved right. Read the book
>Steve.
>
Look, I'm not trying to send a message from New York to LA. I'm trying to
get the few dozen people nearest to me to see me, and to get my signal to
the nearest IGate. I'd honestly like to hear what you want from the
system, to see where we differ. There is no law that says a network needs
to use more than one frequency. That we can accomodate thousands of users
on a single frequency is proof it works.
>> You are
>> talking about multiple radios at every digi site,
>
>Yes, in certain cases. Its called a packet radio network.
>
Yes, and node stacks work because every packet going through them has a
route. It would break down if every packet coming in had to be sent out
all ports. This arrangement is what APRS uses. So my question to you is
how do you plan to filter and route APRS data?
>> Computer tunable mobile radios aren't common or cheap.
>
>They are very common. Most PLL chips today are addressable,
>either using SPI or I2C.
The chips are common, the radios are not. Name the 2 meter mobile radios
that can be tuned by computer. That is not to say that the manufacturers
wouldn't produce them if there was a demand, just as Kenwood did with the
Data HT. Telling people they have to buy a new radio isn't going to set
well with them!
>> >What I see happening with APRS on a single frequency is it being a victim
>> >of its own 'success', much as the BBS network on 145.01 was.
>>
>> IMHO, there is no area where there is a true shortage of bandwidth, those
>> areas that have congestion problems deal with it through peer pressure
>> promoting shorter unproto paths and longer transmit intervals.
>
>Your ADMITTING it is broken. I want reports every minute, I want DGPS
>correction data sent every 10 seconds.... I want to track a specific station
>WITHOUT losing a single POSIT. Can't do that, its broken, lets stop making
>excuses and consider fixing it. That is what I was suggesting.
>
Yes, there are areas with congestion. In South Florida there were far too
many WIDEs, one every 10 miles because without mountains we are forced to
use low buildings, many only 100-200 feet high. In order to get 40 miles,
we had to run 4 WIDEs in our path. That caused congestion, even with a
handlful of users. So, all the low digis got turned off, and a digi at
1000 feet was placed on a tower. Now we can run WIDE,WIDE, and get 150
miles. The channel now has lots of spare capacity, were aren't even using
half of it. Sure, if a couple hundred users suddenly joined the ranks,
there would be problems. That isn't gonna happen though.
Well, wait a minute. DGPS every 10 seconds. OK, that is about 15% of the
1200 baud channel load. Now a packet every minute from say 20 mobile
stations. OK, that is another 30 to 40%. Suppose you use full duplex, so
the digi can transmit all the time, and slot the mobile times so they
don't compete. You are not going to be able to support many users. Of
course, you could go to 9600 baud, but I'm sure you know that you don't
gain that much when you are talking about short data packets at 9600
baud. That's OK though, because there won't be many 9600 baud users
clamoring for bandwidth.
>
>>
>> stations. So there are lots of BandAids that can be used.
>
>NO NO NO NO, at least not on the LINUX ham's list. These guys can
>actually do it right. That's the beauty of open source, others can look at
>your
>code, critique it, fix it, patch it, make it better. The success of KA9Q NOS
>was mostly due to its open source nature. APRS is not this way and it clearly
>shows.
>
That is why Linux (in general, not just ham-Linux) so far has remained a
server tool and geek playground. More attention needs to be paid to the
average user's experience. You can sit here and perform mental
masterbation about how you can double and triple channel capacity, but if
it means spending $500, or holding a soldering iron, your system will go
largely unused. Like I said, I have a different focus, on the user. I
think it ain't cool unless people use it!
>I wonder if the developers of Pactor or AX.25 thought of this when they
>tried to change the mind of those RTTY guys. To a degree, there has to
>be a "Gateway" of sort, but for someone to transition, there has to be a
>clear advantage.
>
>> You will run into a lot of resistance if you tell all
>> 300-odd digi owners that they need to spend $1000 upgrading their system!
>
>I'm talking about stuff that can be done on the PIC-E . Mine cost me $49. You
>apparently paid to much for yours.
>
I'm talking about digi sites that have to add another radio, filters, and
antenna. Sure, you can scounge and build for a lot less, but sadly few
people are able to do this.
>> If you had a few tens of millions of dollars, and were designing a
>> nationwide tracking system, you certainly could do a much better job than
>> APRS.
>
>I never said that I wasn't amazed at what you and the other authors of APRS
>had accomplished. I am amazed and impressed. You are defensive about
>APRS, and seeing some of the comments on this list, I can understand why.
>I'm just suggesting, in a hopefully constructive way, you might want to
>occasionally step back and look at the underlying protocol of APRS,
>which frankly I don't think anyone has done that is in a "leadership"
>position in the so called APRS community. The PIC-E, coupled with
>the open source nature and resources of the Linux community is a good
>opportunity for this to happen. Don't be closed to this.
>
Look, I'm no fan of the protocol. Bob and I get into
knock-down-drag-out's about it. When I got involved I started the move to
simplifying things, using the first character of a packet to identify the
type so they could be parsed easily. Bob continues to sabotage the effort
by adding lots of special cases, which I abhor. I would love to trash the
whole thing and do it right.
The problem is that from practical standpoint you just can't do that.
There are too many people involved in APRS to start over. We still get
people who whine because they are using a 6 year old version of APRSdos,
and it isn't working right because the protocol changes. There are almost
a thousand owners of the Kenwood HTs that would need to upgrade. There
are more than a thousand users of the Mic-E and MIM that would need to
upgrade. How many thousands of TNC's?
The APRS authors are pragmatists like me. They aren't going to be willing
to disrupt the user experience just to make the protocol more elegant or
cooler. Any such major overhaul would need to add some major improvements
in functionality to justify itself. If you think your ideas can promise
this, then I urge you to present them.
As to my alleged aversion to open source, there are two things you need
to know. The Pic-E was initially designed to be a cheap, simple
alternative to the Mic-E. It was my idea to open it up to other
developers. One of the things you have to promise to become an "official
APRS software author" is never to release your source code. I resigned
that lofty title so that I can release the source of my Pic-E weather
encoder and XMLserve. So you are preaching to the choir...
Steve K4HG
