Hi John,
I tested the new Cameca PHA MCA feature a bit (http://smf.probesoftware.com/index.php?topic=42.msg883#msg883).
It's great, 1 second PHA scans!
However, I noticed that when PHA differential is specified, the x axis range of the PHA window reflects that PHA window, but the PHA scan data is actually for the full window (.56 to 5.5V) so the x axis range is wrong, see attached two images for S Ka on PET, identical conditions but PHA diff switched on for the first one (base .75, window 2.09V) and PHA integral for the second one.
Cheers,
Karsten
Ok, I see this.
Interesting that I got it to work correctly in demo mode!
(https://smf.probesoftware.com/oldpics/i62.tinypic.com/etd1xs.jpg)
Hi Karsten,
OK, I got it working. But here's something I don't understand...
So here is a MCA PHA acquired using the new MCA PHA hardware:
(https://smf.probesoftware.com/oldpics/i58.tinypic.com/dcfo90.jpg)
It looks just like the display on the PeakSight software. And here is the same x-ray line acquired using the traditional PHA scanning method:
(https://smf.probesoftware.com/oldpics/i59.tinypic.com/14kchgl.jpg)
Why are they different? Where is the Ar escape peak in the MCA PHA acquisition?
Not sure.
I do normally see the escape peak using PeakSight's MCA and usually it has more separation between the main and the escape peak, but that's obviously energy dependent.
Which x-ray line did you use for that PHA scan?
here is an MCA PHA scan and a traditional PHA scan of the Fe ka peak from my SX100.
(https://smf.probesoftware.com/oldpics/i57.tinypic.com/ru1tu0.jpg)
(https://smf.probesoftware.com/oldpics/i58.tinypic.com/i6wffn.jpg)
the peak position appears different, Is the x-axis wrong for one of the plots?
Testing the new MCA PHA acquisition I increased the time to 1s with 40 intervals, I get this error:
PHA MCA Test on spectro 1 timed out. This is usually caused by too low an x-ray intensity. Please try the PHA MCA Test again using a material with a higher concentration or uncheck the Use MCA PHA Acquisition checkbox in Acquisition Options dialog and instead utilize the traditional PHA acquisition method.
I did a bit more messing around and discovered that if:
count time * intervals >= ~30
the error occurs. count time * intervals < 30 and all is good.
Gareth
Quote from: Karsten Goemann on March 25, 2014, 08:32:52 PM
Not sure.
I do normally see the escape peak using PeakSight's MCA and usually it has more separation between the main and the escape peak, but that's obviously energy dependent.
Which x-ray line did you use for that PHA scan?
Fe Ka.
Gareth's Fe scan looks more like my traditional one!
I wonder if these MCA PHA electronics ever need to get recalibrated?
John,
If I move to lower gain so that the peak is at a similar V to yours, then I see similar results to you, I don't know why yet either:
MCA
(https://smf.probesoftware.com/oldpics/i60.tinypic.com/11qkaqv.jpg)
Traditional
(https://smf.probesoftware.com/oldpics/i57.tinypic.com/efl8hf.jpg)
BUT note again that the peak has an apparent shift - I have a feeling that the Cameca MCA data is returned as 0-5V not 0.5-5.5V as it is being plotted by PFE.
Gareth
That makes some sense. I was just going by the PeakSight data display which I thought shows a blue line for the PHA data going from 0.5 to 5.5 and yes:
(https://smf.probesoftware.com/oldpics/i61.tinypic.com/309pj41.jpg)
but I have a pretty old version of PeakSight. What do you see?
Well, what about that - Mine shows 0-5V!
(https://smf.probesoftware.com/oldpics/i59.tinypic.com/2zp35as.jpg)
p.s. I have no idea how I managed to turn the background black, and I can't figure out how to make it white again!
EDIT by GSeward: this plot has no smoothing applied
You know what this means?
We can't demonstrate the escape peak any longer using this new MCA PHA hardware!
john
So I tried PeakSight again with checking the smoothing option off and get a slightly better escape peak:
(https://smf.probesoftware.com/oldpics/i61.tinypic.com/2lt57h5.jpg)
and now my acquisition looks pretty much the same:
(https://smf.probesoftware.com/oldpics/i58.tinypic.com/4ijxtx.jpg)
So I guess the MCA method is not quite as good energy resolution...?
Our SX is in use right now so I can't collect examples for comparison before Monday.
But I seem to remember that the "traditional" PHA scans we collected with PFE on our system were looking extremely jagged and asymmetrical. Back then I thought it was because the electronics can't keep up with the fast baseline/window changes. Or the count rates are just too low, or both. The minimum PHA window setting I needed to get an acceptable PHA peak shape was 0.6V.
Gareth, to change the background colour in PeakSight, double left-click into the background of the graph. A window should open where you can adjust the colour.
Quote from: Karsten Goemann on March 27, 2014, 04:03:57 PM
So in my quick testing, I can see we are getting back 256 intensities, but what voltage range do these intensities represent? I ask because my PeakSight display shows them going from 0.5 to 5.5, but on Gareth's PeakSight display they go from 0 to 5 volts.
The test PHA return packet seems to *always* return 805 and 5637 millivolts for the baseline and window respectively, but if I set the PHA window *before* the pha acquisition to 3 volts, I can see that the instrument window is 3 volts in the PeakSight display during the test PHA acquisition, but the test PHA function still returns the same exact range of intensities no matter what window setting I specify.
Here is what one sees when running a MCA PHA "test" in DebugMode (from the Output menu)...
Setting spectro 2 PHA (BWGBMD): .5 3 1003 1250 -1 .0000038
Moving to crystal and on-peak spectrometer positions...
SX100MoveMotor: 2 to 27644 at speed 3000
Moving motor 2 from 32295 to 27644
Setting column conditions (TKCS)...
Inserting faraday cup or blanking beam
Faraday cup inserted or beam blanked
Setting operating conditions (TKCS): 40 15 50 0
Setting operating conditions (TKCS): 40 15 50 0
Setting operating conditions (TKCS): 40 15 50 0, getting current conditions...
SX100SetConditions: current conditions (TKCS) = 40 15 51.5915 0
SX100SetConditions: static variables (TKCS) = 40 15 50 0
SX100SetConditions: ForceAnalyticalConditions = 0
SX100SetConditions: OperatingVoltageTolerance = .002, BeamCurrentTolerance = .01
SX100SetConditions: beam current error = 51.5915 / 50 = 3.18300 %
Setting operating conditions (TKCS): 40 15 50 0, setting beam current...
SX100SetConditions: set beam current = 50
Setting operating conditions (TKCS): 40 15 50 0, setting beam size...
SX100SetConditions: set beam size = 0
Operating conditions set (TKCS)
Setting beam mode (Analog Spot)...
Setting beam mode (Analog Spot)...
Setting magnification: 40000
Setting magnification to 40000...
Magnification set to 40000
Removing faraday cup or unblanking beam
Faraday cup removed or beam unblanked
Acquiring PHA acquisition...
Setting spectro 2 PHA (BWGBMD): .5 3 1003 1250 -1 .0000038
SX100GetPHADistributionMCA2: Motor= 2, Status= 1, MaxTries= 0
SX100GetPHADistributionMCA2: Motor= 2, Status= 0, MaxTries= 1
SX100GetPHADistributionMCA2: Motor= 2, Acquisition number=1
SX100GetPHADistributionMCA2: Baseline= 804
SX100GetPHADistributionMCA2: Window= 5627
SX100GetPHADistributionMCA2: Alignment= 0
SX100GetPHADistributionMCA2: Index= 256
SX100GetPHADistributionMCA2 (Byte): Min= 0, Max= 246, CountTime= 0.035
SX100GetPHADistributionMCA2 (PHA Sum): Min= 0, Max= 236.5714
SX100GetPHADistributionMCA2 (Averaged): Min= 0, Max= 236.5714
SX100GetPHADistributionMCA2 (Normalized): Min= 0, Max= 6759.184
Note that the returned "baseline" and "window" from the MCA PHA acquisition are 0.804 and 5.627 volts respectively.
I've done some testing on our SX100 #846, vintage 2003, using both PeakSight and MCA and "traditional" PHA with Probe For EPMA. I've done FeKa on LLiF with the gain about twice the normal value to shift the PHA peak to higher V and better resolve the escape peak.
Exporting the PeakSight PHA data to ASCII can be done by clicking the "Save" button in the Display WDS window (at least using PeakSight 4.2).
I've attached an Excel plot.
PeakSight exports 256 points starting at 0.56V and ending at 5.54 V. This matches the lowest possible baseline on the SX100 of 0.56V and maximum window of 5V (total of 5.56V). Interestingly, the data has a repeated Y value every 0.156V in X, and all values in between are perfectly on the plot line, so these in between values might only be interpolated and not real MCA channels.
PFE "traditional" scans are similar in peak position as the PeakSight PHA scan, better in resolution but the peak shapes are bad.
The PFE MCA scan with range 0-5V is shifted compared to the PeakSight scan, but not by 0.56V as expected, more like 0.8V. So PeakSight might be cutting something off at the high end. This would be supported by the curves in the attached graph where the PFE MCA curve has more "background" on the right of the PHA peak than PeakSight.
I will try to read out the data in PFE's verbose mode that's actually returned by the SX.
So below is what I get in debug mode, same settings as before (FeKa on LLiF...). Completely different baseline and window values returned, so maybe they're just random? Is it somehow possible to view the actual 256 data points that are returned?
Acquiring PHA acquisition...
Setting spectro 5 PHA (BWGBMD): .56 4.99 700 1824 -1 .000003
SX100GetPHADistributionMCA2: Motor= 5, Status= 1, MaxTries= 0
SX100GetPHADistributionMCA2: Motor= 5, Status= 1, MaxTries= 1
SX100GetPHADistributionMCA2: Motor= 5, Status= 1, MaxTries= 2
SX100GetPHADistributionMCA2: Motor= 5, Status= 1, MaxTries= 3
SX100GetPHADistributionMCA2: Motor= 5, Status= 1, MaxTries= 4
SX100GetPHADistributionMCA2: Motor= 5, Status= 1, MaxTries= 5
SX100GetPHADistributionMCA2: Motor= 5, Status= 1, MaxTries= 6
SX100GetPHADistributionMCA2: Motor= 5, Status= 1, MaxTries= 7
SX100GetPHADistributionMCA2: Motor= 5, Status= 0, MaxTries= 8
SX100GetPHADistributionMCA2: Motor= 5, Acquisition number=1
SX100GetPHADistributionMCA2: Baseline= 1517
SX100GetPHADistributionMCA2: Window= 1125
SX100GetPHADistributionMCA2: Alignment= 0
SX100GetPHADistributionMCA2: Index= 256
SX100GetPHADistributionMCA2 (Byte): Min= 0, Max= 254, CountTime= 1.555
SX100GetPHADistributionMCA2 (PHA Sum): Min= 0, Max= 249.8571
SX100GetPHADistributionMCA2 (Averaged): Min= 0, Max= 249.8571
SX100GetPHADistributionMCA2 (Normalized): Min= 0, Max= 160.6798
SX100GetPHADistributionMCA2: Motor= 5, Status= 1, MaxTries= 9
SX100GetPHADistributionMCA2: Motor= 5, Status= 1, MaxTries= 10
SX100GetPHADistributionMCA2: Motor= 5, Status= 1, MaxTries= 11
SX100GetPHADistributionMCA2: Motor= 5, Status= 1, MaxTries= 12
SX100GetPHADistributionMCA2: Motor= 5, Status= 1, MaxTries= 13
SX100GetPHADistributionMCA2: Motor= 5, Status= 1, MaxTries= 14
SX100GetPHADistributionMCA2: Motor= 5, Status= 0, MaxTries= 15
SX100GetPHADistributionMCA2: Motor= 5, Acquisition number=2
SX100GetPHADistributionMCA2: Baseline= 1517
SX100GetPHADistributionMCA2: Window= 1125
SX100GetPHADistributionMCA2: Alignment= 0
SX100GetPHADistributionMCA2: Index= 256
SX100GetPHADistributionMCA2 (Byte): Min= 0, Max= 254, CountTime= 1.308
SX100GetPHADistributionMCA2 (PHA Sum): Min= 0, Max= 496.1429
SX100GetPHADistributionMCA2 (Averaged): Min= 0, Max= 248.0714
SX100GetPHADistributionMCA2 (Normalized): Min= 0, Max= 189.6571
PHA acquisition complete
Quote from: Karsten Goemann on April 01, 2014, 04:04:44 PM
So below is what I get in debug mode, same settings as before (FeKa on LLiF...). Completely different baseline and window values returned, so maybe they're just random? Is it somehow possible to view the actual 256 data points that are returned?
Just turn on "VerboseMode".
Yeah, clearly your data actually is not ranging from 1.1 to 2.6 volts!
OK, I've done another test in verbose mode now and am getting the 256 individual values listed in the PFE log window. It shows the same behaviour that Y values are repeated every 8 channels.
If I use the following formula to convert channel number to voltage PFE and PeakSight MCA match (see attached screenshot of plots):
X axis value (V) = 0.56 V + channel number * (5V / 256)
Channel number is zero to 255. So this confirms 0.56 V baseline and 5 V window as MCA range.
This works for our SX100, which is SX#846, installed 2003, 68030 mainboard, Stage, WDS, and Scanning all "Old" as listed in Cameca config.
However, it might be different for newer SX100s and the SXFive, where the minimum baseline appears to be dynamically adjusted by the SX depending on x-ray energy (or spectro position).
Wow! Well I'm *almost* convinced that it's 0.56 to 5.56 volts!
Gareth do you see something similar on your instrument?
Karsten, John
You show me yours and I'll show you mine!
Looks like I have newer hardware on SX921 since my baseline for MCA acquisition is 'displayed' as 0V (should there be a 'noise' signal at low mV???)
Here is the ascii output from peaksight (full content attached). I deliberately set the gain low so that there are pulses at low mV (i.e. below the ~0.5mV baseline that you are seeing).
Interesting points to note:
1)there are pluses down to the first channel (0-19.5mV)
2)X = : mV (0 to 5000
3)despite the 8 bit cts (0 to 255), no single channel has 255cts - I thought this was the criteria for termination of the testPHA command?
Edit by John: I too have noted this...
4) MCA runs min mV to max mV regardless of base line and window that might be set in PFE or Peaksite. This
seems to be just the way it is. Presumably this is because the 8-bit MCA channel width is fixed in mV range to ~19.5mV per bit, and hence there would be no advantage to collecting a smaller V range than the max i.e. you can't improve on the ~19.5mV resolution.
Edit by John: That would make sense...
5)peaksight restricts my setting of the baseline , as you describe e.g. 597mV for LTAP on Sp1, 674mV for TAP on Sp2 etc. (this value must be stored somewhere? I would like to edit it - the current value is displayed in Configuration/Crystal but the limit is not set there, as far as I can tell). My window is restricted, as you mention, but in my case to BL + W = 5V. The dynamic baseline that Karsten mentions is called diff. Auto mode in Peaksight.
Edit by Gareth: Dynamic Baseline is a function of detector Gain. See discussion below.
On the older SX100 hardware are Count Diff. and Count integral both returned, regardless of which mode is being used?
Nothing in life is straight forward!
Gareth
ascii data attached.
I'm not sure this "dynamic baseline behaviour" is the same as Peak Sight's diff. auto. At least on our older SX100 the latter sets much narrower windows.
What I mean is that the minimum baseline setting you can set in both PHA integral and diff is not constant 560 mV as on older SX100s, but a value that depends on the spectrometer position or x-ray energy.
That's at least what I saw on the SXFive.
I.e. you wouldn't have a constant minimum baseline value per crystal, but the value should change depending on where you are in the spectrometer range.
I don't think these values are user adjustable.
In any case it looks like for the newer SXs it the MCA range might be 0-5 V which makes sense because then this "dynamic baseline" behaviour can be ignored for PHA scans for the sake of simplicity.
It's also interesting that in your ASCII data the count value every 8th channel is still a duplicate of the previous value and the "spacing" between those values is 0.156V. So that's the same as with my instrument.
Gareth, could you do a PFE MCA scan in verbose setting and save the corresponding PeakSight PHA scan (they might be identical as PeakSight seems to update the PHA scans display even when collected by PFE)? Then we could really compare directly.
Cheers, Karsten
On the topic of energy resolution (perhaps a question for someone from Cameca?) :
do we see differences between a 'traditional' PHA scan (with a fixed window and moving baseline) and the MCA scan because the two different methods are using different pulse processing hardware/signal paths ?
e.g. a physically separate single-channel analyser is being used for the 'traditional' scan?
or is the same MCA used for both, with the reduced resolution being the result of different pulse processing between the two methods (e.g. shaping time etc.)?
I guess I could look at the schematic and perhaps find the answer!
Gareth
Quote from: Karsten Goemann on April 01, 2014, 09:42:59 PM
I'm not sure this "dynamic baseline behaviour" is the same as Peak Sight's diff. auto. At least on our older SX100 the latter sets much narrower windows.
What I mean is that the minimum baseline setting you can set in both PHA integral and diff is not constant 560 mV as on older SX100s, but a value that depends on the spectrometer position or x-ray energy.
That's at least what I saw on the SXFive.
I.e. you wouldn't have a constant minimum baseline value per crystal, but the value should change depending on where you are in the spectrometer range.
I don't think these values are user adjustable.
In any case it looks like for the newer SXs it the MCA range might be 0-5 V which makes sense because then this "dynamic baseline" behaviour can be ignored for PHA scans for the sake of simplicity.
It's also interesting that in your ASCII data the count value every 8th channel is still a duplicate of the previous value and the "spacing" between those values is 0.156V. So that's the same as with my instrument.
Gareth, could you do a PFE MCA scan in verbose setting and save the corresponding PeakSight PHA scan (they might be identical as PeakSight seems to update the PHA scans display even when collected by PFE)? Then we could really compare directly.
Cheers, Karsten
OK, so you have Diff Auto too. I only just realised that the 'dynamic' baseline set-point is a function of detector Gain (not spectrometer position 'directly'). Thanks for bringing it to my attention. I've been fighting with this for a while. I guess moving the baseline 'up' as the gain increase is designed to prevent electronic noise being included. However, I find the escape peak is sometimes truncated by a cameca imposed (aka dynamic) baseline; here is a good example where increasing the Bias and reducing the Gain, would be a better option.
You're right, I dug out my notes on the SXFive again and I've actually collected lower baseline limit vs. gain curves, which is a linear correlation. I didn't have much time for that when working on the instrument.
I think you're right the reason would be cutting off the low energy noise.
For what its worth:
Gain max = 4095 (presumably 12 bit DAC), BL = 994
Gain min = 0, BL= 369mV
Dynamic BL = 0.152625*Gain + 369
Nice, I got
baseline (V) = 0.1524* gain + 368.73
for the SXFive.
Could that even be put into emppha.dat if we need to reproduce it in PFE?
Quote from: Karsten Goemann on April 01, 2014, 11:28:04 PM
Nice, I got
baseline (V) = 0.1524* gain + 368.73
for the SXFive.
Could that even be put into emppha.dat if we need to reproduce it in PFE?
You guys are good!
Yes. These coefficients could be added to the emppha.dat file...
Michel Outrequin offers these words of wisdom:
"The 256 intensities returned by the PHA routine are always from the minimum value (805 mV) to the maximum value (5637 mV)."
So I will change the MCA PHA limits in my code tonight...
Quote from: Karsten Goemann on April 01, 2014, 09:42:59 PM
Gareth, could you do a PFE MCA scan in verbose setting and save the corresponding PeakSight PHA scan (they might be identical as PeakSight seems to update the PHA scans display even when collected by PFE)? Then we could really compare directly.
Cheers, Karsten
Karsten,
Here is a spreadsheet with numbers from PFE (using debug+verbose mode), I have pasted in the peaksight ASCII output that corresponds to the same scan. Channel values correspond. Note: Cameca data has mV as x axis (0-5000mV), PFE has channel number.
Quote from: Probeman on April 02, 2014, 12:52:36 PM
Michel Outrequin offers these words of wisdom:
"The 256 intensities returned by the PHA routine are always from the minimum value (805 mV) to the maximum value (5637 mV)."
So I will change the MCA PHA limits in my code tonight...
presumably with the caveat that any Cameca with dynamic baseline hardware (newer SX100s and SX5) have values 0-5V !!!
Quote from: Gseward on April 02, 2014, 12:56:17 PM
Quote from: Probeman on April 02, 2014, 12:52:36 PM
Michel Outrequin offers these words of wisdom:
"The 256 intensities returned by the PHA routine are always from the minimum value (805 mV) to the maximum value (5637 mV)."
So I will change the MCA PHA limits in my code tonight...
presumably with the caveat that any Cameca with dynamic baseline hardware (newer SX100s and SX5) have values 0-5V !!!
How does one determine if they have "dynamic baseline hardware (newer SX100s and SX5)"? I mean from software...? Maybe the easiest thing is to make this a user defined setting in the probewin.ini file?
John,
I am confused: my assumption has been that the values reported in each channel were 'counts', and that the MCA was programmed to run until one channel hit 255 counts. Hence you needed to know the duration of testPHA in order to convert to cps. etc. etc.
I ask, because if you run testPHA with ~ no xrays (e.g. condenser at 4095 and the sample out of focus, or with 1kV beam etc) you get something that looks like this:
(https://smf.probesoftware.com/oldpics/i62.tinypic.com/28hpwt0.jpg)
total count Integral = 9, Count Diff. = 5 in 19.906s, which seems to be about the maximum time the testPHA runs. (values as reported by peaksight).
This seems to implies to me that some averaging and scaling is occurring in the MCA before the 'raw' values are reported. Perhaps this is only the case in a situation where there is no meaningful count rate i.e. this test? and as such we can ignore it, but I worry that the 'raw' data might not be what it seems...
I wonder if this relates to the Y axis differences between traditional and MCA data??
ASCII output for image is attached - note values of either 0 or 255.
Quote from: Probeman on April 02, 2014, 01:09:07 PM
Quote from: Gseward on April 02, 2014, 12:56:17 PM
Quote from: Probeman on April 02, 2014, 12:52:36 PM
Michel Outrequin offers these words of wisdom:
"The 256 intensities returned by the PHA routine are always from the minimum value (805 mV) to the maximum value (5637 mV)."
So I will change the MCA PHA limits in my code tonight...
presumably with the caveat that any Cameca with dynamic baseline hardware (newer SX100s and SX5) have values 0-5V !!!
How does one determine if they have "dynamic baseline hardware (newer SX100s and SX5)"? I mean from software...? Maybe the easiest thing is to make this a user defined setting in the probewin.ini file?
I would imagine that might be the easiest.
Hi John,
Quote from: Probeman on April 02, 2014, 12:52:36 PM
"The 256 intensities returned by the PHA routine are always from the minimum value (805 mV) to the maximum value (5637 mV)."
These values don't make sense for my "old" SX100 (#846, 2003), which appears to have a range of 560-5560mV:
http://smf.probesoftware.com/index.php?topic=217.msg1038#msg1038
Aren't the above values just what is returned on your instrument?
http://smf.probesoftware.com/index.php?topic=217.msg1027#msg1027
http://smf.probesoftware.com/index.php?topic=217.msg1031#msg1031
If I do that test I get 1517 for baseline and 1125 for window:
http://smf.probesoftware.com/index.php?topic=217.msg1033#msg1033
This seems random, so these values might not be used for anything if the actual minimum and maximum values for the PHA scan are fixed as Michel says.
Looking at your own PeakSight PHA scans, they also seem to have a range of 0.56 to 5.56:
http://smf.probesoftware.com/index.php?topic=217.msg979#msg979
So I assume your instrument is "old" like mine. What happens on your instrument if you try to set a baseline below 560mV in PeakSight?
A agree that a probewin.ini flag for dynamic baseline minimum (and 0-5V PHA range) might be best.
Quote from: Gseward on April 02, 2014, 01:37:29 PM
I am confused: my assumption has been that the values reported in each channel were 'counts', and that the MCA was programmed to run until one channel hit 255 counts. Hence you needed to know the duration of testPHA in order to convert to cps. etc. etc.
That is what I was told by Michel... it returns when 255 count has been reached or after 20 seconds, whichever comes first.
Quote from: Karsten Goemann on April 02, 2014, 04:05:33 PM
Quote from: Probeman on April 02, 2014, 12:52:36 PM
"The 256 intensities returned by the PHA routine are always from the minimum value (805 mV) to the maximum value (5637 mV)."
These values don't make sense for my "old" SX100 (#846, 2003), which appears to have a range of 560-5560mV:
http://smf.probesoftware.com/index.php?topic=217.msg1038#msg1038
If I do that test I get 1517 for baseline and 1125 for window:
http://smf.probesoftware.com/index.php?topic=217.msg1033#msg1033
This seems random, so these values might not be used for anything if the actual minimum and maximum values for the PHA scan are fixed as Michel says.
Looking at your own PeakSight PHA scans, they also seem to have a range of 0.56 to 5.56:
http://smf.probesoftware.com/index.php?topic=217.msg979#msg979
So I assume your instrument is "old" like mine. What happens on your instrument if you try to set a baseline below 560mV in PeakSight?
A agree that a probewin.ini flag for dynamic baseline minimum (and 0-5V PHA range) might be best.
OK, so yes I agree this is confusing, I am just relying what Michel said. But I have added new keywords in the [pha] section of the Probewin.ini file so you can set them to whatever you want... post coming soon...
Ok, I've implemented the new MCA PHA keywords for Cameca instruments as follows:
[pha]
PHAMultiChannelMin=0.805 ; Cameca MCA PHA minimum x-axis voltage
PHAMultiChannelMax=5.637 ; Cameca MCA PHA maximum x-axis voltage
for the [pha] section of the Probewin.ini.
According to Michel, older Sx100 instruments use 0.804 and 5.637, but it may be different for newer instruments.
I've also indicated this with a version bump:
http://smf.probesoftware.com/index.php?topic=40.0
and a post to the "new" INI parameters thread started by Julien:
http://smf.probesoftware.com/index.php?topic=36.msg1067#msg1067
john
This does not work for me. The values do not seem to apply to my machine. So, what is the best way to approach that? I do a traditional scan and then try to calibrate the MCA scan with the ini parameters?
It seems that the PfE traditoinal and PeakSight scans match pretty well.
So let's hope these ini values are not random... I mean different for every element...
For U Ma on a Qtz crystal for me the values are more 0.15 and 5.15. Strange enough: I plot the pha scan. I get a grid on the plot and lines. If I put my mouse on the grid line at 2.2 Volts, In the coordinate window it shows me 2.14 as the X coordinate. How can this be?
What means: ERROR in SX100GetPHADistributionMCASum : PHA MCA sum range parameters are equal and therefore represent a zero (invalid) range
Quote from: Philipp Poeml on April 04, 2014, 09:37:58 AM
The values do not seem to apply to my machine. So, what is the best way to approach that? I do a traditional scan and then try to calibrate the MCA scan with the ini parameters?
It seems that Cameca varied the x-axis voltage range with different instrument models. I think this is all we can do is check our own instrument and edit the Probewin.ini accordingly.
Quote from: Philipp PoemlIt seems that the PfE traditoinal and PeakSight scans match pretty well.
Good for you! If they match well then you don't need to edit your Probewin.ini. ;D
Quote from: Philipp PoemlFor U Ma on a Qtz crystal for me the values are more 0.15 and 5.15. Strange enough: I plot the pha scan. I get a grid on the plot and lines. If I put my mouse on the grid line at 2.2 Volts, In the coordinate window it shows me 2.14 as the X coordinate. How can this be?
Where is this? I need just a wee tiny bit more information unless we are playing "20 questions"! ;)
Quote from: Philipp PoemlWhat means: ERROR in SX100GetPHADistributionMCASum : PHA MCA sum range parameters are equal and therefore represent a zero (invalid) range
I again need more details: how did you produce this error? That is, under what conditions do you get the error? I have not seen this error, it is only there for a code "sanity check".
I just got another reply from Michel. Now he says something different.
Quote from: MichelThis morning, I ran a Test PHA on 4 different crystals (2TAPs and 1 PET on a L P spectro and 1 LPET on a high pressure spectrometer). The corresponding text file is attached. I was wrong, the Test PHA routine returns counts values between 0 and 5000mV as shown on the attached file.
I suspect that we are seeing that the older Sx100 instruments use 0.8 to 5.6 or so for the MCA PHA range, but newer Sx100s and SXFive instruments go from 0 to 5 volts?
Quote from: John Donovan on April 04, 2014, 11:07:13 AM
Quote from: Philipp Poeml on April 04, 2014, 09:37:58 AM
The values do not seem to apply to my machine. So, what is the best way to approach that? I do a traditional scan and then try to calibrate the MCA scan with the ini parameters?
It seems that Cameca varied the x-axis voltage range with different instrument models. I think this is all we can do is check our own instrument and edit the Probewin.ini accordingly.
This seams reasonable. I will try to do that.
QuoteQuote from: Philipp PoemlIt seems that the PfE traditoinal and PeakSight scans match pretty well.
Good for you! If they match well then you don't need to edit your Probewin.ini. ;D
In fact I will have to edit. I said PfE traditoinal and PeakSight scans match pretty well. The PfE MCA scan does not fit by something around 0.2 and 0.3 Volts. But this seems variable.
Quote
Quote from: Philipp PoemlFor U Ma on a Qtz crystal for me the values are more 0.15 and 5.15. Strange enough: I plot the pha scan. I get a grid on the plot and lines. If I put my mouse on the grid line at 2.2 Volts, In the coordinate window it shows me 2.14 as the X coordinate. How can this be?
Where is this? I need just a wee tiny bit more information unless we are playing "20 questions"! ;)
Sorry, I try to explain, but it seems I rarely succeed. Basically it is in any PHA plot, see this image. I tried to include the mouse coursor, but it did not show up in the screen shot: The tip is pointing exactly to the 2.2 Volts vertical line.
(https://smf.probesoftware.com/oldpics/i57.tinypic.com/rviv08.jpg)
Quote
Quote from: Philipp PoemlWhat means: ERROR in SX100GetPHADistributionMCASum : PHA MCA sum range parameters are equal and therefore represent a zero (invalid) range
I again need more details: how did you produce this error? That is, under what conditions do you get the error? I have not seen this error, it is only there for a code "sanity check".
Normally I was trying to do the PfE MCA scan with Count Time .1 and Intervals 40, the default values. I changed the Intervals to 60 and I got this error message. Still, the PHA scan seemed to display correctly.
Quote from: Philipp Poeml on April 07, 2014, 01:07:58 AM
Sorry, I try to explain, but it seems I rarely succeed. Basically it is in any PHA plot, see this image. I tried to include the mouse coursor, but it did not show up in the screen shot: The tip is pointing exactly to the 2.2 Volts vertical line.
(https://smf.probesoftware.com/oldpics/i57.tinypic.com/rviv08.jpg)
I see now what you mean. Yes, this is a "feature" of the graphics control I am using. It occasionally (though rarely) rounds the numbers on the graph tick mark labels so they aren't always as accurate as they could be. So it is something that I can't directly control, but I will be implementing a new graphics control this year that will take care of this.
In the meantime the mouse cursor X/Y display is the most accurate value.
Quote from: Philipp PoemlWhat means: ERROR in SX100GetPHADistributionMCASum : PHA MCA sum range parameters are equal and therefore represent a zero (invalid) range
Normally I was trying to do the PfE MCA scan with Count Time .1 and Intervals 40, the default values. I changed the Intervals to 60 and I got this error message. Still, the PHA scan seemed to display correctly.
Ah, OK, I will check for this now! Thanks!
John,
I've tested the new PHA MCA keywords in Probewin.ini a bit.
I can get a perfect match between PFE and PeakSight if I use PFE's verbose output of the 256 channels to the log window, see Excel plot screenshot attached. This is using 0.56V for the range minimum and 5.54V for the range maximum. The blue curve is not visible because it is completely covered by the green curve.
I'm using the same minimum and maximum values in Probewin.ini, but PFE's output of the same PHA scan (using the Export Data function in PHA | Display and Export Scans) seems scaled differently (red curve). This is using 0.1 for count time and 40 intervals.
How are you processing the data into 40 channels from 256? Would it be possible to just use the 256 raw channels and recalculate the x value based on the min-max settings? At the moment I can't set the intervals value for PHA acquisition to 256 without getting the error I've reported before.
Cheers,
Karsten
Karsten,
I think I have the same issue here. It just seems I can't set the values right in the probewin.ini. I will try and check with the verbose output as well and plot the curves in Excel.
Cheers
Ph
Hi Phillip,
I don't know if you've read your way through the whole thread, but based on the testing that Gareth and I have done on our instruments there might be as few as two different settings for these limits which depend on the instrument generation. But it would be good to confirm this on more instruments.
Range of 0-5V for newer SX100 and SXFive, which appear to have this "dynamic baseline" behaviour, where the minimum baseline value you can set in PeakSight depends on the gain setting, i.e. a linear correlation from baseline 0.369V at gain zero to 0.994V at gain 4096.
Range of 0.56 - 5.54V for older SX100s, where the minimum baseline you can set in PeakSight is always 0.56V. This is basically a 5V range as well - I think the missing 0.02V to 5.56V might just be the width of the final channel (5V / 256 channels = 0.0195V, rounded to 0.02V).
One way to find out your PHA range might be by saving a PHA scan to ASCII in PeakSight (click the Save button in the top right corner of the SX Control | Display | WDS | PHA window, only available in newer PeakSight versions). PeakSight seems to display the last PHA ROM/MCA scan even if it was acquired with PFE, so you can export the data for the same PHA scan in both softwares (in PFE doing both the verbose log window and normal export) and compare directly in Excel, which is how I created the graph I attached to the last post.
One thing we're also seeing on our "old" SX100 is a slight shift in the PHA distribution depending on if it is acquired directly after the Faraday cup is switched out or if the beam has already been on the sample/standard for some time. The counting system seems to have to settle for some time once hit by x-rays. I don't know exactly for how long, might be less than a second. But this is why I when doing these tests always switch the cup out, wait a couple of seconds and then do the PHA scan. After that initial "settling" period the PHA peak doesn't appear to shift anymore.
Cheers,
Karsten
PS: I see in Gareth's PeakSight data for the "new" SX100 that it is the same there too, i.e. the voltage range is 0V to 4.98V, not 0 - 5 V, so the missing 0.02V is probably again just the width of the last channel of 0.02V.
Quote from: Karsten Goemann on April 07, 2014, 07:41:27 PM
I've tested the new PHA MCA keywords in Probewin.ini a bit.
We really appreciate it!
Quote from: Karsten Goemann
I can get a perfect match between PFE and PeakSight if I use PFE's verbose output of the 256 channels to the log window, see Excel plot screenshot attached. This is using 0.56V for the range minimum and 5.54V for the range maximum. The blue curve is not visible because it is completely covered by the green curve.
I'm using the same minimum and maximum values in Probewin.ini, but PFE's output of the same PHA scan (using the Export Data function in PHA | Display and Export Scans) seems scaled differently (red curve). This is using 0.1 for count time and 40 intervals.
How are you processing the data into 40 channels from 256? Would it be possible to just use the 256 raw channels and recalculate the x value based on the min-max settings? At the moment I can't set the intervals value for PHA acquisition to 256 without getting the error I've reported before.
Good question. Here is the latest code for the conversion from 256 to n points (it is not uploaded yet, probably later tonight).
SX100GetPHADistributionMCASum = 0#
' Calculate range (total range is 256 values or 0 to 255)
m% = BIT8& / CSng(npoints%)
i% = m% * (n% - 1) + 1
j% = (i% + m%) - 1
If i% < 1 Then i% = 1
If i% > BIT8& + 1 Then i% = BIT8& + 1
If j% < 1 Then j% = 1
If j% > BIT8& + 1 Then j% = BIT8& + 1
' Sum range
temp! = 0#
For k% = i% To j%
temp! = temp! + CSng(bArray(k% - 1))
Next k%
' Average range
temp! = temp! / ((j% - i%) + 1)
SX100GetPHADistributionMCASum = temp!
The new code (will upload tonight) also now handles 256 point acquisitions just fine as seen here:
(https://smf.probesoftware.com/oldpics/i62.tinypic.com/2ro2kic.jpg)
But I'm still a little dismayed that the MCA method seems to have lower energy resolution than the traditional PHA method as seen here:
(https://smf.probesoftware.com/oldpics/i61.tinypic.com/v64xi1.jpg)
(https://smf.probesoftware.com/oldpics/i61.tinypic.com/a3e3h2.jpg)
Note in the two PHA scans above that both scans peak around 2.5 volts, but the traditional PHA scan shows the escape peak more clearly.
Guys,
I tested the .exe John shared on dropbox. This is what I get now:
(https://smf.probesoftware.com/oldpics/i60.tinypic.com/2urruba.jpg)
This is PeakSight PHA scan over the PfE MCA scan. My parameters are:
PHAMultiChannelMin=0 ; Cameca MCA PHA minimum x-axis voltage
PHAMultiChannelMax=5 ; Cameca MCA PHA maximum x-axis voltage
This is for U Ma on a high pressure spectro and Qtz crystal. .1 counting; 40 channels.
This looks pretty good, doesn't it? As expected. I think the new code is good.
I did not try to look at any escape peaks now. But I am happy that the PHA peak is at the right voltage. Basically for non-escape peak studies this is usable now.
My SXR should be a "new" type.
How are your scans going?
Cheers
Philipp
Btw, trying with .5 seconds counting and 256 channels I got:
(https://smf.probesoftware.com/oldpics/i60.tinypic.com/9i6wj7.jpg)
Ph
Quote from: Philipp Poeml on April 10, 2014, 05:16:16 AM
Btw, trying with .5 seconds counting and 256 channels I got:
(https://smf.probesoftware.com/oldpics/i60.tinypic.com/9i6wj7.jpg)
You must be a very patient man! I've written the code so the routine continues to average the MCA PHA values for a time period equal to the count time times the number of points, so 0.5 times 256 equals 128 seconds which is a long.... time!
I can only assume that maybe you accidentally tried to move a stage or spectro axis during the PCA acquisition?
I'm more interested in why the Cameca MCA intensities seem to form line segments, e.g.:
(https://smf.probesoftware.com/oldpics/i62.tinypic.com/14mfces.jpg)
Quote
You must be a very patient man! I've written the code so the routine continues to average the MCA PHA values for a time period equal to the count time times the number of points, so 0.5 times 256 equals 128 seconds which is a long.... time!
I can only assume that maybe you accidentally tried to move a stage or spectro axis during the PCA acquisition?
No, in fact there was no time difference between 0.1/40 and 0.5/256. It did not take two minutes at all. The acquisitoin time was exactly the same, about 10-15 seconds or so.
I will try again, but I did not move anything; there is also no reason to move something during these 10 seconds. I can also count the time, if that helps.
Quote from: Philipp Poeml on April 11, 2014, 12:59:10 AM
Quote
You must be a very patient man! I've written the code so the routine continues to average the MCA PHA values for a time period equal to the count time times the number of points, so 0.5 times 256 equals 128 seconds which is a long.... time!
I can only assume that maybe you accidentally tried to move a stage or spectro axis during the PCA acquisition?
No, in fact there was no time difference between 0.1/40 and 0.5/256. It did not take two minutes at all. The acquisition time was exactly the same, about 10-15 seconds or so.
I will try again, but I did not move anything; there is also no reason to move something during these 10 seconds. I can also count the time, if that helps.
If you track down the cause, please let me know. I will also try this long count time on some MCA PHA scans of my own.
I've tested again on our "old" SX100 #846 with the latest PFE version 10.3.4, downloaded this morning, using settings of 0.56 for minimum and 5.54 for maximum, 256 "intervals".
PeakSight and PFE PHA scans match perfectly for all spectrometers. There are some small differences but that is I think due to PeakSight only exporting the last scan and PFE averaging multiple scans.
It doesn't seem to matter what the actual baseline/window settings are or if it is set to integral/differential, the range returned by the SX always appears to be the same, 0.56 to 5.54V, i.e. a 5V range minus the width of channel 256. I'm confident that this is the right setting and will use it from now.
PFE doesn't let me set the counting time per interval lower than 0.1s which as far as understand means the actual scan runs 25.6 seconds, which seems about right. Within that time it's probably averaged at least 10 PHA scans which seems a little excessive.
Edit by John: OK, I've set the minimum PHA interval time to 0.05 sec, so if the default is say 40 points that's only 2 seconds of total acquisition.
Hi,
Please, can anyone summarize the differences between PHA scans in peaksight and PFE? On this "old-SX100" using PFE software I obtain the asymmetric distribution of spikelets or extreme narrow distributions, and errors if I choose more than 100 points. I think I am using always "traditional" PHA, because I have no MCA options in the PHA Properties window.
Thanks in advance,
Jared
Quote from: jared.wesley.singer on September 19, 2014, 08:30:08 AM
Please, can anyone summarize the differences between PHA scans in peaksight and PFE? On this "old-SX100" using PFE software I obtain the asymmetric distribution of spikelets or extreme narrow distributions, and errors if I choose more than 100 points. I think I am using always "traditional" PHA, because I have no MCA options in the PHA Properties window.
Note sure what you mean by "spikelets", can you post a pic? The main difference between PeakSight and Probe for EPMA is that PeakSight only has the MCA PHA type while PFE has both the traditional and MCA type.
john
The option to change the PHA acquisition type is found in the Acquisition Options dialog.
Note also, the default PHA acquisition type can be specified in the INI file.
I can not post images. :-[
I have no MCA in Acquisition Options. :'(
Can I suggest a greater selection of frustrated and sad faces? :(
It's quitting time. ;D
Quote from: jared.wesley.singer on September 19, 2014, 03:12:35 PM
I can not post images. :-[
Oh yes you can!
http://smf.probesoftware.com/index.php?topic=6.msg14#msg14
Quote from: jared.wesley.singer on September 19, 2014, 03:12:35 PM
I have no MCA in Acquisition Options. :'(
Oh yes you do!
http://smf.probesoftware.com/index.php?topic=42.msg883#msg883
Quote from: jared.wesley.singer on September 19, 2014, 03:12:35 PM
Can I suggest a greater selection of frustrated and sad faces? :(\
Probably!
Quote from: jared.wesley.singer on September 19, 2014, 03:12:35 PM
It's quitting time. ;D
You got it now!
Many thanks, John (8)). Updated software and a shiny-new tinypics account! I'll try out the MCA next week ASAP.
This is an old thread but since people have been discussing PHA recently on the SX50 listserver, and also comparing the MCA (multi channel analyzer) PHA versus the traditional SCA (single channel analyzer) PHA, I decided to run some tests on my instrument which (except for Spectro 1 which has a cracked crystal and therefore lower intensities), should be a good comparison of a (mostly) normally running SX100 instrument.
If you look at the filenames of the images attached below (login to see attachments), you'll note that I ran PHA using MCA and SCA on Ti Ka on all five spectrometers at both 10 nA and 100 nA. I used 0.1 sec per point and 40 points on the (traditional) PHA SCA scans.
As noted previously in other topics, the MCA method produces PHA data much faster but at much lower energy resolution. I guess that's Heisenberg for you! :)
It's also interesting to toggle between the 10 nA and 100 nA PHA scans (both MCA and SCA) and one can see the PHA peaks at 100 nA shifting to higher voltages from the lower intensities at 10 nA.
Hi all
I have finally found some time to start using MCA in PfE, and am struggling at the moment to get my PHA plots from Peaksite to match with those I acquire in PfE. I have an SXFive with dynamic baseline behaviour, and as such have modified my ini file to the following parameters:
PHAMultiChannelMin="0"
PHAMultiChannelMax="5"
When I run a PHA through Peaksite, visually I can see the plot continuing all the way up to 5V, however when I export the PHA plot through Peaksite the voltage column only goes up to a maximum of 4.826V? Looking at the rest of this post I note Gareth's finished at 4.98V where it was assumed the last 0.02V was the last channel missing, but mine is missing ~0.174 V...
What is strange is that a visual inspection of the PHA plot in Peaksite I can even see little inflections in the curve right up to 5V where there must be datapoints...
(https://smf.probesoftware.com/gallery/318_24_02_20_9_05_35.jpeg)
As a result, when I overlay a Peaksite PHA plot (using data exported from Peaksite which only goes up to 4.826V), to one that I acquire in PfE which acquires all the way up to 5V (using 0.1s/256 intervals), there is an obvious mismatch as below:
(https://smf.probesoftware.com/gallery/318_24_02_20_9_18_29.jpeg)
The shapes of the plot are identical, however there is a lateral offset of which I was hoping was going to be 0.174V, but its actually around 0.130V. Also there is a strange increase in channel intensity when I acquire through PfE, and I dont know why this is.
Doing just a visual comparison the PHA plot acquired in Peaksite I see that it is centred around 3.6V and has a Y maxima of ~250. When I run the PHA scan through PfE I can see the PHA plots acquire in Peaksite, and Peaksite displays the last acquired scan from PfE. Visually I can see it is almost identical to that acquired through Peaksite in both peak maxima and peak centre (ie centred at ~3.6V, Y maxima ~250). See image below of the side by side comparison. You could be forgiven to think they are the same plot but they are actually subtly different.
(https://smf.probesoftware.com/gallery/318_24_02_20_9_36_38.jpeg)
So visually I think I am OK that the MCA PHA scan in PfE is doing the same as what Peaksite is doing, but it would have been nice to confirm that by overlaying some plots on each other!! Does anyone have any experience with what might be going on here with regards to my voltage maxima from export of 4.826V, and why my maxima channel counts are totally different in my PfE PHA scan....I am tearing my hair out.
Cheers
Hi Ben,
Please don't tear your hair out! :)
Here's the thing with the Cameca MCA PHA method: the function call only returns the intensity data, not the voltage values. The voltage values are calculated based on the INI file PHA Min/Max and what those should be is not exactly clear to me.
I'd suggest two things. First, turn on DebugMode in PFE and you will see much of the low level communications during the PHA acquisition. In fact if you turn on VerboseMode you will even see the raw intensities coming back from the instrument in the PFE log window.
But due to the design of the MCA electronics (only 8 bit MCA), I wouldn't attempt to glean much scientific information from these scans. Instead I would turn off the MCA mode and acquire your PHA scan one point at a time as god intended! ;)
See here to acquire "traditional" PHA scans on your Cameca instrument:
(https://smf.probesoftware.com/gallery/395_25_02_20_12_12_37.png)
You will obtain quite different (higher resolution) scans and the voltage values will be exactly what they claim to be.
Hi John
Ha right OK thanks I will continue to acquire my PHA as the creator intended....but now that we are opening pandora's box this takes me to my next problem and why I wanted to start using MCA for PHA in PfE. I just cannot get good traditional PHA scans in PfE no matter what beam current, x-ray line, window, software/ini settings I use, they always come out extremely "jagged" and useless. This has always been the case for me so I have just been using Peaksite for PHA scans, and PfE for Gain and Bias scans.
Below are some examples of "traditional" PHA scans I get in PfE (Count Time of 1/256 intervals).
(https://smf.probesoftware.com/gallery/318_25_02_20_7_01_25.jpeg)
(https://smf.probesoftware.com/gallery/318_25_02_20_7_01_42.jpeg)
(https://smf.probesoftware.com/gallery/318_25_02_20_7_01_57.jpeg)
You can see they are pretty horrible. I don't know if its any way related, but I also get really strange artifacts in my Gain scans in PfE. See some Gain scans below of different elements on different spectrometers (all at same beam current, counttime/interval of 1/256). Although not entirely obvious on SP5/LIF I think there is still weirdness at those points. If I use PET on SP5 I still see the bumps as well.
(https://smf.probesoftware.com/gallery/318_25_02_20_7_24_29.jpeg)
What is really weird is that those strange "bumps" in CPS all somehow coincide with each other on the X-axis even on scans done on totally different days at totally different Gain voltage ranges on totally different crystals?? How is that even possible? These "bumps" do not occur in any Bias scans, only in Gain scans. I have tried changing point time settings and interval and it makes no difference, they all still occur at exactly the same places...
Here are gain scans on Si Ka at different count times and interval settings:
(https://smf.probesoftware.com/gallery/318_25_02_20_7_55_11.jpeg)
The only thing I can think of is that its some strange time dependant thing going on from when you initiate a scan, and at these very specific regular time intervals it somehow changes the acquisition time per spot to change the resultant calculated CPS number?? But I dont really see how that would work as it should change the periodicity when I change the count time?
For reference here are the Bias scans:
(https://smf.probesoftware.com/gallery/318_25_02_20_7_34_53.jpeg)
Also while we are on the topic and looking in pandora's box , I have a few other problems....
1) There is a tiny bug in exporting Gain/Bias scans from the from the display fitting window, in that when you click on the "Export Data" button and you get the window to save the DAT file, the automated file name it pops up with labels it as the opposite of what it is (in that if you are trying to export a Bias scan it labels it as a Gain scan and vice versa);
2) Mostly a comment, but in Bias scans the first data point is almost always some randomly high CPS value which I just ignore. I was wondering if it was a voltage settling thing after changing the Bias a large amount, as I saw the PHAFirstTimeDelay setting in the ini. I increased this from 5 to 10 seconds which didnt make a difference, so I guess that setting is just for PHA scans not Bias scans?
3) I cannot run PHA scans automated, only manually one at a time through the PHA properties window. If I attempt to run PHA scans through automated actions I get the error message below
(https://smf.probesoftware.com/gallery/318_25_02_20_6_44_28.jpeg)
These settings are corresponding to the first element its trying to do a scan for, but they all seem fine to me I cannot see anything wrong? I have checked my scalers file to make sure nothing is whack in there but it all seems fine.
Cheers
Well that doesn't look very good at all! Try running some scans with only 40 points or so. Also increase the time per point. Be patient!
I'll try running some non MCA PHA scans on my instrument and see what I get, but it probably won't be until next week.
john
My traditional PHA scans look as crappy as Ben's. Exactly the same. One thing we tried was to get "purer" P10 gas, but this did not seem to help. I would also be very interested in a solution to this.
There's several things to consider here.
First of all the MCA method uses several loops of averaging to "smooth" the intensity data. And because it's always integrating, it can acquire more photons per clock time, just as a ROM (continuous) wavescan is more efficient than a step/count wavescan.
This is why the MCA PHA method is preferred for normal use. My point was simply that if Ben is interested in making exact measurements of his PHA distributions, he might want to try using the "traditional" PHA method. Because then the X axis (voltage) values are exactly known. Again, analogous to step/count wavescans where the spectrometer position (x-axis) is exactly known and not calculated by interpolation as when performing ROM (continuous) wavescans.
Second of all, one needs to have a sufficient integration time when performing "traditional" PHA scans. The default in PFE in 0.1 seconds for 40 acquisition points. Running the default PHA scan parameters (0.1 sec/40 points), here is a "traditional" PHA scan from my SX100 this morning:
(https://smf.probesoftware.com/gallery/395_26_02_20_8_15_57.png)
And here is an MCA PHA acquisition using the same conditions:
(https://smf.probesoftware.com/gallery/395_26_02_20_8_27_53.png)
My point is simply that one gets better energy resolution and more accurate x-axis values (voltage) when using the traditional PHA acquisition method.
I have no idea why anyone would think that this has anything to do with the purity of the detector gas. Both PHA acquisition methods are using the same detector!
Quote from: BenjaminWade on February 25, 2020, 07:37:31 PM
1) There is a tiny bug in exporting Gain/Bias scans from the from the display fitting window, in that when you click on the "Export Data" button and you get the window to save the DAT file, the automated file name it pops up with labels it as the opposite of what it is (in that if you are trying to export a Bias scan it labels it as a Gain scan and vice versa);
Hi Ben,
I will look into this. I haven't used the Export PHA button in many years, thanks for the heads up.
Quote from: BenjaminWade on February 25, 2020, 07:37:31 PM
2) Mostly a comment, but in Bias scans the first data point is almost always some randomly high CPS value which I just ignore. I was wondering if it was a voltage settling thing after changing the Bias a large amount, as I saw the PHAFirstTimeDelay setting in the ini. I increased this from 5 to 10 seconds which didnt make a difference, so I guess that setting is just for PHA scans not Bias scans?
It makes a lot of sense because the bias scan lowers the bias voltage dramatically for the first point and it could very well require some settling time when the bias voltage is lowered by that much. But the PHAFirstTimeDelay setting is the wrong one to change. This value is only applied the *first time* the bias voltage is set on that spectrometer (per application instance). You'd have more luck by editing the BiasChangeDelay parameter in the [software] section of the Probewin.ini file.
But I think a better solution is for Probe Software to add a small delay after setting the first bias voltage in the bias scan acquisition
Quote from: BenjaminWade on February 25, 2020, 07:37:31 PM
3) I cannot run PHA scans automated, only manually one at a time through the PHA properties window. If I attempt to run PHA scans through automated actions I get the error message below
(https://smf.probesoftware.com/gallery/318_25_02_20_6_44_28.jpeg)
These settings are corresponding to the first element its trying to do a scan for, but they all seem fine to me I cannot see anything wrong? I have checked my scalers file to make sure nothing is whack in there but it all seems fine.
I don't think this has to do with the automation per se, but we are looking into it. I suspect it has to do with using so many points per PHA scan. That is, when I use the default 0.1 seconds and 40 points I have no trouble running automated PHA scans from the Automate! window.
Here is a comparison of "traditional" PHA for Fe Ka on my Cameca Sx100:
(https://smf.probesoftware.com/gallery/395_26_02_20_9_05_19.png)
Again using 0.1 seconds and 40 points. Note that the escape peak is much better separated from the main peak. And here is the MCA PHA for Fe Ka using the same conditions:
(https://smf.probesoftware.com/gallery/395_26_02_20_9_05_35.png)
Note that the energy resolution is significantly less in the MCA PHA acquisition, making the escape peak less visible. This is actually a *good* thing in several ways, since the escape peak photons are actually Fe Ka x-rays, just with an energy loss equal to the emission energy of the Ar K shell. So including them in ones PHA range is more accurate (when considering gain shifting from different Fe emission intensities due to composition) and also better statistics.
The MCA although returning 256 channels may in fact only have 32 channels as the values in between look like they are interpolated (linear), see earlier posts in thread. If this is true this would limit the spectral resolution a lot. I've used these settings in probewini.ini on our SX100 because of that:
PHACountTime="0.1" ; default integration time for PHA acquisitions
PHAIntervals=32 ; default PHA intervals
We could never get good gain scans on our SX100 either, with similar step artefacts to what you've found. My thoughts back then were that the electronics may need more time to settle in between gain changes, but I'm not sure if that's the actual explanation. The Cameca philosophy seems to be to allow the PHA peak to move, rather than always forcing it to a 2V maximum or something like that for every x-ray line measured. With the forced extended deadtime there's probably less danger of running into deadtime correction issues and we did not find pulse height depression an issue at reasonable count rates. We had a general rule of thumb to not go above 20kcps. We tended to use pretty much fixed gain & bias values for a given spectro/crystal combination (which were very stable over time) and just changed baseline and window (PHA diff) as required.
Hi Karsten,
The Cameca MCA function call does indeed return 255 discrete values, and they may be smoothed before they are returned by the firmware, but I suspect not. As 255 channels would be a normal 8 bit MCA, which makes sense that Cameca would utilize this.
I'm more concerned with the *non* MCA mode for PHA scanning on the Cameca, and why the returned distribution is so "spiky" when more than 80 or so values are measured. Probeman can confirm that this does indeed occur on his SX100 instrument also.
The concern is that we use the same code to acquire JEOL and Cameca non MCA PHA scans, using the same function call that we use for normal WDS photon counting. So just as a sanity check we'd really like to see a JEOL PHA scan on a strong peak using a 1 second integration time and say 200 or so intervals. Do these JEOL PHA scans look as "spiky" as Benjamin's SXFive scans?
The good news is that we at Probe Software found a fixed the several minor bugs that Benjamin reported yesterday, specifically 1), the problem running non MCA PHA scans with over 80 points when performing automated peaking from the Automate! window, 2), the naming of the PHA scan export file and 3), we added a delay after setting the first bias voltage for a bias scan.
Right now this first point bias scan delay is using the RealTimeInterval from the Probewin.ini file, which is usually around 400 ms or so, but we could use another value, in fact, thinking about it maybe we should.
Benjamin: please download and try this latest version of PFE and see if you get a smaller intensity for the first point on your bias scans and feel free to test the other bug fixes.
But as to what is causing these "spiky" PHA scans on the Cameca when running in non MCA mode with 80 or more points is still a mystery.
Karsten: if you get a chance please test a PHA scan using 200 points on your 8530. Anette just sent me a scan from her JEOL instrument and it looks completely fine. So it appears to be a problem specific to the Cameca instrument when in non MCA mode.
I wonder if Cameca's firmware is messing with the gain or something when the PHA window is being adjusted during non MCA PHA scans?
Hi all
Many thanks for the replies, I am glad I am not the only one re: PHA scans and weird gain scans...
John I appreciate your comment re: resolution of SCA vs MCA PHA scans which is why I was hoping to get it working OK in PfE. However I still think something strange is going on with my PHA scans and its not a count/integration time issue, or a #of points issue. Below are scans ran with 40 points at 0.1/1/10 seconds and you can see that the strange spikiness occurs in all, just at different amounts of scatter.
(https://smf.probesoftware.com/gallery/318_26_02_20_3_56_25.jpeg)
(https://smf.probesoftware.com/gallery/318_26_02_20_3_56_39.jpeg)
(https://smf.probesoftware.com/gallery/318_26_02_20_3_56_50.jpeg)
With regards to other comments, you have just replied while I am still writing this! Great news with the Automate, I can confirm from testing this morning that it was anything over 80 points that it crapped out on. I must have missed that Bias delay setting in the ini file as well, thanks for pointing that one out.
Quote from: Karsten Goemann on February 26, 2020, 03:32:27 PM
We could never get good gain scans on our SX100 either, with similar step artefacts to what you've found. My thoughts back then were that the electronics may need more time to settle in between gain changes, but I'm not sure if that's the actual explanation. The Cameca philosophy seems to be to allow the PHA peak to move, rather than always forcing it to a 2V maximum or something like that for every x-ray line measured. With the forced extended deadtime there's probably less danger of running into deadtime correction issues and we did not find pulse height depression an issue at reasonable count rates. We had a general rule of thumb to not go above 20kcps. We tended to use pretty much fixed gain & bias values for a given spectro/crystal combination (which were very stable over time) and just changed baseline and window (PHA diff) as required.
I am glad its not only me re: the weird steps in the gain scan. I will email Cameca and see what they say. I am not sure its a gain settling issue at least on my system, as 1) the bumps occur so regularly in every scan you do at exactly the same Gain values for a given x-ray line; and 2) I did a laborious manual gain scan in peaksite yesterday waiting 10 seconds after changing the gain and got exactly the same bumps in returned CPS at the same places. So something very weird is going on in the electronics.
Cheers
Hi Ben,
On your non MCA PHA scans above, it seems that they look more "steppy" than "spiky", at least in the 10 second interval scan. I wonder what could be going on... Anette just sent me this screensnap showing a 256 point PHA scan on her JEOL 8530 which looks perfectly good:
(https://smf.probesoftware.com/gallery/395_26_02_20_4_45_00.png)
She says she's never seen anything weird in her PHA scans. But this is a little hard to compare because the JEOL instruments cannot do MCA PHA scans, and the Cameca PeakSight software cannot do non MCA PHA scans (that I am aware of).
On the gain scan issue, I did not run any of those today. Can you post an example of the weirdness in your PHA gain scans?
One possibility with bias scans is that there might be a 10 volt resolution limitation in setting the high voltage. There might be something similar with gain scans. I need to look through the code and see if there are any notes in there.
Quote from: Probeman on February 26, 2020, 04:50:37 PM
One possibility with bias scans is that there might be a 10 volt resolution limitation in setting the high voltage. There might be something similar with gain scans. I need to look through the code and see if there are any notes in there.
In other words, try some more scans (PHA, gain and bias) in PFE using a long count time, and see if you can observe on the Cameca PeakSight software what the actual increments are being displayed, for the x-axis values. Maybe while in debug mode in PFE and observing the calculated values sent to the instrument.
I suspect we might see something interesting.
Hi John
Yes perhaps my terminology wasn't quite right, it is perhaps more steppy than spikey.
My gain scan issue is what I previously posted regarding the "bumps"
Quote from: BenjaminWade on February 25, 2020, 07:37:31 PM
..You can see they are pretty horrible. I don't know if its any way related, but I also get really strange artifacts in my Gain scans in PfE. See some Gain scans below of different elements on different spectrometers (all at same beam current, counttime/interval of 1/256). Although not entirely obvious on SP5/LIF I think there is still weirdness at those points. If I use PET on SP5 I still see the bumps as well.
(https://smf.probesoftware.com/gallery/318_25_02_20_7_24_29.jpeg)
What is really weird is that those strange "bumps" in CPS all somehow coincide with each other on the X-axis even on scans done on totally different days at totally different Gain voltage ranges on totally different crystals?? How is that even possible? These "bumps" do not occur in any Bias scans, only in Gain scans. I have tried changing point time settings and interval and it makes no difference, they all still occur at exactly the same places...
Here are gain scans on Si Ka at different count times and interval settings:
(https://smf.probesoftware.com/gallery/318_25_02_20_7_55_11.jpeg)
The only thing I can think of is that its some strange time dependant thing going on from when you initiate a scan, and at these very specific regular time intervals it somehow changes the acquisition time per spot to change the resultant calculated CPS number?? But I dont really see how that would work as it should change the periodicity when I change the count time?
For reference here are the Bias scans:
(https://smf.probesoftware.com/gallery/318_25_02_20_7_34_53.jpeg)
My Bias scans are fine and I have no issues there, its just the strange plateau bumps in the Gain scans. From Karsten's comments it appears that perhaps he encountered similar issues as well. As per my quoted post above changing the count time had no effect on removing the artifacts in the gain scan.
I have no idea if my Gain problem is related to the steppy/spiky nature of the PHA scans. Would be interested to see if Philip also has strange Gain scans given he might be encountering the same problem I am having with the PHA scans.
What I did yesterday was manually run a Gain scan in the Peaksite software by manually setting the baseline and window, then starting at 1200V incrementing the Gain in 10V increments, waiting a few seconds then recording the resulting CPS. The resulting data is below and as you can see it looks identical to what I get running a Gain scan in Probe for EPMA.
(https://smf.probesoftware.com/gallery/318_26_02_20_5_39_42.jpeg)
So I think its some weirdness direct from the SXFive electronics. I have emailed Cameca and am awaiting a reply.
With regards to the PHA scan problem, I will run some more PHA scans and watch to see what is happening to the increments in Peaksite and debug mode. If my PHA steppy problem is related to the Gain problem though I suspect I wont see a problem given I got the same result manually running the Gain scan in Peaksite
Cheers
Ok John, once again you are dead right. There is something weird going on with the increments displayed in Peaksite when running a PHA scan. Its a bit hard to explain but basically when the scan is initiated the first baseline voltage in both PfE debug and Peaksite match perfectly. Following this the voltage displayed in Peaksite will lag behind for two measurements and on the 4th measurement "catch up" with what is displayed in PfE. These "catch up" points correspond to the highs of the spikes in the PHA scan. I made sure I used a long count time of 5 seconds to make sure Peaksite had time to "catch up" but it made no difference. Its hard to explain but hopefully the graphic below makes sense.
(https://smf.probesoftware.com/gallery/318_26_02_20_6_10_34.jpeg)
So basically if I fit a curve to every 3rd point I would have my nice PHA scan....
I did the same with a Gain scan with similar results:
(https://smf.probesoftware.com/gallery/318_26_02_20_7_09_41.jpeg)
However this was slightly different in that 90% of the time it was only lagging one measurement behind not two like in the PHA scan. There were ocassions when it was 2 measurements behind but not often. So the plateau bumps are still there which i think is another issue, but some of the small "noise" definitely correlates to when it was lagging and when it "caught up"
I then did the same with a bias scan:
(https://smf.probesoftware.com/gallery/318_26_02_20_7_12_15.jpeg)
And same as the Gain scan, it was lagging every second measurement however there was no obvious effect I could see in the Bias scan?
So I think I am having two separate problems here probably. Weird call lagging from Peaksite for steps in PHA, and a separate problem with Gain electronics for my bumps in my gain scan.
Cheers
Ok yet another update. I ran a manual PHA through Peaksite as per John's suggestion, and I get exactly the same problem so I don't think its a "lagging" issue. See below for comparison of PHA acquired throuhg PfE vs manually in Peaksite.
(https://smf.probesoftware.com/gallery/318_26_02_20_9_22_42.jpeg)
Weirdness was happening in Peaksite when I ran it manually though. Every now and then I would enter a number in for the base line volts, hit enter and within a second I can see the window value changing value of its own accord! I was using 104mV and I would watch it drop 103.102,101, 100... so as soon as I hit enter after changing the window value I have to hit the "Count" button immediately otherwise it would start dropping. Once the counting starts the baseline/window voltages were "locked". This also happened on the odd occasion for the baseline voltage!
If I let the window value change of its own accord it wanted to go down to 74mV. I might run the manual scan again using that window and see what happens....to be continued
Cheers
I'm not sure what is going on here, but as per John's request, here is the test results obtained on a JEOL-8230.
Edit by John: Thanks Julien. I just wanted to confirm that the PHA issue Ben Wade and Philipp Poeml reported only concerns Cameca instruments. Your and Anette's PHA scan (link below), confirm that JEOL instruments do not suffer from this issue. That is when many PHA points are acquired using a small PHA window. Based on Ben's observations we suspect that the Cameca firmware is trying to adjust the baseline and window values as we acquire the PHA data. The problem does not not occur with the default Cameca MCA PHA method, but only when acquiring lots of small baseline increments using non MCA (traditional) PHA acquisition methods.
https://smf.probesoftware.com/index.php?topic=217.msg9066#msg9066