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: [Discuss-gnuradio] usrp_n200_r3_fpga.bin build error
(Ian Buckley)
2. Re: LFRX antialiasing (Jeff Scaparra)
3. Re: LFRX antialiasing (Marcus D. Leech)
4. Re: [Discuss-gnuradio] usrp_n200_r3_fpga.bin build error
(Ian Buckley)
5. setting clock source with SDRu library in Matlab? (Qifanski)
6. Recommend Amp, LNA, Antennas, etc. (Mark McCarron)
7. scheduled transmission using tx_timed_samples.cpp (Sam mite)
8. Re: setting clock source with SDRu library in Matlab?
(Mike McLernon)
----------------------------------------------------------------------
Message: 1
Date: Wed, 1 May 2013 09:01:23 -0700
From: Ian Buckley <[email protected]>
To: "Rahman, Muhammad Mahboob Ur" <[email protected]>
Cc: "[email protected] forum" <[email protected]>,
Ian Buckley <[email protected]>, "[email protected] list"
<[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] usrp_n200_r3_fpga.bin
build error
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
OK, if you have yet to change any files from the default and that is the result
of a build then I strongly suspect the ISE version.
2013.1 has not been used to try to build any of the USRP databases yet.
2012.4 (14.4) is known to work for N200, and production images for N200 as
supplied by Ettus are still built using ISE12.1.
I'll load 2013.1 later today and see if I can reproduce your problems.
On May 1, 2013, at 8:08 AM, "Rahman, Muhammad Mahboob Ur"
<[email protected]> wrote:
> Hi Ian,
>
>
>> USRP specific questions (especially FPGA/Hardware) are best directed
>> at the USRP mailing list, rather than the GNURadio one.
>
> You are right in your suggestion :)
>
>> It's hard to say exactly what has caused this error, but basically it;s
>> failing to identify the module name that is the root/top of the FPGA
>> hierarchy.
>> I'm curious to know if the following lines are present in
>> "build-N200R3/u2plus.xise" :
>> <property xil_pn:name="Implementation Top" xil_pn:value="Module|u2plus"
>> xil_pn:valueState="non-default"/>
>> <property xil_pn:name="Implementation Top File" xil_pn:value="../u2plus.v"
>> xil_pn:valueState="non-default"/>
>> <property xil_pn:name="Implementation Top Instance Path"
>> xil_pn:value="/u2plus" xil_pn:valueState="non-default"/>
>
> Not exactly, but this is what I see inside u2plus.xise file:
> <property xil_pn:name="Implementation Top" xil_pn:value=""
> xil_pn:valueState="default"/>
> <property xil_pn:name="Implementation Top Instance Path" xil_pn:value=""
> xil_pn:valueState="default"/>
>
> So should I edit it by hand to match what we expect?
>
>> To help further more information will be needed:
>> * What files in the design have you touched to make your changes
>
> None. But I will do some changes in u2plus_core.v in future.
>
>> * Have you been running ISE in a the gui mode on this project or altered
>> Makefiles or scripts.
>
> No.
>
>> * What version of ISE are you using
>
> 2013.1
>
>> * Detailed log file of your attempt to compile (make -f Makefile.N200R3 bin
>> 2>&1 | tee build.log)
>
> See attached.
>
>> As a sanity check it might be wise to prove that you can compile
>> an un-altered version of the FPGA using the same command line first.
>
> This is what I am currently doing.
>
>
>
> Thanks,
> Mahboob
> <build.log>_______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 2
Date: Wed, 1 May 2013 15:11:19 -0400
From: Jeff Scaparra <[email protected]>
To: Matt Ettus <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] LFRX antialiasing
Message-ID:
<calwgea1jkieevjfebhgwuyd8uupv2yojf4vb9e+t52pdyng...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I built some band-pass filters for 40 meters as I had FM stations aliasing
into receive. That solved the problems but were a pain to build. If your
having the same issues I would try building/buying a filter to place inline
with the USRP.
On Tue, Apr 30, 2013 at 4:29 PM, Matt Ettus <[email protected]> wrote:
> Yes it is current
> On Apr 30, 2013 3:24 PM, "mepard" <[email protected]> wrote:
>
>> On Apr 30, 2013, at 2:38 PM, Matt Ettus <[email protected]> wrote:
>>
>> > The LFRX has its own antialiasing. You don't need to add any unless
>> you need a much steeper rolloff.
>>
>>
>> We're trying to calculate the rolloff.
>>
>> Is the schematic at http://code.ettus.com/redmine/ettus/documents/4current?
>> We have LFRX Rev 2.2.
>>
>> Are you referring to R10, R11, R4, R5 with C25, C26, C22, C23,
>> respectively?
>>
>> -Marc
>>
>>
> _______________________________________________
> 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/20130501/95994c99/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 01 May 2013 15:24:23 -0400
From: "Marcus D. Leech" <[email protected]>
To: Jeff Scaparra <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] LFRX antialiasing
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 05/01/2013 03:11 PM, Jeff Scaparra wrote:
> I built some band-pass filters for 40 meters as I had FM stations
> aliasing into receive. That solved the problems but were a pain to
> build. If your having the same issues I would try building/buying a
> filter to place inline with the USRP.
>
http://www.minicircuits.com/products/filters_coax_low.shtml
Or, if your problems are *just* strong FM stations:
http://www.mcmelectronics.com/product/33-341
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 4
Date: Wed, 1 May 2013 14:43:25 -0700
From: Ian Buckley <[email protected]>
To: "Rahman, Muhammad Mahboob Ur" <[email protected]>
Cc: "[email protected] forum" <[email protected]>,
Ian Buckley <[email protected]>, "[email protected] list"
<[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] usrp_n200_r3_fpga.bin
build error
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Correct, all the build products for N series USRP's are prefixed "u2plus" when
they are generated directly via ISE, the name of the build directory identifies
the specific hardware they are built for.
On May 1, 2013, at 1:27 PM, "Rahman, Muhammad Mahboob Ur"
<[email protected]> wrote:
> Hi Ian,
>
> I have tried to build using 14.4; it took me about 40 minutes but eventually
> the process finished gracefully. So, we will stick to 14.4 for the time being.
>
> Now, I can see u2plus.bin file in /build-N200R3. I hope this is the intended
> file; i.e., it is equivalent to pre-compiled usrp_n200_fpga_r3.bin file.
> Right?
>
>
> Thanks,
> Mahboob
> ________________________________________
> From: Ian Buckley [[email protected]]
> Sent: 01 May 2013 11:01
> To: Rahman, Muhammad Mahboob Ur
> Cc: Ian Buckley; [email protected] forum; [email protected]
> list
> Subject: Re: [Discuss-gnuradio] usrp_n200_r3_fpga.bin build error
>
> OK, if you have yet to change any files from the default and that is the
> result of a build then I strongly suspect the ISE version.
> 2013.1 has not been used to try to build any of the USRP databases yet.
> 2012.4 (14.4) is known to work for N200, and production images for N200 as
> supplied by Ettus are still built using ISE12.1.
> I'll load 2013.1 later today and see if I can reproduce your problems.
>
>
> On May 1, 2013, at 8:08 AM, "Rahman, Muhammad Mahboob Ur"
> <[email protected]> wrote:
>
>> Hi Ian,
>>
>>
>>> USRP specific questions (especially FPGA/Hardware) are best directed
>>> at the USRP mailing list, rather than the GNURadio one.
>>
>> You are right in your suggestion :)
>>
>>> It's hard to say exactly what has caused this error, but basically it;s
>>> failing to identify the module name that is the root/top of the FPGA
>>> hierarchy.
>>> I'm curious to know if the following lines are present in
>>> "build-N200R3/u2plus.xise" :
>>> <property xil_pn:name="Implementation Top" xil_pn:value="Module|u2plus"
>>> xil_pn:valueState="non-default"/>
>>> <property xil_pn:name="Implementation Top File" xil_pn:value="../u2plus.v"
>>> xil_pn:valueState="non-default"/>
>>> <property xil_pn:name="Implementation Top Instance Path"
>>> xil_pn:value="/u2plus" xil_pn:valueState="non-default"/>
>>
>> Not exactly, but this is what I see inside u2plus.xise file:
>> <property xil_pn:name="Implementation Top" xil_pn:value=""
>> xil_pn:valueState="default"/>
>> <property xil_pn:name="Implementation Top Instance Path" xil_pn:value=""
>> xil_pn:valueState="default"/>
>>
>> So should I edit it by hand to match what we expect?
>>
>>> To help further more information will be needed:
>>> * What files in the design have you touched to make your changes
>>
>> None. But I will do some changes in u2plus_core.v in future.
>>
>>> * Have you been running ISE in a the gui mode on this project or altered
>>> Makefiles or scripts.
>>
>> No.
>>
>>> * What version of ISE are you using
>>
>> 2013.1
>>
>>> * Detailed log file of your attempt to compile (make -f Makefile.N200R3 bin
>>> 2>&1 | tee build.log)
>>
>> See attached.
>>
>>> As a sanity check it might be wise to prove that you can compile
>>> an un-altered version of the FPGA using the same command line first.
>>
>> This is what I am currently doing.
>>
>>
>>
>> Thanks,
>> Mahboob
>> <build.log>_______________________________________________
>> Discuss-gnuradio mailing list
>> [email protected]
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
------------------------------
Message: 5
Date: Wed, 1 May 2013 16:16:24 -0700
From: Qifanski <[email protected]>
To: [email protected]
Subject: [USRP-users] setting clock source with SDRu library in
Matlab?
Message-ID:
<CAPVg14a-Tw3+MySBCEA-kVxEYi8Ce_t+52hVYxmO+mDa=ra...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
Is there a way to let the USRP use an external clock source with SDRu
library? As it can be easily achieved with C++ or Python API.
If not? Is it easy to recompile firmware and let external clock be the
default option for USRPs?
Thanks,
Qski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130501/9413d8bb/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 2 May 2013 05:38:10 +0100
From: Mark McCarron <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Recommend Amp, LNA, Antennas, etc.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I am waiting on three new boards to arrive:
WBX (50-2200MHZ Rx/Tx)
BasicTX daughterboard (1-250MHz)
BasicRX daughterboard (1-250MHz)
On the Rx side, I am seeking recommendations for a single wideband antenna, LNA
and anything else people may recommend that can cover the range 1-2200MHz. If
the equipment can go to 6GHz and beyond as well, I would like to hear about it.
On the Tx side, I am looking for similar information but I would like to know
what option exist for amplification. Are there amplifiers that can cover
1-2200MHz and even beyond??? How many Watts, etc?
I have other questions too:
How does we correct high SWR in wideband setups?
What is the best transmission line?
Do we need impedance matching (ie antenna tuners) and what is the input
impedance of USRP boards?
Regards,
Mark McCarron
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130502/86ad1cb2/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 2 May 2013 12:49:11 +0500
From: Sam mite <[email protected]>
To: [email protected]
Subject: [USRP-users] scheduled transmission using
tx_timed_samples.cpp
Message-ID:
<CAPhW9TQ0V3FxS1eoGtMFk6c1OYReDugs+xFu=jdhysp6e5o...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi list,
I want to schedule my transmission and for the purpose I am trying to use
tx_timed_samples.cpp example in uhd/host/examples/. I want to transmit
after 5 seconds of the current time so I changed the value of seconds in
future
po::value<double>(&seconds_in_future)->default_value(5).
Also I inserted following code just to print the time
...
...
usrp->set_time_now(uhd::time_spec_t(0.0));
time_now = usrp->get_time_now();
std::cout<< "Start time is " << time_now.get_full_secs() <<"
"<<time_now.get_frac_secs()<<std::endl;
.....
.....
std::cout << std::endl << "Done!" << std::endl << std::endl;
uhd::time_spec_t time_last;
time_last = usrp->get_time_now();
std::cout<< "End time is " << time_last.get_full_secs() <<"
"<<time_last.get_frac_secs();
But the problem is, value of variable "seconds_in_future" doesn't seem to
effect the starting time of transmission as, I get the following output,
irrespective of "seconds_in_future", immediately without any delay:
Setting device timestamp to 0...
Start time is 0 7.801e-05
Sent packet: 363 samples
Sent packet: 363 samples
.....
.....
Sent packet: 363 samples
Sent packet: 363 samples
Sent packet: 199 samples
However, effect is observed on the following output
Waiting for async burst ACK... success
Done!
End time is 5 0.00197141.
How can I verify that, the transmission actually started after 5 seconds?
Thanks for the time.
--
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130502/31f73e1c/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 2 May 2013 15:48:55 +0000
From: Mike McLernon <[email protected]>
To: Qifanski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] setting clock source with SDRu library in
Matlab?
Message-ID:
<e3879be9a282cb45aab7ce258a9ae48f21a1d...@exmb-01-ah.ad.mathworks.com>
Content-Type: text/plain; charset="us-ascii"
Hi Qski,
At this time, the USRP support package from MathWorks does not offer support
for external clocking.
Mike
From: USRP-users [mailto:[email protected]] On Behalf Of
Qifanski
Sent: Wednesday, May 01, 2013 7:16 PM
To: [email protected]
Subject: [USRP-users] setting clock source with SDRu library in Matlab?
Hi,
Is there a way to let the USRP use an external clock source with SDRu library?
As it can be easily achieved with C++ or Python API.
If not? Is it easy to recompile firmware and let external clock be the default
option for USRPs?
Thanks,
Qski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130502/e6d2357e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 476 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130502/e6d2357e/attachment-0001.sig>
------------------------------
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 33, Issue 2
*****************************************
