python-seabreeze icon indicating copy to clipboard operation
python-seabreeze copied to clipboard

Flame-S spectrometer readout timing issues

Open ap-- opened this issue 3 years ago • 2 comments

This issue is currently for the Flame-S, but might be true for many other spectrometers.

spectrometer and system information

model: Flame-S (confirmed) supposed to be the same for USB-2000PLUS

TODOs

  • [ ] test with USB2000+
  • [ ] provide a test script to create the timing plot

Description Timing Issue (from @waldowda)

Timing of data acquisition. Previously, I measured the average time to acquire a spectrum as a function of integration time and at about 1600 microseconds there is a jump down in acquisition time. Even though I would like that to be accurate I suspect it is an issue in that py-seabreeze might be reporting the spectrum before it is read out of the CCD. Here is what I found as previously reported. In this case, I am triggering in trigger mode 0 (free running). This was acquired on a Mac but it is very similar on a win10 box.

89332522-62b15680-d648-11ea-9d33-412263a45bc2

And I suspect there is some sort of process prioritization that may be computer dependent that adds an approximately constant call time to the loop so the time per scan goes down... I think the main question is why the change in behavior at 1600 µs for integration time?

89332572-765cbd00-d648-11ea-8013-d822198914c0

I have seen this from both win10 and macOS.

The External triggering options firmware3.0 and above PDF file, it has the following timing diagram which I am not sure it the timing would apply to a free running spectrometer but it might providing some insight:

89332654-9be9c680-d648-11ea-8aae-bcab5fb93012

The reason I am doing this is to use edge triggering to sync timing with a Gamry potentiostat which I can set to have an output pulse at each data point and then I turn off edge triggering and acquire 'X' spectra to average then turn on edge triggering again and wait for the next pulse.

I am wondering if the spectrometer will return values for the spectrum even before a new one is acquired.

Notes:

It's very much possible that there's nothing that can be done from the python side, and this is just a hardware issue.

ap-- avatar Aug 18 '20 06:08 ap--

For what it is worth... here is roughly the code I used above though initially I did this more manually.

#
# Timing Test 20200818
# Dean Waldow, [email protected]
#

import numpy as np
import time
import matplotlib.pyplot as plt

# explicitly request pyseabreeze
import seabreeze
#seabreeze.use('cseabreeze')
seabreeze.use('pyseabreeze')

print(seabreeze.__version__)

from seabreeze.spectrometers import list_devices, Spectrometer

devices = list_devices()
print (devices)

spec = Spectrometer.from_first_available()

# spectra to average... though this is not really used here.
loop_limit = 200

# prep lists as empty.
int_time = []
tpc = []

#
# Choose limits and step for integration time
# Note that the minimum int. time is 1000 µs for the Flame-S
#
for it in range(1000, 3000, 100):

    spec.integration_time_micros(it)
    int_time.append(it)
    i = 0 
    start_time = time.time_ns() 

    while i < loop_limit-1: 
        data1 = spec.intensities(correct_dark_counts=True, correct_nonlinearity=True)
        data0 = data1 + data0 
        i += 1
    stop_time = time.time_ns() 
    total_time = (stop_time - start_time)/1000 
    time_per_call = total_time/loop_limit
    tpc.append(time_per_call)
    print ("Int. Time: ",it, " Time per call: ", time_per_call)

plt.figure(figsize = (10,7))
plt.xlabel('Integration time (µs)', fontsize = 16)
plt.ylabel('Ave. Time per spectrum (µs)', fontsize = 16)
plt.plot(int_time,tpc,'o',linestyle='-', color='blue')

Results for this set was:

Int. Time:  1000  Time per call:  2565.49
Int. Time:  1100  Time per call:  2659.54
Int. Time:  1200  Time per call:  2745.105
Int. Time:  1300  Time per call:  2849.83
Int. Time:  1400  Time per call:  2951.915
Int. Time:  1500  Time per call:  3050.155
Int. Time:  1600  Time per call:  1597.55
Int. Time:  1700  Time per call:  1732.625
Int. Time:  1800  Time per call:  1853.94
Int. Time:  1900  Time per call:  1915.99
Int. Time:  2000  Time per call:  1996.895
Int. Time:  2100  Time per call:  2095.27
Int. Time:  2200  Time per call:  2197.08
Int. Time:  2300  Time per call:  2298.345
Int. Time:  2400  Time per call:  2393.31
Int. Time:  2500  Time per call:  2482.825
Int. Time:  2600  Time per call:  2586.715
Int. Time:  2700  Time per call:  2693.67
Int. Time:  2800  Time per call:  2784.31
Int. Time:  2900  Time per call:  2880.77

image

This is just an example and likely could be written more effectively. It may be interesting that when the ave time per spectrum is about 3200 µs the break occurs at ~1600 µs or maybe just a coincidence.

I will try to repeat this with different software later.

Dean

waldowda avatar Aug 19 '20 05:08 waldowda

Any progress on this question? I may have some time to look at it again. Dean

waldowda avatar Jul 23 '21 16:07 waldowda