Add eudaq producer #39
Conversation
| def enable_ext_trigger(self): | ||
| self['cmd'].set_ext_trigger(True) | ||
|
|
||
| def disable_ext_trigger(self): | ||
| self['cmd'].set_ext_trigger(False) | ||
|
|
There was a problem hiding this comment.
Why is this needed? As far as I see, this is only relevant for RD53A chips with AZ flavors, according to the firmware. Anyway, there are no trigger commands sent to the chip.
There was a problem hiding this comment.
I don't know to be honest. But i will put this to the list and when the setup is working reliably, we can test removing it and see if there is any effect (probably not)
| # Send data of each trigger | ||
| for i in range(0, len(trigger_data) - 2): | ||
| dat = trigger_data[i] | ||
| glitch_detected = False |
There was a problem hiding this comment.
What kind of glitch is this? I never observed a glitching trigger number that is bit-shifted by 1?
| 'trigger_latency': 100, # latency of trigger in units of 25 ns (BCs) | ||
| 'trigger_delay': 57, # trigger delay in units of 25 ns (BCs) | ||
| 'trigger_length': 32, # length of trigger command (amount of consecutive BCs are read out) |
There was a problem hiding this comment.
None of these are needed in an untriggered device and anyway not used / commented out.
There was a problem hiding this comment.
You are right, i will clean this (and also the many comments regarding this)
| # The event building works in the following way | ||
| # Data from FIFO eg: | ||
| # D D D T0 D D D D T1 D D D D D T2 D D D T3 D D D D | ||
| # |<---0--->||<----1---->||<--2-->||<-------... (store for next execution) | ||
| # D ... data word, Tx ... Trigger word, |<-x->| ... EUDAQ event with trigger number x | ||
| # investigation of the Chip efficiency in a testbeam setup proved that when doing the event building in | ||
| # the way scetched above, some pixel hits got assigned with a wrong trigger number. Eg: | ||
| # D after T2 would actually still belong to T1 (shown by reconstruction with telescope setup) | ||
| # as an easy workaround we assign all the data to 2 trigger numbers | ||
| # with the scetch from above this looks like: | ||
| # D D D T0 D D D D T1 D D D D D T2 D D D T3 D D D D | ||
| # |<----------0---------->| | ||
| # |<--------1--------->| | ||
| # |<---------------------... next execution |
There was a problem hiding this comment.
This is something we should talk about and probably test during testbeam. With a proper veto length, triggers are vetoed in the TLU until all hit words are read out (effectively limiting the trigger rate, but to a very high value).
Hit duplication opens a lot of room for mistakes.
|
Since 3e024f0 is not related to the (important) PR with an eudaq producer, please move this into its own PR. |
Hi all,
I created this cleaner state of the eudaq producer, maybe now there is the time to ...
Let's talk about this when the VTX testbeam is running...