[aprssig] Bufferless KISS TNCs ?
sv2agw at raag.org
Tue Nov 10 12:16:49 EST 2009
There is already the XKISS and smack KISS mode. Packet Engine Supports it
and you can test it easily.
(SV2AGW) George Rossopoulos
> -----Original Message-----
> From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On
> Behalf Of Wes Johnston, AI4PX
> Sent: Tuesday, November 10, 2009 4:21 PM
> To: TAPR APRS Mailing List
> Subject: Re: [aprssig] Bufferless KISS TNCs ?
> 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?
> 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:
> 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
> God help those who do not help themselves.
More information about the aprssig