Development ideas

In no particular order.

These are ideas, not commitments. Having some discussions beforehand is often useful. An implementation, once done, does not prevent later changes if better approaches are found. Often, only by testing something is it possible to see what might be an easier way to work.

WR-LM32

Finish up the first round of development, with some documentation and commit the code somewhere.

Drasi

Extend WR ID to 8 bits.
- Implemented (HTJ).
- Tested.
WR-stitch
- Basic stitch
  - Implemented (HTJ).
  - Tests ongoing (LR).
- Check by correlation value check.
- Check by 'fingerprint' of non-periodic timestamp differences.

From a discussion with MP. For systems where it is neither possible to inject two kinds of trigger, nor extra values.

It would not consider sync to be good until it has seen some ~10 events with different time intervals. Then, as long as systems match up.

Insert new WR ID subevent in front of the output event.

Such that subsystem WR IDs are never visible to subsequent time sorters.

Remove redundant WR ID subevents, in case the output event has good timestamp matching and check value.

Can only be done if a new WR ID is inserted. (But not required just because a new WR ID is inserted.)

Introduce a WR header marker for incomplete event, such that any following time sorters can treat the event as incomplete.

MBS

Extend WR ID to 8 bit.
- Requested (NJH).
- Implemented (JAM).
- Tested.

UCESB

Extend WR ID to 8 bits.
- Implemented (HTJ).
- Tested.
Correlation check values in crates and modules.

Both UCESB and Drasi support this kind of pre-event value analysis. Drasi does not do unpacking, so cannot easily access more values.

Checking more values per system would, in any case, be more reasonable to include in the unpacker.

The basic idea is that the UCESB .spec format includes a special marker for correlation-check values, enabling automatic processing of these items for such analysis.

TRLO II

On MUPPET.

VUPROM compile?

Exploder compile?

Trigger input recording (like trace), for per-event readout.

To know, afterwards, exactly who contributed to the trigger and how.

(This is a suggestion from Sam Silverstein of ATLAS when discussing triggers.)

Nurdlib

Adapt MVLC support for more VME modules.

List:

Family	Module	Impl. (branch)	Tested	Used?
Mesytec	MDPP16/32	(main)		FRS	R3B
	MADC		-
	MTDC		-	FRS
	VMMR8		-		R3B
	MQDC	-	-	FRS
CAEN V7xx	V775	(main)	-
	V785		-	FRS
	V792		-	FRS
	V965		-
CAEN V767	V767	-	-
CAEN V830	V830	-	-	FRS
CAEN V830	V820	-	-
?	V895	-	-
CAEN V1x90	V1190	-	-	FRS
CAEN V1x90	V1290	-	-
CAEN V17xx	V1725	(main)
GSI	VETAR	(main)	-	FRS	R3B
GSI	VFTX2	(main)	-	FRS	R3B
-	TRLO II	-	-		R3B
Struck	SIS3316	-	-
Struck	SIS3802	-	-
Struck	SIS3820	-	-

Note: FRS use from mail with MB, 2024-06-16. Please check.

Slow Control "DAQ"

Storing of slow control data in LMDs

Description from TDR: p 47, section 5.2.4.2.2
First implementation (MB, NH) in FRS (SFRS-ML experiment):
- https://git.gsi.de/m.bajzek/slow-control-daq/-/tree/main?ref_type=heads
- 10 event/s, one with data, 9 empty
- WR faked from clock time (low accuracy is fine)
- Format is JSON, actual data from FRS Virtual Messhütte: https://lxfrs.gsi.de/vm/api/frs/mbs
- Similar ideas for other DAQs
- Bonus: Faking a running DAQ from LMDs (including fake online monitoring)

Sticky events (deliver to all consumers):
- In Drasi and UCESB:
  - Description: sticky.txt
  - Presentation (2017)
  - Outline: see Chapter 8 of Hunting Tools Beyond the Driplines (thesis)

TODO:
- Testing
- Use data in analysis
- Add additional data (HV, etc)

Please login to edit this topic

Topic revision: r11 - 2026-04-06, HakanTorbjoernJohansson

NustarDAQ

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding GSI Wiki? Send feedback | Legal notice | Privacy Policy (german)