On 2021-09-06 5:13 p.m., zhou wrote:
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.
I would suggest that you look at the time-domain signal in raw form near
the end of your capture, and that might well give you good hints about
what is going on. The N321 and X310 are different platforms, and
will have slightly-different fine-scale behavior.
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]> <mailto:[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]
<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]
