Hello,
I am working on modifying rfnoc_keep_one_in_n.v code for a Dicke radiometer
application. My goal is to generate a Dicke clock for different modes and
to obtain the accumulated power of the incoming signal over half of the
Dicke cycle. I am using this block to produce a Dicke clock from
front-panel GPIO and using the n register to define different modes in
addition to defining the number of kept samples. These modes determine
which GPIO pins will be active. Additionally, I use the complex_to_magsq
module to compute the power of the incoming signal. I have verified the
Dicke clock output from GPIO using an oscilloscope. It responds correctly
to changes in the n value at the application level.
When I try to sample a sinusoidal wave, it produces the sawtooth pattern
for kept samples which looks correct. Initially, I thought that by
adjusting the n value and data rate at the application level to cover half
of the Dicke cycle, I could obtain accumulated results over this period,
which would match the last value of the sawtooth. However, this approach
isn't working as expected. I am using a 200 MHz clock, resulting in a
half-Dicke period of 327.68 µs. To match this, I set the data rate to
ensure an integer number of samples per Dicke period, such as 25 MSPS. I
ran the following command for testing: ./rfnoc_rx_to_file --args
addr=192.168.10.2 --freq 28e6 --nsamps 0 --rate 25e6 --block-id KeepOneInN
--n_value 8192,and for testing, I applied a 27 MHz sinusoidal input.
However, this setup yields inconsistent results. When I change the rate to
20 MSPS or other values, the results seem more accurate. I also
experimented with different n values like 4, 20, and 40, which produced
sawtooth patterns with varying periods as expected. However, my primary
goal is to gather data specifically at the end of each half-Dicke cycle
rather than picking samples during the cycle.
I suspect there may be a synchronization issue between the block and the
Dicke clock. Could you provide suggestions based on my objectives, or is
there an alternative approach that might be more effective than adjusting
the n value? I am also adding modified parts of the code below.
Thank you in advance for your support. I look forward to your response.
Best regards,
Ekin
In output state machine, sample_reg[31:16] <= v1o[31:16];
sample_reg[15:0] <= v2o[31:16];
.......
always @(posedge clk) begin
if (reset) begin
k <= 0;
dicke_1 <= 0;
dicke_ch <= 0;
ctrl_cal_1 <= 0;
ctrl_ref_1 <= 0;
ctrl_v_1 <= 0;
v1o <= 32'd0;
v2o <= 32'd0;
end
else if (~reset) begin
k <= k+1;
if (k == 65536) begin // yields dicke freq = 1.53 kHz
k <= 0;
dicke_1 <= ~dicke_1;
dicke_ch <= 1;
end
if (dicke_ch == 1) begin // if dicke clock phase changed
if (n == 4) begin // Ref-V
if (~dicke_1) begin
ctrl_cal_1 <= 0;
ctrl_ref_1 <= 1;
ctrl_v_1 <= 0;
end else begin
ctrl_cal_1 <= 0;
ctrl_ref_1 <= 0;
ctrl_v_1 <= 1;
end
end
else begin // Cal-Ref (mode 1 for anything else)
if (~dicke_1) begin
ctrl_cal_1 <= 1;
ctrl_ref_1 <= 0;
ctrl_v_1 <= 0;
end else begin
ctrl_cal_1 <= 0;
ctrl_ref_1 <= 1;
ctrl_v_1 <= 0;
end
end
dicke_ch <= 0; v1o <= 32'd0; v2o <= 32'd0;
end
else if (dicke_ch==0) begin
if (s_axis_tvalid && s_axis_tready && o_tvalid) begin
if (dicke_1 == 0) begin
v1o <= v1o + o_tdata;
end
else if (dicke_1 == 1) begin
v2o <= v2o + o_tdata;
end
end
end
end
end
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
