[aprssig] Bufferless KISS TNCs ?

[Wes Johnston, AI4PX]

I don't really see an advantage of it on the receive side.  Several years
ago when µprocessors did not have the memory they do now, it was not
possible to do a 1024 byte frame, but now, I can't see a reason to not
buffer a packet in the TNC until error checking is finished.  Since this is
the aprs sig and not a TCP/IP sig, I'll say that buffering the longest APRS
packet (unicode messaging, right? ;-] ) is going to keep packet lengths to
255 bytes or less, which a low end modern µP can easily handle.

One of the irritating things about KISS tncs on the TX side is that they
will queue up outbound packets and the host has no way to force TX.  This
means that packets can sit in a queue for sometimes many seconds.  This
makes fracticide not work (as discussed last week or the week before).
If you want real time rx bits from the TNC and you want control of the TX
timing, why not use the German 6pack TNC?

Wes


On Tue, Nov 10, 2009 at 05:53, Matti Aarnio <oh2mqk at sral.fi> wrote:

>
> I have thought about ways to make new better TNCs, possibly with
> less resources in TNC than currently, yet providing better access
> to radio channel for a host with the real smarts in them.
>
> I wrote up a story about it at:
>
>   http://wiki.ham.fi/Bufferless_TNC
>
> Can anybody say, if this scheme would not work?
> (Besides of the disadvantages already mentioned there.)
>
>
> 73 de Matti, OH2MQK
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>



-- 
Wes
---
God help those who do not help themselves.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20091110/8016473f/attachment.html>