Ocean Optics USB4000 Spectrometer

[NimbleThink]

In working with some digital oscilloscopes I have found that LabVIEW VISA calls are much slower than using the C DLL provided by the oscilloscope manufacturer.

I have exactly replicated the C library calls in LabVIEW using the most primitive VISA or GPIB calls available, and then compared the download time for a waveform by examining timestamps using NI-Spy.

Consistently the C DLL downloads large amounts of data much faster than any call I was able to make using VISA or GPIB calls (100 ms using the DLL versus 800 ms using VISA or GPIB calls), so I don't think it is a function of LabVIEW Plug & Play, it is a function of how LabVIEW is performing VISA or GPIB calls.

Leif Kirschenbaum

[NimbleThink]

Regarding the 3.5 nm shift I also found inconsistencies with the Ocean Optics USB200 and USB4000 when I worked with them a few years ago.

You may want to check your array of wavelength values, perhaps the array is off by one index.

Another possibility is that the wavelength array indicates the start or center or end wavelength of each spectrometer bin which does not match the laser wavelength expected.

I found that the Ocean Optics LabVIEW code (circa 2008) was atrocious, and the Omnidriver DLL was written quite badly: full of bugs and errors, relied on keeping pointers and handles around in LabVIEW, no error code reporting.  In fact some of their interpolation routines either interpolated as a step function or reported zeroes for intermediate wavelengths.  I ended up writing a whole library of LabVIEW VI's to access the Omnidriver DLL with a minimum of keeping pointers/handles around, including wavelength interpolations, colorpoint calculations, xyY to RGB, CIE chromaticity diagrams, etc..  I'm glad to see that someone has circumvented the Omnidriver DLL with native VISA calls.

Leif Kirschenbaum

[James_G1]

Hello, all

I have found the source of the 20 pixel shift in the driver.  I believe the error is only with the USB4000.  The NI driver is removing the first 20 pixels of data in the read spectra vi.  It should not.

[NimbleThink]

James, good find.

However I am having some uneasiness due to a vague recollection of some esoteric little detail regarding the pixel array in the OO spectrometers, something about a portion of the array being inactive or shadowed or unused or set aside for calibration or something.  I don't have the manuals or Tech Notes for the USB2000 or USB4000 any more, however you may want to check if it is the case.

If that is the case then changing the start index may not be the whole solution: there may be a portion of the data that needs to be deleted (if that data represents the portion of the detector array which is not involved in actual measurement).

Best regards,

Leif Kirschenbaum

[James_G1]

You are correct that the spectrometers contain "optically inactive pixels" and that is why the 20 were removed, but the wavelength calibration is designed to have these pixels present.

It is not really necessary to remove the dark pixels from that data and doing so forever rids you of the ability to use them for a base line correction.  (I am working on this vi for ALL the spectrometers but it may be a little while still)

It also would not be consistent with how the other spectrometers are being treated, since they too have dark pixels but in all other cases are not being removed.

As a side not a quick Google search for USB2000+ datasheet or USB4000 datasheet will pull up the data sheets.

[Doug1974]

I made the same observation regarding the 5nm discrepancy between data acquired via the Labview interface and data acquired with the Ocean Optics Spectrasuite software.  Note: The Labview interface shifts all data ~20 pixels to the left which equates to ~5nm given ~4pixels per nanometer.

Reading the data sheet (http://www.oceanoptics.com/technical/engineering/USB4000%20OEM%20Data%20Sheet.pdf) there is a small blurb on page 8 immediately following the Pixel Description table:

In USB interface mode, Ocean Optics software displays 3648 pixels starting at pixel 1 above.

In RS232 interface mode, the USB4000 transmits out the first 3670 pixels.

The key being "USB Interface Mode" -- all pixels 1-3648 are valid.

In the "Read Spectral Waveform.vi" module, the array is being trimmed with a subset function with a constant of '20' wired to the starting index.  Changing this to '0' corrected the issue.  Using a similar light source, I produced two waveforms (one with the modified Labview function and one with the Spectrasuit software) and they are now perfectly aligned.  (See Attached spectral comparison).

I appologize if this has already been addressed -- I couldn't find it.  The Certified drivers should be updated to reflect this change.

[James_G1]

A quick note.  20 pixels is not necessarily 5 nm.  This depends on your specific spectrometer configuration, grating line density mostly.

Also to reiterate, the first 20 pixels may not provide useful optical data (they for a fact do not, they are basically inactive) but the factory wavelength calibration was created with those 20 pixels as part of the output so removing them and then applying the wavelength calculation is where this error is generated.

PS.  Nice graph

[dof1986]

Hello,

I'm trying to interface a Maya 2000 Spectrometer with LabVIEW, and avoiding buying Omnidriver.

I've installed the latest version of this driver:

http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=7833BD4A31DA1274E04400144FB7D2...

The spectrometer is detected by Windows in the Device Manager tab and it says it is working properly, and shows that this driver is installed. However when I go to MAX I can't see the device. How can I go about getting NI software to recognise the Maya and to begin collecting data from it?

Thanks,

Daniel

[Z'atari]

Make sure you have installed the driver correctly.

http://www.ni.com/devzone/idnet/inetinst.htm

[James_G1]

Im not sure where to post this but I found a minor error in the driver set.  For the NIRQeust spectrometers the query spectral baseline correction.vi has a problem in it.  In the case structure for NIRQuest, there is a swap byptes that is not working. It seems that swap bytes does not work on the string.  The same 2 byte string comes out as goes in. This causes the number to be cast incorrectly.  I think the fix is to simply replace it with a reverse string.

Anyone know where to put such things to get NI's attention?

James G