[aprssig] Re: D7 Flow Control

Robert Bruninga bruninga at usna.edu
Fri Jan 7 14:10:22 EST 2005


>> Like anything else, the system has to be "designed", not
>> just grab somethig with a 9600 baud label on it and hook
>> it up.... and then wonder why it doesnt work...

>>> wa7nwp at jnos.org 1/7/05 12:46:02 PM >>>
> I stand by my statement.   The packets on RF are coming in at
>9600.  That includes all the overhead and control bits.  Actual
>data is going to be something like 3/4 of the raw 9600 bit rate,
>not twice that.

I was speaking of the 9600 baud data at the source.  So it 
seems that we are in violent agreement.   
we both agree that the bits get expanded by a large factor on the
RF channel.  In fact, a typical D7 or D700 MIC-E formatted
packet actually gets doubled or tripled in actual number of bits
depending on the PATH selected.

A lot of the "problem" that people run into when trying to use
the D7 and D700 in a 9600 baud system is the lack of depth
on the buffers to handle the overhead.   For example, the
initial "proplem" with using these radios on the 9600 baud
satellites was simply solved by changing the driving software
parameter from 256 byte length packets to something under
about 200.  (though most people play it safe at 128)...

Again, its not necessarily the fault of the radio.  Its just
that they do have these well known buffer limitations and
the knowledgible designer who intends to support users
of these radios should take into account this small buffer
size.. and the other small nuances I elaborated on the
SUPER-SITE web page...

Lets just get on with using them and expanding APRS
for 9600 baud backbones and RF SUPER-LANs where 
it can be done easily....

Bob





More information about the aprssig mailing list