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: WBX Modification, (Matt Ettus)
   2. Re: USRP N210 Timing Constraints not met (Josh Blum)
   3. Re: what is the largest data transfer rate between fpga and
      overo in e100 (Ben Hilburn)
   4. Re: USRP N210 Timing Constraints not met (Yasir Javed)
   5. Re: UHD Tx Issues with Spurious Samples Being Tx'ed (Isaac Gerg)


----------------------------------------------------------------------

Message: 1
Date: Wed, 23 May 2012 09:13:01 -0700
From: Matt Ettus <[email protected]>
To: Furkan Elibol <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] WBX Modification,
Message-ID:
        <CAN=1kn_NFmHiUDqa4Ldb7SPxJqc8Y3=aTa7bNJut--oaZS=a...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

The 4351 will work on there, and we will have code that takes advantage of
it released soon.  However, the mixers may have trouble going below 50 MHz.
 You'll have to see how well it works.

Matt

On Wed, May 23, 2012 at 5:35 AM, Furkan Elibol <[email protected]> wrote:

> Hi all,
>
> I just want to replace ADF4350 of the wbx daughterboard with a pin and
> software compatible ADF4351.
> I wonder will I need any other modification at hardware or uhd or fpga
> image? Because I want to continue to use wbx
> with same uhd, fpga image and software. I just need to receive low
> frequencies like 30MHz or 25MHz with wbx db which is not supported from
> ADF4350.
>
> Thanks a lot.
>
> Furkan
>
> _______________________________________________
> 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/20120523/01e21df7/attachment-0001.html>

------------------------------

Message: 2
Date: Wed, 23 May 2012 09:22:34 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP N210 Timing Constraints not met
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1



On 05/23/2012 06:10 AM, Yasir Javed wrote:
> I have synthesized N210's FPGA logic. I am getting timing errors.
> 
> ----------------------------------------------------------------------------------------------------------
>   Constraint                                |    Check    | Worst Case |
>  Best Case | Timing |   Timing
>                                             |             |    Slack   |
> Achievable | Errors |    Score
> ----------------------------------------------------------------------------------------------------------
> * TS_dcm_out = PERIOD TIMEGRP "dcm_out" TS_ | SETUP       |    -0.855ns|
>  10.855ns|       5|        1146
>   clk_fpga_p HIGH 50%                       | HOLD        |     0.442ns|
>          |       0|           0
> 
> 
> I am using Xilinx ISE 13.4. I am using GNU radio version 3.6.0 on Ubuntu
> 10.10. I have also tried synthesis on 13.1 on windows XP as well with
> similar results. What could I be missing here
> 

Did you build the ISE project file with the Makefile.N210_R4? If not,
there are important synthesis, translate, and map properties you may be
missing in the project file.

FWIW I have been building FPGA images for release with 12.1, and I have
noticed that that 13 had issues meeting timing on the smaller FPGAs
where 12 did not. I would not expect this to be an issue on N210 though.

-Josh



------------------------------

Message: 3
Date: Wed, 23 May 2012 14:06:04 -0700
From: Ben Hilburn <[email protected]>
To: Page Jack <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] what is the largest data transfer rate
        between fpga and overo in e100
Message-ID:
        <caoevzk+79_k+tafl6d2uyblb8tdks70ywku9c4i_vvw6y_f...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Page -

The memory bus to the ARM provides 40 MBytes / second.  This is used for
streaming samples, as controlled via software.  Currently, UHD supports 16
bit and 8 bit samples for TX & RX.  The GPMC can only going to talk to one
slave at a time; the possible slaves are TX, RX, and ethernet.  So you can
only be sending TX samples, receiving RX samples, or communicating via
ethernet.

Thus, doing the math with the numbers above, you can stream:
16 bit I, 16 bit Q -- Total: 32-bit samples -- @ 10 MSps
8 bit I, 8 bit Q -- Total: 16-bit samples -- @ 20 MSps

What you choose to do with this data is obviously up to you. It is very
easy to try to do more processing than the ARM can handle, in which case
samples will start getting thrown out by UHD.  Thus, you can typically
process between 4 and 8 MHz of baseband bandwidth, depending on your
application.  If you are willing to dig deep into the code to make NEON and
C64 optimizations, you can improve the performance dramatically.

Cheers,
Ben
----------------------------
Ben Hilburn <http://goo.gl/5DdZ3> @ Ettus Research, LLC<http://www.ettus.com/>



On Tue, May 22, 2012 at 7:47 PM, Page Jack <[email protected]> wrote:

> Hi,
> I want to know the overo model used in e100 and the largest data transfer
> rate between fpga  and overo in e100.
>
> Regards!
>
> _______________________________________________
> 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/20120523/4cfb3a9b/attachment-0001.html>

------------------------------

Message: 4
Date: Thu, 24 May 2012 14:38:38 +0500
From: Yasir Javed <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP N210 Timing Constraints not met
Message-ID:
        <cajfaspzajcr9mkjamavfylecuatljs5g+ua_f8g1zqj8pmw...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Thanks. I have installed 12.1 today and now all timing constraints are met.


> Did you build the ISE project file with the Makefile.N210_R4? If not,
there are important synthesis, translate, and map properties you may be
missing in the project file.

FWIW I have been building FPGA images for release with 12.1, and I have
noticed that that 13 had issues meeting timing on the smaller FPGAs
where 12 did not. I would not expect this to be an issue on N210 though.

-Josh




On Wed, May 23, 2012 at 6:10 PM, Yasir Javed <[email protected]> wrote:

>
> I have synthesized N210's FPGA logic. I am getting timing errors.
>
>
> ----------------------------------------------------------------------------------------------------------
>   Constraint                                |    Check    | Worst Case |
>  Best Case | Timing |   Timing
>                                             |             |    Slack   |
> Achievable | Errors |    Score
>
> ----------------------------------------------------------------------------------------------------------
> * TS_dcm_out = PERIOD TIMEGRP "dcm_out" TS_ | SETUP       |    -0.855ns|
>  10.855ns|       5|        1146
>   clk_fpga_p HIGH 50%                       | HOLD        |     0.442ns|
>          |       0|           0
>
>
> I am using Xilinx ISE 13.4. I am using GNU radio version 3.6.0 on Ubuntu
> 10.10. I have also tried synthesis on 13.1 on windows XP as well with
> similar results. What could I be missing here
>
> Regards,
> Yasir Javed
> Assistant Professor
> IQRA University Islamabad
>
>
>
>


-- 
Regards,
Yasir Javed
www.renzym.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120524/b06d9f5b/attachment-0001.html>

------------------------------

Message: 5
Date: Thu, 24 May 2012 10:46:53 -0400
From: Isaac Gerg <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] UHD Tx Issues with Spurious Samples Being
        Tx'ed
Message-ID:
        <cadnn3yxpq5+nugzjsi7es-5z-ez9tmt344qvrnzjyx1zbmk...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

I'm going to put off rebuilding the UHD for now in lieu of trying to get
any kind of signal out of the radio correctly, then scaling it back for my
application.

I have lengthened my burst to ~0.2s by padding it with 0.1s of zeros to the
front and back of the signal. At fs = 250e3, I send 50680 samples over the
air .  When I call send with that buffer, I get the following UHD error:

UHD Error:
    The vandal caught an unexpected exception AssertionError:
usrp_control_write
_cmd(VRQ_FPGA_SET_TX_ENABLE, on, 0) >= 0
      in void __cdecl fx2_ctrl_impl::usrp_tx_enable(bool)
      at
C:\cygdrive\c\remote_fs_root\workspace\u08_win7\s\Win7_x64\stable\uhd_x
64\host\lib\usrp\common\fx2_ctrl.cpp:353


What am I doing wrong?

Isaac


On Fri, May 18, 2012 at 5:25 PM, Josh Blum <[email protected]> wrote:

>
>
> On 05/17/2012 12:33 PM, Isaac Gerg wrote:
> > Hi Josh,
> >
> > I tried your suggestion about flushing with zeros and not setting the
> > EOB.  It doesn't help.  I can't do the other suggestions because I
> > cant get the thing to build correctly in windows.
> >
>
> Any error in particularthat I could help you with?
>
> > I'm send bursts every 2 seconds that start at 1ms in length and
> > increase every time buy 1 ms.  So 4 bursts later, my burst is 4ms in
> > length.  What I am seeing is that I get nothing until burst 6/7.  What
> > comes out is a  burst that is 4ms long.  It like the samples are
> > getting jammed up in a buffer somewhere.
> >
> > What's an optimal signal length to send out of the USRP1?  Id be happy
> > to pad my signal with noise so that it can go out over the air
> > correctly.  There's has to be a signal I can send out that the USRP
> > will function correctly with.
> >
>
> It might be most handy to use the streamer->get_max_num_samps().
> Basically, whenever you call send, all samples up to a multiple of 512
> bytes are committed over USB. So if you dont have any remainder, then
> there arent any samples to hang around in uncommitted buffers.
>
> The submissions are around max 4000 samples, so that may or may not
> describe what you are seeing, depends on how low your sample rate may
> be, and how many samples per call to send().
>
> -josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120524/af17aa54/attachment-0001.html>

------------------------------

_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


End of USRP-users Digest, Vol 21, Issue 23
******************************************

Reply via email to