ROM Peaking Method

[Rom]

Good day!
Could you explain (I have not found the topic) how we can use "Variable Step Size" option for the peaking process.
It should be pretty handy option.

Thank you very much.

[John Donovan]

Good day!
Could you explain (I have not found the topic) how we can use "Variable Step Size" option for the peaking process.
It should be pretty handy option.

Thank you very much.

The variable step option for integrated intensity acquisitions (standards and unknowns)  is described in this post:

https://smf.probesoftware.com/index.php?topic=536.msg2992#msg2992

It does not apply to wavescans or peaking.

The normal variable step size option uses smaller step sizes as the intensity rises and the "inverted" option decreases the step size with intensity. The idea of inverted variable steps being to focus on background intensities versus peak intensities.

All that said, the variable step size option is not available for ROM (Read Only Memory or firmware based) peaking for finding the peak centroid. But there are peaking options that will perform something similar such as the "interval halving" peaking method.



But you must have the ShowAllPeakingOptions keyword set to a non zero number in the probewin.ini file:

[software]
ShowAllPeakingOptions=1

Yet another alternative for customized wavescans and peaking methods is to utilize the Remote Automation interface which is available from Probe Software and described here:

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

Basically it allows one to write code from Excel, Matlab or any other OLE container to perform custom operations on your EPMA instrument.

In fact here is a description by Phil Gopon some time ago when he and John Fournelle were making a close study of Fe La chemical peak shifting using a clever method for determining the peak centroid:

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

[Rom]

Thank you for explanations but it is not exactly the same I wondered to do.
I think the Interval Halving is the option of calculation, not the option of measuring.
The  Remote Automation interface is the independent huge direction and a am not ready enough to dive into. 
I want to save a bit time during the peak searching.
So I wonder to use the variable step size (impossible like you told) at the peaking procedure.
Or potentially I could decrease the interval range of peak searching. For instance, in Peak/Scan (Acquire! window) the interval range of peak searching for O Ka by default is +/- 21.3 spectrometer units, I want to try +/-5; the interval range of peak searching for Fe Ka by default is +/- 2.8 spectrometer units, I want to try +/-1.5 etc. How I can change these ranges by default because now the boxes are gray (not active).

[John Donovan]

Thank you for explanations but it is not exactly the same I wondered to do.
I think the Interval Halving is the option of calculation, not the option of measuring.
The  Remote Automation interface is the independent huge direction and a am not ready enough to dive into. 
I want to save a bit time during the peak searching.
So I wonder to use the variable step size (impossible like you told) at the peaking procedure.
Or potentially I could decrease the interval range of peak searching. For instance, in Peak/Scan (Acquire! window) the interval range of peak searching for O Ka by default is +/- 21.3 spectrometer units, I want to try +/-5; the interval range of peak searching for Fe Ka by default is +/- 2.8 spectrometer units, I want to try +/-1.5 etc. How I can change these ranges by default because now the boxes are gray (not active).

You can only specify the peak scan widths (low and high) when using the non ROM peaking methods (interval, parabolic, etc).  The interval halving peaking method is not a calculation, it actually changes the acquisition of the peaking intensities.  See the Probe for EPMA User Reference manual for details.

If you're just trying to save time during the peaking, you can either decrease the number of Peakscan Points points in the Peaking dialog and/or you can also reduce the Peaking Count Time from the Count Times dialog.

Decreasing the peak scan width won't make the peaking go faster but if you reduce the number of PeakScan Points that would help.  You can also reduce the Peak/ROM Start Size which will decrease the ROM peaking width as shown here:

[Rom]

John, could you explain, how does the Peakscan Low/Hi limits in the "Peak and Scan properties" link with:
1. position of point #1  (Interval Halving method)
2. number of points which the system uses at Interval Halving method
3. width of WS after peaking procedure (number of points, 150, is clear)

Thank you very much!

[John Donovan]

As I stated above all this information is in the Probe for EPMA User Reference Manual which is available as a pdf from the Help menu or by hitting the F1 key and browsing to the ROM peaking size range section in the description of the SCALERS.DAT in the Configuration Files section as shown here:



Another way to understand these various peaking methods is to run them in DebugMode (see the Output menu) and examine the log window output.

You mentioned previously that you wanted to decrease the peaking time so I suggested decreasing the number of Peakscan Points and/or the Peaking Count Times, but now it seems your objective has changed.

Perhaps it might be better if you told me exactly what you are trying to accomplish with these peaking procedures?

[Rom]

Thank you for information. My objective hasn't changed. I try to understand how the peaking works. When it will be clear for me, I can adjust more then just peaking time saving.
You showed me the ROM algorithm - thank you again. My questions was about Interval Halving method and after peaking WS. Anyway I'll try again to understand how does the peaking search works.

Actually my target is simple. I try to understand why the measured content of Fe in Fe2O3 standards (Taylor and SPI) is 2wt% lower than it should be. My old unsolved issue (( https://smf.probesoftware.com/index.php?topic=1423.msg10484#msg10484
Fe standard - Fe metal in the same block with Fe2O3 (carbon coating is the same).
O standard - Fe2O3 or MgO at the same block.
Doesn't matter: oxygen measured or calculated, use or not Fe+2/+3 correction, width and shape BG (from detail WSs analysis).
FeKa is a strong line, so APFs for Fe wont affect.
MAC, APF for O change O. Of course Fe changes a bit as well but not so successfully as it needs.
The only point I thought was a wrong peaking. But also not, everything is good.

Certainly, my affords with searching the solution give me new knowledge but...

You and your colleagues many times recommended to look at results of calculations with different corrections. I did. But what should I see is not clear. For instance here are results for calculation with default MAC table (LINEMU Henke...) and  FFAST table. Empirical MAC and APF values are not use in the calculations.

[John Donovan]

Thank you for information. My objective hasn't changed. I try to understand how the peaking works. When it will be clear for me, I can adjust more then just peaking time saving.
You showed me the ROM algorithm - thank you again. My questions was about Interval Halving method and after peaking WS. Anyway I'll try again to understand how does the peaking search works.

Hi Rom,
Thank-you for providing details, it makes it easier to understand your questions. And good on you for trying to figure out your problem.

I will just mention that peaking is probably not an issue for your attempts to characterize Fe2O3 using an Fe metal standard. There will be little to no peak shifting for Fe Ka and if you are measuring oxygen (are the results below are with oxygen calculated or measured?) the area peak factors (APFs) for O ka using MgO as a standard and Fe2O3 as a secondary standard should be very close to 1.000 as documented by Bastin in the 1990s:



I will respond further to your questions in the other topic because peaking issues for Fe Ka or O Ka should not be a concern for this system.

But one final question here: you are utilizing the Fe Ka emission line, not the Fe La emission line?

[John Donovan]

I just wanted to mention that when one really wants to precisely determine peak centroids, rather than using one of the automated or manual peaking methods, one should consider performing detailed count/step (not ROM based) wavescans and plotting them up in the Plot! window as described in this post:

https://smf.probesoftware.com/index.php?topic=71.msg9601#msg9601

That is, first zoom in on the peak area of interest, then use the Model Backgrounds button to load the Model Background dialog and then selecting one of the peak fitting options as shown here:



That way one obtains an unbiased (less biased?) numerical value for the peak centroid.

[Joe Boesenberg]

Hi All

I have one of those hmmmm... how does that work questions for you. If I drive my LIF crystal on my spectrometer to a specific element line, such as Fe Ka1, and tell the spectrometer to do a peak search, assuming the spectrometer is perfectly aligned with the theoretical values, it will find the peak at an L-value of 134.62. However,what is ACTUAL width the spectrometer is looking at (in L-values)? Does it in reality only look at everything between 134.61 and 134.63 or is it looking at everything  between 134.42 and 134.82? There certainly has to be some slop just because of refraction from the crystal. Is this a constant width or does it vary with every crystal or element?

Thanks
Joe 

[John Donovan]

Hi All

I have one of those hmmmm... how does that work questions for you. If I drive my LIF crystal on my spectrometer to a specific element line, such as Fe Ka1, and tell the spectrometer to do a peak search, assuming the spectrometer is perfectly aligned with the theoretical values, it will find the peak at an L-value of 134.62. However,what is ACTUAL width the spectrometer is looking at (in L-values)? Does it in reality only look at everything between 134.61 and 134.63 or is it looking at everything  between 134.42 and 134.82? There certainly has to be some slop just because of refraction from the crystal. Is this a constant width or does it vary with every crystal or element?

Thanks
Joe 

You can find the answer to your question in reply#5 above.

[sem-geologist]

I just wonder why it is called ROM (Read Only Memory) method where memory is clearly overwritten every time new peak is scanned. "ROM" part in the title makes absolutely no sense! Also as far I am aware about Cameca hardware there are RAM (random access memory) chips on WDS board, I had seen no ROM chips.

[John Donovan]

I just wonder why it is called ROM (Read Only Memory) method where memory is clearly overwritten every time new peak is scanned. "ROM" part in the title makes absolutely no sense! Also as far I am aware about Cameca hardware there are RAM (random access memory) chips on WDS board, I had seen no ROM chips.

It's because a long, time time ago, these firmware chips were read only.  You had to have a chip "burner" to update them.  Eventually manufacturers went to RAM flash chips for firmware, but the ROM name stuck. 

These days, ROM merely refers to firmware (software in hardware).

[sem-geologist]

It's because a long, time time ago, these firmware chips were read only.  You had to have a chip "burner" to update them.  Eventually manufacturers went to RAM flash chips for firmware, but the ROM name stuck. 

Manufacturers did not go to RAM chips for firmware as RAM is volatile. They went to NOR Flash. RAM existed in these old times too, as microcontrollers had to have some memory where to execute the programs and save temporary data (which such peak scan is). Thus why I  got confused.

These days, ROM merely refers to firmware (software in hardware).

This forum is the first place I would ever come across term "ROM" being used like that, and I deal a lot with low level stuff... Why not to name it "firmware peaking method", or "OEM peaking method"? it would be then much clearer what does it do.

For a moment I though maybe it is Rom - the name of person who made that method 

[John Donovan]

This forum is the first place I would ever come across term "ROM" being used like that, and I deal a lot with low level stuff... Why not to name it "firmware peaking method", or "OEM peaking method"? it would be then much clearer what does it do.

For a moment I though maybe it is Rom - the name of person who made that method 

As I said, it was originally referring a firmware peaking method that didn't use flash memory, and the name just stuck.  We probably should have renamed it when they went to flash memory, but "a rose by any other name would smell as sweet"...