<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META name=GENERATOR content="MSHTML 8.00.6001.19019"></HEAD>
<BODY><FONT COLOR=BLACK><FONT COLOR=BLACK>
<DIV><SPAN class=082435810-28022011><FONT color=#0000ff size=2 face=Arial>I've
been looking at 9600 operation for a while, and it concerns me that the spectrum
efficiency is so poor; with 150ms TxDelays being used to send a 35ms packet of
data seems to be utterly ridiculous. I've been working on marine AIS systems for
nearly 10 years, and while I admit that its design could be significantly
improved, at least it only needs 26ms to send a total of 168bits of data - the
Txdelay being essentially 24bits of preamble before the start flag (about 3ms)
plus the 8 bits of PA ramp timing (1ms). Why is there an order of magnitude
difference in the two systems which are otherwise, very
similar?</FONT></SPAN></DIV>
<DIV> </DIV>
<P><FONT size=2 face=Arial>Derek Love, Applied Technology UK</FONT> <BR><FONT
size=2 face=Arial>+44 1749 881130</FONT> </P>
<BLOCKQUOTE>
<DIV dir=ltr class=OutlookMessageHeader align=left><FONT size=2
face=Tahoma>-----Original Message-----<BR><B>From:</B> Wes Johnston, AI4PX
[mailto:wes@ai4px.com]<BR><B>Sent:</B> 28 February 2011 01:42<BR><B>To:</B>
ml41782; TAPR APRS Mailing List<BR><B>Subject:</B> Re: [aprssig] 9600
APRS<BR><BR></FONT></DIV>
<DIV>Yes, many new rigs are 9k6 ready, but they still have horrendous
txdelays. Kantronics did make a good little dataradio years ago that had
something on the order of 40ms (???) txdelay. And we can
really appreciate 9k6 for longer TCP type packets... packets >200
bytes. But for our little onsie twosie packets of 30 to 50 bytes, it's
just not worth the effort.</DIV>
<DIV> </DIV>
<DIV>Moving an aprs digipeater to 440 would be great, 1200 baud sure.
What would be cool would be to have 144.39 and a 70cm frequency bridged at
1200 so that it didn't matter which freq you used, you'd see everything on
your local digi on either frequency. The purpose of this would be to
allow mobiles to run 70cm when they used 2m voice or vice versa.</DIV>
<DIV> </DIV>
<DIV>Skipping right along, on Bob's random text files from years ago, one
really stuck with me. It was running data output on the input frequency
of a repeater. This would be prefect for 9k6 distribution of weather
products. Thing is that today many voice repeaters have COR gated PL
tone outputs. So we could transmit 9k6 on the output of the repeater
with no PL tone for HOURS. Think of all the time that a given repeater
is inactive thru the day. Of course once a voice user started on the
repeater, the data would pause. Now if the voice users run PL tone
decoders, they'd never know it was there! If they didn't run PL decode,
they'd hear quiet static, not annoying BRAAAAPPPPS. Now what data would
you put on that?</DIV>
<DIV><BR clear=all>Wes </DIV>
<DIV>---</DIV>
<DIV>"Language shapes the way we think, and determines what we can think
about." -- B. L. Whorf</DIV><BR><BR><BR>
<DIV class=gmail_quote>On Sun, Feb 27, 2011 at 09:30, ml41782 <SPAN
dir=ltr><<A
href="mailto:ml41782@yahoo.com">ml41782@yahoo.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE
style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex"
class=gmail_quote>
<DIV>
<DIV
style="FONT-FAMILY: arial, helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10pt">
<DIV>Original MSG </DIV>
<DIV>This is a savings of 27ms. based on his numbers. I have
seen numbers shorter and longer than 150ms for keyup. This doesn't
sound like alot of savings but every little bit helps.</DIV>
<DIV> </DIV>
<DIV>9600 on VHF ? I have never really seen this work on even on
packet</DIV>
<P>I have seen 2400 & 4800 on VHF but a true 9600 no because of
bandwidth restrictions.
</P></DIV></DIV></BLOCKQUOTE></DIV></BLOCKQUOTE><BR><P><FONT size=2>Registered Office- Oval Park. Hatfield Road. Langford. Maldon. CM9 6WG<BR>Registered in England and Wales. Registered No. 02847065. VAT No. 368 6007 36</FONT></P></BODY></HTML>