2 Background information

The existing Mark~III data buffer has one megabit (i.e.~128~kilobytes) of RAM. It can be used to capture raw bit data coming out of the Mark~III decoder NRZ decoding logic (before actual decoding of Mark~III formats). The Mark~III decoder also provides an external ``SYNC'' signal that starts the capturing process. This signal is synchronized to 10-second changes of formatter time. One megabit of Mark~III data means 46 full formatter frames 22500~bits each, resulting in 116~ms of captured data at the sampling rate of 8~MHz (9~MHz including the parity bits). The captured tape playback (or formatter bypass) data can be used to:

1. Extract injected phase calibration signal from the data stream to:
   • Detect phase differences between different channels.
   • Detect the relative amplitude of phase calibration signal present in the data stream to:
     • Check (or perhaps help in adjusting) the level of phase calibration signal to be the agreed amount of the overall level. (3--10% in voltage, 0.1--1% in power.)
     • Deduce system temperature by using the relative (known) level of phase calibration signal much in the same way as a level change caused by a switchable (known-level) noise diode.
2. Detect multiple calibration tones which occur at multiples of 1~MHz (with wider bandwidth VC channels, 2--16~MHz) and use these to perform all the calibrations presented in the previous item for one channel also for all tones across a single channel.
3. Capture data at a given UTC moment to be stored and later used in ``real-time'' fringe tests.
4. Duplicate some of the features of the Mark~III decoder in host computer software. This can be useful for:
   • Providing support for VLBA and Mark~IV formats which the original Mark~III decoder cannot decode.
   • Double-checking if the results of decoding Mark~III formats with the hardware decoder and decoding software agree, to detect hardware problems in decoder/data buffer (and software problems in decoding software!)
5. It may be possible to Fourier transform the sampled bit stream to see the spectrum of appropriate test signals such as pulse cal tones and/or LO output of the ``Test'' VC. The resulting ``spectrum analyzer'' can hardly match stand-alone devices in other ways, but it can be operated without human intervention, to scan all VC and all channels.

The current 9600 baud RS232 interface requires at least approximately (128*1024*10/9600) = 136~seconds to send the contents of the whole buffer over to the host computer. Because the ``SYNC'' pulses occur at UTC 10-second intervals and the buffer contents could be reloaded at the maximum of this rate, we would like to be able to download a bufferful of data in the order of 1--15~seconds.

The basic idea behind this upgrade was to come up with something requiring a relatively small effort which can still improve the download rate significantly.

The bidirectional serial interface of the data buffer is presented in Mark~III drawing 6004-005, found in the data buffer section of the Mark~III VLBI ``Blue Binder.'' An ``S1883'' UART chip is used to accept one-character ASCII commands from the host computer and to transmit raw 8-bit binary responses back to host.

The UART chip is clocked with its own baud rate clock, ``BCLK'', independent of the data buffer system clock, ``UCLK'', found on page 2 of the schematics. An UART (if it will tolerate this) can be driven with a clock rate that results in the baud rate of 115200~baud, customarily referred to as ``115~kbaud.''

This baud rate is the maximum that the ordinary PC serial ports and Linux serial drivers can support. To prevent incoming characters to be lost due to missed interrupts, a serial port with an 16550A FIFO-buffered UART is required. The TAG~PCs (and new SWT PCs) have such a port as ``COM2:'' and the DigiBoard ports should also be usable as continuous parity/speed changes are not required. Linux serial drivers can support even serial cards with 16550A UARTs with nonstandard baud rate clocks. The most useful replacement might be to replace the standard 1.8432~MHz (=16x115200) crystal with a 24.576~MHz one. This is said to be supported by 16550A chips, resulting in rates like 1~536~000, 768~000, 512~000 bits/s. Unfortunately the rates 115200 and 57600 cannot be attained with this crystal, but all the standard rates including 38400 baud and below can be used.

The new 115200 baud RS232 interface requires at least approximately (128*1024*10/115200) = 11.4~seconds to send the contents of the whole buffer over to the host computer. It may well take slightly longer due to software overhead---on the other hand, the amount of transferred data could be slightly reduced from the whole buffer contents to accommodate one transfer in the 10-second retrigger period of the data buffer.

The UART chip is used in the original Mark~III data buffer design to separate host computer interface timing and data buffer internal hardware sequencer timing from each other.

The incoming ASCII characters are presented on the bus ``RBR1--8'' (see the schematics 6004-005) and a new character is signified by the raising edge of a ``DR'', Data Request, pulse. The UART keeps the latest character received on the bus until the acknowledgement line ``/DRR'', Data Request Reset, is pulled down. Actually, the data buffer circuitry seems to rely on that the latest character stays on the bus until a new one replaces it: the logic continues to ``execute'' the latest command character received and if it is replaced on the bus, the logic will continue to function as if it were given a new command.

When the execution logic starts to download buffer contents to the host computer, it will load subsequent bytes into the UART bus ``TBR1--8'' by pulling ``/TBBL'', Transmit Buffer Bus Load, repeatedly low. The logic will wait, however, for the acknowledge line ``TBRE'', Transmit Buffer Empty, to go up before trying to send another byte. So, the UART can control the data rate by raising ``TBRE'' only after it is ready for another byte. The data buffer sequencer logic places an upper limit to the rate at which data bytes can be loaded to the UART. The logic functions at the cycle rate of ``UCLK'', 1.6~μs i.e. 600~kHz and it takes something like 6--10 cycles to load another data byte, i.e. 60--100~kilobytes per second is the maximum output rate attainable with the original sequencer logic.

You will need a suitable cable to connect the data buffer to the FS PC ``COM2:''. You most probably already have a suitable cable for D25 connectors, but if you are unsure of the connections in the current cable or you are going to use a D9 serial port, you can find suitable cable pinouts below.

An ``off-the-shelf'' computer-to-modem RS232 cable should be compatible with the data buffer, that is a cable which connects perhaps all 25 but at least the following lines (1, 11, 18, 22 are not used at the PC end, they are included just to show the lines connected in data buffer, schematics 6004-076, I/O Cables):

PC                female DB25 --- DB25 m/f?  Data buffer
TxD   Transmit Data         2  -> 2       Data in
RxD   Receive Data          3 <-  3       Data out
RTS   Request To Send       4  -> 4       (RTS, not used)
CTS   Clear To Send         5 <-  5       Clear To Send (+12V)
DSR   Data Set Ready        6 <-  6       Data Set Ready (+12V)
DCD   Carrier Detect        8 <-  8       Carrier Detect (unused)
GND   Signal Ground         7 --- 7       GND   Signal Ground
DTR   Data Terminal Ready  20 --> 20      Data Terminal Ready (sensed)
                            1 -?- 1       (protective ground)
      unused               11 <-  11      (On-line status, +12V)
      unused               18 <-  18      (Dial initiate, -12V)
RI    Ring Indicator       22 <-  22      (Ring indicator,  unused)


Alternatively, a IBM PC 9-pin serial connector DB9-DB25 modem cable
(or a "dongle" that provides these crossovers) can be used:

PC                 female DB9     DB25 m/f?  Data buffer
DCD   Carrier Detect        1 <-  8       Carrier Detect (unused)
RxD   Receive Data          2 <-  3       Data out
TxD   Transmit Data         3  -> 2       Data in
DTR   Data Terminal Ready   4  -> 20      Data Terminal Ready (sensed)
GND   Signal Ground         5 --- 7       GND   Signal Ground
DSR   Data Set Ready        6 <-  6       Data Set Ready (+12V)
RTS   Request To Send       7  -> 4       (RTS, not used)
CTS   Clear To Send         8 <-  5       Clear To Send (+12V)
RI   Ring Indicator         9 <-  22      (Ring indicator,  unused)

If a suitable cable is not available ready-made and a new cable is decided to be built, the following minimal connections should do the trick. Note that to enable hardware flow control (that is the ``RTS'' signal on PC inhibiting further incoming characters from the data buffer) these cables must be used. Linux expects serial port devices to behave like modems. Modems do not sense ``DTR'' line to decide if they can transmit more characters to the computer: if ``DTR'' drops low, this is an indication to the modem that the computer (or terminal) connected to it has been switched off and the modem connection should be broken. (This is how RS232 describes these signals and their function with modems.) The confusion arises because there are many serial devices such as printers out there that use ``DTR'' to signify that they cannot accept more characters. The Mark~III data buffer was designed to be connected to a computer that is designed to communicate with these non-standard RS232 devices.

PC                female DB25 --- DB25 m/f?  Data buffer
TxD   Transmit Data         2  -> 2       Data in
RxD   Receive Data          3 <-  3       Data out
RTS   Request To Send       4  -> 20      Data Terminal Ready (sensed)
CTS   Clear To Send         5 <-  5       Clear To Send (+12V)
                            | (wire for 5 or 6)
DSR   Data Set Ready        6 <-  6       Data Set Ready (+12V)
                            |
DCD   Carrier Detect        8     8       Carrier Detect (unused)
GND   Signal Ground         7 --- 7       GND   Signal Ground
DTR   Data Terminal Ready  20
                            1 -?- 1       (protective ground)
                                  4       (RTS, not used)
                                  11      (On-line status, +12V)
                                  18      (Dial initiate, -12V)
                                  22      (Ring indicator,  unused)


Alternatively, a IBM PC 9-pin serial connector DB9-DB25 modem cable:

PC                 female DB9     DB25 m/f?  Data buffer
RxD   Receive Data          2 <-  3       Data out
TxD   Transmit Data         3  -> 2       Data in
DTR   Data Terminal Ready   4
GND   Signal Ground         5 --- 7       GND   Signal Ground
DSR   Data Set Ready        6 <-  6       Data Set Ready (+12V)
                            | (wire for 5 or 6)
CTS   Clear To Send         8 <-  5       Clear To Send (+12V)
                            |
DCD   Carrier Detect        1     8       Carrier Detect (unused)
RTS   Request To Send       7  -> 20      Data Terminal Ready (sensed)
RI   Ring Indicator         9     22      (Ring indicator,  unused)

The cable used must be first verified by trying it with the data buffer. If you are going to use a new cable, it may be a good idea to verify the cable first, before performing the upgrade.

A terminal emulator program like Kermit is invoked on ``COM2:'' (or ``/dev/cua1'' in Linux) with the settings ``9600 baud, 8 data bits, 1 stop bit, hardware handshake''. You will need to use 115200 baud for the upgraded data buffer. If your Kermit supports only 50--38400 baud, you need to set a special ``high-rate'' flag for the serial port. For ordinary 16550A COM ports this is accomplished with ``setserial /dev/cua1 spd_vhi'' and by using 38400 baud in Kermit. For Digiboard ports you need to use ``/usr/src/linux/drivers/char/ditty fastbaud ttyd1'' and use 110 baud in Kermit. Please replace the actual port names according to what port you have used to connect to the data buffer.

An ``ESC'' character is sent to data buffer. The green ``Active'' LED on the data buffer back panel should be lit now. (The buffer should also respond with a maximum of four characters which are in binary and appear like more or less garbage in a terminal emulator.)

Other command characters which can be tested by just typing them at the terminal emulator are:

• ``%'': Should switch off the ``Active'' LED. After this, the data buffer will require another ``ESC'' to reactivate it to respond to other command characters, other than the ``ESC'' character.
• ``!'': Arm the buffer to wait for incoming data, lits up the ``Arm'' LED.
• ``:'': Reset the armed state, switches off the ``Arm'' LED.
• ``23+'': Set the active block number to be hexadecimal ``23'' for a subsequent ``?''. This should show up in the 4-character response as a ``#'', ``24+'' as ``$'', ``25+'' as ``%'', and so on.
• ``?'': Start downloading a 512-byte block of buffer data. Should show garbage characters on screen: it is a message of 516 more or less random bytes coming into the terminal emulator program.
• ``0-'': Load a test pattern in data buffer RAM. ``0'' can be a hex digit 0--C to select different patterns, see page DB-17 of the data buffer manual. Should first lit the ``Take'' LED and after the pattern is loaded, the ``Hold'' LED. Note that the bit clock generated by the recorder reproduce/bypass electronics is required for the data buffer to clock test data in. The pattern invoked by ``6-'' should be quite visible when looked at with ``?'' because it consists of a sequence of ``55, 55, AA, AA,...'' Hexadecimal 0x55 shows up as ``U''.

Tests with a ``simulated'' 115200 baud data buffer (an MS-DOS PC running a dedicated program acting like the ``real'' data buffer) seemed to indicate that:

1. Readout of the complete 128~kB buffer is feasible in under 13~seconds.
2. With 16450 UARTs this won't simply work, Linux (nor any other operating system) cannot handle serial interrupts arriving that often.
3. With 16550A UARTs with their 16-byte FIFO buffers dropouts are very seldom, but they do occur. It is expected that this can be easily recovered by requesting a retransmission of the failed 516-byte block.
4. DigiBoard (or other serial cards with large input buffers) should prove ideal to this data buffer application and they should be able to guarantee that no data loss can occur. Alas, in practice the IRQ-less design of DigiBoard responds 25% slower than 16550A based ports.

Measurements with the real 115200 baud data buffer and the 16550A-based COM2: port revealed that it takes in average 13.02~seconds to transfer the buffer contents to the FS PC.

Using a DigiBoard port doubles this time, to the average of 26.19~seconds. It should be noted, though, that DigiBoard required neglible, less than 0.1% of the 486DX-50 CPU; the 16550A-based port continuously transferring requires about 16.5% of CPU.

The Field System version 9.0 supports the use of an upgraded 115200 baud data buffer in its pcalr phase calibration detection program. An enhanced version of this program is anticipated in a forthcoming version of the Field System. We are hoping to combine ingredients of the existing ``pcalr'', experimental data buffer diagnostic software, Sergei Pogrebenko's multiple phase cal tone detection algorithm (presented in VLBI Memo #029), and possibly another version of the algorithm developed by Kaj Wiik at Metsähovi.