Subsequent runs of lock-in and step response measurements

Problem

Subsequent runs of a lock-in and step response measurement do not seem to work.

General setup

# Initialize an experiment
frequenciesHz = np.linspace(1., 2., 2)
Q=70.
rampsHzSq=np.diff(frequenciesHz)/(Q/frequenciesHz[:-1])
ringupPeriods = np.full_like(frequenciesHz, 2.)
measurePeriods = np.full_like(frequenciesHz, 1)

freqsDphi = [frequencyHzToDphi(x) for x in frequenciesHz]
rampsDdphi = [rampHzSqToDdphi(x) for x in rampsHzSq]
rampsDdphi.append(rampsDdphi[-1])
nSweeps = []
for i in range(1,len(freqsDphi)):
    nSweeps.append(DeltaDphiAndDdphiToNsweep(freqsDphi[i]-freqsDphi[i-1], rampsDdphi[i-1]))
nSweeps.append(nSweeps[-1])
nRingup = [numPeriodsToNringup(ringupPeriods[i], frequenciesHz[i]) for i in range(len(frequenciesHz))]
nMeas = [numPeriodsToNmeas(measurePeriods[i], frequenciesHz[i]) for i in range(len(frequenciesHz))]

# Transfer to FPGA
myStitch.setFrequencies(freqsDphi)
myStitch.setMeasureDurations(nMeas)
myStitch.setRingupDurations(nRingup)
myStitch.setSweepDurations(nSweeps)
myStitch.setSweepFrequencyDeltas(rampsDdphi)
myStitch.setNumFrequencies(len(frequenciesHz))

What works

First running the step response measurement and subsequently retrieving the lock-in data of the same experiment works, see the code below:

# Needed for trace recording: set a delay after which recording starts
delay = frequencyHzToTraceDelay(frequenciesHz[1], added_delay=10e-9)
myStitch.setTraceDelay(delay)

# Start the experiment
myStitch.startExperiment()

# Retrieve trace results by choosing SEL_TRACE
timeData, traceData = myStitch.getData(SEL_TRACE) # this successfully returns trace data

# Running the command to retrieve the lock-in data of this experiment
lockin_data = myStitch.getData(SEL_LOCKIN) # this successfully returns lock-in data

How to reproduce the error

# Needed for trace recording: set a delay after which recording starts
delay = frequencyHzToTraceDelay(frequenciesHz[1], added_delay=10e-9)
myStitch.setTraceDelay(delay)

# Start the experiment
myStitch.startExperiment()

# First retrieve the lock-in data
lockin_data = myStitch.getData(SEL_LOCKIN) # this successfully returns lock-in data

# Subsequently try to retrieve the trace data by choosing SEL_TRACE
timeData, traceData = myStitch.getData(SEL_TRACE) # this fails

The last line produces the error

---------------------------------------------------------------------------
IndexError                                Traceback (most recent call last)
Cell In[18], line 1
----> 1 myStitch.getData(SEL_TRACE)

File ~\pythonlibs\Delicate\Stitch\Stitch.py:156, in Stitch.getData(self, select)
    154     traceData.append([data[i*20:i*20+4]]) 
    155     # 5th byte: laser receive time data
--> 156     timeData.append([data[i*20+4]]) # TODO: check this again
    157 return timeData, traceData

IndexError: index out of range

since data = self.serialHandle.read(20*2**15) in Stitch.getData has length 0.

Trying to retrieve the lock-in data again after getting this error message returns empty data:

myStitch.getData(SEL_LOCKIN)

Output:

([[b''], [b'']], [[b''], [b'']], [[b''], [b'']])

Even after restarting the kernel and repeating the experiment, the myStitch.getData(SEL_LOCKIN) returns empty data.

Note: The green LED of the FPGA is constantly on indicating that one of the 5 lowest bits of iCommandDecoder_max_count is '1' (a delay for recording the trace is set).

Current solution

Unplug and plug in the USB cable of the FPGA.

Consequently, obviously, the LED turns off.

changed the description

changed the description

changed the description

Explanation

A call to myStitch.getData(SEL_LOCKIN) locks ReadbackTraceControl in state SEND_DN. Following this up with the correct number (i.e. ceil[32768/CommandDecoder::n_freqs] - 1) of calls to myStitch.getData(SEL_LOCKIN) will unblock ReadbackTraceControl. However, calling myStitch.getData(SEL_TRACE) on a locked ReadbackTraceControl will also lock ReadbackControl. That's why myStitch.getData(SEL_LOCKIN) -> myStitch.getData(SEL_TRACE) locks up the output stage completely.

Solution Idea

In order to prevent the locking of ReadbackTraceControl, this component should be held in state IDLE_S until CommandDecoder::sel has the correct value (i.e. 1).

Solution Implementation

Add a sel input port, connected to the CommandDecoder::sel output port, to ReadbackTraceControl:

entity ReadbackTraceControl is
    Port ( clk100: in STD_LOGIC;
	        start : in  STD_LOGIC;
        --    end_addr : in  STD_LOGIC_VECTOR (16 downto 0);
           serial_trans_idle : in  STD_LOGIC;
           addr_rd : out  STD_LOGIC_VECTOR (14 downto 0); -- address read
           idle : out  STD_LOGIC;
           send : out  STD_LOGIC;
           sel : in  STD_LOGIC);
end ReadbackTraceControl;

Change the update_proc transition out of the IDLE_S state to the following effect:

...
when IDLE_S =>
			if start_old_sig = '0' and start = '1' and sel = '1' then
				current_state <= APP_ADDR;
				idle_sig <= '0';
			else
				current_state <= current_state;
				idle_sig <= '1';
			end if;
			send_sig <= '0';
			addr_sig <= (others => '0');
...

Notes

Note that a symmetric problem will arise for ReadbackControl, whenever CommandDecoder::n_freqs > the number of samples in a trace. The solution is analogous.

mentioned in commit bf7fb22b

Bug fixed in bf7fb22b

closed