Filter
Top Products
MFJ-1278B MULTI-MODE ADVANCED OPERATION
Once the FRACK timer times out, even if the ACK finally makes it through before the MFJ-
1278B sends the retry, the MFJ-1278B sends the original packet anyway. This obviously
wastes much time that could be better used clearing the channel of some of the legitimate
offered load.
It is this feature of the current AX.25 protocol that accounts for most of the abysmally poor
performance of the currently popular NETROM and THENET nodes when are used as omni-
directional single channel (or even multi-channel if there is more than a single other node on
each channel) systems. It should be noted that these node chips CAN handle point to point
links to a single other node perfectly adequately.
The prioritized ACK protocol avoids the above problems by giving ACKs priority access to
the channel. It does this in such a way that even ACKs coming from hidden terminals are
protected from collision.
The current protocol gives a limited version of this priority access only to digipeated frames.
Although it will be possible to support digipeating in a compatible (with the new protocol)
fashion, compatible digipeating support was not an objective that was addressed in this
release.
Ack prioritization works with slotted channel access in the following way:
1. Response frames (ACKs) are always sent immediately with no time delays unrelated to
hardware limitations applied. Ultimately, not even DCD will be checked for sending an
ACK. However, in this release DCD will still hold an ACK off the channel.
2. Stations queued up to access the channel but waiting for a channel busy condition (DCD
true) to clear, will start a slotted access procedure only AFTER enough time for a
response frame to clear the channel has transpired (weather or not the response frame is
detectable by the queued up station).
3. Slot time windows are selected to be large enough that the local TNC will be able to
unambiguously determine whether any other detectable station has selected any slot,
preceding the slot selected by the local TNC.
This is to prevent two TNCs which have selected adjacent slots from colliding.
As you can see, under this protocol there will never be a condition where an ACK is delayed
from being sent beyond the FRACK timer limitation. In fact, the FRACK timer becomes
relatively meaningless in this context. However, in the current firmware release, The
FRACK timer is still active and must be set to a value that is long enough to allow time for
PACLEN + ACKWAIT to expire before FRACK does. This time will depend on the radio