[aprssig] 9600 APRS

Thu Apr 2 23:15:36 EDT 2009

I've got to weigh in on this....

1) bundling packets: I thought about this at one time years ago, and folks
like Stephen Smith are correct.  It will lead to hyper jump issues.  What is
supposed to make aprs work is the fact that DWAIT is supposed to be set to 0
on all digipeaters so that we can have fracticide.  In other words, if three
digis hear my mobile they should all digipeat me at the same exact time.  My
packet then moves outward in "waves" or "ripples".  If DWAIT is not set to
0, then each digi hearing my packet will hesitate.  When they hesitate, they
may hear one of the other digis transmitting my packet and wait even
longer.  In the worst case each of three digi's would wait for the others to
finish and my packet took 3 "slots" to be propagated by 3 digi's.  If DWAIT
is set to 0, my packet takes 1 time slot to be transmitted by all three
neighboring digis simultaneously.  The "fix 14439" "no relay" change we made
5 years ago provided us more of a gain in bandwidth than this proposed
bundling will.  Another imporant overlooked parameter is TXD.  Especially on
digipeaters, please check your TXD.  I'll bet most digi's are set to the
default of 500ms (TXD 50), but most modern rigs can run TXD of 120 to 150ms
(TXD 12, or TXD 15).  We can gain nearly 300ms of "breathing room" on each
packet a digi transmits if the digi owners would adjust the TXD correctly.

2) 9600 baud.  Not as sure here,  but given that the main mobile rig the
d700 can't adjust txd, switching to 9k6 shortens a packet from 800ms to
540ms.  Big friggin deal.  If we had fast turn around radios and could get
the TXd's down in the 30 to 50ms range, it might be worth the effort.  Or if
we transmitted 1500byte ethernet frames at 9600, it might be worth the
effort.  I played with 9k6 6 or 7 years ago (with Jason ke4nyv in VA) and
had trouble getting a thd7 to be heard reliably from one side of a room to
the other using a paccomm spirit 9600 tnc for RX.  I know the deviation was
right on the thd7 and I was hooked to the disc out on the tm733 radio used
for RX.  Through the good graces of a local repeater owner, we were able to
hook the 9k6 rx TNC to the disc out of the repeater receiver and "harvest"
mic-e packets at 9600... On the one hand it was great b/c with 9600, you
don't have to mute the packet racket on the voice channel, but it was less
than reliable.  FWIW, I connected the spirit 9600 TNC with a crossover cable
to a kpc3 at 9600 baud serial.  both TNCs in KISS mode, whatever the paccomm
TNC heard the KPC transmitted on 144.39 at 1200 baud.  At least that part
worked great.  And for you armchair lawyers, yes that does not permit the
kpc3 to ID, so I had cwid turned on.  Not optimal for 144.39, but it was a
relatively short test.  If I had kept the rig running longer I would have
make a PIC processor that injected a KISS id frame every 10 minutes into the
kpc3 serially.

Wes
---
Where there's silence, there is no Hope.

2009/4/2 Wayne Sanderson <whsander at gmail.com>

> 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
>>
>>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20090402/5502efe8/attachment.html>