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: How to sync to external ref. AND use the MIMO cable
([email protected])
2. Re: rx_samples_to_file issue ([email protected])
3. Re: Success report: B200/USB 3.0 card/Core i7-2600
(Garver, Paul W)
4. Re: B210 USB transfer error (Garver, Paul W)
5. Re: Success report: B200/USB 3.0 card/Core i7-2600 (Martin Braun)
6. Re: Remov MIMO-cable (Martin Braun)
7. Re: Success report: B200/USB 3.0 card/Core i7-2600
(Robert McIntyre)
8. Re: Frequency translation works differently on N210 and B210.
(Urban Hakansson)
9. Re: Frequency translation works differently on N210 and B210.
(Marcus D. Leech)
10. Re: B210 USB transfer error (Marcus D. Leech)
11. Re: Frequency translation works differently on N210 and B210.
(Ian Buckley)
12. Re: B210 UHD Error (Terry Stevenson)
13. Re: B210 USB transfer error (Simon Brown)
14. Re: Frequency translation works differently on N210 and B210.
(Urban Hakansson)
15. Re: Frequency translation works differently on N210 and B210.
(Ian Buckley)
16. Re: Frequency translation works differently on N210 and B210.
(Urban Hakansson)
17. Re: rx_samples_to_file issue (gsmandvoip)
18. Re: rx_samples_to_file issue (Marcus D. Leech)
19. Re: rx_samples_to_file issue (gsmandvoip)
20. Re: rx_samples_to_file issue (gsmandvoip)
21. Re: rx_samples_to_file issue (Marcus D. Leech)
22. Re: rx_samples_to_file issue (gsmandvoip)
23. Re: Frequency translation works differently on N210 and B210.
(Ian Buckley)
24. Re: rx_samples_to_file issue (Marcus D. Leech)
25. B200 on YouTube (Simon Brown)
26. UHD Related (Abhinav Jadon)
----------------------------------------------------------------------
Message: 1
Date: Wed, 01 Oct 2014 12:22:55 -0400
From: [email protected]
To: Thomas Hobiger <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] How to sync to external ref. AND use the
MIMO cable
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Do your spurious signals go away when you don't use the external
reference on the master?
What type of external reference are you using?
On 2014-10-01 04:44, Thomas Hobiger via USRP-users wrote:
> Hi list,
>
> I am using two N210s (each with a DBSRX2) which are connected via a MIMO
> cable.
> The master N210 is fed also with an external 10MHz.
> I am using the c++ code below, but I see so many spurious signals
> around my center freq. (1.6 GHz) which makes me think that the receiver does
> not lock
> to the external reference.
>
> usrp->set_clock_source("external", 0);
> usrp->set_clock_source("mimo", 1);
> usrp->set_time_source("mimo", 1);
>
> Am I missing something in my code or is there any other command which I need
> to issue
> in order to make my application work with an external ref AND the MIMO
> configuration?
>
> Regards,
> Thomas
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
Links:
------
[1] 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/20141001/5f21f0e1/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 01 Oct 2014 12:24:55 -0400
From: [email protected]
To: gsmandvoip <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] rx_samples_to_file issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
That actually looks like a bug in rx_samples_to_file, in that it's
checking *TX* DSP configuration, which will fail in this case because
with the 4rx image, there is no TX-side DSP at all.
On 2014-10-01 07:22, gsmandvoip via USRP-users wrote:
> Hi list,
> when I am trying to run rx_samples_to_file, with following command:
> ./rx_samples_to_file --args="fpga=usrp1_fpga_4rx.rbf" --freq "945000000"
> --rate="8000000" $FILE --nsamps
> getting following error:
>
> UHD Warning:
> Unable to set the thread priority. Performance may be negatively affected.
> Please see the general application notes in the manual for instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
>
> Creating the usrp device with: fpga=usrp1_fpga_4rx.rbf...
> -- Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
> -- Opening a USRP1 device...
> -- Loading FPGA image: /usr/share/uhd/images/usrp1_fpga_4rx.rbf... done
> -- Using FPGA clock rate of 52.000000MHz...
> Error: LookupError: IndexError: multi_usrp::get_tx_subdev_spec(0) failed to
> make default spec - ValueError: The subdevice specification "A:0" is too long.
> The user specified 1 channels, but there are only 0 tx dsps on mboard 0.
>
> Can any body throw some light, what mistake I am doing.
> I am using ubuntu 14.04, 32 bit, gnuradio, 3.7, uhd driver latest installation
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
Links:
------
[1] 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/20141001/0a6156d2/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 1 Oct 2014 12:35:30 -0400 (EDT)
From: "Garver, Paul W" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Success report: B200/USB 3.0 card/Core
i7-2600
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8
In my experience 10sec is not long enough to test if the drive can keep up for
longer recording sessions (>1min). I observe (via iostat) the kernel buffering
up the data but it won't actually write it out until a few seconds later. If
you keep streaming data, you can never write fast enough to get the average to
the required MB/sec (100MBytes/sec @ 25MSPS) I'd be curious to know if a 10
minute test results in a perfect output on your system. I ended up modifying
rx_samples_to_file to call sync_file_range() which has performed near
flawlessly at 25MSPS writing ~1TB of samples to a Samsung 840 Evo mSATA SSD at
the cost of CPU usage. I'd be curious to hear other's experiences for long
records on the B200/210.
PWG
Date: Tue, 30 Sep 2014 21:27:03 -0700
From: Robert McIntyre <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Success report: B200/USB 3.0 card/Core
i7-2600
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1256"
Ran some tests tonight...
Using:
rx_samples_to_file --rx_rate 32e6 --freq 107.7e6 --time 10 --file ./testoutput
--stats
I get either a perfect output, or one or two overflows. And, that's to either
my SSD, or my 7200 RPM SATA-6 drive. Which I didn't expect, honestly.
But, I tried:
transport_hammer --rx_rate 32e6
And had very bad results. Not sure what transport_hammer is supposed to do,
though.
Anyway, hope this helps!
Robert
To: [email protected]; [email protected]
Date: Tue, 30 Sep 2014 14:23:41 -0700
Subject: Re: [USRP-users] Success report: B200/USB 3.0 card/Core i7-2600
From: [email protected]
Not yet. I will do that tonight and report back. The disk, though, will
definitely be a concern. I've got a SSD on a SATA-6G link, but expect it to
have problems.
--Robert
From:
Martin Braun via USRP-users
Sent:
?9/?30/?2014 2:06 PM
To:
[email protected]
Subject:
Re: [USRP-users] Success report: B200/USB 3.0 card/Core i7-2600
Hey Robert,
thanks for the data! Out of curiousity, have you also tried streaming to
disk?
Cheers,
m
On 30.09.2014 12:44, Robert McIntyre via USRP-users wrote:
> Just wanted to drop a quick note about the 100% successful USB transfers
> I'm (finally) able to get with my B200. I'm using the following hardware:
>
> - Asus P8Z68 motherboard
> <http://www.newegg.com/Product/Product.aspx?Item=N82E16813131790>
> - HooToo HT-PC002 USB 3.0 card
> <http://www.amazon.com/HT-PC001-SuperSpeed-Expansion-Connector-Capacitors/dp/B00B9R59ZE/ref=sr_1_7?ie=UTF8&qid=1412105646&sr=8-7&keywords=hootoo+usb3+card>
(based
> on VIA VL805)
> - Core i7-2600 cpu
> - 16GB of RAM
> - SSD hard drive
> - OS: Debian Testing
> - UHD: Built from head of master branch
>
> I tried the onboard Intel USB 3 ports, and they weren't able to operate
> at USB 3.0 at all, they only registered the B200 as USB 2.0. So, I
> added the VL805-based USB 3.0 card, and am able to use the UHD benchmark
> tool with a --rx_rate of 32e6 with zero overruns/underflows, repeatable.
>
> I'll be setting up gnuradio shortly and loading the CPU down a bit and
> see how it works.
>
> I have the same USB 3.0 board in my windows 8.1 box (newer
> CPU/motherboard), and it works well, but still experiences some drops at
> that rate, though 16e6 is rock-solid.
>
> Hope this helps someone else get a good config set up!
>
> Cheers,
> Robert
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 4
Date: Wed, 1 Oct 2014 12:46:21 -0400 (EDT)
From: "Garver, Paul W" <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] B210 USB transfer error
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
I saw your comment about the issue not affecting the maint branch and tried it.
Initially, it worked writing ~100GB on a Sandisk Extreme II 2.5" SSD
(successfully did this 4x), but when I switched to a Samsung 840 Evo 1TB mSSD,
I saw the issue again, almost immediately. This time, though, libusb was
reporting BAD_PACKET (1).
Built maint branch commit id: 8995533832f685c4fae388c52e52b06c25a82a2b
UHD Lib reports: linux; GNU C++ version 4.8.2; Boost_105400;
UHD_003.007.002-0-g89955338
The Samsung 840 Evo power spec is 1.8A @ 3.3VDC. I wonder if that is an issue
-- unfortunately on these small form factor PCs I am using (Gigabyte BRIX Pro),
there is no spec and the vendors are usually super secretive about giving you
any real technical info. It also may be relevant to note that I believe the
2.5" SSDs are using the +5VDC rail, but the mSATAs use +3.3VDC.
PWG
----- Original Message -----
From: "Marcus D. Leech" <[email protected]>
To: "Paul W Garver" <[email protected]>
Cc: [email protected]
Sent: Monday, September 22, 2014 12:46:01 PM
Subject: Re: [USRP-users] B210 USB transfer error
On 09/22/2014 12:44 PM, Garver, Paul W wrote:
I've updated to UHD 3.7.2 with the 3.14.0 kernel. I installed from source and
downloaded the 3.7.2 images as well. After writing ~130GB @ 25MSPS I received
the same USB transfer status 5 error. Also, you asked about sample rate -- I
tried a few different values and didn't notice any difference. I haven't tried
USB2.0 - I can do this for debugging purposes but it will not be a solution for
me as I my application requires 25MSPS. I really don't have a good idea if this
is a hardware or software issue.
Thanks,
PWG
Thanks for the experiments, Paul.
Ettus R&D is currently working this issue.
<blockquote>
----- Original Message -----
From: "Marcus D. Leech" <[email protected]>
To: "Paul W Garver" <[email protected]>
Cc: "Tony Arkles" <[email protected]> , [email protected]
Sent: Friday, September 19, 2014 5:04:55 PM
Subject: Re: [USRP-users] B210 USB transfer error
<blockquote>
I tried the 3.14.0 kernel on Ubuntu 14.04 for the BRIX (UHD 3.7.1) and still
continue to see the same error message as the OP.
PWG
</blockquote>
Could you also update to UHD 3.7.2 ?
<blockquote>
----- Original Message -----
From: "Tony Arkles" <[email protected]>
To: [email protected]
Cc: "Paul W Garver" <[email protected]> , [email protected]
Sent: Friday, September 19, 2014 2:43:30 PM
Subject: Re: [USRP-users] B210 USB transfer error
I was having a similar problem on Ubuntu 14.04. Exact same error message. It
wasn't really sample rate dependent, I was seeing it at 4MS/s, which worked
fine over usb2.
I ended up upgrading to a 3.14 kernel (using ubuntu .debs from a newer version)
and it cleared up. There were notes in the change log for the kernel saying
that there were fixes for the Intel USB3 chipset.
On Sep 19, 2014, at 11:45 AM, "Marcus D. Leech via USRP-users" <
[email protected] > wrote:
<blockquote>
I'd like to understand if this is sample-rate dependent. Does it happen more
frequently at higher samples rates, or is it just dependent on
runtime? What about when on USB-2.0?
A goodly chunk of the R&D team at Ettus are on the road until Monday.
On 2014-09-19 13:29, Garver, Paul W via USRP-users wrote:
<blockquote>
I can also report I have had this exact same issue with a B200, although I
typically run rx_samples_to_file. I've also tried external power to no avail.
I've also run the B200 on the haswell Intel NUC which also has the series
8/C210 USB 3.0 controller. I haven't seen this issue yet on the NUC but I
don't have a lot of runtime on it yet.
Could you please post your results to the mailing list or can Ettus support
contact me offline? I'm very interested in the resolution to this issue.
System Info:
Gigabyte Brix GB-BXi7-4770R
Ubuntu 14.04 64 bit
Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)
PWG
Date: Fri, 19 Sep 2014 02:08:04 +0000
From: "Nowlan, Sean" < [email protected] >
To: " [email protected] " < [email protected] >
Subject: [USRP-users] B210 USB transfer error
Message-ID:
< [email protected] >
Content-Type: text/plain; charset="us-ascii"
Hi all -
I've seen this pop up now and again on this list. Basically while running an RX
operation (osmocom_fft or uhd_fft) the B210 will sporadically disconnect from
the USB 3.0 hub and then it will immediately reconnect. I can see this in dmesg
and /var/log/syslog. It was suggested to me that this may be a power brown out
issue since I have a TCXO GPSDO module mounted on board, but I observe the same
error even while connected to wall power through the standard 6V, 3A power
supply. Here is the console output I see.
UHD Error:
The receive packet handler caught an exception.
RuntimeError: usb rx6 transfer status: 5
UHD source block got error code 0xf
terminate called after throwing an instance of 'uhd::runtime_error'
what(): RuntimeError: usb tx4 submit failed: LIBUSB_ERROR_NO_DEVICE
Aborted (core dumped)
System info:
Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI
Host Controller (rev 04)
Ubuntu 14.04 LTS
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.002-94-ge56809a0?
Sean
_______________________________________________
USRP-users mailing list [email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
</blockquote>
</blockquote>
<blockquote>
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
</blockquote>
</blockquote>
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org
</blockquote>
--
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/20141001/5f976489/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 01 Oct 2014 09:48:06 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Success report: B200/USB 3.0 card/Core
i7-2600
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Thanks!
rx_samples_to_file will give you a reliable idea if you can stream to disk.
Cheers,
M
On 30.09.2014 21:27, Robert McIntyre via USRP-users wrote:
> Ran some tests tonight...
>
> Using:
>
> rx_samples_to_file --rx_rate 32e6 --freq 107.7e6 --time 10 --file
> ./testoutput --stats
>
> I get either a perfect output, or one or two overflows. And, that's to
> either my SSD, or my 7200 RPM SATA-6 drive. Which I didn't expect,
> honestly.
>
> But, I tried:
>
> transport_hammer --rx_rate 32e6
>
> And had very bad results. Not sure what transport_hammer is supposed to
> do, though.
>
> Anyway, hope this helps!
> Robert
>
> ------------------------------------------------------------------------
> To: [email protected]; [email protected]
> Date: Tue, 30 Sep 2014 14:23:41 -0700
> Subject: Re: [USRP-users] Success report: B200/USB 3.0 card/Core i7-2600
> From: [email protected]
>
> Not yet. I will do that tonight and report back. The disk, though,
> will definitely be a concern. I've got a SSD on a SATA-6G link, but
> expect it to have problems.
>
> --Robert
> ------------------------------------------------------------------------
> From: Martin Braun via USRP-users <mailto:[email protected]>
> Sent: ?9/?30/?2014 2:06 PM
> To: [email protected] <mailto:[email protected]>
> Subject: Re: [USRP-users] Success report: B200/USB 3.0 card/Core i7-2600
>
> Hey Robert,
>
> thanks for the data! Out of curiousity, have you also tried streaming to
> disk?
>
> Cheers,
> m
>
> On 30.09.2014 12:44, Robert McIntyre via USRP-users wrote:
> > Just wanted to drop a quick note about the 100% successful USB transfers
> > I'm (finally) able to get with my B200. I'm using the following
> hardware:
> >
> > - Asus P8Z68 motherboard
> > <http://www.newegg.com/Product/Product.aspx?Item=N82E16813131790>
> > - HooToo HT-PC002 USB 3.0 card
> >
> <http://www.amazon.com/HT-PC001-SuperSpeed-Expansion-Connector-Capacitors/dp/B00B9R59ZE/ref=sr_1_7?ie=UTF8&qid=1412105646&sr=8-7&keywords=hootoo+usb3+card>
> (based
> > on VIA VL805)
> > - Core i7-2600 cpu
> > - 16GB of RAM
> > - SSD hard drive
> > - OS: Debian Testing
> > - UHD: Built from head of master branch
> >
> > I tried the onboard Intel USB 3 ports, and they weren't able to operate
> > at USB 3.0 at all, they only registered the B200 as USB 2.0. So, I
> > added the VL805-based USB 3.0 card, and am able to use the UHD benchmark
> > tool with a --rx_rate of 32e6 with zero overruns/underflows, repeatable.
> >
> > I'll be setting up gnuradio shortly and loading the CPU down a bit and
> > see how it works.
> >
> > I have the same USB 3.0 board in my windows 8.1 box (newer
> > CPU/motherboard), and it works well, but still experiences some drops at
> > that rate, though 16e6 is rock-solid.
> >
> > Hope this helps someone else get a good config set up!
> >
> > Cheers,
> > Robert
> >
> >
> >
> > _______________________________________________
> > 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
>
> _______________________________________________ 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
>
------------------------------
Message: 6
Date: Wed, 01 Oct 2014 09:50:51 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Remov MIMO-cable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 01.10.2014 05:10, Per Zetterberg via USRP-users wrote:
> Hi,
>
> I have been using the MIMO cable between pairs of N210s and it has
> worked fine. Now I want to remove the cable. I tried to pull with a
> bit of force but it doesn't loose. Should I just pull harder?
Well, be careful. As you know, the cable is latched into the device,
usually there's some part of the cable you need to tug to loosen it.
Wobble it about... the usual spiel.
Hope this was any help.
Cheers,
M
------------------------------
Message: 7
Date: Wed, 1 Oct 2014 09:56:09 -0700
From: Robert McIntyre <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Success report: B200/USB 3.0 card/Core
i7-2600
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Cool. Based on other responses, I'll run a 10 minute test tonight.
--Robert
________________________________
From: Martin Braun via USRP-users<mailto:[email protected]>
Sent: ?10/?1/?2014 9:48 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] Success report: B200/USB 3.0 card/Core i7-2600
Thanks!
rx_samples_to_file will give you a reliable idea if you can stream to disk.
Cheers,
M
On 30.09.2014 21:27, Robert McIntyre via USRP-users wrote:
> Ran some tests tonight...
>
> Using:
>
> rx_samples_to_file --rx_rate 32e6 --freq 107.7e6 --time 10 --file
> ./testoutput --stats
>
> I get either a perfect output, or one or two overflows. And, that's to
> either my SSD, or my 7200 RPM SATA-6 drive. Which I didn't expect,
> honestly.
>
> But, I tried:
>
> transport_hammer --rx_rate 32e6
>
> And had very bad results. Not sure what transport_hammer is supposed to
> do, though.
>
> Anyway, hope this helps!
> Robert
>
> ------------------------------------------------------------------------
> To: [email protected]; [email protected]
> Date: Tue, 30 Sep 2014 14:23:41 -0700
> Subject: Re: [USRP-users] Success report: B200/USB 3.0 card/Core i7-2600
> From: [email protected]
>
> Not yet. I will do that tonight and report back. The disk, though,
> will definitely be a concern. I've got a SSD on a SATA-6G link, but
> expect it to have problems.
>
> --Robert
> ------------------------------------------------------------------------
> From: Martin Braun via USRP-users <mailto:[email protected]>
> Sent: ?9/?30/?2014 2:06 PM
> To: [email protected] <mailto:[email protected]>
> Subject: Re: [USRP-users] Success report: B200/USB 3.0 card/Core i7-2600
>
> Hey Robert,
>
> thanks for the data! Out of curiousity, have you also tried streaming to
> disk?
>
> Cheers,
> m
>
> On 30.09.2014 12:44, Robert McIntyre via USRP-users wrote:
> > Just wanted to drop a quick note about the 100% successful USB transfers
> > I'm (finally) able to get with my B200. I'm using the following
> hardware:
> >
> > - Asus P8Z68 motherboard
> > <http://www.newegg.com/Product/Product.aspx?Item=N82E16813131790>
> > - HooToo HT-PC002 USB 3.0 card
> >
> <http://www.amazon.com/HT-PC001-SuperSpeed-Expansion-Connector-Capacitors/dp/B00B9R59ZE/ref=sr_1_7?ie=UTF8&qid=1412105646&sr=8-7&keywords=hootoo+usb3+card>
> (based
> > on VIA VL805)
> > - Core i7-2600 cpu
> > - 16GB of RAM
> > - SSD hard drive
> > - OS: Debian Testing
> > - UHD: Built from head of master branch
> >
> > I tried the onboard Intel USB 3 ports, and they weren't able to operate
> > at USB 3.0 at all, they only registered the B200 as USB 2.0. So, I
> > added the VL805-based USB 3.0 card, and am able to use the UHD benchmark
> > tool with a --rx_rate of 32e6 with zero overruns/underflows, repeatable.
> >
> > I'll be setting up gnuradio shortly and loading the CPU down a bit and
> > see how it works.
> >
> > I have the same USB 3.0 board in my windows 8.1 box (newer
> > CPU/motherboard), and it works well, but still experiences some drops at
> > that rate, though 16e6 is rock-solid.
> >
> > Hope this helps someone else get a good config set up!
> >
> > Cheers,
> > Robert
> >
> >
> >
> > _______________________________________________
> > 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
>
> _______________________________________________ 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
>
_______________________________________________
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/20141001/c8d7a4bf/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 1 Oct 2014 13:33:14 -0400 (EDT)
From: Urban Hakansson <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Frequency translation works differently on
N210 and B210.
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
First, thank you for responding so promptly. I attach the Gnu Radio flow-graph
and the generated python script. It contains two USRP sink objects, one
configured for the B210 and the other for the N210. FYI, I use GnuRadio
companinion 3.7.1.1 and 3.7.2.2.
I also attach two example images from the spectrum analyzer looking at the
spectrum from the B210.
Image 1) B210 master clock rate = 5MHz, Sampling rate = 5 MHz, frequency of
complex exponential = 1.2 MHz, center frequency = 800MHz.
No replica at fc-f. As expected.
Image 2) B210 master clock rate = 5MHz, Sampling rate = 2 MHz, frequency of
complex exponential = 750 kHz, center frequency = 800MHz.
Replica at fc-f.
The result from the N210 is a replica at fc-f as well so I don't include a
image.
Regards,
Urban Hakansson
----- Original Message -----
From: "Marcus D. Leech via USRP-users" <[email protected]>
To: [email protected]
Sent: Tuesday, September 30, 2014 8:11:34 PM
Subject: Re: [USRP-users] Frequency translation works differently on N210 and
B210.
On 09/30/2014 06:20 PM, Urban Hakansson via USRP-users wrote:
> Hi everybody,
>
> I have a problem. I include below 1) General information, 2) Introduction to
> my problem 3) Detailed description of my problem.
>
> General background information about my environment:
> Fedora 17 Linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5);
> Boost_104800; UHD_003.007.001-0-unknown
>
> N210 informationfrom uhd_usrp_probe:
> | Device: USRP2 / N-Series Device
> | _____________________________________________________
> | /
> | | Mboard: N210r4
> | | hardware: 2577
> | | mac-addr: 00:80:2f:0a:e6:15
> | | ip-addr: 192.168.2.199
> | | subnet: 255.255.255.255
> | | gateway: 255.255.255.255
> | | gpsdo: none
> | | serial: F4A09C
> | | FW Version: 12.4
> | | FPGA Version: 10.1
>
> B210 information from uhd_usrp_probe:
> | Device: B-Series Device
> | _____________________________________________________
> | /
> | | Mboard: B210
> | | revision: 4
> | | product: 2
> | | serial: F571B5
> | | FW Version: 4.0
> | | FPGA Version: 3.0
>
>
> Introduction/background: It is my understanding that outputting a real-valued
> baseband signal x(t) = a*sin(2*pi*f*t) on an RF carrier fc should result in
> two components at fc+f and fc-f, but outputting a complex-valued baseband
> signal x(t) = exp(2*pi*f*t) should only result in an fc+f component. The
> complex exponential can be used for frequency translation but is causing me
> serious problems on the N210 + SBX daughterboard.
>
> Detailed Problem Description: Using GnuRadio I output a simple baseband
> complex exponential at frequency +f centered at the RF center frequency fc.
> Now on the N210 in addition to the sinusoid at fc+f there is a unexpected
> replica at fc-f about 13-14 dB below fc+f. When I run the same script on the
> B210 and set master clock rate equal to the sample clock rate, I only see the
> desired frequency component at fc+f. There is no replica at fc-f as in the
> case of the N210. This is the correct behaviour as I understand it. However,
> if I don't set the master clock rate equal to the sample rate on the B210 I
> do get the undesired replica at fc-f 13-14 dB below the signal at fc+f just
> as I did on the N210.
>
> Why does it only work if the master clock rate is set equal to the sample
> clock rate on the B210? I have read somewhere on the mailing list that the
> FPGA including CIC and HB filters are bypassed in this case.
>
> Question: How can I output a simple complex-valued baseband signal x(t) =
> exp(2*pi*f*t) on an RF carrier fc on the N210 and only get an fc+f component
> so I can use this mechanism to perform frequency translation?
>
> Thanks for you consideration.
>
> Regards,
>
> Urban Hakansson
>
>
>
> This e-mail may contain privileged, confidential, copyrighted or other
> legally protected information, and is intended exclusively for the intended
> recipient. If you are not the intended recipient (even if the e-mail address
> above is yours), you may not review, store, use, copy, disclose or retransmit
> it in any form. If you are not the intended recipient or otherwise have
> received this by mistake, please immediately notify the sender by return
> e-mail (or [email protected]), then delete the message in its entirety.
> Thank you.
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Could you perhaps share your Gnu Radio flow-graph with us? It would
help in seeing where your problems might originate.
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
This
e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected]), then delete the message in its entirety. Thank you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: complex_exp.grc
Type: application/xml
Size: 34500 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141001/e0ea37b2/attachment-0001.grc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: complex_exp.py
Type: text/x-python
Size: 6404 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141001/e0ea37b2/attachment-0001.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: B210_specA_Fs2MHz_750kHz.JPG
Type: image/jpeg
Size: 98117 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141001/e0ea37b2/attachment-0002.JPG>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: B210_specA_Fs5MHz_f1.2MHz.JPG
Type: image/jpeg
Size: 66093 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141001/e0ea37b2/attachment-0003.JPG>
------------------------------
Message: 9
Date: Wed, 01 Oct 2014 14:13:44 -0400
From: "Marcus D. Leech" <[email protected]>
To: Urban Hakansson <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Frequency translation works differently on
N210 and B210.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 10/01/2014 01:33 PM, Urban Hakansson wrote:
> First, thank you for responding so promptly. I attach the Gnu Radio
> flow-graph and the generated python script. It contains two USRP sink
> objects, one configured for the B210 and the other for the N210. FYI, I use
> GnuRadio companinion 3.7.1.1 and 3.7.2.2.
>
> I also attach two example images from the spectrum analyzer looking at the
> spectrum from the B210.
>
> Image 1) B210 master clock rate = 5MHz, Sampling rate = 5 MHz, frequency of
> complex exponential = 1.2 MHz, center frequency = 800MHz.
> No replica at fc-f. As expected.
>
> Image 2) B210 master clock rate = 5MHz, Sampling rate = 2 MHz, frequency of
> complex exponential = 750 kHz, center frequency = 800MHz.
> Replica at fc-f.
>
> The result from the N210 is a replica at fc-f as well so I don't include a
> image.
>
> Regards,
>
> Urban Hakansson
I'll take a look at this sometime this evening.
>
> ----- Original Message -----
> From: "Marcus D. Leech via USRP-users" <[email protected]>
> To: [email protected]
> Sent: Tuesday, September 30, 2014 8:11:34 PM
> Subject: Re: [USRP-users] Frequency translation works differently on N210 and
> B210.
>
> On 09/30/2014 06:20 PM, Urban Hakansson via USRP-users wrote:
>> Hi everybody,
>>
>> I have a problem. I include below 1) General information, 2) Introduction to
>> my problem 3) Detailed description of my problem.
>>
>> General background information about my environment:
>> Fedora 17 Linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5);
>> Boost_104800; UHD_003.007.001-0-unknown
>>
>> N210 informationfrom uhd_usrp_probe:
>> | Device: USRP2 / N-Series Device
>> | _____________________________________________________
>> | /
>> | | Mboard: N210r4
>> | | hardware: 2577
>> | | mac-addr: 00:80:2f:0a:e6:15
>> | | ip-addr: 192.168.2.199
>> | | subnet: 255.255.255.255
>> | | gateway: 255.255.255.255
>> | | gpsdo: none
>> | | serial: F4A09C
>> | | FW Version: 12.4
>> | | FPGA Version: 10.1
>>
>> B210 information from uhd_usrp_probe:
>> | Device: B-Series Device
>> | _____________________________________________________
>> | /
>> | | Mboard: B210
>> | | revision: 4
>> | | product: 2
>> | | serial: F571B5
>> | | FW Version: 4.0
>> | | FPGA Version: 3.0
>>
>>
>> Introduction/background: It is my understanding that outputting a
>> real-valued baseband signal x(t) = a*sin(2*pi*f*t) on an RF carrier fc
>> should result in two components at fc+f and fc-f, but outputting a
>> complex-valued baseband signal x(t) = exp(2*pi*f*t) should only result in an
>> fc+f component. The complex exponential can be used for frequency
>> translation but is causing me serious problems on the N210 + SBX
>> daughterboard.
>>
>> Detailed Problem Description: Using GnuRadio I output a simple baseband
>> complex exponential at frequency +f centered at the RF center frequency fc.
>> Now on the N210 in addition to the sinusoid at fc+f there is a unexpected
>> replica at fc-f about 13-14 dB below fc+f. When I run the same script on the
>> B210 and set master clock rate equal to the sample clock rate, I only see
>> the desired frequency component at fc+f. There is no replica at fc-f as in
>> the case of the N210. This is the correct behaviour as I understand it.
>> However, if I don't set the master clock rate equal to the sample rate on
>> the B210 I do get the undesired replica at fc-f 13-14 dB below the signal at
>> fc+f just as I did on the N210.
>>
>> Why does it only work if the master clock rate is set equal to the sample
>> clock rate on the B210? I have read somewhere on the mailing list that the
>> FPGA including CIC and HB filters are bypassed in this case.
>>
>> Question: How can I output a simple complex-valued baseband signal x(t) =
>> exp(2*pi*f*t) on an RF carrier fc on the N210 and only get an fc+f component
>> so I can use this mechanism to perform frequency translation?
>>
>> Thanks for you consideration.
>>
>> Regards,
>>
>> Urban Hakansson
>>
>>
>>
>> This e-mail may contain privileged, confidential, copyrighted or other
>> legally protected information, and is intended exclusively for the intended
>> recipient. If you are not the intended recipient (even if the e-mail
>> address above is yours), you may not review, store, use, copy, disclose or
>> retransmit it in any form. If you are not the intended recipient or
>> otherwise have received this by mistake, please immediately notify the
>> sender by return e-mail (or [email protected]), then delete the message in
>> its entirety. Thank you.
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> Could you perhaps share your Gnu Radio flow-graph with us? It would
> help in seeing where your problems might originate.
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> This e-mail may contain privileged, confidential, copyrighted or other
> legally protected information, and is intended exclusively for the intended
> recipient. If you are not the intended recipient (even if the e-mail address
> above is yours), you may not review, store, use, copy, disclose or retransmit
> it in any form. If you are not the intended recipient or otherwise have
> received this by mistake, please immediately notify the sender by return
> e-mail (or [email protected]), then delete the message in its entirety.
> Thank you.
------------------------------
Message: 10
Date: Wed, 01 Oct 2014 14:16:20 -0400
From: "Marcus D. Leech" <[email protected]>
To: "Garver, Paul W" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 USB transfer error
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 10/01/2014 01:08 PM, Garver, Paul W wrote:
> I'm using bus power since I, like the OP, had the same issue and
> external power didn't make a difference in the initial
> troubleshooting. I think the drives could make a difference,
> especially since the 2.5" and mSSD/mSATA are on different rails. Say
> the USB 3.0 controller on the motherboard is running on the 3.3VDC
> rail and the Samsung 840 is pulling enough current to max out the spec
> on that rail. But the 2.5" would be fine since it uses the +5VDC
> rail. Unfortunately, without the spec (which we won't get from
> Gigabyte) we won't know. This could happen regardless of how the B200
> is powered.
>
> For clarification, I'm using the B200 not B210.
>
> Just a thought -- thanks for your help and I hope we can resolve this
> issue soon!
>
> PWG
The fact that different hard-disk hardware makes a difference indicates
to me that this is a "systems" issue, rather than one relating directly
to the B2xx hardware.
I can't remember whether you forwarded an lscpi -vv listing to the
list. That can help identify what the different bits of hardware might
be that
could be involved.
> ------------------------------------------------------------------------
> *From: *[email protected]
> *To: *"Paul W Garver" <[email protected]>
> *Sent: *Wednesday, October 1, 2014 12:53:27 PM
> *Subject: *Re: [USRP-users] B210 USB transfer error
>
> Not sure why/how changing disk drives can affect the performance of
> the USB subsystem, particularly if you're using the external
>
> power supply on the B210.
>
> Unless the machine has some kind of SATA-to-USB bridge internally, and
> that controller is shared with the B210.
>
> On 2014-10-01 12:46, Garver, Paul W wrote:
>
> I saw your comment about the issue not affecting the maint branch
> and tried it. Initially, it worked writing ~100GB on a Sandisk
> Extreme II 2.5" SSD (successfully did this 4x), but when I
> switched to a Samsung 840 Evo 1TB mSSD, I saw the issue again,
> almost immediately. This time, though, libusb was reporting
> BAD_PACKET (1).
> Built maint branch commit id:
> 8995533832f685c4fae388c52e52b06c25a82a2b
> UHD Lib reports: linux; GNU C++ version 4.8.2; Boost_105400;
> UHD_003.007.002-0-g89955338
> The Samsung 840 Evo power spec is 1.8A @ 3.3VDC. I wonder if that
> is an issue -- unfortunately on these small form factor PCs I am
> using (Gigabyte BRIX Pro), there is no spec and the vendors are
> usually super secretive about giving you any real technical info.
> It also may be relevant to note that I believe the 2.5" SSDs are
> using the +5VDC rail, but the mSATAs use +3.3VDC.
> PWG
>
> ------------------------------------------------------------------------
> *From: *"Marcus D. Leech" <[email protected]>
> *To: *"Paul W Garver" <[email protected]>
> *Cc: *[email protected]
> *Sent: *Monday, September 22, 2014 12:46:01 PM
> *Subject: *Re: [USRP-users] B210 USB transfer error
>
> On 09/22/2014 12:44 PM, Garver, Paul W wrote:
>
> I've updated to UHD 3.7.2 with the 3.14.0 kernel. I installed
> from source and downloaded the 3.7.2 images as well. After
> writing ~130GB @ 25MSPS I received the same USB transfer
> status 5 error. Also, you asked about sample rate -- I tried
> a few different values and didn't notice any difference. I
> haven't tried USB2.0 - I can do this for debugging purposes
> but it will not be a solution for me as I my application
> requires 25MSPS. I really don't have a good idea if this is a
> hardware or software issue.
> Thanks,
> PWG
>
> Thanks for the experiments, Paul.
>
> Ettus R&D is currently working this issue.
>
>
>
> ------------------------------------------------------------------------
> *From: *"Marcus D. Leech" <[email protected]>
> *To: *"Paul W Garver" <[email protected]>
> *Cc: *"Tony Arkles" <[email protected]>,
> [email protected]
> *Sent: *Friday, September 19, 2014 5:04:55 PM
> *Subject: *Re: [USRP-users] B210 USB transfer error
>
> I tried the 3.14.0 kernel on Ubuntu 14.04 for the BRIX
> (UHD 3.7.1) and still continue to see the same error
> message as the OP.
> PWG
>
> Could you also update to UHD 3.7.2 ?
>
>
>
>
> ------------------------------------------------------------------------
> *From: *"Tony Arkles" <[email protected]>
> *To: *[email protected]
> *Cc: *"Paul W Garver" <[email protected]>,
> [email protected]
> *Sent: *Friday, September 19, 2014 2:43:30 PM
> *Subject: *Re: [USRP-users] B210 USB transfer error
>
> I was having a similar problem on Ubuntu 14.04. Exact same
> error message. It wasn't really sample rate dependent, I
> was seeing it at 4MS/s, which worked fine over usb2.
> I ended up upgrading to a 3.14 kernel (using ubuntu .debs
> from a newer version) and it cleared up. There were notes
> in the change log for the kernel saying that there were
> fixes for the Intel USB3 chipset.
>
> On Sep 19, 2014, at 11:45 AM, "Marcus D. Leech via
> USRP-users" <[email protected]
> <mailto:[email protected]>> wrote:
>
> I'd like to understand if this is sample-rate
> dependent. Does it happen more frequently at higher
> samples rates, or is it just dependent on
>
> runtime? What about when on USB-2.0?
>
> A goodly chunk of the R&D team at Ettus are on the
> road until Monday.
>
> On 2014-09-19 13:29, Garver, Paul W via USRP-users wrote:
>
> I can also report I have had this exact same issue with a
> B200, although I typically run rx_samples_to_file. I've also tried external
> power to no avail. I've also run the B200 on the haswell Intel NUC which
> also has the series 8/C210 USB 3.0 controller. I haven't seen this issue yet
> on the NUC but I don't have a lot of runtime on it yet.
>
> Could you please post your results to the mailing list or
> can Ettus support contact me offline? I'm very interested in the resolution
> to this issue.
>
> System Info:
> Gigabyte Brix GB-BXi7-4770R
> Ubuntu 14.04 64 bit
> Intel Corporation 8 Series/C220 Series Chipset Family USB
> xHCI (rev 05)
>
> PWG
>
> Date: Fri, 19 Sep 2014 02:08:04 +0000
> From: "Nowlan, Sean" <[email protected]
> <mailto:[email protected]>>
> To: "[email protected]
> <mailto:[email protected]>" <[email protected]
> <mailto:[email protected]>>
> Subject: [USRP-users] B210 USB transfer error
> Message-ID:
>
> <[email protected]
> <mailto:[email protected]>>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi all -
>
>
> I've seen this pop up now and again on this list.
> Basically while running an RX operation (osmocom_fft or uhd_fft) the B210
> will sporadically disconnect from the USB 3.0 hub and then it will
> immediately reconnect. I can see this in dmesg and /var/log/syslog. It was
> suggested to me that this may be a power brown out issue since I have a TCXO
> GPSDO module mounted on board, but I observe the same error even while
> connected to wall power through the standard 6V, 3A power supply. Here is the
> console output I see.
>
>
> UHD Error:
> The receive packet handler caught an exception.
> RuntimeError: usb rx6 transfer status: 5
> UHD source block got error code 0xf
> terminate called after throwing an instance of
> 'uhd::runtime_error'
> what(): RuntimeError: usb tx4 submit failed:
> LIBUSB_ERROR_NO_DEVICE
> Aborted (core dumped)
>
> System info:
> Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
> USB controller: Intel Corporation 7 Series/C210 Series
> Chipset Family USB xHCI Host Controller (rev 04)
> Ubuntu 14.04 LTS
> linux; GNU C++ version 4.8.2; Boost_105400;
> UHD_003.007.002-94-ge56809a0?
>
> Sean
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> <mailto:[email protected]>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> 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
>
>
>
> --
> 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/20141001/cba0b0af/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 1 Oct 2014 11:20:34 -0700
From: Ian Buckley <[email protected]>
To: Urban Hakansson <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Frequency translation works differently on
N210 and B210.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Urban, a quick question?I just glanced at your flow graph, it's very simple?I'm
wondering where did the sample rate conversion occur (2MHz->5MHz) in your
example 2) quoted below? There is no re-sampling block instantiated in your
flow graph.
On Oct 1, 2014, at 10:33 AM, Urban Hakansson via USRP-users
<[email protected]> wrote:
> First, thank you for responding so promptly. I attach the Gnu Radio
> flow-graph and the generated python script. It contains two USRP sink
> objects, one configured for the B210 and the other for the N210. FYI, I use
> GnuRadio companinion 3.7.1.1 and 3.7.2.2.
>
> I also attach two example images from the spectrum analyzer looking at the
> spectrum from the B210.
>
> Image 1) B210 master clock rate = 5MHz, Sampling rate = 5 MHz, frequency of
> complex exponential = 1.2 MHz, center frequency = 800MHz.
> No replica at fc-f. As expected.
>
> Image 2) B210 master clock rate = 5MHz, Sampling rate = 2 MHz, frequency of
> complex exponential = 750 kHz, center frequency = 800MHz.
> Replica at fc-f.
>
> The result from the N210 is a replica at fc-f as well so I don't include a
> image.
>
> Regards,
>
> Urban Hakansson
>
> ----- Original Message -----
> From: "Marcus D. Leech via USRP-users" <[email protected]>
> To: [email protected]
> Sent: Tuesday, September 30, 2014 8:11:34 PM
> Subject: Re: [USRP-users] Frequency translation works differently on N210 and
> B210.
>
> On 09/30/2014 06:20 PM, Urban Hakansson via USRP-users wrote:
>> Hi everybody,
>>
>> I have a problem. I include below 1) General information, 2) Introduction to
>> my problem 3) Detailed description of my problem.
>>
>> General background information about my environment:
>> Fedora 17 Linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5);
>> Boost_104800; UHD_003.007.001-0-unknown
>>
>> N210 informationfrom uhd_usrp_probe:
>> | Device: USRP2 / N-Series Device
>> | _____________________________________________________
>> | /
>> | | Mboard: N210r4
>> | | hardware: 2577
>> | | mac-addr: 00:80:2f:0a:e6:15
>> | | ip-addr: 192.168.2.199
>> | | subnet: 255.255.255.255
>> | | gateway: 255.255.255.255
>> | | gpsdo: none
>> | | serial: F4A09C
>> | | FW Version: 12.4
>> | | FPGA Version: 10.1
>>
>> B210 information from uhd_usrp_probe:
>> | Device: B-Series Device
>> | _____________________________________________________
>> | /
>> | | Mboard: B210
>> | | revision: 4
>> | | product: 2
>> | | serial: F571B5
>> | | FW Version: 4.0
>> | | FPGA Version: 3.0
>>
>>
>> Introduction/background: It is my understanding that outputting a
>> real-valued baseband signal x(t) = a*sin(2*pi*f*t) on an RF carrier fc
>> should result in two components at fc+f and fc-f, but outputting a
>> complex-valued baseband signal x(t) = exp(2*pi*f*t) should only result in an
>> fc+f component. The complex exponential can be used for frequency
>> translation but is causing me serious problems on the N210 + SBX
>> daughterboard.
>>
>> Detailed Problem Description: Using GnuRadio I output a simple baseband
>> complex exponential at frequency +f centered at the RF center frequency fc.
>> Now on the N210 in addition to the sinusoid at fc+f there is a unexpected
>> replica at fc-f about 13-14 dB below fc+f. When I run the same script on the
>> B210 and set master clock rate equal to the sample clock rate, I only see
>> the desired frequency component at fc+f. There is no replica at fc-f as in
>> the case of the N210. This is the correct behaviour as I understand it.
>> However, if I don't set the master clock rate equal to the sample rate on
>> the B210 I do get the undesired replica at fc-f 13-14 dB below the signal at
>> fc+f just as I did on the N210.
>>
>> Why does it only work if the master clock rate is set equal to the sample
>> clock rate on the B210? I have read somewhere on the mailing list that the
>> FPGA including CIC and HB filters are bypassed in this case.
>>
>> Question: How can I output a simple complex-valued baseband signal x(t) =
>> exp(2*pi*f*t) on an RF carrier fc on the N210 and only get an fc+f component
>> so I can use this mechanism to perform frequency translation?
>>
>> Thanks for you consideration.
>>
>> Regards,
>>
>> Urban Hakansson
>>
>>
>>
>> This e-mail may contain privileged, confidential, copyrighted or other
>> legally protected information, and is intended exclusively for the intended
>> recipient. If you are not the intended recipient (even if the e-mail
>> address above is yours), you may not review, store, use, copy, disclose or
>> retransmit it in any form. If you are not the intended recipient or
>> otherwise have received this by mistake, please immediately notify the
>> sender by return e-mail (or [email protected]), then delete the message in
>> its entirety. Thank you.
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> Could you perhaps share your Gnu Radio flow-graph with us? It would
> help in seeing where your problems might originate.
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> This e-mail may contain privileged, confidential, copyrighted or other
> legally protected information, and is intended exclusively for the intended
> recipient. If you are not the intended recipient (even if the e-mail address
> above is yours), you may not review, store, use, copy, disclose or retransmit
> it in any form. If you are not the intended recipient or otherwise have
> received this by mistake, please immediately notify the sender by return
> e-mail (or [email protected]), then delete the message in its entirety.
> Thank
> you.<complex_exp.grc><complex_exp.py><B210_specA_Fs2MHz_750kHz.JPG><B210_specA_Fs5MHz_f1.2MHz.JPG>_______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 12
Date: Wed, 1 Oct 2014 13:24:37 -0500
From: Terry Stevenson <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B210 UHD Error
Message-ID:
<canlzwwt+nf66b2glprebtfx4h0cklytxgmhpw-r00wutte3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Martin,
The behavior seems to be rate dependent (like you said, it happens sooner
at a higher data rate), but I haven't kept data on that, so I can't be
sure. We're using USB3, and it's a B210 rev5.
Thanks,
Terry
Message: 2
> Date: Tue, 30 Sep 2014 09:10:54 -0700
> From: Martin Braun <[email protected]>
> To: [email protected]
> Subject: Re: [USRP-users] B210 UHD Error
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Terry,
>
> thanks, this is useful information. We are currently working on this
> bug, but unfortunately, it only occurs with some B-Series boards, and
> any bug that occurs once every couple of hours is hard to debug.
>
> Could you please help us by providing additional info:
>
> - Is this behaviour rate-dependent? Does it happen more easily at high
> rates?
> - You are connected to USB 3, I presume?
> - Which rev board do you have?
> - Just to be sure: You have a B210, and not a B200, right?
>
> Thanks for your help with this -- any datapoint we get will accelerate
> any solution we can come up with.
>
> Cheers,
> m
>
> On 30.09.2014 07:39, Terry Stevenson via USRP-users wrote:
> > 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
> >
> >
> > _______________________________________________
> > 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/20141001/42135a07/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 1 Oct 2014 19:28:30 +0100
From: "Simon Brown" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] B210 USB transfer error
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Marcus,
Just FWIW on my main Windows development system, using my CUDA card in anger
for heavy-duty FFT with a *lot* of overlaps affects the USB 3 throughput
significantly ? the USB 3 seems to want all the bus for itself and doesn?t like
other activity.
Simon Brown G4ELI
http://v2.sdr-radio.com
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus D. Leech via USRP-users
The fact that different hard-disk hardware makes a difference indicates to me
that this is a "systems" issue, rather than one relating directly
to the B2xx hardware.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141001/bf0c892f/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 1 Oct 2014 14:41:56 -0400 (EDT)
From: Urban Hakansson <[email protected]>
To: Ian Buckley <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Frequency translation works differently on
N210 and B210.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Ian,
Thanks for taking a look at this problem. There is no sample rate conversion
2MHz->5MHz taking place. I executed the same flow graph for two different
sample rates. The master clock rate was set to 5 MHz in both cases.
Case 1) The sample rate was set to 5 MHz (equal to the master clock rate).
Case 2) The sample rate was set to 2 MHz (not equal to the master clock rate).
Urban
----- Original Message -----
From: "Ian Buckley" <[email protected]>
To: "Urban Hakansson" <[email protected]>
Cc: "Marcus D. Leech" <[email protected]>, [email protected]
Sent: Wednesday, October 1, 2014 2:20:34 PM
Subject: Re: [USRP-users] Frequency translation works differently on N210 and
B210.
Urban, a quick question?I just glanced at your flow graph, it's very simple?I'm
wondering where did the sample rate conversion occur (2MHz->5MHz) in your
example 2) quoted below? There is no re-sampling block instantiated in your
flow graph.
On Oct 1, 2014, at 10:33 AM, Urban Hakansson via USRP-users
<[email protected]> wrote:
> First, thank you for responding so promptly. I attach the Gnu Radio
> flow-graph and the generated python script. It contains two USRP sink
> objects, one configured for the B210 and the other for the N210. FYI, I use
> GnuRadio companinion 3.7.1.1 and 3.7.2.2.
>
> I also attach two example images from the spectrum analyzer looking at the
> spectrum from the B210.
>
> Image 1) B210 master clock rate = 5MHz, Sampling rate = 5 MHz, frequency of
> complex exponential = 1.2 MHz, center frequency = 800MHz.
> No replica at fc-f. As expected.
>
> Image 2) B210 master clock rate = 5MHz, Sampling rate = 2 MHz, frequency of
> complex exponential = 750 kHz, center frequency = 800MHz.
> Replica at fc-f.
>
> The result from the N210 is a replica at fc-f as well so I don't include a
> image.
>
> Regards,
>
> Urban Hakansson
>
> ----- Original Message -----
> From: "Marcus D. Leech via USRP-users" <[email protected]>
> To: [email protected]
> Sent: Tuesday, September 30, 2014 8:11:34 PM
> Subject: Re: [USRP-users] Frequency translation works differently on N210 and
> B210.
>
> On 09/30/2014 06:20 PM, Urban Hakansson via USRP-users wrote:
>> Hi everybody,
>>
>> I have a problem. I include below 1) General information, 2) Introduction to
>> my problem 3) Detailed description of my problem.
>>
>> General background information about my environment:
>> Fedora 17 Linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5);
>> Boost_104800; UHD_003.007.001-0-unknown
>>
>> N210 informationfrom uhd_usrp_probe:
>> | Device: USRP2 / N-Series Device
>> | _____________________________________________________
>> | /
>> | | Mboard: N210r4
>> | | hardware: 2577
>> | | mac-addr: 00:80:2f:0a:e6:15
>> | | ip-addr: 192.168.2.199
>> | | subnet: 255.255.255.255
>> | | gateway: 255.255.255.255
>> | | gpsdo: none
>> | | serial: F4A09C
>> | | FW Version: 12.4
>> | | FPGA Version: 10.1
>>
>> B210 information from uhd_usrp_probe:
>> | Device: B-Series Device
>> | _____________________________________________________
>> | /
>> | | Mboard: B210
>> | | revision: 4
>> | | product: 2
>> | | serial: F571B5
>> | | FW Version: 4.0
>> | | FPGA Version: 3.0
>>
>>
>> Introduction/background: It is my understanding that outputting a
>> real-valued baseband signal x(t) = a*sin(2*pi*f*t) on an RF carrier fc
>> should result in two components at fc+f and fc-f, but outputting a
>> complex-valued baseband signal x(t) = exp(2*pi*f*t) should only result in an
>> fc+f component. The complex exponential can be used for frequency
>> translation but is causing me serious problems on the N210 + SBX
>> daughterboard.
>>
>> Detailed Problem Description: Using GnuRadio I output a simple baseband
>> complex exponential at frequency +f centered at the RF center frequency fc.
>> Now on the N210 in addition to the sinusoid at fc+f there is a unexpected
>> replica at fc-f about 13-14 dB below fc+f. When I run the same script on the
>> B210 and set master clock rate equal to the sample clock rate, I only see
>> the desired frequency component at fc+f. There is no replica at fc-f as in
>> the case of the N210. This is the correct behaviour as I understand it.
>> However, if I don't set the master clock rate equal to the sample rate on
>> the B210 I do get the undesired replica at fc-f 13-14 dB below the signal at
>> fc+f just as I did on the N210.
>>
>> Why does it only work if the master clock rate is set equal to the sample
>> clock rate on the B210? I have read somewhere on the mailing list that the
>> FPGA including CIC and HB filters are bypassed in this case.
>>
>> Question: How can I output a simple complex-valued baseband signal x(t) =
>> exp(2*pi*f*t) on an RF carrier fc on the N210 and only get an fc+f component
>> so I can use this mechanism to perform frequency translation?
>>
>> Thanks for you consideration.
>>
>> Regards,
>>
>> Urban Hakansson
>>
>>
>>
>> This e-mail may contain privileged, confidential, copyrighted or other
>> legally protected information, and is intended exclusively for the intended
>> recipient. If you are not the intended recipient (even if the e-mail
>> address above is yours), you may not review, store, use, copy, disclose or
>> retransmit it in any form. If you are not the intended recipient or
>> otherwise have received this by mistake, please immediately notify the
>> sender by return e-mail (or [email protected]), then delete the message in
>> its entirety. Thank you.
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> Could you perhaps share your Gnu Radio flow-graph with us? It would
> help in seeing where your problems might originate.
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> This e-mail may contain privileged, confidential, copyrighted or other
> legally protected information, and is intended exclusively for the intended
> recipient. If you are not the intended recipient (even if the e-mail address
> above is yours), you may not review, store, use, copy, disclose or retransmit
> it in any form. If you are not the intended recipient or otherwise have
> received this by mistake, please immediately notify the sender by return
> e-mail (or [email protected]), then delete the message in its entirety.
> Thank
> you.<complex_exp.grc><complex_exp.py><B210_specA_Fs2MHz_750kHz.JPG><B210_specA_Fs5MHz_f1.2MHz.JPG>_______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
This
e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected]), then delete the message in its entirety. Thank you.
------------------------------
Message: 15
Date: Wed, 1 Oct 2014 11:53:04 -0700
From: Ian Buckley <[email protected]>
To: Urban Hakansson <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Frequency translation works differently on
N210 and B210.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Did you note the warnings that this generates? The USRP's can not perform
fractional rate conversions. Your sample rate was coerced to be compatible with
a 5MHz master clock rate and up sampling was pure CIC filter based which has
less than ideal spectra:
UHD Warning:
The requested interpolation is odd; the user should expect CIC rolloff.
Select an even interpolation to ensure that a halfband filter is enabled.
interpolation = dsp_rate/samp_rate -> 3 = (5.000000 MHz)/(2.000000 MHz)
UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 2.000000 MSps
Actual sample rate: 1.666667 MSps
UHD Warning:
The requested interpolation is odd; the user should expect CIC rolloff.
Select an even interpolation to ensure that a halfband filter is enabled.
interpolation = dsp_rate/samp_rate -> 3 = (5.000000 MHz)/(2.000000 MHz)
UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 2.000000 MSps
Actual sample rate: 1.666667 MSps
On Oct 1, 2014, at 11:41 AM, Urban Hakansson <[email protected]> wrote:
> Ian,
>
> Thanks for taking a look at this problem. There is no sample rate conversion
> 2MHz->5MHz taking place. I executed the same flow graph for two different
> sample rates. The master clock rate was set to 5 MHz in both cases.
>
> Case 1) The sample rate was set to 5 MHz (equal to the master clock rate).
>
> Case 2) The sample rate was set to 2 MHz (not equal to the master clock rate).
>
> Urban
>
> ----- Original Message -----
> From: "Ian Buckley" <[email protected]>
> To: "Urban Hakansson" <[email protected]>
> Cc: "Marcus D. Leech" <[email protected]>, [email protected]
> Sent: Wednesday, October 1, 2014 2:20:34 PM
> Subject: Re: [USRP-users] Frequency translation works differently on N210 and
> B210.
>
> Urban, a quick question?I just glanced at your flow graph, it's very
> simple?I'm wondering where did the sample rate conversion occur (2MHz->5MHz)
> in your example 2) quoted below? There is no re-sampling block instantiated
> in your flow graph.
>
> On Oct 1, 2014, at 10:33 AM, Urban Hakansson via USRP-users
> <[email protected]> wrote:
>
>> First, thank you for responding so promptly. I attach the Gnu Radio
>> flow-graph and the generated python script. It contains two USRP sink
>> objects, one configured for the B210 and the other for the N210. FYI, I use
>> GnuRadio companinion 3.7.1.1 and 3.7.2.2.
>>
>> I also attach two example images from the spectrum analyzer looking at the
>> spectrum from the B210.
>>
>> Image 1) B210 master clock rate = 5MHz, Sampling rate = 5 MHz, frequency of
>> complex exponential = 1.2 MHz, center frequency = 800MHz.
>> No replica at fc-f. As expected.
>>
>> Image 2) B210 master clock rate = 5MHz, Sampling rate = 2 MHz, frequency of
>> complex exponential = 750 kHz, center frequency = 800MHz.
>> Replica at fc-f.
>>
>> The result from the N210 is a replica at fc-f as well so I don't include a
>> image.
>>
>> Regards,
>>
>> Urban Hakansson
>>
>> ----- Original Message -----
>> From: "Marcus D. Leech via USRP-users" <[email protected]>
>> To: [email protected]
>> Sent: Tuesday, September 30, 2014 8:11:34 PM
>> Subject: Re: [USRP-users] Frequency translation works differently on N210
>> and B210.
>>
>> On 09/30/2014 06:20 PM, Urban Hakansson via USRP-users wrote:
>>> Hi everybody,
>>>
>>> I have a problem. I include below 1) General information, 2) Introduction
>>> to my problem 3) Detailed description of my problem.
>>>
>>> General background information about my environment:
>>> Fedora 17 Linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5);
>>> Boost_104800; UHD_003.007.001-0-unknown
>>>
>>> N210 informationfrom uhd_usrp_probe:
>>> | Device: USRP2 / N-Series Device
>>> | _____________________________________________________
>>> | /
>>> | | Mboard: N210r4
>>> | | hardware: 2577
>>> | | mac-addr: 00:80:2f:0a:e6:15
>>> | | ip-addr: 192.168.2.199
>>> | | subnet: 255.255.255.255
>>> | | gateway: 255.255.255.255
>>> | | gpsdo: none
>>> | | serial: F4A09C
>>> | | FW Version: 12.4
>>> | | FPGA Version: 10.1
>>>
>>> B210 information from uhd_usrp_probe:
>>> | Device: B-Series Device
>>> | _____________________________________________________
>>> | /
>>> | | Mboard: B210
>>> | | revision: 4
>>> | | product: 2
>>> | | serial: F571B5
>>> | | FW Version: 4.0
>>> | | FPGA Version: 3.0
>>>
>>>
>>> Introduction/background: It is my understanding that outputting a
>>> real-valued baseband signal x(t) = a*sin(2*pi*f*t) on an RF carrier fc
>>> should result in two components at fc+f and fc-f, but outputting a
>>> complex-valued baseband signal x(t) = exp(2*pi*f*t) should only result in
>>> an fc+f component. The complex exponential can be used for frequency
>>> translation but is causing me serious problems on the N210 + SBX
>>> daughterboard.
>>>
>>> Detailed Problem Description: Using GnuRadio I output a simple baseband
>>> complex exponential at frequency +f centered at the RF center frequency fc.
>>> Now on the N210 in addition to the sinusoid at fc+f there is a unexpected
>>> replica at fc-f about 13-14 dB below fc+f. When I run the same script on
>>> the B210 and set master clock rate equal to the sample clock rate, I only
>>> see the desired frequency component at fc+f. There is no replica at fc-f as
>>> in the case of the N210. This is the correct behaviour as I understand it.
>>> However, if I don't set the master clock rate equal to the sample rate on
>>> the B210 I do get the undesired replica at fc-f 13-14 dB below the signal
>>> at fc+f just as I did on the N210.
>>>
>>> Why does it only work if the master clock rate is set equal to the sample
>>> clock rate on the B210? I have read somewhere on the mailing list that the
>>> FPGA including CIC and HB filters are bypassed in this case.
>>>
>>> Question: How can I output a simple complex-valued baseband signal x(t) =
>>> exp(2*pi*f*t) on an RF carrier fc on the N210 and only get an fc+f
>>> component so I can use this mechanism to perform frequency translation?
>>>
>>> Thanks for you consideration.
>>>
>>> Regards,
>>>
>>> Urban Hakansson
>>>
>>>
>>>
>>> This e-mail may contain privileged, confidential, copyrighted or other
>>> legally protected information, and is intended exclusively for the intended
>>> recipient. If you are not the intended recipient (even if the e-mail
>>> address above is yours), you may not review, store, use, copy, disclose or
>>> retransmit it in any form. If you are not the intended recipient or
>>> otherwise have received this by mistake, please immediately notify the
>>> sender by return e-mail (or [email protected]), then delete the message
>>> in its entirety. Thank you.
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> Could you perhaps share your Gnu Radio flow-graph with us? It would
>> help in seeing where your problems might originate.
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>> This e-mail may contain privileged, confidential, copyrighted or other
>> legally protected information, and is intended exclusively for the intended
>> recipient. If you are not the intended recipient (even if the e-mail
>> address above is yours), you may not review, store, use, copy, disclose or
>> retransmit it in any form. If you are not the intended recipient or
>> otherwise have received this by mistake, please immediately notify the
>> sender by return e-mail (or [email protected]), then delete the message in
>> its entirety. Thank
>> you.<complex_exp.grc><complex_exp.py><B210_specA_Fs2MHz_750kHz.JPG><B210_specA_Fs5MHz_f1.2MHz.JPG>_______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> This e-mail may contain privileged, confidential, copyrighted or other
> legally protected information, and is intended exclusively for the intended
> recipient. If you are not the intended recipient (even if the e-mail address
> above is yours), you may not review, store, use, copy, disclose or retransmit
> it in any form. If you are not the intended recipient or otherwise have
> received this by mistake, please immediately notify the sender by return
> e-mail (or [email protected]), then delete the message in its entirety.
> Thank you.
------------------------------
Message: 16
Date: Wed, 1 Oct 2014 15:45:32 -0400 (EDT)
From: Urban Hakansson <[email protected]>
To: Ian Buckley <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Frequency translation works differently on
N210 and B210.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Yes, I deliberately requested a sample rate that would force the use of the
FPGA CIC filters. Fs = 1.666667 MHz is fine. I expected roll-off but I did not
expect the replica at fc-f. The CIC filters should not introduce that kind of
error, at least that is my understanding.
----- Original Message -----
From: "Ian Buckley" <[email protected]>
To: "Urban Hakansson" <[email protected]>
Cc: "Marcus D. Leech" <[email protected]>, [email protected]
Sent: Wednesday, October 1, 2014 2:53:04 PM
Subject: Re: [USRP-users] Frequency translation works differently on N210 and
B210.
Did you note the warnings that this generates? The USRP's can not perform
fractional rate conversions. Your sample rate was coerced to be compatible with
a 5MHz master clock rate and up sampling was pure CIC filter based which has
less than ideal spectra:
UHD Warning:
The requested interpolation is odd; the user should expect CIC rolloff.
Select an even interpolation to ensure that a halfband filter is enabled.
interpolation = dsp_rate/samp_rate -> 3 = (5.000000 MHz)/(2.000000 MHz)
UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 2.000000 MSps
Actual sample rate: 1.666667 MSps
UHD Warning:
The requested interpolation is odd; the user should expect CIC rolloff.
Select an even interpolation to ensure that a halfband filter is enabled.
interpolation = dsp_rate/samp_rate -> 3 = (5.000000 MHz)/(2.000000 MHz)
UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 2.000000 MSps
Actual sample rate: 1.666667 MSps
On Oct 1, 2014, at 11:41 AM, Urban Hakansson <[email protected]> wrote:
> Ian,
>
> Thanks for taking a look at this problem. There is no sample rate conversion
> 2MHz->5MHz taking place. I executed the same flow graph for two different
> sample rates. The master clock rate was set to 5 MHz in both cases.
>
> Case 1) The sample rate was set to 5 MHz (equal to the master clock rate).
>
> Case 2) The sample rate was set to 2 MHz (not equal to the master clock rate).
>
> Urban
>
> ----- Original Message -----
> From: "Ian Buckley" <[email protected]>
> To: "Urban Hakansson" <[email protected]>
> Cc: "Marcus D. Leech" <[email protected]>, [email protected]
> Sent: Wednesday, October 1, 2014 2:20:34 PM
> Subject: Re: [USRP-users] Frequency translation works differently on N210 and
> B210.
>
> Urban, a quick question?I just glanced at your flow graph, it's very
> simple?I'm wondering where did the sample rate conversion occur (2MHz->5MHz)
> in your example 2) quoted below? There is no re-sampling block instantiated
> in your flow graph.
>
> On Oct 1, 2014, at 10:33 AM, Urban Hakansson via USRP-users
> <[email protected]> wrote:
>
>> First, thank you for responding so promptly. I attach the Gnu Radio
>> flow-graph and the generated python script. It contains two USRP sink
>> objects, one configured for the B210 and the other for the N210. FYI, I use
>> GnuRadio companinion 3.7.1.1 and 3.7.2.2.
>>
>> I also attach two example images from the spectrum analyzer looking at the
>> spectrum from the B210.
>>
>> Image 1) B210 master clock rate = 5MHz, Sampling rate = 5 MHz, frequency of
>> complex exponential = 1.2 MHz, center frequency = 800MHz.
>> No replica at fc-f. As expected.
>>
>> Image 2) B210 master clock rate = 5MHz, Sampling rate = 2 MHz, frequency of
>> complex exponential = 750 kHz, center frequency = 800MHz.
>> Replica at fc-f.
>>
>> The result from the N210 is a replica at fc-f as well so I don't include a
>> image.
>>
>> Regards,
>>
>> Urban Hakansson
>>
>> ----- Original Message -----
>> From: "Marcus D. Leech via USRP-users" <[email protected]>
>> To: [email protected]
>> Sent: Tuesday, September 30, 2014 8:11:34 PM
>> Subject: Re: [USRP-users] Frequency translation works differently on N210
>> and B210.
>>
>> On 09/30/2014 06:20 PM, Urban Hakansson via USRP-users wrote:
>>> Hi everybody,
>>>
>>> I have a problem. I include below 1) General information, 2) Introduction
>>> to my problem 3) Detailed description of my problem.
>>>
>>> General background information about my environment:
>>> Fedora 17 Linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5);
>>> Boost_104800; UHD_003.007.001-0-unknown
>>>
>>> N210 informationfrom uhd_usrp_probe:
>>> | Device: USRP2 / N-Series Device
>>> | _____________________________________________________
>>> | /
>>> | | Mboard: N210r4
>>> | | hardware: 2577
>>> | | mac-addr: 00:80:2f:0a:e6:15
>>> | | ip-addr: 192.168.2.199
>>> | | subnet: 255.255.255.255
>>> | | gateway: 255.255.255.255
>>> | | gpsdo: none
>>> | | serial: F4A09C
>>> | | FW Version: 12.4
>>> | | FPGA Version: 10.1
>>>
>>> B210 information from uhd_usrp_probe:
>>> | Device: B-Series Device
>>> | _____________________________________________________
>>> | /
>>> | | Mboard: B210
>>> | | revision: 4
>>> | | product: 2
>>> | | serial: F571B5
>>> | | FW Version: 4.0
>>> | | FPGA Version: 3.0
>>>
>>>
>>> Introduction/background: It is my understanding that outputting a
>>> real-valued baseband signal x(t) = a*sin(2*pi*f*t) on an RF carrier fc
>>> should result in two components at fc+f and fc-f, but outputting a
>>> complex-valued baseband signal x(t) = exp(2*pi*f*t) should only result in
>>> an fc+f component. The complex exponential can be used for frequency
>>> translation but is causing me serious problems on the N210 + SBX
>>> daughterboard.
>>>
>>> Detailed Problem Description: Using GnuRadio I output a simple baseband
>>> complex exponential at frequency +f centered at the RF center frequency fc.
>>> Now on the N210 in addition to the sinusoid at fc+f there is a unexpected
>>> replica at fc-f about 13-14 dB below fc+f. When I run the same script on
>>> the B210 and set master clock rate equal to the sample clock rate, I only
>>> see the desired frequency component at fc+f. There is no replica at fc-f as
>>> in the case of the N210. This is the correct behaviour as I understand it.
>>> However, if I don't set the master clock rate equal to the sample rate on
>>> the B210 I do get the undesired replica at fc-f 13-14 dB below the signal
>>> at fc+f just as I did on the N210.
>>>
>>> Why does it only work if the master clock rate is set equal to the sample
>>> clock rate on the B210? I have read somewhere on the mailing list that the
>>> FPGA including CIC and HB filters are bypassed in this case.
>>>
>>> Question: How can I output a simple complex-valued baseband signal x(t) =
>>> exp(2*pi*f*t) on an RF carrier fc on the N210 and only get an fc+f
>>> component so I can use this mechanism to perform frequency translation?
>>>
>>> Thanks for you consideration.
>>>
>>> Regards,
>>>
>>> Urban Hakansson
>>>
>>>
>>>
>>> This e-mail may contain privileged, confidential, copyrighted or other
>>> legally protected information, and is intended exclusively for the intended
>>> recipient. If you are not the intended recipient (even if the e-mail
>>> address above is yours), you may not review, store, use, copy, disclose or
>>> retransmit it in any form. If you are not the intended recipient or
>>> otherwise have received this by mistake, please immediately notify the
>>> sender by return e-mail (or [email protected]), then delete the message
>>> in its entirety. Thank you.
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> Could you perhaps share your Gnu Radio flow-graph with us? It would
>> help in seeing where your problems might originate.
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>> This e-mail may contain privileged, confidential, copyrighted or other
>> legally protected information, and is intended exclusively for the intended
>> recipient. If you are not the intended recipient (even if the e-mail
>> address above is yours), you may not review, store, use, copy, disclose or
>> retransmit it in any form. If you are not the intended recipient or
>> otherwise have received this by mistake, please immediately notify the
>> sender by return e-mail (or [email protected]), then delete the message in
>> its entirety. Thank
>> you.grc>py>specA_Fs2MHz_750kHz.JPG>specA_Fs5MHz_f1.2MHz.JPG>_______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> This e-mail may contain privileged, confidential, copyrighted or other
> legally protected information, and is intended exclusively for the intended
> recipient. If you are not the intended recipient (even if the e-mail address
> above is yours), you may not review, store, use, copy, disclose or retransmit
> it in any form. If you are not the intended recipient or otherwise have
> received this by mistake, please immediately notify the sender by return
> e-mail (or [email protected]), then delete the message in its entirety.
> Thank you.
This
e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected]), then delete the message in its entirety. Thank you.
------------------------------
Message: 17
Date: Thu, 2 Oct 2014 09:04:05 +0530
From: gsmandvoip <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] rx_samples_to_file issue
Message-ID:
<cade+fgcqgahpxn5qbdrs9polarqxgh0_sqskduxlf6qetbw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thank you for your reply,
Yes it appeared to me as bug as well, but unable to figure out how to get
rid of it, please guide me.
I want to record samples at 8M samples, using uhd_rx_cfile, gives me lots
of overrun (OOOOOOOOO) and I am unable to use that data, so trying record
without gnuradio overhead. By the way, I am using USRP1 along with DBRX1,
while pc having ubuntu14.04 64 bit, 12 gb ram and i7 processor(which I
think should not be bottleneck, please correct me if I am wrong)
Thanks
On Wed, Oct 1, 2014 at 9:54 PM, <[email protected]> wrote:
> That actually looks like a bug in rx_samples_to_file, in that it's
> checking *TX* DSP configuration, which will fail in this case because
>
> with the 4rx image, there is no TX-side DSP at all.
>
>
>
>
>
>
>
>
> On 2014-10-01 07:22, gsmandvoip via USRP-users wrote:
>
> Hi list,
> when I am trying to run rx_samples_to_file, with following command:
> ./rx_samples_to_file --args="fpga=usrp1_fpga_4rx.rbf" --freq "945000000"
> --rate="8000000" $FILE --nsamps
> getting following error:
>
>
> UHD Warning:
> Unable to set the thread priority. Performance may be negatively
> affected.
> Please see the general application notes in the manual for
> instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
>
> Creating the usrp device with: fpga=usrp1_fpga_4rx.rbf...
> -- Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
> -- Opening a USRP1 device...
> -- Loading FPGA image: /usr/share/uhd/images/usrp1_fpga_4rx.rbf... done
> -- Using FPGA clock rate of 52.000000MHz...
> Error: LookupError: IndexError: multi_usrp::get_tx_subdev_spec(0) failed
> to make default spec - ValueError: The subdevice specification "A:0" is too
> long.
> The user specified 1 channels, but there are only 0 tx dsps on mboard 0.
>
>
> Can any body throw some light, what mistake I am doing.
> I am using ubuntu 14.04, 32 bit, gnuradio, 3.7, uhd driver latest
> installation
>
>
>
> _______________________________________________
> USRP-users mailing
> [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/20141002/296e2d33/attachment-0001.html>
------------------------------
Message: 18
Date: Wed, 01 Oct 2014 23:39:01 -0400
From: "Marcus D. Leech" <[email protected]>
To: gsmandvoip <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] rx_samples_to_file issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 10/01/2014 11:34 PM, gsmandvoip wrote:
> Thank you for your reply,
> Yes it appeared to me as bug as well, but unable to figure out how to
> get rid of it, please guide me.
> I want to record samples at 8M samples, using uhd_rx_cfile, gives me
> lots of overrun (OOOOOOOOO) and I am unable to use that data, so
> trying record without gnuradio overhead. By the way, I am using USRP1
> along with DBRX1, while pc having ubuntu14.04 64 bit, 12 gb ram and i7
> processor(which I think should not be bottleneck, please correct me if
> I am wrong)
> Thanks
>
If you're only recording a single channel, then you don't need the
usrp1_fpga_4rx.rbf FPGA image.
What exact parameters are you giving to uhd_rx_cfile? It shouldn't be
*that* much more overhead that rx_samples_to_file.
Also, why are you running a 32-bit system image on a 64-bit machine like
the i7? Are you running this in a VM by any chance?
> On Wed, Oct 1, 2014 at 9:54 PM, <[email protected]
> <mailto:[email protected]>> wrote:
>
> That actually looks like a bug in rx_samples_to_file, in that it's
> checking *TX* DSP configuration, which will fail in this case because
>
> with the 4rx image, there is no TX-side DSP at all.
>
> On 2014-10-01 07:22, gsmandvoip via USRP-users wrote:
>
>> Hi list,
>> when I am trying to run rx_samples_to_file, with following command:
>> ./rx_samples_to_file --args="fpga=usrp1_fpga_4rx.rbf" --freq
>> "945000000" --rate="8000000" $FILE --nsamps
>> getting following error:
>>
>>
>> UHD Warning:
>> Unable to set the thread priority. Performance may be
>> negatively affected.
>> Please see the general application notes in the manual for
>> instructions.
>> EnvironmentError: OSError: error in pthread_setschedparam
>>
>> Creating the usrp device with: fpga=usrp1_fpga_4rx.rbf...
>> -- Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
>> -- Opening a USRP1 device...
>> -- Loading FPGA image:
>> /usr/share/uhd/images/usrp1_fpga_4rx.rbf... done
>> -- Using FPGA clock rate of 52.000000MHz...
>> Error: LookupError: IndexError: multi_usrp::get_tx_subdev_spec(0)
>> failed to make default spec - ValueError: The subdevice
>> specification "A:0" is too long.
>> The user specified 1 channels, but there are only 0 tx dsps on
>> mboard 0.
>>
>>
>> Can any body throw some light, what mistake I am doing.
>> I am using ubuntu 14.04, 32 bit, gnuradio, 3.7, uhd driver latest
>> installation
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[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/20141001/8a64aac6/attachment-0001.html>
------------------------------
Message: 19
Date: Thu, 2 Oct 2014 09:16:54 +0530
From: gsmandvoip <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] rx_samples_to_file issue
Message-ID:
<CADE+fGCY2ur6v+su7kWzJbm3b+Hn=eBw7Xgo0=16ujepody...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Yes I am running single channel, but when trying to achieve my desired
sampling rate without _4rx.rbf, it says, requested sampling rate is not
valid, adjusting to some 3.9M or so.
sorry for misleading info I gave earlier, I have i3, with 32 bit and i7
with 64 bit, but getting same result on both machines
Here is my command to capture signal:
./rx_samples_to_file --args="fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX" --freq
"$FC" --rate="$SR" $FILE --nsamps "$NSAMPLES"
and here is its output:
Creating the usrp device with: fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX...
-- Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
-- Opening a USRP1 device...
-- Loading FPGA image: /usr/share/uhd/images/usrp1_fpga_4rx.rbf... done
-- Using FPGA clock rate of 52.000000MHz...
*Error: LookupError: IndexError: multi_usrp::get_tx_subdev_spec(0) failed
to make default spec - ValueError: The subdevice specification "A:0" is too
long.*
The user specified 1 channels, but there are only 0 tx dsps on mboard 0.
On Thu, Oct 2, 2014 at 9:09 AM, Marcus D. Leech <[email protected]> wrote:
> On 10/01/2014 11:34 PM, gsmandvoip wrote:
>
> Thank you for your reply,
> Yes it appeared to me as bug as well, but unable to figure out how to get
> rid of it, please guide me.
> I want to record samples at 8M samples, using uhd_rx_cfile, gives me lots
> of overrun (OOOOOOOOO) and I am unable to use that data, so trying record
> without gnuradio overhead. By the way, I am using USRP1 along with DBRX1,
> while pc having ubuntu14.04 64 bit, 12 gb ram and i7 processor(which I
> think should not be bottleneck, please correct me if I am wrong)
> Thanks
>
> If you're only recording a single channel, then you don't need the
> usrp1_fpga_4rx.rbf FPGA image.
>
> What exact parameters are you giving to uhd_rx_cfile? It shouldn't be
> *that* much more overhead that rx_samples_to_file.
>
> Also, why are you running a 32-bit system image on a 64-bit machine like
> the i7? Are you running this in a VM by any chance?
>
>
>
> On Wed, Oct 1, 2014 at 9:54 PM, <[email protected]> wrote:
>
>> That actually looks like a bug in rx_samples_to_file, in that it's
>> checking *TX* DSP configuration, which will fail in this case because
>>
>> with the 4rx image, there is no TX-side DSP at all.
>>
>>
>>
>>
>>
>>
>>
>>
>> On 2014-10-01 07:22, gsmandvoip via USRP-users wrote:
>>
>> Hi list,
>> when I am trying to run rx_samples_to_file, with following command:
>> ./rx_samples_to_file --args="fpga=usrp1_fpga_4rx.rbf" --freq "945000000"
>> --rate="8000000" $FILE --nsamps
>> getting following error:
>>
>>
>> UHD Warning:
>> Unable to set the thread priority. Performance may be negatively
>> affected.
>> Please see the general application notes in the manual for
>> instructions.
>> EnvironmentError: OSError: error in pthread_setschedparam
>>
>> Creating the usrp device with: fpga=usrp1_fpga_4rx.rbf...
>> -- Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
>> -- Opening a USRP1 device...
>> -- Loading FPGA image: /usr/share/uhd/images/usrp1_fpga_4rx.rbf... done
>> -- Using FPGA clock rate of 52.000000MHz...
>> Error: LookupError: IndexError: multi_usrp::get_tx_subdev_spec(0) failed
>> to make default spec - ValueError: The subdevice specification "A:0" is too
>> long.
>> The user specified 1 channels, but there are only 0 tx dsps on mboard 0.
>>
>>
>> Can any body throw some light, what mistake I am doing.
>> I am using ubuntu 14.04, 32 bit, gnuradio, 3.7, uhd driver latest
>> installation
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [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/20141002/261e60bd/attachment-0001.html>
------------------------------
Message: 20
Date: Thu, 2 Oct 2014 09:18:15 +0530
From: gsmandvoip <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] rx_samples_to_file issue
Message-ID:
<CADE+fGBG=ige6xay6p-cwz1cksgvm+swm0t805twsdcjta6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
sorry about earlier command, here is my command for uhd_rx_cfile:
uhd_rx_cfile --args="fpga=usrp1_fpga_4rx.rbf" -f "$FC" --samp-rate="$SR"
$FILE -N "$NSAMPLES"
On Thu, Oct 2, 2014 at 9:16 AM, gsmandvoip <[email protected]> wrote:
> Yes I am running single channel, but when trying to achieve my desired
> sampling rate without _4rx.rbf, it says, requested sampling rate is not
> valid, adjusting to some 3.9M or so.
> sorry for misleading info I gave earlier, I have i3, with 32 bit and i7
> with 64 bit, but getting same result on both machines
>
> Here is my command to capture signal:
>
> ./rx_samples_to_file --args="fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX"
> --freq "$FC" --rate="$SR" $FILE --nsamps "$NSAMPLES"
>
> and here is its output:
>
> Creating the usrp device with: fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX...
> -- Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
> -- Opening a USRP1 device...
> -- Loading FPGA image: /usr/share/uhd/images/usrp1_fpga_4rx.rbf... done
> -- Using FPGA clock rate of 52.000000MHz...
> *Error: LookupError: IndexError: multi_usrp::get_tx_subdev_spec(0) failed
> to make default spec - ValueError: The subdevice specification "A:0" is too
> long.*
> The user specified 1 channels, but there are only 0 tx dsps on mboard 0.
>
>
>
> On Thu, Oct 2, 2014 at 9:09 AM, Marcus D. Leech <[email protected]> wrote:
>
>> On 10/01/2014 11:34 PM, gsmandvoip wrote:
>>
>> Thank you for your reply,
>> Yes it appeared to me as bug as well, but unable to figure out how to
>> get rid of it, please guide me.
>> I want to record samples at 8M samples, using uhd_rx_cfile, gives me
>> lots of overrun (OOOOOOOOO) and I am unable to use that data, so trying
>> record without gnuradio overhead. By the way, I am using USRP1 along with
>> DBRX1, while pc having ubuntu14.04 64 bit, 12 gb ram and i7 processor(which
>> I think should not be bottleneck, please correct me if I am wrong)
>> Thanks
>>
>> If you're only recording a single channel, then you don't need the
>> usrp1_fpga_4rx.rbf FPGA image.
>>
>> What exact parameters are you giving to uhd_rx_cfile? It shouldn't be
>> *that* much more overhead that rx_samples_to_file.
>>
>> Also, why are you running a 32-bit system image on a 64-bit machine like
>> the i7? Are you running this in a VM by any chance?
>>
>>
>>
>> On Wed, Oct 1, 2014 at 9:54 PM, <[email protected]> wrote:
>>
>>> That actually looks like a bug in rx_samples_to_file, in that it's
>>> checking *TX* DSP configuration, which will fail in this case because
>>>
>>> with the 4rx image, there is no TX-side DSP at all.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 2014-10-01 07:22, gsmandvoip via USRP-users wrote:
>>>
>>> Hi list,
>>> when I am trying to run rx_samples_to_file, with following command:
>>> ./rx_samples_to_file --args="fpga=usrp1_fpga_4rx.rbf" --freq "945000000"
>>> --rate="8000000" $FILE --nsamps
>>> getting following error:
>>>
>>>
>>> UHD Warning:
>>> Unable to set the thread priority. Performance may be negatively
>>> affected.
>>> Please see the general application notes in the manual for
>>> instructions.
>>> EnvironmentError: OSError: error in pthread_setschedparam
>>>
>>> Creating the usrp device with: fpga=usrp1_fpga_4rx.rbf...
>>> -- Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
>>> -- Opening a USRP1 device...
>>> -- Loading FPGA image: /usr/share/uhd/images/usrp1_fpga_4rx.rbf... done
>>> -- Using FPGA clock rate of 52.000000MHz...
>>> Error: LookupError: IndexError: multi_usrp::get_tx_subdev_spec(0) failed
>>> to make default spec - ValueError: The subdevice specification "A:0" is too
>>> long.
>>> The user specified 1 channels, but there are only 0 tx dsps on mboard 0.
>>>
>>>
>>> Can any body throw some light, what mistake I am doing.
>>> I am using ubuntu 14.04, 32 bit, gnuradio, 3.7, uhd driver latest
>>> installation
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing
>>> [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/20141002/0a84909c/attachment-0001.html>
------------------------------
Message: 21
Date: Wed, 01 Oct 2014 23:57:06 -0400
From: "Marcus D. Leech" <[email protected]>
To: gsmandvoip <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] rx_samples_to_file issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 10/01/2014 11:46 PM, gsmandvoip wrote:
> Yes I am running single channel, but when trying to achieve my desired
> sampling rate without _4rx.rbf, it says, requested sampling rate is
> not valid, adjusting to some 3.9M or so.
> sorry for misleading info I gave earlier, I have i3, with 32 bit and
> i7 with 64 bit, but getting same result on both machines
>
> Here is my command to capture signal:
>
> ./rx_samples_to_file --args="fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX"
> --freq "$FC" --rate="$SR" $FILE --nsamps "$NSAMPLES"
>
> and here is its output:
>
> Creating the usrp device with: fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX...
> -- Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
> -- Opening a USRP1 device...
> -- Loading FPGA image: /usr/share/uhd/images/usrp1_fpga_4rx.rbf... done
> -- Using FPGA clock rate of 52.000000MHz...
> *Error: LookupError: IndexError: multi_usrp::get_tx_subdev_spec(0)
> failed to make default spec - ValueError: The subdevice specification
> "A:0" is too long.*
> The user specified 1 channels, but there are only 0 tx dsps on mboard 0.
>
>
Don't use the _4rx image if you don't need it.
The USRP1 only does strict-integer resampling, and with a master clock
(NON STANDARD FOR USRP1) of 52.000MHz, 4Msps is not a sample rate
that it can produce. Try 5.2Msps or 4.3333Msps.
At 5.2Msps, it's recording at roughly 20.8Mbytes/second, so your system
needs to be able to sustain that for at least as long as the capture lasts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141001/2518d904/attachment-0001.html>
------------------------------
Message: 22
Date: Thu, 2 Oct 2014 10:26:43 +0530
From: gsmandvoip <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] rx_samples_to_file issue
Message-ID:
<cade+fgbejhs5ndnjys8goueiq2hynqwumxyzcc9cmpns-xn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
with rx_samples_to_file without _4rx.rbf, Initially I tried on my i3, 4GB
ram, it gave me
some OOOO but was lesser than earlier, but I do not understand, my most of
the ram capacity and processor was sitting idle while it shows OOOO, why is
this strange behaviour
using uhd_rx_cfile getting similar result, but strangely, why it is low, at
4M sampling rate it was higher???
On Thu, Oct 2, 2014 at 9:27 AM, Marcus D. Leech <[email protected]> wrote:
> On 10/01/2014 11:46 PM, gsmandvoip wrote:
>
> Yes I am running single channel, but when trying to achieve my desired
> sampling rate without _4rx.rbf, it says, requested sampling rate is not
> valid, adjusting to some 3.9M or so.
> sorry for misleading info I gave earlier, I have i3, with 32 bit and i7
> with 64 bit, but getting same result on both machines
>
> Here is my command to capture signal:
>
> ./rx_samples_to_file --args="fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX"
> --freq "$FC" --rate="$SR" $FILE --nsamps "$NSAMPLES"
>
> and here is its output:
>
> Creating the usrp device with: fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX...
> -- Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
> -- Opening a USRP1 device...
> -- Loading FPGA image: /usr/share/uhd/images/usrp1_fpga_4rx.rbf... done
> -- Using FPGA clock rate of 52.000000MHz...
> *Error: LookupError: IndexError: multi_usrp::get_tx_subdev_spec(0) failed
> to make default spec - ValueError: The subdevice specification "A:0" is too
> long.*
> The user specified 1 channels, but there are only 0 tx dsps on mboard 0.
>
>
> Don't use the _4rx image if you don't need it.
>
> The USRP1 only does strict-integer resampling, and with a master clock
> (NON STANDARD FOR USRP1) of 52.000MHz, 4Msps is not a sample rate
> that it can produce. Try 5.2Msps or 4.3333Msps.
>
> At 5.2Msps, it's recording at roughly 20.8Mbytes/second, so your system
> needs to be able to sustain that for at least as long as the capture lasts.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141002/bbc274c7/attachment-0001.html>
------------------------------
Message: 23
Date: Wed, 1 Oct 2014 22:32:58 -0700
From: Ian Buckley <[email protected]>
To: Urban Hakansson <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Frequency translation works differently on
N210 and B210.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
What you are seeing is *exactly* as sampling theory would predict.
Your fc+f signal shows up on your spectrum analyzer at 800.625Mhz (Remember
your 750kHz became 750*1.6666/2.000)
Your "fc-f" image is not at fc-f (which would be 799.375MHz) but at 1.66666Mhz
- 0.625Mhz = 798.95Mhz
You see the alias so prominently because the pure CIC filter has terrible stop
band rejection which is why it's largely unsuitable as a generic interpolation
filter on it's own.
Sweep you CW frequency slowly and watch the direction the image appears
from?this is your clue where it's coming from, and a good practical technique
when looking at real world signals and there unexpected by-products.
If you select peak hold on your spectrum analyzer and sweep the frequency you
will plot the frequency response of the CIC filter. Try it with sample rate
2.5MHz and 1.25MHz and see the response of the small half band filter and then
the cascaded half band filters
Now if you turn up the gain some more you will see a true "fc-f" signal,
probably some 40-50db below your main signal and this will be due to the
residual IQ imbalance present in real world direct conversion receivers.
-Ian
On Oct 1, 2014, at 12:45 PM, Urban Hakansson <[email protected]> wrote:
> Yes, I deliberately requested a sample rate that would force the use of the
> FPGA CIC filters. Fs = 1.666667 MHz is fine. I expected roll-off but I did
> not expect the replica at fc-f. The CIC filters should not introduce that
> kind of error, at least that is my understanding.
>
> ----- Original Message -----
> From: "Ian Buckley" <[email protected]>
> To: "Urban Hakansson" <[email protected]>
> Cc: "Marcus D. Leech" <[email protected]>, [email protected]
> Sent: Wednesday, October 1, 2014 2:53:04 PM
> Subject: Re: [USRP-users] Frequency translation works differently on N210 and
> B210.
>
> Did you note the warnings that this generates? The USRP's can not perform
> fractional rate conversions. Your sample rate was coerced to be compatible
> with a 5MHz master clock rate and up sampling was pure CIC filter based which
> has less than ideal spectra:
>
>
> UHD Warning:
> The requested interpolation is odd; the user should expect CIC rolloff.
> Select an even interpolation to ensure that a halfband filter is enabled.
> interpolation = dsp_rate/samp_rate -> 3 = (5.000000 MHz)/(2.000000 MHz)
>
> UHD Warning:
> The hardware does not support the requested TX sample rate:
> Target sample rate: 2.000000 MSps
> Actual sample rate: 1.666667 MSps
>
> UHD Warning:
> The requested interpolation is odd; the user should expect CIC rolloff.
> Select an even interpolation to ensure that a halfband filter is enabled.
> interpolation = dsp_rate/samp_rate -> 3 = (5.000000 MHz)/(2.000000 MHz)
>
> UHD Warning:
> The hardware does not support the requested TX sample rate:
> Target sample rate: 2.000000 MSps
> Actual sample rate: 1.666667 MSps
>
>
> On Oct 1, 2014, at 11:41 AM, Urban Hakansson <[email protected]> wrote:
>
>> Ian,
>>
>> Thanks for taking a look at this problem. There is no sample rate conversion
>> 2MHz->5MHz taking place. I executed the same flow graph for two different
>> sample rates. The master clock rate was set to 5 MHz in both cases.
>>
>> Case 1) The sample rate was set to 5 MHz (equal to the master clock rate).
>>
>> Case 2) The sample rate was set to 2 MHz (not equal to the master clock
>> rate).
>>
>> Urban
>>
>> ----- Original Message -----
>> From: "Ian Buckley" <[email protected]>
>> To: "Urban Hakansson" <[email protected]>
>> Cc: "Marcus D. Leech" <[email protected]>, [email protected]
>> Sent: Wednesday, October 1, 2014 2:20:34 PM
>> Subject: Re: [USRP-users] Frequency translation works differently on N210
>> and B210.
>>
>> Urban, a quick question?I just glanced at your flow graph, it's very
>> simple?I'm wondering where did the sample rate conversion occur (2MHz->5MHz)
>> in your example 2) quoted below? There is no re-sampling block instantiated
>> in your flow graph.
>>
>> On Oct 1, 2014, at 10:33 AM, Urban Hakansson via USRP-users
>> <[email protected]> wrote:
>>
>>> First, thank you for responding so promptly. I attach the Gnu Radio
>>> flow-graph and the generated python script. It contains two USRP sink
>>> objects, one configured for the B210 and the other for the N210. FYI, I use
>>> GnuRadio companinion 3.7.1.1 and 3.7.2.2.
>>>
>>> I also attach two example images from the spectrum analyzer looking at the
>>> spectrum from the B210.
>>>
>>> Image 1) B210 master clock rate = 5MHz, Sampling rate = 5 MHz, frequency of
>>> complex exponential = 1.2 MHz, center frequency = 800MHz.
>>> No replica at fc-f. As expected.
>>>
>>> Image 2) B210 master clock rate = 5MHz, Sampling rate = 2 MHz, frequency of
>>> complex exponential = 750 kHz, center frequency = 800MHz.
>>> Replica at fc-f.
>>>
>>> The result from the N210 is a replica at fc-f as well so I don't include a
>>> image.
>>>
>>> Regards,
>>>
>>> Urban Hakansson
>>>
>>> ----- Original Message -----
>>> From: "Marcus D. Leech via USRP-users" <[email protected]>
>>> To: [email protected]
>>> Sent: Tuesday, September 30, 2014 8:11:34 PM
>>> Subject: Re: [USRP-users] Frequency translation works differently on N210
>>> and B210.
>>>
>>> On 09/30/2014 06:20 PM, Urban Hakansson via USRP-users wrote:
>>>> Hi everybody,
>>>>
>>>> I have a problem. I include below 1) General information, 2) Introduction
>>>> to my problem 3) Detailed description of my problem.
>>>>
>>>> General background information about my environment:
>>>> Fedora 17 Linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5);
>>>> Boost_104800; UHD_003.007.001-0-unknown
>>>>
>>>> N210 informationfrom uhd_usrp_probe:
>>>> | Device: USRP2 / N-Series Device
>>>> | _____________________________________________________
>>>> | /
>>>> | | Mboard: N210r4
>>>> | | hardware: 2577
>>>> | | mac-addr: 00:80:2f:0a:e6:15
>>>> | | ip-addr: 192.168.2.199
>>>> | | subnet: 255.255.255.255
>>>> | | gateway: 255.255.255.255
>>>> | | gpsdo: none
>>>> | | serial: F4A09C
>>>> | | FW Version: 12.4
>>>> | | FPGA Version: 10.1
>>>>
>>>> B210 information from uhd_usrp_probe:
>>>> | Device: B-Series Device
>>>> | _____________________________________________________
>>>> | /
>>>> | | Mboard: B210
>>>> | | revision: 4
>>>> | | product: 2
>>>> | | serial: F571B5
>>>> | | FW Version: 4.0
>>>> | | FPGA Version: 3.0
>>>>
>>>>
>>>> Introduction/background: It is my understanding that outputting a
>>>> real-valued baseband signal x(t) = a*sin(2*pi*f*t) on an RF carrier fc
>>>> should result in two components at fc+f and fc-f, but outputting a
>>>> complex-valued baseband signal x(t) = exp(2*pi*f*t) should only result in
>>>> an fc+f component. The complex exponential can be used for frequency
>>>> translation but is causing me serious problems on the N210 + SBX
>>>> daughterboard.
>>>>
>>>> Detailed Problem Description: Using GnuRadio I output a simple baseband
>>>> complex exponential at frequency +f centered at the RF center frequency
>>>> fc. Now on the N210 in addition to the sinusoid at fc+f there is a
>>>> unexpected replica at fc-f about 13-14 dB below fc+f. When I run the same
>>>> script on the B210 and set master clock rate equal to the sample clock
>>>> rate, I only see the desired frequency component at fc+f. There is no
>>>> replica at fc-f as in the case of the N210. This is the correct behaviour
>>>> as I understand it. However, if I don't set the master clock rate equal to
>>>> the sample rate on the B210 I do get the undesired replica at fc-f 13-14
>>>> dB below the signal at fc+f just as I did on the N210.
>>>>
>>>> Why does it only work if the master clock rate is set equal to the sample
>>>> clock rate on the B210? I have read somewhere on the mailing list that the
>>>> FPGA including CIC and HB filters are bypassed in this case.
>>>>
>>>> Question: How can I output a simple complex-valued baseband signal x(t) =
>>>> exp(2*pi*f*t) on an RF carrier fc on the N210 and only get an fc+f
>>>> component so I can use this mechanism to perform frequency translation?
>>>>
>>>> Thanks for you consideration.
>>>>
>>>> Regards,
>>>>
>>>> Urban Hakansson
>>>>
>>>>
>>>>
>>>> This e-mail may contain privileged, confidential, copyrighted or other
>>>> legally protected information, and is intended exclusively for the
>>>> intended recipient. If you are not the intended recipient (even if the
>>>> e-mail address above is yours), you may not review, store, use, copy,
>>>> disclose or retransmit it in any form. If you are not the intended
>>>> recipient or otherwise have received this by mistake, please immediately
>>>> notify the sender by return e-mail (or [email protected]), then delete
>>>> the message in its entirety. Thank you.
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> Could you perhaps share your Gnu Radio flow-graph with us? It would
>>> help in seeing where your problems might originate.
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>>
>>>
>>> This e-mail may contain privileged, confidential, copyrighted or other
>>> legally protected information, and is intended exclusively for the intended
>>> recipient. If you are not the intended recipient (even if the e-mail
>>> address above is yours), you may not review, store, use, copy, disclose or
>>> retransmit it in any form. If you are not the intended recipient or
>>> otherwise have received this by mistake, please immediately notify the
>>> sender by return e-mail (or [email protected]), then delete the message
>>> in its entirety. Thank
>>> you.grc>py>specA_Fs2MHz_750kHz.JPG>specA_Fs5MHz_f1.2MHz.JPG>_______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>> This e-mail may contain privileged, confidential, copyrighted or other
>> legally protected information, and is intended exclusively for the intended
>> recipient. If you are not the intended recipient (even if the e-mail
>> address above is yours), you may not review, store, use, copy, disclose or
>> retransmit it in any form. If you are not the intended recipient or
>> otherwise have received this by mistake, please immediately notify the
>> sender by return e-mail (or [email protected]), then delete the message in
>> its entirety. Thank you.
>
>
>
>
> This e-mail may contain privileged, confidential, copyrighted or other
> legally protected information, and is intended exclusively for the intended
> recipient. If you are not the intended recipient (even if the e-mail address
> above is yours), you may not review, store, use, copy, disclose or retransmit
> it in any form. If you are not the intended recipient or otherwise have
> received this by mistake, please immediately notify the sender by return
> e-mail (or [email protected]), then delete the message in its entirety.
> Thank you.
------------------------------
Message: 24
Date: Thu, 02 Oct 2014 08:20:55 -0400
From: "Marcus D. Leech" <[email protected]>
To: gsmandvoip <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] rx_samples_to_file issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
> with rx_samples_to_file without _4rx.rbf, Initially I tried on my i3,
> 4GB ram, it gave me
> some OOOO but was lesser than earlier, but I do not understand, my
> most of the ram capacity and processor was sitting idle while it shows
> OOOO, why is this strange behaviour
The default format for uhd_rx_cfile is complex-float, thus doubling the
amount of data written compared to rx_samples_to_file.
You can't just use CPU usage as an indicator of loading--if you're
writing to disk, the disk subsystem may be much slower than you think,
so the
"rate limiting step" is writes to the disk, not computational elements.
Try using /dev/null as the file that you write to. If the 'O' go away,
even at higher sampling rates, then it's your disk subsystem.
> using uhd_rx_cfile getting similar result, but strangely, why it is
> low, at 4M sampling rate it was higher???
>
>
> On Thu, Oct 2, 2014 at 9:27 AM, Marcus D. Leech <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 10/01/2014 11:46 PM, gsmandvoip wrote:
>> Yes I am running single channel, but when trying to achieve my
>> desired sampling rate without _4rx.rbf, it says, requested
>> sampling rate is not valid, adjusting to some 3.9M or so.
>> sorry for misleading info I gave earlier, I have i3, with 32 bit
>> and i7 with 64 bit, but getting same result on both machines
>>
>> Here is my command to capture signal:
>>
>> ./rx_samples_to_file --args="fpga=usrp1_fpga_4rx.rbf,
>> subdev=DBSRX" --freq "$FC" --rate="$SR" $FILE --nsamps "$NSAMPLES"
>>
>> and here is its output:
>>
>> Creating the usrp device with: fpga=usrp1_fpga_4rx.rbf,
>> subdev=DBSRX...
>> -- Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
>> -- Opening a USRP1 device...
>> -- Loading FPGA image:
>> /usr/share/uhd/images/usrp1_fpga_4rx.rbf... done
>> -- Using FPGA clock rate of 52.000000MHz...
>> *Error: LookupError: IndexError:
>> multi_usrp::get_tx_subdev_spec(0) failed to make default spec -
>> ValueError: The subdevice specification "A:0" is too long.*
>> The user specified 1 channels, but there are only 0 tx dsps on
>> mboard 0.
>>
>>
> Don't use the _4rx image if you don't need it.
>
> The USRP1 only does strict-integer resampling, and with a master
> clock (NON STANDARD FOR USRP1) of 52.000MHz, 4Msps is not a sample
> rate
> that it can produce. Try 5.2Msps or 4.3333Msps.
>
> At 5.2Msps, it's recording at roughly 20.8Mbytes/second, so your
> system needs to be able to sustain that for at least as long as
> the capture lasts.
>
>
>
--
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/20141002/487bf7cc/attachment-0001.html>
------------------------------
Message: 25
Date: Thu, 2 Oct 2014 14:08:21 +0100
From: "Simon Brown" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] B200 on YouTube
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi All,
https://www.youtube.com/watch?v=a_o9FD80sio
A B200 receiving BBC Radio Cornwall on 103.9 MHz, the radio and antenna are
in a very noisy environment - my computer room J .
Simon Brown G4ELI
http://v2.sdr-radio.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141002/df514e9a/attachment-0001.html>
------------------------------
Message: 26
Date: Thu, 2 Oct 2014 20:00:18 +0530
From: Abhinav Jadon <[email protected]>
To: [email protected]
Subject: [USRP-users] UHD Related
Message-ID:
<caax7w7+pgas-kv6dis1dvt_qfyzqmnpmu8suh5bnbhus2dh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all ,
I have flashed the USRP with a GNU-Compatible FPGA image and installed
PCI UHD Drivers . And i queried the uhd_find_devices program to check
what device is connected to the system , if any. This yields me a
result ( see attached screenshot) that should naturally imply that
the driver is working correctly and the link layer level connection is
successfully made but the link led is red and blinking and the rest
(REF and PPS ) LEDs do not light up at all . This is contrary to the
REF ,LINK and PPS LEDs turning green when connected to the system
hosting NI-USRP driver . What inference should i draw from this
observation ? Is something wrong ?
Thanks
--
Abhinav PS Jadon
2012122
Btech 2016-ECE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2014-10-02 18_38_57.png
Type: image/png
Size: 169496 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141002/8ef10759/attachment-0001.png>
------------------------------
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 50, Issue 2
*****************************************
