Thank you Nick! These explanations are very helpful! Do you know any reference where the FIR filter and buffering in the USRP are documented? I would like to study more about them. I appreciate your help a lot.
Wei Nick Foster <[email protected]> 于2021年6月16日周三 下午7:00写道： > I am guessing you mean X310, since E310 doesn't take daughterboards. You > are seeing the effect of FIR filter delay in the USRP's halfband filters. > You can confirm this by setting the sample rate to (for instance) > 200Msps/511. The use of an odd factor will result in lower filter delay but > increased amplitude error toward the edges of the received spectrum. > > This effect also occurs on the TX side, but because the timed transmission > is queued and buffered at the radio component (which operates at 200Msps) > after upconversion, the resulting latency will be much smaller: 200Msps/42, > or about 200ns. > > Nick > > On Wed, Jun 16, 2021 at 2:09 AM Huang Wei <[email protected]> wrote: > >> Hi all, >> >> I am very new to Gnuradio and USRP, and I have a question about the code >> transmission delay between USRPs. >> I have two USRP E310 with UBX160 daughterboards. I send a sequence of >> code from one USRP using simple amplitude modulation, and receive it by >> another USRP. On the receiver side, I use a replica of the code to >> cross-correlate with the received code to compute the transmission delay. >> However, I can’t explain this delay I obtained: >> >> 1. when I set the sample rate to 200MHz/128, the delay is 26.837 us >> (≈ 42 samples); >> 2. Sample rate to 200 MHz/256, the delay is 0.0537 ms (≈ 42 samples); >> 3. Sample rate to 200 MHz/512, the delay is 0.105 ms (≈ 41 samples). >> >> Also I recorded the date received by the USRP, it clearly shows that, no >> matter the sample rate is, the USRP source starts to receive the code after >> the 41st samples, and before are some strange values. You can find them in >> the attached plot. >> >> My questions are >> >> 1. why the transmission delay of the code are based on certain number >> of samples? should it be a certain value (some micro or Pico second)? In >> my >> case this delay changes with the sample rate. >> 2. what are those values received by USRP before the received code? >> they have some similar behaviors. >> 3. Maybe it’s not the correct way to check the transmission delay. Is >> there any better method for measuring it (e.g. adding time stamps)? I used >> USRP “rx_time” stream tags, and it always shows (xxx, 5e-9), like when it >> starts to receive something, maybe only the noise. >> >> (Additionally, both USRPs have their 1 PPS and frequency ref synchronized >> to the external high quality atomic clock. And I set them to start >> transmit/receive data at exactly the same time.) >> >> I appreciate a lot for any comment or advice ! >> >
