[subexp-daq] Question on DRASI and multiple triggers

[Håkan T Johansson]

Dear Günter,

That is indeed not wanted or expected.

I think the fast clear time or conversion time should not be the culprits 
here.  The start of the deadtime signal issued by the TRIVA should not 
depend on their length, but come rather soon after the trigger signals 
reach it.  With your setting of 'accept_window_len = 100 ns;' that ought 
to be well before the 'fast_busy_len = 1000ns;' goes away.

The data dump looks like two events, which are almost even identical?

I do not know what the V1190 does if it gets a double-signal (i.e. 
close-by, say order of 100 ns).  Does it then duplicate the actual hits 
into two events perhaps, with some time difference, corresponding to the 
difference in time between those two signals?


To make debugging easier, perhaps it is possible to provoke the behaviour 
with a high-rate, preferably random, trigger?  E.g. something like

dest <= PRNG_POISSON(1);
PRNG_POISSON(1).period = 100 k/s;

Cheers,
Håkan



On Tue, 30 Jul 2024, Weber, Guenter Dr. wrote:

> 
> Dear friends,
> 
> 
> this night we had the following error in one of our DAQ systems:
> 
> 
> 5: module/caen_v1n90/caen_v1n90.c:811: FIFO stored=2, but event_diff=1.
> 5: crate/crate.c:2067: POLARIMETER[3]=CAEN_V1190 readout error=0x00000010, dumping data:
> 10: crate/crate.c:2083: ---[ Dump begin ]---
> 10: crate/crate.c:2083: Start=0x33ede828  Bytes=104=0x68
> 10: crate/crate.c:2083:     0: 423cc123 08609e20 00484e77 008020c2 00c84626 18609005 09609e20 19609002
> 10: crate/crate.c:2083:    20: 0a609e20 1a609002 0b609e20 1b609002 800001a3 423cc143 0860ae23 00484b77
> 10: crate/crate.c:2083:    40: 00801dc2 00c84326 1860a005 0960ae23 1960a002 0a60ae23 1a60a002 0b60ae23
> 10: crate/crate.c:2083:    60: 1b60a002 800001a3
> 10: crate/crate.c:2083: ---[  Dump end  ]---
> 5: crate/crate.c:1554: POLARIMETER: readout failed!
> 5: crate/crate.c:1598: POLARIMETER: had problems, re-initializing.
> 10: crate/crate.c:688: crate_deinit(POLARIMETER) {
> 10: crate/crate.c:712: crate_deinit(POLARIMETER) }
> 10: crate/crate.c:986: crate_init(POLARIMETER) {
> 10: crate/crate.c:1010: .Slow-init module[0]=GSI_VULOM.
> LOG: TRLO: MD5SUM: 0x6e4ba1a9 (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC)
> 10: crate/crate.c:1010: .Slow-init module[1]=CAEN_V785.
> 10: module/map/map.c:263: ....rd(0x44440000+0x103c/16)=598ns wr(0x44440000+0x103c/16)=433ns.
> 10: crate/crate.c:1010: .Slow-init module[2]=CAEN_V785.
> 10: module/map/map.c:263: ....rd(0x11110000+0x103c/16)=630ns wr(0x11110000+0x103c/16)=470ns.
> 10: crate/crate.c:1010: .Slow-init module[3]=CAEN_V1190.
> 10: module/map/map.c:263: ...rd(0x22220000+0x1028/32)=635ns wr(0x22220000+0x1028/32)=458ns.
> 10: crate/crate.c:1063: .Fast-init module[0]=GSI_VULOM.
> 10: crate/crate.c:1063: .Fast-init module[1]=CAEN_V785.
> 10: crate/crate.c:1063: .Fast-init module[2]=CAEN_V785.
> 10: crate/crate.c:1063: .Fast-init module[3]=CAEN_V1190.
> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime.
> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.  Status: 0x10 (IN_READOUT).  EC: 51504652
> 10: lwroc_triva_state.c:2428: [EB lyserv:7000] EB: Status: 0x0.
> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...
> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime.
> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.  Status: 0x10 (IN_READOUT).  EC: 51504652
> 10: lwroc_triva_state.c:2428: [EB lyserv:7000] EB: Status: 0x0.
> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...
> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime.
> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.  Status: 0x10 (IN_READOUT).  EC: 51504652
> 10: lwroc_triva_state.c:2428: [EB lyserv:7000] EB: Status: 0x0.
> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...
> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime.
> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.  Status: 0x10 (IN_READOUT).  EC: 51504652
> 10: lwroc_triva_state.c:2428: [EB lyserv:7000] EB: Status: 0x0.
> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...
> 10: crate/crate.c:1160: crate_init(POLARIMETER) }
> 5: f_user.c:1257: had readout error, ret=0x10, trigger=1, prev=1
> 
> After this error the DAQ recovered and just continued. The obtained data (so far) looks fine.
> 
> 
> To my understanding, the only possibility to get two events in the FIFO of the TDC module is that the TDC module receives a second trigger before it is
> cleared. However, in our setup the TDC is triggered by a signal generated by the VULOM upon acceptance of a DAQ readout trigger. And after each readout
> the TDC should get cleared. Thus, two consecutive triggers of the TDC module before it is readout an cleared should never happen. And, indeed it almost
> doesn't happen. But once in a while (after millions and millions of events), it does happen.
> 
> 
> Do you guys know a scenario where the observed behaviour is to be expected? And it it possible that this is connected somehow to the DRASI settings of the
> conversion time or something else?
> 
> 
> 
> 
> Thanks a lot!
> 
> 
> 
> 
> 
> Best greetings from Jena
> 
> Günter
> 
> 
> 
> 
> 
> 
> 
>