SCS PTC-IIex, Manual

Page: 160 / 220

10 Hostmode
loaded
.
This is due to the overflow of (sometimes non-existant) buffers and also
timing problems on the RS-232 interface itself.
The CRC-Hostmode solves all these problems in that every Hostmode data packet has a
highly secure integrated CRC check sequence included. Errors can therefore be easily
detected. The CRC-Hostmode
protocol also allows the request for and the automatic re-
transmission of packets recognized as containing errors.
10.8.1 Extended CRC-hostmode
The command JHOST5 enables the extended CRC-Hostmode. This is compatible to
JHOST4, but allows data packets to be transferred with a lengh of max 1024 bytes on the
FAX-channel 252 in the direction PTC to PC. The added 2 length bits are bit 4 and bit 5
of the code-byte.
JHOST5 especially enhances weather FAX receiption with the use of the Bluetooth
interface by compensating the probably occuring higher latency time. Certainly, also with
the use of the USB or RS232 interface the FAX receiption timing becomes less critical
with the use of JHOST5. (With slower PC’s, the probability of “gaps“ in received pictures
decreases.)
10.8.2 Basic principles
The term send packet or receive packet has nothing to do with the data actually
transmitted or received via the HF link. They concern themselves only with data present
on the RS-232 interface. The # character means Binary byte .
The protocol is based on the extended Hostmode . A number of data packets are built up
according to this sub-protocol.
The HOST (PC) is, as in WA8DED mode, the MASTER. That means that every action is
initiated by the PC. The TNC/PTC (SLAVE) may never send data with-out being first
requested by the PC.
For every action by the MASTER, exactly one reaction from the SLAVE must follow.
The Master must wait for this reaction before it starts any other new action. There is of
course, a timeout allowed for this waiting time (see below).
Every WA8DED data packet is expanded by a (unique) header, consisting of #170 -
#170.
Every WA8DED data packet is completed by the addition of two CRC data-bytes
(binary). The CRC is calculated exactly according to the CCITT-CRC16, and is thus
identical to that used for PR and PACTOR. The CRC is calculated from the first byte
after the #170 - #170 header (channel number). (CRC see AX.25-protocol and example
in the chapter
10.8.8 , page 150 ).
Directly before the transmission, thus at the lowest sub-protocol level, the data packet
transmitter (MASTER and SLAVE) carries out so-called Byte-Stuffing. This prevents the
#170 - #170 sequence from appearing within a packet.
The Byte-stuffing takes place directly after the 1st byte after the #170 - #170 header, and
ends after the second CRC-byte. It therefore ranges over the complete packet (excepting
the header). Also, even when the second CRC-byte has the value #170, this changes due
146