Well, OK, I will try here. Excuse the tart attitude but it is late.
Steve Dimse wrote:
>
> >Shades of 145.01, and this is a *technically* sound network design? Hey,
>
> Yes, it is a sound design, for this application. If we were supporting a
> bunch of BBSes and users, it would not be. The one-to-many paradigm of
> APRS is different.
OK. My mistake. I didn't realize that level one and level two issues didn't apply
to APRS.
>
>
> Yes, I believe that the APRS network on a single frequency is sound. This
> isn't a theoretical opinion.
That's clear to me.
> There are many hundreds of APRS digis, now
> virtually all on 144.39, and it works well!
And 12 jurors thought O.J. was innocent. So what.
> would say putting it on a single frequency would indeed be unsound. APRS
> isn't BBS!
Right. But its still packet radio, or do you want to argue this also?
> >> APRS is completely different from a BBS system.
> >
> >The underlay issues are EXACTLY the same. Your explaining a application
> >to me, this is a level one through level 3-4 issue. At best, the APRS
> >'network'
> >appears as a pure aloha implementation, much as the 145.01mhz bbs network
> >appeared. Channel effiencecies are very poor when heavily loaded. This
> >is not good network design.
> >
> I disagree, the issues are not the same.
Then you simply don't understand the basics of packet radio system
design. I suggest you pick up the text "Packet Radio" by TAB books
by ve2py and ve2ben. It has some good basic theory in it, discussing
in detail hidden terminals and the different methods used to improve
channel efficiency.
> In a BBS system, there are one
> or a few users connected to a BBS. Each packet must be received intact,
> and is of little or no interest to other users. One user's data is
> another's QRM.
Thanks for the lesson on how bbs's work in your area. However, you
might want to check out modern NOS system's, PacSat's, DX clusters
as well as Packet Web all which use forms of multicasting or have
client programs that work with them that can take advantage of
multicasting.
> 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?
>
> >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.
>
> >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?
>
> >
> >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.
> >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.
>
>
> >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?
> >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.
> You are
> talking about multiple radios at every digi site,
Yes, in certain cases. Its called a packet radio network.
> and two radios in every
> tracked vehicle, one for control and another tunable at the command of
> the control station, or perhaps alternate the radio between the control
> and local freq.
No need for two radios on a vehicle, although it would be nice.
> Computer tunable mobile radios aren't common or cheap.
They are very common. Most PLL chips today are addressable,
either using SPI or I2C. If I design an AVL network, I don't design
for the ham that still wants to use his two'er. I design it for the
best performance. The arguments you are making are quite familiar
to me and have historically held back packet radio.... I have to upgrade
my radio to run 9600bps, I'll need to run my computer full time to use
NOS, I don't want to put two ports on my network node.... it goes
on. Your either design a system for best performance or you design
for the lowest common denominator.
>
> Sounds like you are going after a gnat with a cruise missle. It'll work,
> and it'll make a really cool bang, but sometimes simple is better.
Yeah, ok. Whatever. A simple two port network node is a "cruise missile"..
guess I better not tell you about my 6 port NOS switch then or you'll have
the AEC on my case.
> >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.
>
> 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.
> >You can either keep
> >applying the band aids or consider some of those issues now.
> >
> Well, I'm willing to discuss any of your ideas.
Thanks.
> I'd maintain though that
> anything that would be successful needs to be compatible with what is
> already out there.
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.
> 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.
-Jeff
