fixes timing issues with triggering

[RostyslavSavytskyy]

In the cases when AWG does not demand a trigger for the first pulse in its sequence (e.g. arbstudio), a pulseblaster needs to wait this additional time between the end (start) of the sequence and the second pulse. Otherwise, the next trigger (for the second pulse) will appear right after the trigger in the end of the sequence, hence cutting out the first pulse, e.g. pre-delay in the plunge pulse is completely gone and is defined only by pulse_sequence.final_delay.

[nulinspiratie]

Hmm are you sure this is needed? I thought I already handled this in the code, I even made a comment about it in lines 120-123. And if there aren't any pulses at the start, it'll send a wait command until the first pulse, right? That's at least how I understand lines 136 - 152

[RostyslavSavytskyy]

I found this problem by looking at the pulse sequence using the oscilloscope. It seems to me that your comment in lines 120-123 was for the "assert 0 in t_list" only, which you commented out. Lines 136 - 152 are looping over the t_list, which does not contain 0, and once the sequence/list is over it does not check for the first pulse of the t_list. But we need to have the delay from 0 to the first Trigger Pulse in the sequence, otherwise the pulseblaster just starts the next sequence and skips the delay.

[RostyslavSavytskyy]

This has already been tested and so far seemed to work

[nulinspiratie]

The pulseblaster interface is inherently tricky, because adding changes that make it work for some instruments may break other instruments. I therefore think this needs to be really be analyzed in depth before accepting this PR. And by analyzing it I mean think if the instructions that are being sent make sense

I'll have a proper look at it whenever I can find some time, but it would be good if @RostyslavSavytskyy can do the same.

[nulinspiratie]

Also it would help if you can print the entire pulse sequence you want to apply. Try to create the simplest pulse sequence that produces the issue. And print both the setup-independent pulse sequence and the pulse sequence from the relevant interfaces

[RostyslavSavytskyy]

I have already spent a whole week trying to find what the problem is (looking at the code for the arbstudio_interface, pulseblaster_interface, checking actual pulse sequences on the oscilloscope, etc.) and because the issue is in the delay between the two consecutive sequences looking at the pulse_sequences in all of the interfaces (AWG, pulseblaster, measurement parameter (adiabatic_ESR)) will not help, since they do not contain the pulse_sequence.final_delay in them or any other information about the times in between the sequences - I have tried/tested this already. The only thing I found was in the pulseblaster: if you have a pulse_sequence where triggers start with the second pulse (as with arbstudio), then the time_list that pulseblaster analyses/uses is something like: t_list = [2e-6, 2.2e-6, 4e-6, 4.2e-6, 6e-6, 6.2e-6, 8e-6, 8.2e-6], where 2us is the pre_delay in the aESR parameter in the plunge section or the start of the aESR_pulse itself; 2.2us is the end of 200ns trigger pulse; 4us, 4.2us - the end time of a 2us aESR pulse; 6us, 6.2us - the end time of the plunge pulse (with 2us post_delay) and the start of read_initialize; 8us, 8.2us - the end of the read_initialize and overall pulse sequence. Don't worry about 1e-6, I used these small times so that I could easily test on the oscilloscope all of the pulses. If you look at the pulseblaster instructions list, you will find all appropriate commands for all of these pulses and then an additional command at the end of the sequence regarding the pulse_sequence.final_delay. And that's it, to my understanding of the pulseblaster work, this means it will start applying the first trigger pulse of the next pulse sequence right away and it does not know about the fact that it should wait for an additional 2us before actually applying it - I could see this on the oscilloscope: the first trigger of the next sequence was right after the end trigger of the previous sequence, without any delay of 2us between them. This is why I introduced this delay there. To be safe that this issue doesn't crash anything for other instruments, besides Arbstudio I have also tested Keysight 81180, looked at all triggers for the Arbstudio, 81180, and microwave sources after adding the changes and it seemed to be all working fine. I honestly don't think I can check anything else more and unfortunately already don't have time. If you would like to see some specific pulse sequence/output from the device, let me know I can try sending you this.

[RostyslavSavytskyy]

I think Tallulah is currently the remaining and only setup using PulseBlaster, so others should not have these issues any time soon. @maij, would you care to add your opinion here before I merge this branch?