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: E110 FPGA (Ian Buckley)
2. Re: USRP2 tx data and Rx data (Mike McLernon)
3. Re: E110 FPGA (Ian Buckley)
4. Re: FPGA reprogramming and real-time (Steve Peters)
5. Re: FPGA reprogramming and real-time (Ian Buckley)
6. Re: FPGA reprogramming and real-time (Steve Peters)
7. Re: UHD Tx Issues with Spurious Samples Being Tx'ed (Isaac Gerg)
8. Re: FPGA reprogramming and real-time (Steve Peters)
9. Re: UHD Tx Issues with Spurious Samples Being Tx'ed (Josh Blum)
10. SSC Spectrum Sensing Toolbox at CTIA (Matt Ettus)
11. Determining the IF in different configs (Farrukh Aziz)
12. Re: Determining the IF in different configs (John Malsbury)
13. Re: Determining the IF in different configs (Marcus D. Leech)
14. USRP B100 Sensitivity Issue (Aaron Eaton)
15. Amplification Equipment? (Count Zero)
16. Shifting on USRPN200 FPGA processing.. (salman dinani)
17. Re: Shifting on USRPN200 FPGA processing.. (John Malsbury)
18. Re: SSC Spectrum Sensing Toolbox at CTIA (Andre Puschmann)
19. Re: Shifting on USRPN200 FPGA processing.. (salman dinani)
20. Re: Shifting on USRPN200 FPGA processing.. (John Malsbury)
----------------------------------------------------------------------
Message: 1
Date: Wed, 9 May 2012 09:17:18 -0700
From: Ian Buckley <[email protected]>
To: Nathan Kohler <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] E110 FPGA
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Nathan,
I don't have an answer for why this change was done, but I can perhaps give you
a method to proceed that works with the newer rev code.
To add a DCM to a version 003_003_000 or later database and retain the same
timing of signals on the FPGA pins from
an external perspective try the following (Code I wrote directly into
email..expect typos):
1) Change the input clock buffer as follows:
wire clk_fpga_in;
IBUFGDS #(.IOSTANDARD("LVDS_33"), .DIFF_TERM("TRUE"))
clk_fpga_pin (.O(clk_fpga_in),.I(CLK_FPGA_P),.IB(CLK_FPGA_N));
2) Add a DCM in SOURCE_SYNCHRONOUS mode, wired so that the feedback does not
included the clock tree, thus giving the same timing on clk_fpga as if it
didn't exist.
wire clk_fpga_unbuf, clk_2x_unbuf, clk_3x_unbuf;
DCM #(
.CLKDV_DIVIDE(2.0),
.CLKFX_DIVIDE(4),
.CLKFX_MULTIPLY(12),
.CLKIN_DIVIDE_BY_2("FALSE"),
.CLKIN_PERIOD(15.62),
.CLK_FEEDBACK("1X"),
.DESKEW_ADJUST("SYSTEM_SYNCHRONOUS"),
.DFS_FREQUENCY_MODE("LOW"),
.DLL_FREQUENCY_MODE("LOW"),
.DUTY_CYCLE_CORRECTION("TRUE"),
.PHASE_SHIFT(0),
.STARTUP_WAIT("FALSE")
)
DCM_inst1 (
.DSSEN(1'b0),
.CLK0(clk_fpga_unbuf),
.CLK2X(clk_2x_unbuf),
.CLKFX(clk_3x_unbuf),
.CLKFB(clk_2x_unbuf),
.CLKIN(clk_fpga_in),
.PSCLK(1'b0),
.PSEN(1'b0),
.PSINCDEC(1'b0),
.RST(1'b0) // Get an SRL16 power-on-reset onto this signal for a
robust design. See UG331
);
BUFG bufg_clk_fpga(.O(clk_fpga),.I(clk_fpga_unbuf));
3)
Add new clock buffers for your higher speed clocks (I provided a 2x and 3x
clock in this example)
wire clk_2x, clk_3x;
BUFG bufg_clk2x(.O(clk2x),.I(clk_2x_unbuf));
BUFG bufg_clk3x(.O(clk3x),.I(clk_3x_unbuf));
NOTE: The 2x clock will be edge aligned with clk_fpga because of the use of the
CLK2X output on the DCM, but the 3X clock, or whatever is generated from the
CLKFX should be treated as an unknown phase relationship to clk_fpga.
The differences between DCM and DCM_SP are explained in UG331, page 67. Using
DCM still works in a Spartan3A but some features aren't supported. Use of DCM
rather than DCM_SP however makes the work portable to USRP2. Use the DCM wizard
in coregen to generate examples for different frequencies, and take the values
in the examples generated and plug them into DCM parameters in your RTL code.
Hope this gets you going again,
-Ian
On May 9, 2012, at 7:40 AM, Nathan Kohler wrote:
> 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
------------------------------
Message: 2
Date: Wed, 9 May 2012 16:17:53 +0000
From: Mike McLernon <[email protected]>
To: sam berhanu <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP2 tx data and Rx data
Message-ID:
<e3879be9a282cb45aab7ce258a9ae48f05cb1...@exmb-01-ah.ad.mathworks.com>
Content-Type: text/plain; charset="us-ascii"
You shouldn't have to write any additional C++ drivers for Simulink. The
Simulink SDRu Receiver block outputs singles and doubles whose range is scaled
to +/-1, and complex int16s with full range.
Marcus already answered the question about passing a DC signal with the Basic
Rx daughter board. Try 10 MHz and see if you get better results.
Best,
Mike
From: [email protected]
[mailto:[email protected]] On Behalf Of sam berhanu
Sent: Tuesday, May 08, 2012 8:42 PM
To: [email protected]
Subject: [USRP-users] USRP2 tx data and Rx data
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/20120509/d510eb7e/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 9 May 2012 10:22:17 -0700
From: Ian Buckley <[email protected]>
To: Nathan Kohler <[email protected]>,
[email protected]
Subject: Re: [USRP-users] E110 FPGA
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Nathan,
Sorry the hazards of typing quickly whilst drinking the first cup of tea of the
day are well known :-)
Your points are all completely correct, you could use the 2x clock as feedback,
but that wasn't my intent with this example, I was aiming to show how a DCM
could be added in series with the clock with no change to the timing of the
existing clock.
Corrections inline below for the benefit of all.
-Ian
On May 9, 2012, at 10:06 AM, Nathan Kohler wrote:
> Thanks. A couple questions:
>
> 1) You have SOURCE_SYNCHRONOUS in your comment and SYSTEM_SYNCHRONOUS in
> your code. I assume I should use SOURCE_SYNCHRONOUS?
> 2) You are using the CLK2X as the feedback. Do I need to change the
> CLK_FEEDBACK attribute to 2X instead of 1X?
>
> Thanks,
>
> Nate
> On Wed, May 9, 2012 at 12:17 PM, Ian Buckley <[email protected]> wrote:
> Nathan,
> I don't have an answer for why this change was done, but I can perhaps give
> you a method to proceed that works with the newer rev code.
> To add a DCM to a version 003_003_000 or later database and retain the same
> timing of signals on the FPGA pins from
> an external perspective try the following (Code I wrote directly into
> email..expect typos):
>
> 1) Change the input clock buffer as follows:
> wire clk_fpga_in;
> IBUFGDS #(.IOSTANDARD("LVDS_33"), .DIFF_TERM("TRUE"))
> clk_fpga_pin (.O(clk_fpga_in),.I(CLK_FPGA_P),.IB(CLK_FPGA_N));
>
> 2) Add a DCM in SOURCE_SYNCHRONOUS mode, wired so that the feedback does not
> included the clock tree, thus giving theSYSTEM
> same timing on clk_fpga as if it didn't exist.
>
> wire clk_fpga_unbuf, clk_2x_unbuf, clk_3x_unbuf;
>
> DCM #(
> .CLKDV_DIVIDE(2.0),
> .CLKFX_DIVIDE(4),
> .CLKFX_MULTIPLY(12),
> .CLKIN_DIVIDE_BY_2("FALSE"),
> .CLKIN_PERIOD(15.62),
> .CLK_FEEDBACK("1X"),
> .DESKEW_ADJUST("SYSTEM_SYNCHRONOUS"),
> .DFS_FREQUENCY_MODE("LOW"),
> .DLL_FREQUENCY_MODE("LOW"),
> .DUTY_CYCLE_CORRECTION("TRUE"),
> .PHASE_SHIFT(0),
> .STARTUP_WAIT("FALSE")
> )
> DCM_inst1 (
> .DSSEN(1'b0),
> .CLK0(clk_fpga_unbuf),
> .CLK2X(clk_2x_unbuf),
> .CLKFX(clk_3x_unbuf),
> .CLKFB(clk_fpga_unbuf),
> .CLKIN(clk_fpga_in),
> .PSCLK(1'b0),
> .PSEN(1'b0),
> .PSINCDEC(1'b0),
> .RST(1'b0) // Get an SRL16 power-on-reset onto this signal for
> a robust design. See UG331
> );
>
> BUFG bufg_clk_fpga(.O(clk_fpga),.I(clk_fpga_unbuf));
>
> 3)
> Add new clock buffers for your higher speed clocks (I provided a 2x and 3x
> clock in this example)
>
> wire clk_2x, clk_3x;
> BUFG bufg_clk2x(.O(clk2x),.I(clk_2x_unbuf));
> BUFG bufg_clk3x(.O(clk3x),.I(clk_3x_unbuf));
>
> NOTE: The 2x clock will be edge aligned with clk_fpga because of the use of
> the CLK2X output on the DCM, but the 3X clock, or whatever is generated from
> the CLKFX should be treated as an unknown phase relationship to clk_fpga.
>
> The differences between DCM and DCM_SP are explained in UG331, page 67. Using
> DCM still works in a Spartan3A but some features aren't supported. Use of DCM
> rather than DCM_SP however makes the work portable to USRP2. Use the DCM
> wizard in coregen to generate examples for different frequencies, and take
> the values in the examples generated and plug them into DCM parameters in
> your RTL code.
>
> Hope this gets you going again,
> -Ian
>
>
>
> On May 9, 2012, at 7:40 AM, Nathan Kohler wrote:
>
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120509/d6db900b/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 9 May 2012 14:19:56 -0500
From: Steve Peters <[email protected]>
To: Jeff Scaparra <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] FPGA reprogramming and real-time
Message-ID:
<cangtpkg3f9ckxqjtlnhqf57rw239gicrnck59b9ptpww2to...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Jeff,
I'm getting this same error. Did you ever obtain a solution?
Thanks,
Steve
On Mon, Oct 10, 2011 at 12:55 PM, Jeff Scaparra <[email protected]> wrote:
> I am in the same situation and I am looking at the FPGA. I have tried
> compiling the FPGA designs from the uhd git clone that I did today, however
> I am getting an error.
>
> Process "Map" failed
> INFO:TclTasksC:1850 - process run : Generate Programming File is done.
> touch /home/scap/Radio/uhd/fpga/usrp2/top/N2x0/build-N200R3/u2plus.bin
> python /home/scap/Radio/uhd/fpga/usrp2/top/python/check_timing.py
> /home/scap/Radio/uhd/fpga/usrp2/top/N2x0/build-N200R3/u2plus.twr
> Traceback (most recent call last):
> File "/home/scap/Radio/uhd/fpga/usrp2/top/python/check_timing.py", line
> 33, in <module>
> if __name__=='__main__': map(print_timing_constraint_summary,
> sys.argv[1:])
> File "/home/scap/Radio/uhd/fpga/usrp2/top/python/check_timing.py", line
> 25, in print_timing_constraint_summary
> for line in open(twr_file).readlines():
> IOError: [Errno 2] No such file or directory:
> '/home/scap/Radio/uhd/fpga/usrp2/top/N2x0/build-N200R3/u2plus.twr'
> make[1]: *** [bin] Error 1
> make[1]: Leaving directory `/home/scap/Radio/uhd/fpga/usrp2/top/N2x0'
> make: *** [N200R3] Error 2
>
> Does anyone know how I can get more information for diagnostics. I have
> installed a evaluation version of ISE 13.2 and am just running make on the
> fpga/usrp2/top directory.
>
> Any help would be appreciated. Also I think there will be a lot of
> interest in FPGA development as I have found that it will be needed for
> anything larger than 10MS/S on my computer. Perhaps we should start a wiki
> page and those of us working on this could start putting something
> together.
>
> - Scap
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120509/1d760f04/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 9 May 2012 12:51:22 -0700
From: Ian Buckley <[email protected]>
To: Steve Peters <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] FPGA reprogramming and real-time
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Which flavor of USRP are you building for and using which ISE version pls?
On May 9, 2012, at 12:19 PM, Steve Peters wrote:
> Jeff,
>
> I'm getting this same error. Did you ever obtain a solution?
>
> Thanks,
> Steve
>
> On Mon, Oct 10, 2011 at 12:55 PM, Jeff Scaparra <[email protected]> wrote:
> I am in the same situation and I am looking at the FPGA. I have tried
> compiling the FPGA designs from the uhd git clone that I did today, however I
> am getting an error.
>
> Process "Map" failed
> INFO:TclTasksC:1850 - process run : Generate Programming File is done.
> touch /home/scap/Radio/uhd/fpga/usrp2/top/N2x0/build-N200R3/u2plus.bin
> python /home/scap/Radio/uhd/fpga/usrp2/top/python/check_timing.py
> /home/scap/Radio/uhd/fpga/usrp2/top/N2x0/build-N200R3/u2plus.twr
> Traceback (most recent call last):
> File "/home/scap/Radio/uhd/fpga/usrp2/top/python/check_timing.py", line 33,
> in <module>
> if __name__=='__main__': map(print_timing_constraint_summary,
> sys.argv[1:])
> File "/home/scap/Radio/uhd/fpga/usrp2/top/python/check_timing.py", line 25,
> in print_timing_constraint_summary
> for line in open(twr_file).readlines():
> IOError: [Errno 2] No such file or directory:
> '/home/scap/Radio/uhd/fpga/usrp2/top/N2x0/build-N200R3/u2plus.twr'
> make[1]: *** [bin] Error 1
> make[1]: Leaving directory `/home/scap/Radio/uhd/fpga/usrp2/top/N2x0'
> make: *** [N200R3] Error 2
>
> Does anyone know how I can get more information for diagnostics. I have
> installed a evaluation version of ISE 13.2 and am just running make on the
> fpga/usrp2/top directory.
>
> Any help would be appreciated. Also I think there will be a lot of interest
> in FPGA development as I have found that it will be needed for anything
> larger than 10MS/S on my computer. Perhaps we should start a wiki page and
> those of us working on this could start putting something together.
>
> - Scap
>
> _______________________________________________
> 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/20120509/cf1e9f29/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 9 May 2012 15:24:11 -0500
From: Steve Peters <[email protected]>
To: Ian Buckley <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] FPGA reprogramming and real-time
Message-ID:
<cangtpkgyw9ojbifludm7d7yv0jzym-dyx-f1060vkyciy3y...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
N210 rev3 and rev4 (have both, tried both, got the same error for both).
ISE 14.1, just came out yesterday I believe. Maybe upgrading was a
mistake. I've gotten it to work before with 13.2 on a completely different
setup.
On Wed, May 9, 2012 at 2:51 PM, Ian Buckley <[email protected]> wrote:
> Which flavor of USRP are you building for and using which ISE version pls?
>
> On May 9, 2012, at 12:19 PM, Steve Peters wrote:
>
> Jeff,
>
> I'm getting this same error. Did you ever obtain a solution?
>
> Thanks,
> Steve
>
> On Mon, Oct 10, 2011 at 12:55 PM, Jeff Scaparra <[email protected]> wrote:
>
>> I am in the same situation and I am looking at the FPGA. I have tried
>> compiling the FPGA designs from the uhd git clone that I did today, however
>> I am getting an error.
>>
>> Process "Map" failed
>> INFO:TclTasksC:1850 - process run : Generate Programming File is done.
>> touch /home/scap/Radio/uhd/fpga/usrp2/top/N2x0/build-N200R3/u2plus.bin
>> python /home/scap/Radio/uhd/fpga/usrp2/top/python/check_timing.py
>> /home/scap/Radio/uhd/fpga/usrp2/top/N2x0/build-N200R3/u2plus.twr
>> Traceback (most recent call last):
>> File "/home/scap/Radio/uhd/fpga/usrp2/top/python/check_timing.py", line
>> 33, in <module>
>> if __name__=='__main__': map(print_timing_constraint_summary,
>> sys.argv[1:])
>> File "/home/scap/Radio/uhd/fpga/usrp2/top/python/check_timing.py", line
>> 25, in print_timing_constraint_summary
>> for line in open(twr_file).readlines():
>> IOError: [Errno 2] No such file or directory:
>> '/home/scap/Radio/uhd/fpga/usrp2/top/N2x0/build-N200R3/u2plus.twr'
>> make[1]: *** [bin] Error 1
>> make[1]: Leaving directory `/home/scap/Radio/uhd/fpga/usrp2/top/N2x0'
>> make: *** [N200R3] Error 2
>>
>> Does anyone know how I can get more information for diagnostics. I have
>> installed a evaluation version of ISE 13.2 and am just running make on the
>> fpga/usrp2/top directory.
>>
>> Any help would be appreciated. Also I think there will be a lot of
>> interest in FPGA development as I have found that it will be needed for
>> anything larger than 10MS/S on my computer. Perhaps we should start a wiki
>> page and those of us working on this could start putting something
>> together.
>>
>> - Scap
>>
>> _______________________________________________
> 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/20120509/4d1e936c/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 9 May 2012 16:31:40 -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:
<cadnn3yx1axeq5x+kea7pgkng2tvbz8tfjc3yjmvghgzoee-...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Thanks Josh, I will try this later this week.
I don't understand what you mean that the USRP isn't capable of
bursting -- I mean, if it didnt, how would openBTS work? Perhaps I'm
misunderstanding you.
Isaac
On Tue, May 8, 2012 at 7:04 PM, Josh Blum <[email protected]> wrote:
>
>
> 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: 8
Date: Wed, 9 May 2012 17:34:20 -0500
From: Steve Peters <[email protected]>
To: Ian Buckley <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] FPGA reprogramming and real-time
Message-ID:
<CANgtPkh1RpH=cdsaowohforp_6zdheru2qlvqmknevlmwgk...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Turns out this is probably a licensing issue. I had a node-locked license
tied to my WLAN card, and the license manager was reading the Ethernet LAN
MAC. When ISE wouldn't build a certain part, the make file kept executing
until it failed somewhere further down the line.
I really appreciate the effort Ian.
Steve
On Wed, May 9, 2012 at 3:24 PM, Steve Peters <[email protected]> wrote:
> N210 rev3 and rev4 (have both, tried both, got the same error for both).
> ISE 14.1, just came out yesterday I believe. Maybe upgrading was a
> mistake. I've gotten it to work before with 13.2 on a completely different
> setup.
>
>
> On Wed, May 9, 2012 at 2:51 PM, Ian Buckley <[email protected]> wrote:
>
>> Which flavor of USRP are you building for and using which ISE version pls?
>>
>> On May 9, 2012, at 12:19 PM, Steve Peters wrote:
>>
>> Jeff,
>>
>> I'm getting this same error. Did you ever obtain a solution?
>>
>> Thanks,
>> Steve
>>
>> On Mon, Oct 10, 2011 at 12:55 PM, Jeff Scaparra <[email protected]>wrote:
>>
>>> I am in the same situation and I am looking at the FPGA. I have tried
>>> compiling the FPGA designs from the uhd git clone that I did today, however
>>> I am getting an error.
>>>
>>> Process "Map" failed
>>> INFO:TclTasksC:1850 - process run : Generate Programming File is done.
>>> touch /home/scap/Radio/uhd/fpga/usrp2/top/N2x0/build-N200R3/u2plus.bin
>>> python /home/scap/Radio/uhd/fpga/usrp2/top/python/check_timing.py
>>> /home/scap/Radio/uhd/fpga/usrp2/top/N2x0/build-N200R3/u2plus.twr
>>> Traceback (most recent call last):
>>> File "/home/scap/Radio/uhd/fpga/usrp2/top/python/check_timing.py",
>>> line 33, in <module>
>>> if __name__=='__main__': map(print_timing_constraint_summary,
>>> sys.argv[1:])
>>> File "/home/scap/Radio/uhd/fpga/usrp2/top/python/check_timing.py",
>>> line 25, in print_timing_constraint_summary
>>> for line in open(twr_file).readlines():
>>> IOError: [Errno 2] No such file or directory:
>>> '/home/scap/Radio/uhd/fpga/usrp2/top/N2x0/build-N200R3/u2plus.twr'
>>> make[1]: *** [bin] Error 1
>>> make[1]: Leaving directory `/home/scap/Radio/uhd/fpga/usrp2/top/N2x0'
>>> make: *** [N200R3] Error 2
>>>
>>> Does anyone know how I can get more information for diagnostics. I have
>>> installed a evaluation version of ISE 13.2 and am just running make on the
>>> fpga/usrp2/top directory.
>>>
>>> Any help would be appreciated. Also I think there will be a lot of
>>> interest in FPGA development as I have found that it will be needed for
>>> anything larger than 10MS/S on my computer. Perhaps we should start a wiki
>>> page and those of us working on this could start putting something
>>> together.
>>>
>>> - Scap
>>>
>>> _______________________________________________
>> 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/20120509/e159019c/attachment-0001.html>
------------------------------
Message: 9
Date: Wed, 09 May 2012 16:47:00 -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/09/2012 01:31 PM, Isaac Gerg wrote:
> Thanks Josh, I will try this later this week.
>
> I don't understand what you mean that the USRP isn't capable of
The problem is that things are asynchronous like shutting off transmit
with respect to the samples. Thats why we do EOB flag inline with the TX
packets in the later USRPs.
The EOB flag for USRP1 shuts off the transmitter, but its asynchronous
with respect to the samples. So its hard to flush out those last zeros.
> bursting -- I mean, if it didnt, how would openBTS work? Perhaps I'm
> misunderstanding you.
>
OpenBTS has a customized FPGA image. If it is using the basically same
TX chain, then it might be left with TX enable, and every end'ing of
burst results in an underflow.
The benefit is that all the samples sent are guaranteed to be
transmitted. Not sure how that affects the ATR switching. But this is a
totally possible and reasonable usage model for USRP1+UHD.
-Josh
------------------------------
Message: 10
Date: Wed, 9 May 2012 20:40:17 -0400
From: Matt Ettus <[email protected]>
To: [email protected], [email protected]
Subject: [USRP-users] SSC Spectrum Sensing Toolbox at CTIA
Message-ID:
<CAN=1kn8NjzHbQEctOZMBW=hbh_reqrxnhkrjmpeqkb55zkj...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
We are very excited to announce our partnership with Shared Spectrum
Company (SSC). SSC has long been a leader in the areas of dynamic spectrum
access and spectrum sensing. If you are lucky enough to be at the CTIA
show this week, you should stop by their booth and see the new Spectrum
Sensing Toolbox (SST), which is based on USRP devices.
The Spectrum Sensing Toolbox (SST) is an innovative software package that
enables highly precise radio frequency sensing by wireless devices
operating in the TV White Spaces (TVWS) and other spectrum bands. Among its
many features, the SST accurately detects wireless microphones, TV
transmitters and other emitters while allowing TVWS devices to avoid false
alarms, access more spectrum and improve quality of service. The SST is
based on over a decade of research and field testing in harsh RF
environments for defense, government and commercial users.
Spectrum Sensing Toolbox main page:
http://www.sharedspectrum.com/dsa-licensing/sensing-toolbox/
Press Release Here:
http://www.sharedspectrum.com/2012/05/shared-spectrum-company-launches-spectrum-sensing-toolbox-for-the-ettus-research-platform-at-ctia-wireless-2012-2/
Matt Ettus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120509/c81a3f98/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 9 May 2012 18:09:16 -0700 (PDT)
From: Farrukh Aziz <[email protected]>
To: USRP user forum <[email protected]>
Subject: [USRP-users] Determining the IF in different configs
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I have been working with different combinations of USRP motherboards and
daughterboards i.e a) N210 with WBX b) N210 with TVRX2 c) USRP1 with WBX. I
understand that the passband signal is eventually downconverted to the
baseband, but I do not know exactly ?where is this process completed? Are all
these dboards direct conversion boards, or do the dboards downconvert to a low
IF and then the FPGA downcoverts from IF to DC. If so, then what is that low
IF?I will appreciate an answer, as I need this info for my report writing.
Farrukh Aziz Bhatti
Department of Electrical & Computer Engineering
University of Auckland
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120509/b46eff95/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 09 May 2012 18:14:28 -0700
From: John Malsbury <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Determining the IF in different configs
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Farrukh,
TVRX2 uses an IF that dependent on the selected bandwidth. LFRX/TX
BaiscRX/TX use an IF when a single channel is used(i.e. subdevice A:A).
All others use a quadrature interface. The remaining boards use a
quadrature interface, and can be configured for low IF with the offset
tuning commands.
The up/downconversion is takes place in the analog domain, and then in
the DDC/DUC in the FPGA, which provides finer tuning resolution than the
PLLs.
http://files.ettus.com/uhd_docs/manual/html/dboards.html
http://files.ettus.com/uhd_docs/manual/html/general.html#tuning-notes
-John
On 05/09/2012 06:09 PM, Farrukh Aziz wrote:
> I have been working with different combinations of USRP motherboards
> and daughterboards i.e a) N210 with WBX b) N210 with TVRX2 c) USRP1
> with WBX. I understand that the passband signal is eventually
> downconverted to the baseband, but I do not know exactly where is
> this process completed? Are all these dboards direct conversion
> boards, or do the dboards downconvert to a low IF and then the FPGA
> downcoverts from IF to DC. If so, then what is that low IF?
------------------------------
Message: 13
Date: Wed, 09 May 2012 21:22:31 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Determining the IF in different configs
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 05/09/2012 09:09 PM, Farrukh Aziz wrote:
> I have been working with different combinations of USRP motherboards
> and daughterboards i.e a) N210 with WBX b) N210 with TVRX2 c) USRP1
> with WBX. I understand that the passband signal is eventually
> downconverted to the baseband, but I do not know exactly where is
> this process completed? Are all these dboards direct conversion
> boards, or do the dboards downconvert to a low IF and then the FPGA
> downcoverts from IF to DC. If so, then what is that low IF?
> I will appreciate an answer, as I need this info for my report writing.
>
> *Farrukh Aziz Bhatti*
> Department of Electrical & Computer Engineering
> University of Auckland
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
The WBX is a direct-conversion daughtercard.
The TVRX2 uses a low-IF, and the conversion to complex-baseband is
accomplished in the FPGA. According to the code, the IF is 12.5MHz for
this daughtercard.
--
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/20120509/43f67695/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 9 May 2012 21:03:13 -0700 (PDT)
From: Aaron Eaton <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP B100 Sensitivity Issue
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi All,
I suspect that I have a B100/WBX with a receive sensitivity problem. I'm
wondering if I am doing something wrong which is causing my B100 to perform
poorly or if my
B100 main board is bad.
I tested the 12 dB SINAD sensitivity (which is considered the minimum usable
signal for an analog radio) of my B100/WBXunder the following
conditions:
-LO offset of 10 MHz in gnruradio companion?
(uhd.tune_request(150000000,10000000))
-smallest possible sample rate (125kHz) for lowest noise floor
-self calibrated with version 0.2 of the
UHD calibration routines which contains a B100 calibration enhancement
-WBX Board (not B100) has been sent back to ETTUS for verification and has been
verified as good
Setup Information
GNURADIO Companion Version: 3.6.1git-61-gf9f1508e
UHD Version:???????????????????????????? UHD_003.004.001-111-g869e5ff1
UBUNTU Version :???????????????????? 12.04 LTS
USRP B100 SN:??????????????????????? EOR 10Z3B1
WBX S/N
:??????????????????????????????? E3R0C22GS
USRP
B100 Jumpers:??????????????? J17 OPEN
??????????????????????????????????????????????? J102 OPEN, OPEN, OPEN
??????????????????????????????????????????????? J15? two left pins shorted
(w.r.t silkscreen printing) shorted, 3rd disconnected
SINAD Signal Generator Setup
Communications Test Set:????????? HP8920B
FM
Deviation:??????????????????????????? 3 kHz
Modulation frequency:??????????????? 1 kHz
Carrier Frequency:???????????????????? 150 MHz
Gnuradio Companion Flowgraph used for this test:
http://www.flickr.com/photos/31205821@N03/7168633298/in/photostream
Picture of RF Spectrum with -70 dBm SINAD Test Signal
http://www.flickr.com/photos/31205821@N03/7168619146/in/photostream
Picture of Filtered SINAD Test Signal centred at 0 Hz
http://www.flickr.com/photos/31205821@N03/7168618586/in/photostream
Time Domain of demodulated 1 kHz SINAD Test Signal
http://www.flickr.com/photos/31205821@N03/7168618054/in/photostream
Sensitivity Test Result:
Level required to achieve 12 dB SINAD at the B100 SMA input connector: -70 dBm
A few months ago,I measured it at? -84 dBm.? It seems to be getting worse. A
normal analog narrowband reciever requires only -115 to -120 dBm to achieve
12dB SINAD. Therefore, my B100 is now missing approximately 50 dB of
sensitivity.? This is a
MAJOR
sensitivity degradation.? Only strong local signals can be heard with an
outdoor antenna.
Other users on the internet report -117 dBm 12 dB SINAD sensitivity, which is
what I would expect.? Has anybody else measured the sensitivity of their USRP??
Thanks in advance.
Aaron Eaton
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120509/4c51d3bd/attachment-0001.html>
------------------------------
Message: 15
Date: Thu, 10 May 2012 00:10:06 -0400
From: Count Zero <[email protected]>
To: [email protected]
Subject: [USRP-users] Amplification Equipment?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
I will greatly appreciate any pointers / recommendations you guys may have to
equipment that can be used to increase the range of a USRP2.
The frequency range is the standard GSM bands, so between 800MHz and 1900MHz.
Cheers.
--
Count Zero
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120510/6b385a79/attachment-0001.html>
------------------------------
Message: 16
Date: Thu, 10 May 2012 09:46:37 +0500
From: salman dinani <[email protected]>
To: usrp-users <[email protected]>, Mike McLernon
<[email protected]>, [email protected]
Subject: [USRP-users] Shifting on USRPN200 FPGA processing..
Message-ID:
<cadt0h5ar6f0yczph4up2e0fhoe0t7cdzt7e4smfgshghraj...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
I am using USRP N200 with SBX daughtecard via MATLAB R2011b. I wanted to
transmit and receive from my USRP using MATLAB but was facing some timing
and synchronization issues like I wanted to first transmit for a certain
time (i.e 3 usec) and after that wants to switch from TX to RX mode and
receive for a particular window and goes back to transmit and repeat this
cycle.. what i observed that when i tried to do this in SIMULINK, i started
to face timing issues.. the time at which i was turing off the TX
was different from what was happening in hardware, similarly it was taking
a considerable time to switch from TX to RX mode in SIMULINK. (Note: The
only TX and only RX projects are runing perfectly, but when SDRu TX block
and SDRu RX block are put in one single project of SIMULINK
these problems arises).
Therefore after asking from experts on this forum i reached to conclusion
that this thing cant be done on MATLAB/SIMULINK.. Now I have decided
that the TX portion is to implemented on FPGA of USRP N200 and use MATLAB/
Simulink for receiving data..
could any one please guide me :
1) where to start?
2) How to incorporated a TX code in existing USRP N200 default verliog
code?
3) where to find this default code?
Thanks,
Regards
Salman Dinani
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120510/8a4e55e0/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 09 May 2012 22:01:31 -0700
From: John Malsbury <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Shifting on USRPN200 FPGA processing..
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Salman,
The FPGA code can be found in the /fpga folder of the UHD git
repository. The readme file in this folder gives some guidance on how
to integrate custom code into the DSP chains - which is really the
easiest method at this point. These are your starting points.
Supposedly, MATLAB/Simulink has specialized capability to synthesize
code for the N200/210 with the HDL Coder tool, but I have to defer to
the Mathworks guys on those details.
Before jumping into the FPGA, you may want to consider a hybrid software
approach with an application that uses the new timing features of the
UHD API and passes data to/from matlab scripts. Depending on the
coupling between your transmit and receive protocols, this should be
fairly workable.
-John
On 5/9/2012 9:46 PM, salman dinani wrote:
> Hi all,
>
> I am using USRP N200 with SBX daughtecard via MATLAB R2011b. I wanted
> to transmit and receive from my USRP using MATLAB but was facing some
> timing and synchronization issues like I wanted to first transmit for
> a certain time (i.e 3 usec) and after that wants to switch from TX to
> RX mode and receive for a particular window and goes back to transmit
> and repeat this cycle.. what i observed that when i tried to do this
> in SIMULINK, i started to face timing issues.. the time at which i was
> turing off the TX was different from what was happening in hardware,
> similarly it was taking a considerable time to switch from TX to RX
> mode in SIMULINK. (Note: The only TX and only RX projects are runing
> perfectly, but when SDRu TX block and SDRu RX block are put in one
> single project of SIMULINK these problems arises).
>
> Therefore after asking from experts on this forum i reached to
> conclusion that this thing cant be done on MATLAB/SIMULINK.. Now I
> have decided
> that the TX portion is to implemented on FPGA of USRP N200 and use
> MATLAB/ Simulink for receiving data..
>
> could any one please guide me :
> 1) where to start?
> 2) How to incorporated a TX code in existing USRP N200 default verliog
> code?
> 3) where to find this default code?
>
> Thanks,
>
> Regards
>
> Salman Dinani
>
>
>
> _______________________________________________
> 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/20120509/b8d6109f/attachment-0001.html>
------------------------------
Message: 18
Date: Thu, 10 May 2012 10:04:24 +0200
From: Andre Puschmann <[email protected]>
To: Matt Ettus <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] SSC Spectrum Sensing Toolbox at CTIA
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/10/2012 02:40 AM, Matt Ettus wrote:
>
>
> We are very excited to announce our partnership with Shared Spectrum
> Company (SSC). SSC has long been a leader in the areas of dynamic
> spectrum access and spectrum sensing. If you are lucky enough to be at
> the CTIA show this week, you should stop by their booth and see the new
> Spectrum Sensing Toolbox (SST), which is based on USRP devices.
>
> The Spectrum Sensing Toolbox (SST) is an innovative software package
> that enables highly precise radio frequency sensing by wireless devices
> operating in the TV White Spaces (TVWS) and other spectrum bands. Among
> its many features, the SST accurately detects wireless microphones, TV
> transmitters and other emitters while allowing TVWS devices to avoid
> false alarms, access more spectrum and improve quality of service. The
> SST is based on over a decade of research and field testing in harsh RF
> environments for defense, government and commercial users.
>
> Spectrum Sensing Toolbox main page:
>
> http://www.sharedspectrum.com/dsa-licensing/sensing-toolbox/
>
Sounds good. I am missing the download button, though.
-Andre
------------------------------
Message: 19
Date: Thu, 10 May 2012 14:52:06 +0500
From: salman dinani <[email protected]>
To: John Malsbury <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Shifting on USRPN200 FPGA processing..
Message-ID:
<cadt0h5awqb1ghqnnzwa1mavvu5_zu8tddadywuqrxg4dedg...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi josh,
HDL coder seems to be very interesting, I am indeed looking forward to the
Mathswork guys.
1) what is this UHD API?
2) How to use it?
Thanks
Regards
Salman Dinani
On Thu, May 10, 2012 at 10:01 AM, John Malsbury <[email protected]>wrote:
> Salman,
>
> The FPGA code can be found in the /fpga folder of the UHD git repository.
> The readme file in this folder gives some guidance on how to integrate
> custom code into the DSP chains - which is really the easiest method at
> this point. These are your starting points.
>
> Supposedly, MATLAB/Simulink has specialized capability to synthesize code
> for the N200/210 with the HDL Coder tool, but I have to defer to the
> Mathworks guys on those details.
>
> Before jumping into the FPGA, you may want to consider a hybrid software
> approach with an application that uses the new timing features of the UHD
> API and passes data to/from matlab scripts. Depending on the coupling
> between your transmit and receive protocols, this should be fairly workable.
>
> -John
>
>
>
> On 5/9/2012 9:46 PM, salman dinani wrote:
>
> Hi all,
>
> I am using USRP N200 with SBX daughtecard via MATLAB R2011b. I wanted to
> transmit and receive from my USRP using MATLAB but was facing some timing
> and synchronization issues like I wanted to first transmit for a certain
> time (i.e 3 usec) and after that wants to switch from TX to RX mode and
> receive for a particular window and goes back to transmit and repeat this
> cycle.. what i observed that when i tried to do this in SIMULINK, i started
> to face timing issues.. the time at which i was turing off the TX
> was different from what was happening in hardware, similarly it was taking
> a considerable time to switch from TX to RX mode in SIMULINK. (Note: The
> only TX and only RX projects are runing perfectly, but when SDRu TX block
> and SDRu RX block are put in one single project of SIMULINK
> these problems arises).
>
> Therefore after asking from experts on this forum i reached to
> conclusion that this thing cant be done on MATLAB/SIMULINK.. Now I have
> decided
> that the TX portion is to implemented on FPGA of USRP N200 and use MATLAB/
> Simulink for receiving data..
>
> could any one please guide me :
> 1) where to start?
> 2) How to incorporated a TX code in existing USRP N200 default verliog
> code?
> 3) where to find this default code?
>
> Thanks,
>
> Regards
>
> Salman Dinani
>
>
>
> _______________________________________________
> USRP-users mailing
> [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/20120510/939e4cf1/attachment-0001.html>
------------------------------
Message: 20
Date: Thu, 10 May 2012 07:11:02 -0700
From: John Malsbury <[email protected]>
To: salman dinani <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Shifting on USRPN200 FPGA processing..
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki
You should download the source from the git repository, as seen in the
directions here:
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki/UHD_Build
-John
On 5/10/2012 2:52 AM, salman dinani wrote:
> Hi josh,
>
> HDL coder seems to be very interesting, I am indeed looking forward to
> the Mathswork guys.
>
> 1) what is this UHD API?
> 2) How to use it?
>
> Thanks
>
> Regards
> Salman Dinani
>
> On Thu, May 10, 2012 at 10:01 AM, John Malsbury
> <[email protected] <mailto:[email protected]>> wrote:
>
> Salman,
>
> The FPGA code can be found in the /fpga folder of the UHD git
> repository. The readme file in this folder gives some guidance on
> how to integrate custom code into the DSP chains - which is really
> the easiest method at this point. These are your starting points.
>
> Supposedly, MATLAB/Simulink has specialized capability to
> synthesize code for the N200/210 with the HDL Coder tool, but I
> have to defer to the Mathworks guys on those details.
>
> Before jumping into the FPGA, you may want to consider a hybrid
> software approach with an application that uses the new timing
> features of the UHD API and passes data to/from matlab scripts.
> Depending on the coupling between your transmit and receive
> protocols, this should be fairly workable.
>
> -John
>
>
>
> On 5/9/2012 9:46 PM, salman dinani wrote:
>> Hi all,
>>
>> I am using USRP N200 with SBX daughtecard via MATLAB R2011b. I
>> wanted to transmit and receive from my USRP using MATLAB but was
>> facing some timing and synchronization issues like I wanted to
>> first transmit for a certain time (i.e 3 usec) and after that
>> wants to switch from TX to RX mode and receive for a particular
>> window and goes back to transmit and repeat this cycle.. what i
>> observed that when i tried to do this in SIMULINK, i started to
>> face timing issues.. the time at which i was turing off the TX
>> was different from what was happening in hardware, similarly it
>> was taking a considerable time to switch from TX to RX mode in
>> SIMULINK. (Note: The only TX and only RX projects are runing
>> perfectly, but when SDRu TX block and SDRu RX block are put in
>> one single project of SIMULINK these problems arises).
>>
>> Therefore after asking from experts on this forum i reached to
>> conclusion that this thing cant be done on MATLAB/SIMULINK.. Now
>> I have decided
>> that the TX portion is to implemented on FPGA of USRP N200 and
>> use MATLAB/ Simulink for receiving data..
>>
>> could any one please guide me :
>> 1) where to start?
>> 2) How to incorporated a TX code in existing USRP N200 default
>> verliog code?
>> 3) where to find this default code?
>>
>> Thanks,
>>
>> Regards
>>
>> Salman Dinani
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[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/20120510/c933857d/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 10
******************************************
