Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Weight of B200 sdr (Chris Evans)
2. Re: b200 Overflows (Robert Kossler)
3. Re: b200 Overflows (Simon Brown)
4. Re: b200 Overflows (Simon Brown)
5. Re: b200 Overflows (Marcus D. Leech)
6. Re: b200 Overflows (Robert Kossler)
7. Re: b200 Overflows (Marcus D. Leech)
8. Re: Weight of B200 sdr (Neel Pandeya)
9. B200 and C# (Nir Eden)
10. Re: b200 Overflows (Simon Brown)
----------------------------------------------------------------------
Message: 1
Date: Sun, 28 Sep 2014 15:01:29 -0400
From: Chris Evans <[email protected]>
To: Dirk Ogermann <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Weight of B200 sdr
Message-ID:
<captrmrb7xlsouh4r-7cre2jjcjsr2r3f9y3-c1dejanl+as...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dirk,
Our B210 board (white PCB) is 102.0 grams. I assume the new B200 boards
will differ very slightly due to the larger USB-B connector, the lack of
two SMA connectors, the new GPIO connector as mentioned on this list a few
days ago.
On Sun, Sep 28, 2014 at 6:46 AM, Dirk Ogermann via USRP-users <
[email protected]> wrote:
> Hello,
>
> For a mobile platform I'm actual using an N210+wbx board which weight
> without the case is round about 218g.
>
> Regarding the datasheet for the b200 I was wondering about the weight of
> 350g for the board only although the dimensions are half size of the n210.
>
> Is there a cooling kit installed? Does someone know the correct weight of
> the b200 (board only) if there is mistake in the datasheet?
>
> Thank you for the answer.
>
> Kind regards
> Dirk
>
> Von Samsung Mobile gesendet
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
Chris Evans
Systems Engineer
Azure Summit Technology, Inc.
3050 Chain Bridge Road, Suite 600
Fairfax, VA 22030
919-428-6243 (cell)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140928/e9c3169d/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 28 Sep 2014 16:25:03 -0400
From: Robert Kossler <[email protected]>
To: Simon Brown <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] b200 Overflows
Message-ID:
<cab__htqglbct8h2ennag+ytt-ez6mtpavtc4cwts71gspdq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Simon,
The data returned in the recv() function is returned in whatever format you
specify for "cpu" in the stream_args. The sc12 data over-the-wire will be
automatically converted to your specified cpu format. So, in other words,
it should be completely transparent to you.
Rob
On Sun, Sep 28, 2014 at 3:47 AM, Simon Brown via USRP-users <
[email protected]> wrote:
> Marcus,
>
>
>
> Very stupid question ? I assume that if I use sc12 I get 12-bit complex
> data returned in the rx_stream recv() function? I?ve been digging in the
> source but am afraid I?m lost.
>
>
>
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>
>
>
> *From:* Marcus D. Leech [mailto:[email protected]]
>
> For all products other than B200, the only available formats are sc16 and
> sc8. B200 has the additional sc12 over-the-wire format.
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140928/a382f33f/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 29 Sep 2014 06:51:46 +0100
From: "Simon Brown" <[email protected]>
To: "'Robert Kossler'" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] b200 Overflows
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Excellent, thanks.
I got my spade out, I see this in the code, it should help. No doubt this is
documented but there?s just so much code in UHD.dll, it?s a lot to learn for a
simple programmer such as myself.
B200 is working very well, in fact so well that I?ll spend more money and get a
good box and add an external frequency source. Oh for 16-bits from the ADC?
Simon Brown G4ELI
http://v2.sdr-radio.com
From: Robert Kossler [mailto:[email protected]]
Simon,
The data returned in the recv() function is returned in whatever format you
specify for "cpu" in the stream_args. The sc12 data over-the-wire will be
automatically converted to your specified cpu format. So, in other words, it
should be completely transparent to you.
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/ff721e3d/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 29 Sep 2014 08:00:54 +0100
From: "Simon Brown" <[email protected]>
To: "'Marcus D. Leech'" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] b200 Overflows
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Marcus,
Using the 007.003.001 codebase uhd::stream_args_t("sc16", "sc12") crashes
inside usrp->get_rx_stream. I don't see any reference to sc12 in the
https://github.com/EttusResearch/uhd/blob/master/CHANGELOG, so I'm a bit
lost now.
Please clarify (I've read the source) if I get an overrun then the data is
being delivered from the B200 faster than the UHD.dll is reading it? If this
is the case I also believe that there's no way I can tell the underlying
code to flush the LibUSB buffers?
I'm currently having considerable success with all Ettus hardware flavours
but am a tad stuck with the whole UHD concept / way of life, your help is
greatly appreciated.
Simon Brown G4ELI
http://v2.sdr-radio.com
From: Marcus D. Leech [mailto:[email protected]]
Sent: 27 September 2014 19:41
To: Simon Brown
Cc: [email protected]
Subject: Re: [USRP-users] b200 Overflows
On 09/27/2014 02:30 PM, Simon Brown via USRP-users wrote:
Hi Marcus,
I'll try sc12 tomorrow, possibly later this evening. I'm currently preparing
food and adding some diagnostics.
It's probably in the manual, but is there a way to determine the most
efficient format for a device without losing resolution, for example sc12
for b200, (maybe) sc16 or fc21 for the N210 etc.? I would like to reduce any
network / bus traffic where possible.
Simon Brown G4ELI
http://v2.sdr-radio.com
The number of over-the-wire-formats is strictly-limited---it's not
open-ended.
For all products other than B200, the only available formats are sc16 and
sc8. B200 has the additional sc12 over-the-wire format.
These "wire formats" are then converted by the driver into one of a few
host-side formats, the most natural for a lot of work being
fc32.
The idea behind "wire formats" is to preserve a strictly-limited resource,
namely, over-the-wire bandwidth. No amount of "buying the very best"
1GiGe controller, for example, will get you beyond 1Gigabit of bandwidth
over that medium. Which is why to support 50Msps on the N2xx, you
have to use 8-bit wire format. On the B200, you can reduce USB bus
bandwidth, but preserve ADC/DAC dynamic range by using SC12. I think
that only really "plays out" (normally) over USB-2.0. Over USB-3.0, you
*should* have plenty of bandwidth available, at least over the USB-3.0
bus and inside the controller. But outside the controller, there may be
host-bus limitations that may drive on to using more
byte-per-second-conserving
formats.
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus D. Leech via USRP-users
Sent: 27 September 2014 19:11
To: [email protected]
Subject: Re: [USRP-users] b200 Overflows
On 09/27/2014 02:00 PM, Simon Brown via USRP-users wrote:
Thanks,
I've tried changing these, still get overruns with sample rates of 8MS/s or
higher.
Simon Brown G4ELI
http://v2.sdr-radio.com
Are you sure that your USB-3.0 interface is actually dealing with the device
as a USB-3.0 and not a USB-2.0 device?
If you specify a wire-format of sc8 or sc12, do the overruns go away? This
will help distinguish between cases involving CPU exhaustion, and interior
bus deficiencies (I found this on one of my embedded systems--could
sustain only 6.4Msps with full-width samples, but was perfectly happy to
stream 12.8Msps with 8-bit samples).
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus D. Leech via USRP-users
Sent: 26 September 2014 20:03
To: [email protected]
Subject: Re: [USRP-users] b200 Overflows
On 09/26/2014 02:18 PM, Simon Brown via USRP-users wrote:
Hi,
Windows 64-bit: I'm streaming nicely, none of my threads indicate CPU
problems (plenty of headroom). At 8MB/s and higher I'm getting fastpath
Overrun messages every second or so even though I'm pulling data from the
b200 as fast as it's available, I am not CPU limited in any way. Using Intel
USB 3.
FWIW I don't see any way to tune the uhd::rx_streamer - bigger / more
buffers, also I don't see any way to flush either.
Interestingly if I get my CUDA card working harder (more work on the bus)
the Overrun messages appear more frequently. I7 4770k, good motherboard
(can't remember what).
Any suggestions?
Simon Brown G4ELI
http://v2.sdr-radio.com
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
The USB transport parameters can be tweaked:
http://files.ettus.com/manual/page_transport.html#transport_usb_params
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/0044c06e/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 29 Sep 2014 10:04:23 -0400
From: "Marcus D. Leech" <[email protected]>
To: Simon Brown <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] b200 Overflows
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 09/29/2014 03:00 AM, Simon Brown wrote:
>
> Marcus,
>
> Using the 007.003.001 codebase uhd::stream_args_t("sc16", "sc12")
> crashes inside usrp->get_rx_stream. I don't see any reference to sc12
> in the https://github.com/EttusResearch/uhd/blob/master/CHANGELOG, so
> I'm a bit lost now.
>
> Please clarify (I've read the source) if I get an overrun then the
> data is being delivered from the B200 faster than the UHD.dll is
> reading it? If this is the case I also believe that there's no way I
> can tell the underlying code to flush the LibUSB buffers?
>
> I'm currently having considerable success with all Ettus hardware
> flavours but am a tad stuck with the whole UHD concept / way of life,
> your help is greatly appreciated.
>
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>
http://files.ettus.com/manual/structuhd_1_1stream__args__t.html#aa54b7dc3e2c71d11c774d8b4a15984cc
Describes the components of stream_args_t. In particular, the first
component is the desired host-side ("CPU") format, the second the wire-side
format.
I think sc12 was introduced after UHD 3.7.1, so upgrade.
> *From:*Marcus D. Leech [mailto:[email protected]]
> *Sent:* 27 September 2014 19:41
> *To:* Simon Brown
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] b200 Overflows
>
> On 09/27/2014 02:30 PM, Simon Brown via USRP-users wrote:
>
> Hi Marcus,
>
> I'll try sc12 tomorrow, possibly later this evening. I'm currently
> preparing food and adding some diagnostics.
>
> It's probably in the manual, but is there a way to determine the
> most efficient format for a device without losing resolution, for
> example sc12 for b200, (maybe) sc16 or fc21 for the N210 etc.? I
> would like to reduce any network / bus traffic where possible.
>
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>
> The number of over-the-wire-formats is strictly-limited---it's not
> open-ended.
>
> For all products other than B200, the only available formats are sc16
> and sc8. B200 has the additional sc12 over-the-wire format.
>
> These "wire formats" are then converted by the driver into one of a
> few host-side formats, the most natural for a lot of work being
> fc32.
>
> The idea behind "wire formats" is to preserve a strictly-limited
> resource, namely, over-the-wire bandwidth. No amount of "buying the
> very best"
> 1GiGe controller, for example, will get you beyond 1Gigabit of
> bandwidth over that medium. Which is why to support 50Msps on the
> N2xx, you
> have to use 8-bit wire format. On the B200, you can reduce USB
> bus bandwidth, but preserve ADC/DAC dynamic range by using SC12. I think
> that only really "plays out" (normally) over USB-2.0. Over USB-3.0,
> you *should* have plenty of bandwidth available, at least over the USB-3.0
> bus and inside the controller. But outside the controller, there
> may be host-bus limitations that may drive on to using more
> byte-per-second-conserving
> formats.
>
>
>
> *From:*USRP-users [mailto:[email protected]] *On
> Behalf Of *Marcus D. Leech via USRP-users
> *Sent:* 27 September 2014 19:11
> *To:* [email protected] <mailto:[email protected]>
> *Subject:* Re: [USRP-users] b200 Overflows
>
> On 09/27/2014 02:00 PM, Simon Brown via USRP-users wrote:
>
> Thanks,
>
> I've tried changing these, still get overruns with sample rates of
> 8MS/s or higher.
>
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>
> Are you sure that your USB-3.0 interface is actually dealing with the
> device as a USB-3.0 and not a USB-2.0 device?
>
> If you specify a wire-format of sc8 or sc12, do the overruns go away?
> This will help distinguish between cases involving CPU exhaustion, and
> interior
> bus deficiencies (I found this on one of my embedded systems--could
> sustain only 6.4Msps with full-width samples, but was perfectly happy to
> stream 12.8Msps with 8-bit samples).
>
>
>
>
> *From:*USRP-users [mailto:[email protected]] *On
> Behalf Of *Marcus D. Leech via USRP-users
> *Sent:* 26 September 2014 20:03
> *To:* [email protected] <mailto:[email protected]>
> *Subject:* Re: [USRP-users] b200 Overflows
>
> On 09/26/2014 02:18 PM, Simon Brown via USRP-users wrote:
>
> Hi,
>
> Windows 64-bit: I'm streaming nicely, none of my threads indicate
> CPU problems (plenty of headroom). At 8MB/s and higher I'm getting
> fastpath Overrun messages every second or so even though I'm
> pulling data from the b200 as fast as it's available, I am not CPU
> limited in any way. Using Intel USB 3.
>
> FWIW I don't see any way to tune the uhd::rx_streamer -- bigger /
> more buffers, also I don't see any way to flush either.
>
> Interestingly if I get my CUDA card working harder (more work on
> the bus) the Overrun messages appear more frequently. I7 4770k,
> good motherboard (can't remember what).
>
> Any suggestions?
>
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>
>
>
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> [email protected] <mailto:[email protected]>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> The USB transport parameters can be tweaked:
>
> http://files.ettus.com/manual/page_transport.html#transport_usb_params
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/a6415ea2/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 29 Sep 2014 10:09:18 -0400
From: Robert Kossler <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] b200 Overflows
Message-ID:
<cab__htq+ystayxtd4fd_dctod2vhputkwq+yrr91upjdkov...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Even after upgrade, sc12 only works with cpu format fc32 (not sc16). So,
if you want to use sc12, you need to choose fc32 as cpu format.
Rob
On Mon, Sep 29, 2014 at 10:04 AM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 09/29/2014 03:00 AM, Simon Brown wrote:
>
> Marcus,
>
>
>
> Using the 007.003.001 codebase uhd::stream_args_t(?sc16?, ?sc12?) crashes
> inside usrp->get_rx_stream. I don?t see any reference to sc12 in the
> https://github.com/EttusResearch/uhd/blob/master/CHANGELOG, so I?m a bit
> lost now.
>
>
>
> Please clarify (I?ve read the source) if I get an overrun then the data is
> being delivered from the B200 faster than the UHD.dll is reading it? If
> this is the case I also believe that there?s no way I can tell the
> underlying code to flush the LibUSB buffers?
>
>
>
> I?m currently having considerable success with all Ettus hardware flavours
> but am a tad stuck with the whole UHD concept / way of life, your help is
> greatly appreciated.
>
>
>
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>
>
> http://files.ettus.com/manual/structuhd_1_1stream__args__t.html#aa54b7dc3e2c71d11c774d8b4a15984cc
>
> Describes the components of stream_args_t. In particular, the first
> component is the desired host-side ("CPU") format, the second the wire-side
> format.
>
> I think sc12 was introduced after UHD 3.7.1, so upgrade.
>
>
>
>
>
> *From:* Marcus D. Leech [mailto:[email protected] <[email protected]>]
> *Sent:* 27 September 2014 19:41
> *To:* Simon Brown
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] b200 Overflows
>
>
>
> On 09/27/2014 02:30 PM, Simon Brown via USRP-users wrote:
>
> Hi Marcus,
>
>
>
> I?ll try sc12 tomorrow, possibly later this evening. I?m currently
> preparing food and adding some diagnostics.
>
>
>
> It?s probably in the manual, but is there a way to determine the most
> efficient format for a device without losing resolution, for example sc12
> for b200, (maybe) sc16 or fc21 for the N210 etc.? I would like to reduce
> any network / bus traffic where possible.
>
>
>
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>
> The number of over-the-wire-formats is strictly-limited---it's not
> open-ended.
>
> For all products other than B200, the only available formats are sc16 and
> sc8. B200 has the additional sc12 over-the-wire format.
>
> These "wire formats" are then converted by the driver into one of a few
> host-side formats, the most natural for a lot of work being
> fc32.
>
> The idea behind "wire formats" is to preserve a strictly-limited resource,
> namely, over-the-wire bandwidth. No amount of "buying the very best"
> 1GiGe controller, for example, will get you beyond 1Gigabit of bandwidth
> over that medium. Which is why to support 50Msps on the N2xx, you
> have to use 8-bit wire format. On the B200, you can reduce USB bus
> bandwidth, but preserve ADC/DAC dynamic range by using SC12. I think
> that only really "plays out" (normally) over USB-2.0. Over USB-3.0, you
> *should* have plenty of bandwidth available, at least over the USB-3.0
> bus and inside the controller. But outside the controller, there may
> be host-bus limitations that may drive on to using more
> byte-per-second-conserving
> formats.
>
>
>
>
>
> *From:* USRP-users [mailto:[email protected]
> <[email protected]>] *On Behalf Of *Marcus D. Leech via
> USRP-users
> *Sent:* 27 September 2014 19:11
> *To:* [email protected]
> *Subject:* Re: [USRP-users] b200 Overflows
>
>
>
> On 09/27/2014 02:00 PM, Simon Brown via USRP-users wrote:
>
> Thanks,
>
>
>
> I?ve tried changing these, still get overruns with sample rates of 8MS/s
> or higher.
>
>
>
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>
>
>
> Are you sure that your USB-3.0 interface is actually dealing with the
> device as a USB-3.0 and not a USB-2.0 device?
>
> If you specify a wire-format of sc8 or sc12, do the overruns go away?
> This will help distinguish between cases involving CPU exhaustion, and
> interior
> bus deficiencies (I found this on one of my embedded systems--could
> sustain only 6.4Msps with full-width samples, but was perfectly happy to
> stream 12.8Msps with 8-bit samples).
>
>
>
>
> *From:* USRP-users [mailto:[email protected]
> <[email protected]>] *On Behalf Of *Marcus D. Leech via
> USRP-users
> *Sent:* 26 September 2014 20:03
> *To:* [email protected]
> *Subject:* Re: [USRP-users] b200 Overflows
>
>
>
> On 09/26/2014 02:18 PM, Simon Brown via USRP-users wrote:
>
> Hi,
>
>
>
> Windows 64-bit: I?m streaming nicely, none of my threads indicate CPU
> problems (plenty of headroom). At 8MB/s and higher I?m getting fastpath
> Overrun messages every second or so even though I?m pulling data from the
> b200 as fast as it?s available, I am not CPU limited in any way. Using
> Intel USB 3.
>
>
>
> FWIW I don?t see any way to tune the uhd::rx_streamer ? bigger / more
> buffers, also I don?t see any way to flush either.
>
>
>
> Interestingly if I get my CUDA card working harder (more work on the bus)
> the Overrun messages appear more frequently. I7 4770k, good motherboard
> (can?t remember what).
>
>
>
> Any suggestions?
>
>
>
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>
>
>
>
>
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> [email protected]
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> The USB transport parameters can be tweaked:
>
> http://files.ettus.com/manual/page_transport.html#transport_usb_params
>
>
>
>
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> [email protected]
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
> --
>
> Marcus Leech
>
> Principal Investigator
>
> Shirleys Bay Radio Astronomy Consortium
>
> http://www.sbrac.org
>
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> [email protected]
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/9108f951/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 29 Sep 2014 10:14:39 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] b200 Overflows
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 09/29/2014 10:04 AM, Marcus D. Leech via USRP-users wrote:
> On 09/29/2014 03:00 AM, Simon Brown wrote:
>>
>> Marcus,
>>
>> Using the 007.003.001 codebase uhd::stream_args_t("sc16", "sc12")
>> crashes inside usrp->get_rx_stream. I don't see any reference to sc12
>> in the https://github.com/EttusResearch/uhd/blob/master/CHANGELOG, so
>> I'm a bit lost now.
>>
>> Please clarify (I've read the source) if I get an overrun then the
>> data is being delivered from the B200 faster than the UHD.dll is
>> reading it? If this is the case I also believe that there's no way I
>> can tell the underlying code to flush the LibUSB buffers?
>>
>> I'm currently having considerable success with all Ettus hardware
>> flavours but am a tad stuck with the whole UHD concept / way of life,
>> your help is greatly appreciated.
>>
>> Simon Brown G4ELI
>> http://v2.sdr-radio.com
>>
> http://files.ettus.com/manual/structuhd_1_1stream__args__t.html#aa54b7dc3e2c71d11c774d8b4a15984cc
>
> Describes the components of stream_args_t. In particular, the first
> component is the desired host-side ("CPU") format, the second the
> wire-side
> format.
>
> I think sc12 was introduced after UHD 3.7.1, so upgrade.
>
>
Actually, I somewhat mis-spoke. As of current release, there is no
converter from sc12 to sc16, only to fc32, so if you use sc12
wire-format, you
pretty-much have to use fc32, and then if desired, convert it
yourself to an integer format.
Some DSP folks have an aversion to floating-point for DSP work, but in
fact on "ordinary" machines, notably, x86, floating-point is very often the
better format for heavy-duty numerical work, both because of the heavy
pipelining of non-SIMD floating point, and because of the SIMD units
that can be used aggressively to handle floating-point numerical
streams. There are exceptions, of course, where the integer ALU is
faster, but
there's generally much more "pressure" on the integer unit from
ordinary, non-numerical, flows.
There is no "flush the USB buffers, please" API call. The overall
reason for overruns is that the hardware is delivering them faster than your
system, overall, can cope. The "harvester" of data in UHD is quite
efficient, so if things are running into trouble, it's usually the
*overall* system
that is the cause. There's usually no single cause, but a
collection of things all cooperating to hamper your ability to handle
real-time data flows.
The benchmark_rate tool that I mentioned last week can be used to get
some rough idea of what the basic "stack" from USB up to UHD can handle,
without bringing in the complexity of actually "doing stuff" with the
resulting samples.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/bf9ea66c/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 29 Sep 2014 07:23:21 -0700
From: Neel Pandeya <[email protected]>
To: Dirk Ogermann <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Weight of B200 sdr
Message-ID:
<CACaXmv9yWh+wUHdkLmeoTQmc7SDq42k73m=h8srybvptxd4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Dirk:
The weight of my B200 Rev 4 board is 0.205 lbs (93g). Note that this is the
Rev 4 with the mini-USB connector, not the Rev 6 with the new B connector.
You can view more information about the differences between board revisions
and obtain mechanical information at the link below. I hope this helps!
http://files.ettus.com/b2x0_enclosure/
--Neel
On Sun, Sep 28, 2014 at 10:22 PM, Dirk Ogermann <[email protected]>
wrote:
> Hi Neel,
>
> Thank you for the offer.
>
> If the effort is not too high I would like to know the exact weight of
> the b200.
>
> Thank you again.
>
> Kind regards
> Dirk
>
>
> Von Samsung Mobile gesendet
>
>
> -------- Urspr?ngliche Nachricht --------
> Von: Neel Pandeya
> Datum:28.09.2014 17:46 (GMT+01:00)
> An: Dirk Ogermann
> Betreff: Re: [USRP-users] Weight of B200 sdr
>
> Hello Dirk:
>
> I don't think the B200 is as heavy as 350g. It should certainly weigh less
> than an N210 with WBX. On Monday, I could put a B200 on a scale, and give
> you the result. Let me know if you're interested.
>
> --Neel
>
>
> On Sun, Sep 28, 2014 at 3:46 AM, Dirk Ogermann via USRP-users <
> [email protected]> wrote:
>
>> Hello,
>>
>> For a mobile platform I'm actual using an N210+wbx board which weight
>> without the case is round about 218g.
>>
>> Regarding the datasheet for the b200 I was wondering about the weight of
>> 350g for the board only although the dimensions are half size of the n210.
>>
>> Is there a cooling kit installed? Does someone know the correct weight of
>> the b200 (board only) if there is mistake in the datasheet?
>>
>> Thank you for the answer.
>>
>> Kind regards
>> Dirk
>>
>> Von Samsung Mobile gesendet
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/84b8d546/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 29 Sep 2014 17:51:56 +0300
From: Nir Eden <[email protected]>
To: [email protected]
Subject: [USRP-users] B200 and C#
Message-ID:
<CAP4_4=d8we1bc2hvdzxf__aawex1cyvknle6kzv83b1rpqt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I'm trying to use uhd.dll in C# program. I've tried to use DllImport with
decorated names, without success. Dose anyone can provide any leads for
working with uhd.dll and C#?
Thanks in advance,
Nir 4Z7DEF
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/55af86e7/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 29 Sep 2014 16:58:00 +0100
From: "Simon Brown" <[email protected]>
To: "'Robert Kossler'" <[email protected]>, "'Marcus D.
Leech'" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] b200 Overflows
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Everybody,
Many thanks, this info is/was missing from the change log. Or maybe I?m just
thick J .
Simon Brown G4ELI
http://v2.sdr-radio.com
From: Robert Kossler [mailto:[email protected]]
Sent: 29 September 2014 15:09
To: Marcus D. Leech
Cc: Simon Brown; [email protected]
Subject: Re: [USRP-users] b200 Overflows
Even after upgrade, sc12 only works with cpu format fc32 (not sc16). So, if
you want to use sc12, you need to choose fc32 as cpu format.
Rob
On Mon, Sep 29, 2014 at 10:04 AM, Marcus D. Leech via USRP-users
<[email protected]> wrote:
On 09/29/2014 03:00 AM, Simon Brown wrote:
Marcus,
Using the 007.003.001 codebase uhd::stream_args_t(?sc16?, ?sc12?) crashes
inside usrp->get_rx_stream. I don?t see any reference to sc12 in the
https://github.com/EttusResearch/uhd/blob/master/CHANGELOG, so I?m a bit lost
now.
Please clarify (I?ve read the source) if I get an overrun then the data is
being delivered from the B200 faster than the UHD.dll is reading it? If this is
the case I also believe that there?s no way I can tell the underlying code to
flush the LibUSB buffers?
I?m currently having considerable success with all Ettus hardware flavours but
am a tad stuck with the whole UHD concept / way of life, your help is greatly
appreciated.
Simon Brown G4ELI
http://v2.sdr-radio.com
http://files.ettus.com/manual/structuhd_1_1stream__args__t.html#aa54b7dc3e2c71d11c774d8b4a15984cc
Describes the components of stream_args_t. In particular, the first component
is the desired host-side ("CPU") format, the second the wire-side
format.
I think sc12 was introduced after UHD 3.7.1, so upgrade.
From: Marcus D. Leech [mailto:[email protected]]
Sent: 27 September 2014 19:41
To: Simon Brown
Cc: [email protected]
Subject: Re: [USRP-users] b200 Overflows
On 09/27/2014 02:30 PM, Simon Brown via USRP-users wrote:
Hi Marcus,
I?ll try sc12 tomorrow, possibly later this evening. I?m currently preparing
food and adding some diagnostics.
It?s probably in the manual, but is there a way to determine the most efficient
format for a device without losing resolution, for example sc12 for b200,
(maybe) sc16 or fc21 for the N210 etc.? I would like to reduce any network /
bus traffic where possible.
Simon Brown G4ELI
http://v2.sdr-radio.com
The number of over-the-wire-formats is strictly-limited---it's not open-ended.
For all products other than B200, the only available formats are sc16 and sc8.
B200 has the additional sc12 over-the-wire format.
These "wire formats" are then converted by the driver into one of a few
host-side formats, the most natural for a lot of work being
fc32.
The idea behind "wire formats" is to preserve a strictly-limited resource,
namely, over-the-wire bandwidth. No amount of "buying the very best"
1GiGe controller, for example, will get you beyond 1Gigabit of bandwidth over
that medium. Which is why to support 50Msps on the N2xx, you
have to use 8-bit wire format. On the B200, you can reduce USB bus
bandwidth, but preserve ADC/DAC dynamic range by using SC12. I think
that only really "plays out" (normally) over USB-2.0. Over USB-3.0, you
*should* have plenty of bandwidth available, at least over the USB-3.0
bus and inside the controller. But outside the controller, there may be
host-bus limitations that may drive on to using more byte-per-second-conserving
formats.
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus D. Leech via USRP-users
Sent: 27 September 2014 19:11
To: [email protected]
Subject: Re: [USRP-users] b200 Overflows
On 09/27/2014 02:00 PM, Simon Brown via USRP-users wrote:
Thanks,
I?ve tried changing these, still get overruns with sample rates of 8MS/s or
higher.
Simon Brown G4ELI
http://v2.sdr-radio.com
Are you sure that your USB-3.0 interface is actually dealing with the device as
a USB-3.0 and not a USB-2.0 device?
If you specify a wire-format of sc8 or sc12, do the overruns go away? This
will help distinguish between cases involving CPU exhaustion, and interior
bus deficiencies (I found this on one of my embedded systems--could sustain
only 6.4Msps with full-width samples, but was perfectly happy to
stream 12.8Msps with 8-bit samples).
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus D. Leech via USRP-users
Sent: 26 September 2014 20:03
To: [email protected]
Subject: Re: [USRP-users] b200 Overflows
On 09/26/2014 02:18 PM, Simon Brown via USRP-users wrote:
Hi,
Windows 64-bit: I?m streaming nicely, none of my threads indicate CPU problems
(plenty of headroom). At 8MB/s and higher I?m getting fastpath Overrun messages
every second or so even though I?m pulling data from the b200 as fast as it?s
available, I am not CPU limited in any way. Using Intel USB 3.
FWIW I don?t see any way to tune the uhd::rx_streamer ? bigger / more buffers,
also I don?t see any way to flush either.
Interestingly if I get my CUDA card working harder (more work on the bus) the
Overrun messages appear more frequently. I7 4770k, good motherboard (can?t
remember what).
Any suggestions?
Simon Brown G4ELI
http://v2.sdr-radio.com
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
The USB transport parameters can be tweaked:
http://files.ettus.com/manual/page_transport.html#transport_usb_params
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/0fda6ce9/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 49, Issue 28
******************************************
