Closed cej25 closed 8 months ago
It would be good to not have the silly 'fake' detector 4 thing like in Go4, but make it more explicit
Also it might be useful in the config file to set thresholds (e.g. the SC41 signals should have a minimum ToT otherwise it's noise)
I have made a request in the ELOG for how I believe all allocation files should be structured. I have set up FATIMA VME to read them as such, and I can adjust the other subsystems too, but we'll discuss.
How does 0 based indexing work with TAMEX, which are basically 1 based index? (Ch0 = Trigger) ?
Hey I am changing this now, some mapping is done with the trigger in the background. I want the user to input physical channel on the twinpeaks board from 1-16. This is to implement a trigger corrected wr timestamp :)
How does 0 based indexing work with TAMEX, which are basically 1 based index? (Ch0 = Trigger) ?
This should still work though, right? In the mapping, sure the TAMEX channels will start at 1 because of this, but in a sense its already zero-based indexed because the source code acknowledges Ch0 is in use for the trigger?
Hey I am changing this now, some mapping is done with the trigger in the background. I want the user to input physical channel on the twinpeaks board from 1-16. This is to implement a trigger corrected wr timestamp :)
Not sure if you did, but can you check my ELOG post and see if there are any concerns? etc.
Ah well there you say that the channel 1 on the board should be channel zero - the tamex / twinpeaks manual labels the channel 1 - 16 (so no 0)
Ah well there you say that the channel 1 on the board should be channel zero - the tamex / twinpeaks manual labels the channel 1 - 16 (so no 0)
Ah ok, so it's not possible everywhere. That's fine, as long as we have clear rules for when and where
P.S. I don't think we will have analog SCI41 signals (it is up to Helena but I don't think it's a good idea) so you only need to account for digital
Configuration classes were added for each subsystem. When reading a detector map file, it can also read additional signals as long as they're labelled. If further signals are added to the same boards then the source code will need to be added to, but this is all.
These configuration classes can probably be used for a decent amount more too if necessary, much like TAidaConfiguration.
SC41L/R signals etc are also in channels of FATIMA, Germaniums etc.
We need a way for the software to understand these channels without having to hardcode them in source files. It would be nice if somehow the {sys}_alloc.txt file could provide both the full mapping and the identity of the additional signal channels? Rather than essentially defining them again in some "setup" header file.
For example in AidaFatimaCorrelations at the moment, we simply check if Detector_ID == 18 || 19, but these channels can change on a whim, and this may require changing in several places (easily forgotten exactly where).