Awg70k odmr #644
Awg70k odmr #644
Conversation
…icrowave source. For this additional functions were added so the 'tektronix_awg70k.py' hardware file complies with the microwave_interface. Now Resolved merge conflict resulting from cherry-picking commit ec77b93 from branch awg70k_microwave_interface. Some diffs between master and awg70k_microwave_interface remain unclear: __max_seq_steps = 0 <-> __max_seq_steps = -1 (changed for several parameters, sticking with the master branch) Comment in commit ec77b93 "THIS FEATURE IS NOT SUPPORTED BY AWG70K" but is apparently used in the current master branch. One command self.query(*OPC) that is not used in the master branch.
….py" file in the last commit. Added function to get the sampling rate used by the waveform compiler plugin and ensuring that the number of samples is a multiple of 2.
There was a problem hiding this comment.
I tested it on my setup and unfortunately it still gives me the same instabilities and extremely long waiting times as back when I tried to implement that.
First time I started an ODMR scan it took about 2 min before it actually started measuring. Then I stopped and changed the power and started again. Boom, waited for 10 min before I gave up because ODMR and the AWG did not respond anymore. Checking the socket server on the AWG itself revealed an ongoing read operation from client. This is exactly the kind of problem what makes those Tektronix AWG so bad. The server running on the AWG just deadlocks randomly on queries and the commands *WAI and *OPC? do not behave as specified in the standard.
Long story short, in my opinion this scheme of using the Tektronix AWG70k is completely unuseable. Very long waiting times during experiments, extremely volatile device communication and missing sync between this functionality and other modules using the AWG (like pulsed).
The additional cost for a cheap CW microwave device (~2k EUR) and a simple (slow) microwave switch (~100 EUR) makes a setup so much more productive and stable compared to using this integrated solution. And if you can afford a multi-100k AWG, these additional parts should be in the budget.
It's a shame that Tektronix is so extremely incompetent when it comes to their Software but it currently limits the usefulness for applications. (Analog hardware is great though)
|
@Geegee Do you encounter an entirely different user experience? |
|
What I can say is that it is slower compared to the setup with e.g. the SMIQ, but besides that it is running fine. As far as I remember also @anjusha-vs was using it for some time. Maybe it is a problem with the 2 channel AWG? It could also |
There was a problem hiding this comment.
The pull request was tested on a setup with Windows 8.1 Enterprise and with an one channel Tektronix AWG 70001A. The output was checked with an Antritsu Spectrum Analyzer.
The first loading of the ODMR module after starting qudi causes the AWG "Compiling basic waveforms" taking actually a long time.
As long as the ODMR GUI is not loaded yet loading other modules causes the whole qudi to crash. After some while the ODMR GUI appears with a timeout error notification.
I am not sure if this only happens to me or was also observed in other setups.
Another severe error is that the actual sampling rate of the hardware is not checked but assumed to be 50GS/s, even if in the config already something differnt is defined.
Loading and playing a waveform with not the proper sampling rate causes a wrong output (checked with the spectrum analyzer).
The test of the bounderies in the GUI was successful, no wrong parameter could be set.
With configuring the sampling rate to 50GS/s the output was correct for a single frequency as well as for ODMR runs.
I tested ODMR runs up to 4k points. These runs were successful but took a lot of time to upload. For 1k points it was about 5 min, however, double the points took more than double the time.
For a common use of the ODMR, finding some unknown resonance frequency this is very unconvenient way of working.
During the upload it is not possible to change the parameters (which is basically good) or interrupt the upload. Especially considering an accidentally set input parameter, it can be useful to interrupt a maybe very long uploading process.
It is not possible to load also other modules relying on the AWG when it is still busy.
This will cause an severe error in the communication, so that both, the AWG and qudi has to be restarted to again communicate properly.
Maybe this pull request could be an option when the bugs are fixed for only small ranges (~100 points), but for the common use of ODMR it is currently not stable enough.
- First the sampling rate of the waveform compiler is set to the sampling rate of the AWG. - Second the user is notified with an error message in case the sampling rate is too low for the given frequency (around 6 points per period are necessary).
|
Thanks a lot for the rigorous testing, especially the sampling rate issue. It turns out that there are a couple more |
Use the Tektronix AWG70k as a microwave source that works in the ODMR toolchain.
Description
@Neverhorst made the AWG70k comply with the microwave interface.
I made the get_status functions use overloading. Introduced a new function that
gets the sampling rate of the simple waveform compiler and additionally a small change
that ensures that the number of samples is even.
Motivation and Context
How Has This Been Tested?
Could only test with some changes as the way I run ODMR differs somewhat
due to different hardware (mainly I need an additional sequence step that is only run once).
Screenshots (only if appropriate, delete if not):
Types of changes
Checklist:
documentation/changelog.md)