IslandLength Plots look weird (e.g. Al50(b), Figure 61)

[AndrewEdmonds11]

In today's meeting, Aji pointed out that some of the IslandLength plots look a bit weird, especially for the CAEN (e.g. Al50(b), Figure 61).

One thing we should check is that MDQ_IslandLength is actually plotting what we expect it to. I will update this issue once I've looked into it

[AndrewEdmonds11]

I have just checked and it looks like this module is doing what we expect. In MDQ_IslandLength.cpp on lines 129-130, it shows that the size of the samples vector is filled into the histogram. So this is not the problem with the IslandLength plots.

I will rename this issue so we can keep discussing it here.

[litchfld]

I don't see any obvious problems in this function either, although there is an unnecessary copy of the vector on line 129. I think we use -O2 optimizer level so perhaps it is elided, but it would be better to make theSamples a (const) vector&, just to be sure. Or just get the size() directly on this line.

[jrquirk]

Aji and I were talking about it, and one thought is that the less-than-600 samples are actually tails of 600+ sample pulses.

On page 18 of the CAEN DT5720 manual, it states that if there is a trigger mode such that if there is a second trigger (such as if the GeS signal goes over threshold a bit after the GeF one) N samples after the first trigger, then an additional pulse will be measured immediately following first that is N samples long.

This might explain it. A check would be to see if the first sample of a shorter island is the next clock tick from the previous island.

[AndrewEdmonds11]

So when should we check this? Can someone write a quick alcapana module now and test on a single run before the next production run? It might mean we have to change a ProcessRaw module to make sure we get the full pulse shape.

[AndrewEdmonds11]

So I saw these keys in the ODB:

[/Equipment/Crate 5/Settings/CAEN]
waveform length = DWORD : 64

and

[/Equipment/Crate 4/Settings/CAEN0]
waveform length = DWORD : 600

which are the BU and UH CAEN's respectively. This seems to match what we remember that the digitised pulses were set to be a specific length.

[jrquirk]

Below is a copy of an email I got from CAEN. In short, we need to change the ProcessRaw anyway. The is probably

1. Get the time
2. Get the number of presamples (BU: /Equipment/Crate 5/Settings/CAEN/post_trigger_size, UH: Default?)
3. When making the TPulseIsland, subtract off number of ticks to get the tick of the first sample
4. Profit

Hello John,

here is Marco and I hope you are doing fine. Thanks for your question: the answer you thought is the correct one. A trigger (and its relative TTT) is issued as soon as one channel goes over-threshold and the TTT refers to the first sample over-threshold. The first sample in a window is not taken into account when dealing with TTT. Please note that with Standard FW the over-threshold signal is sent from the channel to the motherboard that generate the trigger for all the channels in the board. The motherboard trigger Logic clock is generally different from the sampling clock but in the 724 family. This means that the uncertainty of the TTT is 10 ns for a 724 digitizer, while it is 8 ns (Trigger Logic clock 125 MHz) for the 720 Family. I hope this information will help, otherwise please do not hesitate to contact me.

By the way, I will attend the Neutrino Conference at BU next week. If you will be around and would like to stop at the booth I will be pleased to meet you. I will try in any case to find sometime to come to the Physics Dept as well.

Thanks and Regards, Marco.

Il 26/05/2014 12:04, Monica Farnocchia ha scritto:

-------- Messaggio originale -------- Oggetto: CAEN Eletronic Instr. - Richiesta informazioni Data: Fri, 23 May 2014 02:25:12 +0200 Mittente: jrquirk@buphy.bu.edu A: info@caen.it

Richiesta informazioni da: http://www.caen.it

Name: John Quirk Country: US Company: Boston University Phone: 6178344735 Mail: jrquirk@buphy.bu.edu Message: To whom it may concern,

I have a question about the Trigger Time Tag delivered to us from our DT5720 and V1724, both >with the standard firmware. We have them set up to trigger when an enabled channel goes over >threshold.

Is the TTT the time of the first sample, or the time of the trigger when a channel goes over >threshold? We're pretty sure as the second, but we decided it wise to check.

Thank you for any help you can provide!

Cheers, --John Q. Consenso: Si

Marco Locatelli Field Application Scientist CAEN Technologies, Inc. 1140 Bay Street - Suite 2C Staten Island, NY 10305 Phone: +1 (718) 981-0401 Mobile: +1 (718) 501-5309 Fax: +1 (718) 556-9185 www.caentechnologies.com

---

Le informazioni trasmesse attraverso la presente comunicazione via mail ed eventuali allegati sono da intendersi di esclusiva spettanza del destinatario. Nel caso in cui le stesse raggiungessero, per qualunque motivo, soggetti diversi dai destinatari,questi dovrebbero darne immediata notizia al mittente. In ogni caso, eventuali soggetti diversi dai legittimi destinatari della presente comunicazione sono esplicitamente diffidati da ogni utilizzazione, sia ai sensi del D.Lgs. n.196/2003 "Codice in materia di protezione dei dati personali" sia ai sensi degli art.616 e ss.Codice Penale che sanziona la violazione del segreto sulla corrispondenza.

The information contained in this transmission may contain privileged and confidential information and is intended only for the use of the person(s)named above. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender immediately

and destroy all copies of the original message.

[jrquirk]

I've assigned myself to this issue. I'm starting a new hotfix branch in an effort to learn more about git-flow at the same time.

[AndrewEdmonds11]

Cool. I've done a hotfix before and it is basically the same commands as a feature branch except that it will be merged into both develop and master when you "finish" it.

Also, I'm trying to understand the issue. Is it that the timestamp we get is the timestamp of the first sample above threshold and not the start of our TPulseIsland? And how does this relate to our pulses being too short problem?

[jrquirk]

This merits an elog I guess.

The timestamp we get from the CAEN is the timestamp of the trigger. For us, it's exactly what you said; the trigger is the first channel to pass threshold. For context, the threshold for many (if not all) runs for the UH CAEN seems to be when the signal passes above threshold. The fast Ge and slow Ge amplifiers are the only ones plugged into the UH CAEN for most of the Golden Runs. The fast pulse is negative, and the slow pulse positive. Because the fast pulse most often arrives first, it triggers when it's returning to baseline. Often just a couple of samples later the slow pulse will trigger again on the rising edge. So now we get a fast and slow pulse with a timestamp of when the fast pulse is relaxing beyond the threshold, which is often ~100 samples after the first in the island. Then we get an uneventful few samples afterwards from both that has a timestamp of when the slow pulse passed over threshold (which tends to be ~500 samples before the first sample in this short island). This is the pulse-too-short issues. But you're right, this is for the most part a separate issue.

As a tangent, when we calculate the time we calculate clock_tick_length_peak_sample, but what we should be calculating is clock_ticklength(peak_sample-number_of_presamples). My plan is to change the ProcessRaw method to subtract off the number of presamples before making the TPI, that way we can use the same GetTime methods in alcapana.

Pictures will undoubtedly help, which I'll try make today.

[dmalexan]

I was made a root file with the first 100 samples from Ge-F and Ge-S for run 3204. It also has a plot of the timestamps with bin widths roughly equivalent to a single event. We can see most events get a second trigger, with a few getting as many as four signals.

I also generated a text output.

for pulse number 1_Ge-F : Timestamp 494 time 30628.1 Length 500 for pulse number 2_Ge-F : Timestamp 34412 time 2.13355e+06 Length 600 for pulse number 3_Ge-F : Timestamp 34424 time 2.13429e+06 Length 12 for pulse number 4_Ge-F : Timestamp 66464 time 4.12078e+06 Length 600 for pulse number 5_Ge-F : Timestamp 66470 time 4.12115e+06 Length 6 for pulse number 6_Ge-F : Timestamp 66474 time 4.1214e+06 Length 4 for pulse number 7_Ge-F : Timestamp 80340 time 4.98109e+06 Length 600 for pulse number 8_Ge-F : Timestamp 80348 time 4.98159e+06 Length 8 for pulse number 9_Ge-F : Timestamp 80540 time 4.99349e+06 Length 192 for pulse number 10_Ge-F : Timestamp 116476 time 7.22153e+06 Length 600 for pulse number 11_Ge-F : Timestamp 116484 time 7.22202e+06 Length 8 for pulse number 12_Ge-F : Timestamp 116674 time 7.2338e+06 Length 190 for pulse number 13_Ge-F : Timestamp 131670 time 8.16356e+06 Length 600 for pulse number 14_Ge-F : Timestamp 132070 time 8.18836e+06 Length 400 for pulse number 15_Ge-F : Timestamp 132076 time 8.18873e+06 Length 6 for pulse number 16_Ge-F : Timestamp 184478 time 1.14377e+07 Length 600 for pulse number 17_Ge-F : Timestamp 184482 time 1.14379e+07 Length 4 for pulse number 18_Ge-F : Timestamp 185094 time 1.14759e+07 Length 600 for pulse number 19_Ge-F : Timestamp 185100 time 1.14762e+07 Length 6 for pulse number 20_Ge-F : Timestamp 265340 time 1.64511e+07 Length 600

We should be able to stitch them together based on the difference between timestamps. I'll try and work up a method in the ProcessRaw this week. (I'll also double check the signals from the BU CAEN).

[jrquirk]

See elog https://muon.npl.washington.edu/elog/mu2e/Analysis-R13/98 I'm working on the same thing. Let's discuss it tomorrow to avoid redundancy.

Additionally, there's a pulse viewer in analyzer/scripts:

$ cd AlcapDAQ/analyzer/scripts
$ root -l
[0] .x load_pulse_viewer.c
[1] view_pulses("tree_file.root")

You can choose the detector and flip through pulses one after another. It'll give you the timestamps in the standard out as well for comparison. Building the detector list can take a minute or two (after running view_pulses(fname) it may hang for a bit).

[AndrewEdmonds11]

So looking at these three pulses in Damien's output:

for pulse number 7_Ge-F :
Timestamp 80340 time 4.98109e+06 Length 600
for pulse number 8_Ge-F :
Timestamp 80348 time 4.98159e+06 Length 8
for pulse number 9_Ge-F :
Timestamp 80540 time 4.99349e+06 Length 192

We can see that we can answer Phill's question from last time (i.e. 192 is the number of ticks from the previous trigger and not the first).

But I'm a little confused as to what the third thing is. The first two (from John's elog) are the fast and slow pulses but if the third one is another fast pulse, would we not expect a fourth island from the slow?

Damien, if you have time before the meeting (I know it'll be early for the US), could you plot these three pulses for both Ge-F and Ge-S? They don't need to be stitched but just seeing them one at a time would be useful.

[dmalexan]

For the fast channel

And the slow channel

[AndrewEdmonds11]

Thanks, Damien. I was hoping it would be obvious which was the trigger... Anyway, I'll guess we'll discuss more in a bit

[jrquirk]

I'll post a picture in response to elog 98

[AndrewEdmonds11]

Hi John! I have a couple of questions about the plots in elog:103 and elog:104.

In elog:104, why do we still see islands with less than 600 samples long. I realise this is a log plot and has been normalised so I guess this is very few events but just wondering if this can be explained (do we want both normalised and non-normalised versions of the plots?).

In elog:103, are all four columns consecutive to each other as well? i.e. Are they all from the same reset pulse or are the later ones actual hits?

[jrquirk]

The pulses less than 600 I can't explain yet. I've gone through some of the raw pulses, and thus far have only seen them as the first pulse of a MIDAS block. This is far from a methodical examination though and I guess should be examined... I was just so happy to see only a few I didn't put much thought into it.

The pulses from left to right are all one after another. The pulse that would've been fifth in the series isn't shown because it's normal for both the slow and fast channels. This is a single reset, yes. I'll clarify in the elog.

[benkrikler]

I think we see that peak around 500 samples in the pulse length plot. My guess is that the few pulses between 500 and 600 samples are being stitched onto pulses from the 500 sample peak.

Is there a CAEN issue that occasionally (around 0.5% of the time) produces a 500 sample trigger window and not a 600 sample one? I also remember hearing that we had 100 samples in the presample. Could some pulses not be being getting presampled?

[benkrikler]

Also, this is physics discussion, should we copy it onto the elog in reply to 104?

[jrquirk]

I don't understand what you're saying about the 500 sample peak.

Two more things. This is much less than 0.5% because the histogram is log and continues on past the upper bound. But more to the point, I don't know about other types of triggers. My initial guess would be "no," but there is something going on here and maybe that's in the manual somewhere. You raise a really good point with the missing presamples. Perhaps it is possible that if the acquisition window is opened (the MIDAS block is started) and there's a trigger less than the presample length later, then this will happen. We should see only these short pulses at the beginning of a block (which is what I've noticed so far), and the pulse itself should be closer to the beginning of the TPulseIsland start.

An elog was started.

[benkrikler]

In the pulse length plots on the bottom row, out of the pulses with fewer than 600 samples, there is a definite peak at around 500 samples. We saw it in Aji and Damien's plots last week as a fainter band compared to the stripe at 600 samples in the 2D full dataset plots.

If something in the DAQ can produce triggers that last 500 samples, and in that time we get a second trigger, then I'm guessing we would now stitch the second set of samples onto the the first 500, which would then give pulses with 500 -> 600 samples.

And what you say makes total sense. If the detector is above trigger threshold when the acquisition window opens then the buffer wont have anything it to read out as presample, so I guess nothing is written out. Looking at the pulses would be the simplest thing to check that. If that is the explanation however, wouldn't we expect an even distribution from 500 to 600 samples?

[jrquirk]

The 500 sample pulse would get stitched onto the pulse before it unless there were no pulses before it because it's less than 600 samples. All pulses less than 600 samples are assumed to be continuations of the pulse before them.

You're right, we would expect it to be smooth. It's still worth looking into but this makes it look not quite as promising...

[benkrikler]

But there wouldn't be any pulses before it if they're at the start of the midas event right?

Are you checking the timestamps make sense before you stitch then? Didn't we say the timestamp would be from when the second signal arrived? If so, wouldn't we be able to check if the timestamp overlaps with a previous pulse.

[jrquirk]

You're right on both counts. I should be checking the timestamps. Which I have not done yet for various legitimate not-just-making-excuses reasons which I won't bore anyone with. But it is on my to do list:

[jrquirk]

I haven't done a systematic check yet. But before I left I checked the first ~100 of the events from the GeS/GeF of run 3275 and all of them checked out in that the afterpulse length is equal to the trigger time difference. I think this is okay for this next production run since there been no indication that this will be a problem. I'll put a sanity check in the code before our final alcapana run.

[AndrewEdmonds11]

Sorry for going back a few comments but if the signal is above threshold when the MIDAS event starts and there aren't 100 presamples to take, doesn't the CAEN just read up to 600 samples anyway and end up taking more samples later on?

[litchfld]

Hm... we need to understand which part of the system is doing what. My naive expectation is that CAEN waveform digitiser would be filling a circular buffer continually even when MIDAS is busy doing other things. So when a trigger arrives the presample should always be available...

I had a look for CAEN preamps, and my browser history has a search for "CAEN DT5720", so I'm assuming this is the correct model(?) [Edit: No it's the V1724. The relevant part of the documentation seems to be the same for this model though, and they use the same FPGA.] The user manual states (ss 3.3.2)

A trigger can be refused for the following causes:

• [...]
• memory is FULL and therefore there are no available buffers
• the required number of samples for building the pre-trigger of the event is not reached yet; this happens typically as the trigger occurs too early either with respect to the RUN_ACQUISITION command (see § 3.3.1) or with respect to a buffer emptying after a MEMORY_FULL status

So it seems like a properly behaving CAEN V1724 should not produce shorter pulses for either of the reasons suggested.

User manual for V1724: http://www.caen.it/csite/CaenProd.jsp?parent=11&idmod=483 (User manual for DT5720: http://www.caen.it/csite/CaenProd.jsp?parent=14&idmod=624)

[AndrewEdmonds11]

That's the BU CAEN. The UH CAEN, which is the one with the Ge detector, is V1724

[litchfld]

Updated previous comment accordingly. Turns out they have the same logic in this respect.

[jrquirk]

I did a check on run 3275, and 0.06% of pulses stitched onto the end of another lack the correct timestamp difference (by a several thousand at least, dt >10000 usually and nSamples < 10), and only 0.0007% are longer than 100 samples. I have a fix for this that I still need to debug, but it's low on the priority list due to the small effect.