Rising data acquisition with mbs event synchronization with time stamps
This presentation is the property of its rightful owner.
Sponsored Links
1 / 37

RISING Data-Acquisition with MBS Event Synchronization with Time Stamps PowerPoint PPT Presentation


  • 107 Views
  • Uploaded on
  • Presentation posted in: General

RISING Data-Acquisition with MBS Event Synchronization with Time Stamps. MBS homepage: http://daq.gsi.de/. Contents. 2003: Requirements and DAQ Solution RISING Experimental setup Time Stamp Module TITRIS Data Acquisition Architecture In-Beam Results and problems encountered

Download Presentation

RISING Data-Acquisition with MBS Event Synchronization with Time Stamps

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Rising data acquisition with mbs event synchronization with time stamps

RISINGData-Acquisition with MBSEvent Synchronization with Time Stamps

MBS homepage: http://daq.gsi.de/

N. Kurz, GSI, DVEE, 27-Apr-2004


Contents

Contents

2003:

Requirements and DAQ Solution

RISING Experimental setup

Time Stamp Module TITRIS

Data Acquisition Architecture

In-Beam Results and problems encountered

2004:

Digital Gamma Finder

MINIBALL in RISING

D

N. Kurz, GSI, DVEE, 27-Apr-2004


Rare isotopes investigation at gsi rising

Rare Isotopes INvestigation at GSI(RISING)

1) Coulomb excitation at relativistic energies

2) Two step fragmentation

FRS delivers exotic nuclei

1) Measurement of incident particle properties before the reaction target

2) High resolution gamma ray spectroscopy

3) Measurement of particle properties after the reaction target

Doppler Correction !!

N. Kurz, GSI, DVEE, 27-Apr-2004


About three years ago

About Three Years ago ...

RISING shall consist of:

1) Euroball Germanium Cluster Detector for high resolution gamma ray spectroscopy

- based on VXI (VME)

- MIDAS (Tcl/Tk) as control and daq software system

- Self - and external trigger capability

2) FRS for incident particle properties

- MBS system with two E7 processors

- GSI trigger modules

- Digitizers all in CAMAC

- Moving to RIO3, LynxPC and VME digitizers

3) CATE (calorimeter telescope) for outgoing particle properties

- to be developed and build, VME

- shall be incorporated into FRS MBS

4) Ancillary detectors -> Barium Fluoride array HECTOR for high efficiency gamma ray

spectroscopy

- restricted to VME

5) ?????

N. Kurz, GSI, DVEE, 27-Apr-2004


Major requirements

Major Requirements

Germanium / VXI part of RISING shall be operated as before.

(Hardware: STRUCK 8080, D32 Bus, D2VB, …)

(Trigger scheme and its associated hardware.)

(Software: MIDAS and functionality behind, front end software, …)

RISING DAQ shall be done with MBS, the standard DAQ system of

GSI, (100 installations, 50 at GSI, 50 at foreign laboratories).

FRS uses MBS since many years.

N. Kurz, GSI, DVEE, 27-Apr-2004


Rising 2003 4 setup

RISING 2003/4 Setup

N. Kurz, GSI, DVEE, 27-Apr-2004


Cluster detector setup for fast beam germanium campaign

Cluster Detector Setupfor Fast Beam Germanium Campaign

15 * 7 Germanium - Cluster Detectors

optimized geometrically for efficiency

and resolution

N. Kurz, GSI, DVEE, 27-Apr-2004


Rising from above

RISING from above

N. Kurz, GSI, DVEE, 27-Apr-2004


Solution with new time stamp module titris

Solution with new Time Stamp Module TITRIS

All 3 sub-systems ( GE/VXI, FRS/CATE, HECTOR ) :

- run asindependentDAQ systems

- are triggered independently

- produce their own local dead time

- provide time stamp for synchronization in all events

Major Requirements of Time Stamp Module:

- precision at least 100 ns

- bin size 100 ns

- 48 bit counter

- provide synchronization over distances of at least 50 m between

3 TITRIS modules

- VME module providing special daisy chained block transfer

for the standard VXI readout

N. Kurz, GSI, DVEE, 27-Apr-2004


Time stamp module titris developer jan hoffmann

Time Stamp Module TITRIS(developer Jan Hoffmann)

N. Kurz, GSI, DVEE, 27-Apr-2004


Titris functionality

TITRIS Functionality...

- Re-use of GSI VME Trigger Module

- 48 bit counter packed in 3 VME registers á 16 bit (65 days)

- Sets time stamp on each external signal (ECL input)

- Single hit time stamp (no multi-event capability)

- 50 MHz => 20 ns for least significant bit

- Euroball special chain readout capability (mandatory for usage in EUROBALL VXI)

- Master and Slave modules hard and software identical

- Synchronization via chained bus, Sync. Rate ~ 1 Khz

… and Operation

New stand alone program, running on LynxOS to:

- Set Master or Slave

- Calibrate cable delay between Master and Slaves

- Set Go and Halt

- Reset TITRIS (identical to “Set Slave”)

- Display TITRIS Status - and Control register contents

- Display actual time stamp value

N. Kurz, GSI, DVEE, 27-Apr-2004


Test results for time stamp module

Test results for Time Stamp Module

3 Time Stamp Modules (1 master, 2 slave), 50+10m distance:

- difference slave modules to master always <= 3 counts

average difference <= 1.1 counts

- difference with respect to average of all modules: <= 2.0 counts

average difference with respect to average time: 0.8 counts

FWHM: 1.9 counts

- stable running for weeks, with 20KHz stamping rate

Similar results with 6 Time Stamp Modules (60+10+1+1+1 m)

N. Kurz, GSI, DVEE, 27-Apr-2004


Rising data acquisition with mbs event synchronization with time stamps

R

E

S

M

A

N

S

T

R

8

0

8

0

T

I

M

I

N

G

VXI

DT32

M

V

M

E

C

P

U

D

2

V

B

VME

R

I

O

3

T

R

I

G

G

E

R

T

I

M

I

N

G

VME

R

I

O

3

T

R

I

G

G

E

R

T

I

M

I

N

G

VME

TCP

TCP

TCP

Event Builder

LynxOS PC

Event Builder

LynxOS PC

Event Builder

LynxOS PC

TCP

Time Ordering

Data Logging

Online Analysis

LynxOS PC

All sub-systems inside the

dashed boxes are able to run

as independent MBS systems.

Ge (2 x VXI) FRS / CATE Hector

N. Kurz, GSI, DVEE, 27-Apr-2004


Rising data acquisition with mbs event synchronization with time stamps

MBS readout

LynxOS RIO3

MBS readout

LynxOS RIO3

m_read_meb

m_read_meb

D2VB readout

LynxOS

MVME 2431

Daresbury

m_ds

m_ds

Tcp

Tcp

Tcp

MBS event-

builder

LynxOS PC

MBS event-

builder

LynxOS PC

MBS event-

builder

LynxOS PC

m_rirec

m_dr

m_dr

Data: MBS

formatted

Data: MBS

formatted

Data: MBS

formatted

m_transport

m_event_serv

m_stream_serv

m_transport

m_event_serv

m_stream_serv

m_transport

m_event_serv

m_stream_serv

Tape

Disk

Tape

Disk

Tape

Disk

Tcp

Tcp

Tcp

Tcp

Tcp

Tcp

MBS time -

ordering

LynxOS PC

m_to

Data: MBS

formatted

m_transport

m_event_serv

m_stream_serv

All sub-systems inside the

dashed boxes are able to run

as independent MBS systems.

Tape

Disk

Tcp

Tcp

Ge (VXI) FRS / CATE Hector

N. Kurz, GSI, DVEE, 27-Apr-2004


New mbs data receiver process m rirec

New MBS Data Receiver Process m_rirec

- receives 16K buffers with preformatted events from

the EUROBALL VXI/VME based DAQ via TCP socket

-reformats events contained in buffer into single MBS events

Daresbury (MIDAS group, V.Pucknell) developed the data sender

process running on the EUROBALL VME processor according

to our specification.

N. Kurz, GSI, DVEE, 27-Apr-2004


New mbs time ordering process m to

New MBS Time Ordering Process “m_to”

Commands:

- connect/disconnect transport [node]

- start/stop output

- set toreceiver flushtime [time in sec]

- show input nodes

Sorting of events is suspended if any of the connected input nodes

has no event ready:

- guarantees strong time ordering at data output stream

- requires slow fixed rate trigger at each sub-system (1Hz ok)

- de-randomization buffers on each sub-systems (100-200MB) avoid

sub-system to sub-system dependency of dead time

m_to runs without any problem with 3 sub-systems under harsh

conditions

m_to sorts according to time, but does not tag events to “real”

physics events

N. Kurz, GSI, DVEE, 27-Apr-2004


Rising trigger

RISING Trigger

Physics Triggers

1) FRS Sci 2 in coincidence with gamma trigger in Ge-Cluster detector

(Readout of FRS/CATE and Ge-Cluster (VXI))

2) FRS Sci 2 in coincidence with gamma trigger in HECTOR

(Readout of FRS/CATE and HECTOR)

Monitoring Triggers

1) Pulser Trigger for Time Stamp monitoring

(Readout of all Systems)

2) Timing Generator with varying pulse heights (step function) for

monitoring the synchronicity of all sub-system data

(Readout of all Systems)

N. Kurz, GSI, DVEE, 27-Apr-2004


Time stamp sources

Time Stamp Sources

FRS/CATE, HECTOR:

Master Trigger Out (MTO) from GSI trigger module

(300 ns delayed with respect to trigger time)

Ge-Cluster (VXI):

Validation 3 from Resource Manager (RM)

(~ 3 us delayed with respect to trigger time)

N. Kurz, GSI, DVEE, 27-Apr-2004


Time stamp format in mbs event

Time Stamp Format in MBS Event

No space for time stamp in event or sub-event header

First 4 data words in first sub-event of an event:

------------------------------------------------------------------

| sub-system identifier|

------------------------------------------------------------------

| identifier low 16| time stamp low 16|

------------------------------------------------------------------

| identifier middle 16| time stamp middle 16|

------------------------------------------------------------------

| identifier high 16| time stamp high 16|

------------------------------------------------------------------

3116150

identifierlow:0x0f7

middle: 0x1f7

high:0x2f7

sub-system identifier: Ge-Cluster (0x100), FRS/CATE (0x200), Hector (0x300)

N. Kurz, GSI, DVEE, 27-Apr-2004


In beam results 1

In-Beam Results 1

N. Kurz, GSI, DVEE, 27-Apr-2004


In beam results 2

In Beam Results 2

N. Kurz, GSI, DVEE, 27-Apr-2004


Problems encountered

Problems Encountered

Treatment of multi-event (hit) digitizers in FRS readout.

Error was caused by gating (starting) multi event CAEN modules but

missing readout for special purpose triggers (pulser, end of spill, etc).

Severe checks in module readout implemented.

Monitoring with time calibrator trigger fanned out in all 3 sub-systems

established.

VXI chain readout of Ge-Cluster cards is not (was never) perfect.

==>> Test DGF module (Digital Gamma Finder) from XIA with few

Ge-Cluster detectors in May 2004 run

N. Kurz, GSI, DVEE, 27-Apr-2004


Rising data acquisition with mbs event synchronization with time stamps

Planned Upgrades

Splitting FRS and CATE readout will reduce dead time.

Needs additional VME crate, VME Processor and Trigger Module.

Hardware is available.

MINIBALL detector system with 48 DGF modules

(3 CAMAC crates) will come end of 2005 and has to

be incorporated into the RISING DAQ system

N. Kurz, GSI, DVEE, 27-Apr-2004


Dgf functionality incomplete emphasis on synchronization with titris time stamp system

DGF Functionality (Incomplete)(Emphasis on Synchronization with TITRIS Time Stamp System

Fast CAMAC module, 4 channels (pre-amplifier signal input), trigger logic in/out,

40 MHz clock. DGF expert: H. Schaffner

DGF signal processing: (1-3) for each channel, 1 DSP for all 4 channels

1) Nyquist filter (bandwidth of input signal should be limited to 20 MHz)

2) 12 bit ADC, 40 MHz

3) Filter FPGA to estimate energy and time

- slow (6-8 us, adjustable) trapezoidal digital filter for energy estimation

- fast (100 ns) trapezoidal digital filter for pileup rejection

- correction of ballistic deficit (signal rise time ~ 300 ns, SIGNAL fall time ~ 50 us)

- digital constant fraction discriminator to signal time estimation

(40 MHz 16 bit counter)

4) DSP

- takes filter values of energy and time, possible pulse shape analysis and

many more...

- writes data to output memory (4 different standard data formats available)

N. Kurz, GSI, DVEE, 27-Apr-2004


Dgf data taking and data format

DGF Data Taking and Data Format

To start data taking on a DGF module a “run” has to be started per CAMAC

command, specifying how many events a run shall contain prior to readout.

A run can be specified for 1-N-MAX events. N-Max is determined through the

output memory size of the DGF and the output format chosen.

Output format for DGF test in May 2004:

Buffer header (once for each run):

1) number of data words in this run

2) DGF module number (CAMAC slot)

3) Format descriptor

4)-6) Buffer time high, middle, low (3 * 16 bit, á 25 ns, generated at run start by DSP)

Event header (for each event, events starts with first earliest channel in a DGF):

1) Hit pattern (1-0xf to indicate which out of 4 DGF channels have fired)

2-3) event time high and low (2 * 16 bit`, á 25 ns, generated at “earliest” channel by DSP)

Channel data (most compact format, for each channel fired in event):

1) Fast trigger time (16 bit, á 25 ns, generated by FPGA)

2) Energy

N. Kurz, GSI, DVEE, 27-Apr-2004


Rising data acquisition with mbs event synchronization with time stamps

T

R

I

G

R

I

O

3

V

C

3

2

CAMAC, front view

C

C

3

2

CAMAC

CAMAC

DGF Control and Readout with VC32/CC32 (Wiener, (Plein+Baus))

Tests: also Henning Schaffner

Advantages:

- supports Fast CAMAC level 1 (DGF from XIA)

- performance

- broadcast CAMAC commands

Disadvantages:

- only one CAMAC crate (one CC32 per VC32)

- cable length <= 5 m

- no simultaneous readout of more than one VC32 in one

VME crate possible

- no VME block read on VC32

Performance: MBS, RIO2, 1000 16bit words per event,

per software packed in 32 bit words:

CC32, no auto:970 KB/s (1.76 us/CAMAC word)

CC32, auto:1600 KB/s (1.27 - “- )

CC32, auto, fast CAMAC:1700 KB/s (0.84 -”- ) <= VME single cycle speed

CBV:850 KB/s (2.16 -”- )

Not yet implemented in MBS ESONE server

VME, front view

N. Kurz, GSI, DVEE, 27-Apr-2004


Synchronization of dgf time with titris time

Synchronization of DGF Time with TITRIS Time

First possibility: Use TITRIS also in DGF system for each event!

- Start DGF run with only one event per run!

- Time stamp TITRIS with FRS particle in coincidence with gamma trigger

and “anti” dead-time

Disadvantage: Data size per event (buffer header for each event) => readout speed

Second possibility: Stamp TITRIS only at Run start!

- Synchronize once at run start “DGF buffer time” and “TITRIS time” (use “anti” busy output from

DGF module to time stamp TITRIS)

- Re-calibrate DGF event/channel time with respect to “buffer time” into “TITRIS units”

- Specify as many events per run as possible

- Readout at end of spill (and if Run is completed in spill)

Disadvantage: Complicated time sorting with other DAQ branches

Question: How do the TITRIS clock and the DGF clock jitters or drifts in a period of

a spill time (~3-5s) against each other?

Check also long time behavior over several days!

N. Kurz, GSI, DVEE, 27-Apr-2004


Test setup to measure time drift

Test Setup to Measure Time Drift

Use 2 branch system:1) “Conventional” with TITRIS as reference system

2) DGF system with additional TITRIS

and feed both data streams through the time sorter MBS process m_to

Trigger:

- Use random trigger (Poisson) with lowest rate (average ~ 10Hz)

- Simulate spill structure: 4 s trigger enabled, 4 s disabled

- Split Trigger and trigger both systems at the “same” time.

Technically: - use random pulser output to trigger conventional system

- use random pulser output to trigger analog pulser, which simulates

germanium signal from a gamma and feed it into DGF

Conventional system:

- Set time stamp with Master Trigger out (MT) from GSI trigger module as usual

DGF system:

- Start DGF run with only one event requested !

- Time stamp TITRIS with DGF run start

NOTE: Both TITRIS modules are synchronized via their sync. bus

For each spill exactly one DGF run is started, which gets its event in the

next spill. Therefore the minimum time which elapses between DGF run

start and the event (channel) time is the length of the spill off duration.

N. Kurz, GSI, DVEE, 27-Apr-2004


Dgf time vs titris time

Run start

Simultaneous events (triggers)

in both systems

TITRIS trigger time

(Conventional system)

0 => 8 sec

TIME

Buffer time DGF

(run start)

Channel time DGF

?

TITRIS time

(run start)

DGF Time vs. TITRIS Time

Calibrate DGF run time in TITRIS units :

DGF run time = (Channel time DGF - Buffer time DGF) * 1.250xxx

Calculate event time difference between both sub-systems:

Event time difference = DGF run time - TITRIS trigger time (Conventional system)

N. Kurz, GSI, DVEE, 27-Apr-2004


Dgf run time 1 hour data taking

DGF Run Time (1 Hour Data Taking)

X-Axis: DGF run time

Full range: 6 sec = 3*10**8 TITRIS units

N. Kurz, GSI, DVEE, 27-Apr-2004


Event time difference 1 hour

Event Time Difference (1 Hour)

X-Axis: Event time difference

Full range: 4 us = 200 TITRIS units

~ 20 channels = 400 ns

N. Kurz, GSI, DVEE, 27-Apr-2004


1 hour

1 Hour

Y-Axis: Event time difference

Full range: 1.6 us = 80 TITRIS units

X-Axis: DGF run time

Full range: 6 sec = 3*10**8 TITRIS units

N. Kurz, GSI, DVEE, 27-Apr-2004


Rising data acquisition with mbs event synchronization with time stamps

DGF Run Time (7 Days Data Taking)

X-Axis: DGF run time

Full range: 6 sec = 3*10**8 TITRIS units

N. Kurz, GSI, DVEE, 27-Apr-2004


Event time difference 7 days

Event Time Difference (7 Days)

~ 300 channels:= 6 us

X-Axis: DGF run time

Full range: 6 sec = 3*10**8 TITRIS units

N. Kurz, GSI, DVEE, 27-Apr-2004


7 days

7 Days

Y-Axis: Event time difference

Full range: 1.6 us = 80 TITRIS units

X-Axis: DGF run time

Full range: 6 sec =: 3*10**8 TITRIS units

N. Kurz, GSI, DVEE, 27-Apr-2004


Miniball in rising

MINIBALL in RISING

- 8 Germanium detectors

- Each detector consists of 3 Germanium crystals of Ge-Cluster shape

- Each crystal is 6 fold segmented

- Each crystal has a central contact

use 2 DGF for each crystal:6 segments

1 central contacts

1 spare

==>48 DGF modules in 3 CAMAC crates

144 germanium segments, 168 readout channels in total

Trigger only on central contacts

Readout of all segments of a crystal (and central contact) on a trigger

N. Kurz, GSI, DVEE, 27-Apr-2004


Conclusion

Conclusion

1)RISING DAQ is running stable

2)New Event Synchronization with Time Stamps is

working as expected

3)Miniball needs to be incorporated. Solution available.

4)Wait and see for the next detector system to be

used in RISING

N. Kurz, GSI, DVEE, 27-Apr-2004


  • Login