Re: tpc

[Fred Gray <fegray@socrates.Berkeley.EDU>]

Hi, Peter,

> After some alignment effort, we docked the TPC into the
> eSC today, for the first time. Surprisingly, they fitted well!

Congratulations!

> Tomorrow we will connect the TPC electronics, both TDC400 and
> FADC. I will think how to install a trigger based FADC
> readout (any comments on that?).

The FADCs are set up in a "common stop" mode: they run until they receive
a trigger, going circularly through the memory (when they get to the end, they
start again at the beginning).  Consequently, you will have the 4096 samples
immediately _before_ your trigger.  However, there's currently a problem:
the DAQ reads the memory starting at sample 0 and going through sample 4095
without regard to where the trigger came.  I need to change it to read the
samples in the proper order, which I will do today/tonight.

Also, there is still not a program to analyze the FADC data.  I understand 
that Piotr came up with an event display program, which I will try to find 
and resurrect for you.

> As we understand we can use your conversion program also for
> the full TPC data. Probably we'll try that tomorrow.

In principle, the TDC400 data should be converted properly.  Since it's never
been tested, I'm of course not really sure.  I can imagine that the bytes 
might come out in the wrong order: with 8 bytes per word, there are 
8! = 40320 possible orderings. :-)  The old file format did not contain any 
provision for FADC information, so it will not be copied from the MIDAS file.

> Thanks for the elog. We are trying to get serious about that,
> so please don't delete it. 

OK, I just deleted my garbage entries and left the rest alone.  I then 
configured it to remove the "delete" and "edit" options.

> Actually, do you know how save/protected it is-if we use it
> as our main run book instead of a written version. We'll
> get a scanner to be able to attach hand writings to the 
> log.

Currently, I think it is as safe as any other data on pc3608.  Disks have a 
typical MTBF of order 300,000 operating hours, right? :-) Translation: we need 
a regular automatic off-site backup system for the logbook.  I'll look into 
setting up a job to copy it daily to Berkeley and/or Illinois.

> -Can we integrate our camac pc as an additional producer
>  in the midas event or is that a lot of effort. This would
>  allow the recording of sclalers and other slow camac stauff.

Yes.  If we want it to produce data asynchronously from the main DAQ event,
it's trivial (set two environment variables and copy any required settings
to the main ODB).  In this case, its events would be stuffed in the same 
data stream together with the main DAQ events, but only approximately 
time-ordered.  If it needs to be precisely synchronized, it's a bit more 
complicated, but definitely still feasible.  

> -I will try to program the FPGA in July, so that we can
>  aim to replace your impressive complex logic.

OK--it's still pretty much Tom Case's impressive complex logic.  I don't think
we made any hardware changes at all, certainly no large ones.

-- Fred

-- Fred Gray / Visiting Postdoctoral Researcher                         --
-- Department of Physics / University of California, Berkeley           --
-- fegray@socrates.berkeley.edu / phone 510-642-4057 / fax 510-642-9811 --