Raw data

The files without an extension, i.e. 6333/6333.2012.1226.2 are raw data files directly uploaded from the detector. The first element of the filename is the DAQ ID, while the second and third are the date of the upload given as 2012.1226 = Dec 26, 2012 in the above example. The fourth is also probably something.

These files are readable with the form

6F47946F BF 00 3F 00 3E 00 3E 00 6E0811EA 130024.022 261212 V 05 0 +0072
6F479470 00 29 00 29 00 2A 00 2E 6E0811EA 130024.022 261212 V 05 0 +0072
6F4F4525 AB 00 2A 00 00 00 00 00 6E0811EA 130024.022 261212 V 05 0 +0072
6F4F4525 00 37 00 34 00 00 00 00 6E0811EA 130024.022 261212 V 05 0 +0072
70147E73 B2 00 35 00 00 00 34 00 6F858A2B 130025.030 261212 V 05 0 +0064
...

This is the datastream written directly from the DAQ board, explained in the CRMD manual starting on page 33 ("Data Words"). Briefly, they encode the timing of pulses from all four input channels with respect to the onboard clock of the DAQ and the GPS clock provided by the GPS unit.

Reading the raw data

In more detail, a single event is represented by multiple lines, each of which comprises 16 "words" separated by a space. Considering the first line in the example above,

Trigger Count	RE0	FE0	RE1	FE1	RE2	FE2	RE3	FE3	1PPS	UTC Time	UTC Date	GPS	NSat	Status	Delay
6F47946F	BF	00	3F	00	3E	00	3E	00	6E0811EA	130024.022	261212	V	05	0	+0072

The first 10 columns, Trigger Count - 1PPS, are hexadecimal integers (32-bit for Trigger Count and 1PPS, 8-bit for RE0 - FE3).

The Trigger Count is the clock value at which the event trigger registers, as measured by the 25MHz DAQ clock. At this frequency, the clock produces a tick every 40ns, meaning that 6F47946F_hex = 1866962031_dec ticks is equivalent to 1866962031*40ns = 7.467848124s. This time is measured from the last time the DAQ clock "rolled over" to 00000001, which it does every 171.798691800s (not quite three minutes).

Note, then, that the Trigger Count column does not give absolute time, but the time from a somewhat arbitrary reference point less than three minutes in the past. We'll have to do more work to turn this into an absolute clock time.

The eight Edge Count columns RE0 - FE3 are TMC readings of the pulses from the PMTs on the 4 detector channels. The first two are the rising edge and falling edge of the input 0 pulse, abbreviated RE0 and FE0, respectively. Input 0 is channel one. The remaining three pairs follow the same pattern: RE1 and FE1 (channel 2), RE2 and FE2 (channel 3), and RE3 and FE3 (channel 4).

Do the inputs really correspond to channels? If not, what defines the input ordering? That is, why is input zero always first?

"Rising edge" means the point at which the PMT pulse first exceeds the threshold voltage. Converted to binary, these 8-bit values are interpreted as

• Bits 0-4: TMC count of rising edge
• Bit 5: Channel edge tag (1=valid rising edge, 0=no rising edge)
• Bit 6: Unused, always zero
• Bit 7: Trigger tag (1=new trigger, start of a new event, 0=follow-up data of a trigger event)

For instance, in the first line of our sample file, RE0=BF_hex=10111111_bin. This parses as

Bits	Meaning	Value
10111111	TMC count	31Dec
10111111	Edge tag	Valid
10111111	Not used	Always 0
10111111	Trigger tag	New event

The first digit of RE0 gives you a quick way to identify separate events in the data. For a new trigger, the value of RE0 must be greater than or equal to 1000000_bin=80_hex; if a line is a continuation, then this first digit must be less than 8. From the example given above,

6F47946F BF 00 3F 00 3E 00 3E 00 6E0811EA 130024.022 261212 V 05 0 +0072
6F479470 00 29 00 29 00 2A 00 2E 6E0811EA 130024.022 261212 V 05 0 +0072
6F4F4525 AB 00 2A 00 00 00 00 00 6E0811EA 130024.022 261212 V 05 0 +0072
6F4F4525 00 37 00 34 00 00 00 00 6E0811EA 130024.022 261212 V 05 0 +0072
70147E73 B2 00 35 00 00 00 34 00 6F858A2B 130025.030 261212 V 05 0 +0064
...

we can quickly see that the first line starts a new event (RE0=BF>80) that is continued on the second line (where RE0=00<80). The third and fourth lines are a separate event (RE0=AB and RE0=00, respectively); while the fifth line begins yet another event (RE0=B2).

In practice, since bit 6 is unused, the first digit of RE0 will be either A or B for a new event with a valid rising edge and 8 for a new event with an invalid rising edge. A value of 9 would mean that the leading digit of the 5-bit binary TMC count is 1; the relative absence of RE0 values beginning with 9 indicates that invalid leading edges occur only early in the TMC clock cycle.

What determines an invalid rising edge, physically and logically?
Why do invalid rising edges occur only for TMC < 10000?
In RE/FE pairs, one value is always zero. Why?

RE0 is special in that it defines the trigger on bit 7. For all other rising edge values (RE1, RE2, RE3), bit 7 is always zero.

Similarly, "falling edge" means the point that the pulse drops back below the threshold voltage. Converted to binary, these 8-bit values are interpreted as

• Bits 0-4: TMC count of falling edge
• Bit 5: Channel edge tag (1=valid falling edge, 0=no falling edge)
• Bit 6: Unused, always zero
• Bit 7: Unused, always zero

This applies to all falling edge values (FE0, FE1, FE2, FE3).

The 32-bit 1PPS column is a reference to the GPS unit. As part of the standard, every GPS device maintains a clock that "ticks" once per second, providing a standard "one pulse per second" (1PPS) signal. The value in the 1PPS column is the CPLD time at which the last 1PPS GPS signal was received - it is not a direct time reading from the GPS unit itself. This value will always be less than the Trigger Count value in the first column.

Is the CPLD clock the same as the TMC clock?

The next two columns are UTC timestamp readings from the GPS unit itself. The format for UTC Time is

Digits	Meaning	Range
HHMMSS.mmm	hours	00-23
HHMMSS.mmm	minutes	00-59
HHMMSS.mmm	seconds	00-59
HHMMSS.mmm	milliseconds	000-999

The format for UTC Date is

Digits	Meaning	Range
ddmmyy	day	01-31
ddmmyy	month	01-12
ddmmyy	year	00-99

Note that the century is implicitly "20", setting us up for a Y2100 problem if we maintain the same DAQs for the next 80+ years. The UTC signal is sent from the GPS unit every second, but it is separate from the 1PPS signal sent with the same frequency.

The next two columns give general GPS information. The GPS column indicates whether the GPS signal is valid: A for valid, V for invalid. The signal might be invalid, for example, if the unit cannot find enough satellites, or if it is currently initializing.

Is this true? Seems like V would be "valid". There are an awful lot of V's in the data I've looked at

The NSat column gives the number of satellites currently available to the GPS unit, from 00-12.

The Status column is a single-digit hex integer that serves as a DAQ status flag. Page 35 of the manual explains the system. A value of 0 means that everything is nominal.

The Delay column is the time delay in milliseconds between the GPS unit's 1PPS signal and UTC data signal. A positive sign means the 1PPS arrived first, while negative means the UTC data arrived first.

Calculating time

First, we use the UTC Time and Delay columns to calculate the GPS time of the last 1PPS pulse as

1PPS = *UTC Time* + (Delay/1000)

This correlates with the value given in the 1PPS column, which is the CPLD clock reading when that pulse arrived. Thus, we now have the absolute GPS time of the last 1PPS pulse. We can now compare this to the clock value in the Trigger Count column to assign an absolute GPS time to that event. Using the same example data,

Trigger Count	RE0	FE0	RE1	FE1	RE2	FE2	RE3	FE3	1PPS	UTC Time	UTC Date	GPS	NSat	Status	Delay
6F47946F	BF	00	3F	00	3E	00	3E	00	6E0811EA	130024.022	261212	V	05	0	+0072

we find

1PPS = 130024.022 + 0.072 = 130024.094

This is the GPS time of the value 6E0811EA recorded in the 1PPS column. The difference between the value in the Trigger Count column and this value is

6F47946F - 6E0811EA = 13F8285

or 13F8285_hex=20939397_dec clock ticks. At 40ns per tick, this means that the Trigger Count value occurs 0.837575880s after the 1PPS value (remember, the 1PPS record always occurs first chronologically). The Trigger Count GPS time is therefore 130024.931(575880) to the nearest millisecond. (The additional digits are below the precision of the UTC time and therefore meaningless, but I've kept them because I'm not done playing with the numbers).

-- Main.JoelG - 2017-03-22

Comments