Raw-mode readout

Raw data and Raw mode refer to the acquisition of ADC samples at 50 MHz. Raw data acquisition occurs in the 'background', i.e. it can occur while multiplexing and servoing proceed normally. Most version 5+ Readout Card firmware support 1-column raw-mode acquisition alongside other features.

Older readout card firmware does not include raw mode support, except in special revisions where the low-pass output filter and the read-back of some parameters was disabled:

• For 8-column raw mode readout (i.e. 4.3.7, 4.2.7, 4.1.7): up to 8192 samples per column.
• For 1-column raw mode readout (i.e. 4.0.d, 4.0.e, and 5.0.0+): 65536 samples.

The ADC readings are 14 bits, signed, and are reported as 32-bit signed integers. Before using your raw mode data for anything, please take a look at #Interpreting raw mode data. This will explain how to account for the following:

• Data reported by raw mode is offset by 3 (RC Rev. B) or 10 (RC Rev. F) clock cycles relative to the ADC voltage at ARZ.
• Raw mode traces can be used to set sample_dly -- but the relationship is non-trivial in some versions of firmware.

The ADC offset is not included in raw mode readings. So to study servoing, the settled values should be compared to ADC offset.

Firmware Revisions

Raw data acquisition and 4-pole low-pass filter are both memory-intensive features of the MCE readout-card firmware. As a general rule, a given firmware has only one of these features available, e.g., the firmware that has raw mode enabled will not include the filter and vice versa. In some versions that support raw mode, read back of gaini0/gainp0/gaind0 is also not supported.

Firmware Revision	Reported data (signed)
4.0.d+	14-bit ADC samples, single column, 65536 points.
4.3.7	14-bit ADC samples, 8 columns, 8192 points.
4.2.7	upper 8-bit of the 14-bit ADC samples (deprecated)
4.1.7	upper 8-bit of the 14-bit ADC sample (deprecated)

Raw Acquisition With MAS

The scripts "mce_raw_acq" and "mce_raw_acq_1col" handle the details of disabling the sync-box, computing the number of frames the user probably wants, issuing the capture command, and reading out the data. Use them like this:

For 8-Column Readout

• Tune and configure your array.
• Run, for some RC (e.g 1):

mce_raw_acq 1

This will create files <ctime>_raw, <ctime>_raw.run.

For 1-Column Readout

• Tune and configure your array.
• Run, for some RC (e.g. 1) and column (e.g. 3):

mce_raw_acq_1col 1 3

Differences Between 1- and 8-Column Readout

Due to differences in firmware implementation, mce_raw_acq and mce_raw_acq_1col have different default behaviours.

• mce_raw_acq:
  • 8-column firmware supports the acquisition of either 8192 samples, or two full multiplexing frames, whichever is lower.
  • By default, mce_raw_acq attempts to acquire this maximum number of samples.
• mce_raw_acq_1col:
  • 1-column firmware supports the acquisition of 65536 samples, regardless of multiplexing settings.
  • By default, mce_raw_acq will attempt to acquire 65536 samples. It will change num_rows_reported to 32 in order to make the readout frame size go evenly into 65536.

MCE Firmware Implementation

Raw mode readout is accomplished by first triggering the MCE to store 50 MHz data, and then reading out that data using a special data mode.

There are two RC parameters that have to be set for raw data acquisition:

• captr_raw stores a snapshot of 50 MHz data, starting at the next row-return-to-zero.
  • In 8-column firmware, row_len samples of num_rows rows for 2 consecutive frames up to 8192 entries for each channel and stores them in MCE memory buffer for readout in raw mode. The user must delay here before proceeding to read out the data. The delay should be a few return-to-zeros (milliseconds). (Computers are fast, and ARZs can take a long time if row_len is increased for noise measurements... so be generous when running from within scripts.)
  • In 1-column firmware, 65536 samples are stored.
• data_mode determines the pixel-data readout mode.
  • The data_mode must be 3 for 8-column raw mode readout.
  • The data_mode must be 12 for 1-column raw mode readout.
• readout_col_index, in 1-column raw mode, selects the column to store.

The examples below assume a simple configuration where num_rows = num_rows_reported. Remember to delay after captr_raw to ensure the data have been recorded.

1-column example

Be sure to readout enough frames to get all 64k samples; i.e. ceil(8000/num_rows).

 wb rc1 readout_col_index 4
 wb rc1 captr_raw 1
 wb rc1 data_mode 12
 acq_config <filename> rc1
 acq_go <n_frames>
 

8-column example

Only min(8000, 2*row_len*num_rows) samples (per-column) will be stored, so readout min(8000/num_rows,2*row_len) frames.

 wb rc1 captr_raw 1
 wb rc1 data_mode 3
 acq_config <filename> rc1
 acq_go <n_frames>

Unpacking raw mode data

Raw mode data files are MCE flatfiles and can be loaded using the usual mas_data.pro or mce_data.py programs. However, the data should be time-ordered for meaningfullness. This is done by re-ordering the dimensions and collapsing the row and time dimensions.

In newer MASes, the reader programs are aware of data modes 3 and 12 and automatically reform the output data into an n_cols * n_samples array:

d = MCEFile('1234000000_raw_col3').Read()
print d.data.shape
  (1, 65536)

If you wanted to do the unravelling yourself, though, you would do this (assuming 8-column raw mode):

d = MCEFile('1234000000_raw').Read(row_col=True, data_mode=0)
_, nc, _ = d.data.shape
d.data = d.data.transpose((1,2,0)).reshape((nc,-1))

Or in IDL (it's practically a one-liner!):

data = mas_data('1234000000_raw', /no_runfile, data_mode=0)
ds = size(d)
nc = ds[1]
nt = ds[2]*ds[3]
data_raw = reform(data, nc, nt)

Interpretation of raw mode data

Due to internal latencies in how a voltage present on the ADC input is sampled, propagated, and processed in the Readout card, some care must be taken when interpreting raw mode data. The basic things to remember are:

• the trace includes some extra samples from before the ARZ (address-return-to-zero).
• the RC co-adding window may be displaced in non-trivial way from both the raw mode trace and the ADC sampling time index.

When triggered to acquire 50 MHz data, a Readout Card waits for the next ARZ and then begins recording samples from the ADC chain into the storage buffer. Due to ADC chain latencies, some of the data stored actually corresponds to ADC input voltages at times from before the ARZ. The ADC chain latency is 4 clock cycles in RC hardware Rev. B, and 11 clock cycles in RC hardware Rev. E. Separate from the latency, raw mode readout omits a single value at the start of the acquisition.

To make this totally clear, consider a trace measured in raw mode. The "raw index" of these data runs from 0 to 65535. The times, in clock cycles relative to ARZ, at which the voltages in the raw data were actually observed at the ADC are t = -3 to 65532 in Rev. B and t = -10 to 65525 in Rev. E Firmware.

The final complication to the interpretation of raw mode traces is in the identification of what samples are actually summed into the co-added error for a given value of sample_dly.

• For Rev. B cards and all firmware, and for Rev. E cards with RC firmware 5.1.5 and later, the RC co-adder accounts for the ADC latency and so the samples co-added correspond to the voltages present on the ADC input at clock cycles sample_dly through sample_dly + sample_num - 1.
• For Rev. E cards with RC firmware 5.1.4 and earlier, the RC co-adder accounts for 4 cycles of latency rather than 11 (oversight!!). So the samples co-added correspond to the voltages present on the ADC input at clock cycles sample_dly - 7 through sample_dly + sample_num - 8.

The following tables restate the above two facts from the stand-point of how one should interpret a 50 MHz data trace indexed from 0, for the 3 configurations of hardware and firmware revisions. The terminology of the tables is:

• Raw mode sample index: the index (from 0) of data acquired using raw mode readout (capt_raw + data_mode 12).
• Voltage sampling time relative to ARZ cycle: for a given digital sample, the time in clock cycles relative to ARZ that the corresponding voltage was actually present on the ADC input.
• RC co-adder effective index: the effective indexing used by the RC co-adder to choose samples it will add into the co-added error. So if sample_dly = 90 and sample_num = 10, then the samples taken for co-adding are those found at RC co-adder effective index of 90 through 99.

For hardware Rev. B, all firmware revisions

Raw mode sample index	0	1	2	3	4	5	...	n
Voltage sampling time relative to ARZ cycle	-3	-2	-1	0	1	2	...	n-3
RC co-adder effective index	-3	-2	-1	0	1	2	...	n-3

For hardware Rev. E, firmware rev 5.1.4 and earlier

Raw mode sample index	0	1	2	3	...	10	...	n
Voltage sampling time relative to ARZ cycle	-10	-9	-8	-7	...	0	...	n-10
RC co-adder effective index	-3	-2	-1	0	...	7	...	n-3

For hardware Rev. E, firmware rev. 5.1.5 and later

Raw mode sample index	0	1	2	3	...	10	...	n
Voltage sampling time relative to ARZ cycle	-10	-9	-8	-7	...	0	...	n-10
RC co-adder effective index	-10	-9	-8	-7	...	0	...	n-10

MAS Details

Data storage and packaging

What follows below is a description of 8-column raw mode data packaging. For 1-column raw data, the data are packed in time order, and read out in units of the frame size. Values past the end of the 1-column buffer will read as -(2³¹) = 0x80000000.

• Once the raw-buffer of 8192 samples is full, no more samples are stored till a new captr_raw is issued.
• The raw-buffer is shipped out of MCE in a regular frame format (header + num_rows_reported*num_columns + checksum). As compared with normal MCE flatfile data organization, in raw mode the time index takes the place of row. At each time, all columns are reported.
• For RC1 only, for example, time indices t = [0, num_rows_reported-1] are reported in the first frame, with the offset of column c and time t being

index = 8t + c

• Subsequent frames contain subsequent data samples. Since the number of time samples, per column, in a full multiplexing cycle of the MCE is row_len*num_rows, the number of readout frames required to record an entire MCE internal frame's-worth of raw data is equal to row_len (assuming that num_rows = num_rows_reported).
• The readout frame and index of a given time t, column c, is thus

frame = floor[ (8t + c) / num_rows_reported ]
index = (8t + c) MOD num_rows_reported

• Since the number of clock ticks spent on each row is row_len, the row associated with time t is

row = floor [ t / row_len ]

• It is possible to get raw mode data from multiple readout cards; in that case the data will be packaged in the usual way, with all columns reporting at each time.
• Schematically, the organization of raw data for num_rows = num_rows_reported = 33 and row_len = 100 can be represented as follows (here sNNNNNcXX represents a word containing the data for time sample NNNNN, column XX):

(header of frame 0, 43 words)
s0000c00 s0000c01 s0000c02 s0000c03 s0000c04 s0000c05 s0000c06 s0000c07
s0001c00 s0001c01 s0001c02 s0001c03 s0001c04 s0001c05 s0001c06 s0001c07
s0002c00 s0002c01 s0002c02 s0002c03 s0002c04 s0002c05 s0002c06 s0002c07
...
s0032c00 s0032c01 s0032c02 s0032c03 s0032c04 s0032c05 s0032c06 s0032c07
(checksum of frame 0, 1 word)

(header of frame 1, 43 words)
s0033c00 s0033c01 s0033c02 s0033c03 s0033c04 s0033c05 s0033c06 s0033c07
...
s0065c00 s0065c01 s0065c02 s0065c03 s0065c04 s0065c05 s0065c06 s0065c07
(checksum of frame 1, 1 word)

...

(header of frame 199, 43 words)
s6567c67 s6567c01 s6567c02 s6567c03 s6567c04 s6567c05 s6567c06 s6567c07
...
s6599c00 s6599c01 s6599c02 s6599c03 s6599c04 s6599c05 s6599c06 s6599c07
(checksum of frame 199, 1 word)

• Unfortunately, collecting data for up to 2 internal MCE frames is hard-coded in firmware. Even if you reduce number of rows, you will be restricted by 2 frames. If you really want to look at more samples, then you may want to increase row_len instead and using row_order parameter of the address card, move your particular row of interest to the beginning of the frame.
• The readout_row_index parameter is ignored when data_mode is set to 3 or raw mode.
• If num_rows_reported < num_rows, it takes more frames, to be exact:

nframes = 2 * num_rows * row_len / num_rows_reported

to read all the data out.