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: X310 FPGA : Lowering bus_clk ? (Matt Ettus)
2. Re: X310 FPGA : Lowering bus_clk ? (Sylvain Munaut)
3. Re: Full-duplex MIMO issues with B210 board (Rob Kossler)
4. Intermediate Frequency with SBX,WBX... (LEMENAGER Claude)
5. Re: Intermediate Frequency with SBX,WBX... ([email protected])
6. could not find image downloader (nur qalbi)
7. Need help with B100 (Ryan Cadiz)
----------------------------------------------------------------------
Message: 1
Date: Sun, 22 Mar 2015 13:36:29 -0700
From: Matt Ettus <[email protected]>
To: Sylvain Munaut <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 FPGA : Lowering bus_clk ?
Message-ID:
<CAN=1kn8xTaeco2WCZkjk9B6TM=sjpsvpgheapktoqyaywsi...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
bus_clk needs to be at least 156.25 MHz to keep up with 10GE. The ZPU
doesn't need to be that fast, but it would take some work to get it off of
bus_clk.
One thing to keep in mind, though, is that the problem is not necessarily
in bus_clk. If you put in some logic elsewhere which has a lot of trouble
meeting timing, the tool works very hard on that clock domain, and you can
see timing errors show up in unrelated clock domains. So optimizing your
logic might help.
Matt
On Sun, Mar 22, 2015 at 3:56 AM, Sylvain Munaut via USRP-users <
[email protected]> wrote:
> Hi,
>
>
> Is there any fundamental reason why the bus_clk needs to be 166 MHz ?
>
>
> The reason I ask is that half my builds are failing timing and at 3h
> per build, this is getting old very quickly.
>
> The failing path are pretty much always the same : mostly inside the
> ZPU and starting with the ZPU BRAM output (which eats 1.8 ns of
> clk-to-out by itself).
> And when it fails, it fails by up to 0.6 ns, so that's not something I
> can just ignore and hope it works anyway.
>
> So I'd like to lower bus_clk to 150MHz, putting the constraint to
> 6.6ns instead of 6ns which should help it quite a bit.
>
>
> Cheers,
>
> Sylvain
>
> _______________________________________________
> 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/20150322/a4512065/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 22 Mar 2015 23:18:24 +0100
From: Sylvain Munaut <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 FPGA : Lowering bus_clk ?
Message-ID:
<cahl+j0-emuqo8+pteyjnohaerevfdynehg7quwdg4h2qc8j...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Matt,
> bus_clk needs to be at least 156.25 MHz to keep up with 10GE. The ZPU
> doesn't need to be that fast, but it would take some work to get it off of
> bus_clk.
Ok, so lowering it in general wouldn't be good.
But since I don't use 10GE, I could still modify it locally to 150M
just to speed up my test builds and this should work ?
Then when things are finalized, I can move it back to 166M and if it
takes a couple of run to produce a production bitstream, that's not
too much of an issue.
> One thing to keep in mind, though, is that the problem is not necessarily in
> bus_clk. If you put in some logic elsewhere which has a lot of trouble
> meeting timing, the tool works very hard on that clock domain, and you can
> see timing errors show up in unrelated clock domains. So optimizing your
> logic might help.
Yes I know, but I'm fairly confident that particular path is the
problem. Out of 10 failed timing build this weekend (some not even
including my custom logic but just a full set of standard NoC blocks),
this path (starting from zpu bram and ending somewhere with zpu stack)
has been present in all the failures, and it's always very long (9-10
levels of logic including a BRAM out).
Some time others will also show up, like the radio_clk_2x db phase
thing that's running at 400 MHz, but those only show up randomly and
are probably just because it tried meeting the bus_clk so hard.
Cheers,
Sylvain
------------------------------
Message: 3
Date: Mon, 23 Mar 2015 10:14:22 -0400
From: Rob Kossler <[email protected]>
To: Tom Tsou <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Full-duplex MIMO issues with B210 board
Message-ID:
<CAB__hTQxqiqUakVkgfZ+sYf-6oR4g5fJkAx=zkibp8zborr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Thu, Mar 19, 2015 at 4:29 PM, Tom Tsou via USRP-users <
[email protected]> wrote:
> On Thu, Mar 19, 2015 at 1:52 AM, Ian Buckley via USRP-users
> <[email protected]> wrote:
> > Marcus,
> > You've been given bad information by R&D?RX and TX H/W paths are
> orthogonal?2x2 MIMO@ 30.72MHz is a legal configuration. (It is however
> the maximum legal sample rate for this configuration)
>
> Confirming the following B210 items:
>
> * 2x2 MIMO at 30.72 MHz is a valid configuration.
> * Full-duplex or Rx/Tx only does not restrict the clock rate setting.
> * Operation with 2x2 MIMO at 30.72 MHz may generate bit-level errors.
>
> Ettus R&D has reproduced and diagnosed the clocking issue and a fix is
> in progress. In the meantime with 2x2 MIMO, master clock rates that
> approach the maximum allowable value of 30.72 MHz should be avoided.
> Single channel operation is not affected.
>
> For 2x2 LTE purposes, clocking at 7.68 or 15.36 MHz provides coverage
> up to 15 MHz channels. 20 MHz LTE can be covered with 23.04 MHz clock
> and sample rates.
>
> -TT
>
>
Regarding 2x2 at 30.72 MHz, I understand the discussion above, but I'm
wondering how is this even possible over USB 3? The chart Ettus provides
regarding 2x2 sample rates achievable using various USB 3 controllers shows
19 MS/s as the max rate in 2x2 config. I suppose 8-bit OTW would work
fine, but even 12-bit OTW should only bump it up to about 25 MS/s or so.
Is this correct?
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150323/a93fa040/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 23 Mar 2015 16:22:14 +0100
From: LEMENAGER Claude <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Intermediate Frequency with SBX,WBX...
Message-ID:
<59957d668d245c4eb38e8f85c054e901077bc05...@thsonea01cms09p.one.grp>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I just have a question about the setting of Intermediate Frequency programming
for daughter board with quadrature frontend.
In certain circumstances, we want to avoid IQ impairment and then acquire the
signal using IF techniques which should be possible through UHD.
To program that, we have to put the correct RF and offset frequencies
(tune_request_t) but also, in my opinion, the input of the dsp through
set_subdev.
But the only subdev spec allowed for the SBX in X3x0 are A:0 or B:0, i.e. if I
understand correctly, a quadrature interface (using two ADC in the RX case).
So the question is how to acquire in IF for these boards?
Claude Lem?nager
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150323/45759059/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 23 Mar 2015 11:29:02 -0400
From: [email protected]
To: LEMENAGER Claude <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Intermediate Frequency with SBX,WBX...
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
It's handled automatically. You specify the same front-end, and in your
tune request, use an offset.
The data are *always* delivered in complex-baseband format, even if you
are using offset tuning.
On 2015-03-23 11:22, LEMENAGER Claude via USRP-users wrote:
> Hello,
>
> I just have a question about the setting of Intermediate Frequency
> programming for daughter board with quadrature frontend.
>
> In certain circumstances, we want to avoid IQ impairment and then acquire the
> signal using IF techniques which should be possible through UHD.
>
> To program that, we have to put the correct RF and offset frequencies
> (tune_request_t) but also, in my opinion, the input of the dsp through
> set_subdev.
>
> But the only subdev spec allowed for the SBX in X3x0 are A:0 or B:0, i.e. if
> I understand correctly, a quadrature interface (using two ADC in the RX
> case).
>
> So the question is how to acquire in IF for these boards?
>
> Claude Lem?nager
>
> _______________________________________________
> 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/20150323/e1351f46/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 23 Mar 2015 11:45:38 +0800
From: nur qalbi <[email protected]>
To: [email protected]
Subject: [USRP-users] could not find image downloader
Message-ID:
<CAK1g3CF-_FkiBQxVMAQF3ktjarr5GO3q+eiyQ=ryq+krb0k...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
hi. i am use ubuntu 14.04.as i am installing gnuradio from this link:
http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource
and choose build from source.
Gnuradio &uhd
What can i do?i hope you can help me.
thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150323/052d44b1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2015-03-20 16:06:24.png
Type: image/png
Size: 779741 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150323/052d44b1/attachment-0001.png>
------------------------------
Message: 7
Date: Mon, 23 Mar 2015 13:07:46 +0800
From: Ryan Cadiz <[email protected]>
To: [email protected]
Subject: [USRP-users] Need help with B100
Message-ID:
<CAPMVvZ0vhs1XusJ9O8jRYTJfM2k2P=boNHsjUw=9p_mpcig...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
A colleague left me with a B100 and the laptop setup. The previous
programmer left without any kind of documentation.
Anyone willing to help setup the machine for sms blasting? Let me know how
much it would cost me and the features you can implement.
Please contact me at [email protected]
Best Regards,
Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150323/1195b075/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 55, Issue 22
******************************************
