LIBS Spectrometer - Data Analysis

So, spectrums in hand, I have to find a way to see if they agree with what I believe to know about the targets.

OceanOptics' original software for their LIBS hardware is called OOILIBSplus. It is available for download from their site, but if you don't already own a copy, you will have to email them and ask if they kindly give you the installation password. This is the screen after opening:

That looks very promising. Unfortunately, it cannot open the data files that the OceanOptics OOIBase32 spectrometer software outputs - go figure....

OceanOptics retired that program and now bundles a third party app from a company called Plasus with their LIBS systems. It is called PLASUS Specline and the company is very nice in allowing the download of a demo version of their software. And, as one might expect, it supports the OOIBase32 file format. This is what that looks like for the spectrum associated with the steel block:

Since it is based on iron, I selected the elemental peaks for Fe, and played around a bit with what else was available:

This looks pretty good, as a lot of the lines seem to correspond to Fe. Unfortunately, this is a demo version and does not have the data for the common alloy elements one might expect here, such as Cr...

Furthermore, when asking Specline to show all the known lines corresponding to Fe, it turns out there are a lot of them:

Sooooo - what does this mean? I am not totally sure...but it is heartening that Specline does not identify every peak to be Fe. Also, it means that trying to do the identification manually is probably a bad idea.

I do think it would be helpful to compare that to the output of another program. Lets look at OOILIBSplus again.

It is possible to save the empty spectrum after the program has launched. That file then has contents that look like this:

OOI LIBS    Data File
Saturday    August    06    2016
Averages    1
QSwitch Delay    0.0us
Wavelength    Counts

With no actual data...

On the other hand, the OOIBase32 files look like this:

OOIBase32 Version Data File
Date: 07-30-2016, 23:48:16
User: Valued Ocean Optics Customer
Spectrometer Serial Number:
Spectrometer Channel: Master
Integration Time (msec): 100
Spectra Averaged: 1
Boxcar Smoothing: 0
Correct for Electrical Dark: Disabled
Time Normalized: Disabled
Dual-beam Reference: Disabled
Reference Channel: Master
Temperature: Not acquired
Spectrometer Type: S2000
ADC Type: ADC1000USB
Number of Pixels in File: 2048
Graph Title: 
>>>>>Begin Spectral Data<<<<<
339.80    0.000
340.18    91.000
340.56    90.000
340.94    89.000
341.32    91.000
341.70    93.000
342.08    93.000

So it seems reasonable that the developers of the software would keep the same schema to save data. And in any case the header strongly suggests two columns of wavelength and counts, respectively. There is no harm in trying, so I just copied the data into the OOILIBSplus file:

OOI LIBS    Data File
Saturday    August    06    2016
Averages    1
QSwitch Delay    0.0us
Wavelength    Counts
339.80    0.000
340.18    91.000
340.56    90.000
340.94    89.000
341.32    91.000
341.70    93.000
342.08    93.000

It turns out that that works! So I can now use OOILIBSplus to try to identify the peaks...

However, here also the identification does not seem to work. The only item in the list of most found lines that makes sense is Neodymium, perhaps, because it is in the laser rod.

Time to go back and think this through...

After some consideration, it occurs to me that the resolution of my spectrometer is only 0.37 nm per pixel, but the OceanOptics unit will do 0.1 nm FWHM or better. So, I adjusted the settings in the Specline software that matched the peaks to within 0.1 nm to look to within 0.4 nm.

Then, looking only for Fe:

That looks much better. Additionally, looking for Fe, O and C

And when enabling the lines for Ions:

This is encouraging because

- at least one peak is identified that was not before hand

- several peaks are left unidentified, even though there is a huge number of lines available to match to:

Lets enable more elements that are possibly present. H, N and Ar, because they are in the atmosphere. And Mo, S, Si and P because they are commonly found in steel:

The number of elements identified per line is strongly dependent on the resolution setting, so I should really try to get a spectrometer with higher resolution...

Still, the majority of lines do match Fe, and a number of lines are still not identified. So Specline does seem to do a passable job of ensuring that there are no false matches.

I am going to turn on all available elements and see what I get for both elemental only and ion lines.

As would be expected the result is a bit crazy. However, not all the elements are found, and that is very good!

Ok, lets compare the resolution on this spectrometer with the LIBS unit from OceanOptics a bit more carefully. To calculate the FWHM resolution of my unit I use this formula:

and there is a nice example here:

So, based on the spectrometer data my dispersion value is 0.31 nm/pixel and I have a 25 micrometer slit on that channel, so I get an optical resolution of: 0.31 nm/pixel * 4.2 pixel = 1.3 nm FWHM - less than 1/10 of the actual LIBS unit.

Also, it seems that the signal can be helped greatly by using a double pulse. I.e. shoot a second laser at the plasma plume of the first one.

Small update:

While almost all channels on my spectrometer are identical:

600 Lines Blazed at 500 nm

350 - 1000 nm

OFLV-3 Detector, L2 Lens, 25um Slit

Ocean Optics calls that grating #3:

So perhaps I could normalize the result using this curve. But even more importantly, the efficiency is pretty bad for most of the range. I would quite like to put some new gratings into these spectrometers....

Slave 5 has a 10um slit, no lens. So with the original setup, there was not enough light collected to work with. I replaced the focusing lens between the fiber and the sample with one that has a far shorter focal length. This way, I got a very small focus close to the sample and was able to get a decent signal :

The FWHM with this is 0.31 nm/pixel * 3.2 pixel = 1.0 nm. This is a large improvement, but still an order of magnitude from where I would like to be at.