Steve Dimse K4HG wrote:
>
> >anything I stated? Everything I stated or expanded upon in my last
> >message is basic packet radio stuff that was published in the 70's and 80's.
> >
> Complex here is relative to the APRS system currently used. Virtually any
> ham can put up a digi or install a tracker as they are currently
> implemented in APRS.
Why couldn't they do this in a different system? Just as the "hams" that are
presently
putting up your APRS digi's don't write the firmware/software for the
system, they wouldn't write it for some of the ideas that were tossed about.
Your comparing apples to oranges. Granted, someone has to start, just
as they did with ax.25, but ultimately if something worked better then it
would reach the level of plug and player's.
> Complex means a system where ther user has to go into a radio, and solder
> a PIC onto the PLL chip.
Yeap, but that wasn't in my last message. The first guys that built TNC's (in the
U.S.) had to know 6502 assembly (alpha board) but things then evolved
from there.
> Complex is 9600/440 digi stacked with a 1200/2m.
You've been the only one talking about 9600bps, not me. If you keep you message
size short, this is of limited value. Anyways, you likely could find some network
type hams that have already mastered 9600bps and have a system in place you
could hang your aprs node off of.
>
> Complex is a mobile that listens on 440 for dgps and busy tones and then
> transmits on 2 meters.
Oh please, cut me a break. You really are hanging around the wrong kind of
people.
Almost everyone I know has a dual band HT. The system I suggested (DPGS
corrections multiplexed with a busy tone on a separate 440 system) would offer
a order of magnitude improvement for channel throughput while AT THE SAME
TIME giving a powerful tool to your users (real time DGPS). A simple PIC-E at
the end user station could both decode the DGPS, feed it to the GPS and multiplex
the busy tone CD with the standard CD from the TNC.
This type of system is best implemented on a high digi, much like you have there
in Miami. You don't believe me, try it. You'll be able to get into that digi alot
better with your HT at the fringes and reduce collisions. And the beauty of it
is its cheap to do. I only suggested multiplexing it with DGPS (which you don't
need to do) to give the users a "hook" to buy into it (they might care less about
"busy tones" but they will buy into DGPS).
I tell you what, if I code something up like this on a PIC-E, will this
qualify as one of your "betters" that you cite? (see below)
>
> >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.
>
>
> >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.
> Yes, it is a single
> frequency and that disqualifies it from being called a network in your
> opinion.
I think I said it could be implemented and applied more properly. It
is a network, so if I said it wasn't, I was wrong.
> Yes, it operates at a different layer than you would use,
And most anyone else that knows what they are doing....
> but it
> uses technology that already existed. The goal was to produce a system
> that had good enough functionality, and still was cheap and easy. It
> wasn't to produce the best possible system regardless of complexity or
> cost.
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
in my pocket that is much simpler to use then most HT's, and cost's less
money. Its called a PCS cell phone. Steve, you have something in your
shack called a PIC-E, it costs less then most TNC's and can implement
some/most of the PAD functions I have talked about. Granted, most of your
end users couldn't write the code for it but that's OK. Only one person
need do that, and then your end user's could use that.
> >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.
> 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)
> >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? I'd guess your using a token
server of some sort for the third party messaging.
> 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.
-Jeff
