Improvements at the MCA-3 software allow to acquire and save individual spectra with very low deadtime
The actual MCA-3 software is able to save in sequential mode individual spectra immediately after each completed cycle and this way allows very low deadtime between individual measurements (about 14 msec for 2k spectra).
Here is part of the readme file describing the news (see especially first part at v 3.05):
Server v 3.06 (Sep-25-2009):
- New commands:
qdac+=val
increments qdac (DAC2) by the (decimal) value val.
oncycle command
executes "command" after a cycle end in sequential mode.
It is possible to enter up to 512 different such commands, each can
be maximal 20 character long. The next in the series will be executed
after the next cycle. When the last such entered command was executed
the first one will be executed again after the next cycle.
oncycle off
switches off the oncycle command executing.
Server v 3.05 (Aug-25-2009):
- A new checkbox "Save Cycle" in the Settings dialog allows in sequential MCS mode an automatic saving of each row in the 2D spectra immediately when it is acquired. The filename is made from the standard data filename by attaching _00000, _00001,...
- The "highrate" option for MCS listmode with more than 255 counts per bin now can be edited in the Settings dialog (see below at v 2.87).
The dwelltime must be > 2 mikrosec, otherwise a warning will be shown.
If short acquisitions with a spectra length between 2k and 16k are started, stopped, saved and erased, this costs acually a time of about 200..300 msec. But if sequential mode is used, it is for example possible to acquire 256 2k spectra into the card RAM with a dead time of only about 14 msec for switching the acquisition from one row to the next. The long dead time for single acquisitions comes from the mechanism of starting and stopping Windows threads that do the reading and evaluation of data in a polling loop. These threads are not stopped and restarted when using sequential mode and this way it can be done much faster. If the card RAM is full, you could either stop, save, erase and restart, which cost about 5.8 seconds (1.6 sec just for erasing), or continue the acquisition in a new sequence without erasing the RAM. If you have the old RAM content saved in your application you could subtract the old values and this way run the system with pretty low deadtime. I did my tests using the built-in command language using loops with a script like loop.ctl with a command line "onstop start" for acquisition loops with erasing or "onstop cont" without erasing. (This works only with the latest release that can be downloaded from our website). The precise time of start and stop can be seen in the first comment line.