<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi Sean,</div><div class=""><br class=""></div><div class=""> Looks like I didn’t specify the right “from” branch earlier. I think I’ve</div><div class="">committed the changes now.</div><div class=""><br class=""></div><div class="">The documentation on the first level FPGA firmware is here:</div><div class=""><br class=""></div><div class=""><a href="https://halldweb.jlab.org/level-1/manuals/FADC250/FADC250_Processing_FPGA_Firmware_ver_0x0C00_Description_Instructions.pdf" class="">https://halldweb.jlab.org/level-1/manuals/FADC250/FADC250_Processing_FPGA_Firmware_ver_0x0C00_Description_Instructions.pdf</a></div><div class=""><br class=""></div><div class="">The second level is written by someone else and adds the block headers</div><div class="">but otherwise I believe the data format is driven by this.</div><div class=""><br class=""></div><div class="">I’ve written the parsing to place the individual quality factor bits into their</div><div class="">own members in Df250PulseData. For the digihits though I compressed</div><div class="">them all back into the existing QF member. I did not place any documentation</div><div class="">on those bit assignments anywhere, but you can see them in </div><div class="">DTranslationTable::CopyDf250Info. Lines 533-539 here:</div><div class=""><br class=""></div><div class=""><a href="https://github.com/JeffersonLab/sim-recon/blob/davidl_Df250PulseData/src/libraries/TTAB/DTranslationTable.h" class="">https://github.com/JeffersonLab/sim-recon/blob/davidl_Df250PulseData/src/libraries/TTAB/DTranslationTable.h</a></div><div class=""><br class=""></div><div class="">Regards,</div><div class="">-David</div><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 15, 2016, at 7:18 PM, Alexander Somov <<a href="mailto:somov@jlab.org" class="">somov@jlab.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">Hi Sean,<br class=""><br class="">The pedestal sum (14 bits) is reported by the<br class="">firmware. Pedestals are summed in a window<br class="">with programmable size (Min = 4 samples<br class="">and Max = 15 samples). I guess that David is<br class="">not normalizing pedestals in Df250PulsePedestal.<br class="">The window size will be stored in rcdb and<br class="">data stream (the default value is 4 samples).<br class=""><br class="">Quality bits reported by fadc:<br class=""><br class="">-----------------------------<br class="">a) pedestal quality (bit 14)<br class="">It is set to 1 if any of amplitudes in the<br class="">pedestal window are larger than a threshold<br class="">(programmable parameter, defaulted to 512<br class="">fadc counts) The threshold will be stored<br class="">in the rcdb and data stream.<br class=""><br class="">b) pulse integral quality (bits 9, 10, 11)<br class="">bit 9 : one (or more samples) is underflow<br class="">bit 10 : one (or more samples) is overflow<br class="">bit 11 : NSA extends beyond the readout window<br class=""><br class=""><br class="">c) time quality bit (bits 0, 1, 2)<br class="">bit 1: peak cannot be found<br class="">bit 2: peak is beyond NSA (or window end)<br class=""><br class="">You can find more details about the format<br class="">and processing in:<br class=""><br class=""><a href="https://halldweb.jlab.org/level-1/manuals/FADC250/FADC250_Processing_FPGA_Firmware_ver_0x0C00_Description_Instructions.pdf" class="">https://halldweb.jlab.org/level-1/manuals/FADC250/FADC250_Processing_FPGA_Firmware_ver_0x0C00_Description_Instructions.pdf</a><br class=""><br class="">Cheers,<br class=""> Alex<br class=""><br class=""><br class=""><br class=""><br class="">On Thu, 15 Sep 2016, Sean Dobbs wrote:<br class=""><br class=""><blockquote type="cite" class="">Hi David,<br class=""><br class="">Thanks a lot for the update. Did you push the branch to the github<br class="">server? I see a branch with that name there, but it's 7 days old.<br class=""><br class="">Also, is there a copy of the data format specification that exists? I'm<br class="">particularly curious:<br class="">1) If the pedestal value is reported in the same way as the previous<br class="">firmware (i.e., it corresponds to the pedestal for a single sample)<br class="">2) How firmware errors are reported, or what QF values we need to worry<br class="">about to start off with.<br class=""><br class="">Hopefully we'll get some data soon to test this with =)<br class=""><br class="">Cheers,<br class="">Sean<br class=""><br class=""><br class="">On Thu, Sep 15, 2016 at 1:04 PM David Lawrence <davidl@jlab.org> wrote:<br class=""><br class=""><blockquote type="cite" class="">Dear fADC250 fans,<br class=""><br class=""> I have just pushed some changes to a branch (davidl_Df250PulseData) to<br class="">support<br class="">the new f250 firmware at the digihit level for all detectors. As you may<br class="">know, the new<br class="">firmware includes a new data type that combines information previously<br class="">spread over<br class="">the following classes:<br class=""><br class="">Df250PulseIntegral<br class="">Df250PulseTime<br class="">Df250PulsePedestal<br class=""><br class="">The new class that reflects this new data type is:<br class=""><br class="">Df250PulseData<br class=""><br class=""><br class="">The digihits actually did not require much change since they already<br class="">contained<br class="">members to hold values from the 3 older classes. The changes are:<br class=""><br class="">1. The “pulse_peak" value is now a member of all digihit classes derived<br class="">from fADC250 data<br class="">(BCAL already contained this, but now all others do as well)<br class=""><br class="">2. A new member “datasource” has been added that will be set to “1” for<br class="">the old firmware<br class="">and “2” for the new firmware. This may also be set to “0” if the emulate<br class="">flag is set<br class="">indicating that the values were derived from Window Raw Data<br class=""><br class="">3. The QF value is now a combination of 7 quality factor bits when the<br class="">data comes<br class="">from the new firmware. i.e. Interpretation of the QF value should depend<br class="">on the value<br class="">of “datasource”.<br class=""><br class=""><br class="">Finally, one additional piece of information available in the new firmware<br class="">is the<br class="">"nsamples_over_threshold”. Currently, this is available in the<br class="">Df250PulseData<br class="">which may be obtained from the digihit via the Associated Objects<br class="">mechanism.<br class="">I did not add an additional member to all digihits to hold another copy of<br class="">this<br class="">value. If there is strong desire to make an additional copy of this value<br class="">at the digihits<br class="">level then we can do that. We could also consider adding it as some higher<br class="">bits<br class="">to the QF value.<br class=""><br class="">I will likely put a pull request in for this soon. If I get a file with<br class="">the new format soon<br class="">I will test it on that first. Otherwise, I’ll just put in the pull request<br class="">and we can debug<br class="">it on the master.<br class=""><br class="">Regards,<br class="">-David<br class=""><br class=""><br class="">_______________________________________________<br class="">Halld-offline mailing list<br class="">Halld-offline@jlab.org<br class=""><br class="">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=<br class=""></blockquote></blockquote></div></div></blockquote></div><br class=""></body></html>