marceluda / rp_lock-in_pid

Lock-in and PID application for RedPitaya enviroment
https://marceluda.github.io/rp_lock-in_pid/
GNU General Public License v3.0
41 stars 22 forks source link

Harmonic Lock-in Working Frequency #10

Open jiuchang07 opened 2 years ago

jiuchang07 commented 2 years ago

Hi Luda,

I was wondering why the harmonic lock-in working frequency is limited to only up to 50 kHz. I read your paper and your source code and guess that it is because the gen_mod2.v module can only generate sinusoidal waves up to 50 kHz. Is this true? If there is another reason, I would love to learn about it. If the above is true, why don't you use the built-in signal generator that can reach up to 50 MHz?

Best, Jiu

marceluda commented 2 years ago

Hi Jiu

That is just a design choice. I made the reference signals from 2520 data points. This number was chosen just to have a very good harmonic shape with low anharmonic effects. So, the max frequency is internal clock / mem_length : 125 MHz / 2520

I've made some other versions with shorter mem length for higher modulation : https://github.com/marceluda/rp_lock-in_pid_h_hf

But I'm not doing maintenance on that...

El lun, 4 abr 2022 a las 21:42, jiuchang07 @.***>) escribió:

Hi Luda,

I was wondering why the harmonic lock-in working frequency is limited to only up to 50 kHz. I read your paper and your source code and guess that it is because the gen_mod2.v module can only generate sinusoidal waves up to 50 kHz. Is this true? If there is another reason, I would love to learn about it. If the above is true, why don't you use the built-in signal generator that can reach up to 50 MHz?

Best, Jiu

— Reply to this email directly, view it on GitHub https://github.com/marceluda/rp_lock-in_pid/issues/10, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACALCQFBOS466ZOAW2763ITVDOEA5ANCNFSM5SRESE2Q . You are receiving this because you are subscribed to this thread.Message ID: @.***>

jiuchang07 commented 2 years ago

Hmm that makes sense. I tried running the hf version on my RP and it doesn't work. For our purposes, we are willing to sacrifice the good shape of sine waves for a higher frequency.

  1. Which files should I modify to change the number of data points used? fpga/rtl/lock/gen_mod2.v?
  2. I see that gen_mod_h.v still uses 2520 data points. How did you achieve a higher frequency?
  3. Is there a reason you didn't use the signal generator code or the PLL code provided by the manufacturers? (It looks like the built-in signal generator ranges 0-50MHz)
marceluda commented 2 years ago

Sorry ... today I noticed I've never uploaded the changes made on de HF version. I've never pushed the git repo. My mistake. Now it's up today. The important file you are looking for is gen_mod_h.v

  1. I didn't want to use that generator for several reasons. The main one: I want to have several signals produced at the same time. cos_ref , sin_ref , double frequency, triple frequency ...
jiuchang07 commented 2 years ago

Great, it works! Thank you. I have a few more design choice questions:

  1. Why didn’t you use the clock frequency of 667 MHz and instead limited the signal generator to use 125 MHz? Is this because the input wave is sampled at 125 MHz and you wanted to match the input signal sampling rate with the reference signal frequency for the demodulation?
  2. Does the app sample the input signal at a lower frequency if the demodulation frequency is lower, or is the sampling frequency always 125 MHz?
  3. Did you do anything to filter out higher harmonic frequencies, e.g., using a digital filter on input signal to filter out higher harmonic frequencies before demodulation?
  4. I tried changing the number of data points used to generate signal in gen_mod_h.v to:

    // [PERIOD_LEN_PARAM DOCK]
    
    localparam mem_large =  12'd48   ; // complete signal large
    localparam mem_f1    =  12'd24   ; // memory large for cos_f1
    localparam mem_f2    =   9'd12; // memory large for cos_f2
    localparam mem_f3    =   8'd8; // memory large for cos_f3

    But it doesn't change the generated signal frequency. When the period parameter is 107, I would expect 24 kHz with 48 data points because it was 9.6 kHz with 120 data points, but it's still showing 9.6kHz. What else should I change?

marceluda commented 2 years ago
  1. 125 MHz is the frequency of the ADCs (tied to the Crystal oscillator). So you cannot acquire data faster than that. If I use an internal faster clock I wouldn't process info faster because the input signal will be still limited to that sample rate.
  2. The ADC and DAC sample rate is always 125 MS/s. The oscilloscope module can make a decimation procedure before user acquisition.
  3. No, I didn't. But is a good idea to implemente. I didn't do that just because I was short of FPGA resources.
  4. With that params I get 24 kHz for 107 period and 48 datapoints [ 125 MHz/48/(1+107) ] . Have you changed the values in the data_cos?.dat files? . You can use an script to make them
jiuchang07 commented 2 years ago

That makes sense, thank you for your clarification!

I was also studying the file mult_dsp_14.v but couldn't find the implementation of mult_dsp_14_mult_gen_v12_0_viv. Is the implementation included in the encrypted code below (line 134 - 334)?