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: Phase offset drift over time for two x310 (Michael West)
2. Re: [Discuss-gnuradio] New UHD seems to break a lot...
(Ralph A. Schmid, dk5ras)
3. Re: [Discuss-gnuradio] New UHD seems to break a lot...
(Ian Buckley)
4. Re: [Discuss-gnuradio] New UHD seems to break a lot...
(Ralph A. Schmid, dk5ras)
5. Re: Detecting if USRP contended via USB 2.0 or USB 3.0.
(Martin Braun)
6. uhd.tune_request on the fly? (Murphy, John)
7. Re: uhd.tune_request on the fly? (Marcus D. Leech)
8. Re: uhd.tune_request on the fly? (Murphy, John)
9. Re: Question: new (green) USRP B210 and Takachi enclosure
(Dan CaJacob)
10. Re: [Discuss-gnuradio] New UHD seems to break a lot...
(Ian Buckley)
11. Re: [Discuss-gnuradio] New UHD seems to break a lot...
(Ralph A. Schmid, dk5ras)
12. Overrun on 56MHz with B210 (Jason A. Donenfeld)
13. Re: Overrun on 56MHz with B210 (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Fri, 17 Apr 2015 09:50:49 -0700
From: Michael West <[email protected]>
To: [email protected]
Cc: Damiano Scanferla <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Phase offset drift over time for two x310
Message-ID:
<cam4xkrqp6lt9cpoub0ev8mryxs4uzxk8l2yybql4ccej+xm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Ruben,
The change in 3.8.3 is to reduce the phase oscillations. The issue of the
phase offset drift is still under investigation.
Regards,
Michael
On Fri, Apr 17, 2015 at 2:47 AM, <[email protected]> wrote:
> Hello Folks,
>
> Is there any update on this drift issue? I noticed ?X300: Improved phase
> alignment across devices?
>
> in the latest 003.008.003 changelog.
>
> Thanks for all the work
>
> Ruben
>
>
>
> *From:* USRP-users [mailto:[email protected]] *On Behalf
> Of *Michael West via USRP-users
> *Sent:* Monday, March 30, 2015 7:55 PM
> *To:* Damiano Scanferla
> *Cc:* usrp-users
> *Subject:* Re: [USRP-users] Phase offset drift over time for two x310
>
>
>
> Hi Damiano,
>
> The change Neel sent you was to reduce the oscillations, not the drift.
> We are actively looking into the drift and will let you know what we find
> as soon as possible.
>
> Regards,
>
> Michael
>
>
>
> On Mon, Mar 30, 2015 at 8:18 AM, Damiano Scanferla via USRP-users <
> [email protected]> wrote:
>
> Hello Neel,
>
>
>
> Thanks for your answer. I have tried what you suggested but we did not see
> any significant improvements:
>
> - the phase offset at 2.7 GHz drifted by 40 degrees over 3 minutes (same
> as before)
>
> - the oscillations of the phase offset over short time were reduced.
>
>
>
> Do you have a reason for this phase offset drift over time?
>
>
>
> Damiano
>
>
>
> On Mon, Mar 30, 2015 at 3:54 PM, Neel Pandeya <[email protected]>
> wrote:
>
> Hello Damiano Scanferla:
>
> We have seen this issue before, and we believe that we have a solution
> that should improve the results that you're seeing. I would like to ask you
> to make a one-line change on line 193 of the file
> "uhd/host/lib/usrp/x300/x300_clock_ctrl.cpp", and then re-build and
> re-install UHD. I've attached a copy of the file with the change in it. It
> is necessary that you are running UHD 3.8.2 for this to work. I assume that
> you're on Linux, such as Ubuntu 14.04. Please let me know if you see better
> results with this change, or if you have any problems making the code
> change. Thanks.
>
> --Neel
>
>
>
> On 27 March 2015 at 05:58, Damiano Scanferla via USRP-users <
> [email protected]> wrote:
>
> Hi,
>
> I would like to achieve phase alignment at two receivers being 2 SBX-120
> daughter-boards of either the same X310 or belonging to 2 different X310s.
>
> I can measure the phase offset between the two receivers and compensate
> for it. The problem is that the phase offset is not constant but it is
> drifting over time. Of course I can do a periodic calibration of the
> receivers but I read in several blogs that the phase offset should be
> constant so I am wondering what I am not doing properly in my setup.
>
> SETUP
> An RF signal at 800 MHz or 2700 MHz is generated with a signal generator
> (R&S SMJ100A) and fed to 2 daughter-boards via splitter and 2 cables of the
> same length. At the receiving USRPs, I just measure the phase difference
> between the samples received by receiver 1 and receiver 2 (phase offset).
> The USRPs get the 10 MHz ref and PPS from an OctoClock (both clock_source
> and time_source set to "external", and sync set to "unknown PPS").
>
> I have attached the "grc file" and the slope of the phase offset over 3
> minutes for the following configurations:
>
> - 800 MHz, 2 SBX-120 in 1 X310
>
> - 800 MHz, 1 SBX-120 in 2 different X310
> - 2700 MHz, 2 SBX-120 in 1 X310
> - 2700 MHz, 1 SBX-120 in 2 different X310
>
>
>
> 2 observations:
>
> - the higher the frequency, the higher the phase drift (almost linear with
> frequency). So, could it be due to a phase drift of the 10 MHz reference?
>
> - the phase drift is lower when the 2 daughter-boards belong to the same
> X310.
>
> Do you know what could be the reason for this? Have you ever seen such
> behaviour?
>
> Best regards,
>
> Damiano
>
>
>
>
>
> _______________________________________________
> 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/20150417/cbed5abf/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 17 Apr 2015 19:00:39 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Martin Braun'" <[email protected]>,
<[email protected]>, "'GNU Radio Discussion List'"
<[email protected]>, "'Ian Buckley'" <[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] New UHD seems to break a
lot...
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
OK, here we go. The hotel TV was dvb-c only, so I had to do the tests back
at home.
I took my perfectly working Kubuntu 14.04 64 bit VM container together with
my B210, made a copy and updated this one, first I made a git pull to get
latest master, built it, rebuilt gnuradio, rebuilt gr-dvbt, updated the FPGA
images, and everything still was fine. The chosen dvb-t bandwidth is 8 MHz.
Then I changed to 003_008_003_rc1, did the same procedure, fired up grc, and
the signal was not decodable both with a dvb-t PC receiver and with an dvb-x
analyzer. The analyzer saw the RF level, but no data, no constellation,
nothing, it looked to him like interference.
When you have a look at the two "uhd" screenshots here
http://dk5ras.dyndns.org/tmp/DVB/ made with my spectrum analyzer then you
will find that RC1 produces a somehow narrower signal, so it really looks
something gets cut at the ends with all the filtering and DSP stuff.
Adjusting the channel bandwidth in the uhd sink block from 0 to a sensible
value changes nothing.
Btw., the dvb-t2 package behaves identical.
Ralph.
-----Original Message-----
From: Martin Braun [mailto:[email protected]]
Sent: Wednesday, April 15, 2015 21:14
To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
master works, but RC1 does not? Huh, I'm confused now. Can you give some
detail on what's going on, so we can try and reproduce this?
Thanks,
Martin
On 15.04.2015 12:52, Ralph A. Schmid, dk5ras wrote:
> RC1, master seems to work.
>
> Ralph.
>
> -----Original Message-----
> From: Martin Braun [mailto:[email protected]]
> Sent: Wednesday, April 15, 2015 15:44
> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
> Discussion List'
> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>
> Thanks, Ralph. Just to clarify: When you say 'New UHD', do you mean
> 3.8.3-RC1, or latest master?
>
> Martin
>
> On 15.04.2015 08:40, Ralph A. Schmid, dk5ras wrote:
>> It is a B210, but as a note, due to the up to now missing FPGA images
>> I used 003.008.003-RC1, not the latest master. Still I had no access
>> to a spectrum and DVB-T analyzer, so I have no idea what is
>> happening, I just can confirm that RF is transmitted, and the
>> receiver doesn't get a picture, while with the snapshot of the same
>> VM before the upgrade
> is received without problems.
>> I will know more in about three hours.
>>
>> Ralph.
>>
>>> -----Original Message-----
>>> From: Martin Braun [mailto:[email protected]]
>>> Sent: Wednesday, April 15, 2015 3:15 PM
>>> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
>>> Discussion List'
>>> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>>>
>>> On 15.04.2015 06:20, Ralph A. Schmid, dk5ras wrote:
>>>> Hi,
>>>>
>>>> Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more
>>>> with latest uhd. A quick check during lunch break showed, the
>>>> produced output is not decodable any more. I will take a closer
>>>> look this evening at home, where I have more and better equipment.
>>>
>>> Ralph,
>>>
>>> which device is this on?
>>>
>>> Thanks,
>>> Martin
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150417/2239254a/attachment-0001.sig>
------------------------------
Message: 3
Date: Fri, 17 Apr 2015 10:24:47 -0700
From: Ian Buckley <[email protected]>
To: "Ralph A. Schmid, dk5ras" <[email protected]>
Cc: [email protected], 'GNU Radio Discussion List'
<[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] New UHD seems to break a
lot...
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Great Ralph, thats a big help. Can you send me your exact flow graph used to
generate these 2 plots off list please. I want to re run this scenario and see
your exact configuration.
Thanks
-Ian
On Apr 17, 2015, at 10:00 AM, "Ralph A. Schmid, dk5ras" <[email protected]>
wrote:
> OK, here we go. The hotel TV was dvb-c only, so I had to do the tests back
> at home.
>
> I took my perfectly working Kubuntu 14.04 64 bit VM container together with
> my B210, made a copy and updated this one, first I made a git pull to get
> latest master, built it, rebuilt gnuradio, rebuilt gr-dvbt, updated the FPGA
> images, and everything still was fine. The chosen dvb-t bandwidth is 8 MHz.
>
> Then I changed to 003_008_003_rc1, did the same procedure, fired up grc, and
> the signal was not decodable both with a dvb-t PC receiver and with an dvb-x
> analyzer. The analyzer saw the RF level, but no data, no constellation,
> nothing, it looked to him like interference.
>
> When you have a look at the two "uhd" screenshots here
> http://dk5ras.dyndns.org/tmp/DVB/ made with my spectrum analyzer then you
> will find that RC1 produces a somehow narrower signal, so it really looks
> something gets cut at the ends with all the filtering and DSP stuff.
> Adjusting the channel bandwidth in the uhd sink block from 0 to a sensible
> value changes nothing.
>
> Btw., the dvb-t2 package behaves identical.
>
> Ralph.
>
>
> -----Original Message-----
> From: Martin Braun [mailto:[email protected]]
> Sent: Wednesday, April 15, 2015 21:14
> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
> Discussion List'
> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>
> master works, but RC1 does not? Huh, I'm confused now. Can you give some
> detail on what's going on, so we can try and reproduce this?
>
> Thanks,
> Martin
>
> On 15.04.2015 12:52, Ralph A. Schmid, dk5ras wrote:
>> RC1, master seems to work.
>>
>> Ralph.
>>
>> -----Original Message-----
>> From: Martin Braun [mailto:[email protected]]
>> Sent: Wednesday, April 15, 2015 15:44
>> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
>> Discussion List'
>> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>>
>> Thanks, Ralph. Just to clarify: When you say 'New UHD', do you mean
>> 3.8.3-RC1, or latest master?
>>
>> Martin
>>
>> On 15.04.2015 08:40, Ralph A. Schmid, dk5ras wrote:
>>> It is a B210, but as a note, due to the up to now missing FPGA images
>>> I used 003.008.003-RC1, not the latest master. Still I had no access
>>> to a spectrum and DVB-T analyzer, so I have no idea what is
>>> happening, I just can confirm that RF is transmitted, and the
>>> receiver doesn't get a picture, while with the snapshot of the same
>>> VM before the upgrade
>> is received without problems.
>>> I will know more in about three hours.
>>>
>>> Ralph.
>>>
>>>> -----Original Message-----
>>>> From: Martin Braun [mailto:[email protected]]
>>>> Sent: Wednesday, April 15, 2015 3:15 PM
>>>> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
>>>> Discussion List'
>>>> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>>>>
>>>> On 15.04.2015 06:20, Ralph A. Schmid, dk5ras wrote:
>>>>> Hi,
>>>>>
>>>>> Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more
>>>>> with latest uhd. A quick check during lunch break showed, the
>>>>> produced output is not decodable any more. I will take a closer
>>>>> look this evening at home, where I have more and better equipment.
>>>>
>>>> Ralph,
>>>>
>>>> which device is this on?
>>>>
>>>> Thanks,
>>>> Martin
>>>
>>
>>
>
>
------------------------------
Message: 4
Date: Fri, 17 Apr 2015 20:48:54 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Ian Buckley'" <[email protected]>
Cc: [email protected], 'GNU Radio Discussion List'
<[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] New UHD seems to break a
lot...
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I have put it all here, flow graphs and screenshots of the flow graphs:
http://dk5ras.dyndns.org/tmp/DVB/
This way we can keep it on the list without sending attachments.
They were taken from the VM container before all the upgrades were made, but
I did not change anything when upgrading.
Ralph.
-----Original Message-----
From: Ian Buckley [mailto:[email protected]]
Sent: Friday, April 17, 2015 19:25
To: Ralph A. Schmid, dk5ras
Cc: 'Martin Braun'; [email protected]; 'GNU Radio Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
Great Ralph, thats a big help. Can you send me your exact flow graph used to
generate these 2 plots off list please. I want to re run this scenario and
see your exact configuration.
Thanks
-Ian
On Apr 17, 2015, at 10:00 AM, "Ralph A. Schmid, dk5ras" <[email protected]>
wrote:
> OK, here we go. The hotel TV was dvb-c only, so I had to do the tests
> back at home.
>
> I took my perfectly working Kubuntu 14.04 64 bit VM container together
> with my B210, made a copy and updated this one, first I made a git
> pull to get latest master, built it, rebuilt gnuradio, rebuilt
> gr-dvbt, updated the FPGA images, and everything still was fine. The
chosen dvb-t bandwidth is 8 MHz.
>
> Then I changed to 003_008_003_rc1, did the same procedure, fired up
> grc, and the signal was not decodable both with a dvb-t PC receiver
> and with an dvb-x analyzer. The analyzer saw the RF level, but no
> data, no constellation, nothing, it looked to him like interference.
>
> When you have a look at the two "uhd" screenshots here
> http://dk5ras.dyndns.org/tmp/DVB/ made with my spectrum analyzer then
> you will find that RC1 produces a somehow narrower signal, so it
> really looks something gets cut at the ends with all the filtering and DSP
stuff.
> Adjusting the channel bandwidth in the uhd sink block from 0 to a
> sensible value changes nothing.
>
> Btw., the dvb-t2 package behaves identical.
>
> Ralph.
>
>
> -----Original Message-----
> From: Martin Braun [mailto:[email protected]]
> Sent: Wednesday, April 15, 2015 21:14
> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
> Discussion List'
> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>
> master works, but RC1 does not? Huh, I'm confused now. Can you give
> some detail on what's going on, so we can try and reproduce this?
>
> Thanks,
> Martin
>
> On 15.04.2015 12:52, Ralph A. Schmid, dk5ras wrote:
>> RC1, master seems to work.
>>
>> Ralph.
>>
>> -----Original Message-----
>> From: Martin Braun [mailto:[email protected]]
>> Sent: Wednesday, April 15, 2015 15:44
>> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
>> Discussion List'
>> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>>
>> Thanks, Ralph. Just to clarify: When you say 'New UHD', do you mean
>> 3.8.3-RC1, or latest master?
>>
>> Martin
>>
>> On 15.04.2015 08:40, Ralph A. Schmid, dk5ras wrote:
>>> It is a B210, but as a note, due to the up to now missing FPGA
>>> images I used 003.008.003-RC1, not the latest master. Still I had no
>>> access to a spectrum and DVB-T analyzer, so I have no idea what is
>>> happening, I just can confirm that RF is transmitted, and the
>>> receiver doesn't get a picture, while with the snapshot of the same
>>> VM before the upgrade
>> is received without problems.
>>> I will know more in about three hours.
>>>
>>> Ralph.
>>>
>>>> -----Original Message-----
>>>> From: Martin Braun [mailto:[email protected]]
>>>> Sent: Wednesday, April 15, 2015 3:15 PM
>>>> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
>>>> Discussion List'
>>>> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>>>>
>>>> On 15.04.2015 06:20, Ralph A. Schmid, dk5ras wrote:
>>>>> Hi,
>>>>>
>>>>> Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more
>>>>> with latest uhd. A quick check during lunch break showed, the
>>>>> produced output is not decodable any more. I will take a closer
>>>>> look this evening at home, where I have more and better equipment.
>>>>
>>>> Ralph,
>>>>
>>>> which device is this on?
>>>>
>>>> Thanks,
>>>> Martin
>>>
>>
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150417/6e62b39d/attachment-0001.sig>
------------------------------
Message: 5
Date: Fri, 17 Apr 2015 14:24:20 -0500
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Detecting if USRP contended via USB 2.0 or
USB 3.0.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
If you're running a B210, you can query /mboards/0/link_max_rate on the
property tree.
Cheers,
Martin
On 16.04.2015 14:18, Weaver, Tyler via USRP-users wrote:
> Hello Marcus,
>
> Thank you for the help. I need to access it through a UHD application.
> Using your method I got these two results when connecting:
>
> usb 2: 3.2e+07
> usb 3: 5e+08
>
> The question I have relates to the usb 2 rate. I?ve read that the
> greatest sample rate under usb 2 is 8 MS/s. Are these numbers in
> bytes/s? If so that would make sense that you need 32e6 bytes/s to
> transfer 8e6 2x16bit complex values. Is this correct?
>
> tyler
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 6
Date: Fri, 17 Apr 2015 15:45:54 -0400
From: "Murphy, John" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] uhd.tune_request on the fly?
Message-ID:
<CAOyy2vXb7mrLRg23SDR84CA-k40-=7DW_nF57tOSpfmHyz2q=w...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
I am trying to change center frequencies in response to GUI text entry.
Other blocks in the flowgraph accept and propogate the change in the
GUI text thru a variable in GRC.
But the UHD does not appear to change frequencies "on the fly" like
this. It will only change when I stop the flowgraph, execute the
change, and re-start.
Is this the expected behavior when you pass a uhd.tune_request() to
the center frequency parameter of a UHD Source block in GRC? Or maybe
something with the version I am using anyhow? Or just something I am
doing incorrectly?
GR 3.7.6.1
UHD 3.8.1
UHD Source Block Ch0 Center Freq
B200 (one of the old white boards)
GPSDO on board if it by some chance matters
center_freq and samp_rate are GRC flowgraph variables from QT GUI
Entries with those names
exact param is uhd.tune_request(center_freq, samp_rate / 2.0)
similarly changing samp_rate (say, between 2M and 4M) *works on the
fly* (for the samp_rate, it does not seem to change the tune request
either)
changing center_freq from 600M-ish to 1600M-ish for instance does not
actually tune the receiver.
even though I see the rest of the flowgraph update because axis labels
on the GUI etc change
(plus I have debug printfs that pop out when I change frequencies in a
custom block)
Thanks
John Murphy
[email protected]
------------------------------
Message: 7
Date: Fri, 17 Apr 2015 16:22:55 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] uhd.tune_request on the fly?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 04/17/2015 03:45 PM, Murphy, John via USRP-users wrote:
> I am trying to change center frequencies in response to GUI text entry.
> Other blocks in the flowgraph accept and propogate the change in the
> GUI text thru a variable in GRC.
> But the UHD does not appear to change frequencies "on the fly" like
> this. It will only change when I stop the flowgraph, execute the
> change, and re-start.
>
> Is this the expected behavior when you pass a uhd.tune_request() to
> the center frequency parameter of a UHD Source block in GRC? Or maybe
> something with the version I am using anyhow? Or just something I am
> doing incorrectly?
>
> GR 3.7.6.1
> UHD 3.8.1
> UHD Source Block Ch0 Center Freq
> B200 (one of the old white boards)
> GPSDO on board if it by some chance matters
>
> center_freq and samp_rate are GRC flowgraph variables from QT GUI
> Entries with those names
> exact param is uhd.tune_request(center_freq, samp_rate / 2.0)
> similarly changing samp_rate (say, between 2M and 4M) *works on the
> fly* (for the samp_rate, it does not seem to change the tune request
> either)
> changing center_freq from 600M-ish to 1600M-ish for instance does not
> actually tune the receiver.
> even though I see the rest of the flowgraph update because axis labels
> on the GUI etc change
> (plus I have debug printfs that pop out when I change frequencies in a
> custom block)
>
> Thanks
>
> John Murphy
> [email protected]
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Please include your .grc file, and perhaps use the discuss-gnuradio
mailing list.
UHD absolutely tunes on-the-fly, and if it's handed a tune_request_t
on-the-fly will indeed honor it. The question is whether GRC is
actually, because of
the way you have your variables structured, handing the UHD block a
fresh tune_request_t dynamically or not.
------------------------------
Message: 8
Date: Fri, 17 Apr 2015 16:51:07 -0400
From: "Murphy, John" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] uhd.tune_request on the fly?
Message-ID:
<CAOyy2vW3RMweiaACi=2bt9swwzlsv_gazbde0d0o+gonxgt...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Actually it looks like if I have an intermediate GRC variable with the
uhd.tune_request() and pass that to the UHD block it will tune on the
fly. Odd, but I can handle that.
Thanks.
John Murphy
[email protected]
On Fri, Apr 17, 2015 at 3:45 PM, Murphy, John <[email protected]> wrote:
> I am trying to change center frequencies in response to GUI text entry.
> Other blocks in the flowgraph accept and propogate the change in the
> GUI text thru a variable in GRC.
> But the UHD does not appear to change frequencies "on the fly" like
> this. It will only change when I stop the flowgraph, execute the
> change, and re-start.
>
> Is this the expected behavior when you pass a uhd.tune_request() to
> the center frequency parameter of a UHD Source block in GRC? Or maybe
> something with the version I am using anyhow? Or just something I am
> doing incorrectly?
>
> GR 3.7.6.1
> UHD 3.8.1
> UHD Source Block Ch0 Center Freq
> B200 (one of the old white boards)
> GPSDO on board if it by some chance matters
>
> center_freq and samp_rate are GRC flowgraph variables from QT GUI
> Entries with those names
> exact param is uhd.tune_request(center_freq, samp_rate / 2.0)
> similarly changing samp_rate (say, between 2M and 4M) *works on the
> fly* (for the samp_rate, it does not seem to change the tune request
> either)
> changing center_freq from 600M-ish to 1600M-ish for instance does not
> actually tune the receiver.
> even though I see the rest of the flowgraph update because axis labels
> on the GUI etc change
> (plus I have debug printfs that pop out when I change frequencies in a
> custom block)
>
> Thanks
>
> John Murphy
> [email protected]
------------------------------
Message: 9
Date: Fri, 17 Apr 2015 18:06:42 -0400
From: Dan CaJacob <[email protected]>
To: Piotr Krysik <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Question: new (green) USRP B210 and Takachi
enclosure
Message-ID:
<camomjoah8bv7hwyjwzxuoz7o8dqm-5bbp6yqz1kimyoeznt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I may or may not have been able to purchase pre-drilled enclosures directly
from Takachi for the latest B2XX models...
Very Respectfully,
Dan CaJacob
On Fri, Apr 3, 2015 at 4:14 AM, Piotr Krysik via USRP-users <
[email protected]> wrote:
> Many thanks Patrick!
>
> Your answer is exactly what I needed to know.
>
> Best Regards,
> Piotr Krysik
>
> W dniu 03.04.2015 o 00:54, Patrick Sathyanathan pisze:
> > Correction: "SMA connector/USB/power jack holes"
> >
> > --Patrick
> >
> > ------------------------------------------------------------------------
> > From: [email protected]
> > To: [email protected]
> > Subject: RE: [USRP-users] Question: new (green) USRP B210 and Takachi
> > enclosure
> > Date: Thu, 2 Apr 2015 15:43:17 -0700
> >
> > I recently purchased a B210 enclosure from Takachi and the model I
> > ordered was MXA3-11-16SSH (though the label on the packing said
> > something like FXA3-11-16SSH, can't confirm right now). It fits my
> > revision 6 B210 perfectly. It comes with printing of the front and
> > back panels, which have all SMA connector/UDB/power jack holes, as
> > well as two screw holes in each plate (screws included). You should
> > tell them that it's for the rev 6 and they have all the drawings for it.
> >
> > Here is a snippet from their invoice:
> >
> > *
> >
> > Customization : Ettus B210 ver.6
> >
> > */
> >
> > Enclosure : USD17.93 /unit
> >
> > /
> >
> > All Alu. Mobile Enclosure, Torx-screws
> >
> > Silver Anodized Frames / Silver Anodized End-panels
> >
> > /
> >
> > Milling : USD62.89 /unit
> >
> > /
> >
> > DRW#B2Xx_PLATE_R2_111814 (Updated Nov.20,2014)
> >
> > Note: All inner-side corners of rectangular cutouts are R0.5 (Radius
> >
> > 0.5mm).
> >
> > Note: Base material (color) is visible after machined.
> >
> > /
> >
> > Inkjet-printing : USD26.55 /unit
> >
> > /
> >
> > ART#B2Xx_PLATE_R2_111814 (Updated Nov.20,2014)
> >
> > 2-side, 1-color (Black)
> >
> > --Patrick
> > > Date: Thu, 2 Apr 2015 15:42:42 +0200
> > > To: [email protected]
> > > Subject: Re: [USRP-users] Question: new (green) USRP B210 and
> > Takachi enclosure
> > > From: [email protected]
> > >
> > > W dniu 02.04.2015 o 15:19, David via USRP-users pisze:
> > > > On 2015-04-02 14:14, Piotr Krysik via USRP-users wrote:
> > > >> Hi all,
> > > >>
> > > >> I wonder if Takachi enclosure MXA3-11-16 is suitable for USRP B210
> > > >> revision 6?
> > > >> If yes - is there design for drilling holes in the front and back
> > of the
> > > >> enclosure available?
> > > >
> > > > It doesn't directly answer your question, but an old reply of mine
> > > > might help you:
> > > >
> >
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-February/012608.html
> > > >
> > > > David
> > > >
> > > I've seen that post but I have following situation:
> > > I'm in advanced talks with a company based in Poland regarding purchase
> > > of 4 Takachi enclosures (with drilled holes and with printing) for B210
> > > devices that we are going to buy. But I just figured out that Takachi
> > > enclosures were advised for white USRPs B210 and there is no
> information
> > > if the revision 6 devices will fit in it. I cannot find any drawing
> with
> > > dimensions for drilling holes in the enclosure for revision 6 B210.
> > >
> > > There is this file:
> > >
> >
> http://files.ettus.com/b2x0_enclosure/B210_PLATE_REV1.2_070913_FINAL2.pdf
> > > but there are no dimensions.
> > >
> > > Piotr
> > >
> > > _______________________________________________
> > > 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/20150417/506f49a5/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 17 Apr 2015 18:44:58 -0700
From: Ian Buckley <[email protected]>
To: "Ralph A. Schmid, dk5ras" <[email protected]>
Cc: [email protected], 'GNU Radio Discussion List'
<[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] New UHD seems to break a
lot...
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Ralph,
I'm not able to access either of the .grc files on your website, but using the
original dvbt_tx_demo_8k flow graph from gr-dvbt, the spectrum I generate with
003.008.003-RC1 has a 3dB bandwidth of about ~7.5MHz the same as your
uhd_master screen shot. I don't see the truncated bandwidth of your uhd_rc1
screenshot. http://ianbuckley.net/dvbt.jpg
Can you verify please that you have UHD at the current 003.008.003-RC1 tag
position git hash 2fe319d9790c7ec0bcdb9582c4fea95f3fd809b9, and that the
downloaded FPGA images are from:
http://files.ettus.com/binaries/images/uhd-images_003.008.003-rc1.zip
I'll need your exact flow graph if I'm to debug this anymore.
-Ian
On Apr 17, 2015, at 11:48 AM, "Ralph A. Schmid, dk5ras" <[email protected]>
wrote:
> I have put it all here, flow graphs and screenshots of the flow graphs:
>
> http://dk5ras.dyndns.org/tmp/DVB/
>
> This way we can keep it on the list without sending attachments.
>
> They were taken from the VM container before all the upgrades were made, but
> I did not change anything when upgrading.
>
> Ralph.
>
>
>
> -----Original Message-----
> From: Ian Buckley [mailto:[email protected]]
> Sent: Friday, April 17, 2015 19:25
> To: Ralph A. Schmid, dk5ras
> Cc: 'Martin Braun'; [email protected]; 'GNU Radio Discussion List'
> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>
> Great Ralph, thats a big help. Can you send me your exact flow graph used to
> generate these 2 plots off list please. I want to re run this scenario and
> see your exact configuration.
>
> Thanks
> -Ian
>
> On Apr 17, 2015, at 10:00 AM, "Ralph A. Schmid, dk5ras" <[email protected]>
> wrote:
>
>> OK, here we go. The hotel TV was dvb-c only, so I had to do the tests
>> back at home.
>>
>> I took my perfectly working Kubuntu 14.04 64 bit VM container together
>> with my B210, made a copy and updated this one, first I made a git
>> pull to get latest master, built it, rebuilt gnuradio, rebuilt
>> gr-dvbt, updated the FPGA images, and everything still was fine. The
> chosen dvb-t bandwidth is 8 MHz.
>>
>> Then I changed to 003_008_003_rc1, did the same procedure, fired up
>> grc, and the signal was not decodable both with a dvb-t PC receiver
>> and with an dvb-x analyzer. The analyzer saw the RF level, but no
>> data, no constellation, nothing, it looked to him like interference.
>>
>> When you have a look at the two "uhd" screenshots here
>> http://dk5ras.dyndns.org/tmp/DVB/ made with my spectrum analyzer then
>> you will find that RC1 produces a somehow narrower signal, so it
>> really looks something gets cut at the ends with all the filtering and DSP
> stuff.
>> Adjusting the channel bandwidth in the uhd sink block from 0 to a
>> sensible value changes nothing.
>>
>> Btw., the dvb-t2 package behaves identical.
>>
>> Ralph.
>>
>>
>> -----Original Message-----
>> From: Martin Braun [mailto:[email protected]]
>> Sent: Wednesday, April 15, 2015 21:14
>> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
>> Discussion List'
>> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>>
>> master works, but RC1 does not? Huh, I'm confused now. Can you give
>> some detail on what's going on, so we can try and reproduce this?
>>
>> Thanks,
>> Martin
>>
>> On 15.04.2015 12:52, Ralph A. Schmid, dk5ras wrote:
>>> RC1, master seems to work.
>>>
>>> Ralph.
>>>
>>> -----Original Message-----
>>> From: Martin Braun [mailto:[email protected]]
>>> Sent: Wednesday, April 15, 2015 15:44
>>> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
>>> Discussion List'
>>> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>>>
>>> Thanks, Ralph. Just to clarify: When you say 'New UHD', do you mean
>>> 3.8.3-RC1, or latest master?
>>>
>>> Martin
>>>
>>> On 15.04.2015 08:40, Ralph A. Schmid, dk5ras wrote:
>>>> It is a B210, but as a note, due to the up to now missing FPGA
>>>> images I used 003.008.003-RC1, not the latest master. Still I had no
>>>> access to a spectrum and DVB-T analyzer, so I have no idea what is
>>>> happening, I just can confirm that RF is transmitted, and the
>>>> receiver doesn't get a picture, while with the snapshot of the same
>>>> VM before the upgrade
>>> is received without problems.
>>>> I will know more in about three hours.
>>>>
>>>> Ralph.
>>>>
>>>>> -----Original Message-----
>>>>> From: Martin Braun [mailto:[email protected]]
>>>>> Sent: Wednesday, April 15, 2015 3:15 PM
>>>>> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
>>>>> Discussion List'
>>>>> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>>>>>
>>>>> On 15.04.2015 06:20, Ralph A. Schmid, dk5ras wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more
>>>>>> with latest uhd. A quick check during lunch break showed, the
>>>>>> produced output is not decodable any more. I will take a closer
>>>>>> look this evening at home, where I have more and better equipment.
>>>>>
>>>>> Ralph,
>>>>>
>>>>> which device is this on?
>>>>>
>>>>> Thanks,
>>>>> Martin
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150417/e4c9e356/attachment-0001.html>
------------------------------
Message: 11
Date: Sat, 18 Apr 2015 09:24:42 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Ian Buckley'" <[email protected]>
Cc: [email protected], 'GNU Radio Discussion List'
<[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] New UHD seems to break a
lot...
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Yes, I can confirm hash 2fe3..., and the images were downloaded with the
supplied uhd_image_downloader, what is configured like this:
_DEFAULT_BASE_URL = "http://files.ettus.com/binaries/images/";
_AUTOGEN_IMAGES_FILENAME = "uhd-images_003.008.003-rc1.zip"
_AUTOGEN_IMAGES_CHECKSUM = "8522b02386f5fe0bb51baa3ba0001ef0"
The GRC filkes are accessible now, the only modifications I made were due to
Ron Economos' hints regarding sampling rate, and I added a frequency slider
to choose the correct European TV channel without having to know the
frequency.
Ralph.
From: Ian Buckley [mailto:[email protected]]
Sent: Saturday, April 18, 2015 03:45
To: Ralph A. Schmid, dk5ras
Cc: 'Martin Braun'; [email protected]; 'GNU Radio Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
Ralph,
I'm not able to access either of the .grc files on your website, but using
the original dvbt_tx_demo_8k flow graph from gr-dvbt, the spectrum I
generate with 003.008.003-RC1 has a 3dB bandwidth of about ~7.5MHz the same
as your uhd_master screen shot. I don't see the truncated bandwidth of your
uhd_rc1 screenshot. http://ianbuckley.net/dvbt.jpg
Can you verify please that you have UHD at the current 003.008.003-RC1 tag
position git hash 2fe319d9790c7ec0bcdb9582c4fea95f3fd809b9, and that the
downloaded FPGA images are from:
http://files.ettus.com/binaries/images/uhd-images_003.008.003-rc1.zip
I'll need your exact flow graph if I'm to debug this anymore.
-Ian
On Apr 17, 2015, at 11:48 AM, "Ralph A. Schmid, dk5ras" <[email protected]>
wrote:
I have put it all here, flow graphs and screenshots of the flow graphs:
http://dk5ras.dyndns.org/tmp/DVB/
This way we can keep it on the list without sending attachments.
They were taken from the VM container before all the upgrades were made, but
I did not change anything when upgrading.
Ralph.
-----Original Message-----
From: Ian Buckley [mailto:[email protected]]
Sent: Friday, April 17, 2015 19:25
To: Ralph A. Schmid, dk5ras
Cc: 'Martin Braun'; [email protected]; 'GNU Radio Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
Great Ralph, thats a big help. Can you send me your exact flow graph used to
generate these 2 plots off list please. I want to re run this scenario and
see your exact configuration.
Thanks
-Ian
On Apr 17, 2015, at 10:00 AM, "Ralph A. Schmid, dk5ras" <[email protected]>
wrote:
OK, here we go. The hotel TV was dvb-c only, so I had to do the tests
back at home.
I took my perfectly working Kubuntu 14.04 64 bit VM container together
with my B210, made a copy and updated this one, first I made a git
pull to get latest master, built it, rebuilt gnuradio, rebuilt
gr-dvbt, updated the FPGA images, and everything still was fine. The
chosen dvb-t bandwidth is 8 MHz.
Then I changed to 003_008_003_rc1, did the same procedure, fired up
grc, and the signal was not decodable both with a dvb-t PC receiver
and with an dvb-x analyzer. The analyzer saw the RF level, but no
data, no constellation, nothing, it looked to him like interference.
When you have a look at the two "uhd" screenshots here
http://dk5ras.dyndns.org/tmp/DVB/ made with my spectrum analyzer then
you will find that RC1 produces a somehow narrower signal, so it
really looks something gets cut at the ends with all the filtering and DSP
stuff.
Adjusting the channel bandwidth in the uhd sink block from 0 to a
sensible value changes nothing.
Btw., the dvb-t2 package behaves identical.
Ralph.
-----Original Message-----
From: Martin Braun [mailto:[email protected]]
Sent: Wednesday, April 15, 2015 21:14
To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
master works, but RC1 does not? Huh, I'm confused now. Can you give
some detail on what's going on, so we can try and reproduce this?
Thanks,
Martin
On 15.04.2015 12:52, Ralph A. Schmid, dk5ras wrote:
RC1, master seems to work.
Ralph.
-----Original Message-----
From: Martin Braun [mailto:[email protected]]
Sent: Wednesday, April 15, 2015 15:44
To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
Thanks, Ralph. Just to clarify: When you say 'New UHD', do you mean
3.8.3-RC1, or latest master?
Martin
On 15.04.2015 08:40, Ralph A. Schmid, dk5ras wrote:
It is a B210, but as a note, due to the up to now missing FPGA
images I used 003.008.003-RC1, not the latest master. Still I had no
access to a spectrum and DVB-T analyzer, so I have no idea what is
happening, I just can confirm that RF is transmitted, and the
receiver doesn't get a picture, while with the snapshot of the same
VM before the upgrade
is received without problems.
I will know more in about three hours.
Ralph.
-----Original Message-----
From: Martin Braun [mailto:[email protected]]
Sent: Wednesday, April 15, 2015 3:15 PM
To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
On 15.04.2015 06:20, Ralph A. Schmid, dk5ras wrote:
Hi,
Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more
with latest uhd. A quick check during lunch break showed, the
produced output is not decodable any more. I will take a closer
look this evening at home, where I have more and better equipment.
Ralph,
which device is this on?
Thanks,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150418/18dc15d1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150418/18dc15d1/attachment-0001.sig>
------------------------------
Message: 12
Date: Sat, 18 Apr 2015 16:17:46 +0200
From: "Jason A. Donenfeld" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Overrun on 56MHz with B210
Message-ID:
<CAHmME9ou_=A-JYLFZt=yh+yy_6ti4tfh549jgc9dbfcx9cs...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi folks,
I'm running a B210 over USB3. I seem to be getting buffer overruns
when asking for the maximum 56MHz of bandwidth. For example:
zx2c4@thinkpad ~/Desktop/sdr $ osmocom_fft -a
uhd,master_clock_rate=56e6 -s 56e6 -f 420e6 -F
linux; GNU C++ version 4.9.2; Boost_105600; UHD_003.008.002-0-unknown
gr-osmosdr v0.1.4-16-g61184a19 (0.1.5git) gnuradio v3.7.6.1-103-g8ecfd13a
built-in source types: file rtl rtl_tcp uhd
-- Operating over USB 3.
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 56.000000 MHz
-- Actually got clock rate 56.000000 MHz
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- Using subdev spec 'A:A A:B'.
[+] Selected device: Quadro K2000M
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO.....[repeated enormous amounts]
Incidentally, when it's overrunning, I can hear a high pitched
capacitor noise inside of my laptop (Thinkpad W530, Intel i7-3820QM,
C210 chipset), which is a bit funny. Is it possible that the system's
USB controller is simply not up to task? Or is this a configuration
issue I can address?
Thanks,
Jason
------------------------------
Message: 13
Date: Sat, 18 Apr 2015 17:13:10 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Overrun on 56MHz with B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Jason,
yes, in most cases, that is a system bandwidth limitation. Many
controllers just max out; your chipset is usually on the good side[1],
but that doesn't actually mean that much.
Also, I know the noise you're talking about -- it happens to my Laptop,
too, and also on higher rates. I typically hear it when I do something
CPU intensive, though -- my blind guess is that it's a voltage converter
that supplies the CPU with power, and is driven at the edge of its
specs. You're running osmocom_fft in fosphor mode, which means you're
using openCL; I suppose you're using OpenCL as a means to get more out
of your CPU, so that would align with my CPU load assumption.
So, what you can do is first just use the rx_samples_to_file example
that comes with uhd (look into /usr/[local/]/lib[64]/uhd/examples), and
write your samples to /dev/null ; if the overflows go away, you're
CPU-bound, if they persist, you're USB-bound.
Greetings,
Marcus
[1]
http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks
On 04/18/2015 04:17 PM, Jason A. Donenfeld via USRP-users wrote:
> Hi folks,
>
> I'm running a B210 over USB3. I seem to be getting buffer overruns
> when asking for the maximum 56MHz of bandwidth. For example:
>
> zx2c4@thinkpad ~/Desktop/sdr $ osmocom_fft -a
> uhd,master_clock_rate=56e6 -s 56e6 -f 420e6 -F
> linux; GNU C++ version 4.9.2; Boost_105600; UHD_003.008.002-0-unknown
> gr-osmosdr v0.1.4-16-g61184a19 (0.1.5git) gnuradio v3.7.6.1-103-g8ecfd13a
> built-in source types: file rtl rtl_tcp uhd
> -- Operating over USB 3.
> -- Initialize CODEC control...
> -- Initialize Radio control...
> -- Performing register loopback test... pass
> -- Performing register loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Asking for clock rate 56.000000 MHz
> -- Actually got clock rate 56.000000 MHz
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> -- Using subdev spec 'A:A A:B'.
> [+] Selected device: Quadro K2000M
> OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO.....[repeated enormous amounts]
>
> Incidentally, when it's overrunning, I can hear a high pitched
> capacitor noise inside of my laptop (Thinkpad W530, Intel i7-3820QM,
> C210 chipset), which is a bit funny. Is it possible that the system's
> USB controller is simply not up to task? Or is this a configuration
> issue I can address?
>
> Thanks,
> Jason
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
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 56, Issue 18
******************************************
