Thanks for your explanation, Marcus.
The number of samples is based on the sampling rate. I am using X310 USRP. Its
sampling rate is equal to its master clock, 184.32MHz. Usually I capture signal
for 20ms, so the number of samples = 20*184320.We have many X310 USRPs and have
been using UHD3.10 for a few years. We have been capturing signals without
extra trailing 0s. There is no problem so far. Because it is stable, we don't
upgrade UHD even though new UHD versions come out. Only until recently, we need
to use higher sampling rate for new signals with wider band. I am using N321
USRP for this. We use the latest UHD for this USRP. Though the new system is
intended for the new USRP, I also try to use it on the old X310 USRP, then I
find this capture problem. Not all test cases fail with this new UHD. In some
cases, the EVMs are all good; only in some test cases, the last EVM is bad.
I haven't observed this EVM issue in the UHD4.1.0+N321 combination. It only
happens in UHD4.1.0+X310 sometimes, and it is repeatable. At the moment, my
workaround is to do 1ms extra capture for UHD4.1.0+X310 combination.
I do have other problem with N321. I will start another thread for it. Hope you
can continue to help.
On Monday, 6 September 2021, 16:18:00 BST, Marcus D. Leech
<[email protected]> wrote:
On 2021-09-06 10:38 a.m., zhou wrote:
Hi Marcus,
Thanks for your comments. What is group-delay in FPGA? I had a guess that
there was some delay between the time instance when FPGA issued Rx command and
the time instance when ADC started to sample. Does group-delay mean this?
I use time-based capture - specify a start time and specify the number of
samples to capture, uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
stream_cmd.time_spec = time_spec
stream_cmd.num_samps = num_requested_samples
In a while loop, I keep calling rx_stream->recv() to receive samples. When
the number of samples are received, capture is done.
The samples are saved in buffer when calling recv(); after all samples are
received, they will be saved into a file and processed offline.
From the EVM results, I don't think the whole timing is shifted between the
two UHD versions, otherwise, the whole EVM should become worse, but we only see
the final EVM becomes worse. It looks to me that FPGA is "releasing" ADC
earlier than it should. If I increase num_requested_samples, that seems to
delay its release.
Look forward to your further comments.
Many thanks,
Hongwei
Group delay is a property of any filtering element in a signal-processing
chain. Whether it's an analog filter or digital filter. Any SDR that has an
ADC clock
that is higher than the host-side sample rate will need a digital
down-converter (DDC) and that involves a digital filter. That digital filter
has group delay
(usually on the order of 10s of sample times). Different versions of UHD
might employ slightly different versions in the DDC portion of the FPGA, leading
to slightly-different group-delay behavior.
If you're calculating the number of samples you need based on something like:
number-of-frames-I-want X number-of-samples-per-frame
Then there is ALWAYS the chance that the last frame will get cut off.
Just as you usually need to "pad" the TX side with a few trailing 0s, so too
should you extend your receive for a few samples beyond what you exactly need.
This has always been true. That you "got away" with it in UHD 3.10 was
likely just a matter of luck.
On Sunday, 5 September 2021, 20:47:39 BST, Marcus D. Leech
<[email protected]> wrote:
On 2021-09-05 11:28 a.m., zhou via USRP-users wrote:
Hi All,
I have a problem in using X310 USRP after upgrading UHD from 3.10 to 4.1.0. I
am using it to capture NR5G radio signal in UL. After analyzing the captured
signal, the quality in the last subframe is worse than the earlier subframes.
EVM = [1.014, 1.08, 1.055, 1.053, 0.954, 1.043, 1.145, 1.112, 1.162, 1.072,
1.131, 1.125, 1.038, 1.08, 1.003, 1.1, 0.972, 0.941, 1.046, 0.917, 1.01, 1.023,
1.025, 0.982, 1.101, 1.044, 1.089, 0.987, 0.923, 1.022, 1.012, 1.009, 1.021,
1.037, 0.998, 1.112, 1.112, 0.981, 0.987, 2.785]
When using UHD 3.10, I had no such problem.
If I deliberately capture one more subframe with UHD 4.1.0 but ignore it
when analyzing the signals, I will have good EVM.
Is this a bug in FPGA for UHD4.1.0 in X310?
Thanks for any input.
Hongwei
My guess is that there are just slight timing and/or group-delay
deifferences between the two FPGA releases, and your capture time is just
slightly too short
to account for that.
It is inevitable that going from a quite-old release to very much newer
(latest) release that there will be subtle things like group delay differences
between the
two FPGA implementations.
How do you decide when you are "done" capturing? How are you capturing? Do
you do your processing in real-time, or do you capture to a file then
process the file.
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
