[subexp-daq] Strange instability of the event counter register of the CAEN V767 module

[Hans Toshihide Törnqvist]

Dear Günter,

It looks to me like this happens when configuring the module, i.e. 
setting windows, operating mode etc? And not in the "inner" readout loop?

 From the manual, it seems like one has to wait 2 seconds (oof) after 
the soft-reset, and do polling of the the micro-controller 
communication. An additional sleep of 100 ms after the complete setup 
seems fine.

Some Caen and Mesytec implementations already sleep in many places 
during initialization, and the v1n90 modules also have the TDC 
micro-controller support.

A small schematic for an idea what registers are touched in the modules:

init {
  init_slow {
    mapping, one-time settings
  }
  init_fast {
   all other settings
   sleep to let the module settle
  }
  (post_init optional)
}
loop {
  readout_dt {
   read module counter, typically a 32-bit reg-read
   if available, read buffer size, another 16/32-bit reg-read
  }
  (release dt optional)
  readout {
   read buffer {
    either a loop with 32-bit reg-reads from event-fifo,
    or block transfer
   }
  }
}

So during the readout loop the tests you made should not be a concern, 
if I understood it correctly?

Two requests:

- Could you make the 2 seconds soft-reset sleep a config with the 
default value 2 s? Software tests can then set it to 0 s.

- I'm guessing it's sufficient to wait for ~100 ms at the end of 
init_fast for the internals to be ready, please make also this configurable.

Since an increasing event-counter relies on external triggers, I don't 
see how it could be used while setting up the DAQ before running, a 
"time_sleep(0.1);" or a bit longer ought to work.

Happy weekend,
Hans

On 2024-03-01 16:16, Weber, Guenter Dr. wrote:
> Dear friends,
> 
> 
> we just noticed that the value that is read from the event counter 
> register (Base + %004C) of V767 is not stable during times when the 
> module does internal operations. To demonstrate this we used the 
> following code:
> 
> 
> last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter);
> write_op(caen_v767a->sicy_map, 0x1000); /* set mode of operation */
> t = time_getd();
> while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, 
> event_counter) )
> {
>      usleep(1);
> }
> t = time_getd() - t;
> LOGF(info)(LOGL, NAME" TIME is %f", t);
> 
> last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter);
> window_setting = config_get_int32(caen_v767a->module.config, KW_WIDTH, 
> CONFIG_UNIT_NONE, 0x0001, 0x84D0);
> write_op(caen_v767a->sicy_map, 0x3000); /* set time window length */
> write_op(caen_v767a->sicy_map, window_setting);
> t = time_getd();
> while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, 
> event_counter) )
> {
>      usleep(1);
> }
> t = time_getd() - t;
> LOGF(info)(LOGL, NAME" TIME is %f", t);
> 
> last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter);
> window_setting = config_get_int32(caen_v767a->module.config, KW_OFFSET, 
> CONFIG_UNIT_NONE, 1 - 320000, window_setting + 2000 - 1);
> write_op(caen_v767a->sicy_map, 0x3200); /* set time window offset */
> write_op(caen_v767a->sicy_map, window_setting);
> t = time_getd();
> while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, 
> event_counter) )
> {
>      usleep(1);
> }
> t = time_getd() - t;
> LOGF(info)(LOGL, NAME" TIME is %f", t);
> 
> last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter);
> write_op(caen_v767a->sicy_map, 0x7000); /* set data ready status to 
> event ready */
> t = time_getd();
> while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, 
> event_counter) )
> {
>      usleep(1);
> }
> t = time_getd() - t;
> LOGF(info)(LOGL, NAME" TIME is %f", t);
> 
> And the output in two trials was the following:
> 
> 
> 10: module/caen_v767a/caen_v767a.c:143: ..CEAN_V767A TIME is 0.000002
> 10: module/caen_v767a/caen_v767a.c:155: ..CEAN_V767A TIME is 0.000002
> 10: module/caen_v767a/caen_v767a.c:167: ..CEAN_V767A TIME is 0.055224
> 10: module/caen_v767a/caen_v767a.c:177: ..CEAN_V767A TIME is 0.000354
> 
> 10: module/caen_v767a/caen_v767a.c:143: ....CEAN_V767A TIME is 0.000002
> 10: module/caen_v767a/caen_v767a.c:155: ....CEAN_V767A TIME is 0.000002
> 10: module/caen_v767a/caen_v767a.c:167: ....CEAN_V767A TIME is 0.055223
> 10: module/caen_v767a/caen_v767a.c:177: ....CEAN_V767A TIME is 0.000387
> 
> Thus, we can conclude that the event counter register is set to some 
> fake value for up to almost 60 ms as a result of an internal operation 
> of the module. Only after this time, the register goes back to the real 
> value.
> 
> 
> We will now take care of this effect and after each WRITE_OP call wait 
> for the event counter to to gack to the original value. However, who 
> knows what happens in the other registers of the module (and for how long).
> 
> 
> As the event counter value is used as a sanity check in CRATE.C it might 
> make sense to check if some of the other CAEN modules also exhibit this 
> 'fascinating feature'.
> 
> 
> 
> 
> 
> Best greetings
> 
> Günter
> 
> 
> 
>