Brief DAQ output format description and example .......... H.Berns, 3/8/03 In its current version, the DAQ card generates one data line at each coincidence trigger occurence. The trigger coincidence and other options can be set through a variety of uC commands as described in http://www.phys.washington.edu/~berns/WALTA/Qnet2/FNAL_files/Qnet2UserGuide.doc and http://www.phys.washington.edu/~berns/WALTA/Qnet2/FNAL_files/qnetcpld.doc Note1: This document is valid only for Qnet2 DAQ firmware versions *before* May 2003! The output format has changed significantly for the production version DAQ cards, firmware versions 5/29/2003 and newer. I will try to update this document soon to reflect the changes in the newer firmware version(s). Note2: A few new commands have been added since the above docs were last updated. The DAQ card is still under development, so there'll probably be a couple of more changes and bug fixes coming up. (Again, be patient. We'll try to update the manuals soon, too...) E.g. one of the new commands enables environmental data lines to be generated at regular intervals (once per minute, once every 10 minutes, or once per hour). Each environmental data line starts with the symbol #. They're currently just for testing and internal use, not yet final state and documented. So, if you're only interested in extracting the DAQ *data* lines, please make sure your software skips the lines starting with '#'! Best if you add some sort of sanity check in the scanner to make sure that you actually read only valid data lines containing 17 words with the ranges and formats described below: DAQ output data format (lines not starting with '#'): ----------------------------------------------------- - ascii format - each line contains 17 words - words 1-10 are hex format and described in http://www.phys.washington.edu/~berns/WALTA/Qnet2/FNAL_files/qnetcpld.doc (internal note: this doc file needs to be updated, some statements are out of date...) brief overview: 1: hit tags for the four inputs, bit0= input 0, bit1= input 1, etc.; examples: 1= input 0 only, A= inputs 1 and 3 2: trigger count of upper 28 bits of the 31-bit 41.66 MHz CPLD counter; range: 0000000...FFFFFFF, resolution (1 LSB increment) = 24 nsec * 8 = 192 nsec; trigger occurs at end of trigger gate (192 nsec) NOTE: A trigger count of 0000000 means that the DAQ card is still in the initialization phase, i.e. the GPS receiver hasn't started to generate 1PPS pulses yet! Do not use the inital data until the trigger count becomes non-zero! 3: TMC count of rising edge at input 0 (RE0); range: 00...FF, resolution = 24 nsec / 32 = 0.75 nsec 4: TMC count of falling edge at input 0 (FE0) 5: TMC count of rising edge at input 1 (RE1) 6: TMC count of falling edge at input 1 (FE1) 7: TMC count of rising edge at input 2 (RE2) 8: TMC count of falling edge at input 2 (FE2) 9: TMC count of rising edge at input 3 (RE3) 10: TMC count of falling edge at input 3 (FE3) - word 11: 31-bit CPLD count of the most recent 1PPS (1-pulse-per-second) time mark of the GPS receiver; hex format, range: 00000000...7FFFFFFF, resolution = 24 nsec - word 12: UTC time of most recent GPS receiver data update; 1 per second (unfortunately asynchrounous of 1PPS pulse); format: HHMMSS.mmm where: HH= hour [00...23], MM= minute [00..59], SS=second [00...59], mmm= millisecond [000...999] - word 13: UTC date of most recent GPS receiver data update; format: ddmmyy where: dd= day of month [01...31], mm= month [01...12], yy= year 2-digit format [00...99, e.g. 03=2003] - word 14: GPS valid/invalid flag; format: A= valid (GPS data ok), V= invalid (insufficient satellite lock, or GPS receiver is in init phase) - word 15: number of GPS stallites tracked for time&position solution [decimal: 00...12] - word 16: DAQ status flag (hex): bit0: 0=ok, 1= 1PPS interrupt pending (warning flag: if DAQ card is busy, then 1PPS count might lag behind or get mismatched) bit1: 0=ok, 1= trigger interrupt pending (possibly high trigger rate; if continues, then data might be corrupted) bit2: 0=ok, 1= GPS data possibly corrupted while DAQ uC was/is busy bit3: 0=ok, 1= current or last 1PPS rate is not within 41666666 +/-50 CPLD clock ticks (GPS glitch or DAQ uC busy). - word 17: time delay [milliseconds] between 1PPS pulse and GPS data interrupt; a positive number means 1PPS pulse is ahead of GPS data, and negative number means GPS data is ahead of 1PPS pulse by milliseconds. Usage: round (word12 + word17/1000) to nearest full second gives the actual GPS time at last 1PPS pulse Example: -------- C F6EA719 F4 00 74 87 06 0A 26 34 791A2790 181600.655 130103 A 07 0 +0143 - C : hit tag: inputs 2 and 3 were within the coincidence trigger gate window (192 nsec width) - F6EA719 : trigger count = 49710715584 nsec (internal CPLD count) - TMC counts: due to hit tag = C, use only RE2/FE2 and RE3/FE3, ignore RE0/FE0 and RE1/FE1. RE2= 06 = 4.5 nsec FE2= 0A = 7.5 nsec => input 2 pulse length = 3.0 nsec (FE2-RE2) RE3= 26 = 28.5 nsec FE3= 34 = 39.0 nsec => input 3 pulse length = 10.5 nsec (FE3-RE3) => input 2 is 24.0 nsec ahead of input 3 (RE3-RE2) - 791A2790 : 1PPS count = 48762172800 nsec (internal CPLD count) => trigger occured 948542592 nsec after 1PPS pulse (trigger count - 1PPS count - trigger gate width: 49710715584 - 48762172800 - 192 nsec) - 181600.655 : UTC time from GPS = 18:16:00.655 (HH:MM:SS.mmm) - 130103 : UTC date from GPS = 13 Jan 2003 - A : GPS data is valid - 07 : 7 GPS satellites were tracked - 0 : no warning flags, data is clean - +0143 : 1PPS pulse is 143 msec ahead of GPS data: 1PPS pulse occured at ROUND(18:16:00.655 + 0.143) = 18:16:01 ==> input 2 started the trigger gate at 13 Jan 2003, 18:16:01.948542597 (18:16:01 + 948542592 nsec + 4.5 nsec)