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] UHD Python API (was: Query regarding connection of usrp)

[Marcus Müller via USRP-users]

Hi Kirthana,

yes, Ettus just announced that API! For much more info, see:

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-June/0
57034.html

You will need to build UHD yourself with the mentioned flags to get it.

However, it'll be a little bit harder than necessary to get it to build
on such an old operating system; you'll need some modern dependencies,
and I don't know if everything you need can easily be installed through
apt-get on Ubuntu 14.04, or whether you'll need to fiddle with prefix
installations; 14.04 is just... old.

I *think* it should work out with a few hacks to build modern UHD on
old Ubuntu, but really, that's avoidable:
Ubuntu 14.04LTS isn't really the greatest thing to start development on
mid-2018. Unless you have *very* important reasons to stay on that
kind-of-ancient release, I'd recommend upgrading to Ubuntu 18.04, which
itself is a long-term support release, and thus officially supersedes
14.04.

Hope this helps,
best regards,
Marcus

On Wed, 2018-06-27 at 11:25 +0530, Kirthana Rao via USRP-users wrote:
> Respected Members
> 
> I have a query regarding the uhd software , is there any python api
> for uhd. If so please guide me about the installation of the same on
> ubuntu 14.04.Thanks in advance.
> 
> 
> ___
> 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] Streaming and storing signals of full BW of 2x UBX-160 cards to PC in file

[Marcus Müller via USRP-users]

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 (Sequential writing speed is 2,100
> MB/s) (https://www.samsung.com/us/computing/memory-storage/solid-stat
> e-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-stat
> e-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-stat
> e-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 

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 (Sequential writing speed is 2,100
> MB/s) (https://www.samsung.com/us/computing/memory-storage/solid-stat
> e-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/co

[USRP-users] Octoclock support page missing links

[Alejandra Mercado via USRP-users]

Dear USRP folks,

I've just unpackaged an OctoClock-G CDA-2990. I googled instructions in the
Ettus web page: https://kb.ettus.com/OctoClock_CDA-2990

However, the part I was most interested in does not have any links:

   - *Where can I find user manuals for the OctoClock and USRP*

Here is helpful document. Sync. and MIMO w/ the USRP

Also, here is some documentation on how to use UHD™ to interact with
multi-USRP systems.
Any idea where I can get tutorials or user manuals for a beginner?

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

Re: [USRP-users] Synchronizing multiple B205 mini radios

[Chintan Patel via USRP-users]

Ian,

We are using multiple B210 radios. We are monitoring two PPS signal (one
per radio) reclocked in the radio/sample clk domain on the scope. So
essentially, we are indirectly monitoring the radio clk/sample clk from two
different B210s, which always seem phase aligned over multiple reboots.

But given everything I now know about MCS, I am beginning to doubt the
measurements and will repeat.

Thanks
Chintan


On Tue, Jun 26, 2018 at 2:09 PM, Ian Buckley  wrote:

> Chintan,
> When you refer to lab trial’s with B210…I’m assuming you were using
> multiple B210’s rather than demonstrating coherence of the 2 channels on a
> singe B210?
> How were you verifying that the sample clocks were aligned? Can you share
> your rough configuration?
> If you are using a common PPS to sync time on multiple REF locked B210’s
> then the FPGA’s will be operating coherently with the caveat that they are
> clocked with the divided BBPLL clock (a.k.a master_clock_rate). If you are
> running master_clock_rate at a relatively high value and doing significant
> decimation to the ultimate sample_rate on B210, then a residual phase
> ambiguity on the BBPLL might start to be hard to observe just looking at
> output samples.
> -Ian
>
> On Jun 26, 2018, at 2:42 AM, Chintan Patel  wrote:
>
> Hi Ian, Robin, Marcus
>
> Thanks a lot for your help so far. Three more questions/clarifications:
>
> 1. For the B205 Multi-chip sync (MCS), we are trying to achieve, we are
> actually providing an external stable 40MHz clock common to both B205s.
> i.e. we have re-worked the boards so that the DPLL is not being used at all
> to drive the CLK_40MHz_FPGA to the FPGA input - instead a shared
> very-stable 40MHz clock input it.
>
> 2. Sounds like along with this, the sync_in pin into the AD9364/9361 needs
> to be driven correctly to both B2xx radios. I see that for the B205mini
> this pin is grounded, while the B210 it goes to the FPGA - which would
> explain the MCS capability of the B210. What confuses me, is that the stock
> FPGA image for B210 drives the sync_in input to 0. So, I don't understand
> why we see phase aligned  sample clocks on the B210 in our lab trials. I
> think the FPGA changes Ian refers to that he needed to make MCS work for
> B210 must be related to driving this sync_in pin - but we are just using
> the stock FPGA image, so scratching my head on that one.
>
> 3. Lastly, seems like there is a software routine to be called too, for
> the AD936 MCS. ( ad9361_multichip_sync.c
> 
>  per https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms5
> -ebz/multi-chip-sync). Theoretically, if one is able to rework the
> B205mini so that the sync_in pin goes to the FPGA (not practical I know), I
> assume there will be a similar routine needed for ad9364_multichip_sync.
>
> Thanks again for your continued guidance.
>
> Chintan
>
>
>
> On Tue, Jun 26, 2018 at 12:31 AM, Ian Buckley via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Robin,
>> that ADI support thread is not applicable to B2x0, it’s for AD9361
>> external LO mode which isn’t used by Ettus products.
>>
>> In internal LO mode there is always a phase ambiguity in the RF
>> synthesizers that requires higher level S/W to calibrate and correct for.
>> The baseband synthesizer can be made phase coherent between multiple
>> AD936x’s if you use the MCS mechanism, however that’s not included in the
>> factory FPGA image, (though I have used it in custom images) so you also
>> see some phase ambiguity here too between REF locked USRP's
>> -Ian
>>
>>
>> On Jun 25, 2018, at 9:15 PM, Robin Coxe via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> Marcus is correct and the schematics do in fact provide the answer.
>>
>> Please refer to p.1 of the B210 schematic.  It contains an ADF4002 analog
>> PLL.
>> The B200mini clocking circuitry is on p. 4 of the schematic.  The PLL is
>> digital and implemented inside the FPGA.
>>
>> There is a divide-by-2 for the external LO input in the AD9361/AD9364
>> RFIC that can result in a 180 degree phase ambiguity.   More details here
>> provided by my former colleague at ADI also named Robin:
>> https://ez.analog.com/thread/73543?commentID=225150#comment-225150
>>
>>
>> -Robin
>>
>>
>> On Mon, Jun 25, 2018 at 9:07 PM, Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 06/25/2018 11:57 PM, Dan CaJacob wrote:
>>>
>>> Without looking at the schematic, I'd guess that the difference is in
>>> the implementation of the PLLs for tracking.
>>>
>>> On Mon, Jun 25, 2018 at 11:21 AM Chintan Patel via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hi Marcus,

 Two follow-up questions related to B205/B210 synchronization.

 1. What is the fundamental reason why B210 supports phase coherent
 sync across multiple devices and B205 does not. The reference manuals on
 the AD9364/AD9361 does not point

[USRP-users] rfnoc-devel versus master for RFNoC development

[Rob Kossler via USRP-users]

Hi,
I am doing RFNoC development for the N310 and it is not clear to me why I
would want to use rfnoc-devel as opposed to master.  I know that the RFNoC
getting started guide talks about using rfnoc-devel, but I would still like
to understand better why I should be using that instead of master and
whether the two branches are going to continue for a while or be merged
such that rfnoc-devel is removed.

Thanks.

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

[USRP-users] Multi-usrp Threads

[Keith k via USRP-users]

Hello all

When a multi-usrp object is first created, what purpose do the created
threads serve? I'm just curious on their role, what kind of cpu utilization
they need, and what level of cpu priority they need if the computer is
under heavy load. Thanks.

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

[USRP-users] N310 with rfnoc-devel branch

[Rob Kossler via USRP-users]

Hi,
I am getting some unexpected behavior from my N310 using the example
'tx_waveforms' utility and stock FPGA image using 'rfnoc-devel'.  If I
simply switch to 'maint', things behave as expected.  Here are the issues...

   1. With 'rfnoc-devel', it is necessary for me to specify a subdev spec
   (A:0 A:1 B:0 B:1) in order to access all 4 channels. Otherwise, I can only
   see 2 channels. This is not a big problem, but wanted to mention it because
   it appears that the default subdev spec is not correct.  With 'maint', all
   4 channels are available with default subdev spec.
   2. With 'rfnoc-devel', I get unexpected TX output power levels on the
   various channels when using the example program 'tx_waveforms' with the
   'constant' waveform which produces a single tone at the carrier frequency
   (see table below).
   3. With 'rfnoc-devel', I can only run 1 channel at a time. If I specify
   more than one channel (e.g., '--channels=0,1'), I get an error message that
   the PPS is not detected (even though using 'internal') and the example
   program crashes.  With 'maint', multiple channels work fine.

The table below shows the measured RF power levels (dBm) for a single tone
output at 2400 MHz.  The tx_gain setting was 45 (20 dB below maximum) and
there was about 31dB external attenuation.  So, for a measured power of -28
dBm, this implies that the maximum usrp output power is +23dBm (-28 + 20 +
31).

Channelmaintrfnoc-devel
   0   -27.8-27.8* (some trials ~-67)
   1   -27.9-66.6* (some trials ~-27)
   2   -27.6-39.9* (some trials ~-67)
   3   -27.6-54.6* (consistent)

Details:

   - maint hash: ad6b0935
   - rfnoc-devel hash: 1f8463cc
   - command line: tx_waveforms --rate 20e6 --freq 2400e6 --gain 45
   --channels 
   - os: ubuntu 16.04

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

Re: [USRP-users] error while reading samples in C++ for B210

[Marcus D. Leech via USRP-users]

On 06/27/2018 09:25 PM, RizThon wrote:


I would have expected to have no problem in mono channel at 56MS/s, as 
I have no problem on the Lime (with int12 instead of int16, but with 2 
channels instead of 1).


Is it possible to stream at 56MS/s on a single channel on the B210 
(same question for the others B2xx) without overflows?

Yes, if your machine is up to the task, and you've tweaked the buffering.

Try "num_recv_frames=256" in your device arguments.




Thanks.



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