dcrc_documentation.txt

###########################
Communicating with the DCRC
###########################

You can communicate with the DCRC via telnet.  Typically, connection to port 5002 is possible.  The telnet syntax is:
$ telnet ip_addr:port

From the DCRC onboard help (type 'help'):
RDB adr c  Read Data Binary,  adr(h), byteCnt=evenCnt(h)
 RDW cnt    Read sdRam Binary Addr=0x18, cnt= wordCnt(h)
 RD adr c   Read Adr(h) ASCII, c=wordCnt(hex), no_adr_increment
 WR adr d   Write Addr ASCII, d=Data16 (word write)
 RT         Read Trig FIFO, ASCII LngWords Cnt, Data0, Data1, Data2...

to read a register:
rd 14\n\r

the dcrc will respond with the register value, followed by the newline and carriage return characters.  In general, the DCRC output consists of the data followed by the newline and carriage return characters (two bytes).

For example, 'rd 0' returns six bytes: the first four are a memory address.  the last two are \n\r.

For additional documentation on the DCRC boards, see https://confluence.slac.stanford.edu/display/CDMS/DCRC+Documentation.

##################
The trigger buffer
##################

to read the trigger buffer:
rt\n\r

the response to 'rt' consists of a header that gives the number of triggers, followed by the trigger addresses.  The data is separated by the two-byte delimiter '\n\r'.  Both the header data and the address data are 8 bytes.  To read the header or an address datum requires a 10-byte read because of the '\n\r' characters.

To calculate the number of triggers, you must realize that each of the eight bytes represents a character - and that these eight characters give the number of triggers in hexadecimal.  Don't expect to convert the response from 'rt' into a number solely with math - you also need an ascii table.

Here is an example: 110000 110000 110000 110000 110000 110000 111000 110000 1101 1010 = '00000080\n\r' => 8*16^1 = 128 triggers.
 
In the RevC DCRC, one trigger word from an 'rt' command consists of eight bytes - better thought of in this case as four groups of 16 bits.  [This following is probably wrong?] The actual address of the phonon waveform are the lower five bits and can be extracted from the 16-bit group by masking with 0xfffff.  The four groups of 16 bits correspond to phonon channels A, B, C, and D.


#############
Waveform data
#############

to read the fourth waveform and request the sixth:
wr a %c%c%c%c\rwr b %c%c%c%\rrdb 14 %x

the waveform is read in towerfe3.c.  First the addresses are prepped, and then the read command is issued.

	if ((triggerword & 0x3fffff) < phononprepulse[dcrc]) 
	 phtriggerword=0x400000+(triggerword & 0x3fffff) - phononprepulse[dcrc];
	phtriggerword += (triggerword & 0xff000000);
	sprintf (newaddr, "%08lx", phtriggerword);


	// Read the second waveform and request the third
	for (int dcrc=1; dcrc<=6; dcrc++) {
	  if (!dcrcread[dcrc]) continue;
	  sprintf(command,"wr 4 %c%c%c%c\rwr 5 %c%c%c%c\rrdb 14 %x",
		  phaddr[dcrc][whichtrigger][0],phaddr[dcrc][whichtrigger][1],phaddr[dcrc][whichtrigger][2],phaddr[dcrc][whichtrigger][3],
		  phaddr[dcrc][whichtrigger][4],phaddr[dcrc][whichtrigger][5],phaddr[dcrc][whichtrigger][6],phaddr[dcrc][whichtrigger][7],phonon_nbytes[dcrc]);
	  int avail = gDataSocket[dcrc]->available();

these are encoded by the Midas logger (i.e., post-DCRC):
    /// Encode a word that encodes the origin of the trigger.  Here is       
    /// the intended byte assignment:
    /// bits 32-26: unused
    /// bits 25-21: trigger type (types to be defined, 0=default)          
    /// bits 20-14: tower of 2nd (coincident) trigger source
    /// bits 13-11: DCRC# of 2nd (coincident) trigger source
    /// bits 10-04: tower of 1st (primary) trigger source
    /// bits 03-01: DCRC# of 1st (primary) trigger source


// Ideally I would be unpacking information that looks like this:
      // Each trigger will have 10 bytes of data stored with it
      // Byte 0: which DCRC in the array the trigger came from
      // Bytes 1-2: trigger bit information (16 channels)
      // Byte 3: Clock "rollover" value: one byte encoding 0-255
      // Bytes 4-9: ASCII bytes for trigger address
      // Note: This code is not currently compatible with what the front end
      // will put out;
      // So instead what I have coming from towerfe3.exe is this (13 bytes):
      // Bytes 0-7: trigger address, including trigger bits and address
      // Byte 8: which DCRCs to read--ignore this byte
      // Bytes 9-12: trigger origin word---lower 10 bits give which DCRC