Feature #518

Incorporate new unpacker (allows read-out of EMR and tracker)

Added by Tunnell, Christopher almost 13 years ago. Updated about 12 years ago.

Target version:
Start date:
22 June 2011
Due date:
% Done:


Estimated time:


As I understand it, the unpacker was refactored to allow for readout of EMR and tracker. Other interesting features including being able to disable equipment and it passes all the Coverity static code analysis stuff.

This issue will track the progress of this and information extracted from the unpacker guys. The new unpacker version breaks G4MICE.

The work required to incorporate it into MAUS (which I think Yordan has done a lot of) is the following I believe:

  • update InputCppRealData interfaces
  • include datacards for turning on and off equipment
  • write a few paragraphs on what is meant by unpacking, the general philosophy, etc., that will eventually make its way into a paper.
  • leave 'room' such that we can fit pulses somewhere instead of storing low level information in the high level datastructure

Updated by Tunnell, Christopher almost 13 years ago

Chat with Jean Sebastien Graulich (JSG):

DATE defines each equipment within it. When DATE reads out from a certain board, it adds a header to tell the unpacker what format the bits mean in addition to the board information.

JSG is writing a note.

In the end for production, the tracker will have data per particle event (ie. trigger) and this has been what's good about the new unpacker. JSG rewrote the tracker readout. Currently though the tracker data for the cosmics doesn't have the particle event level information but rather just 'per spill' thinking in the corollary to future hall data.

The EMR data will come all at one spill because muons can decay, they slow down, etc., so you have to corrolate the EMR data with, for example, TOF. EMR has 2.5 ns resolution.

fragment means payload.

if there is corrupt data, then the entire daq event (ie. spill) is skipped.

ldc ~ crate

the realdata stuff won't have to loop like it did before. There is a 'process manager' that walks across the daq data tree and has 'switch' type statements for different equipment maps. mdprocessor can inherit and has something like 'process' so depending on if it's a start of run, start of spill, etc., it does the right hting.

the unpacker also sorts out itself the files.

nobody knows how to hook up unpacker to socket.

JSG has a nice example that outlines a lot of the functionality that can be done with the unpacker and it looks fairly easy to figure out.


Updated by Tunnell, Christopher almost 13 years ago

Dear others I've added in:

I've taken notes of my chat with JSG if you want to view them at this link. I think the unpacker will be fine despite JSG's departure.


Updated by Rogers, Chris over 12 years ago

Can we close this issue?


Updated by Rogers, Chris about 12 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

Must be closed


Updated by Rogers, Chris about 12 years ago

  • Target version deleted (Future MAUS release)

Also available in: Atom PDF