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: Timed Commands support image - compatibility number 10
(Josh Blum)
2. Re: UHD Tx Issues with Spurious Samples Being Tx'ed (Isaac Gerg)
3. Re: UHD Tx Issues with Spurious Samples Being Tx'ed (Josh Blum)
4. Is there any WCDMA support or development on usrp? (Wang, Waylon)
5. USRP2 tx data and Rx data (sam berhanu)
6. Re: USRP2 tx data and Rx data (Marcus D. Leech)
7. E110 FPGA (Nathan Kohler)
----------------------------------------------------------------------
Message: 1
Date: Tue, 08 May 2012 09:36:00 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Timed Commands support image - compatibility
number 10
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
On 05/08/2012 03:36 AM, Marius wrote:
> Hi!
>
> I'm building an FPGA image for my USRP2s:
>
> ? ~/source/uhd/fpga/usrp2/top/USRP2/ master* git show
> commit 869e5ff110a56c597acff5e493e603eef2bde366
> Merge: 6ca39ad c42c02f
> Author: Josh Blum <[email protected]>
> Date: Wed Apr 25 19:15:21 2012 -0700
>
> Merge branch 'maint'
>
> When I make this I get into failed constraints
>
> Process "Check Syntax" failed
> INFO:TclTasksC:1850 - process run : Check Syntax is done.
> python /home/marius/source/uhd/fpga/usrp2/top/python/check_timing.py
> /home/marius/source/uhd/fpga/usrp2/top/USRP2/build/u2_rev3.twr
>
>
What version of ise? I was using 12.1 for this build and I have known
13.1 to build it as well
>
> Mainly I need the compatibility number 10, but the newest released build has
> 9.
> Could someone build me an FPGA image, that works, or help me fix this issue?
> Some nightly build here or something would do fine. I know it might be
> unstable.
>
This feature has been merged onto the master branch for N200/N210, you
can get images here: http://files.ettus.com/binaries/master_images/
-josh
------------------------------
Message: 2
Date: Tue, 8 May 2012 17:29:13 -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:
<CADnN3yViwgszuXO1BEtBFe3uxFR=jrftpszpldcp0icjnti...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi Josh,
Have you had any more time to look into my problem? Is there
something I can do to help you?
Thanks,
Isaac
On Fri, May 4, 2012 at 9:27 AM, Isaac Gerg <[email protected]> wrote:
> Josh,
>
> The send call from tx_streamer doesnt match the interface in io_impl.
>
> This has 4 arguments,
> http://files.ettus.com/uhd_docs/doxygen/html/stream_8hpp_source.html
>
> This has 6,
> http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/repository/revisions/6c13ef7855dcfe9c825e819f69f219851387da25/entry/host/lib/usrp/usrp1/io_impl.cpp
>
> I am looking for the implementation of send() call with 4 arguments.
>
> Isaac
>
> On Thu, May 3, 2012 at 5:01 PM, Josh Blum <[email protected]> wrote:
>>
>>
>> On 05/03/2012 12:12 PM, Isaac Gerg wrote:
>>> Hi Josh,
>>>
>>> After more analysis with the scope today I noticed that the waveforms
>>> of my bursts seemed to get queued up and when I send say burst 5, I
>>> see burst 3 go out.
>>>
>>> Also, what file has the implementation of the tx_streamer->send()
>>
>>
>> Its all in usrp1/io_impl.cpp
>>
>> You should see that tx_stream_on_off is called with enable false when an
>> end of burst is set, and that flush_send_buff is called.
>>
>>> function? ?With this interface, it looks like the parameter to capture
>>> SEND_MODE_FULL_BUFF went away.
>>>
>>
>> There wasnt really a distinction. If you just wanted to send 1 packet,
>> then you just set the length to be 1 packet and no more. So its always
>> full buffer basically.
>>
>>> Have you had any time to check things out on your end?
>>>
>>
>> I verified that the flush is being called when EOB is set. I havent had
>> time to look any closer.
>>
>> Hope that helps,
>> -Josh
------------------------------
Message: 3
Date: Tue, 08 May 2012 16:04:52 -0700
From: Josh Blum <[email protected]>
To: Isaac Gerg <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] UHD Tx Issues with Spurious Samples Being
Tx'ed
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/08/2012 02:29 PM, Isaac Gerg wrote:
> Hi Josh,
>
> Have you had any more time to look into my problem? Is there
> something I can do to help you?
>
I think you are seeing that the DAC is still modulating the last sample
that it saw.
So, when you EOB, there are zeros flushed out, but it seems that USRP
FPGA transmit state machine is disabled before the zeros are seen in the
FPGA, so the DAC modulates the last known samples, not zero:
Here is a possible fix, dont disable TX state machine:
http://pastebin.com/D9SqYQ6n
Here is another, disable DAC along with TX state machine:
http://pastebin.com/YhVKq6KQ
You could also, from an application standpoint, not set EOB, but rather
send a packet's worth of zeros.
This is all very hairy because USRP1 isnt really capable of bursting.
-josh
------------------------------
Message: 4
Date: Tue, 8 May 2012 23:15:58 +0000
From: "Wang, Waylon" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Is there any WCDMA support or development on
usrp?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Can anyone shed some light on any WCDMA support on the usrp?
Thanks,
Waylon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120508/4a8386b8/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 8 May 2012 20:42:12 -0400
From: sam berhanu <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP2 tx data and Rx data
Message-ID:
<CAEyq4Nf4MB=n+oae5l2_6bvaavwfx7jupo-vr07ht7bd_ko...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I am new with SDR, and the USRP2. I have a USRP2 with Basic daughterboards.
I am doing a simple BPSK and QPSK modulation scheme, where I want the
output of the USPR2 to feed into an RF front end that has half the other
part of a weaver architecture (assumption i am making here is that the
complex mixing in the USRP2 is the 1st stage of the weaver image rejection
stage).
I am completely lost on how the data is organized or on how to correctly
translate the data that is being fed into the USRP2 and that I find from
the USRP2. I am pretty sure I am setting the downsample and upconvert
factors correctly but I think I need help in understanding on how to
translate the values that I see I am receiving from the USRP2 block in
simulink. Two huge issues;
a) i sent a constant signal in simulink, i.e a DC and I guess I was
expecting a constant at the output but the values are up and down (I set
the USPR2 both to double and int16) which should i set it for correct
translation
b) fundamentally the quesiton i have pertains to : does the UHD convert the
data samples correctly back and forth between the hadware and the software
environment or do i need to do that translation myself? i.e do I need to
write more code/circuitry in simulink for scaling, bit rearranging
(apparently the USRP2 writes and reads big endian while the software
environment is in small endian) etc.
in simple terms, i am new and need lots of help with getting to understand
how the data conversion is happening or if I need to also write additional
C++ drivers in simulink?
thanks
sam berhanu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120508/58b3ec2c/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 08 May 2012 23:46:57 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP2 tx data and Rx data
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 05/08/2012 08:42 PM, sam berhanu wrote:
> I am new with SDR, and the USRP2. I have a USRP2 with Basic
> daughterboards. I am doing a simple BPSK and QPSK modulation scheme,
> where I want the output of the USPR2 to feed into an RF front end that
> has half the other part of a weaver architecture (assumption i am
> making here is that the complex mixing in the USRP2 is the 1st stage
> of the weaver image rejection stage).
>
> I am completely lost on how the data is organized or on how to
> correctly translate the data that is being fed into the USRP2 and that
> I find from the USRP2. I am pretty sure I am setting the downsample
> and upconvert factors correctly but I think I need help in
> understanding on how to translate the values that I see I am receiving
> from the USRP2 block in simulink. Two huge issues;
>
So the USRP family tends to deal in terms of complex-baseband signals
into/out-of the device. The analog RF hardware up-converts those
complex-baseband signals to their final RF center frequency on TX,
and does the converse on RX--takes the RF signals, and downconverts
them to complex-baseband.
> a) i sent a constant signal in simulink, i.e a DC and I guess I was
> expecting a constant at the output but the values are up and down (I
> set the USPR2 both to double and int16) which should i set it for
> correct translation
A couple of different issues here--by default, there's DC-offset removal
enabled in the FPGA, and the BASIC_TX board will not pass DC--it
has a lower-end cutoff around 1MHz or so, same for the BASIC_RX board.
> b) fundamentally the quesiton i have pertains to : does the UHD
> convert the data samples correctly back and forth between the hadware
> and the software environment or do i need to do that translation
> myself? i.e do I need to write more code/circuitry in simulink for
> scaling, bit rearranging (apparently the USRP2 writes and reads big
> endian while the software environment is in small endian) etc.
>
> in simple terms, i am new and need lots of help with getting to
> understand how the data conversion is happening or if I need to also
> write additional C++ drivers in simulink?
>
>
I can't comment specifically about SimuLink, since I've never used it.
But the UHD driver architecture converts between host-side
signal representation (which in Gnu Radio, by default, is
complex-floats scaled to {-1.0, +1.0}) to hardware-appropriate values
for whatever hardware you're using.
The FPGA does complex rate conversion (decimation and interpolation) as
well as complex DUC/DDC functions as appropriate.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 7
Date: Wed, 9 May 2012 10:40:39 -0400
From: Nathan Kohler <[email protected]>
To: [email protected]
Subject: [USRP-users] E110 FPGA
Message-ID:
<CABp8TYSymUMtWKfRq1ij71_D5y7QA0gS8aPf25GZnPSHk=k...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hello -
I am creating a custom transmit chain in the E110 FPGA. I need to
generate a faster clock rate for some filtering I am doing, and am
trying to insert a DCM_SP module. I saw that in version 003_002_004
you had a DCM module called clk_doubler in u1e.v, however this was
removed in version 003_003_000. It looks like all this module did was
pass the 64MHz clock through the DCM and into the u1e_core, which is
probably why you removed it since you werent using it for doubling the
clock anymore.
When I try to simply add this module back in (I just want to pass the
64MHz clock through the DCM to the u1e_core for now until I get that
working before I try to generate faster clocks) I now receive the
following error when I try to run any of the example code after the
wishbone readback test fails:
------------------------------------------------------------------------
"The FPGA is either clocked improperly\n"
"or the FPGA build is not compatible.\n"
"Subsequent errors may follow...\n"
-----------------------------------------------------------------------
Is there something else I need to do to get the DCM working? It
synthesizes and maps without any errors or warnings, and the schematic
looks to be what I would expect. Was there another change (in either
the host or fpga code) going from 003_002_004 to 003_003_000 that
would prevent the DCM from working?
Also, why were you using a DCM and not a DCM_SP for the E110 in 003_002_004?
Thanks!
------------------------------
_______________________________________________
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 9
*****************************************
