Contents of this section
The existing Mark~III data buffer has 1~megabit (or 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
apparently 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:
- 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. (I cannot remember the exact
level value, it should be present in the Mark~III ``Blue Binder.'')
- 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.
- For broadband VC channels (2--16~MHz bandwidths) detecting
multiple calibration tones which occur at multiples of 1~MHz and using
these to perform all the calibrations presented in the previous item
for one channel also for all tones across a single channel.
- Capture data at a given UTC moment to be stored and later
used in ``real-time'' fringe tests.
- 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!)
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 can
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 is to come up with something requiring a relatively
small effort which can still improve the download rate significantly.
Next Chapter, Previous Chapter
Table of contents of this chapter,
General table of contents
Top of the document,
Beginning of this Chapter