Difference between rates measured in list mode vs shift register

[davidbrought]

It looks like there could be some sort of background being subtracted from the list mode rates results that isn't showing in the output.

These are 2 measurements with background set to 0 cps and using the same neutron pulse simulator settings and detector parameters. They have pretty much the same Passive cycle DTC rate data, but different passive results. Measurement output files with background set to 0 cps (for singles, doubles, triples): ptr list mode results (background set to 0).txt jsr15 results (background set to 0).txt

Then the same thing with the background set to 10 cps and there is still nearly the same difference between the list mode and shift register measurements.. I'm not sure if I am missing something, it seems strange that it's close to the same difference between the rates in both cases. Measurement output files with background set to 10 cps (for singles, doubles, triples): ptr list mode results (with background of 10 cps).txt jsr15 results (background of 10 cps).txt

This was using a PRT-32 and JSR-15.

[jflongo]

Great test, thank you. I'll review the details in the morning (here)

Sent from my iPhone

On 19 Dec 2016, at 21:44, "notifications@github.commailto:notifications@github.com" notifications@github.com<mailto:notifications@github.com> wrote:

It looks like there could be some sort of background being subtracted from the list mode rates results that isn't showing in the output. This was using a PRT-32 and JSR-15.

These are 2 measurements with background set to 0 cps and using the same neutron pulse simulator settings and detector parameters. They have pretty much the same Passive cycle DTC rate data, but different passive results.

Measurement output files with background set to 0 cps (for singles, doubles, triples): ptr list mode results (background set to 0).txthttps://github.com/hnordquist/INCC6/files/662055/ptr.list.mode.results.background.set.to.0.txt jsr15 results (background set to 0).txthttps://github.com/hnordquist/INCC6/files/662054/jsr15.results.background.set.to.0.txt

Then the same thing with the background set to 10 cps and there is still the same difference between the list mode and shift register measurements.. I'm not sure if I am missing something, it seems strange that it's close to the same difference between the rates in both cases. Measurement output files with background set to 10 cps (for singles, doubles, triples): ptr list mode results (with background of 10 cps).txthttps://github.com/hnordquist/INCC6/files/662070/ptr.list.mode.results.with.background.of.10.cps.txt jsr15 results (background of 10 cps).txthttps://github.com/hnordquist/INCC6/files/662071/jsr15.results.background.of.10.cps.txt

� You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/hnordquist/INCC6/issues/137, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGpMnoAEYWgnK8ki5M0KiWBMocEYH6iZks5rJuyIgaJpZM4LRKls.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

[jflongo]

Yeah something really wrong with the LM SDT summaries here, did you collect original 15 .bin files? Each cycle looks good, but the summary calculation is way off. Are they multichannel counts or just a single channel? Can you provide the related csv files? It has more info on the LM details.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

[davidbrought]

So far it's just been single channel measurements.

Here are the other files for where the background was set to zero: background set to zero.zip

Looking at the csv it has the correct 24 us gate width on line 8, but is using 20 us for the channel hits per second (starting line 309). I tried another analysis with the gate set to 30 us and the channel hits per second still used 20 us.

[hnordquist]

Joe, when I read in these same files, it counts up the count time as 3.3 s and all is cray cray.

[davidbrought]

For me reanalyzing from the files in that .zip I get a count time of 0.249 s per cycle (total time 3.735 s).

This is the output: reanalyzing data.zip

[hnordquist]

Yes, that jives with the total count time I got.

[jflongo]

Ok I will dig into it

Sent from my iPhone

On 20 Dec 2016, at 23:17, "notifications@github.commailto:notifications@github.com" notifications@github.com<mailto:notifications@github.com> wrote:

For me reanalyzing from the files in that .zip I get a count time of 0.249 s per cycle.

This is the output: reanalyzing data.ziphttps://github.com/hnordquist/INCC6/files/664895/reanalyzing.data.zip

� You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/hnordquist/INCC6/issues/137#issuecomment-268375353, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGpMngrEWnVAYh1Ob63EKap3FR6sJU1uks5rKFPegaJpZM4LRKls.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

[hnordquist]

Joe, see issue #137. We think they are related. And, why are you awake?

[davidbrought]

Retried this with higher rates (cps values of 100000 singles, 10000 doubles, 1000 triples) and it is able to pretty closely match the original time and rates results during reanalysis. There is still a big difference between the gate width values at the bottom of the csv files depending on if it's an initial or a reanalysis, but that doesn't seem to make much difference in the rate calculation.

The .bin files are too large to post, but these are results: higher rates.zip

[hnordquist]

OK, so now I can get a live measurement to give me roughly 3 cycles of ~100 cps. However, the singles rate comes in at ~60. The measured singles is derived from totals (hits) per cycle/count time, which is far lower than the count rates.

[hnordquist]

OK, theory of two different errors going on. First, in Ptr32Instrument.....

The while loop currently stops when elapsed time does and leaves some uncounted things in a buffer. We tested this by adding the code shown below:

            while (stopwatch.Elapsed < duration) {
                cancellationToken.ThrowIfCancellationRequested();

                if (m_device.Available > 0) {
                    int bytesRead = m_device.Read(buffer, 0, buffer.Length);

                    if (bytesRead > 0) {
                        RDT.PassBufferToTheCounters(buffer, 0, bytesRead);
                        total += bytesRead;
                    }
                }
            }

            //If there is something left, count it. HN
            if (stopwatch.Elapsed >= duration)
            {
                System.Threading.Thread.Sleep(5000);
                if (m_device.Available > 0)
                {
                    int bytesRead = m_device.Read(buffer, 0, buffer.Length);

                    if (bytesRead > 0)
                    {
                        RDT.PassBufferToTheCounters(buffer, 0, bytesRead);
                        total += bytesRead;
                    }
                    stopwatch.Stop();
                }
            }

If you do this, you'll get the expected # of hits.......

Now, the cycle singles and measurement singles are quite off before that. Theory is that cycles calculate singles by hits/tics (which will statistically be 100 in our case) while total takes tics (singles) / delta t = fubar = less than half the actual count rate.

So, that is problem #1.

Problem #2 has to do with you storing absolute times instead of delta times. The ulong is overflowing. I tested this by adding a conditional to my debugger in the Ptr32Parser where the buffer is read and m_time += time (line 137)

Set the condition to be >= the maximum ulong.......

So, our time array is also fubar.

I'm off for Christmas break, but at least now we know where to look.

[jflongo]

This is most likely a cycle summing issue based on the QC status of the cycle. I will figure it out.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

[jflongo]

Hello, working now with Mr Taehoon Lee/IAEA on PTR-32 and MCA testing. Taehoon notes there is a known problem with the PTR-32 and low count background rates. The issue has been reported and discussed with the PTR-32 vendor, and a fix is planned for 2017.

[hnordquist]

Well, I can get all the counts with an added pause there. Please keep me posted..... I'll be in the office in about 1.5 hours.

On Tue, Feb 7, 2017 at 3:06 AM, J F Longo notifications@github.com wrote:

Hello, working now with Mr Taehoon Lee/IAEA on PTR-32 and MCA testing. Taehoon notes there is a known problem with the PTR-32 and low count background rates. The issue has been reported and discussed with the PTR-32 vendor, and a fix is planned for 2017.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hnordquist/INCC6/issues/137#issuecomment-277954221, or mute the thread https://github.com/notifications/unsubscribe-auth/AFqkL3lXdkJZYDa8tKlZf6bMpHdRgbIvks5raEI8gaJpZM4LRKls .