Hi all,
This is a bit off the wall. We have attached an optical spectrometer to the stem of our CL camera system as a DIY approach to CL spectral analysis. Since the materials we are looking at are high CL emitters, it works surprisingly well.
We would like to attempt hyperspectral imaging. The thought is to use the Rectangular Grid feature in Automate to set the XY positions and timing while we compile the spectra into an array using our own program. Does anybody know of a way to have ProbeSoftware issue a serial port command at the beginning or end of each analysis within a grid? We would use this for triggering the spectrometer.
Bonus question: Does anybody know how to have ProbeSoftware write a text file containing X, Y, and time at the beginning or end of each analysis within the grid of spots?
All advice is appreciated. Has anybody tried this or something similar?
Cheers,
Jason
Quote from: Jason in Singapore on June 10, 2015, 04:45:05 AM
This is a bit off the wall. We have attached an optical spectrometer to the stem of our CL camera system as a DIY approach to CL spectral analysis. Since the materials we are looking at are high CL emitters, it works surprisingly well.
We would like to attempt hyperspectral imaging. The thought is to use the Rectangular Grid feature in Automate to set the XY positions and timing while we compile the spectra into an array using our own program. Does anybody know of a way to have ProbeSoftware issue a serial port command at the beginning or end of each analysis within a grid? We would use this for triggering the spectrometer.
Bonus question: Does anybody know how to have ProbeSoftware write a text file containing X, Y, and time at the beginning or end of each analysis within the grid of spots?
All advice is appreciated. Has anybody tried this or something similar?
Cheers,
Jason
I love this kind of DIY stuff! Basically I think you want to acquire a CL spectra along with the WDS data in PFE, just as we currently do for EDS spectra... correct?
I'd prefer to implement an interface to a commercial CL system such as Gatan or even a defacto standard such as an Ocean Optics visible light spectrometer. Is that what you are using? I am not aware of what kind (if any) of an API that Ocean Optics makes available.
A vendor API would be much preferred to re-inventing the wheel as they say.
john
The spectrometer is a Newport but next week we want to try the same thing with an Ocean Optics spectrometer. Our plan was to bypass the spectrometer software and use our homebrew software "IV Spectrum", which is written in Python.
Our thought was to use Probe Software for stage control while IV Spectrum sorts out the spectral data and produces images of designated wavelength ranges. What we need is a triggering mechanism ... ideally 2-way triggering. There are a few options. The "start" trigger could either be ProbeSoftware issuing a serial port command, or else ProbeSoftware appending the X,Y position to a designated text file. The reverse trigger is not essential, but it would allow the pace to be set by IV Spectrum.
Quote from: Jason in Singapore on June 12, 2015, 01:53:23 AM
The spectrometer is a Newport but next week we want to try the same thing with an Ocean Optics spectrometer. Our plan was to bypass the spectrometer software and use our homebrew software "IV Spectrum", which is written in Python.
Our thought was to use Probe Software for stage control while IV Spectrum sorts out the spectral data and produces images of designated wavelength ranges. What we need is a triggering mechanism ... ideally 2-way triggering. There are a few options. The "start" trigger could either be ProbeSoftware issuing a serial port command, or else ProbeSoftware appending the X,Y position to a designated text file. The reverse trigger is not essential, but it would allow the pace to be set by IV Spectrum.
Hi Jason,
I don't mind adding a serial port trigger to PFE for initiating a CL spectra acquisition, but then what? I'd rather have PFE also store the CL intensity data in the PFE database automatically just as it does for EDS spectra currently. I hate external files scattered all over the hard drive!
In your "homebrew" software could you provide an API that I could call from PFE to start, stop, get the status of and retrieve the CL spectra intensity acquisition? It's simpler than acquisition of EDS spectra because I wouldn't need to obtain net intensities for quantification! Can you make your python code into a DLL that I could call from PFE? I think Philippe Pinard told me that this is possible. Here is a possible API:
Function CL_Init
Open a connection to the CL interface
Function CL_StartCL
Start the CL spectrum acquisition
Function CL_GetStatus
Returns true if acquisition in progress, false if not.
Function CL_StopCL
Stop or cancel the current spectrum acquisition
Function CL_GetSpectrum(npoints&, narray&())
Get an array of CL intensities from the current acquisition. Npoints& is the number of array elements returned in narray&().
Function CL_Close
Close the CL interface
We could add an Export All CL Spectra button too. What do you think about this possibility?
john
Hi John, thanks for approving my request.
Ocean optics is providing library for their spectrometer for free.
It is called seabreeze http://oceanoptics.com/product/seabreeze/
We are using basically the same library for our python scripts (we called 'IV SPectrum' for Current-voltage-spectrum acquisition).
It will be great if this thing can be integrated to PFE !!.
Some equivalent functions copied from seabreeze docs:
Function CL_Init
Open a connection to the CL interface
int probeDevices ()
int addRS232DeviceLocation (char *deviceTypeName, char *deviceBusPath, unsigned int baud)
int getNumberOfDeviceIDs ()
int getDeviceIDs (long *ids, unsigned long maxLength)
int openDevice (long id, int *errorCode)
Function CL_StartCL
Start the CL spectrum acquisition
int spectrometerGetUnformattedSpectrumLength (long deviceID, long featureID, int *errorCode)
int spectrometerGetUnformattedSpectrum (long deviceID, long featureID, int *errorCode, unsigned char *buffer, int bufferLength)
int spectrometerGetFormattedSpectrumLength (long deviceID, long featureID, int *errorCode)
int spectrometerGetFormattedSpectrum (long deviceID, long featureID, int *errorCode, double *buffer, int bufferLength)
int spectrometerGetWavelengths (long deviceID, long featureID, int *errorCode, double *wavelengths, int length)
Function CL_GetStatus
Returns true if acquisition in progress, false if not.
Function CL_StopCL
Stop or cancel the current spectrum acquisition
Function CL_GetSpectrum(npoints&, narray&())
Get an array of CL intensities from the current acquisition. Npoints& is the number of array elements returned in narray&().
Function CL_Close
Close the CL interface
void closeDevice (long id, int *errorCode)
-riko-
Quote from: RIKO on June 14, 2015, 11:04:41 AM
Hi John, thanks for approving my request.
Ocean optics is providing library for their spectrometer for free.
It is called seabreeze http://oceanoptics.com/product/seabreeze/
We are using basically the same library for our python scripts (we called 'IV SPectrum' for Current-voltage-spectrum acquisition).
It will be great if this thing can be integrated to PFE !!.
Some equivalent functions copied from seabreeze docs:
Function CL_Init
Open a connection to the CL interface
int probeDevices ()
int addRS232DeviceLocation (char *deviceTypeName, char *deviceBusPath, unsigned int baud)
int getNumberOfDeviceIDs ()
int getDeviceIDs (long *ids, unsigned long maxLength)
int openDevice (long id, int *errorCode)
Function CL_StartCL
Start the CL spectrum acquisition
int spectrometerGetUnformattedSpectrumLength (long deviceID, long featureID, int *errorCode)
int spectrometerGetUnformattedSpectrum (long deviceID, long featureID, int *errorCode, unsigned char *buffer, int bufferLength)
int spectrometerGetFormattedSpectrumLength (long deviceID, long featureID, int *errorCode)
int spectrometerGetFormattedSpectrum (long deviceID, long featureID, int *errorCode, double *buffer, int bufferLength)
int spectrometerGetWavelengths (long deviceID, long featureID, int *errorCode, double *wavelengths, int length)
Function CL_GetStatus
Returns true if acquisition in progress, false if not.
Function CL_StopCL
Stop or cancel the current spectrum acquisition
Function CL_GetSpectrum(npoints&, narray&())
Get an array of CL intensities from the current acquisition. Npoints& is the number of array elements returned in narray&().
Function CL_Close
Close the CL interface
void closeDevice (long id, int *errorCode)
-riko-
So have you tested the interface at all?
I see these functions:
int spectrometerGetUnformattedSpectrumLength (long deviceID, long featureID, int *errorCode)
int spectrometerGetUnformattedSpectrum (long deviceID, long featureID, int *errorCode, unsigned char *buffer, int bufferLength)
int spectrometerGetFormattedSpectrumLength (long deviceID, long featureID, int *errorCode)
int spectrometerGetFormattedSpectrum (long deviceID, long featureID, int *errorCode, double *buffer, int bufferLength)
int spectrometerGetWavelengths (long deviceID, long featureID, int *errorCode, double *wavelengths, int length)
but are they called to start or return the data?
Maybe post the document for us?
john
Some other considerations:
How do you get the CL signal out of the instrument? Are you utilizing the EPMA light optics or using an insertable parabolic mirror? In other words can the CL spectra be acquired at the same time as the WDS elements, or does it have to be before or afterwards?
There is also a discussion on future integration of EDS (and CL) spectrum imaging using the stage/beam pixel sync pulses from the instrument mapping generator:
http://smf.probesoftware.com/index.php?topic=400.msg2174#msg2174
Thermo is already implementing this new integrated EDS-WDS mapping method on John Fournelle's new Cameca SXFive instrument. But having this for point analyses is a good start... we already acquire a full EDS spectra for each point analysis from Bruker and Thermo detectors.
Unfortunatelly we had not tried seabreeze itself.
I thougth it should be easier than creating a new api from our python script, and probably more robust than our home-made driver.
Quote
int spectrometerGetUnformattedSpectrumLength (long deviceID, long featureID, int *errorCode) ....
Those function should be for return data, as I can see from the example code (attached).
The official docs for this driver is pretty minimal, but discern able from the example.
In our script, we skip the seabreeze and use python driver from Nuria Pujol Vilanova.
Downloadable from
Quote
http://www.google.com.sg/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CB0QFjAAahUKEwjjksvprJHGAhVNfLwKHWEpAJA&url=http%3A%2F%2Fforja.rediris.es%2Ffrs%2Fdownload.php%2F682%2FTestingUSB4000.py&ei=DpZ-VePTLs348QXh0oCACQ&usg=AFQjCNGfAsv4t2bIyydm3NFZl35GaViQjQ
And attached are our stripped down versions of the same driver (oospec.py & oospec.pyc).
The problem next is, how can we interface with c++. There seems to either call or embed python from/to c++. I attached the docs print out as well https://docs.python.org/2/extending/embedding.html.
We obtained the CL signal from a small window provided by JEOL (as seen from picture posted by Jason, with me in the frame). There use to be metal stem on that window, with attached photo multiplier and a CCD. There are seems to be lens system in it. The CL collected at the same time as WDS and EDS.
Looking at the EDS spectrum imaging, looks like CL will be much simpler.
Hi Rico,
I like that you utilized the secondary optical/EDS port so you can acquire CL at the same time as EDS and WDS.
Yes, I agree using the "seabreeze" API should be a better solution than a "hacked" API. ;)
I'm sort of gearing up for the M&M conference this summer (a few other irons in the fire as they say!), but I think I should be able to create a CL acquisition interface for point analyses in PFE later this summer using your link:
http://oceanoptics.com/product/seabreeze/
Creating CL spectrum imaging capability (a la xCLent) will be more difficult as we would need to synchronize with the JEOL stage/beam mapping pixel sync signals as described here (for EDS):
http://smf.probesoftware.com/index.php?topic=400.msg2174#msg2174
We are currently implementing this for a Thermo EDS on John Fournelle's Cameca SXFive instrument in Wisconsin...
Rico,
Can you provide more details on the CL optics as shown here:
(https://smf.probesoftware.com/oldpics/i61.tinypic.com/35lujcg.jpg)
Do you know anything about the geometric efficiency? How do you think it compares to collecting light through the JEOL light optics (a la xCLent) or compared to a parabolic mirror over the sample which I believe is the most efficient?
After a quick look at the open source SeaBreeze driver, I wonder if their standard OmniDriver seen here:
http://oceanoptics.com/product/omnidriver/
is a better way to proceed. The only caveat I see is that the OmniDriver is not free, but it appears to be well supported which is often a good way to go.
If I implement this CL interface in PFE, would you be willing to provide a copy of the OmniDriver CL driver for me to test the interface with?
Edit by John: here is question I would very much enjoy hearing from CL experts on: how does the optical collection efficiency (numerical aperture?) numbers compare for these three methods of CL spectrum collection to a fiber optic:
1. Gatan/Horiba style parabolic mirror
2. XCLent style through the instrument light optics
3. Transfer lens style using secondary EDS port as shown in the above photograph.
Jason and Rico: please see this post:
http://smf.probesoftware.com/index.php?topic=529.msg2913#msg2913
I've implemented all the code for CL spectrum acquisition in PFE except for the hardware specifics. Now we just need someone to specify a CL hardware API for me to connect! Ocean Optics, Newport, Gatan, etc.- you all tell me what you need!
john
Hi John,
Those looks cool
As for your questions, I have no idea what is our setup efficiency. I guess it is pretty low. For one, we are using refurbished spectrometer (Newport 100 OSM). It took about 5s to collect reasonable signal from InGaN sample. Jeol's exClent system is definitely better, but probably much more costly than our setup. Next, we want to try Ocean Optics USB4000, to see if we can capture the spectrum better (as soon as the machine available).
As for the Omnidriver. I will have to get back to you on this. I have to make sure the licensing does not conflict with the lab and my institution regulation and policy.
Quote from: RIKO on June 21, 2015, 06:50:04 PM
As for the Omnidriver. I will have to get back to you on this. I have to make sure the licensing does not conflict with the lab and my institution regulation and policy.
No worries. If you are going to interface to the Ocean Optics box I'll buy my own copy of the driver. I know someone that has an Ocean Optics spectrometer I can test.
It would be interesting to get some absolute readings on a few standard fluorescent materials... I'm sure this has been done, and although the sensitivity will be a function of the spectral characteristics, even a panchromatic measurement will be useful for comparing relative optical efficiency of the various collection devices.
Quote from: RIKO on June 21, 2015, 06:50:04 PM
As for the Omnidriver. I will have to get back to you on this. I have to make sure the licensing does not conflict with the lab and my institution regulation and policy.
Hi Rico,
OK, I called Ocean Optics and they will sell us a full driver with optical spectrum processing for ~600$, so I'll just have Probe Software purchase it- and yes, the driver is fully re-distributable for end-users so we will provide that along with the CL spectrum acquisition capability.
If you guys would like to beta-test the CL acquisition feature for us, we can provide the PFE CL acquisition feature and driver to you for free- everyone else will have to pay a nominal cost! :P
Can you provide us with any information on the collection optics hardware circled in the picture in this post:
http://smf.probesoftware.com/index.php?topic=517.msg2883#msg2883
For example, who makes it, how much is it and how well does it seem to work (the geometric efficiency question)?
Edit by John: I just received the Ocean Optics driver. Will start implementing it in PFE ASAP. Any one willing to beta test the acquisition? I don't have a fiber optic connection on my Sx100 (yet).
Though Paul Edwards said he was able to attach the CL spectrometer directly to the Sx100 using a small lens optics.
For reference a parabolic mirror, for example like the ones Gatan uses in many of their systems is roughly 80-85% efficient.
Ed
Quote from: qEd on June 24, 2015, 12:56:25 PM
For reference a parabolic mirror, for example like the ones Gatan uses in many of their systems is roughly 80-85% efficient.
Ed
Hi Ed,
That is just the mirror geometric efficiency I'm assuming?
I can't wait to make some absolute measurements on my two CL systems! ;D
john
Paul Edwards at StrathClyde, who has added a CL spectrometer to his Sx100 in place of the PMT, writes:
Yes, I use the Cameca optics and the PMT port. However, I don't use a fibre at all, but directly focus the light to the entrance slit of a small (0.125 m) spectrograph which is bolted to that port. I use a simple achromatic doublet lens to focus the light. I don't remember the focal length of the lens I use, but it was chosen to match the f-number of the spectrograph (f/3.7, or NA0.135). You will need one which matches the acceptance cone of your fibre, which is probably NA0.22. If I remember right, the rays are diverging by the time they get to the port, as the image plane lies some distance into the optics assembly.
On thing to bear in mind when choosing a fibre is that the diameter will determine the field of view of the CL. In my case, the image formed at the detector is magnified by around ×3, so when I use a 25µm spectrometer slit I have a field of view of around 8µm. Of course this is not a problem when acquiring point spectra or stage maps. I think in your case the the total magnification should be nearer 2×, as your fibre will have a larger acceptance angle than my spectrograph.
I focus the light to an image at the entrance of the spectrograph, whereas you would focus it to an image at the entrance of the fibre. I just called it "directly coupled" as I don't go via a fibre. In either case you are collecting a lot more light than if you were to just stick the end of the fibre into the port. I avoided a fibre because this would have lost some of the light, but I can see how the flexibility (literally) of a fibre-based system would appeal.
It just occurred to me that we'll probably want to export both the dark spectrum and signal spectrum to the EMSA format file, so that would require a 2 column EMSA format (which does seem to be supported in the description I have).
However, I haven't seen any examples of a 2 column EMSA format file. Can any one send me a 2 column EMSA format file, ideally one with CL intensity data containing both the dark and signal spectra?
Also, one more question: what Ocean Optics spectrometer should people be buying for use on an EPMA? I have a Ocean Optics USB 4000 which cost something around $3-4K I think. Here is the info on it:
http://oceanoptics.com/product/usb4000-custom/
Of course I guess it might matter whether one will be connecting directly to the instrument light optics as Paul Edwards does on his Sx100, or whether one wants to connect via fiber...
I am unaware of CL spectra collected in MSA format. X.DM3 and X.epmx are more common formats from Gatan and XCLent. Regarding your need for a two column MSA file, examine your Thermo NSS 2.X/3.X spectrum files as they are native MSA (not EMSA BTW).
Quote from: qEd on July 06, 2015, 08:08:40 AM
I am unaware of CL spectra collected in MSA format. X.DM3 and X.epmx are more common formats from Gatan and XCLent. Regarding your need for a two column MSA file, examine your Thermo NSS 2.X/3.X spectrum files as they are native MSA (not EMSA BTW).
Hi Ed,
Thanks. I'm just noting that in the EMSA specification the EMSA file format is intended for CL spectra also.
The Thermo EDS spectra files are EMSA (they have a .EMSA file extension!), but yes they have been *extended* by Thermo with additional "custom" parameters as is allowed in the EMSA format specification using a "##" line specifier. Also these Thermo EMSA files are only one column... here is the first few lines from a Thermo EDS file:
#FORMAT : EMSA/MAS Spectral Data File
#VERSION : 1.0
#TITLE : Moacyr(1)
#DATE : 09-SEP-2013
#TIME : 14:26:29
#OWNER :
#NPOINTS : 2048
#NCOLUMNS : 1
#XUNITS : keV
#YUNITS : Intensity
So I would still like to get my hands on a CL two column format if possible for my own enlightenment. Can the Gatan or xCLent apps export an EMSA format file that you can send me? Thanks!
I can check what Gatan export options are later in the week. I do not have an XCLent system. You're right the file suffix is outdated! Below is a 5 column Y only example file. Does that help?
From the original spec EMSAMASFF (EMSA MAS file format):
Hi Ed,
Better if you would just attach the file to this post below so the characters aren't "interpreted" by the forum software!
john
Here you go, I saved a multicolumn .MSA file using Bruker software.
Quote from: qEd on July 07, 2015, 07:59:51 AM
Here you go, I saved a multicolumn .MSA file using Bruker software.
Thanks Ed.
If do you find that Gatan does output an EMSA file (EMSA or MSA apparently it's the same format), please send that CL spectrum data file also.
Thanks again.
Hi John,
I am sorry for my long silent.
Quote from: John Donovan on June 22, 2015, 06:50:08 PM
If you guys would like to beta-test the CL acquisition feature for us, we can provide the PFE CL acquisition feature and driver to you for free- everyone else will have to pay a nominal cost! :P
I've mentioned this briefly to Jason (the JX1 Master) before his trip, I think he will allow me to beta-test CL feature :p.
Quote
Can you provide us with any information on the collection optics hardware circled in the picture in this post:
http://smf.probesoftware.com/index.php?topic=517.msg2883#msg2883
For example, who makes it, how much is it and how well does it seem to work (the geometric efficiency question)?
The stem made by JEOL. I think it came as a package with the system. The docs doesn't give much details (attached), just " a specially made relay lens for CL". Since it is was made for CL, it should worked pretty well.
-riko-
Quote from: RIKO on August 21, 2015, 11:04:57 AM
Quote
Can you provide us with any information on the collection optics hardware circled in the picture in this post:
http://smf.probesoftware.com/index.php?topic=517.msg2883#msg2883
For example, who makes it, how much is it and how well does it seem to work (the geometric efficiency question)?
The stem made by JEOL. I think it came as a package with the system. The docs doesn't give much details (attached), just " a specially made relay lens for CL". Since it is was made for CL, it should worked pretty well.
Ok, cool. So do you have an Ocean Optics spectrometer that you can connect to it now?
john
Quote
Ok, cool. So do you have an Ocean Optics spectrometer that you can connect to it now?
john
Yes, I have Ocean Optics USB4000 configured for UV-VIS (180-850nm) at hand now.
Extra : I may have another one that cover 350nm-1100 nm soon, but may not from ocean optics.
-riko-
Quote from: RIKO on August 21, 2015, 11:22:24 AM
Quote
Ok, cool. So do you have an Ocean Optics spectrometer that you can connect to it now?
john
Yes, I have Ocean Optics USB4000 configured for UV-VIS (180-850nm) at hand now.
Extra : I may have another one that cover 350nm-1100 nm soon, but may not from ocean optics.
-riko-
Hi Riko,
Ok, very good.
I will get back to you. Ocean Optics is fixing a problem I found with their driver, so as soon as they send me a fixed driver I will get that out to you.
john
Hi John,
As mentioned before, we just obtained a 2nd spectrometer. It is Avantes AvaSpec-3648. This time it come with the DLL and should be able to supply it to you. Let me know if you are interested.
Regards,
Riko
Quote from: RIKO on November 01, 2015, 09:32:10 PM
Hi John,
As mentioned before, we just obtained a 2nd spectrometer. It is Avantes AvaSpec-3648. This time it come with the DLL and should be able to supply it to you. Let me know if you are interested.
Regards,
Riko
Hi Riko,
I will have to check that the DLL is a royalty free distribution.
By the way, I now have the Ocean Optics "omnidriver" DLL and will also be implementing that soon for sure, as it is a royalty free distribution.
john
Hi Riko,
I have successfully interfaced an Ocean Optics spectrometer to Probe for EPMA.
It automatically acquires a dark spectrum (before the cup comes out), and then acquires a CL spectrum during the WDS/EDS acquisition as shown here:
(https://smf.probesoftware.com/oldpics/i67.tinypic.com/3492mh3.jpg)
The extra space at the top of the acquisition time display is because the WDS data is for 30 seconds, but the CL acquisition is specified at 40 secs. See here for more details:
http://smf.probesoftware.com/index.php?topic=42.msg3855#msg3855
The acquired CL spectra can be displayed and/or exported in EMSA format with both the dark spectrum and normal CL intensity data for further processing and reporting.
Hi John,
This is really cool !! I wonder if your offer is still stand, that we can beta test it for free?
I should be able to get a time slot for Jason's JX1 system in Feb 2016.
Regards,
Riko
Quote from: RIKO on December 21, 2015, 10:47:45 PM
Hi John,
This is really cool !! I wonder if your offer is still stand, that we can beta test it for free?
I should be able to get a time slot for Jason's JX1 system in Feb 2016.
Regards,
Riko
Hi Riko,
Sure. You can beta test for free- that's my usual deal! ;D
However, do you have an Ocean Optics spectrometer you can use for this test?
You'll also want to make sure Jason is updated to the latest v. 11.x of Probe for EPMA.
john
Hi John,
Great !!
I will have the spectrometer ready by Feb.
I will still need to check the software versions.
Just in case it is not v11.x, what should I do (read: Jason will need to do ...).
Am right to assume v11.x is ready to interface with OceanOptics spectrometer?
-riko-
Quote from: RIKO on December 22, 2015, 10:42:37 AM
Great !!
I will have the spectrometer ready by Feb.
I will still need to check the software versions.
Just in case it is not v11.x, what should I do (read: Jason will need to do ...).
Am right to assume v11.x is ready to interface with OceanOptics spectrometer?
See here for updating:
http://smf.probesoftware.com/index.php?topic=642.0
Yes, v. 11.1.8 is ready to go. I will send you the Ocean Optics driver when you are ready to test.
john
Hi John
I tried the OO-USB4000 with v11.x.
The "CL Acquisition" group is greyed (see attached picture)
-riko-
Quote from: RIKO on March 16, 2016, 01:42:09 AM
Hi John
I tried the OO-USB4000 with v11.x.
The "CL Acquisition" group is greyed (see attached picture)
-riko-
Did you "turn on" the CL interface in the probewin.ini file?
Thanks John,
I found the following lines from probewin.ini
"CLSpectraInterfacePresent=0
CLSpectraInterfaceType=0"
change it to
"CLSpectraInterfacePresent=1
CLSpectraInterfaceType=0"
It brings the groups out of the grey. I am trying a test run now.
Quote from: RIKO on March 16, 2016, 08:40:21 PM
Thanks John,
I found the following lines from probewin.ini
"CLSpectraInterfacePresent=0
CLSpectraInterfaceType=0"
change it to
CLSpectraInterfacePresent=1
CLSpectraInterfaceType=0"
It brings the groups out of the grey. I am trying a test run now.
Hi Riko,
CLSpectraInterfacePresent=1
is fine, but
CLSpectraInterfaceType=0
is demo mode. Check the help file for the Ocean Optics interface value for this keyword.
john
A quick search of the Help will reveal:
QuoteCLSpectraInterfacePresent=0
CLSpectraInterfaceType=0
CLInterfaceInsertRetractPresent=0
These keywords are to specify the CL spectrum acqusition interface for Probe for EPMA. To indicate a CL interface is present, change CLSpectraInterfacePresent to any non-zero number. The following CL interfaces will be supported:
0 = Demo CL
1 = Ocean Optics (OmniDrive driver)
2 = Gatan
3 = Newport
4 = Unspecified
Hi John,
Good news and bad news:
The good news is probesoftware interface with Ocean-optics USB4000 without problems. It worked both for single point measurement and automated measurement (polygon).
The bad news is, the unit is not sensitive enough. Even though I can see the light with eyes (for brief moments) and JEOL's CCD camera, USB4000 wasn't detecting anything. Picture1.png is the test results. The unit's entrance slit is maybe too small.
Another thing, my other spectrometer i.e Newport-OSM100 and Avantes-Avaspec 3648 seems able to pickup the signal (see Picture2).
The Newport-OSM100 doesn't need a special driver, it can be controlled from serial port.
-riko-
Quote from: RIKO on March 21, 2016, 01:44:23 AM
Hi John,
Good news and bad news:
The good news is probesoftware interface with Ocean-optics USB4000 without problems. It worked both for single point measurement and automated measurement (polygon).
The bad news is, the unit is not sensitive enough. Even though I can see the light with eyes (for brief moments) and JEOL's CCD camera, USB4000 wasn't detecting anything. Picture1.png is the test results. The unit's entrance slit is maybe too small.
Another thing, my other spectrometer i.e Newport-OSM100 and Avantes-Avaspec 3648 seems able to pickup the signal (see Picture2).
The Newport-OSM100 doesn't need a special driver, it can be controlled from serial port.
-riko-
Hi Riko,
Happy to hear the PFE interface works.
Maybe you need to improve the optical coupling? The USB 4000 works just fine on my Quanta SEM. I know that the ExCLent system also uses an Ocean Optics spectrometer, though not sure what model they use. Maybe someone on the forum can check the model number for us?
Do you have an engineer there you can consult? Perhaps you should contact Ocean Optics?
What comms interface does the Avantes have? Does the Newport spectrometer offer an API at all? I really don't want to parse out a serial stream! Also I'm totally swamped for the next few weeks.
john
Quote from: RIKO on March 21, 2016, 01:44:23 AM
The bad news is, the unit is not sensitive enough. Even though I can see the light with eyes (for brief moments) and JEOL's CCD camera, USB4000 wasn't detecting anything. Picture1.png is the test results. The unit's entrance slit is maybe too small.
I note that the xCLent system seems to use the Ocean Optics QE65000 spectrometer. Maybe this is a more sensitive spectrometer?
I've attached the data sheet below.
Hi John,
Yes I've been in contact with OO representative here, I'll update you again what their recommendation.
Second, I've manage to source Ocean Optics QE65000 spectrometer from a friend here. I should be able to test it out next week (pending for the probe's slot).
Third, the Avantes use USB interface, and they provided dll for it. I am checking if it is distributable. Unfortunately, the Newport spectrometer does not provide any sort of dll, so we are stuck to serial port.
-Riko
The data sheet for the Ocean Optics USB 4000 is attached below.
john
I chatted a bit with a guy from Ocean Optics and he thinks it could be an issue with the way the USB 4000 unit is configured. For example the entrance slit.
I asked him to compare the USB 4000 (now called the FLAME) and the QE 65000 (now called the QE Pro), and he said the main difference was the thermal electric cooling and the use of a back thinned CCD on the QE Pro. This difference is also reflected in the price difference as a well. The USB 4000 is about $4000 US and the QE 65000 is around $13000 US.
However, he also said that using short interval accumulations (say, 0.5 seconds or so, which is how I coded the interface), that even though the P/B for the cheaper unit is around 250:1 and the more expensive one is 1000:1, the two units will produce comparable results during long accumulations. Some experimentation is of course worth doing.
So basically please try running the USB 4000 for 100 seconds or so and you should see the CL spectrum improve as the data is accumulated.
Please chime in as I am just beginning to learn this stuff. In my discussions with another optical engineer there seem to be two or three source of noise in a CL spectrometer:
1. Incoherent noise- simply random thermal noise- analogous to the x-ray continuum. Integrating over time will improve the P/B of the signal.
2. Coherent noise- noise artifacts from the detector/electronics which create a non-continuous background and must be removed using the dark spectrum. Ideally the dark spectrum and light spectrum should be acquired with the same acquisition time.
3. Not sure about this, but there may be a third type of noise which increases with integration time and the active operation of the detector itself? Hence the instruction from the vendor to utilize short integrations and average or sum these interval spectra so the detector has time to "re-set" in between...
Can someone with more knowledge on light spectroscopy please add their expertise?
John,
Update, I got the probe time to try the QE-Pro, the software able to detect it, and detect the emission spectrum.
Instead of using a longer count time, I found averaging -average of multiple short period acquisition - is better to improve the signal to noise ratio.
My problem now, how do I export the CL spectrum out from the db?
Quote from: RIKO on April 20, 2016, 09:46:55 PM
John,
Update, I got the probe time to try the QE-Pro, the software able to detect it, and detect the emission spectrum.
Instead of using a longer count time, I found averaging -average of multiple short period acquisition - is better to improve the signal to noise ratio.
My problem now, how do I export the CL spectrum out from the db?
Hi Riko,
Awesome. What exactly did you do to acquire the best spectra?
From the Run menu use the CL display menu and use the EMSA format export- I don't have an OEM export method implemented at the moment.
john
(https://smf.probesoftware.com/gallery/1_20_04_16_10_17_39.png)
Hi John,
Got it. Now I need to figure out how to read emsa format.
Am I correct to say that the first column (after keyword #spectrum) is the wavelength, and the second one is the intensity?
If yes, the number seems to be too large. Should they multiply by some factor?
To get a clean signal, I did the following steps manually:
1. Get the dark spectra with 500ms integration time, and
2. Repeat (1) four times (or as necessary), save them separately.
3. Average the dark spectra
4. Get the CL spectra with 500ms integration time (should be the same as dark ref)
6. Subtract the CL spectra with the dark spectra.
6. Repeat (3) and (4) four times
7. Average of all four (CL minus dark) is the final spectra.
Quote from: RIKO on April 21, 2016, 01:49:05 AM
Hi John,
Got it. Now I need to figure out how to read emsa format.
Am I correct to say that the first column (after keyword #spectrum) is the wavelength, and the second one is the intensity?
If yes, the number seems to be too large. Should they multiply by some factor?
To get a clean signal, I did the following steps manually:
1. Get the dark spectra with 500ms integration time, and
2. Repeat (1) four times (or as necessary), save them separately.
3. Average the dark spectra
4. Get the CL spectra with 500ms integration time (should be the same as dark ref)
6. Subtract the CL spectra with the dark spectra.
6. Repeat (3) and (4) four times
7. Average of all four (CL minus dark) is the final spectra.
The first column in the dark spectrum intensities and the second column is the light spectrum intensities.
The thing is I'm surprised that you need to average them manually because the way I acquire them is by summing a number of short integration times.
For example, let's say you specify 10 seconds for the CL acquisition time. The software divides that into intervals based on the RealTimeInterval specified in your Probewin.ini file which is usually around 400 milliseconds or so. It then adds those 400 ms integrations together for the total spectra.
So summing or averaging fractional second integrations, one should get the same results I would think!
Quote from: John Donovan on April 21, 2016, 08:16:14 AM
For example, let's say you specify 10 seconds for the CL acquisition time. The software divides that into intervals based on the RealTimeInterval specified in your Probewin.ini file which is usually around 400 milliseconds or so. It then adds those 400 ms integrations together for the total spectra.
So summing or averaging fractional second integrations, one should get the same results I would think!
John,
I think there are small difference between those two methods. On my method, the the random noise is cancelling each other, while your implementation seem to be not.
On my methods, I've subtracted the light spectrum intensities with the dark references before summing it up. In this way, I will end up with some pixels to have positive and some negative value. This is useful to remove some random noise, particularly for some non-emitted wavelengths. Averaging those positive and negative value should give me a zero average. I've also make sure to take the dark ref with the same acquisition time with the light spectrum to get the same noise characteristic for both.
On the other hand, on your implementation, it seem that you are summing all the short acquisition. Since all the pixels are having a positive value, we will end up accumulate the random noise if we just simply sum them up.
Quote from: RIKO on April 21, 2016, 10:21:43 PM
Quote from: John Donovan on April 21, 2016, 08:16:14 AM
For example, let's say you specify 10 seconds for the CL acquisition time. The software divides that into intervals based on the RealTimeInterval specified in your Probewin.ini file which is usually around 400 milliseconds or so. It then adds those 400 ms integrations together for the total spectra.
So summing or averaging fractional second integrations, one should get the same results I would think!
John,
I think there are small difference between those two methods. On my method, the the random noise is cancelling each other, while your implementation seem to be not.
On my methods, I've subtracted the light spectrum intensities with the dark references before summing it up. In this way, I will end up with some pixels to have positive and some negative value. This is useful to remove some random noise, particularly for some non-emitted wavelengths. Averaging those positive and negative value should give me a zero average. I've also make sure to take the dark ref with the same acquisition time with the light spectrum to get the same noise characteristic for both.
On the other hand, on your implementation, it seem that you are summing all the short acquisition. Since all the pixels are having a positive value, we will end up accumulate the random noise if we just simply sum them up.
Hi Riko,
I don't quite get why your method of performing the net intensity subtraction for each integration would provide better data than performing the net intensity subtraction after summing them. Mathematically they are exactly equivalent...
Unless there is some non-linearity with the spectromotor that changes with each sub second interval acquisition?
But still I'd like to try and figure out how to make your net (light - dark) method an option in my software. The problem is, I want to keep both the dark and the light spectra stored separately, not just the net intensities. Storing the dark and light spectra for each sub second interval would be an excessively large amount of data. Also doing a light - dark net subtraction would require inserting the faraday cup for each integration! We don't want to interrupt the WDS/EDS acquisition!
Maybe I could just add a third storage array for the net spectra. That way I could perform a net subtraction for each sub second acquisition and store that as an accumulation, instead of calculating it on the fly after all acquisitions are complete... I would have to add it as a third column in the EMSA file.
I guess I don't quite understand why your net method would work better. Random noise should still average out over time. Can you provide some examples here of the two methods compared?
john
John,
Yes they should be the same. But just to be sure, when I set the count time set at 40 sec and "dark fraction time" to 0.5, does that means it will use 20 sec for the dark ref, and 20 sec for light spectrum? If that is the case, then you are right, both method should be the same.
Another thing on the emsa file. The first pixel, the dark ref is larger than the light spectrum. Don't you think that is kind of odd?
Quote from: RIKO on April 22, 2016, 09:20:17 AM
Yes they should be the same. But just to be sure, when I set the count time set at 40 sec and "dark fraction time" to 0.5, does that means it will use 20 sec for the dark ref, and 20 sec for light spectrum? If that is the case, then you are right, both method should be the same.
Hi Riko,
No, the dark fraction time only applies to the dark spectrum acquisition. So if you set the count time to 40 and the dark fraction time to 0.5, it will acquire the dark spectrum for 20 seconds and the light spectrum for 40 seconds.
I did this because I assume some people won't care too much about the dark spectrum and so would want a shorter time spent on the dark spectrum.
Quote from: RIKO on April 22, 2016, 09:20:17 AM
Another thing on the emsa file. The first pixel, the dark ref is larger than the light spectrum. Don't you think that is kind of odd?
I had it backwards. The light spectrum is the first column, the dark spectrum is the second column. Sorry.
john