Block Recovery Protocol (pdf) - Güralp Systems Ltd
Block Recovery Protocol (pdf) - Güralp Systems Ltd
Block Recovery Protocol (pdf) - Güralp Systems Ltd
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Specification<br />
2 Transmission of data<br />
2.1 GCF blocks<br />
Each transmitted GCF block is pepended with a 4-byte header, shown in table<br />
2.1. The header contains an identifier for synchronising the start of the block, a<br />
sequence number (these are assigned by the transmitter and will increase sequentially,<br />
wrapping from 255 to 0), and the size of the packet. The packet size is in<br />
bytes and may be less than 1024 if there were any unused bytes after the RIC.<br />
Most receivers will want to discard a header (or assume it is terminal data) if the<br />
size is greater than 1024 bytes.<br />
Immediately following the header is the data block itself, truncated to the block<br />
size listed in the header. After the block a 16-bit checksum is sent. The checksum<br />
is computed by finding the sum of all the bytes in the header and data packet and<br />
discarding all but the lowest 16 bits. The remainder is transmitted in network<br />
byte order. The whole transmission is summarised in table 2.2.<br />
2.2 ACK and NAK<br />
After each transmitted block, the transmitter will wait up to n milliseconds (n is<br />
sometimes referred to as the “MS_GAP” setting) for a valid ACK or NAK signal<br />
before transmitting the next block. On receiving a valid ACK block, the transmitter<br />
assumes that the block has been successfully received and will not retransmit<br />
it later. On receiving a valid NAK block, the transmitter can be rewound to an-<br />
15<br />
8 7<br />
Identifier: 0x47: ‘G’<br />
Sequence number<br />
<strong>Block</strong> size (network byte order)<br />
0<br />
Table 2.1: GCF block BRP header.<br />
September 27, 2008 5