Apparent peak shifts from contamination buildup

[pgopon]

Hi all,

Many of you know that we have done a bit of careful spectroscopic work at UW Madison, looking at transition metal L lines.  In the course of this work we discovered that contamination buildup could affect the apparent peak position, simply based on the speed and direction of the wavescan. 

We wrote some code that allows us to randomize wavescan acquistions to remove the time dependent aspect of the contamination buildup affecting the wavescan.  We are in the process of compiling it and making it available on our website (http://geoscience.wisc.edu/geoscience/?p=16420). 

The code uses the PfEPMA remote comm server to communicate with the instrument, so is a a bit overhead intensive. 

For those interested we will have a paper out in December in Applied Spectroscopy on the subject (email me and I will send you the proof if you are interested).

Cheers,

phil

[Probeman]

Hi all,

Many of you know that we have done a bit of careful spectroscopic work at UW Madison, looking at transition metal L lines.  In the course of this work we discovered that contamination buildup could affect the apparent peak position, simply based on the speed and direction of the wavescan. 

We wrote some code that allows us to randomize wavescan acquistions to remove the time dependent aspect of the contamination buildup affecting the wavescan.  We are in the process of compiling it and making it available on our website (http://geoscience.wisc.edu/geoscience/?p=16420). 

The code uses the PfEPMA remote comm server to communicate with the instrument, so is a a bit overhead intensive. 

For those interested we will have a paper out in December in Applied Spectroscopy on the subject (email me and I will send you the proof if you are interested).

Cheers,

phil

Hi Phil,
This is excellent work.

I had another idea to "smooth out" the carbon contamination effects you are seeing in your wavescans, similar to the stage scan carbon contamination effects that Philippe Pinard and I worked on with the CPQ method described here:

http://probesoftware.com/smf/index.php?topic=114.msg3258#msg3258

The main problem we found is with running the same stage scan on a standard for the background subtraction (they used a single std for a crude MAN type correction and they really should use the full MAN correction with multiple stds to correct for changes in Z since they are scanning across a carbide grain in steel), is that the carbon contamination isn't as reproducible as it might be.  So as shown in the post linked to above, when you subtract two line scans (both on pure Fe), the difference between them fluctuates around zero by an amount larger than we would like to see...

So I then thought well maybe we should do a number of "fast" beam (or stage) line scans (instead of 5 to 10 seconds per pixel that we are currently doing) and then integrate those scans until we get the counting statistics we desire.  Philippe hasn't gotten back to me on this idea, but I suspect that the carbon contamination will be much more consistent over the scan because the carbon contamination is being "smoothed out" over the entire scan, rather than on a single pixel by pixel basis. This is described here in the next post:

http://probesoftware.com/smf/index.php?topic=114.msg3322#msg3322

In the same manner, I wonder if you could code the Remote interface (I think you used LabView to call the Remote functions), so instead of randomizing the wavescan acquisition points, simply do a number of "fast" wavescans each over the entire scan width, and then add them all up to get sufficient counting statistics.

If this works for you in your code, I think I could add this as an option to the wavescan acquisition in PFE.
john

[pgopon]

This is a good idea, and one that was used for a lot of the Fe oxidation state determination by EPMA studies by La position.  I have always had a sneaking suspicion that this never worked as well it it should have because of the opposite effect to the one we observed with long wavescans.  What we noticed is that with enough current (presumably if you will do fast scan you will need an appreciable current), you actually ablate the coating medium (we observed it on C coatings) and increase the counts (see attached).  My concern is that the peak will be shifted in the same direction as the scan since there are more counts on the right side of the peak than the left, but I have never tested this myself (although I probably should have).

Also, it might take some cleaver programming to make this happen.  As it is now the program has way too much overhead to be able to do a fast wavescan.  Every point requires us to ask the machine to move the spectrometer to the new postions, then ask if the spectrometer is at the position, and then start the counting; moreover this has to be be one through an intermediary (PfE comm server) which adds to the time even more.  Not a concern when your wavescans take 4 hours and you are spending 30 second per point, but I don't think that this will work with millisecond channel times.  Maybe doing this is the peaksight software might make more sense since they can do this all ready, or figure out a way to ask peaksight to run the scan and cache the results and spit them out to our program at the end..  Might also be something useful to have in PfEPMA to make peak searches and wavescans faster in the software.  Which bring me to another question, are the absolute spectrometer positions different in peaksight and PfEPMA?  I have noticed slight shifts in the peak position when I determine them in PfEPMA and peaksight, does this have something to do with the verification sequence peaksight uses and PfEPMA presumably doesn't do?  Or am I just imagining these shifts (which could very well be true).

phil

[Probeman]

This is a good idea, and one that was used for a lot of the Fe oxidation state determination by EPMA studies by La position.  I have always had a sneaking suspicion that this never worked as well it it should have because of the opposite effect to the one we observed with long wavescans.  What we noticed is that with enough current (presumably if you will do fast scan you will need an appreciable current), you actually ablate the coating medium (we observed it on C coatings) and increase the counts (see attached).  My concern is that the peak will be shifted in the same direction as the scan since there are more counts on the right side of the peak than the left, but I have never tested this myself (although I probably should have).

Also, it might take some cleaver programming to make this happen.  As it is now the program has way too much overhead to be able to do a fast wavescan.  Every point requires us to ask the machine to move the spectrometer to the new postions, then ask if the spectrometer is at the position, and then start the counting; moreover this has to be be one through an intermediary (PfE comm server) which adds to the time even more.  Not a concern when your wavescans take 4 hours and you are spending 30 second per point, but I don't think that this will work with millisecond channel times.  Maybe doing this is the peaksight software might make more sense since they can do this all ready, or figure out a way to ask peaksight to run the scan and cache the results and spit them out to our program at the end..  Might also be something useful to have in PfEPMA to make peak searches and wavescans faster in the software.  Which bring me to another question, are the absolute spectrometer positions different in peaksight and PfEPMA?  I have noticed slight shifts in the peak position when I determine them in PfEPMA and peaksight, does this have something to do with the verification sequence peaksight uses and PfEPMA presumably doesn't do?  Or am I just imagining these shifts (which could very well be true).

phil

Hi Phil,
I agree this would only be practical using the ROM scanning feature where the spectrometer scans continuously and we repeat this "fast wavescan" N times to improve counting statistics.  If that is done, we should be able to use the same beam current and get similar statistics will maybe even less overhead than a step/count type wavescan. See the Use ROM Scan checkbox in the Peak/Scan Options dialog in PFE.

I just wanted you to try this first and see what you get before I start modifying the PFE code.   Just FYI, you *can* perform a continuous ROM scan through the Remote interface from Excel, LabView, etc, just not with your SX51, only with the SX100/SXFIVE.

[pgopon]

Hmmmm.... interesting... I guess I forgot about the ROM option since I am used to how it work on the SX51 (i.e. spits out the peak pos and thats it).  I will look into this and see if we can get this working in our LabView code.

phil