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]
<mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
