CTB fragment generator M. Roda
Class implementation ● TriggerBoardReader CTB_Controller – Creates the Fragment generator from a +send_config() +send_start() buffer of words +send_stop() +send_reset() ● CTB_Controller TriggerBoardReader – Simply send the control commands to the CommandableFragmentGenerator +getNext_() board +start() +stop() ● CTB_Receiver – Handles the receiving threads and fills the CTB_Receiver buffer of words +Buffer()
Receiver stream ● There are two threads that create a the buffer of word TCP socket 1)One that fills a raw buffer – currently a 1 st thread boost::spsc_queue of uint8_t from whatever is coming from a TCP socket queue<uint8_t> 2)The other reads the previous queue and fills a spsc_queue of 16 byte words 2 nd thread ● The second buffer is consumed by the queue<trigger_word> fragment generator whenever getNext_() is called
Returned fragments ● Right now, whenever a getNext_() is called, the whole content of the buffer is put into a Fragment – The time stamp associated with the fragment is the timestamp of the first available word in the buffer ● The decision of which fragments are added to the event is not on the FragmentGenerator, it’s happening in a higher level of ArtDAQ. – It is based on the timestamp of the fragment – The fragmentGenerator will continuously send fragment as the board sends triggers at all times
Fragments, to be changed soon ● After a discussion with Nuno we decided to create fragments more regularly – The Board is sending regularly a timestamp word – Whenever this word is seen, a new fragment is created and its associated timestamp will be the one of the word – At the present board configuration we create a fragment every 10 μs if there is at least a triggerword ● John already raised the issue of the number of sent fragments – Possible solution: combine together more words – Drawback: we increase the number of lost trigger words (see next slide)
Leak of trigger words at the edges of the 5 ms readout window ● The trigger words sent by the board are timestamped – Ideally we would like to store all the words whose TS is within the 5ms readout window word Fragment ● Since the selection is not based on the TS of the single word, time word a strange thing is happening at the edges – see the diagram of single TS an example word – Possible solution: redundancy ● I don’t really like this idea – The diagram is just an example, something similar might happen at the end of the readout window 5 ms ● According to a quick discussion we had with Karol, it’s not a window problem if we loose something at the edge – According to Nuno, it is a problem All these words are lost as – I’m happy to go both ways but I guess we need an agreement first The fragment TS is out of the 5ms – What I want to stress is that this is unavoidable with the current But we would have liked to save the last word system as we don’t know the 5 ms start and end while we create the fragment of the fragment as its TS is within the 5 ms – There might be the possibility to fix this using some fcl file options to be passed by the FragmentGenerator, I have to check with Kurt
Calibration stream ● We still want a calibration stream of the things received by the board reade – Not implemented yet ● The stream has no defined usage at the moment – it’s supposed to be an internal cross check – It’s going to be a simple file (binary or txt) for every 5 minutes of run or so – It will contain every trigger word received from the BoardReader ● Concerning its implementation – The natural place for this implementation is the thread which is filling the word_buffer – Every word pushed into the buffer will also be printed into the file
Recommend
More recommend
