Project

General

Profile

Bug #24878

Labview DAQ is broken, the first 1000 point capture is repeated

Added by Brian Chase about 2 months ago. Updated 22 days ago.

Status:
Closed
Priority:
Immediate
Start date:
08/28/2020
Due date:
% Done:

100%

Estimated time:
Spent time:
Duration:

Description

I have looked at many files taken by people in recent days and all I see is a repeat of the first 1000 points for all parameters.
This needs to be fixed, tested in the Lab, documented and deployed. It would be very good if we can understand when and how this got broken.
Testing in the lab means that there has to be a signal with sinusoidal modulation that can be measured for data integrity. Something like a 9.41 Hz sine wave.

I want this done on the version that added the raw IQ data so that this feature will be deployed as well.

lv_dat_file_reader.m (5.51 KB) lv_dat_file_reader.m John Dusatko, 09/01/2020 03:50 PM

History

#1 Updated by John Dusatko about 2 months ago

Further Testing on 8/31/2020 & 9-1-2020:

All,

I did some tests in the lab yesterday and today to check for the following items:

1) Test if the 1000 sample repeating problem is resolved
2) Test if we get contiguous data for a waveform between 1000 sample packets
3) Test if Cavity B DAQ works properly
4) Test if we get continuous, contiguous data for long (minutes) recording sessions

These tests were done on the lab system. We inject a 325.001MHz signal from an RF synthesizer into the Cavity and forward ports (via a 3dB power splitter / there is an additional 3dB pad on the forward signal) of the 325MHZ downconverter chassis. To see some signal, 400Hz and 800Hz FM was injected into the carrier signal (using the FM modulation feature of the RF synthesizer). I saved only Cavity Magnitude and Cavity Phase to the .dat file. I moved the RF synthesizer signal inputs between Cavity A & B ports for my testing. I selected between cavity A & B using the labview Cavity 9 & 10 selections, respectively.

Data files were recorded and analyzed offline using the matlab code that was supplied, with a few more additions.

The recordings were done with the dt = 50 value, as Ed suggested.

Here is the summary of what I found:

1) The repeating packet problem seems to be fixed for Cavity A, but still seems to be there for Cavity B: if you look at the raw data, you can see the exact same value for array elements 1, 1001, 2001… this is true for both of the waveforms that I recorded.
2) The data seems to be contiguous for the recorded waveforms. I checked this by doing an FFT on the waveforms, with the assumption that non-continuous data would show up clearly in an FFT. The FFTs looked reasonable.
3) Cavity B DAQ partially works: It records the signal injected into the Cavity B ports, but the repeating problem is there
4) I took 10000 packet (sample) recordings (which works out to something like 8 minutes) for both Cav A & B: Cavity A looks OK, cavity B has the repeating problem, so the test is inconclusive. This test probably needs to be repeated for longer recording sessions.

The data files are located here:

Y:\Projects\LLRF\Documents\LLRF user share\jdusatko\HWR_lab_test_data

I am attaching the matlab file to this message so you can run and also cross-check my findings and if my code is correct. I used the matlab unique() function to check for repeating data. When I do the FFT, I only run it on 2^n points where n is determined from the total number of samples in the dataset. So its not computing all points. I did this because although I can FFT the full dataset for small files, it seems to choke on big datasets like 10E6 samples.

Regards,

/John

#2 Updated by John Dusatko about 2 months ago

Some follow-up from Ed Cullerton:

Hi John,

The fundamental problem is that the ‘wavelist’ sent to the front end is only correct when cavity A is selected. The data packet does not repeat, it is just that the local buffer is not being updated . You will have to add a conditional around the code (frame 9 of the Main Loop, ‘Get Data’ event) to check for cavity A or B selected.

If I remember correctly, the bitfield for the wavelist has the MSB set to 1 for cavity B. You will have to send the following when cavity B is selected:

( 1000 0000 0000 0000 0000 0000 0000 1100) for cav I and Q signals – needed for cavity mag and phase

( 1000 0000 0000 0000 0000 0000 0011 0000) for forward I and Q – needed for forward mag and phase

( 1000 0000 0000 0000 0000 0000 1100 0000) for reverse I and Q – needed for reverse mag and phase

(1000 0000 0000 0000 0100 0000 0000 0000) for frequency tracking

( 1000 0000 0000 0000 0000 0000 0000 0100) for cav I

( 1000 0000 0000 0000 0000 0000 0000 1000) for cav Q

Look at the Labview code in the event for: “Tab control”, “Display A”, “Display B”, “Disaply A ctl”, ……

That will show you how the wavelist is set for the display windows waveform requests.

Ed

#3 Updated by John Dusatko about 2 months ago

Uploading matlab file

#4 Updated by Shrividhyaa Sankar Raman 22 days ago

  • % Done changed from 0 to 100
  • Status changed from New to Closed
  • This issue has been solved.
  • The LV panel was not requesting data correctly.
  • This issue was solved by restructuring the arrays in the LV code to accept the right data at the right time.
  • This ensures proper population of the buffer.
  • Changes mainly involved in case 1 of the outer loop -> case 9 of the main loop -> case 2 (Get Data) of the event handle loop.
  • Here the new waveforms were added and the size of the cluster restructured.


Also available in: Atom PDF