usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsRe: [USRP-users] Rx sample rate for USRP E310
Thank you Marcus and Martin.
Maybe I will try to explain what I am trying to do and you can correct what
I am doing wrong.
I don't want to stream the samples. I understand the limitations of the ARM
processor.
What I would like to do is to record (capture) samples to DDR memory in
real time. Only one block of samples.
Then, write that block, offline, to the SD card as slow as necessary. So
definitely no streaming to SD card.
This should be possible and not related at all to the speed of the ARM
processor. It should be handled by a DMA of the FPGA directly to DDR memory
and the FPGA should be fast enough to handle the task.
I thought that by specifying --nsamps instead of --duration it would
achieve exactly what I wanted. I thought that specifying --duration is a
streaming operation while specifying --nsamps makes it one-shot.
Regards,
Ofer Saferman
---------- Forwarded message ----------
From: Martin Braun martin.braun@ettus.com
To: usrp-users@lists.ettus.com
Cc:
Bcc:
Date: Tue, 8 Sep 2020 17:16:45 +0200
Subject: Re: [USRP-users] Rx sample rate for USRP E310
On 9/5/20 2:59 PM, Ofer Saferman via USRP-users wrote:
Hello,
I am just starting out with the USRP E310 so bare with me.
I am trying to capture samples to file using: ./rx_samples_to_file
--freq 2.4e9 --rate 40e6 --bw 40e6 --gain 30 --nsamps 1000000 --file
samp4.dat
I get the following two warnings during processing:
[WARNING] [RFNOC] [legacy_compat] No FIFO detected. Higher transmit
rates may encounter errors.
Setting RX Rate: 40.000000 Msps...
[WARNING] [MULTI_USRP] The hardware does not support the requested RX
sample rate:
Target sample rate: 40.000000 MSps
Actual sample rate: 16.000000 MSps
Are the warnings related?
I tried various combinations of number of samples bandwidths and sample
rates and can't get more than 16 Msps.
Why can't I get a sample rate of more than 16 MSps?
Any help will be appreciated.
On top of what Marcus said, you need to specify master_clock_rate to set
other rates. 16 MHz is the default master clock rate. If you were able
to stream 40 MHz, you would need to do
./rx_samples_to_file --args master_clock_rate=40e6 [...other args..]
This is also relevant for other sampling rates. For example, 3 Msps is
something the device can handle (maybe even write to SD card), but you
would need a different master clock rate that is an integer multiple,
ideally an even one. In this case, I'd recommend master_clock_rate=12e6
which is 4 times 3. The USRP will engage 2 halfband filters to decimate
the rate. A master clock rate of 3 Msps is theoretically possible, but
not recommended since it will slow down other parts of the chip, too.
The FIFO warning is unrelated. You can ignore that. It should probably
not be there in the first place.
--M
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
On 9/9/20 5:46 AM, Ofer Saferman via USRP-users wrote:
Thank you Marcus and Martin.
Maybe I will try to explain what I am trying to do and you can correct
what I am doing wrong.
I don't want to stream the samples. I understand the limitations of the
ARM processor.
What I would like to do is to record (capture) samples to DDR memory in
real time. Only one block of samples.
Then, write that block, offline, to the SD card as slow as necessary. So
definitely no streaming to SD card.
This should be possible and not related at all to the speed of the ARM
processor. It should be handled by a DMA of the FPGA directly to DDR
memory and the FPGA should be fast enough to handle the task.
Ofer,
UHD won't initiate direct DMA if you do that. Every packet of data
coming from the FPGA needs to go to the CPU first.
If you want your samples to DMA directly to memory, you need to do
something like this: https://www.youtube.com/watch?v=Y8QQ0sh5IhI
rx_samples_to_file is a generic tool that works equally with all USRPs,
regardless of their transport type.
--M
Does the axi_ram_fifo rfnoc block work for the E310 (perhaps in uhd 4.0)?
If so, couldn't you implement an rfnoc graph such as
Radio->axi_ram_fifo->host and then you should be able to capture
250MSamples (1GB) at a time which could be streamed at a slower rate to
host?
Rob
On Wed, Sep 9, 2020 at 3:28 AM Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:
On 9/9/20 5:46 AM, Ofer Saferman via USRP-users wrote:
Thank you Marcus and Martin.
Maybe I will try to explain what I am trying to do and you can correct
what I am doing wrong.
I don't want to stream the samples. I understand the limitations of the
ARM processor.
What I would like to do is to record (capture) samples to DDR memory in
real time. Only one block of samples.
Then, write that block, offline, to the SD card as slow as necessary. So
definitely no streaming to SD card.
This should be possible and not related at all to the speed of the ARM
processor. It should be handled by a DMA of the FPGA directly to DDR
memory and the FPGA should be fast enough to handle the task.
Ofer,
UHD won't initiate direct DMA if you do that. Every packet of data
coming from the FPGA needs to go to the CPU first.
If you want your samples to DMA directly to memory, you need to do
something like this: https://www.youtube.com/watch?v=Y8QQ0sh5IhI
rx_samples_to_file is a generic tool that works equally with all USRPs,
regardless of their transport type.
--M
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
On 9/9/20 3:49 PM, Rob Kossler wrote:
Does the axi_ram_fifo rfnoc block work for the E310 (perhaps in uhd
4.0)? If so, couldn't you implement an rfnoc graph such as
Radio->axi_ram_fifo->host and then you should be able to capture
250MSamples (1GB) at a time which could be streamed at a slower rate to
host?
Unfortunately, no, the PL-DRAM is not exposed to the blocks on the E310
as with the other devices. It's something that could be added in the
future; the decision to not expose the PL-DRAM in the same way as the
other devices predates RFNoC and all that.
--M
Rob
On Wed, Sep 9, 2020 at 3:28 AM Martin Braun via USRP-users
<usrp-users@lists.ettus.com mailto:usrp-users@lists.ettus.com> wrote:
On 9/9/20 5:46 AM, Ofer Saferman via USRP-users wrote:
Thank you Marcus and Martin.
Maybe I will try to explain what I am trying to do and you can correct
what I am doing wrong.
I don't want to stream the samples. I understand the limitations
of the
ARM processor.
What I would like to do is to record (capture) samples to DDR
memory in
real time. Only one block of samples.
Then, write that block, offline, to the SD card as slow as
necessary. So
definitely no streaming to SD card.
This should be possible and not related at all to the speed of the ARM
processor. It should be handled by a DMA of the FPGA directly to DDR
memory and the FPGA should be fast enough to handle the task.
Ofer,
UHD won't initiate direct DMA if you do that. Every packet of data
coming from the FPGA needs to go to the CPU first.
If you want your samples to DMA directly to memory, you need to do
something like this: https://www.youtube.com/watch?v=Y8QQ0sh5IhI
rx_samples_to_file is a generic tool that works equally with all USRPs,
regardless of their transport type.
--M
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com