Epson manual MFJ-1278B MULTI-MODE Advanced Operation

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