Block Recovery Protocol (pdf) - Güralp Systems Ltd

Block Recovery Protocol
Transmission of GCF over Serial
Specification
Part No. SWA-RFC-BRPR
Designed and manufactured by
Güralp Systems Limited
3 Midas House, Calleva Park
Aldermaston RG7 8EA
England
Proprietary Notice: The information in this manual
is propriety to Güralp Systems Limited and may not be
copied or distributed outside the approved recipient’s
organisation without the approval of Güralp Systems
Limited. Güralp System Limited shall not be liable for
technical or editorial errors or omissions made herein,
nor for incidental or consequential damages resulting
from the furnishing, performance or usage of this
material.
Issue B September 27, 2008

Block Recovery Protocol — Transmission of GCF over Serial
Contents
Contents 2
1 Introduction 3
2 Transmission of data 5
2.1 GCF blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 ACK and NAK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 ACK packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 ACK commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 NAK packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Other considerations 9
3.1 Terminal passthrough . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Real-time status . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 SWA-RFC-BRPR — Issue B

Specification
1 Introduction
Güralp instruments that communicate via a serial stream (e.g. the DM24 and
the CD24), either over RS232 or via a TCP/IP to serial converter, will use block
recovery protocol. This is a transport layer that allows for efficient use of the
available bandwidth (GCF packets which are not ‘full’ are truncated) and for a
degree of error detection and missing block recovery.
The BRP transmitter prepends a small 4-byte header to each data block that is
transmitted, and appends a 16 bit checksum (see section 2). It may also transmit
real-time status blocks, which provide information about the current time, i.e.
UTC (see section 3.2).
The BRP receiver can send a 6-byte ACK/NAK block for flow control. An ACK
will allow the next block to be transmitted as soon as it is available; a NAK allows
for the transmission to be ‘rewound’ to a previous block. There is also a small set
of commands available to the receiver to initiate terminal passthrough (section
3.1), etc.
September 27, 2008 3

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

Block Recovery Protocol — Transmission of GCF over Serial
Start block: ‘G’
Length
GCF block
Sequence number
❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤
❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤❤
Checksum
Table 2.2: GCF block transmission.
other point in the sequence 1 . If neither signal is received, the transmitter will
generally store the unacknowledged blocks in some sort of memory until they
can be transmitted later.
2.3 ACK packets
The format of a valid ACK packet is shown in table 2.3. The ACK packet is
tied to the last block received by the stream ID, which is transmitted in little
endian format 2 . Note that this should be the stream ID of the last block received,
regardless of whether that block was out of sequence, or corrupted (in which
case the stream ID might be wrong; but this simply means that the ACK will be
ignored by the transmitter).
The ‘Ctrl’ bit is set to 0 if a control code is used (see table 2.4 below), or 1 if a
control code is not used, in which case the ACK packet is further tied to the block
1 Unfortunately, some BRP transmitters have modes where, due to the implementation,
rewinding does not work (e.g. CMG-DM24mk3 in adaptive mode). There is no way for the
receiver to detect this. In such a mode, the receiver should NAK blocks that have corrupt checksums,
but it should not pay attention to the sequence numbers. Otherwise, there will be suboptimal
behaviour as the receiver continues to try to rewind but the transmitter does not perform
this — although no data should be lost, transmission bandwidth will be wasted. This could be
implemented as an option that the user must explicity activate in the receiver.
2 An earlier version of serial link protocol used only the first two bytes of the ACK/NAK
packet. It was only deemed necessary to use the least siginificant byte of the stream ID, since that
would capture the tap and component information. Once BRP was introduced, this packet was
extended in a backward-compatible manner, leading to the strange layout of bytes.
6 SWA-RFC-BRPR — Issue B

Specification
15
14
13 12 11 10
ACK byte: 0x01
9
8
7
6
5 4 3 2
Stream ID LSB
1
0
Ctrl
Sequence ID
Stream ID MSB, little-endian
Table 2.3: ACK packet layout.
Control code Description Digitisers
0x00 Acknowledge, ignore sequence number All
0x13 (^S) Break in to command mode All
0x54 (‘T’) Initiate software trigger CD24
Table 2.4: Control codes that may be used in BRP ACK packets.
by least significant 7 bits of the sequence number. For example, if the transmitter’s
last block was sequence number 0x67, the receiver would ACK it with 0xE7 in
byte 2 of its ACK packet. If the ACK of the previous packet (0xE6) was delayed,
the transmitter would not match the sequence number and would discard the
delayed ACK packet.
2.4 ACK commands
In addition to simply acknowledging correctly received blocks, the ACK packet
can be used to send some special commands. These are detailed in table 2.4. A
special code of 0 will cause the digitiser to accept the ACK packet as long as
the stream ID matches (i.e. the block sequence number is ignored 3 ). To request
terminal passthrough mode on the digitiser, a control code of 0x13 (byte 2 as
0x13) is sent. The CD24 digitiser firmware also recognises a control code of 0x54
to initiate a software trigger.
2.5 NAK packets
Finally, the format of a NAK packet is shown below. The NAK packet contains
a field which tells the transmitter which block sequence number to rewind to.
3 This method of acknowledgement was widely used until later versions of the CD24 and
DM24 firmware. However, the new method of sending the sequence byte with the top bit set is
backwards compatible with the old firmware so it should be used by any new receiver software.
September 27, 2008 7

Block Recovery Protocol — Transmission of GCF over Serial
On receipt of a valid NAK packet, the transmitter should rewind to the given
sequence number and begin transmitting from there (but see earlier note about
certain digitisers and certain modes).
15
14
13
12
11
10
NAK byte: 0x02
Rewind sequence ID
9
8
Stream ID MSB, little-endian
7
6
5
4
Stream ID LSB
3
2
1
0
8 SWA-RFC-BRPR — Issue B

Specification
3 Other considerations
3.1 Terminal passthrough
BRP receivers may request terminal passthrough by transmitting a lone ^S character
(ASCII code 19), or by sending a specially-formulated ACK packet (preferred
method; see section 2.4). If the transmitter is not currently transmitting, a single
^S should be sent; otherwise, the receiver should wait for its next ACK packet
before requesting BRP mode. This avoids incompatible behaviour between the
CD24 and the DM24 1 , and avoids a long wait if no packets are currently being
transmitted.
There is no clear indicator of when passthrough mode has been activated. The
CMG-DCM receiver code currently assumes passthrough mode is activated when
it has requested passthrough and it receives bytes that do not belong to a block
transmission (table 2.2).
The terminal passthrough should time out after some seconds if there is no activity
on the link. This should be enforced by the BRP transmitter. The receiver may
end the link at any time by sending a ‘GO’ command (this is actually transmitterspecific,
but all current known transmitters implement GO, although there may be
other commands for other situations). The transmitter should send the sequence
0x1B 0x11 to signify it has exited passthrough mode.
3.2 Real-time status
Due to a design flaw, the CMG-DCM mk2x hardware does not contain a realtime
clock module. The CMG-EAM hardware does, but the clock must be synchronised
somehow. The DCM must attempt to retrieve its time from the connected
digitisers. This process is not easy — only status packets can be used, because
1 The CMG-CD24 always honours ^S characters, whereas the CMG-DM24 may ignore them
if it is busy transmitting a packet.
September 27, 2008 9

Block Recovery Protocol — Transmission of GCF over Serial
15
Packet identifier: 0x67: ‘g’
14 13 12 11 10 9 8 7 6 5
4
3
2
1
0
FracLock
GCF day
GCF seconds
(Optional) Fraction of second
Table 3.1: Real-time status packet.
there is no (unmeasurable) filtering delay, but even so there is a variable transmission
delay and status packets may not be frequent; moreover, in any mode
other than direct, packets can be delayed by arbitrary amounts so their timestamps
do not correspond to the real time.
To counter this problem, the real-time status packet has been introduced. This is
a very small packet that is transmitted on the second, every second (where possible).
If the digitiser is busy transmitting when the second boundary is crossed, the
real-time status packet is inhibited to avoid inaccuracy. The layout of the packet
is shown in table 3.1.
The current lock status is transmitted by setting bit ‘Lock’ to 1 if the clock is
locked to a time source, or to 0 if not. The time itself is transmitted in GCF
format: number of days elapsed since 1989-11-17 and number of seconds elapsed
since midnight of that day. Note this accurately represents leap seconds.
In some implementations (e.g. the CMG-CD24), the packet may not be transmitted
exactly on the second boundary but at some fraction of a second later. As long
as the time at which it is transmitted is known, the fractional time bit (‘Frac’) may
be set to indicate the packet contains an extra two bytes with the fractional second
offset. This offset is unsigned, in network byte order, and has units of 1/40000
seconds.
10 SWA-RFC-BRPR — Issue B