On 16/10/2024 20:55, Ekin Su Sacin wrote:
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
99% of the folks on here would have no idea what a Dicke Radiometer
is. I do. But unfortunately, I'm not much of an FPGA guy.
You haven't mentioned which USRP you're using, with which
daughtercard(s). What are your ultimate bandwidth requirements?
Given your "test" frequency of 28MHz, I'm guessing this is some kind of
HF radiometer, so I can't imagine that you're
dealing with "eye-watering" bandwidth. Have you considered a purely
host-based implementation? Gain drift in
modern RF hardware is small enough, and slow enough, that a fairly
"lazy" Dicke-switching cadence could probably
be used, and it could probably be managed from the host side. Due to
uncertainties of how many samples there may
be "in flight", my approach to this in the (distant, mind) past has
been to simply discard some samples after a state-change
of the Dicke hardware. This has negligible impact on radiometer
sensitivity.
I'm able to do 50Msps of simple radiometer-like "things" into a host
computer that is 11 years old. So with more modern
PC hardware, this shouldn't be a problem to manage
