MFJ-1270C/1274C MANUAL ADVANCED OPERATION
Page 90
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 ACKWAIT to expire
before FRACK does. This time will depend on the radio baud rate in use. The
TNC knows that if it doesn't see the ACK immediately when expected, it is never
going to see it. See discussion of new parameters below for definition of
ACKWAIT.
Enforcing a channel access delay for all stations on the channel for whom the
packet that caused the queue was not intended (& who therefore aren't going to
ACK it) allows even ACKs from hidden terminals to get back to the expecting
station. This clears that traffic from the offered load list. If the packet was
indeed copied and ACKed, further retrys of the same information will not be
necessary.
New Parameters
There are several new parameters that relate to this modification of the protocol.
They are as follows:
