EMSA File Format

[John Donovan]

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?

[Mike Matthews]

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]

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

[Nicholas Ritchie]

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]

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!

[jrminter]

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.

[Nicholas Ritchie]

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.

[Mike Matthews]

I'm looking for example .emsa files from all the different detector vendors for a future review of the EMSA standard (ISO 22029). I recently received a Thermo Fisher Pathfinder export, and this included a lot of their own user defined keywords and some of these would be very useful to be added to the standard as optional keywords. This would encourage more vendors to use them and keep their definitions consistent between them. For example, Thermo add a peak label keyword that gives the x-ray line label and energy position for each of the identified peaks. Having had to manually add these in to very simple exported emsa data a few times I'd very much like to see this added! I'm interested to see what other or similar keywords the other vendors use to try to get the best from all of them. If anyone is willing to share an example file from their system I'd much appreciate it.

[jrminter]

I am attaching two spectra (generated in 2017) from the Oxford EDS system from my old lab (I am now retired) per Mike Matthews request. They are Cu spectra. One has 2048 channels, the other has 4096 channels. I would note that Oxford did not correct for sum peaks in the .msa files at the time.  I hope these are useful for your collection.

[Mike Matthews]

Many thanks, I know have examples from Thermo, Bruker and OI.

[JonF]

I can get you a JEOL EDS .EMSA file, if you want one?

[Mike Matthews]

Yes please Jon.

[JonF]

Ok, emailed one across.

Oddly, the JEOL PC-SEM version that I have gives the #XPERCHAN as keV/channel rather than eV/channel, so is a 1000x off when importing in to DTSA-II. The #XUNITS value is listed as "Energy (keV)".

No idea whether this is something I've done wrong, whether its something I need to alter in my JEOL configuration somewhere, my DTSA-II installation, or whether the .EMSA format wasn't correctly implemented in my version of PC-SEM.

[Mike Matthews]

Thanks Jon,

No email arrived yet. The standard allows for #XPERCHAN to be in eV or keV, with the units used being declared with the #XUNITS required keyword. Sounds like DTSA-II isn't picking that up.

Mike

[JonF]

Huh, weird. Perhaps some filter somewhere didn't like the .EMSA attachment. I've attached it here instead.