Author Topic: EMSA File Format  (Read 3950 times)

John Donovan

  • Administrator
  • Emeritus
  • *****
  • Posts: 2507
  • Other duties as assigned...
    • Probe Software
EMSA File Format
« on: June 27, 2015, 12:24:23 pm »
I recently noticed that the EMSA format has no defined parameter for detector deadtime!  Of all things to leave out of an EDS file specification! Admittedly this is the verion 1.0 EMSA format, but I'm not aware there is a newer one.

Yes, there is the live time and the elapsed time, and yes one can create "user defined" parameters, but why not also just include a deadtime parameter?
John J. Donovan, Pres. 
(541) 343-3400

"Not Absolutely Certain, Yet Reliable"

Mike Matthews

  • Professor
  • ****
  • Posts: 111
Re: EMSA File Format
« Reply #1 on: June 28, 2015, 04:04:40 am »
Hi John,
Nestor's leading the development of the next generation file format. This will do so much more than the, now very old, EMSA format. For example, it'll allow multiple map signals to be stored together, not just a 1-D spectrum. Like the EMSA format the ne Hyperspectral Data Format will be platform and instrument independent. I don't know how close to release it is though.

Probeman

  • Emeritus
  • *****
  • Posts: 1984
  • Never sleeps...
    • John Donovan
Re: EMSA File Format
« Reply #2 on: June 28, 2015, 09:38:25 am »
Hi John,
Nestor's leading the development of the next generation file format. This will do so much more than the, now very old, EMSA format. For example, it'll allow multiple map signals to be stored together, not just a 1-D spectrum. Like the EMSA format the ne Hyperspectral Data Format will be platform and instrument independent. I don't know how close to release it is though.

Hi Mike,
Yes, I knew about the new multi-spectral EMSA format format...  but will  it include a "deadtime" keyword?  I guess time will tell!

In the meantime is anyone using a "user defined" keyword for this?   I note the these already defined keywords in the EMSA format:

#LIVETIME     = Signal Processor Active (Live) time in seconds [RN]
#REALTIME     = Total clock time used to record the spectrum in seconds [RN]

Rather than ask why they didn't define a similar #DEADTIME parameter, I guess I'm asking now if we should just go ahead and define it ourselves?   Yes, some readers/writers won't respect that keyword, but maybe we could "retro" them?  I for one would be pleased to add it to my EMSA reader/writer...
john
The only stupid question is the one not asked!

NicholasRitchie

  • Professor
  • ****
  • Posts: 30
    • NIST DTSA-II
Re: EMSA File Format
« Reply #3 on: February 05, 2020, 05:44:05 am »
I guess the reason I'd argue that the EMSA file format did the right thing in not having a deadtime keyword is that it is redundant.  Since the deadtime can be calculated from the realtime and livetime, it would only leave open the possibility that the three values could be inconsistent.  In this case, what do you believe? 

Furthermore, livetime is really the only thing that really matters.  (Not to say that there isn't some useful information in realtime and/or deadtime.)  In the end, the only critical pieces of data in an EDS spectrum are the energy scale (gain and offset), the live-time and the probe current.

Nicholas

Probeman

  • Emeritus
  • *****
  • Posts: 1984
  • Never sleeps...
    • John Donovan
Re: EMSA File Format
« Reply #4 on: February 05, 2020, 09:53:57 am »
I agree that livetime is the important parameter for quantification and that deadtime is not really necessary. However recording the deadtime can be a very useful diagnostic parameter, so it is worth saving I think. For example, the post here:

https://probesoftware.com/smf/index.php?topic=939.msg8735#msg8735

describes a situation where I had left the time constant on our Thermo system set to "auto" time constant mode. The issue was that when the Faraday cup is in, the EDS system thinks the count rate is very low and so it automatically increases the time constant to improve spectral resolution. 

The problem occurs when an acquisition starts and the cup is pilled out, because it takes the EDS system 10 or 15 seconds to reduce the time constant for a reasonable deadtime. But once the EDS acquisition starts, the system stops changing the time constant (as it should), and the deadtime is left absurdly high, this producing a very distorted spectrum that cannot be quantified.

If we had not recorded the deadtime, I would not have realized what the problem with those spectra was!
The only stupid question is the one not asked!

jrminter

  • Professor
  • ****
  • Posts: 54
Re: EMSA File Format
« Reply #5 on: February 05, 2020, 12:22:56 pm »
I think both Probeman and Nicholas Ritchie are right in their assertions. On some detectors, spectral resolution degrades with high dead times. I would suggest that the revised MSA format permit an optional deadtime parameter.  In cases where there is an issue about the data, the additional information would have been recorded and the analyst can evaluate later whether the resolution was compromised on a given spectrum.  Analysts will be thankful to the vendor software engineers who automate recording this parameter in the .msa file.  My dad always said, it is better to have it and not need it than to need it and not have it.

NicholasRitchie

  • Professor
  • ****
  • Posts: 30
    • NIST DTSA-II
Re: EMSA File Format
« Reply #6 on: February 20, 2020, 09:46:00 am »
I think that we have a vocab issue.  I don't think that we agree on the definition of deadtime.  I suspect that you mean "the time constant of the pulse processing electronics" or the "pulse processor throughput setting".   When I say deadtime, I mean deadtime = realtime - livetime.  It is a duration measured in seconds and redundant when you have both #REALTIME and #LIVETIME.

I'd be fine with storing the pulse processor throughput setting in the file but these settings are detector specific and would only be "informational values".  Various vendors quote them as "low/medium/high", "60 kHz/130 kHz/...", "1/2/3/4/5/6".   In the old days you could say "12 µs", "25 µs" shaping times etc.  However, with digital pulse processors, the "pulse pair rejection time" depends on the energies of the previous and this x-ray and so isn't a single constant value. Some use multiple process chains simultaneously to adapt to each x-ray pair.  X-rays that arrive in quick succession are measured with a short time constant while x-rays that are well separated in time are measured with long time constants on a xray-by-xray basis.