griffincollaboration/data-spy

an online parser of raw GRIFFIN data

data-spy's Issues

PPG Events

The data format for PPG events are as follows:

The header is parse the same way as a GRIFFIN header (label (0x8) ).
If the Data Type received from the header is 4 and the channel address is 0xFFFF, then this is a PPG event.

• The next word may, or may not have a network packet (0xd), parsed like griffin.
• The next word is the new ppg pattern, starts with 0x0, the next 28 bits are the pattern
• The next word is the old ppg pattern, starts with 0x9, the next 28 bits are the pattern
• The next word may or may not be the network packet (see above)
• The next word is the PPG low time stamp, starts with 0xa next 28 bits are the low time
• The next word is the PPG high time stamp, starts with 0xb, next 28 bits are the high time
• The next word is the trailer, starts with 0xe, last 16 bits are a repeat of last 16 bits of new ppg.

I'm pretty sure the PPG patterns are actually only 16 bits, so it's 12 truncated PPG bits concatenated with 16 ppg bits in every one of the "28 bit" pattern cases.

Scaler Events

The data format for Scaler events are as follows:

The header is parsed the same way as a GRIFFIN header (label (0x8) ).
If the Detector Type received from the header is 0xf and contains at least 8 words. The address the scaler represents is given in the "Address portion of the header". The words are then given in teh following order

• network packet
  • usual 0xd with 28 bits for packet id
• low time stamp
  • 0xa with 28 bits of low time stamp
• 4 scaler words (meaning depends on scaler)
• trailer which contains high time stamp word and scaler type
  • 0xe
  • next 16 bits are time stamp high
  • "type" is next 4 bits
  • next 8 bits should equal first 8 bits of time stamp low

Currently, "type 0" represents a precision dead time scaler, while "type 1" represents a rate scaler

timestamps

Do the timestamps have a convenient interpretation other than some gigantic number of ns? They look a but too small to be ms since epoch, but it would be nice to express them as something a little more human readable in the data-spy, if a useful human readable interpretation exists.

cc @SmithJK

Suggestions

Question:

• Is the idea to parse a single GRIFFIN event? Or a single MIDAS event?

Suggestions:

• Allow selective display of events based on digitizer, channel number, type of event (scaler, PPG, event, etc.), pileup type, filters passed.
• Print both the hex event and parsed event.
• Allow display of corrupted events (probably reasonable only in hex). In the case of a corrupted event in GRSISort, it print the entire MIDAS event. Practically, we would probably only need to print from the beginning of a previous non-corrupted GRIFFIN event to the end of the next non-corrupted GRIFFIN event.

waveform sample

Word VIb contains a 28-bit waveform sample, but the docs don't describe how to unpack this into anything more meaningful than an integer. Are there things we can do to make this number more human-readable in the data spy?

raw GRIFFIN events

Hi folks - I'm planning on pulling together a first cut at this project (online parser of raw GRIFFIN data) hopefully around the end of next week. To proceed I need a couple examples of raw GRIFFIN data (and a link to the spec for this format) - can anyone link me anything? No need to actually serve real events right now, just looking for some static examples to build the app around - easy enough to plug a real data feed into it later.

cc @AdamGarnsworthy @SmithJK

event types

Thanks @SmithJK for the latest docs - @AdamGarnsworthy, do we want panels / tabs for each of the four data types (GRIF-16 fragment, GRIF-16 scalar, GRIF-4G fragment, GRIF-C PPG), or will not all of these be written to the ODB?

feedback from Vinzenz

@VinzenzBildstein had some useful feedback:

• include raw word in title bar of each word
• tooltip over each row to explain the meaning of each variable
• clarify reporting for multi-word words (ie waveforms)

docs typeo

From section 3.1.3:

A type of 0 indicates a deadtime scaler, while a type of 0 indicates a rate scaler.

word XIII < 32 bits

according to the docs, type XIII words are 4 byte words consisting of:

• a 4 bit label (0xE)
• a 10 bit event trailer
• a 14 bit repeat of the low bits of the timestamp

Where are the other 4 bits?