This message (now translated to html) was sent From sullivan Mon Oct 18 12:41:03 MDT 1999. It was sent to phenix-mvd-l@bnl.gov, chi@nevis.nevis.columbia.edu (Cheng-Yi Chi), young@orph01.phy.ornl.gov (Glenn Young), chiu@nevis1.nevis.columbia.edu (Mickey Chiu), nagle@nevis1.nevis.columbia.edu (Jamie Nagle), bobrek@icsun1.ic.ornl.gov (Miljko Bobrek), brittoncl@ornl.gov (Chuck Britton), emery@icsun1.ic.ornl.gov (Mike Emery)
Subject: MVD DAQ chaintest, really this time

Hi,

This message is to the MVD listserver and a few other people who might be interested. Sorry I just sent an empty message.

Last week, Miljko Bobrek was in Los Alamos to help get the MVD "chaintest" (DAQ hardware chaintest, not the software chaintest) working. More work is needed, but everything seems to work. We did not run many events (a few 100 probably) through the system -- running more events is one of the things we need to do. I consider the test a success and would like to thank Miljko for his efforts. I also want to thank Mickey Chiu at Nevis for giving us a lot of help over the phone with very little (i.e. no) advance notice.

Here is a brief description of the tests. A glossary is given at the end.

Timing (clocks, mode-bits, level-1) came from the minidaq (standing in for the GTM) through a Glink fiber to the TCIM. Starting with the TCIM, the "real" hardware was used -- ribbon cable to the Motherboard, then to a power-comm board, via a kapton cable to a real MCM. No problems were seen with this part of the chain.

Output data came from the MCM, through the power/comm board, motherboard, and a ribbon cable to the DCIM. We tested the DCIM output both with the minidaq and with a DCM. Both the minidaq and the DCM were able to read the packets. The DCM produced an output PRDF file which appeared to have the right format. The MVD part of the data packets were OK, I assume the other information added to the packet by the DCM was OK too. Both the multiplexed mode (data from two MCMs output on one fiber) and the non-multiplexed mode worked. One (of 4) input channels on the DCM did not work.

The arcnet (serial controls) part of the data chain was done with a home-made VME board, which was controlled from a PC running LabWindows. This was set up by SangYeol Kim, who also wrote a lot if the software to control everything. The home-made VME board was connected to the MCMs via a motherboard and power/comm board. The MCMs appeared to "forget" the serial data after a few minutes. This was the only problem we found. In the past, we had problems with other parts of the hardware chain when various components in the hardware chain triggered on noise and sent out reset pulses, etc. I believe that this is happening on our home-made VME board. As was done with other parts of the chain, we should be able to fix it with appropriate filtering capacitors. We have not done this (and the problem is not in part of the "real" hardware), but we will do it soon. The home-made VME board is a stand-in for the (not yet built) arcnet interface module (AIM). This "triggering on noise" problem is probably a lesson learned for the AIM design.

The MVD's trigger interface module does not exist so that part of the chain was not tested.

Glossary:
GTM = granule timing module
TCIM = MVD's Timing and Control Interface Module, takes one Glink input and outputs to 14 ribbon cables, each to a group of 6 MCMs.
DCIM = MVD's Data Collection Interface Module
Motherboard = there is one of these for each 1/4 of the MVD, six power/comm boards connected to one motherboard
power/comm board = there are 6 MCMs connected to each power/comm board

Regards,
John