[aprssig] 9600 APRS

[Bill Vodall WA7NWP]

I use the Seattle 9600 system nearly exclusively.   A combination of
the 9600 - UHF characteristics  (shorter range thus more cellular and
quicker packets for less collisions) plus the lack of alligator
trackers (big mouth - no ears) makes 9600 work far better then the
local 1200 baud system.

>> 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...

On an independent 9600 system - that wouldn't matter.   It wouldn't be
useful but it also wouldn't hurt.

>
>> 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.

Upgraded D7(G) does 9600 very well.    Original D7 will only if used
as a TNC and not with the built in APRS.

>> ... 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.

Partially true.   The overhead reduction hasn't kept up with the 8x
speed improvement but the mere double of performance only applies to
the far from optimum fixed TXD of 500 MS on the D700.   D7(G) and D710
both have adjustable TXD which works well at 200 MS.

> 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.

There has to be a choice if this 9600 is going to be a 'backbone'
network or a user network.   Bundling would be good for a backbone or
feed network.   If it's to be a user centric network, then the sparse
activity is essential.   We had a misdirected experiment clog the 9600
network here with all the regional traffic and that made the system
unusable.

> 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,

Satellite positions, quakes and out of area stations (we see it when
Bob goes for a drive) are also interesting on the local 9600 user lan.
  Coming real soon now is traffic conditions and certain bus locations
as well as some Twitter info...


> 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.

I doubt the APRS-IS would handle the massive traffic that a real IM
system would generate.  APRS should indeed be part of such a system.

> Now that would be worth doing!  Both BUNDLING and 9600 baud!

It's all worth doing...

> Bob, WB4APR