[aprssig] 9600 APRS

[Wayne Sanderson]

I can see how a data burst with a rapid update on the text screen of a
D7/D700/D710, HamHud, etc, would diminish the experience for those who watch
that. I am more of a map screen watcher while driving, at first years ago on
a Garmin GPS III+, later an E-Trex Legend, and now on an AvMap G5. The data
burst would have the opposite effect on my G5- It would zip new positions to
the GPS for the screen objects quickly, and clear up the channel for non
routine position packets, such as text messaging and such...

And maybe there is little or no text traffic nowadays not only because of
the dumb trackers but because of a lack of interest. Maybe we are jaded and
just a bit bored. Something new and useful from the old rig might generate a
bit of interest. 9600 UHF APRS and some neat-o features like what the NWAPRS
guys in the Seattle area have cooked up might be just the ticket.



> Date: Thu,  2 Apr 2009 00:03:50 -0400 (EDT)
> From: "Bob Bruninga " <bruninga at usna.edu>
> Subject: Re: [aprssig] 9600 APRS
> To: TAPR APRS Mailing List <aprssig at tapr.org>
> Message-ID: <20090402000350.AJJ39793 at mp3.nettest.usna.edu>
> Content-Type: text/plain; charset=us-ascii
>
> > My increasing involvement in Emergency Management...
> > has gotten me back into APRS with a vengeance,
> > and my Kenwood rigs are running hot.
>
> I hope that doesn't mean you are flooding the channel with 1 minute
> position rates 24/7...
>
> > The newer rigs will run 9600 APRS,
> > but there is no 9600 network for them.
>
> Actually all of the APRS rigs going back to he introduction of the D7 in
> 1998 will run APRS at 9600.
>
> > ... the capacity of the channel is as much
> > as eight times that of 144.39 because of
> > the speed increase.
>
> Unfortunately, I think it has been shown that the effective throughput will
> only about double because there is fixed overhead.  But your idea to bundle
> packets is a very good way to improve throughput... BUT...
>
> But a lot of the value of APRS in the mobile is seeing the new info from
> the latest packet flash on your screen without having to move your fingers
> or hands from the wheel and without having to do anything.  This flash of
> info lasts 10 seconds whcih is about right for a 1200 baud channel operating
> at the Aloha limit.
>
> If you fire-hose the channel with  4 times the data throughput (by bundling
> and going to 9600 baud), then only one of every 4 stations will get flashed
> on the mobile's screen, and the other 3 will not be seen.  Personally, I'd
> rather see everyone around me reliably, than 4 times as much spam from out
> of area that is hidden from view that I have to go look for, by searching
> through the lists of captured packets.
>
> Again, your idea of bundling to improve throughput has merrit.  Ive looked
> for applications of it for years....  but if you acccept the fact that APRS
> is supposed to be a real-time information distribution and display system
> for mobiles, then it should only be applied to info that no one needs to see
> in real time.  And if local real-time info is in that category of no worth
> looking at, then why is it being transmitted on the local info channel?
>
> About the only thing that fits this category is MESSAGES, since they will
> flash special alerts when they come in anyway to the recepient only, and
> those that are not addressed will not see them.  So they can be dumped at a
> high rate without any disadvantages...  But the problem there is, that there
> are too many trackers driving around and hardly anyone is messaging.  SO
> messaging remains a very small piece of APRS.
>
> Though I think it could revolutionize amateur radio if we would just tie
> all of the dozens of amateur radio text messaging systems into APRS
> seamlessly.  See
>
> www.aprs.org/aprs-messaging.html
>
> Now that would be worth doing!  Both BUNDLING and 9600 baud!
>
> Bob, WB4APR
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20090402/3c5b171d/attachment.html>