[USRP-users] NI USRP / PCIe interface and RFNoC FPGA images

[Tarik Kazaz via USRP-users]

Hello everyone,

I am just starting to use RFNoC and I am a bit confused with hardware 
compatibility for RFNoC development.
In order to describe my setup I will list items below:


1.   I have NI USRP RIO (equivalent of X310 with integrated GPS module)

2.   I am connecting it with PC over PCIe interface

I tried to flash USRP with RFNoC usrp_x310_fpga_RFNOC_XG.bit  image. However, 
after I power cycle USRP
and execute uhd_usrp_probe seems that fpga is again flashed with NI USRP as it 
contains only DDCs, DMA and Radio
RFNoC blocks.

In general I am confused what is a right RFNoC image for setup consisting of 
USRP connected with PC over PCIe interface.
Should I use XG RFNoC FPGA images? Are RFNoC images compatible with PCIe 
interface?

Kind Regards,

Tarik
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] NI USRP / PCIe interface and RFNoC FPGA images

[Tarik Kazaz via USRP-users]

le PCIe to reload 
> image.
>
> I think instead of .bit, I should flash it with .lvbit if I want to use USRP
> over PCIe with RFNoC? Or I am wrong.
>
> Kind Regards,
>
> Tarik
>
> -Original Message-
> From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of 
> Martin Braun via USRP-users
> Sent: maandag 29 januari 2018 20:46
> To: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] NI USRP / PCIe interface and RFNoC FPGA images
>
> On 01/29/2018 07:37 PM, Tarik Kazaz via USRP-users wrote:
>> Hello everyone,
>>
>>
>>
>> I am just starting to use RFNoC and I am a bit confused with hardware
>> compatibility for RFNoC development.
>>
>> In order to describe my setup I will list items below:
>>
>>
>>
>> 1.   I have NI USRP RIO (equivalent of X310 with integrated GPS
>> module)
>>
>> 2.   I am connecting it with PC over PCIe interface
>>
>>
>>
>> I tried to flash USRP with RFNoC *usrp_x310_fpga_RFNOC_XG.bit* image.
>> However, after I power cycle USRP
>>
>> and execute *uhd_usrp_probe* seems that fpga is again flashed with NI
>> USRP as it contains *only DDCs, DMA and Radio*
>>
>> *RFNoC blocks*.
>>
>>
>>
>> In general I am confused what is a right RFNoC image for setup
>> consisting of USRP connected with PC over PCIe interface.
>>
>> Should I *use XG RFNoC FPGA images*? Are RFNoC images compatible with
>> PCIe interface?
>
> Yeah, but PCIe does reload images on every run. If you specify 
> fpga=/path/to/rfnoc_image.bit, it'll pick that.
>
>
> -- M
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] NI USRP / PCIe interface and RFNoC FPGA images

[Tarik Kazaz via USRP-users]

Hello Derek,

I got you. Thank you.

I have one more question, where can I specify default bit stream location?

What happen now is that by calling

uhd_usrp_probe –args =”fpga=/path/to/image.lvbitx”

I am able to flash USRP with RFNoC design. However, after I run gnuradio 
fosphor program it again roles
back to previous bitstream. Which is logical based on your advices.

However where can I specify path to default bitstream. In which file I should 
do it?

Thx for comments related to 10Gbe. Then I think we will need to order also 10 
Gbe interface.

Kind Regards,

Tarik Kazaz

From: Derek Kozel [mailto:derek.ko...@ettus.com]
Sent: dinsdag 30 januari 2018 11:50
To: Tarik Kazaz
Cc: Martin Braun; USRP-users@lists.ettus.com
Subject: Re: [USRP-users] NI USRP / PCIe interface and RFNoC FPGA images

Hi Tarik,
Your steps are based on the misunderstanding of how the image loading occurs in 
each of these scenarios.
When using PCIe the FPGA will always be reloaded from the host computer. Every 
program you run using the PCIe link needs the "fpga=/path/to/image.lvbitx" 
string added to the device arguments. The image loading is very fast compared 
to other methods. For example:
uhd_usrp_probe --args="fpga=/path/to/image.lvbitx"
When using JTAG an image is loaded into RAM on the FPGA. This will be 
overwritten if PCIe is used and forgotten (the RAM will clear) when the device 
is turned off. This is useful for rapid testing when using Ethernet connections 
since JTAG is faster than writing to flash, and for recovering when an image 
with an error has been written to the flash.
When using the uhd_image_loader the image is written to flash and will be used 
the next time the device is turned off and on again. This is useful for loading 
a persistent image when using the Ethernet interfaces. PCIe will still load and 
use an image from the host every time.
Can you please try the uhd_usrp_probe with the device arguments specifying the 
FPGA image to use?

As for 2x10 GigE vs PCIe, No, they do not have the same throughput. The PCIe is 
equivalent to 1x 10 GigE. In order to get the full bandwidth of the X3x0, which 
is 2x 200 MS/s on receive, you would need to use both 10 GigE connections.
https://kb.ettus.com/X300/X310#Choosing_a_Host_Interface
Regards,
Derek

On Tue, Jan 30, 2018 at 10:01 AM, Tarik Kazaz via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Hello Martin,

I hope I am replying now correctly (I am using reply all to you and mailing 
list).
I am still not able to flash RFNoC bit stream on FPGA. Here is what I am doing:

1. First step - Check status of device

Call:   uhd_usrp_probe
Output:   [INFO] [X300] Using LVBITX bitfile 
/home/cas-sdr/rfnoc/share/uhd/images/usrp_x310_fpga_XG.lvbitx...
  ...
  |   |   |   RFNoC blocks on this device:
  |   |   |
  |   |   |   * DmaFIFO_0
  |   |   |   * Radio_0
  |   |   |   * Radio_1
  |   |   |   * DDC_0
  |   |   |   * DDC_1
  |   |   |   * DUC_0
  |   |   |   * DUC_1

2. Second step: Load new FPGA image - usrp_x310_fpga_RFNOC_XG.lvbitx:

Call:   uhd_image_loader 
--args="type=x300,RESOURCES=RIO0" --fpga-path="/xyz/xyz/rfnoc/share/uhd/images
 
/usrp_x310_fpga_RFNOC_XG.lvbitx"

Output:
  [INFO] [UHDlinux; GNU C++ version 4.8.4; 
Boost_105400; UHD_4.0.0.rfnoc-devel-409-gec9138eb]
  [INFO] [NIRIO] rpc_client stopping...
  [INFO] [NIRIO] rpc_client stopped.
  [INFO] [NIRIO] rpc_client stopping...
  [INFO] [NIRIO] rpc_client stopped.
  [INFO] [NIRIO] rpc_client stopping...
  [INFO] [NIRIO] rpc_client stopped.
  [INFO] [NIRIO] rpc_client stopping...
  [INFO] [NIRIO] rpc_client stopped.
  Unit: USRP X310 (3114FC4, RIO0)
  FPGA Image: 
/xyz/xyz/rfnoc/share/uhd/images/usrp_x310_fpga_RFNOC_XG.lvbitx
  -- Loading XG FPGA image (this will take 5-10 
minutes)...[INFO] [NIRIO] rpc_client stopping...
  [INFO] [NIRIO] rpc_client stopped.

  After few minutes I get:
  successful.
  Power-cycle the USRP X310 to use the new 
image.
  

Re: [USRP-users] NI USRP / PCIe interface and RFNoC FPGA images

[Tarik Kazaz via USRP-users]

Hello Derek,

I managed to specify custom bistream file by editing one of uhd source files ( 
“/rfnoc/src/uhd/host/build/lib/transport/nirio/lvbitx/x310_lvbitx.cpp”)
Changing line 50 to
std::string fpga_file = “usrp_x310_fpga_RFNOC_” + option + “.lvbitx”;

and then calling in folder “/rfnoc/src/uhd/host/build$”

make
make install

in order to compile new code.

In this way I redirected path to RFNOC bitstream.

Thank you for your help.
Indeed I think this is really confusing. Based on documentation, I could not 
figure out what is going on.
I think it would be good to be able to specify path to bit stream as parameter 
in gnuradio-companion.

Thank you agin,

Tarik




From: Derek Kozel [mailto:derek.ko...@ettus.com]
Sent: dinsdag 30 januari 2018 14:33
To: Tarik Kazaz
Cc: Martin Braun; USRP-users@lists.ettus.com
Subject: Re: [USRP-users] NI USRP / PCIe interface and RFNoC FPGA images

Hi Tarik,
The USRP source in GNU Radio has a spot for specifying device arguments. The 
osmocom_fft application has a "--args" option the same as the UHD utilities. 
There is not currently the ability to specify a custom default FPGA image but 
it is a feature we agree would be useful.
Regards,
Derek

On Tue, Jan 30, 2018 at 12:24 PM, Tarik Kazaz 
mailto:t.ka...@tudelft.nl>> wrote:
Hello Derek,

I got you. Thank you.

I have one more question, where can I specify default bit stream location?

What happen now is that by calling

uhd_usrp_probe –args =”fpga=/path/to/image.lvbitx”

I am able to flash USRP with RFNoC design. However, after I run gnuradio 
fosphor program it again roles
back to previous bitstream. Which is logical based on your advices.

However where can I specify path to default bitstream. In which file I should 
do it?

Thx for comments related to 10Gbe. Then I think we will need to order also 10 
Gbe interface.

Kind Regards,

Tarik Kazaz

From: Derek Kozel [mailto:derek.ko...@ettus.com<mailto:derek.ko...@ettus.com>]
Sent: dinsdag 30 januari 2018 11:50
To: Tarik Kazaz
Cc: Martin Braun; USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>

Subject: Re: [USRP-users] NI USRP / PCIe interface and RFNoC FPGA images

Hi Tarik,
Your steps are based on the misunderstanding of how the image loading occurs in 
each of these scenarios.
When using PCIe the FPGA will always be reloaded from the host computer. Every 
program you run using the PCIe link needs the "fpga=/path/to/image.lvbitx" 
string added to the device arguments. The image loading is very fast compared 
to other methods. For example:
uhd_usrp_probe --args="fpga=/path/to/image.lv<http://image.lv>bitx"
When using JTAG an image is loaded into RAM on the FPGA. This will be 
overwritten if PCIe is used and forgotten (the RAM will clear) when the device 
is turned off. This is useful for rapid testing when using Ethernet connections 
since JTAG is faster than writing to flash, and for recovering when an image 
with an error has been written to the flash.
When using the uhd_image_loader the image is written to flash and will be used 
the next time the device is turned off and on again. This is useful for loading 
a persistent image when using the Ethernet interfaces. PCIe will still load and 
use an image from the host every time.
Can you please try the uhd_usrp_probe with the device arguments specifying the 
FPGA image to use?
As for 2x10 GigE vs PCIe, No, they do not have the same throughput. The PCIe is 
equivalent to 1x 10 GigE. In order to get the full bandwidth of the X3x0, which 
is 2x 200 MS/s on receive, you would need to use both 10 GigE connections.
https://kb.ettus.com/X300/X310#Choosing_a_Host_Interface
Regards,
Derek

On Tue, Jan 30, 2018 at 10:01 AM, Tarik Kazaz via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Hello Martin,

I hope I am replying now correctly (I am using reply all to you and mailing 
list).
I am still not able to flash RFNoC bit stream on FPGA. Here is what I am doing:

1. First step - Check status of device

Call:   uhd_usrp_probe
Output:   [INFO] [X300] Using LVBITX bitfile 
/home/cas-sdr/rfnoc/share/uhd/images/usrp_x310_fpga_XG.lvbitx...
  ...
  |   |   |   RFNoC blocks on this device:
  |   |   |
  |   |   |   * DmaFIFO_0
  |   |   |   * Radio_0
  |   |   |   * Radio_1
  |   |   |   * DDC_0
  |   |   |   * DDC_1
  |   |   |   * DUC_0
  |   |   |   * DUC_1

2. Second step: Load new FPGA image - usrp_x310_fpga_RFNOC_XG.lvbitx:

Call:   uhd_image_loader 
--args="type=

[USRP-users] USING USRP Xseries as clock master

[Tarik Kazaz via USRP-users]

Hello everyone,

I am considering to synchronize several USRPs Xseries. However, I have only one 
device with integrated
GPS disciplined oscillator.

I am wondering whether it is possible to use the device with GPS disciplined  
oscillator as a master clock source?

What is the output of REF Out port on USRP Xseries devices (is  it 10MHz or PPS 
signal generated by GPSDO or some
other configurable signal generated from fpga)?

Kind Regards,

Tarik

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] RF_NoC fosphor issue (Source IO size "8" does not match sink IO size "8192".)

[Tarik Kazaz via USRP-users]

Hi All,


I am using USRP X310 with UBX-160MHz. I tried to run RFNoC fosphor demo, 
however I am getting errors related to connection of RFNoC:Radio to RFNoC: DDC 
and to RFNoC:Window (Source IO size "8" does not match sink IO size "8192"). I 
found this discussion on mailing list (from 2016) 
https://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00366.html. 
However, I did not manage to make it work.


Could you please provide me more information which modifications I should do in 
order to make it work?


KInd Regards
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] RF_NoC fosphor issue (Source IO size "8" does not match sink IO size "8192")

[Tarik Kazaz via USRP-users]

Hi All,

I am using USRP X310 with UBX-160MHz. I tried to run RFNoC fosphor demo, 
however I am getting errors related to connection of RFNoC:Radio to RFNoC: DDC 
and to RFNoC:Window (Source IO size "8" does not match sink IO size "8192"). I 
found this discussion on mailing list (from 2016) 
https://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00366.html. 
However, I did not manage to make it work.

Could you please provide me more information which modifications I should do in 
order to make it work?

KInd Regards

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RF_NoC fosphor issue (Source IO size "8" does not match sink IO size "8192".)

[Tarik Kazaz via USRP-users]

Hi Nate,

Now after I did those changes it looks much better. However, seems still there 
is kind of mirrored spectrum on fosphor plot.
I just did simple test with transmitting signal from Zigbee sensor device. 
Seems signal is mirrored on plot. I will check more tomorrow,
and will let you know.

Thanks,

Tarik



From: Nate Temple [mailto:nate.tem...@ettus.com]
Sent: maandag 19 maart 2018 17:54
To: Tarik Kazaz
Subject: Re: [USRP-users] RF_NoC fosphor issue (Source IO size "8" does not 
match sink IO size "8192".)

Hi Tarik,

Can you please try rebuilding uhd/rfnoc-devel and gr-ettus based off of these 
commits:

https://github.com/EttusResearch/uhd/commit/12a34d6ef6b9666e29a23039291138f989c7c2ce
https://github.com/EttusResearch/gr-ettus/commit/30302780a44f3f0b146e9b81f88e70c9d983f559

We have an issue on our internal bug tracker already for this specific bug with 
the plots.

Regards,
Nate Temple

On Mon, Mar 19, 2018 at 9:37 AM, Tarik Kazaz 
mailto:t.ka...@tudelft.nl>> wrote:
Hi Nate,

I was avoiding  error by pressing F6. However results that I observe on fosphor 
plot are a bit strange.
Seems spectrum and spectrogram plots are divided in two plots? Also scaling of 
signal seems to be wrong.
I am sending signal of 2MHZ however it seems to be 20MHz on plot.

Is bypass good solution to this issue?

Kind Regards,



From: Nate Temple [mailto:nate.tem...@ettus.com<mailto:nate.tem...@ettus.com>]
Sent: maandag 19 maart 2018 17:24
To: Tarik Kazaz
Cc: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RF_NoC fosphor issue (Source IO size "8" does not 
match sink IO size "8192".)

Hi Tarik,

If you press "F6" instead of the "Run" button, it will bypass this warning and 
run the flowgraph.

Regards,
Nate Temple

On Mon, Mar 19, 2018 at 8:59 AM, Tarik Kazaz via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Hi All,



I am using USRP X310 with UBX-160MHz. I tried to run RFNoC fosphor demo, 
however I am getting errors related to connection of RFNoC:Radio to RFNoC: DDC 
and to RFNoC:Window (Source IO size "8" does not match sink IO size "8192"). I 
found this discussion on mailing list (from 2016) 
https://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00366.html. 
However, I did not manage to make it work.



Could you please provide me more information which modifications I should do in 
order to make it work?



KInd Regards

___
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


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Streaming and storing signals of full BW of 2x UBX-160 cards to PC in file

[Tarik Kazaz via USRP-users]

Dear All,

We are working on prototyping Signal Processing Algorithms for Radar and 
localization scenarios (wideband signals).
At the moment we are setting up the testbed for testing our algorithms. We are 
interested in the streaming and storing of high data rate
samples full bandwidth of 2x 160 MHz UBX cards to the file in PC. Later on, we 
would perform offline processing of those samples.

We managed to find several posts related to the similar work. However, we did 
not manage to find concrete suggestions or reference guideline
how to setup system that is able to perform offline acquisition of full 
bandwidth signals supported by 2xUBX-160 cards in PC.

Our questions is directed to Ettus Research developers and anyone who was 
trying to achieve same:

1. What is hardware configuration for the PC in order to support streaming and 
storing of samples from 2xUBX-160 cards  (2(cards)x2(IQ)x160(BW)x8(sample 
size)) to SSD memory?
2. Did you in Ettus tried to do a similar experiment and could you provide us 
references for HW and SW configurations?

Our testbed at the moment consists of:

1. PC (Dell Precision Tower 5810 - 
https://www.dell.com/en-ca/work/shop/dell-desktops-workstations/dell-precision-tower-5810-workstation-build-your-own/spd/precision-t5810-workstation/cup5810onca):
RAM: 4x4GB 
(https://www.micron.com/parts/modules/ddr4-sdram/mta9asf51272pz-2g3) (This we 
could also extend to 32GB or 64GB)

CPU:  Intel Xeon - Intel Xeon Processor E5-1620 v3 (4C, 3.5GHz, Turbo, HT, 
10M, 140W)

SSD:  skhynix 512GB, 2.5'', Read : up to 550MB/s, Write : up to
 480MB/s. (http://ssd.skhynix.com/ssd/en/about/sc300a.jsp) (this we 
plan to extend and maybe change as writing speed is low and capacity is low. Do 
you have a recommendation   for SSD configuration ?)

2. USRP X310
 RF DaugtherBoard: 2x UBX-160MHz
 PC-USRP interface: 2x10GB ethernet interface

Thank you in advance on comments and suggestions,


Tarik



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Streaming and storing signals of full BW of 2x UBX-160 cards to PC in file

[Tarik Kazaz via USRP-users]

Hi All,

I did further research on issues related to streaming and storing IQ samples 
from USRP X310 (with UBX-160)  sampling at 200Msps to PC.
The connection between USRP X310 and PC would be over two (2) 10 Gigabit 
Ethernet interface.

Based on my calculations writing speed to the memory of PCs should be:

DataRate_of_two_streams = 2(RF_cards) x 2(IQ) x 200 Msps x 16 (bits) = 
12800Mbps  = 12.8 Gbps = 1.6GBps =>

(taking into account computer science definition of 1GB = 1024^3 bits)

ð  1600MB/s = 1.5625GB/s

These data rates are huge for regular SSDs. As possible solutions I found that 
PC with:

1.   PCIe/NVMe SSDs

2.   RAM Disks
could support these data rates.

First solution seems to be better in terms of the capacity as we would like to 
be able to store signals during 5-10 min time interval.
This would require around 1TB capacity. I found that SAMSUNG NVMe SSDs (at 
least based on specification) could support these data rates:


1.   SSD 960 PRO NVMe M.2 2TB (Sequential writing speed is 2,100 MB/s) 
(https://www.samsung.com/us/computing/memory-storage/solid-state-drives/ssd-960-pro-m-2-2tb-mz-v6p2t0bw/)

2.   SSD 970 PRO NVMe M.2 1TB (Sequential writing speed is 2,700 MB/s) 
(https://www.samsung.com/us/computing/memory-storage/solid-state-drives/ssd-970-pro-nvme-m2-1tb-mz-v7p1t0bw/)

3.   SSD 970 EVO NVMe M.2 2TB (Sequential writing speed is 2,500 MB/s) 
(https://www.samsung.com/us/computing/memory-storage/solid-state-drives/ssd-970-evo-nvme-m2-2tb-mz-v7e2t0bw/)


Does anyone has experience with similar set-up? Did you guys from Ettus perform 
similar experiments?
We would be grateful for any advice or opinion on these issues.

Cheers,

Tarik



From: Tarik Kazaz
Sent: maandag 25 juni 2018 15:07
To: 'usrp-users@lists.ettus.com'
Subject: Streaming and storing signals of full BW of 2x UBX-160 cards to PC in 
file

Dear All,

We are working on prototyping Signal Processing Algorithms for Radar and 
localization scenarios (wideband signals).
At the moment we are setting up the testbed for testing our algorithms. We are 
interested in the streaming and storing of high data rate
samples full bandwidth of 2x 160 MHz UBX cards to the file in PC. Later on, we 
would perform offline processing of those samples.

We managed to find several posts related to the similar work. However, we did 
not manage to find concrete suggestions or reference guideline
how to setup system that is able to perform offline acquisition of full 
bandwidth signals supported by 2xUBX-160 cards in PC.

Our questions is directed to Ettus Research developers and anyone who was 
trying to achieve same:

1. What is hardware configuration for the PC in order to support streaming and 
storing of samples from 2xUBX-160 cards  (2(cards)x2(IQ)x160(BW)x8(sample 
size)) to SSD memory?
2. Did you in Ettus tried to do a similar experiment and could you provide us 
references for HW and SW configurations?

Our testbed at the moment consists of:

1. PC (Dell Precision Tower 5810 - 
https://www.dell.com/en-ca/work/shop/dell-desktops-workstations/dell-precision-tower-5810-workstation-build-your-own/spd/precision-t5810-workstation/cup5810onca):
RAM: 4x4GB 
(https://www.micron.com/parts/modules/ddr4-sdram/mta9asf51272pz-2g3) (This we 
could also extend to 32GB or 64GB)

CPU:  Intel Xeon - Intel Xeon Processor E5-1620 v3 (4C, 3.5GHz, Turbo, HT, 
10M, 140W)

SSD:  skhynix 512GB, 2.5'', Read : up to 550MB/s, Write : up to
 480MB/s. (http://ssd.skhynix.com/ssd/en/about/sc300a.jsp) (this we 
plan to extend and maybe change as writing speed is low and capacity is low. Do 
you have a recommendation   for SSD configuration ?)

2. USRP X310
 RF DaugtherBoard: 2x UBX-160MHz
 PC-USRP interface: 2x10GB ethernet interface

Thank you in advance on comments and suggestions,


Tarik



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Streaming and storing signals of full BW of 2x UBX-160 cards to PC in file

[Tarik Kazaz via USRP-users]

Hi Marcus,

Thank you for your comments, although this scares me a bit. 
Obviously storing samples at 1.6 GB/s will not be easy to achieve, or at least 
it is not straightforward.
I will wait a bit with further responses, I hope that someone else tried to do 
same. 

Is it possible to use Dual 10Gbe connection towards two PCs (splitting single 
connection towards separate PCs)? 

What I mean with this is to:
stream  IQ samples from one ADC0 (UBX0) to one PC at 0.8 GB/s and 
stream IQ samples from another ADC1(UBX1) to another PC at 0.8 GB/s.

Maybe my idea is not valid, however might be solution.
Probably in this case there will be miss-alignment between samples stored at 
separate NVMe SSDs. 


Kind Regards,

Tarik



-Original Message-
From: Marcus Müller [mailto:marcus.muel...@ettus.com] 
Sent: woensdag 27 juni 2018 11:23
To: Tarik Kazaz; 'usrp-users@lists.ettus.com'
Subject: Re: [USRP-users] Streaming and storing signals of full BW of 2x 
UBX-160 cards to PC in file

Hi Tarik,

I didn't try to continously stream to storage of dual-channel full-rate 
X3x0 recordings myself, but I do have some experience to share;
hopefully it helps more than it scares.

* Even NVMe SSDs aren't uniform in access latency and write speed. So,
make sure your write rate is *reliably* above 1.6 GB/s
  * A marketing 2100MS/s write speed is what you'll get on average;
you'd need that on "short-term minimum", with "short" being defined by
how well your OS buffers writes in RAM.
  * A quick research on some "SSD user benchmarking" sites revealed the
Samsung 970 PRO 1TB would indeed do more than 2.1 GB/s write speed –
but only on strictly size-limited sequential writes, so you definitely
don't want a journaling file system on the same device, or do
*anything* with the SSD at the same time as storing samples. (Same site
says "sustained write 1.5 GB/s", so, it really doesn't work out with
but one of these)
  * Gut feeling: Get more CPU cores, probably more RAM for the
buffering to compensate instantaneous write speed differences, and
build a software RAID 0 out of at least two of these PCIe SSDs, or out
of >> four SATA SSDs

* Storage subsystems usually aren't safe from preemption; you'll need
to make sure that you have enough buffer to write things to while your
storages system catches up after an interruption. Luckily, you can
teach for example Linux how much storage write it is allowed to buffer
into RAM before it starts blocking

* 2x200 MS/s vs Quad-Core: that's a lot of packets per second that
you're trying to juggle with only four cores at 2.8 GHz, considering
these cores handle the network packets, the unpacking of the samples
from these, the file writing and the file system as well as storage
interfacing.

* 16 GB RAM is certainly at the lower end of what I'd expect of a high-
bandwidth storage system/workstation, but I don't think you'll need
much more – after all, that's quite a lot of buffer (i.e. let's say 8s
worth of samples, if you subtract all the RAM requirements of OS and
applications that don't go into write buffering). Looking at the price
of Dell's ECC RAM: you can probably live with some bit error
probabilities in the 2e-11/bit/hr range (which I think is what's
estimated for modern RAM) for noisy data without any problem, so ECC
possibly isn't important here (but I don't know your operational
requirements! So take with a grain of salt). The fact that you
constantly overwrite with fresh values and thus most bits are probably
shorter stored in RAM than one DRAM refresh cycle would be anyway does
probably help physically, too.

Best regards,
Marcus

On Wed, 2018-06-27 at 08:30 +, Tarik Kazaz via USRP-users wrote:
> Hi All,
>  
> I did further research on issues related to streaming and storing IQ
> samples from USRP X310 (with UBX-160)  sampling at 200Msps to PC.
> The connection between USRP X310 and PC would be over two (2) 10
> Gigabit Ethernet interface.
>  
> Based on my calculations writing speed to the memory of PCs should
> be:
>  
> DataRate_of_two_streams = 2(RF_cards) x 2(IQ) x 200 Msps x 16 (bits)
> = 12800Mbps  = 12.8 Gbps = 1.6GBps =>
>  
> (taking into account computer science definition of 1GB = 1024^3
> bits)
> ð  1600MB/s = 1.5625GB/s
>  
> These data rates are huge for regular SSDs. As possible solutions I
> found that PC with:
> 1.   PCIe/NVMe SSDs
> 2.   RAM Disks
> could support these data rates.
>  
> First solution seems to be better in terms of the capacity as we
> would like to be able to store signals during 5-10 min time interval.
> This would require around 1TB capacity. I found that SAMSUNG NVMe
> SSDs (at least based on specification) could support these data
> rates:
>  
> 1.   SSD 960 PRO NVMe M.2 2TB (Sequenti

Re: [USRP-users] RFNoC FIR filter block - filter taps

[Tarik Kazaz via USRP-users]

Hi Nives,

It is not clear for me what is your issue. However, based on what you have 
wrote I think you have issue with
Implementing and understanding decimation.

Here is short explanation what is decimation. With decimation of digital signal 
you are removing some samples
of your signal in order to decrease its sampling rate. What you are achieving 
is reduction of your sampling rate.
Easiest to explain would be decimation by 2. Imagine you have signal that you 
sample at 16MHz so you get 16 Msps
and in your processing chain you would like to decrease its sampling rate to 8 
Msps. What you want to do is to decimate it
by 2.
Imagine you represent certain period of your signal (T) as vector of samples :
x = [1, 2,  3,  4,  5, 6, 7, 8]

Then signal decimated by 2 would be:
x_2d = [1, 3, 5, 7]

So basically you have removed every second sample from your original signal and 
you have reduced its sampling rate.
This should be easy to implement in FPGA by mapping two shift registers. Or you 
could use some of Xilinx IP cores.

However you should be careful when you do decimation. When bandwidth of your 
signal is not small enough direct decimation
will cause aliasing of your signal. In order to avoid this  before you do 
decimation you should band limit your signal by low pass filter.

In order to understand these concepts. I would advise you to read some DSP 
book. 
(https://www.amazon.com/Understanding-Digital-Signal-Processing-3rd/dp/0137027419/ref=sr_1_1?ie=UTF8&qid=1530806535&sr=8-1&keywords=understanding+dsp)

Good Luck,
Tarik






From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of Nives 
Novkovic via USRP-users
Sent: donderdag 5 juli 2018 17:37
To: Marcus D. Leech
Cc: USRP-users@lists.ettus.com
Subject: Re: [USRP-users] RFNoC FIR filter block - filter taps

Thank you for the tip, I have found this tool for easy FIR filter design: 
http://t-filter.engineerjs.com/ . What I am trying to achieve here is to get 
the same output signal from RFNoC FIR filter as I am currently getting from a 
design that is running purely on CPU using the low pass filter block in GNU 
radio. That block has the option to account a parameter called "decimation". 
Does anybody know how can I implement that parameter in RFNoC FIR filter block 
design?
Kind regards,
Nives

pon, 2. srp 2018. u 16:02 Marcus D. Leech 
mailto:mle...@ripnet.com>> napisao je:
On 07/02/2018 07:33 AM, Nives Novković wrote:

Hi Marcus,

Thank you for your answer, since I am quite new in this area I didn't 
understand how to figure out which coefficients to enter. For example, if I 
want to pass a signal only between 200 and 300 kHz, which coefficients should I 
use?
Kind regards,
Nives

You'll need to use a filter design tool, like the FIRDES routines in Gnu Radio, 
or the external filter designer or some other tool.

https://www.allaboutcircuits.com/technical-articles/finite-impulse-response-filter-design-by-windowing-part-i-concepts-and-rect/





---
Message: 5
Date: Tue, 19 Jun 2018 14:04:40 -0400
From: "Marcus D. Leech" mailto:mle...@ripnet.com>>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] RFNoC FIR filter block - filter taps
Message-ID: <5b2945b8.1080...@ripnet.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

The RFNoC FIR filter takes a list of ints that can be scaled from a
floating-point representation of the filter.

Gnu Radio includes the firdes routines for producing coefficients for
simple low-pass/high-pass/band-pass filters.  One you have the results,
you can just use a simple Python expression to scale by 32767.0 and
convert to int.   Something like:

  [int(i*32767) for i in filter_coeffs]

Keep in mind that the RFNoC FIR filter is, last I checked, limited to 41
filter coefficients
On 06/19/2018 10:28 AM, Nives Novkovi? via USRP-users wrote:
> Hi everyone,
>
> me again with the questions. :) Next thing I am trying to learn is
> RFNoC FIR filter. I see that the only thing I can modify for the
> filter is filter taps. Is there any official documentation on those
> blocks? I am trying to figure out what values should I enter there if,
> i.e. I want to eliminate all the frequencies above 100 kHz. Those are
> actually coefficients in the FIR filter equation? Here is my current
> flow graph.
>
>
> fir_filter_flow_grc.png
>
> Kind regards,
> Nives
>
>

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Detecting and sampling short bursts of signals at full sampling rate of USRP X310 for longer period of time

[Tarik Kazaz via USRP-users]

Hi All,

I am giving up hope of sampling signals of full BW of two UBX-160 cards, and 
storing those streams in the PC.
Based on my calculations (one of the previous posts) in order to be able to do 
that I would need to write to
memory with the speed of 1.6GBps.

However, now I am interested in sampling short bursts of signals with the full 
bandwidth of USRP x310 (so 2(cards)x2(IQ)x200MSPs)
and then storing them into PC memory for the period of 10 minutes.

The idea would be to stream bursty signal when the signal is in the air.

For this, I would probably need to have some sort of energy detector in the 
FPGA. The idea would be that energy detector signalizes when the

signal is in the air and to trigger streaming samples towards PC.


In this way, I would try to lower requirements on the speed of memory write in 
the PC.

Does anyone have experience with doing the same?

Previously, I was interested in the possibility to connect single USRP-X310 to 
two separate PCs over 10GBe interfaces
 (to split dual 10GBe connection to two PCs with NVMe SSDs). In that way, there 
would be a possibility to lower down
requirements on memory writing speed to 0.8GBps. These memory writing speeds 
should be supported by modern
NVMe SSDs. Probably this is not straightforward to achieve as I did not get too 
many replies on my previous post. More details about

my previous posts are available here 
https://www.mail-archive.com/usrp-users@lists.ettus.com/msg05579.html.


Cheers,
Tarik
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Detecting and sampling short bursts of signals at full sampling rate of USRP X310 for longer period of time

[Tarik Kazaz via USRP-users]

Hi Derek,


Thank you for the advice and comments. So UHD requires connection of Dual 10GBe 
interface to

single PC.


I have experience with FPGA and debugging. However, I did not explore RFNoC 
FPGA design (I did read few papers about RFNoC).

If it really complicated I would like to avoid implementing signal detection 
there.


However, I am still wondering will PC be able to process 400Msps of data in 
burst mode.

Did you guys do similar experiments at ettus?


What we want is to test our signal processing algorithm for localization. For 
that, we transmit wideband signals

(of 320MHz, two UBX card are stitched together) from several anchor nodes to 
the mobile node which we want to

localize (this node also has USRP X310 with two UBX cards).


While sending signals from 320 MHz from anchor should not cause us issues (as 
signals are same all the time,so we can store it in USRP itself).

I am worried how PC and USRP will behave in case of the receiver (mobile node) 
as there we need to us PC to store our samples.


Kind Regards,


Tarik




From: Derek Kozel 
Sent: Monday, July 9, 2018 12:37:16 PM
To: Tarik Kazaz
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Detecting and sampling short bursts of signals at 
full sampling rate of USRP X310 for longer period of time

Hello Tarik,

Just stepping in to respond that UHD does not support splitting the 10 GigE 
interfaces to two computers.

The X310 supports RFNoC which you could use to create an energy detection block 
which only streams samples back to the computer when your criteria are met. 
However it is likely simplest for you to do the energy detection on the host 
computer, streaming the full bandwidth to the computer but then only saving 
samples long term if your detector identifies a signal of interest. Host coding 
is almost invariably faster and simpler to debug than FPGA code, though of 
course there are cases where putting processing in the FPGA is either more 
efficient or provides unique benefits. In this case you could see some very 
good efficiency benefits if the FPGA DSP could limit the number of samples that 
are actually sent to the host, but it is an efficiency gain you likely don't 
need.

Regards,
Derek



On Mon, Jul 9, 2018 at 11:01 AM, Tarik Kazaz via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Hi All,

I am giving up hope of sampling signals of full BW of two UBX-160 cards, and 
storing those streams in the PC.
Based on my calculations (one of the previous posts) in order to be able to do 
that I would need to write to
memory with the speed of 1.6GBps.

However, now I am interested in sampling short bursts of signals with the full 
bandwidth of USRP x310 (so 2(cards)x2(IQ)x200MSPs)
and then storing them into PC memory for the period of 10 minutes.

The idea would be to stream bursty signal when the signal is in the air.

For this, I would probably need to have some sort of energy detector in the 
FPGA. The idea would be that energy detector signalizes when the

signal is in the air and to trigger streaming samples towards PC.


In this way, I would try to lower requirements on the speed of memory write in 
the PC.

Does anyone have experience with doing the same?

Previously, I was interested in the possibility to connect single USRP-X310 to 
two separate PCs over 10GBe interfaces
 (to split dual 10GBe connection to two PCs with NVMe SSDs). In that way, there 
would be a possibility to lower down
requirements on memory writing speed to 0.8GBps. These memory writing speeds 
should be supported by modern
NVMe SSDs. Probably this is not straightforward to achieve as I did not get too 
many replies on my previous post. More details about

my previous posts are available here 
https://www.mail-archive.com/usrp-users@lists.ettus.com/msg05579.html.


Cheers,
Tarik

___
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


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com