I'm one of the 99% and I didn't even bother to Google what a Dicke radiometer is. Nor do I have even half of Marcus' RF and RA knowledge.
But I know a thing or two about RFNoC. Here's what I gather from your email: - You are capturing a radio signal from some source - You are also generating a clock signal (which presumably gets applied to your capture device?) - I'm guessing that this clock signal controls which part of the time domain signal you're actually capturing, but the USRP's receiver will be free-running, so if you're not capturing continuously, that means you have gaps in your Rx signal you want to remove? (Again, just guessing) - You are having trouble synchronizing Now my mission here is usually to steer people successfully towards RFNoC (and what you've done already is pretty impressive), but in this case I agree with Marcus that a software approach might be sufficient. Can you not simply generate your Dicke-clock-signal in software and generate it on the B-side of your device, instead of on the GPIO? USRPs will take care of synchronizing Tx and Rx signals in time (with some offset, but that can be calibrated and you seem perfectly capable of doing so). This seems more like a GNU Radio task than an RFNoC task. If not, then I blame my ignorance in this particular field -- maybe you can ask a more specific question. --M On Thu, Oct 17, 2024 at 3:12 AM Marcus D. Leech <patchvonbr...@gmail.com> wrote: > 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 entirely from the > software side of things. > > > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
