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: b200 Overflows (Simon Brown)
2. Uhd build fails (Daniel Gould)
3. Re: Uhd build fails (Marcus D. Leech)
4. Re: B200 and C# (Simon Brown)
5. Re: b200 Overflows (Ian Buckley)
6. Re: b200 Overflows (Simon Brown)
7. Re: b200 Overflows (Marcus D. Leech)
8. Re: b200 Overflows (Simon Brown)
9. Re: b200 Overflows (Marcus D. Leech)
10. Re: b200 Overflows (Simon Brown)
11. Re: b200 Overflows (Marcus D. Leech)
12. Re: b200 Overflows (Simon Brown)
13. Re: B200 and C# (Nir Eden)
14. Re: b200 Overflows (Ian Buckley)
15. Re: b200 Overflows (Marcus D. Leech)
16. Re: b200 Overflows (Simon Brown)
17. Re: b200 Overflows (Marcus D. Leech)
18. USRP B210 RX channel alignment (Chris Evans)
19. Re: USRP B210 RX channel alignment (Marcus D. Leech)
20. "Block diagram" of USRP FPGA content? (Ralph A. Schmid, dk5ras)
21. B210 rev6 - currently shipping? (Paul Sutton)
22. query GPSDO satellite receive quality (Martin)
23. Re: USRP-users Digest, Vol 49, Issue 25 (Isen I-Chun Chao)
24. Re: USRP-users Digest, Vol 49, Issue 25 ([email protected])
25. B210 UHD Error (Terry Stevenson)
26. Bandwidth limitation (FIXED-TERM Ghobrial Antoun (CR/AEH4))
----------------------------------------------------------------------
Message: 1
Date: Mon, 29 Sep 2014 17:09:34 +0100
From: "Simon Brown" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] b200 Overflows
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi Marcus,
My system can cope, I can read 38.4 MHz from the bladeRF without any
problem. I have to first find someone who can run UHD.dll at 30MHz without
overrun issues then I can start diagnostics.
My other alternative is to replace UHD.dll for USB3-related devices L .
I'll try the benchmark tool, I hope it reports overruns, but first I have
presentations to write.
Simon Brown G4ELI
http://v2.sdr-radio.com
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus D. Leech via USRP-users
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/71f7c87a/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 29 Sep 2014 12:12:58 -0400
From: Daniel Gould <[email protected]>
To: [email protected]
Subject: [USRP-users] Uhd build fails
Message-ID:
<cagtrgwfhcbzf_oy1rjndaf0rw4cgcvhwbhnaanoqsy5_f2g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I pulled the latest UHD source and am having build failures due to
boost/thread/lock_guard.hpp, missing file. This file does not exist within
the boost install directories, i believe it is part of new boost
deliveries, somewhere around 1.52/1.53.
The build error originates from /utils/log.cpp.
I was able to build by backing up to just prior to the following commit:
fa0313652cc25e17e6c3151f67111fb88c62778e:
uhd: Fixed logging bug (#476) -- UHD logging has unexplained effect on
packet loss
System:
Ubuntu 12.04
Boost 1.48, from apt-get repo
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/53e484fd/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 29 Sep 2014 12:22:16 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Uhd build fails
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 09/29/2014 12:12 PM, Daniel Gould via USRP-users wrote:
>
> I pulled the latest UHD source and am having build failures due to
> boost/thread/lock_guard.hpp, missing file. This file does not exist
> within the boost install directories, i believe it is part of new
> boost deliveries, somewhere around 1.52/1.53.
>
> The build error originates from /utils/log.cpp.
>
> I was able to build by backing up to just prior to the following commit:
>
> fa0313652cc25e17e6c3151f67111fb88c62778e:
>
> uhd: Fixed logging bug (#476) -- UHD logging has unexplained effect on
> packet loss
>
> System:
>
> Ubuntu 12.04
>
> Boost 1.48, from apt-get repo
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
I'm seeing the same issue on Fedora 14 and Fedora 18.
--
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/3c5b8c4e/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 29 Sep 2014 17:25:53 +0100
From: "Simon Brown" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] B200 and C#
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Nir,
Based on my experience with UHD.dll in a Windows C++ project I think you?ll
have to write a C++ DLL which uses UHD.DLL and in your own DLL expose the
functions you need, this can be done, I?ve done it (proof in this screenshot
https://www.dropbox.com/s/ogm5mvqly8v9zf5/Screenshot-2014-09-29-101001.png?dl=0
).
Myself I?m seriously thinking about interfacing to the B200 / B210 directly,
using just some of the lower-level code inside UHD.dll.
UHD.dll is a massive piece of co, I am very interested in how you get on with
this. Maybe Windows developers should provide a self-help group J .
Simon Brown G4ELI
http://v2.sdr-radio.com
From: USRP-users [mailto:[email protected]] On Behalf Of Nir
Eden via USRP-users
Sent: 29 September 2014 15:52
To: [email protected]
Subject: [USRP-users] B200 and C#
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/e67e1626/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 29 Sep 2014 09:42:57 -0700
From: Ian Buckley <[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="windows-1252"
Simon,
Just to give you the H/W picture, you can visualize Rx data in the B200 as
flowing through the following in order:
DSP->Packetization Logic-> FIFO's
There actually quite a few FIFO's before the USB interface is reached and they
all run (in H/W) much quicker than USB3 throughput.
Thus data "falls through" and tends to accumulate at the last FIFO(s) where it
is rate limited by whatever the USB performance is.
If the sustained USB throughput (over a significant period of time) can't match
the sample rate (rate over the USB wire...DSP output rate) then that chain of
FIFO's slowly fills and, when the packetization logic can not add any more
samples to the head of the FIFO chain then and overflow error indication is
signaled to the host in an error packet (that bypasses the queued sample data).
Not directly helpful for you I know, but always nice to have the big picture.
-Ian
On Sep 29, 2014, at 12:00 AM, Simon Brown via USRP-users
<[email protected]> 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
>
> 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
>
> _______________________________________________
> 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/79cdcc83/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 29 Sep 2014 17:50:30 +0100
From: "Simon Brown" <[email protected]>
To: "'Ian Buckley'" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] b200 Overflows
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Ah,
So - is this overrun on the B200 itself or as I assumed inside the UHD.dll's
own buffering? If it's inside the B200 then it would possibly be firmware?
Apart from this overrun and something bloody odd errors with USRP1 on USB3 I
am, at the moment, a happy camper (I'll report these errors later).
Ian - everything helps, I do understand hardware, it's what people buy.
Software on the other hand is assumed to be free.
Simon Brown G4ELI
http://v2.sdr-radio.com
From: Ian Buckley [mailto:[email protected]]
Simon,
Just to give you the H/W picture, you can visualize Rx data in the B200 as
flowing through the following in order:
DSP->Packetization Logic-> FIFO's
There actually quite a few FIFO's before the USB interface is reached and
they all run (in H/W) much quicker than USB3 throughput.
Thus data "falls through" and tends to accumulate at the last FIFO(s) where
it is rate limited by whatever the USB performance is.
If the sustained USB throughput (over a significant period of time) can't
match the sample rate (rate over the USB wire...DSP output rate) then that
chain of FIFO's slowly fills and, when the packetization logic can not add
any more samples to the head of the FIFO chain then and overflow error
indication is signaled to the host in an error packet (that bypasses the
queued sample data).
Not directly helpful for you I know, but always nice to have the big
picture.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/d5f9c459/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 29 Sep 2014 12:53:27 -0400
From: "Marcus D. Leech" <[email protected]>
To: Simon Brown <[email protected]>, 'Ian Buckley'
<[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 12:50 PM, Simon Brown wrote:
>
> Ah,
>
> So -- is this overrun on the B200 itself or as I assumed inside the
> UHD.dll's own buffering? If it's inside the B200 then it would
> possibly be firmware?
>
> Apart from this overrun and something bloody odd errors with USRP1 on
> USB3 I am, at the moment, a happy camper (I'll report these errors later).
>
USB-3 controllers very-often aren't happy "downshifting" to support
USB-2.0 devices. The USRP1 may just be one of those. I've found the same
with the RTLSDR dongle devices as well--they *don't work* on a
USB-3.0 port.
> Ian -- everything helps, I do understand hardware, it's what people
> buy. Software on the other hand is assumed to be free...
>
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>
> *From:*Ian Buckley [mailto:[email protected]]
>
> Simon,
>
> Just to give you the H/W picture, you can visualize Rx data in the
> B200 as flowing through the following in order:
>
> DSP->Packetization Logic-> FIFO's
>
> There actually quite a few FIFO's before the USB interface is reached
> and they all run (in H/W) much quicker than USB3 throughput.
>
> Thus data "falls through" and tends to accumulate at the last FIFO(s)
> where it is rate limited by whatever the USB performance is.
>
> If the sustained USB throughput (over a significant period of time)
> can't match the sample rate (rate over the USB wire...DSP output rate)
> then that chain of FIFO's slowly fills and, when the packetization
> logic can not add any more samples to the head of the FIFO chain then
> and overflow error indication is signaled to the host in an error
> packet (that bypasses the queued sample data).
>
> Not directly helpful for you I know, but always nice to have the big
> picture.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/aafcb1d5/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 29 Sep 2014 18:11:57 +0100
From: "Simon Brown" <[email protected]>
To: "'Marcus D. Leech'" <[email protected]>, "'Ian Buckley'"
<[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] b200 Overflows
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Marcus,
Just FWIW I'm seeing the 'out of sequence' error with the USRP1 and I'm sure
it's on a USB3 device.
Simon Brown G4ELI
http://v2.sdr-radio.com
From: Marcus D. Leech [mailto:[email protected]]
USB-3 controllers very-often aren't happy "downshifting" to support USB-2.0
devices. The USRP1 may just be one of those. I've found the same
with the RTLSDR dongle devices as well--they *don't work* on a USB-3.0
port.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/a4e5c68e/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 29 Sep 2014 13:15:01 -0400
From: "Marcus D. Leech" <[email protected]>
To: Simon Brown <[email protected]>, 'Ian Buckley'
<[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 01:11 PM, Simon Brown wrote:
>
> Marcus,
>
> Just FWIW I'm seeing the 'out of sequence' error with the USRP1 and
> I'm sure it's on a USB3 device.
>
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>
The FX2 USB controller on the USRP1 and B100 was designed *long* before
USB-3. 0 was even a dream. It doesn't surprise me that some USB-2.0
devices don't work right with USB-3.0 controllers.
> *From:*Marcus D. Leech [mailto:[email protected]]
>
> USB-3 controllers very-often aren't happy "downshifting" to support
> USB-2.0 devices. The USRP1 may just be one of those. I've found the
> same
> with the RTLSDR dongle devices as well--they *don't work* on a
> USB-3.0 port.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/f2e45676/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 29 Sep 2014 18:17:28 +0100
From: "Simon Brown" <[email protected]>
To: "'Marcus D. Leech'" <[email protected]>, "'Ian Buckley'"
<[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] b200 Overflows
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Don't blame me, it's a user of my software who's doing this.
Simon Brown G4ELI
http://v2.sdr-radio.com
From: Marcus D. Leech [mailto:[email protected]]
The FX2 USB controller on the USRP1 and B100 was designed *long* before
USB-3. 0 was even a dream. It doesn't surprise me that some USB-2.0
devices don't work right with USB-3.0 controllers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/a1af5477/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 29 Sep 2014 13:22:58 -0400
From: "Marcus D. Leech" <[email protected]>
To: Simon Brown <[email protected]>, 'Ian Buckley'
<[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 01:17 PM, Simon Brown wrote:
>
> Don't blame me, it's a user of my software who's doing this.
>
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>
Ha! No blame implied, Simon. But you should suggest that they try the
USRP1 on a USB-2.0 port. USB-3.0 still has some very-rough edges, and
backwards-compat with some types of USB-2.0 high-speed devices is one
of them. It's a chicken/egg problem. On the one hand, you'd like
for no devices to "issue" until the USB-3.0 "ecosystem" is stable and
all the dark-corners explored. On the other hand, that will never
happen if there
aren't USB-3.0 devices "out there" pushing the envelope, making the
whole ecosystem better...
> *From:*Marcus D. Leech [mailto:[email protected]]
>
> The FX2 USB controller on the USRP1 and B100 was designed *long*
> before USB-3. 0 was even a dream. It doesn't surprise me that some
> USB-2.0
> devices don't work right with USB-3.0 controllers.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/96eb1f16/attachment-0001.html>
------------------------------
Message: 12
Date: Mon, 29 Sep 2014 18:53:25 +0100
From: "Simon Brown" <[email protected]>
To: "'Marcus D. Leech'" <[email protected]>, "'Ian Buckley'"
<[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] b200 Overflows
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
And what makes this worse is new laptops with only USB3.
Simon Brown G4ELI
http://v2.sdr-radio.com
From: Marcus D. Leech [mailto:[email protected]]
Sent: 29 September 2014 18:23
To: Simon Brown; 'Ian Buckley'
Cc: [email protected]
Subject: Re: [USRP-users] b200 Overflows
On 09/29/2014 01:17 PM, Simon Brown wrote:
Don't blame me, it's a user of my software who's doing this.
Simon Brown G4ELI
http://v2.sdr-radio.com
Ha! No blame implied, Simon. But you should suggest that they try the
USRP1 on a USB-2.0 port. USB-3.0 still has some very-rough edges, and
backwards-compat with some types of USB-2.0 high-speed devices is one of
them. It's a chicken/egg problem. On the one hand, you'd like
for no devices to "issue" until the USB-3.0 "ecosystem" is stable and all
the dark-corners explored. On the other hand, that will never happen if
there
aren't USB-3.0 devices "out there" pushing the envelope, making the whole
ecosystem better...
From: Marcus D. Leech [mailto:[email protected]]
The FX2 USB controller on the USRP1 and B100 was designed *long* before
USB-3. 0 was even a dream. It doesn't surprise me that some USB-2.0
devices don't work right with USB-3.0 controllers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/d3d8a4f8/attachment-0001.html>
------------------------------
Message: 13
Date: Mon, 29 Sep 2014 21:01:51 +0300
From: Nir Eden <[email protected]>
To: Simon Brown <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] B200 and C#
Message-ID:
<CAP4_4=fJ=f-nka-ktu5a59gyx9msxqfboqwk8pzg6msexfw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thin wrapper is good advice, especially for static functions. I will keep
you update you on my progress with this.
I was hoping that I will get some uhd.dll specific clues to reduce the
painful start.
-- Nir 4Z7DEF
On Mon, Sep 29, 2014 at 7:25 PM, Simon Brown via USRP-users <
[email protected]> wrote:
> Nir,
>
>
>
> Based on my experience with UHD.dll in a Windows C++ project I think
> you?ll have to write a C++ DLL which uses UHD.DLL and in your own DLL
> expose the functions you need, this can be done, I?ve done it (proof in
> this screenshot
> https://www.dropbox.com/s/ogm5mvqly8v9zf5/Screenshot-2014-09-29-101001.png?dl=0
> ).
>
>
>
> Myself I?m seriously thinking about interfacing to the B200 / B210
> directly, using just some of the lower-level code inside UHD.dll.
>
>
>
> UHD.dll is a massive piece of co, I am very interested in how you get on
> with this. Maybe Windows developers should provide a self-help group J .
>
>
>
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>
>
>
> *From:* USRP-users [mailto:[email protected]] *On Behalf
> Of *Nir Eden via USRP-users
> *Sent:* 29 September 2014 15:52
> *To:* [email protected]
> *Subject:* [USRP-users] B200 and C#
>
>
>
> 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
>
> _______________________________________________
> 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/a95fbbe9/attachment-0001.html>
------------------------------
Message: 14
Date: Mon, 29 Sep 2014 11:18:29 -0700
From: Ian Buckley <[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="windows-1252"
Slow(er than needed) host performance can propagate back pressure as far as the
FPGA H/W?so it's not (necessarily) indicative of a H/W problem if the H/W flags
overflow, just that downstream data consumption is not keeping up.
It may well be possible for UHD to flag Overflow without interaction with the
actual USRP under some set of conditions?I just can't speak to that off the
cuff, not my area of expertise.
On Sep 29, 2014, at 9:50 AM, Simon Brown <[email protected]> wrote:
> Ah,
>
> So ? is this overrun on the B200 itself or as I assumed inside the UHD.dll?s
> own buffering? If it?s inside the B200 then it would possibly be firmware?
>
> Apart from this overrun and something bloody odd errors with USRP1 on USB3 I
> am, at the moment, a happy camper (I?ll report these errors later).
>
> Ian ? everything helps, I do understand hardware, it?s what people buy.
> Software on the other hand is assumed to be free?
>
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>
> From: Ian Buckley [mailto:[email protected]]
>
> Simon,
> Just to give you the H/W picture, you can visualize Rx data in the B200 as
> flowing through the following in order:
> DSP->Packetization Logic-> FIFO's
>
> There actually quite a few FIFO's before the USB interface is reached and
> they all run (in H/W) much quicker than USB3 throughput.
> Thus data "falls through" and tends to accumulate at the last FIFO(s) where
> it is rate limited by whatever the USB performance is.
> If the sustained USB throughput (over a significant period of time) can't
> match the sample rate (rate over the USB wire...DSP output rate) then that
> chain of FIFO's slowly fills and, when the packetization logic can not add
> any more samples to the head of the FIFO chain then and overflow error
> indication is signaled to the host in an error packet (that bypasses the
> queued sample data).
>
> Not directly helpful for you I know, but always nice to have the big picture.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/c6bd8f13/attachment-0001.html>
------------------------------
Message: 15
Date: Mon, 29 Sep 2014 14:35:03 -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 12:50 PM, Simon Brown wrote:
>
> Ah,
>
> So -- is this overrun on the B200 itself or as I assumed inside the
> UHD.dll's own buffering? If it's inside the B200 then it would
> possibly be firmware?
>
> Apart from this overrun and something bloody odd errors with USRP1 on
> USB3 I am, at the moment, a happy camper (I'll report these errors later).
>
> Ian -- everything helps, I do understand hardware, it's what people
> buy. Software on the other hand is assumed to be free...
>
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>
>
So, I think I suggested yesterday that you try "benchmark_rate" which
basically exercises the "data harvesting" stack, without actually doing
anything
with the samples. Did you do that, and what were the results?
I apologize in advance if you've already done that and reported
results. This thread is growing quite quickly, and I'm starting to lose
track.
--
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/2a40e549/attachment-0001.html>
------------------------------
Message: 16
Date: Mon, 29 Sep 2014 19:37: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"
Hi Marcus,
You're losing track J and I'm losing the plot. I'm writing a couple of
presentations, when done I'll get back to this, I mentioned this some posts
ago. Honest.
Simon Brown G4ELI
http://v2.sdr-radio.com
From: Marcus D. Leech [mailto:[email protected]]
So, I think I suggested yesterday that you try "benchmark_rate" which
basically exercises the "data harvesting" stack, without actually doing
anything
with the samples. Did you do that, and what were the results?
I apologize in advance if you've already done that and reported results.
This thread is growing quite quickly, and I'm starting to lose track.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/5ad35d70/attachment-0001.html>
------------------------------
Message: 17
Date: Mon, 29 Sep 2014 14:42:44 -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 02:37 PM, Simon Brown wrote:
>
> Hi Marcus,
>
> You're losing track Jand I'm losing the plot. I'm writing a couple of
> presentations, when done I'll get back to this, I mentioned this some
> posts ago. Honest.
>
> Simon Brown G4ELI
> http://v2.sdr-radio.com
>
Oh, yes. You did mention that.
Well, looking forward to that test, whenever it happens...
> *From:*Marcus D. Leech [mailto:[email protected]]
>
> So, I think I suggested yesterday that you try "benchmark_rate" which
> basically exercises the "data harvesting" stack, without actually
> doing anything
> with the samples. Did you do that, and what were the results?
>
> I apologize in advance if you've already done that and reported
> results. This thread is growing quite quickly, and I'm starting to
> lose track.
>
--
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/da2e845f/attachment-0001.html>
------------------------------
Message: 18
Date: Mon, 29 Sep 2014 16:04:51 -0400
From: Chris Evans <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP B210 RX channel alignment
Message-ID:
<CAPTrmrBB=bh4jrvgrcugasm2ae7uwsgzdn3dejncop-uflp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
All,
I believe I might be running into the same issue that Stefan Ereth wrote
about on 05/02/14 and maybe also what Robert Kossler wrote about on
05/23/14 regarding phase alignment of USRP B210 RX channels. I have a 2:1
splitter feeding both RX ports on the B210 and I'm using code similar to
examples/rx_multi_samples.cpp. When I receive data from both channels,
there is a seemingly random phase offset between the two sinusoids each
time I run the program. However, if I issue_stream_cmd() multiple times in
one program, the relative phase between the two received sine waves is the
same.
If I use GNURadio to receive on two channels, I consistently get the same
relative phase offset. The relative phase offset seen in a GNURadio scope
is the same as what I see when chipscoping the outputs of both DDCs.
Using chipscope, I see that with GNURadio, radio_0/run_rx and
radio_0/strobe_rx go high at the same time that radio_1/run_rx and
radio_1/strobe_rx go high. With my UHD program, one channel starts
receiving before the other (and I assume the other one starts streaming at
some later time determined by software).
How can I force both channels to receive synchronously?
--
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/20140929/0a92f368/attachment-0001.html>
------------------------------
Message: 19
Date: Mon, 29 Sep 2014 16:13:49 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B210 RX channel alignment
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 09/29/2014 04:04 PM, Chris Evans via USRP-users wrote:
> All,
>
> I believe I might be running into the same issue that Stefan Ereth
> wrote about on 05/02/14 and maybe also what Robert Kossler wrote about
> on 05/23/14 regarding phase alignment of USRP B210 RX channels. I have
> a 2:1 splitter feeding both RX ports on the B210 and I'm using code
> similar to examples/rx_multi_samples.cpp. When I receive data from
> both channels, there is a seemingly random phase offset between the
> two sinusoids each time I run the program. However, if I
> issue_stream_cmd() multiple times in one program, the relative phase
> between the two received sine waves is the same.
>
> If I use GNURadio to receive on two channels, I consistently get the
> same relative phase offset. The relative phase offset seen in a
> GNURadio scope is the same as what I see when chipscoping the outputs
> of both DDCs.
>
> Using chipscope, I see that with GNURadio, radio_0/run_rx and
> radio_0/strobe_rx go high at the same time that radio_1/run_rx and
> radio_1/strobe_rx go high. With my UHD program, one channel starts
> receiving before the other (and I assume the other one starts
> streaming at some later time determined by software).
>
> How can I force both channels to receive synchronously?
>
> --
> Chris Evans
> Systems Engineer
> Azure Summit Technology, Inc.
> 3050 Chain Bridge Road, Suite 600
> Fairfax, VA 22030
> 919-428-6243 (cell)
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
I would recommend you look at the way gr-uhd commences streaming on a
multi_usrp object--it does some timed streaming, which will likely
arrange for things to start at more-or-less the same time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140929/2a729239/attachment-0001.html>
------------------------------
Message: 20
Date: Tue, 30 Sep 2014 08:16:51 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] "Block diagram" of USRP FPGA content?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
Is there some "block diagram drawing" available to show what the FPGA image
does in the different USRP models? Just some simple functionality overview,
decimation, resampling, buffers, control logic, to make it a bit more
transparent for us RF / non-coder guys... For me especially the USRP1 and
the B210 would be of interest :)
Ralph.
--
Ralph A. Schmid
Mondstr. 10
90762 F?rth
+49-171-3631223
[email protected]
http://www.bclog.de/
------------------------------
Message: 21
Date: Tue, 30 Sep 2014 11:29:19 +0100
From: Paul Sutton <[email protected]>
To: [email protected]
Subject: [USRP-users] B210 rev6 - currently shipping?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
If I order a B210 today, will I get the newer rev6 model?
Thanks,
Paul
--
________________________________________________________________
Paul Sutton Ph.D.
CTVR, The Telecommunications Research Centre,
Room 2.08, Dunlop House, Fenian Street,
University of Dublin, Trinity College, Ireland.
+353-1-8968443 | [email protected] | http://www.ctvr.ie
PGP Key ID: 7762DDC6
Fingerprint: 3EB5 39A3 C33D 68DE FA0F 1B81 C422 DC6C 7762 DDC6
________________________________________________________________
------------------------------
Message: 22
Date: Tue, 30 Sep 2014 14:23:46 +0200
From: Martin <[email protected]>
To: [email protected]
Subject: [USRP-users] query GPSDO satellite receive quality
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
How I can measure signal strength/received signal quality from satellite
to my GPSDO GPS receiver in USRP N210?
Sometimes in closed spaces I don't know if my receiver has a good signal
or not.
Can I filter that out of the raw NMEA messages some way or is there a
sensor that I can query.
With best regards,
Martin
------------------------------
Message: 23
Date: Tue, 30 Sep 2014 11:39:49 -0400
From: Isen I-Chun Chao <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP-users Digest, Vol 49, Issue 25
Message-ID:
<CAEG73KqwYsX2ZAYv9eUEmu3JiwKfiuHVSphAC2j3BpsnB1-j=w...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi
Since Martin mentioned the biggest changes in FPGA code, which making it
easier to build, I wonder if this release is the version with
Network-on-Chip design tool, which I am currently waiting for. If so, I
actually did not see any major change in usrp3/top/x300 in the fpga
directory.
Thanks
*Best Regards,Isen I-Chun Chao*
> Message: 7
> Date: Thu, 25 Sep 2014 12:07:52 -0700
> From: Martin Braun <[email protected]>
> To: "'[email protected]'" <[email protected]>
> Subject: [USRP-users] [UHD-3.7.3-RC1] Bugfix Release Announcement
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi everyone,
>
> we'll soon be releasing another bugfix release (3.7.3) and are putting
> out a release candidate for now. It is tagged at
> https://github.com/EttusResearch/uhddev/tree/003_007_003_rc1.
>
> Users working off of the 'maint' branch will be automatically updated if
> you run a 'git pull'.
> Note: This RC includes new images, so do run uhd_images_downloader if
> you update. There is no warning or error if you don't update the images
> (because they are still compatible), but you won't benefit from the
> stability changes we introduced.
>
> This RC mainly includes stability issues and bugfixes. The biggest
> change is for the FPGA code, which is now easier to build.
>
> Enjoy!
>
> Martin
>
> 3.7.3-RC1 Changelog:
> * Fixed examples
> * Removed compiler warnings
> * Fixed CBX LO settings (FRAC truncation)
> * Fixed build issues for out-of-tree tools for some distros
> * Fixed some logging strings (SBX, GPSDO)
> * Improved logging (speedups, removed unnecessary cycles)
> * Added output sync for DAC reference clocks on X300
>
>
> ------------------------------
>
> > -----Original Message-----
> > From: USRP-users [mailto:[email protected]] On Behalf
> Of Martin Braun via USRP-users
> > Sent: Thursday, 25 September, 2014 21:08
> > To: '[email protected]'
> > Subject: [USRP-users] [UHD-3.7.3-RC1] Bugfix Release Announcement
> >
> > Hi everyone,
> >
> > we'll soon be releasing another bugfix release (3.7.3) and are putting
> out a release candidate for now. It is tagged at
> > https://github.com/EttusResearch/uhddev/tree/003_007_003_rc1.
> >
> > Users working off of the 'maint' branch will be automatically updated if
> you run a 'git pull'.
> > Note: This RC includes new images, so do run uhd_images_downloader if
> you update. There is no warning or error if you don't
> > update the images (because they are still compatible), but you won't
> benefit from the stability changes we introduced.
> >
> > This RC mainly includes stability issues and bugfixes. The biggest
> change is for the FPGA code, which is now easier to build.
> >
> > Enjoy!
> >
> > Martin
> >
> > 3.7.3-RC1 Changelog:
> > * Fixed examples
> > * Removed compiler warnings
> > * Fixed CBX LO settings (FRAC truncation)
> > * Fixed build issues for out-of-tree tools for some distros
> > * Fixed some logging strings (SBX, GPSDO)
> > * Improved logging (speedups, removed unnecessary cycles)
> > * Added output sync for DAC reference clocks on X300
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: PGP.sig
> Type: application/pgp-signature
> Size: 832 bytes
> Desc: not available
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140925/05b99892/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 9
> Date: Thu, 25 Sep 2014 12:42:32 -0700
> From: Martin Braun <[email protected]>
> To: "'[email protected]'" <[email protected]>
> Subject: Re: [USRP-users] [UHD-3.7.3-RC1] Bugfix Release Announcement
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> My apologies, the tag is actually to be found here:
> https://github.com/EttusResearch/uhd/tree/003_007_003_rc1
>
> Cheers,
> Martin
>
>
> On 25.09.2014 12:07, Martin Braun wrote:
> > Hi everyone,
> >
> > we'll soon be releasing another bugfix release (3.7.3) and are putting
> > out a release candidate for now. It is tagged at
> > https://github.com/EttusResearch/uhddev/tree/003_007_003_rc1.
> >
> > Users working off of the 'maint' branch will be automatically updated if
> > you run a 'git pull'.
> > Note: This RC includes new images, so do run uhd_images_downloader if
> > you update. There is no warning or error if you don't update the images
> > (because they are still compatible), but you won't benefit from the
> > stability changes we introduced.
> >
> > This RC mainly includes stability issues and bugfixes. The biggest
> > change is for the FPGA code, which is now easier to build.
> >
> > Enjoy!
> >
> > Martin
> >
> > 3.7.3-RC1 Changelog:
> > * Fixed examples
> > * Removed compiler warnings
> > * Fixed CBX LO settings (FRAC truncation)
> > * Fixed build issues for out-of-tree tools for some distros
> > * Fixed some logging strings (SBX, GPSDO)
> > * Improved logging (speedups, removed unnecessary cycles)
> > * Added output sync for DAC reference clocks on X300
>
> ------------------------------
>
> Message: 10
> Date: Thu, 25 Sep 2014 12:44:41 -0700
> From: Martin Braun <[email protected]>
> Cc: [email protected]
> Subject: Re: [USRP-users] [UHD-3.7.3-RC1] Bugfix Release Announcement
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 25.09.2014 12:32, Ralph A. Schmid, dk5ras wrote:
> > Hi,
> >
> > Will this also deal with the b210 issue discussed during the last days?
>
> If you're talking about the disconnect issues: As far as we know, they
> only occur on the master branch, so the maint branch should be
> unaffected. However, we're also working on that issue at the moment.
>
> > Thank you for all the continuous work on the code!
>
> You're very welcome! Expect more improvements in the future!
>
> Cheers,
> Martin
>
> >
> > Ralph.
> >
> >> -----Original Message-----
> >> From: USRP-users [mailto:[email protected]] On Behalf
> Of Martin Braun via USRP-users
> >> Sent: Thursday, 25 September, 2014 21:08
> >> To: '[email protected]'
> >> Subject: [USRP-users] [UHD-3.7.3-RC1] Bugfix Release Announcement
> >>
> >> Hi everyone,
> >>
> >> we'll soon be releasing another bugfix release (3.7.3) and are putting
> out a release candidate for now. It is tagged at
> >> https://github.com/EttusResearch/uhddev/tree/003_007_003_rc1.
> >>
> >> Users working off of the 'maint' branch will be automatically updated
> if you run a 'git pull'.
> >> Note: This RC includes new images, so do run uhd_images_downloader if
> you update. There is no warning or error if you don't
> >> update the images (because they are still compatible), but you won't
> benefit from the stability changes we introduced.
> >>
> >> This RC mainly includes stability issues and bugfixes. The biggest
> change is for the FPGA code, which is now easier to build.
> >>
> >> Enjoy!
> >>
> >> Martin
> >>
> >> 3.7.3-RC1 Changelog:
> >> * Fixed examples
> >> * Removed compiler warnings
> >> * Fixed CBX LO settings (FRAC truncation)
> >> * Fixed build issues for out-of-tree tools for some distros
> >> * Fixed some logging strings (SBX, GPSDO)
> >> * Improved logging (speedups, removed unnecessary cycles)
> >> * Added output sync for DAC reference clocks on X300
> >>
> >> _______________________________________________
> >> 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/20140930/7966f472/attachment-0001.html>
------------------------------
Message: 24
Date: Tue, 30 Sep 2014 11:47:43 -0400
From: [email protected]
To: Isen I-Chun Chao <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] USRP-users Digest, Vol 49, Issue 25
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I'm sure Matt would have better "crystal balling", but my personal
impression is that RFNoC is still several months away from being a
thing one might want to share with the greater community.
On 2014-09-30 11:39, Isen I-Chun Chao via USRP-users wrote:
> Hi
> Since Martin mentioned the biggest changes in FPGA code, which making it
> easier to build, I wonder if this release is the version with Network-on-Chip
> design tool, which I am currently waiting for. If so, I actually did not see
> any major change in usrp3/top/x300 in the fpga directory.
>
> Thanks
>
> Best Regards,
> Isen I-Chun Chao
> _ _
> _ _
>
>> Message: 7
>> Date: Thu, 25 Sep 2014 12:07:52 -0700
>> From: Martin Braun <[email protected]>
>> To: "'[email protected]'" <[email protected]>
>> Subject: [USRP-users] [UHD-3.7.3-RC1] Bugfix Release Announcement
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> Hi everyone,
>>
>> we'll soon be releasing another bugfix release (3.7.3) and are putting
>> out a release candidate for now. It is tagged at
>> https://github.com/EttusResearch/uhddev/tree/003_007_003_rc1 [1].
>>
>> Users working off of the 'maint' branch will be automatically updated if
>> you run a 'git pull'.
>> Note: This RC includes new images, so do run uhd_images_downloader if
>> you update. There is no warning or error if you don't update the images
>> (because they are still compatible), but you won't benefit from the
>> stability changes we introduced.
>>
>> This RC mainly includes stability issues and bugfixes. The biggest
>> change is for the FPGA code, which is now easier to build.
>>
>> Enjoy!
>>
>> Martin
>>
>> 3.7.3-RC1 Changelog:
>> * Fixed examples
>> * Removed compiler warnings
>> * Fixed CBX LO settings (FRAC truncation)
>> * Fixed build issues for out-of-tree tools for some distros
>> * Fixed some logging strings (SBX, GPSDO)
>> * Improved logging (speedups, removed unnecessary cycles)
>> * Added output sync for DAC reference clocks on X300
>>
>> ------------------------------
>>
>>> -----Original Message-----
>>> From: USRP-users [mailto:[email protected]] On Behalf Of
>>> Martin Braun via USRP-users
>>> Sent: Thursday, 25 September, 2014 21:08
>>> To: '[email protected]'
>>> Subject: [USRP-users] [UHD-3.7.3-RC1] Bugfix Release Announcement
>>>
>>> Hi everyone,
>>>
>>> we'll soon be releasing another bugfix release (3.7.3) and are putting out
>>> a release candidate for now. It is tagged at
>>> https://github.com/EttusResearch/uhddev/tree/003_007_003_rc1 [1].
>>>
>>> Users working off of the 'maint' branch will be automatically updated if
>>> you run a 'git pull'.
>>> Note: This RC includes new images, so do run uhd_images_downloader if you
>>> update. There is no warning or error if you don't
>>> update the images (because they are still compatible), but you won't
>>> benefit from the stability changes we introduced.
>>>
>>> This RC mainly includes stability issues and bugfixes. The biggest change
>>> is for the FPGA code, which is now easier to build.
>>>
>>> Enjoy!
>>>
>>> Martin
>>>
>>> 3.7.3-RC1 Changelog:
>>> * Fixed examples
>>> * Removed compiler warnings
>>> * Fixed CBX LO settings (FRAC truncation)
>>> * Fixed build issues for out-of-tree tools for some distros
>>> * Fixed some logging strings (SBX, GPSDO)
>>> * Improved logging (speedups, removed unnecessary cycles)
>>> * Added output sync for DAC reference clocks on X300
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [2]
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: PGP.sig
>> Type: application/pgp-signature
>> Size: 832 bytes
>> Desc: not available
>> URL:
>> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140925/05b99892/attachment-0001.sig
>> [3]>
>>
>> ------------------------------
>>
>> Message: 9
>> Date: Thu, 25 Sep 2014 12:42:32 -0700
>> From: Martin Braun <[email protected]>
>> To: "'[email protected]'" <[email protected]>
>> Subject: Re: [USRP-users] [UHD-3.7.3-RC1] Bugfix Release Announcement
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> My apologies, the tag is actually to be found here:
>> https://github.com/EttusResearch/uhd/tree/003_007_003_rc1 [4]
>>
>> Cheers,
>> Martin
>>
>> On 25.09.2014 12:07, Martin Braun wrote:
>>> Hi everyone,
>>>
>>> we'll soon be releasing another bugfix release (3.7.3) and are putting
>>> out a release candidate for now. It is tagged at
>>> https://github.com/EttusResearch/uhddev/tree/003_007_003_rc1 [1].
>>>
>>> Users working off of the 'maint' branch will be automatically updated if
>>> you run a 'git pull'.
>>> Note: This RC includes new images, so do run uhd_images_downloader if
>>> you update. There is no warning or error if you don't update the images
>>> (because they are still compatible), but you won't benefit from the
>>> stability changes we introduced.
>>>
>>> This RC mainly includes stability issues and bugfixes. The biggest
>>> change is for the FPGA code, which is now easier to build.
>>>
>>> Enjoy!
>>>
>>> Martin
>>>
>>> 3.7.3-RC1 Changelog:
>>> * Fixed examples
>>> * Removed compiler warnings
>>> * Fixed CBX LO settings (FRAC truncation)
>>> * Fixed build issues for out-of-tree tools for some distros
>>> * Fixed some logging strings (SBX, GPSDO)
>>> * Improved logging (speedups, removed unnecessary cycles)
>>> * Added output sync for DAC reference clocks on X300
>>
>> ------------------------------
>>
>> Message: 10
>> Date: Thu, 25 Sep 2014 12:44:41 -0700
>> From: Martin Braun <[email protected]>
>> Cc: [email protected]
>> Subject: Re: [USRP-users] [UHD-3.7.3-RC1] Bugfix Release Announcement
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 25.09.2014 12:32, Ralph A. Schmid, dk5ras wrote:
>>> Hi,
>>>
>>> Will this also deal with the b210 issue discussed during the last days?
>>
>> If you're talking about the disconnect issues: As far as we know, they
>> only occur on the master branch, so the maint branch should be
>> unaffected. However, we're also working on that issue at the moment.
>>
>>> Thank you for all the continuous work on the code!
>>
>> You're very welcome! Expect more improvements in the future!
>>
>> Cheers,
>> Martin
>>
>>>
>>> Ralph.
>>>
>>>> -----Original Message-----
>>>> From: USRP-users [mailto:[email protected]] On Behalf Of
>>>> Martin Braun via USRP-users
>>>> Sent: Thursday, 25 September, 2014 21:08
>>>> To: '[email protected]'
>>>> Subject: [USRP-users] [UHD-3.7.3-RC1] Bugfix Release Announcement
>>>>
>>>> Hi everyone,
>>>>
>>>> we'll soon be releasing another bugfix release (3.7.3) and are putting out
>>>> a release candidate for now. It is tagged at
>>>> https://github.com/EttusResearch/uhddev/tree/003_007_003_rc1 [1].
>>>>
>>>> Users working off of the 'maint' branch will be automatically updated if
>>>> you run a 'git pull'.
>>>> Note: This RC includes new images, so do run uhd_images_downloader if you
>>>> update. There is no warning or error if you don't
>>>> update the images (because they are still compatible), but you won't
>>>> benefit from the stability changes we introduced.
>>>>
>>>> This RC mainly includes stability issues and bugfixes. The biggest change
>>>> is for the FPGA code, which is now easier to build.
>>>>
>>>> Enjoy!
>>>>
>>>> Martin
>>>>
>>>> 3.7.3-RC1 Changelog:
>>>> * Fixed examples
>>>> * Removed compiler warnings
>>>> * Fixed CBX LO settings (FRAC truncation)
>>>> * Fixed build issues for out-of-tree tools for some distros
>>>> * Fixed some logging strings (SBX, GPSDO)
>>>> * Improved logging (speedups, removed unnecessary cycles)
>>>> * Added output sync for DAC reference clocks on X300
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [2]
>>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [2]
Links:
------
[1] https://github.com/EttusResearch/uhddev/tree/003_007_003_rc1
[2] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[3]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140925/05b99892/attachment-0001.sig
[4] https://github.com/EttusResearch/uhd/tree/003_007_003_rc1
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140930/cae771b7/attachment-0001.html>
------------------------------
Message: 25
Date: Tue, 30 Sep 2014 09:39:52 -0500
From: Terry Stevenson <[email protected]>
To: [email protected]
Subject: [USRP-users] B210 UHD Error
Message-ID:
<CANLZwWuy9nuu0UTEjHy1L0htH5rTHLRwgGYYqwrUZSK=7cs...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I'm using a USRP B210 and I've encountered what seems to be a driver error.
When running the uhd_fft program (packaged with GnuRadio) it will run
smoothly for a few minutes, then become very laggy, then freeze and begin
printing "UHD Error: The receive packet handler caught an exception.
RuntimeError: usb rx6 transfer status 5".
At first I was using UHD 3.7.2, and I saw that another user had a similar
problem, so I reverted to 3.7.1. Now it will run for several hours, but the
same problem eventually occurs. My motherboard chipset is Intel Z77
Express, if that helps.
Thanks,
Terry
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140930/0b21f6ad/attachment-0001.html>
------------------------------
Message: 26
Date: Tue, 30 Sep 2014 15:49:34 +0000
From: "FIXED-TERM Ghobrial Antoun (CR/AEH4)"
<[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Bandwidth limitation
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hello ,
I am using USRP N210 with LFTX and LFRX daughter boards connected with the host
computer via an Ethernet connection.
According to this tutorial provided by Ettus ,
http://www.ettus.com/kb/detail/usrp-bandwidth
I can say that bandwidth is around 20 MHz and this limit is set by the Ethernet
connection.
Here , I have a question :
For each LFTX and LFRX , there are two antenna (or two channel A & B).
If I am using only one channel (A or B) from each daughterboard (One Tx channel
and one Rx channel ), Does it mean that bandwidth will remain the same to be
equal = 20 MHz or 20MHz/(No of channels) ?!
According to that, every channel should have a bandwidth below a certain value.
How can I calculate this threshold value ?!
I have the same question if I am going to use both antennas from both daughter
boards ?!
Any Suggestion !!
Mit freundlichen Gr??en / Best regards
Antoun Ghobrial
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140930/f77821f6/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 29
******************************************
