On-trigger acquisition phase stability

[werefkin]

Hi Alex,

First of all, thank you a lot for releasing the new version, I have had my hands on it just now - it is very cool and easy to use (I use a non-GUI version). Decimation works perfectly (I know it is with no averaging). However, I noticed that the on-trigger acquisition behaves weird.

To explain the issue, here is how my signal looks like (trigger signal is in blue, I connected it to the 2nd channel just to record them synchronously): The signal period is 0.1 s. These rectangular pulses (0..3.3V) I use for on-trigger acquisition for the 1st channel (orange signal is of my interest for stable acquisition).

Further, the reference signal connected to the EXT_TRIG pin, I run your script (non-GUI),

for bUseTrig = 0 I clearly see that on-trigger ACQ is OFF (as the recorded signals are randomly places in the time domain):

when bUseTrig = 1 on trigger ACQ is ON and it can be seen, but something like 50% of the signal is being shifted (and sometimes there are small shifts as well). Here I recorded 10 cycles with bUseTrig = 1 , in this case, 5 cycles overlap well and 5 do overlap but with some shift relative to the first 5 (also they are quite unstable in phase actually).

Do you have an idea from where this problem could come from? I have tried to play with some parameters but did not succeed. Also, I tried to feed ideal signals to the RP generated using a function generator, the results are the same. I also played with the phase for the signal, but it did change nothing.

[werefkin]

Hi! I could make it work by introducing another time delay in the loop ` for i in range(0,len(daqdat)): print(i) timeStart = time.time()

time.sleep(n_pts/fs) 

dev.write_Zynq_AXI_register_uint32(TRIG_REG, 0)
dev.write_Zynq_AXI_register_uint32(TRIG_REG, 1) # Start with trig need to stay high to register external trig
dev.write_Zynq_AXI_register_uint32(TRIG_REG, 0)
time.sleep(n_pts/fs) 

status = 0

while status == 0:
    status = dev.read_Zynq_AXI_register_uint32(STATUS_REG)

data_in = dev.read_Zynq_ddr(data_addr-START_ADDR, int(2*n_pts))
print('Elapsed time for receiving= {}'.format(time.time() - timeStart))

# data_in = np.fromstring(data_in, dtype=np.uint32) # Uncomment this line if you want to read data as 32 bits (useful if both ADCs are connected to counter)
data_in = np.fromstring(data_in, dtype=np.int16) # Uncomment this line if you want to read data as 16 bits
print('Elapsed time for conversion = {}'.format(time.time() - timeStart))
daqdat[i,:]=data_in

dd=np.transpose(daqdat) plt.plot(dd)

however, in this case, we arrive at a very slow acquisition speed. moreover, changing the decimation factor to 64 or 2048 makes it not working.

[werefkin]

Another very interesting observation -- sometimes even with the additional delay it fails, but fails in an interesting way. If I run the code (your code wrapped in a loop starting from trigger def dev.write_Zynq_AXI_register_uint32(TRIG_REG, 0) # 0 before to make sure we have a rising edge ) manually several times, it works and then does not and then works again. here I plotted several measurements (20 waveforms in each dataset) but with different run

[werefkin]

Please note, sometimes it is like that -- here it failed only in a single case out of 20 forms recorded

[alex123go]

Thanks for the debugging you did.

Good catch on the delay. I've never tried to use the code in a loop, but maybe there's a block that need some time to reset... I'm not sure why the delay solve the problem, but it's good if it works.

I have an idea where the 2nd problem might be coming from. The FPGA code look for the trigger event before the FIFO (which is filled at fs, but read 4 points at 2*fs in burst mode). There might be a variable delay in that block (that depends in which burst will the point of interest will be send). There would be some modifications to do to compensate for that.

I sadly don't have time to correct that in the near future, but I keep it on my to do list.

[werefkin]

Thanks for the debugging you did.

Good catch on the delay. I've never tried to use the code in a loop, but maybe there's a block that need some time to reset... I'm not sure why the delay solve the problem, but it's good if it works.

I have an idea where the 2nd problem might be coming from. The FPGA code look for the trigger event before the FIFO (which is filled at fs, but read 4 points at 2*fs in burst mode). There might be a variable delay in that block (that depends in which burst will the point of interest will be send). There would be some modifications to do to compensate for that.

I sadly don't have time to correct that in the near future, but I keep it on my to do list.

Hi Alex,

Thank you for the response. Sure, no hurry. Currently, my colleague who is more experienced with FPGA programming (sry I am mostly in a different field and here only a user), trying to find out what is the problem. At least, when we opened the project in Vivado, we have already seen some warnings about timing. WIll let you know if we find the issue.

[alex123go]

I'm not an FPGA programmer myself. I had to learn (and improvise) to build the tools we needed in the lab.

I'm aware of the timing issues, however, they are for reset signal and others which don't have impact on the design. I know there's a way to tell vivado to ignore the warnings on these signals, but didn't take the time to explore that.

[werefkin]

I'm not an FPGA programmer myself. I had to learn (and improvise) to build the tools we needed in the lab.

I'm aware of the timing issues, however, they are for reset signal and others which don't have impact on the design. I know there's a way to tell vivado to ignore the warnings on these signals, but didn't take the time to explore that.

We will try to find out. Do you know a tutorial to learn that (maybe not the right place to ask, though)? What i have found is quite a mess. Life is fast, also do not have enough time, but still enough interest.

[alex123go]

I haven't find a lot of useful resources. I like https://www.nandland.com/ for the basis.

For more complex design, it takes a lot of time and a lot of debugging. It also help that I could start from a functioning design (constraint file, ethernet communication and some code examples already present).