How to make a sync device

How to make a sync device

In previous lectures we have shown why it was useful to insert "sync" or "flag" words prior to the digitized sample point of channel 1 during each time epoch. One reason is to display any particular channel at the touch of a switch. This becomes very useful with large multichannel data sets. For 320 data channels, it is much easier to dial in a channel number on a dip switch to display it on the oscilloscope than to use some kind of elaborate setup with 320 separate cables, one of which is chosen for display. The syncs also provide the fiduciary time which can be used by the data analysis software to determine where each channel is located in the file.

A problem is that we don't want sync words randomly in the data. To ensure there are no randomly occurring syncs, the length of the sync word should be long. If we used only a one byte sync word, the odds of it appearing randomly in the data would be 1 in 2⁸ which is 1 in 256. It would likely come up on the very first sample point! Because the 320 channels of sample data, each having a 16 bit data word, means there are 640 bytes of data each time epoch. If there is a one byte sync word, say the hexidecimal number "0A", then odds are it will appear at least twice during a single time epoch. For a two byte sync word, the odds are it will appear once every 1 in 2¹⁶ byte of data (1 in 65536). How much time elapses? Well, there are 640 bytes generated per time epoch, and let use say for simplicity that each time epoch is 1ms duration. Then 65536 bytes / 640 bytes/ms = 102.4ms is the time before the sync would be expected to appear randomly. However if we use a 3 byte sync, that is 1 chance in 2²⁴ that these sync words will come up randomly (1 in 16,777,216), which is 16,777,216/640 = 26214ms or 26.214 seconds. For analysis of short sequences, a three bytes sync is acceptable.

We will use the sync words "A B C" (hexidecimal) for this simple example. Remember that hexidecimal (hex) numbers are 4 bits long (1 nibble) - because they are base 16. We will, however, make them byte length because we have stated above our sync words will be 3 bytes long. Therefore the actual hex values are 0A 0B 0C. Now, how can we insert them into the data stream? We mentioned that there is a 21^st slot on the VME chassis. We can insert a board that makes sync words in this slot. It will have its own board number, say board "0" (we used numbers 1-20 for the data acquisition boards). Hence, each time the binary number 00000 appears on the board address lines of the VME bus, this board will be accessed. We would like to insert 0A 0B 0C, which we can do simply by placing these words in latches like the ones we described for the data acquisition boards. The outputs of the latches will be tied (connected) to the 16 data lines of the VME bus that we are using for this system. When board 00000 is accessed, the address decoder sends a valid signal to the latch's enable pin, so that the output goes from high impedance (called z state) to low impedance and the sync words are inserted into the data stream.

Actually it is a bit more complicated, because we have 3 sync words - yet we have been using a 2 byte protocol to send data onto the VME backplane bus. How can we do it? In fact instead of just the three sync words, normally an entire block of information called a "header" is sent prior to each 320 sampled data points. Let us say that the header is 6 bytes long. The first 3 bytes are the sync words, which means we have 3 bytes left. A use for those other 3 bytes would be for a real-time counter. The counter (3 ganged 8-bit binary counters) would tick once at the start of each time epoch. As we mentioned before, if each time epoch has period 1ms, then this allows for an experiment of up to 2²⁴ or 1.68E7 milliseconds long (4.66 hours) before the counter number will wrap around to 00000000 00000000 00000000. This will often be sufficient for the length of the experiment.

We will therefore need 6 buffer latches on this 'sync' board, 3 to contain the syncs, which can be hard-wired at the latch inputs, and 3 for the counter, which will originate from the 3 binary counter outputs. To send this data as a header at the beginning of each time epoch, board 0 actually needs to be accessed thrice, supposing that we maintain our protocol of using a 16-bit (2-byte) wide data bus. We could simply broadcast the following information onto the bus to access the header information:

board chan gain/corner

00000 0001 xxxx

00000 0010 xxxx

00000 0100 xxxx

where x means "not used", and the info about which latch pair to output to the data bus appears on the 5^th - 7^th address/command lines (least to most significant bit from right to left). For the data acq boards, we had to worry about the time delay for setup of the sample/hold and the analog to digital conversion. But we do not have to worry about in this case - accessing the same board repeatedly - because the sync board does not do sample/hold and analog and digital conversion. Hence, the above address/command words can be accessed and broadcast to the VME data lines one after the other. Of course, the latches and binary counters need to be configured with appropriate logic circuitry so that the channel number would determine which pair of 6 latches which actually broadcast the information onto the data bus. This is illustrated in the accompanying diagram. A set of three latches provide the three sync words information. This information (0A 0B 0C) is hard-wired at the inputs to each latch. A given latch is enabled when: 1) the board decoder is valid (when 00000 appears on the board address lines, so that the output of the board decoder is hi), and 2) the particular channel line assigned to each latch (5^th, 6^th, or 7^h address line of VME bus), as shown above, is hi. Then the output of a particular logic "AND" is hi and that latch is enabled to send its information onto the VME data lines. A set of three ganged binary counters provide the three bytes of counter information. The outputs of these are attached to the remaining available inputs to the latches. In the diagram, they are colored by varying shades of orange to denote lo, mid, and hi order counter byte. By convention the counter bytes are normally inserted into the data stream from hi to lo, as shown.

Data Streaming

One other important point, now that we have our entire biomedical data transduction and acquisition system together, is data streaming. This is the last stage of our system during the recording process. We have mentioned that "streaming" means that digital data is sent continuously to a digital storage medium. Commercial boards are available to do this work in the way we need it done, so we can use a commercial product. One such is the DT 3801 from Data Translation (see also DT3801 overview, installation). It is inserted into a PCI slot of a dedicated PC computer. The digital input ports to the DT3801 are 16-bit wide, so we can simply use a cable from the VME data lines to the input port of the DT 3801. The only other signal that the board needs is the system clock. It needs this so that it will know when new data is at the input port, that should be received by the board and sent for storage on the hard drive or other storage medium. For example, it may work based on the trailing edge of the clock. Each time it sees a trailing edge, it knows a new data word is ready to be ported in. The board can be set up in software to start and stop acquiring data at any time. Hence the easiest setup is to allow the system clock and the data acquisition system to run continuously throughout the experiment. The data which appears on the VME data lines will then be stored by software command.

Why not just record data continuously without a stop and start mechanism? Because often for a large part of the experiment there is adjustment of the equipment and preparation, and waiting for various events to occur, that would not be useful in the data analysis. If this data were to be recorded it would just add to the size of the data file. Ergo, a start/stop mechanism is used so that the investigator can decide what to record and what to leave out of the data file.