Time Dependent Intensity (TDI) Corrections

[John Donovan]

So you would recommend evaluating the models on a point by point basis rather than trying to be consistent with the model used?

Hi Andrew,
I think the model you use to evaluate the fit should be evaluated on a point by point basis since that is how the TDI correction is applied during the matrix iteration.

In your original examples it looked to me (based on the Relative Deviation % displayed) that the log-linear fit gave the smallest avg deviation.
john

[AndrewLocock]

This may have been pointed out earlier, but:

The TDI intensities can be saved in Excel format, and then evaluated in Excel.
An example of Na intensities for a point in obsidian (15 kV, 6 nA, 5 micron beam diameter, nominally 30 s on peak) is in the PDF attachment.

Cheers,
Andrew Locock

[John Donovan]

Hi,

I have a controversial suggestion - to see what you think. Currently TDI only applies to first row elements. This restricts it to the first element on each of the spectromters. I'd like to suggest that it could be used for second row elements - if it was done carefully checking that the intensity was a linear drop of with time - then it can be done for the second row elements. A case were it might be useful is volcanic glass with 2 TAP, 2 PET, and 2 LIF. Where Al is measured after Si (i.e. can't measure Si, Al and Na in first row). Currently you have to make sure its stable for the second row Al, so having to make sure Al is linear drop off is not much harder?

Ben

I saw this old post looking for something else and realized that I should have mentioned to Ben that one can apply TDI corrections to multiple sample setups (each with 5 elements per sample), then acquire them in the Automate! window and then combine them post acquisition using the Combine Samples into  a New Sample feature from the Analyze! window:

https://probesoftware.com/smf/index.php?topic=40.msg12137#msg12137

That way one can utilize TDI corrections on more than 5 elements in a sample. Be sure to update to the latest Probe for EPMA using the Help menu as we fixed some minor bugs in this method earlier this year.

[AndrewLocock]

That way one can utilize TDI corrections on more than 5 elements in a sample.

But should you do that?

TDI is correcting for the change in intensity over time.
For the first set of elements, measured over time period 1, TDI is correcting for changes in the X-ray emission of the sample and ideally the regression provides data that correspond to "time zero" - the fresh, unirradiated original composition.

If TDI is applied to a second set of elements measured at the same spot, starting at time period 2, it will only be able to correct back to the composition of the sample as it was at the end of time period 1 = the start of time period 2.
The second application of TDI on the same analytical point is correcting back to an already-damaged/changed/altered material, not to the original composition.

It may be argued that some further correction is better than none at all, but it must be realized that a second set of TDI corrections during an analytical routine is not a panacea to obtain the actual original composition.

If the sample is sufficiently beam-sensitive that it continues to change during the measurement of a second set of elements,
perhaps a better analytical scheme should be used.

In the case of most zeolite minerals, for which the Fe content is effectively negligible, I find that simultaneous measurement of the 5 main measurable components: Na, Al, Si (all on TAP), K and Ca (both on PET) with a single application of TDI is sufficient.

Cheers, Andrew

[John Donovan]

Yes, of course, you are exactly correct. That is why we don't allow TDI corrections on subsequent elements in the first place!   

But...  and this is what Scott Boroughs does, he will digitize slightly different points for each of these sample setups, so they each get "virgin" interaction volumes.  Of course that assumes that one's sample is homogeneous on the micro scale, but as you say, it's better than nothing.

In a way, this is similar to how the "assigned" TDI correction is acquired. The app "bumps" the stage a specified number of microns for each element and acquires TDI curves for each element separately, which can then be assigned to any subsequent (normally acquired) samples for a TDI correction.

[dawncruth]

One concern that has arisen multiple times by my users is how TDI is affected by the apparent/perceived lag between counting and when the Faraday cup is removed. In other words, does counting happen immediately after the cup is removed and there is simply a lag in the Acquire window display? Or is there really a lag between counting and the cup removal?  If so, how does that affect the TDI calculation?

[John Donovan]

One concern that has arisen multiple times by my users is how TDI is affected by the apparent/perceived lag between counting and when the Faraday cup is removed. In other words, does counting happen immediately after the cup is removed and there is simply a lag in the Acquire window display? Or is there really a lag between counting and the cup removal?  If so, how does that affect the TDI calculation?

There is always overhead on the microprobe communications.  It's something we all have to deal with.

But the TDI acquisition zero time is referenced from the time the faraday cup is removed, not when the counting starts.   So your users do not need to worry.

Note that you can try using different FaradayWaitOutTime values in the [Faraday] section of the Probewin.ini file.  This is the amount of time that the program waits after the faraday cup is removed before counting starts. You might need to start a new MDB to test each different value.

[sem-geologist]

interesting. As for peaksight, spectrometers firstly move to the positions, then beam current is measured, and then counting starts at once the faraday cup is disengaged (Had not noticed any human perceptible delay). I guess the sequence of steps as instruction in machine code are first copied to microprocessor memory and then executed there, at least I would do so. For TDI builtin hardware sequencer rather should be used and not direct commands to count, read, reset and repeat again and again. It should get counts as array binned by set timespan per bin. The same as with mapping, just without moving the stage. Actually I got an idea - in case the probe controll api for TDI do lots of PC<->probe communications, the mapping or (even better) line-crosssection API mode could be overused for this with set length of few nm or 0 (depends if firmware has no "divide by 0" gotchas) - pixels of line will contain equally spaced in timeline counts spaced equally by hardware with no relevant lag or glitch.
Another thought - counting is in hardware (there are 24bit counters implemented in FPGA) if they are reset prior launch (which should take place during initial spectrometer moving to the positions), only a single clock cycle is needed to start them, at 16 MHz the delay will be about 1-2µs which would translate into at most one or two pulse counts missed (in case of over-saturated count rate, but TDI then is the least concern). (FPGA in new gen on cameca electronics work at 50MHz thus delay is rather even more irrelevant). Unless software is micromanaging and sending every command sequentially (Hopefully rather not either with Peaksight and either with PfS).

Just for the record, there is also delay of beam hitting the sample after disengaging the faraday cup due to inductance of the beam and beam control deflectors. It is more visible where beam needs to be deflected to the faraday cup, instead of faraday cup being mechanically inserted into the beam. Thus there could be actually opposite delay - counting being engaged before beam drifts into the right spot.

[John Donovan]

interesting. As for peaksight, spectrometers firstly move to the positions, then beam current is measured, and then counting starts at once the faraday cup is disengaged (Had not noticed any human perceptible delay). I guess the sequence of steps as instruction in machine code are first copied to microprocessor memory and then executed there, at least I would do so. For TDI builtin hardware sequencer rather should be used and not direct commands to count, read, reset and repeat again and again. It should get counts as array binned by set timespan per bin. The same as with mapping, just without moving the stage.

I wish I could have coded it that way, but I had to write TDI code that works for both Cameca and JEOL instruments and JEOL does not have this capability, at least not for non-mapping acquisition modes.

And yes, PFE also performs all necessary instrument functions before removing the faraday cup.  The delay after the faraday cup is removed isn't noticeably long on the Cameca.  But JEOL instruments have another problem which is that the JEOL picoammeter is very slow. So when inserting the faraday cup, we often have to wait up to 2.5 seconds(!) before we can obtain a stable beam current measurement.  This is not a problem at the start of the point measurement, but it can be problematic in the second beam current measurement.

In fact each model JEOL instrument seems to have a slower picoammeter. The 89800/8900 picomameter was actually quite fast, essentially as fast as the Cameca. Then the 8200/8500 was slower often requiring up to 1.5 seconds of delay after removing the faraday cup. And as mentioned above the 8230/8530 picoammeter is even slower.

This is not a problem for the TDI measurement because we're not measuring the absorbed current after removing the faraday cup (unless you are using the measure absorbed current option with TDI!), but if someone is measuring absorbed currents normally and has set the FaradayWaitOut too long (in order to obtain accurate absorbed current measurements), there will be an appreciable delay before the counting starts (if we were really smart we would measure absorbed current during the x-ray intensity measurements- need to think about that!). 

Note that PFE measures the faraday current both before and after each x-ray measurement and can also measure the absorbed current measurement before and after the x-ray measurement (when the faraday cup is removed).

I think the best compromise for JEOL instruments might be to set FaradayWaitOutTime to zero in the Probewin.ini file (for timely TDI measurements), then set the Incubation/Decontamination delay time (in the Acquire! | Acquisition Options dialog) from zero to a couple of seconds when you aren't measuring TDI but need to obtain accurate absorbed current measurements.

https://probesoftware.com/smf/index.php?topic=116.0

Or JEOL could provide a faster picoammeter...  maybe one of you electronics geniuses could come up with a fast picoammeter circuit for JEOL instruments?  In other words, why did JEOL slow down their picoammeter so much over the last several decades?

[Probeman]

...then set the Incubation/Decontamination delay time (in the Acquire! | Acquisition Options dialog) from zero to a couple of seconds when you aren't measuring TDI but need to obtain accurate absorbed current measurements.

This feature is shown here:



By incubation time we mean the delay that may be necessary to account for the time is takes for the ion migration to begin after the faraday cup is removed (the interaction volume needs to heat up), though this can be resolved also by simply increasing the beam current.

The decontamination time is the same feature but used to delay the measurement of carbon (again, after the faraday cup is removed), in order to provide time for the beam to "burn off" any surface hydrocarbon contamination when measuring trace C Ka.

[mwloewen]

Apologies if this has been addressed in this thread already--

Have you considered adding a test for regression significance that if not met would turn off the TDI correction on a point-by-point and analyte-by-analyte basis? This was TDI would only be applied if it was statistically justified.

Below is copied from an example of how we do this with time-resolved LA-ICP-MS analyses. It seems like a similar approach would be helpful by EPMA if possible to implement.

https://jlubbersgeo.github.io/lasertram/explanation/

We determine the significance of each regression by evaluating following null hypothesis: there is no relationship between a given analyte's internal standard normalized ratio and time. We reject this if both the following conditions are true: The p-value for the coefficient (i.e., slope) is significant; The F-statisic comparing the regression and observed data is greater than the critical F value. By default, we set the threshold for p-value significance at .01 (i.e., we have 99\% confidence that we can reject the null hypothesis) in an effort to mitigate drift correcting all but the most linear of changes in normalized count rates, but this may be changed by the user. If the null hypothesis for a given analyte is rejected, the analyte is linearly corrected for drift and the regression parameters (e.g., slope and intercept) are used to calculate a normalized count rate for the calibration standard at the point in time where an unknown was analyzed: where is the regression slope, is the analysis time, and is the intercept for analyte .

[John Donovan]

Have you considered adding a test for regression significance that if not met would turn off the TDI correction on a point-by-point and analyte-by-analyte basis? This was TDI would only be applied if it was statistically justified.

Almost everything is possible, given enough time and resources!     

Not a bad idea, we will consider the suggestion.