search

lneuhaus / pyrpl

pyrpl turns your RedPitaya into a powerful DSP device, especially suitable as a lockbox in quantum optics experiments.
http://lneuhaus.github.io/pyrpl/
MIT License
140 stars 108 forks source link

NA on low frequency, restriction and bug with rbw #372

Open bricault opened 5 years ago

bricault commented 5 years ago

Hello, First Thank you for your collaborative work!!! Perhaps i can collaborate and try to merge one of my project.

But now, I try to use the NA module of pyrpl with many decades down to low frequency, i hope that it's possible (ideally i hope to go to 1mHz, i see that NA can drive at 2.91e-2). So i have a problem with the rbw. Ideally, i don't need filter, because my electrochemical electronic already compense the DC offset. But i don't understand the use of the rbw in the formula τ=avg_per_point/rbw.

Also, i find a problem for using this rbw. For example i try to get NA between 1Hz and 1kHz, but rbw cause problem: it s work for rbw >= 7.589e1 , but NA stopped for rbw < 7.589e1 ("NA data not yet ready").

Last trouble: I don't understand the IQ modulation for this test: I can draw on NA as many point that I want between 1Hz and 2 Hz, and points are draw very fastly. I don't understand that because the sum of the Real and Im can only be true exactly at the pi and 2pi phase of the modulation, so at 1Hz modulation, point can only be true at least all the 0,5s.

I work with the "python3-only" branch, because using of python 3.7 (last issue of Samuel) Thank you. Damien

lneuhaus commented 5 years ago

Hi,

  1. If you want to drive at frequencies below 29 mHz, you need to modify the IQ module Fpga code, at best adding more bits (5 at least) to the accumulated phase register, and similarly to the frequency setting register. This should probably still fit in the current FPGA design. Let me know if you have trouble doing this.
  2. The NA can work without lowpass filter, i.e. cutoff frequency set to zero. It is possible that this causes an error in the python interface of the NA, in which case you can either try to fix it in the NA code, or directly use the raw data from the FPGA. Check out the lower level NA implementation in function "na_trace" in https://github.com/lneuhaus/pyrpl/blob/python3-only/pyrpl/hardware_modules/iq.py, or the example notebook https://github.com/lneuhaus/pyrpl/blob/python3-only/docs/example-notebooks/iq-accumulator-example.ipynb
  3. "NA data not yet ready" must be a bug. The code is not waiting long enough for the measurement to have finished. The solution is to increase the number of retries to get the data, as this is probably related to different clock drifts of your PC (determines the time to wait) and the FPGA (determines the actual measurement duration). Let me know if you are unable to find the relevant code.
  4. If I understand correctly, you would like to forbid certain rbw/averaging times that are similar or even much shorter that a modulation period. While this could be done, we did not exclude that to not limit the freedom of the user artificially. Maybe somebody finds a scenario where this is useful? But we could at least issue a warning in this case..
lneuhaus commented 5 years ago

One problem you will encounter with point 1 is that the frequency setting register 'shift_phase' currently has 32 bits, and if you add more, you cannot update it in a single write operation, which can break the NA logic if not done carefully. Basically, the frequency setting register should become a 64bit register of a new type "LongFrequencyRegister", derived from "Frequency Register" and "LongRegister", and should get an address of two consecutive 4-byte blocks, where I recommend 0x104 and 0x108 for minimum code changes. Then you need to assign a new free address for the start_frequency register, eg 0x128 and 0x12C. It is not a lot of work, so if this feature is important to you let me know and I can also do it.

lneuhaus commented 5 years ago

3 was indeed a bug in the python 3 branch, fixed by Samuel today

SamuelDeleglise commented 5 years ago

Ok at first I thought we were not talking about this bug since I understood we were talking about a bug in the master branch, but indeed, after re-reading the thread above, that was most probably the bug I solved today (the bug was only present on the python3-only branch I believe)