Experimental Physics and
Industrial Control System

"Dr. Matthias Kirsch" <[email protected]> · Mon, 1 Apr 2013 17:20:16 +0200

Hello,
what is the anticipated count rate? 
Best regards
Matthias 

-----Ursprüngliche Nachricht-----
Von: Mark Davis [mailto:[email protected]] 
Gesendet: Montag, 1. April 2013 14:47
An: Mark Rivers
Cc: [email protected]; Matthias Kirsch
Betreff: Re: SIS3820 scaler limits

The DAC output has no direct effect on the pulses being counted.  It merely
controls the conditions that generate the pulses.

Also note that I "misspoke" about the period of interest:  It is 1
MICROsecond every 10ms, NOT 1 millisecond every 10ms.

The setup is in out new BECOLA (BEam COoler and LAser spectrscopy) lab:  
Every 10ms a 1microsecond "long" bunched group of ions will pass the
detector, and there is a photon detector that generates the pulses to be
counted by the 3820.

The goal is to divide up that 1us period in to as many smaller periods as
possible.  The original goal was 50 periods (20ns each), but that seems to
be well beyond what the 3820 is capable of.  The person in charge of this
lab said that even 4 or 5 periods (200 - 250ns dwell time for each count)
would be enough to get useful results, but of course more/shorter periods
would be even better.

I am trying to digest the rest of the comments/responses so far and make
sense of them relative to what I know so far (i.e. I will no doubt have more
questions shortly...)

Thanks for all the responses so far!

Mark Davis, NSCL/FRIB

On 3/29/2013 6:57 PM, Mark Rivers wrote:
> Hi Mark,
>
>> and a new count captured at the end of each acquisition period (dwell
time) during which the DAC output is stable.
> Is the DAC driving a voltage to frequency converter, or how is the voltage
converted to a TTL pulse that the SIS3820 counts?  What is the frequency of
the pulse signal that you are counting with the SIS3820?
>
> The short answer to your question is that my current EPICS driver cannot
do what you want.  I need to do some research to determine if the SIS3820
can actually do it at all.  But the information requested above will be
useful to get started.
>
> Matthias: Can the SIS3820 be set up to trigger an acquisition from an
external source, but using the internal time base?  Can this be done
repetitively, or does software need to re-arm it after N channels have been
acquired?
>
> Mark
>
>
> ________________________________
> From: [email protected] [[email protected]] on 
> behalf of Mark Davis [[email protected]]
> Sent: Friday, March 29, 2013 2:57 PM
> To: [email protected]
> Subject: SIS3820 scaler limits
>
> I am new to synApps and use of scaler/counters, etc. and I have some
questions regarding the use and capabilities of the SIS3820 VME scaler and
its driver.
>
> Our current setup for the project I am working on is a VME crate with an
Emerson MVME3100 CPU board, an SIS3820 scaler, and a Hytec VDD2670 DAC.
Don't know at the moment how much memory the CPU card has, or if the memory
card on the 3820 is larger than 64M.  The CPU is running RTEMS rather than
VxWorks.
>
> The use of this setup is currently a fairly straightforward scan (using
sscan records) where the DAC output is ramped over a range of values, and a
new count captured at the end of each acquisition period (dwell time) during
which the DAC output is stable.  The dwell time is currently hundreds of
milliseconds, so nothing that even comes close to the limits of the scaler
card.
>
> But the next step is to support the following scenario:
>
>    *   An external pulse indicates when to start counting the number of
events on a single channel.  This pulse will repeat about every 10ms (100
Hz)
>
>    *   For each external pulse, begin counting event pulses on the one
channel.  At regular intervals, capture the current counter value (doesn't
matter if it is reset at the start of each period, although I am guessing
that NOT resetting it is probably safer, as it would be less likely to miss
an event close to the start of the next interval).
>
>    *   Continue this for a specified number of the regular intervals, then
stop capturing the counter value until the next external pulse
>
> Basically there will be an external pulse once every 10ms that indicates
the start of a 1ms long period of interest.  During that 1ms period, we need
to capture the state of the counter as often as possible (minimum dwell
time), but at regular intervals.
>
> The original specs called for the dwell time to be 20ns, but after looking
over the specs on the 3820, it seems that is not possible.
>
> So here are my questions:
>
>    *   What IS the minimum dwell time for counting on a single channel?
The smallest one indicated in the documentation says 220ns for 8 channels
(using 8-bit counts, which - as the doco points out - is more than large
enough for such short dwell times).  Can this be made even smaller when we
really only need to count 1 channel?  Or maybe 2, if we needed to also count
50MHz pulses on channel 1 to use as a time reference?
>
>    *   The minimum dwell times for the "Histogramming Scaler mode (MCS
with add enabled)" are longer than those for the MCS mode with the same
number of channels and counter depth.  Why is that?  Is it really doing an
addition operation that is taking up time?  I would have thought that the
Histogram mode would be the same as the MCS mode except that you do NOT take
the time to clear the counts (expect prior to the first scan).  And to guard
against incrementing the counts between scans, simply disabling the inputs
or counting of them would do the job.  So unless disabling the counting
between scans takes a lot longer than clearing them at the start of each
scan, I would think that the Histogram mode would have the same or shorter
dwell times than MCS mode, not LONGER!  Why is it the other way around?
>
>    *   Is it possible to get at least the 220ns dwell time performance
using the existing driver, or would I have to modify it?
>
>    *   If modification is not needed, how do I get it do do the MCS mode
with 8-bit counts and the 220ns dwell time?
>
>    *   If I modified the driver, could I get even smaller dwell times
(without changing the firmware/FPGA programming)?
>
>    *   Can someone explain the LNE (Load Next Event) concept?  Depending
the context it is used in, it seems that sometimes it means to advance which
channel's count is being incremented, and other times it seems to mean copy
the counts to the FIFO.  Is either of these correct?  Does it mean something
different for different modes?  When does it apply and when does it not?
>
> Probably more questions as I dig in to this some more, but any pointers,
explanations, insights, suggestions, etc  would be much appreciated.
>
> Thanks,
>
> Mark Davis
> NSCL, MIchigan State University
>
>
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System