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 stop "usrp_spectrum_sense.py"? (Martin Braun)
2. UHD and B200 unreliable on USB3 card (Mike Willis)
3. Re: UHD and B200 unreliable on USB3 card (Marcus Leech)
4. Re: Stepped Frequency Radar (Haroon Muhammad)
5. Re: UHD and B200 unreliable on USB3 card (Marcus D. Leech)
6. Re: UHD and B200 unreliable on USB3 card (Marcus M?ller)
7. Re: Query - Capturing Spectrum Using USRP N2920 (Amber and Sarosh)
8. Re: Query - Capturing Spectrum Using USRP N2920 (Marcus D. Leech)
9. State of the Rx chain during transmission with XCVR
(Andre Puschmann)
10. Re: State of the Rx chain during transmission with XCVR
(Ian Buckley)
11. X310 and 10G MTU settings (Douglas Geiger)
12. Re: X310 and 10G MTU settings (Marcus D. Leech)
----------------------------------------------------------------------
Message: 1
Date: Mon, 31 Mar 2014 18:03:38 +0200
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] How to stop "usrp_spectrum_sense.py"?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Syed,
It looks like you're not shutting down the receiver thread correctly.
Also, remember the the delete_head() call blocks.
What are you trying to achieve? Do you want to switch off the rx
completely? Maybe for half duplex?
If not, I suggest you continue emptying the rx queue, and simply discard
the information.
Martin
On 03/30/2014 10:25 AM, Syed Aqeel Raza wrote:
> Hi Everyone,
>
> The "usrp_spectrum_sense.py" program is used to sense the defined
> spectrum range. Now, I want to stop it for a period of five second time
> (e.g. from 55 to 59 seconds). For that purpose, I wrote the following
> lines in python.
>
> ================================================
> import usrp_spectrum_sense_updated
>
> import time
>
>
>
> class main_class():
>
>
> # calling the 'usrp_spectrum_sense.py' program
>
>
> def relay_func(self, tb):
>
> while 1:
>
>
> curr_time = time.strftime('%S',time.localtime())
>
>
> if int(curr_time)>=55:
>
> print 'Hello World"
>
> else:
>
> t = usrp_spectrum_sense_updated.ThreadClass()
>
> t.start()
>
>
> tb = usrp_spectrum_sense_updated.my_top_block()
>
> try:
>
> tb.start()
>
> usrp_spectrum_sense_updated.main_loop(tb)
>
>
> except KeyboardInterrupt:
>
> pass
>
> if __name__ == '__main__':
>
> tb = main_class()
>
> tb.relay_func(tb)
>
> ================================================
>
>
> In the above program, I tried to stop sensing for the duration of 5
> seconds (i.e. 55 ---- 59 seconds). The program works fine whenever I
> execute it in between of the mentioned time and it shift automatically
> to the sensing mode at time=0 second; but once it start sensing then it
> never be returned to the print message 'hello world' even when the
> condition is matched.
>
> Earliest and kind response is highly appreciated. Thanks.
>
> Regards,
> Syed Aqeel Raza
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 2
Date: Sat, 29 Mar 2014 15:20:55 -0000
From: "Mike Willis" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] UHD and B200 unreliable on USB3 card
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I have a B200 and a USB3 card on my laptop under Ubuntu 12.04
Dmesg indicates all is well, uhd_find_devices doesn't find the devices - it
does sometimes but not always. The same B200 on a USB2 port is usually
found. Why would Gnuradio be unreliable? I can understand it not working at
all, but not working occasionally. I initially thought power - but that is
not the case if dmesg is to be believed.
These new Ettus bus devices are proving to be a real pain the neck.
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140329/a58dab42/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 31 Mar 2014 16:45:21 +0000 (UTC)
From: Marcus Leech <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] UHD and B200 unreliable on USB3 card
Message-ID: <720266586.71795.1396284321601.JavaMail.mail@webmail10>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140331/b3b05520/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 31 Mar 2014 23:03:00 +0500
From: Haroon Muhammad <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Stepped Frequency Radar
Message-ID:
<CAJ+qE8LORT8bCK3V8wR402Z_Ro9vHDHFo+gNTF3vJA3=_ca...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Dear Mr Braun. I am trying to use 1-2 GHz frequency range. If I don't
implement a two stage super heterodyne receiver, would the phase noise be
at a level to let me figure out something from the received data?
Cheers,
On Monday, March 31, 2014, <[email protected]> wrote:
> Send USRP-users mailing list submissions to
> [email protected] <javascript:;>
>
> 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] <javascript:;>
>
> You can reach the person managing the list at
> [email protected] <javascript:;>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of USRP-users digest..."
>
>
> Today's Topics:
>
> 1. GPSDO and MIMO (Dan Sego)
> 2. Re: GPSDO and MIMO (Mike Jameson)
> 3. KU Band Rx/Tx (hossein talaiee)
> 4. KU Band Rx/Tx (hossein talaiee)
> 5. Re: KU Band Rx/Tx (Marcus M?ller)
> 6. Re: Stepped Frequency Radar (Martin Braun)
> 7. Re: Full bandwidth streaming from X300 to disk (Martin Braun)
> 8. Re: GPSDO and MIMO (Martin Braun)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 30 Mar 2014 10:03:56 -0700
> From: Dan Sego <[email protected] <javascript:;>>
> To: [email protected] <javascript:;>
> Subject: [USRP-users] GPSDO and MIMO
> Message-ID:
> <
> calgevjsajqzzgldxhxoxxx+0nmeuwo98fpdx3otzyyx4bwq...@mail.gmail.com<javascript:;>
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Good morning all;
>
> I would like to use a single GPSDO to provide the 10 MHz coherent reference
> to two N200 chassis. As I read the data sheets it is unclear whether that
> is supported via the MIMO cabling, or if there is an output from N200
> number one (with internal GPSDO) to connect to the second N200 external
> reference.
>
> Advice, comments or suggestions, please.
>
> Dan Sego
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140330/47aa5337/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Sun, 30 Mar 2014 18:26:29 +0100
> From: Mike Jameson <[email protected] <javascript:;>>
> To: Dan Sego <[email protected] <javascript:;>>
> Cc: "[email protected] <javascript:;>" <
> [email protected] <javascript:;>>
> Subject: Re: [USRP-users] GPSDO and MIMO
> Message-ID:
> <
> cajcjmiqeqbafirjzbqw916zqau_ozh8nox2fsn6tpauoojq...@mail.gmail.com<javascript:;>
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Dan,
>
> The MIMO cable carries the 10MHz reference, 1PPS signal and network
> traffic. If you use the UHD source/sink blocks in GRC you can select the
> MIMO cable as the clock source for your second N200.
>
> Cheers,
>
> Mike
>
> --
> Mike Jameson M0MIK BSc MIET
> Email: [email protected] <javascript:;>
> Web: http://scanoo.com
>
>
> On Sun, Mar 30, 2014 at 6:03 PM, Dan Sego
> <[email protected]<javascript:;>>
> wrote:
>
> > Good morning all;
> >
> > I would like to use a single GPSDO to provide the 10 MHz coherent
> > reference to two N200 chassis. As I read the data sheets it is unclear
> > whether that is supported via the MIMO cabling, or if there is an output
> > from N200 number one (with internal GPSDO) to connect to the second N200
> > external reference.
> >
> > Advice, comments or suggestions, please.
> >
> > Dan Sego
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected] <javascript:;>
> > 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/20140330/2d13cc7e/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Sun, 30 Mar 2014 23:03:40 +0430
> From: hossein talaiee <[email protected] <javascript:;>>
> To: "[email protected] <javascript:;>" <
> [email protected] <javascript:;>>
> Subject: [USRP-users] KU Band Rx/Tx
> Message-ID:
> <
> caaibebtn5qdeqzgxqbidxs7f2o9e1fap2gus7erzmk-t3od...@mail.gmail.com<javascript:;>
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Can I use USRP for Rx/Tx in Ku band? Rx: 10.5 GHz and Tx : 14GHz ?
> I think I can use a universal LNB + T-Bias for power for RX but what can
> use for Tx?
> Is there any cheap UCB for 14GHz band?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140330/8df21ce6/attachment-0002.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Sun, 30 Mar 2014 23:03:40 +0430
> From: hossein talaiee <[email protected] <javascript:;>>
> To: "[email protected] <javascript:;>" <
> [email protected] <javascript:;>>
> Subject: [USRP-users] KU Band Rx/Tx
> Message-ID:
> <
> caaibebtn5qdeqzgxqbidxs7f2o9e1fap2gus7erzmk-t3od...@mail.gmail.com<javascript:;>
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Can I use USRP for Rx/Tx in Ku band? Rx: 10.5 GHz and Tx : 14GHz ?
> I think I can use a universal LNB + T-Bias for power for RX but what can
> use for Tx?
> Is there any cheap UCB for 14GHz band?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140330/8df21ce6/attachment-0003.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Sun, 30 Mar 2014 21:02:16 +0200
> From: Marcus M?ller <[email protected] <javascript:;>>
> To: [email protected] <javascript:;>
> Subject: Re: [USRP-users] KU Band Rx/Tx
> Message-ID: <[email protected] <javascript:;>>
> Content-Type: text/plain; charset=ISO-8859-1
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Hossein,
>
> as far as I'm aware of, the highest you can go with any of the Ettus RF
> daughterboards is 6 GHz, so yes, you'll need something to downconvert,
> like an LNB (and a bias tee).
>
> As for cheap Block Upconverters (BUCs): I don't think there are cheap
> (as in sub 200$) solutions, because there is not as much of a mass
> market for satellite uplinks, at least here in central Europe. My best
> guess would be looking for satellite internet access devices on ebay,
> but I guess they won't come cheap; also, used maritime equipment could
> be useful.
>
> Obviously, you have to be *very* aware of regulatory problems if you're
> working with power upconverters with unknown characteristics for TX.
>
> Greetings,
> Marcus
>
> On 30.03.2014 20:33, hossein talaiee wrote:
> > Can I use USRP for Rx/Tx in Ku band? Rx: 10.5 GHz and Tx : 14GHz ?
> > I think I can use a universal LNB + T-Bias for power for RX but what can
> > use for Tx?
> > Is there any cheap UCB for 14GHz band?
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected] <javascript:;>
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTOGo4AAoJEBQ6EdjyzlHtLaMH/2AskBnk9cPQLfvI/gkntCGr
> oVPyrJdFGSErnrsprxukdaCLXWOrgcrXOLP59OmQk0HqgcTPbovZtxjPU7MdafP1
> DMMF34EdtkhfNvXYyiPzmxOJYMe8rbEon/9wSD12Cycs4fT9iJuteiL1zht6KTsr
> Kt9sQchO/Jwaa1vWL9En46YDjGqgrshQ3UDYsw9z+8k+l3yD6WTgZgoSonQbBaLa
> jGpltgQs8nNJtTa5A5V7fqhLDvKvWRUz9eCSAopZOGlK78FzpEYjgNL7PvrizSvD
> Gl5QWWJzBPWmWpHf3b0Xpb/rrit9jf/bhx3Jl/BvbDd8qWwR6AVbb03a2GY21eY=
> =izH9
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 31 Mar 2014 17:08:25 +0200
> From: Martin Braun <[email protected] <javascript:;>>
> To: [email protected] <javascript:;>
> Subject: Re: [USRP-users] Stepped Frequency Radar
> Message-ID: <[email protected] <javascript:;>>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 03/21/2014 02:38 PM, Haroon Muhammad wrote:
> > Hi!
> >
> > Please advice if the WBX along with N-210 can be used to implement a
> > coherent Stepped Frequency Radar which detects the phase difference at
> > each transmitted frequency? Can any other daughterboard serve the
> purpose?
>
> Haroon,
>
> which bandwidths are you trying to achieve here? If you want to stay
> within the available baseband bandwidth, there'll be no problems.
>
> Martin
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 31 Mar 2014 17:40:40 +0200
> From: Martin Braun <[email protected] <javascript:;>>
> To: [email protected] <javascript:;>
> Subject: Re: [USRP-users] Full bandwidth streaming from X300 to disk
> Message-ID: <[email protected] <javascript:;>>
> Content-Type: text/plain; charset=windows-1252
>
> On 03/27/2014 07:09 PM, Mann, John P. - 1003 - MITLL wrote:
> > I?m thinking of buying an X300, and am interested in recording full
> > bandwidth data to hard disk. I realize that the data rates will be
> > insanely high, so what would I need to accomplish this? I currently use
> > Samsung 840pro solid state drives to record data from our N200s, and
> > they handle 100 Mbytes/sec with no problem. But I?m guessing I may need
> > to use a RAID of solid state drives to keep up with the X300? Any
> > chance I could record 2 full bandwidth channels at once?
>
> Hey John,
>
> if you want to record 100 MHz at full resolution (16 bits), then your HD
> will have to support a write speed of at least 400 MB/s (4 bytes per
> sample!), or 800 MB/s if you're recording floats (I guess you don't want
> that).
>
> Experience has shown that SSDs aren't necessarily that much faster than
> HDDs when it comes to sustained writing. If you have a benchmark to test
> writing speed, it should exceed whatever you need (e.g. 400 MB/s) by a
> large margin.
>
> > Also ? I am a bit confused by the spec sheet. It claims a maximum ADC
> > sample rate of 200 MHz, but then says it supports 120 MHz bandwidth.
> > Doesn?t that violate Nyquist? How much instantaneous bandwidth can I
> > actually get out of it?
>
> Those number are actually unrelated. The ADC runs at 200 Msps (I + Q),
> so according to Nyquist, it can sample a 200 MHz chunk of bandwidth.
>
> The 120 MHz come from the analog preselection filters. Our
> daughterboards ship with different types of analog filters, the widest
> you can buy directly have the mentioned 120 MHz bandwidth.
> In practice, you can't use the full Nyquist bandwidth (i.e. the 200 MHz)
> anyway, because you want to avoid aliasing. So if you buy an X300 kit
> w/o modifications, 120 MHz is what you'll get.
>
> > Could I set the decimation to 2, and get 100 MHz complex baseband I/Q
> > data streaming to disk? If so, what would the usable bandwidth be?
>
> If you're using a 120 MHz d'board (e.g. CBX-120), then you can use
> pretty much the entire 100 MHz, minus some space for the digital filter
> flanks. So, if you had a signal that's exactly 100 MHz wide, this would
> be problematic (again, aliasing etc.), but if you only "need" 90 or so,
> you're good.
>
> Martin
>
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 31 Mar 2014 17:57:27 +0200
> From: Martin Braun <[email protected] <javascript:;>>
> To: [email protected] <javascript:;>
> Subject: Re: [USRP-users] GPSDO and MIMO
> Message-ID: <[email protected] <javascript:;>>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 03/30/2014 07:26 PM, Mike Jameson wrote:
> > Hi Dan,
> >
> > The MIMO cable carries the 10MHz reference, 1PPS signal and network
> > traffic. If you use the UHD source/sink blocks in GRC you can select the
> > MIMO cable as the clock source for your second N200.
>
> Also, since you're asking about MIMO: Two N210s connected via MIMO cable
> behave pretty much like one device, only the phase might be offset. Make
> sure you consider this for your MIMO application.
>
> Martin
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <javascript:;>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> ------------------------------
>
> End of USRP-users Digest, Vol 43, Issue 31
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140331/1f004a0f/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 31 Mar 2014 16:38:51 -0400
From: "Marcus D. Leech" <[email protected]>
To: Mike Willis <[email protected]>, "[email protected]"
<[email protected]>, Ben Hilburn <[email protected]>
Subject: Re: [USRP-users] UHD and B200 unreliable on USB3 card
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 03/31/2014 04:32 PM, Mike Willis wrote:
>
> I looked at that page but it does not tell you much about makes so
> what would you recommend? The card was supposed to work and it did
> work until recently. It needs to be an expresscard as this is on a
> laptop.
>
> Mike
>
Unfortunately, those tests were done "by controller type", rather than
by make/model of card. Since there are probably dozens and dozens of
cards extant in the marketplace for the various PCI-e and ExpressCard
form-factors, producing such a table, except by anecdotal evidence
from customers isn't very practical.
Ben: is there an ExpressCard that is known to work well?
Also, there are two different specs out there for ExpressCards --
apparently one has lower peak data rate than the other, so that can get
in the
way as well, for peak-bandwidth applications.
> *From:*Marcus Leech [mailto:[email protected]]
> *Sent:* 31 March 2014 18:01
> *To:* [email protected]
> *Subject:* Re: [USRP-users] UHD and B200 unreliable on USB3 card
>
> From the document I pointed you to:
>
>
> USRP B200 and B210 - USB 3.0 Streaming Rate Benchmarks
>
> *Incompatible USB 3.0 Controllers*
>
> USB 3.0 is a relatively new interface, and some USB 3.0 controllers do
> not perform reliably with devices like SDRs that stream data
> continuously. This is a list of controllers that we do not recommend
> for the USRP B200/B210:
>
> * Any Renesas Technology Controller
> * Any AS Media Controller
> * NEC uPD720200
>
> The ECUSB3S1 uses the NEC controller noted above, so it won`t be
> reliable at all.
>
> on Mar 31, 2014, *Mike Willis* <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Marcus ? it is strange it works sometimes. I don?t think power
> is the issue ? it could be but it has an adapter to take more
> power from a USB port if needed, so I doubt it ? and anyway it
> identifies fine under the OS. It?s one of the star tech express
> cards ECUSB3S1. So much for standards!
>
> Mike
>
> *From:*Marcus Leech [mailto:[email protected]]
> *Sent:* 31 March 2014 17:45
> *To:* [email protected] <mailto:[email protected]>
> *Cc:* [email protected] <mailto:[email protected]>
> *Subject:* Re: [USRP-users] UHD and B200 unreliable on USB3 card
>
> There are some USB-3.0 controllers that "dont play nice" with the
> FX3 chip on the B200 (and also on other SDR devices that happen to
> use FX3 as well).
>
> The AsMedia chips, in particular, are notoriously unreliable.
> Consult the following for a list of device tests that Ettus has done:
>
>
> http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks
>
> Also, I found that in *some* cases, the USB port isn't providing
> *quite* enough power, even for the B200, so using the external
> power supply will cure that issue.
>
> on Mar 31, 2014, *Mike Willis* <[email protected]
> <mailto:[email protected]>> wrote:
>
> I have a B200 and a USB3 card on my laptop under Ubuntu 12.04
>
> Dmesg indicates all is well, uhd_find_devices doesn?t find the
> devices ? it does sometimes but not always. The same B200 on a
> USB2 port is usually found. Why would Gnuradio be unreliable?
> I can understand it not working at all, but not working
> occasionally. I initially thought power ? but that is not the
> case if dmesg is to be believed.
>
> These new Ettus bus devices are proving to be a real pain the
> neck.
>
> Mike
>
>
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140331/c5421a0c/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 01 Apr 2014 00:26:42 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD and B200 unreliable on USB3 card
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Marcus, hi Mike,
On 31.03.2014 22:38, Marcus D. Leech wrote:
> Unfortunately, those tests were done "by controller type", rather
> than by make/model of card. Since there are probably dozens and
> dozens of cards extant in the marketplace for the various PCI-e and
> ExpressCard form-factors, producing such a table, except by
> anecdotal evidence from customers isn't very practical.
To make matters even worse, as USB3 hits mass market, we soon can
expect identically branded cards with differing chipsets...
Mike, since Laptop manufacturers usually have different product lines,
it's hard to say "XY Laptops work well". Sadly, this implies having to
look at the datasheet of every single laptop you're considering.
The hardship here really lies in the USB3 host controller not behaving
completely standards conform - nothing a driver, UHD or GNU Radio
could fix.
Greetings,
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTOeuiAAoJEBQ6EdjyzlHtH/EH/2pKqI8AiyKnbu86LfIpqQSM
+10pp1bAt1cd9LLGNsLg9HkdrfVBzK/APqXAv0dk1PYY5UQwhnxF1ES47/OzUbBH
424W3RYkQb8mnB7sjZDu5PSA0WVWOAEY8PAfw627jZlnPXWjbJaT8n+ZXW0btDA7
puqgNyp76TzH6eN93zt556paEmkr7eBSMBd2lWahiBz2rnrveBQ6vyqFj1PwS4qv
S/q5Sg1X5OQ3gZ3g0NBaXzySz39Ug38LDVPmZjRpH79gUHomVsc/piUtpyUuYZcT
mi+Lh5es7tHfN5sRf3WhpRXesMMtbQz/UCnb4TTY0IbOyUL1aK5wWpCsx3od0xc=
=Twmj
-----END PGP SIGNATURE-----
------------------------------
Message: 7
Date: Tue, 1 Apr 2014 15:57:36 +0500
From: Amber and Sarosh <[email protected]>
To: Marcus M?ller <[email protected]>, "[email protected]"
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Query - Capturing Spectrum Using USRP N2920
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Thank you for your response.
Can you please guide us where can we set the decimation factor for our USRP
within GNU radio scripts so that when we run the uhd_usrp_cfile , it can gather
data at any given sample rate (<=100MSps). As, in our GNU radio software, after
running uhd_usrp_cfile with sample rate parameter value of anything >
5.88MSps, it is giving UHD warning notice that the requested rx sample rate is
not supported by the hardware.
Regards,
Naheed, Amber & Sarosh
> Date: Thu, 27 Mar 2014 17:58:34 +0100
> From: [email protected]
> To: [email protected]
> Subject: Re: [USRP-users] Query - Capturing Spectrum Using USRP N2920
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi!
>
> I don't quite understand your question -- there is no "data at a
> specific frequency"; every signal has a bandwidth > 0, so it spans a
> specific interval around a center frequency.
>
> Try running
> uhd_rx_cfile --help
> . It yields a list of options you can define if you want to use that
> tool to capture samples to a file. Among these options are center
> frequency and sample rate. So you're free to configure the USRP to the
> desired center frequency (if it is in the tuning range of the device)
> and to a set of sampling bandwidth (try using fractions of 100MHz -- a
> sampling rate of 5Ms/s will give you 25 (theoretical) GSM channels; if
> your computer is fast enough, you can get up to 25Ms/s over Gigabit
> Ethernet).
>
> If you want something more sophisticated than what can be done with
> that command, try using the gnuradio-companion. It is an awesome tool
> where you can use the UHD source, connect it to things like filters,
> filter banks, GMSK demodulators, synchronizers etc.
>
> Greetings,
> Marcus
>
> On 27.03.2014 08:07, Amber and Sarosh wrote:
> >
> > Hi all, We are basically trying to capture a part of GSM spectrum
> > so that all the needed ARFCNs for hopping will be included into the
> > bandwidth, Kindly inform if any GNU radio command can help us
> > capture spectrum using the USRP N2920. Can we use the uhd_rx_cfile
> > command to capture a wide spectrum or this command can only capture
> > data at a given specific frequency ?
> >
> > Regards, Naheed, Amber & Sarosh
> >
> >
> >
> > _______________________________________________ USRP-users mailing
> > list [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTNFi6AAoJEBQ6EdjyzlHtlMQH/2HJ+MtQtYZwI8nkXzj6YR74
> 4kDW8wNRdGfsI/xpC9Qbr1Z5R3WNyhJI2hVP/yYrAwKSVy3MyRRFz/g+byiFpnn5
> i15fTmgZguD4AIboC4O0qRuuAWFV/4wctaJv/uDoFhlZAqNas8uLZfxgMG7ggrlE
> CAUOv0WQW9EoVWD7TCHQQQRA8Bb+4yL3zk4EQP99SZL2cfPVXyJnhUKB74Ki2Uq+
> ABKPNIhzaU2gqCxsfdUzL+7idtPeIz9xjOAsz+uOmbMn3fjAcQk6yYRhiKhcvZRn
> ad6iGs0zVFbaf6W7MoGKtI5yEldcDpkz7w1xTO60GWM5dHjEbgQl4t0N5CQAoOs=
> =t1DS
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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/20140401/ea45baed/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 01 Apr 2014 09:14:28 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Query - Capturing Spectrum Using USRP N2920
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 04/01/2014 06:57 AM, Amber and Sarosh wrote:
> Thank you for your response.
> Can you please guide us where can we set the decimation factor for our
> USRP within GNU radio scripts so that when we run the uhd_usrp_cfile ,
> it can gather data at any given sample rate (<=100MSps). As, in our
> GNU radio software, after running uhd_usrp_cfile with sample rate
> parameter value of anything > 5.88MSps, it is giving UHD warning
> notice that the requested rx sample rate is not supported by the
> hardware.
>
> Regards,
> Naheed, Amber & Sarosh
Any sample-rate given *must* be a proper integer fraction of the master
clock rate, which in your case is 100Mhz.
So a sample rate of 5Msps will work, whereas 5.88Msps will not.
--
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/20140401/33c26e06/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 01 Apr 2014 15:45:34 +0200
From: Andre Puschmann <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] State of the Rx chain during transmission with
XCVR
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hi guys,
I have an application that continuously receives and only transmits
bursts every now and then. I am running this on a N210 plus XCVR board.
I believe I've read somewhere that if Tx is active on the half-duplex
board, null-samples are generated on the Rx line during that time. Can
anybody confirm this or am I wrong? I quick try didn't bring the
expected results.
The reason I am asking is that I'd like to know for how long my
transmitter was active inside the Rx part of my radio. I could certainly
get the same information from the transmitter part but not without
significant changes to my radio's SW architecture.
Thanks
-Andre
------------------------------
Message: 10
Date: Tue, 1 Apr 2014 07:37:55 -0700
From: Ian Buckley <[email protected]>
To: Andre Puschmann <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] State of the Rx chain during transmission
with XCVR
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
The RX stream should contain leakage of the TX signal from the radio, the data
is not zero'd out, the radio daughter board is purely analog.
-Ian
On Apr 1, 2014, at 6:45 AM, Andre Puschmann <[email protected]>
wrote:
> Hi guys,
>
> I have an application that continuously receives and only transmits
> bursts every now and then. I am running this on a N210 plus XCVR board.
>
> I believe I've read somewhere that if Tx is active on the half-duplex
> board, null-samples are generated on the Rx line during that time. Can
> anybody confirm this or am I wrong? I quick try didn't bring the
> expected results.
>
> The reason I am asking is that I'd like to know for how long my
> transmitter was active inside the Rx part of my radio. I could certainly
> get the same information from the transmitter part but not without
> significant changes to my radio's SW architecture.
>
> Thanks
> -Andre
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 11
Date: Tue, 01 Apr 2014 11:30:42 -0400
From: Douglas Geiger <[email protected]>
To: [email protected]
Subject: [USRP-users] X310 and 10G MTU settings
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
I'm having some trouble when trying to setup my X310 to talk to my
desktop 10G NIC. In particular I'm having difficulty when setting the
recommended MTU size. It seems to result in some communication errors -
uhd_usrp_probe fails, and if I try to start a flowgraph (e.g. uhd_fft or
osmocom_fft) it errors out during startup.
I don't know if this is a peculiarity of my 10G NIC, or something
else, but it's definitely tied to the MTU size: I don't have any
difficult when I use an MTU of 1500 (uhd_usrp_probe works fine, and when
I start a flowgraph it works fine). Also - using the 1G port/IP address
has no issues. For the 10G port I'm using an Intel x520-DA2 adapter,
which lspci reports as an Intel 82599EB controller. This is on a machine
running Ubuntu 12.04.4 (x86_64).
If I set the NIC MTU to 8192, here's what I see with uhd_usrp_probe:
$ uhd_usrp_probe --args="addr=192.168.40.2"
linux; GNU C++ version 4.6.3; Boost_105300; UHD_003.007.000-0-unknown
-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Initialize Radio control...
-- Performing register loopback test... pass
Error: EnvironmentError: IOError: Radio ctrl (A) no response packet -
AssertionError: bool(buff)
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at
/home/MSS/doug-geiger/src/uhd/uhd-3.7.0/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:196
If I set the NIC MTU to 1500, here's what I see with uhd_usrp_probe:
$ uhd_usrp_probe --args="addr=192.168.40.2"
linux; GNU C++ version 4.6.3; Boost_105300; UHD_003.007.000-0-unknown
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO.... No GPSDO found
-- Initialize Radio control...
UHD Warning:
For this connection, UHD recommends a send frame size of at least
8000 for best
performance, but your system's MTU will only allow 1472.
This will negatively impact your maximum achievable sample rate.
UHD Warning:
For this connection, UHD recommends a receive frame size of at
least 8000 for best
performance, but your system's MTU will only allow 1472.
This will negatively impact your maximum achievable sample rate.
-- Performing register loopback test... pass
-- Sync DAC's.
UHD Warning:
For this connection, UHD recommends a send frame size of at least
8000 for best
performance, but your system's MTU will only allow 1472.
This will negatively impact your maximum achievable sample rate.
UHD Warning:
For this connection, UHD recommends a receive frame size of at
least 8000 for best
performance, but your system's MTU will only allow 1472.
This will negatively impact your maximum achievable sample rate.
-- Performing register loopback test... pass
-- Sync DAC's.
-- Setting references to internal sources
_____________________________________________________
/
| Device: X-Series Device
| _____________________________________________________
| /
| | Mboard: X310
| | revision: 99
| | product: 30410
| | mac-addr0: 00:80:2f:0a:eb:74
| | mac-addr1: 00:80:2f:0a:eb:75
| | gateway: 192.168.10.1
| | ip-addr0: 192.168.10.2
| | subnet0: 255.255.255.0
| | ip-addr1: 192.168.20.2
| | subnet1: 255.255.255.0
| | ip-addr2: 192.168.30.2
| | subnet2: 255.255.255.0
| | ip-addr3: 192.168.40.2
| | subnet3: 255.255.255.0
| | serial: F4E349
| | FW Version: 3.0
| | FPGA Version: 3.0
| |
| | Time sources: internal, external, gpsdo
| | Clock sources: internal, external, gpsdo
| | Sensors: ref_locked
| | _____________________________________________________
| | /
| | | RX DSP: 0
| | | Freq range: -100.000 to 100.000 Mhz
| | _____________________________________________________
| | /
| | | RX DSP: 1
| | | Freq range: -100.000 to 100.000 Mhz
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | ID: SBX (0x0054)
| | | Serial: F4B465
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: SBXv3 RX
| | | | Antennas: TX/RX, RX2, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 400.000 to 4400.000 Mhz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: ads62p48
| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
| | _____________________________________________________
| | /
| | | RX Dboard: B
| | | ID: SBX (0x0054)
| | | Serial: F4B46D
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: SBXv3 RX
| | | | Antennas: TX/RX, RX2, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 400.000 to 4400.000 Mhz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: B
| | | | Name: ads62p48
| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
| | _____________________________________________________
| | /
| | | TX DSP: 0
| | | Freq range: -100.000 to 100.000 Mhz
| | _____________________________________________________
| | /
| | | TX DSP: 1
| | | Freq range: -100.000 to 100.000 Mhz
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | ID: SBX (0x0055)
| | | Serial: F4B465
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: SBXv3 TX
| | | | Antennas: TX/RX, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 400.000 to 4400.000 Mhz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Connection Type: QI
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: ad9146
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: B
| | | ID: SBX (0x0055)
| | | Serial: F4B46D
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: SBXv3 TX
| | | | Antennas: TX/RX, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 400.000 to 4400.000 Mhz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Connection Type: QI
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: B
| | | | Name: ad9146
| | | | Gain Elements: None
Any suggestions on why this might be happening? I know Intel NIC's are
generally pretty high quality, but I don't know if you've tested with
this particular part before. If you have any settings you'd like me to
test out, etc. let me know.
Thanks,
Doug
--
Douglas Geiger
Code 5545
U.S. Naval Research Laboratory
Washington, DC 20375
(202) 767-9048
[email protected]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4632 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140401/6caf92fc/attachment-0001.p7s>
------------------------------
Message: 12
Date: Tue, 01 Apr 2014 11:34:53 -0400
From: "Marcus D. Leech" <[email protected]>
To: Douglas Geiger <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 and 10G MTU settings
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> I'm having some trouble when trying to setup my X310 to talk to my
> desktop 10G NIC. In particular I'm having difficulty when setting the
> recommended MTU size. It seems to result in some communication errors
> - uhd_usrp_probe fails, and if I try to start a flowgraph (e.g.
> uhd_fft or osmocom_fft) it errors out during startup.
>
> I don't know if this is a peculiarity of my 10G NIC, or something
> else, but it's definitely tied to the MTU size: I don't have any
> difficult when I use an MTU of 1500 (uhd_usrp_probe works fine, and
> when I start a flowgraph it works fine). Also - using the 1G port/IP
> address has no issues. For the 10G port I'm using an Intel x520-DA2
> adapter, which lspci reports as an Intel 82599EB controller. This is
> on a machine running Ubuntu 12.04.4 (x86_64).
>
> If I set the NIC MTU to 8192, here's what I see with uhd_usrp_probe:
>
> $ uhd_usrp_probe --args="addr=192.168.40.2"
> linux; GNU C++ version 4.6.3; Boost_105300; UHD_003.007.000-0-unknown
What happens if you just try to do a size-large PING with the larger MTU
settings?
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
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 44, Issue 1
*****************************************
