Hello together, hi build UHD version 4.6 on the fft_cp_preview2 branch, I don’t know if this is (already) supported. And With the YAML files there I build the FPGA Image (x410_x4_200_fft_ddc_duc_rfnoc_image_core.yml) just at it was an flashed it to the USRP. All of this just worked fine. I Also can Use the fft blocks with the cyclic prefix. Just two questions came up to me while tinkering with the ofdm_loopback.py example script. As far as I understand using the -l flag I avoid using the analog frontend and with the -d flag set to for instance 50 I can set a digital delay. All this also works… Now the question if I use the analog frontend (not setting these flags) and attaching cables the delay I measure is way longer. I’ve seen there is a delay of 188 samples set between the Tx and the Rx in the example script, is this due to the FPGA setup? Is there a way to make the Rx and Tx in time-sync? I’ve seen a timed command is used there and the delays between Tx and Rx are constant, but constantly to big. I can correct for this time error, is the the following correction right 188 / tick_rate? Or is there more to compensate for?\ I tried to set the same time_offset in the transmit_and_receive function but still seen the same delay, so I guess that is a delay which can’t be removed? The other thing I have noticed is that if I set channels just to 0, away from the default which is 0,1 I don’t receive any samples. Seems like the flow graph hangs after sending, this happens regardless of using the loopback (-l) or not.. \ \ Other than that I realy like this feature in UHD and am looking forward to the official release, great work keep it up!

PS: maybe I should have checked for typos before sending the message. I hope it is understandable, if not I’ll send a corrected version. Sorry for the inconvenience.

Hi Ruben, thanks for your question to the new FFT+CP feature. 1. The question regarding the delay: you can use the ofdm_loopback.py example (probably renamed to fft_loopback.py when officially released) to calibrate the exact actual delay of the complete processing chain, including RF. Don’t provide CP insertion/removal values (no —cp-list/-p flag) and find the delay (number of samples as —delay/-d flag) where you see a sharp peak in the diagrams shown in the second row (=amplitude of the received signal). Note that symbol #0 has minor transient effects but all other symbols should have a sharp peak. 188 samples is what we measured for the 200 MHz bitfile, which value do you determine? 2. As you noticed, the pre-release version in branch fft_cp_preview2 has a limitation that only two (“0,1” / “2,3) or four channels (“0,1,2,3”) are supported. Kind regards,\ Jörg

Hello Jörg, \ Hello interested reader, sorry I was quite busy end of the year and then on vacation so I couldn’t continue with my tests here. But today I tinkered a little with what you described under 1. \ Unfortuantely, I wasn’t able to reproduce what you are saying. Are we working on the same version of the code (ofdm_loopback.py) ? here is some Info. 1) the command I used initially with a delay of “0” according to what you said this shouldn’t result in a sharp peak, which I am seeing. `./ofdm_loopback.py --args "addr=192.168.10.2" -s 2048 -n 10 -y 0.8 -d 0 -c 0,1 --tx-gain 0 --rx-gain 0 --rate 245760000` `using arguments:` `--args addr=192.168.10.2` `--fft-size 2048` `--num-symbols 10` `--amplitude 0.8` `--cp-list ` `--channels 0,1` `--loopback False` `--delay 0` `--tx-gain 0` `--rx-gain 0` `--rate 245760000.0` `Using samples per packet of 1024` `[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; DPDK_21.11; UHD_4.6.0.fft_cp_preview_2-14-g4a94995c` `[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=x4xx,product=x410,serial=33D8E1F,name=ni-x4xx-33D8E1F,fpga=X4_200,claimed=False,addr=192.168.10.2` from the output you can see on which Version of the code-base I am working (fft_cp_preview_2-14-g4a94995c). I changed the amplitude to 0.8 but that doesn’t really affect the result.  So my guess is that in the current version of ofdm_loopback.py the delay is already accounted for by lines 640 and 641: `(…)`\ `tx_time=tx_time,`\ `rx_time=tx_time + get_tx_rx_delay(radio, args),`\ `(…)` where get_tx_rx_delay is a function (starting from line 373) which sets the delay as follows: (only showing lines 388-395) `else:`\ ` # With RF loopback there's a fixed delay between TX and RX`\ ` if tick_rate in [245.76e6, 250.0e6]:`\ ` # Add 188 cycles for 200 MHz FPGA`\ ` loopback_delay = 188`\ ` else:`\ ` raise NotImplementedError()`\ ` return loopback_delay / tick_rate` Am I right with my assumption? \ So to check for the delay I should set that offset back to 0 from 188 right? \ But when I tried that, the number of Rx samples didn’t match the number of Tx samples and the code didn’t execute fully. \ \ So is there a different code I should focus on ? \ Furthermore i wrote a code which estimates the delay on the phase-difference between tx and rx. But these delays somehow don’t match the time I get by `loopback_delay / tick_rate` which would be 188/245.76MHz in my case… \ \ Do you have any suggestions what I can additionally try to determine the delay introduced by the USRP. Or maybe hint an error I might be doing… Kind regards and a happy new year, Ruben