[Halld-offline] New fADC250 data format + sim-recon

[David Lawrence]

Hi Sean,

  Looks like I didn’t specify the right “from” branch earlier. I think I’ve
committed the changes now.

The documentation on the first level FPGA firmware is here:

https://halldweb.jlab.org/level-1/manuals/FADC250/FADC250_Processing_FPGA_Firmware_ver_0x0C00_Description_Instructions.pdf <https://halldweb.jlab.org/level-1/manuals/FADC250/FADC250_Processing_FPGA_Firmware_ver_0x0C00_Description_Instructions.pdf>

The second level is written by someone else and adds the block headers
but otherwise I believe the data format is driven by this.

I’ve written the parsing to place the individual quality factor bits into their
own members in Df250PulseData. For the digihits though I compressed
them all back into the existing QF member. I did not place any documentation
on those bit assignments anywhere, but you can see them in 
DTranslationTable::CopyDf250Info. Lines 533-539 here:

https://github.com/JeffersonLab/sim-recon/blob/davidl_Df250PulseData/src/libraries/TTAB/DTranslationTable.h <https://github.com/JeffersonLab/sim-recon/blob/davidl_Df250PulseData/src/libraries/TTAB/DTranslationTable.h>

Regards,
-David

> On Sep 15, 2016, at 7:18 PM, Alexander Somov <somov at jlab.org> wrote:
> 
> 
> Hi Sean,
> 
> The pedestal sum (14 bits) is reported by the
> firmware. Pedestals are summed in a window
> with programmable size  (Min = 4 samples
> and Max = 15 samples). I guess that David is
> not normalizing pedestals in Df250PulsePedestal.
> The window size will be stored in rcdb and
> data stream (the default value is 4 samples).
> 
> Quality bits reported by fadc:
> 
> -----------------------------
> a) pedestal quality (bit 14)
> It is set to 1 if any of amplitudes in the
> pedestal window are larger than a threshold
> (programmable parameter, defaulted to 512
> fadc counts) The threshold will be stored
> in the rcdb and data stream.
> 
> b) pulse integral quality (bits 9, 10, 11)
> bit 9  : one (or more samples) is underflow
> bit 10 : one (or more samples) is overflow
> bit 11 : NSA extends beyond the readout window
> 
> 
> c) time quality bit (bits 0, 1, 2)
> bit 1: peak cannot be found
> bit 2: peak is beyond NSA (or window end)
> 
> You can find more details about the format
> and processing in:
> 
> https://halldweb.jlab.org/level-1/manuals/FADC250/FADC250_Processing_FPGA_Firmware_ver_0x0C00_Description_Instructions.pdf
> 
> Cheers,
>      Alex
> 
> 
> 
> 
> On Thu, 15 Sep 2016, Sean Dobbs wrote:
> 
>> Hi David,
>> 
>> Thanks a lot for the update.  Did you push the branch to the github
>> server?  I see a branch with that name there, but it's 7 days old.
>> 
>> Also, is there a copy of the data format specification that exists?  I'm
>> particularly curious:
>> 1) If the pedestal value is reported in the same way as the previous
>> firmware (i.e., it corresponds to the pedestal for a single sample)
>> 2) How firmware errors are reported, or what QF values we need to worry
>> about to start off with.
>> 
>> Hopefully we'll get some data soon to test this with =)
>> 
>> Cheers,
>> Sean
>> 
>> 
>> On Thu, Sep 15, 2016 at 1:04 PM David Lawrence <davidl at jlab.org> wrote:
>> 
>>> Dear fADC250 fans,
>>> 
>>>  I have just pushed some changes to a branch (davidl_Df250PulseData) to
>>> support
>>> the new f250 firmware at the digihit level for all detectors. As you may
>>> know, the new
>>> firmware includes a new data type that combines information previously
>>> spread over
>>> the following classes:
>>> 
>>> Df250PulseIntegral
>>> Df250PulseTime
>>> Df250PulsePedestal
>>> 
>>> The new class that reflects this new data type is:
>>> 
>>> Df250PulseData
>>> 
>>> 
>>> The digihits actually did not require much change since they already
>>> contained
>>> members to hold values from the 3 older classes. The changes are:
>>> 
>>> 1. The “pulse_peak" value is now a member of all digihit classes derived
>>> from fADC250 data
>>> (BCAL already contained this, but now all others do as well)
>>> 
>>> 2. A new member “datasource” has been added that will be set to “1” for
>>> the old firmware
>>> and “2” for the new firmware. This may also be set to “0” if the emulate
>>> flag is set
>>> indicating that the values were derived from Window Raw Data
>>> 
>>> 3. The QF value is now a combination of 7 quality factor bits when the
>>> data comes
>>> from the new firmware. i.e. Interpretation of the QF value should depend
>>> on the value
>>> of “datasource”.
>>> 
>>> 
>>> Finally, one additional piece of information available in the new firmware
>>> is the
>>> "nsamples_over_threshold”. Currently, this is available in the
>>> Df250PulseData
>>> which may be obtained from the digihit via the Associated Objects
>>> mechanism.
>>> I did not add an additional member to all digihits to hold another copy of
>>> this
>>> value. If there is strong desire to make an additional copy of this value
>>> at the digihits
>>> level then we can do that. We could also consider adding it as some higher
>>> bits
>>> to the QF value.
>>> 
>>> I will likely put a pull request in for this soon. If I get a file with
>>> the new format soon
>>> I will test it on that first. Otherwise, I’ll just put in the pull request
>>> and we can debug
>>> it on the master.
>>> 
>>> Regards,
>>> -David
>>> 
>>> 
>>> _______________________________________________
>>> Halld-offline mailing list
>>> Halld-offline at jlab.org
>>> 
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.jlab.org_mailman_listinfo_halld-2Doffline&d=CwIGaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=y4ZD58I4nPR6tZqjerSGt-WlWVAhqa3FHDMXqQ_5aUc&m=nV9B_NzFm4Wp643jryzHDXn8hC4rn_JEazxyFcYVU7s&s=XmVLRyBPhg9xKSjIfBf1QkX1QJPc4OegsI4fvk-WyZw&e=

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20160915/483b6daa/attachment-0002.html>