[aprssig] Re: D7 Flow Control

Wes Johnston aprs at kd4rdb.com
Fri Jan 7 21:01:54 EST 2005


I see the problem....
A TNC in conv mode prepends path and control/framing characters to each packet. 
If I were to send a continuous stream of 9600 baud data at a TNC and that TNC
was in conv mode, I would soon overflow the TNC's input buffer as it got
further and further behind b/c it was adding 10 to 20 characters to each
packet.

On the other hand, if I run my TNC in kiss mode the TNC actually strips two or
more (if you count the transposed character flags and the FEND characters) from
the raw serial stream.  In this case, the host can never overrun the TNC...
assuming the TNC goes ahead on air and sends the packets.

Alas, the overhead you are refering to Bill also occurs at 1200... with the same
% penalty.  10 to 20 bytes of overhead for path and control bits is 10 or 20
bytes no matter what the baud rate is.

The thing that stinks about 9k6 is that darned 100mS TXD.  I want to send 32
bytes in a mic-e packet... a cool .25 second at 1200 baud... but it takes
.25sec plus the 100ms TX delay... now we're up to .35 sec to send a packet.  At
9k6, it takes .03125 seconds to send the raw data, but you have to add the SAME
txd of .1 sec... so a posit report at 1200 takes .35, at 9k6 it takes .131 sec,
only 1/3 as long as the 1200 version... the 100ms txdelay in the radio blew it
for us.   But once the radio is on air, you can keep sending packet after
packet at 9600 and in the long run it will work out to just under 8 times
faster than 1200.... if you can bunch enough packets together to whittle away
at the TXD insertion average.  Just make sure the TNC is in KISS mode so that
the TNC stays ahead of the host sending the data.

Wes
--



Quoting Bill Vodall <wa7nwp at jnos.org>:

>
>
>
> > >>> wa7nwp at jnos.org 1/6/05 9:36:53 PM >>>
> > >Flow control on RF is another part of the problem.
> > >Packets at 9k6 come in too fast for the unit to handle them.
> >
> > Well, I hate to see blanket statements like that without
> > qualification.  It would be better to say:
> >
> > On systems not designed for the overhead of AX.25 on RF,
> > and the application, "packets at 9k6 can come in too fast
> > for the unit to handle them."
> >
> > Would be a better statment I think.  As long as the designer
> > recognizes that continuous data at 9600 baud on an AX.25
> > packet system can actually produce data throughput rates
> > as high as 19,200 baud or higher and designs accordingly,
> > then they will work just fine.
> >
> > 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...
>
>
> 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.
>
> If somebody puts a 9600 baud label on something, shouldn't it
> work at 9600?
>
> Bill
>
>
> Bill
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>





More information about the aprssig mailing list