For users of the spiffy SCS Tracker DSP TNC in connected mode be forewarned the current version (as of January 17, 2018) of the instruction manual contains a serious oversight.
The T1 (FRACK) parameter
Possible parameters: 1…15000
„Frack“ is the maximum waiting time between the transmission of a packet and the confirmation by the distant station. (Afterwards a request back will be sent). With “The Firmware“ Frack is implemented as a dynamic “Round Trip Timer“ which adapts to the actual channel activities. The value set with the F-command serves as the start value for the automatism.
The time can be entered directly in seconds. With entries < 16 the value will be multiplied with 100 and then divided by 2. Entries > 15 are directly interpreted as milliseconds (L2-„Round Trip Time“).
Taken literally the default value of 500 yields a FRACK value of half a second… far too short for practical packet use in connected mode. Indeed during our testing we did assume the F value was in units of milliseconds and set it to 5000 intending a five second noACK resend time. We puzzled why the retries were coming about 50-55 seconds, hence causing long pauses in the normal AX.25 flow. We thought the manual was the final word on the topic so looked elsewhere for resolution.
Finally we came to our senses and simply questioned the accuracy of the manual. We dared to assume F is really in 10ms increments and set it to 700. Sure enough the delays observed during testing were about 7 seconds. We changed it to 1400. The delays were now about 14 seconds. Eureka! The manual was the smoking gun.
That default value of 500 is actually a good default setting for a five second FRACK value and should have been a clue to us earlier. Oh well.
Response from SCS
As usual the response from my contact at SCS is 100% wonderful. Expect a revised manual soon on this and other typos we found.
Apparently the FRACK value in their higher end Pactor products is in milliseconds. This likely explains what happened when the Tracker came along later. The Tracker manual has all the characteristics of a hastily put together publication so it appears the FRACK paragraph was just copied verbatim. It happens.
It seems SCS carries on the tradition of AX.25’s less than stellar documentation quality. Even TAPR’s AX.25 standard contains typos (i.e. search for “188.8.131.52”) along with TAPR’s almost bizarre prose. Kudos to everyone who actually gets AX.25 code running on new platforms.
SCS’s scorecard is still quite good. Documentation isn’t the primary reason I purchase quality gear, but it sure helps when it is correct. In time I’m sure it will be.