[Halld-tracking-hw] Tracking minutes posted

[Gerard Visser]

Hi Beni & all,
	-->

		Gerard

On 7/24/2013 9:14 AM, Beni Zihlmann wrote:
> Hi Naomi, everybody,
>
> I finally looked through all the back and forth on this issue and more or less
> understand
>   the last iteration of the data format. So here my 0.5 cent blabla:
>
...
> 2) we do not need special pedestal runs, what we need is special runs reading
> out all samples with the offsets
>      all set at 0x8000 or some other most preferred offset. From that data one
> can easily calculate the pedestals
>      and width and from that new best offsets. These new offsets can then be
> loaded and the procedure repeated
>      to verify/optimize the settings if so desired.
>      -> which of course brings up another point of book-keeping these pedestals,
> width and offsets and what is
>      currently loaded in the ADCs.

Beware that the pulser gain and ADC gain are both having a few % variation from 
channel to channel, mostly due to the 1% tolerance of various resistors. It is 
not possible to deduce the correct offset DAC setting to move the pedestal an 
exact large amount... I don't think there is much value in runs with all offset 
DAC's set to mid-scale / no offset, except for initial setup. Rather, as was 
done with the old test daq software, the current pedestals (with offset DAC's 
set to the current offset values from prior running) should be compared to 
targets, and small changes in the offset DAC's calculated to move the pedestals 
nominally _part way_ to the target (lambda factor 0.1-0.2 perhaps). This 
procedure proved to coverge reliably and reasonably rapidly. I continue to 
recommend it.

About the number of bits of pedestal monitoring: For _normal_ purposes the 
pedestals will surely be in some sub-range, perhaps 0-255 is enough although 
maybe 2x that needed. So that can reduce the number of bits. I think it would be 
a mistake to reduce the resolution by dropping LSB's or doing any other sort of 
integer division. The pedestals are a useful monitor of the health of the FEE 
and ADC. [Although, the "pedestal" field of hit record does not have to be the 
mechanism for monitoring the pedestals, and I am not personally convinced it 
should be, although that doesn't matter. Whatever the monitoring mechanism may 
be, have it have full resolution although need not have full range.]

>
>
> 3) I think it is a very bad idea to have different data formats for the FDC and
> CDC. We have to come up with
>      a common solution. The threat of a potential mix-up in the future
> overweights any benefit I see.

For what it may be worth, I completely agree. Best to even have just one version 
of the firmware, make it flexible enough to deal with both cases under of course 
different control register settings. But at a minimum, one version of the data 
format.