or run cmake-gui and check the box for usrp1 :-)
-Josh
On 11/04/2010 09:15 PM, Kyle Zhou wrote:
I am trying uhd with my usrp1. However, when I do cmake, it reported
that "usrp1 support disabled by configure flag".
usrp2 is enabled.
It seems to me usrp1 is disabled by default?
If I need to give
So its looks like it found USB support. My guess is that you ran the
configure again after installing libusb1.0. Either remove the
CMakeCache.txt and re-run cmake, or run the cmake command with the
option -DENABLE_USRP1=TRUE
-Josh
On 11/04/2010 09:15 PM, Kyle Zhou wrote:
I am trying uhd with
I am trying uhd with my usrp1. However, when I do cmake, it reported
that "usrp1 support disabled by configure flag".
usrp2 is enabled.
It seems to me usrp1 is disabled by default?
If I need to give some flags to cmake to enable usrp1?
I have no experience in cmake before.
Please help
Thanks
Kyle
Yes! that seems to be doing it.
After using u.set_dc_offset_cl_enable(0x0, 0xf) to disable the dc
correction the Low Freq roll-off seems to be gone and my IQ looks a
lot better.
That's really excelent, I presume I'll still need to compensate for
the dc in my flow graph now though...
Many thanks!
D
On Thursday, November 04, 2010 02:35:32 pm Tom Rondeau wrote:
> On Thu, Nov 4, 2010 at 5:06 PM, Eric Blossom wrote:
> > On Thu, Nov 04, 2010 at 10:17:04AM -0700, Steve Mcmahon wrote:
> >> It took me a while to get some time to go back to my openSUSE 11.3
> >> machine and regenerate the error messa
On 11/04/2010 07:47 PM, Eric Brombaugh wrote:
>
> You're probably seeing the high-pass behavior of the RX DC offset
> removal. There's a logical block inside the FPGA which integrates the
> ADC DC offset and subtracts it from the incoming signal.
>
> This function isn't needed on the TX side.
>
>
W
On 11/04/2010 04:24 PM, Drew Read wrote:
It seems that there is a very significant roll-off at lower
frequencies on the receive side which pretty much makes it unusable
for our baseband signals.
The aformentioned forum post suggests that it is not caused by the
LFRX board and so is likely to be
On 11/04/2010 07:24 PM, Drew Read wrote:
> Hi All,
>
> We're seeing pretty much the same thing on the USRP1 as this:
> http://www.ruby-forum.com/topic/206912#900641
>
> It seems that there is a very significant roll-off at lower
> frequencies on the receive side which pretty much makes it unusable
USRP1 support is in the UHD, but no timestamps.
-Josh
On 11/04/2010 05:56 AM, Kyle Zhou wrote:
I know time stamped tx/rx with usrp2 is supported in uhd.
According to past posts, support for usrp1 was worked on.
Could anyone give an update on that progress? Is it already done?
Regards
Kyle
I am also very interested in this. I have had some success by using
gr.message_source, and having a python thread that periodically pushes new
data into the system by putting it on the message queue. Transmitter auto_tr
is enabled so that when the usrp runs out of data it turns off the transmi
Hi All,
We're seeing pretty much the same thing on the USRP1 as this:
http://www.ruby-forum.com/topic/206912#900641
It seems that there is a very significant roll-off at lower
frequencies on the receive side which pretty much makes it unusable
for our baseband signals.
The aformentioned forum pos
On Thu, Nov 4, 2010 at 5:33 PM, Yan Nie wrote:
> Dear all,
>
> I am developing a transmitter on USRP1 with LFTX daughterboard. This
> transmitter sends a BPSK modulated Barker code sequence up-converting to a
> frequency ranging from 1MHz to 20MHz. I implemented the transmission of the
> whole se
On Thu, Nov 4, 2010 at 5:06 PM, Eric Blossom wrote:
> On Thu, Nov 04, 2010 at 10:17:04AM -0700, Steve Mcmahon wrote:
>> It took me a while to get some time to go back to my openSUSE 11.3 machine
>> and regenerate the error message. Sorry, I should have done this when I made
>> the initial post.
Dear all,I am developing a transmitter on USRP1 with LFTX daughterboard. This transmitter sends a BPSK modulated Barker code sequence up-converting to a frequency ranging from 1MHz to 20MHz. I implemented the transmission of the whole sequence in one fixed frequency in the requried range on one USR
On Thu, Nov 4, 2010 at 4:07 PM, Marc Epard wrote:
> This reminds me of a question. What do you guys use for profiling native code
> on Linux? I have a lot more experience on Mac OS where we have Shark,
> Instruments and the like.
>
> -Marc
Generally, I've used Oprofile. I have recently been exp
On 11/04/2010 01:25 PM, Marcus D. Leech wrote:
On 11/04/2010 03:23 PM, Josh Blum wrote:
Well, there is extra overhead. A "pirate" thread in the the receive
path spins on the socket and inspects the contents. The packet may be
an asynchronous message packet for flow control or destined for the
On Thu, Nov 04, 2010 at 03:07:42PM -0500, Marc Epard wrote:
> This reminds me of a question. What do you guys use for profiling
> native code on Linux? I have a lot more experience on Mac OS where
> we have Shark, Instruments and the like.
Marc,
I like to use oprofile. It's packaged for Fedora
On Thu, Nov 04, 2010 at 10:17:04AM -0700, Steve Mcmahon wrote:
> It took me a while to get some time to go back to my openSUSE 11.3 machine
> and regenerate the error message. Sorry, I should have done this when I made
> the initial post.
>
> So I successfully installed the following from source
On 11/04/2010 03:23 PM, Josh Blum wrote:
> Well, there is extra overhead. A "pirate" thread in the the receive
> path spins on the socket and inspects the contents. The packet may be
> an asynchronous message packet for flow control or destined for the
> user. Or it may be a data packet, in which c
Hello all,
I am building a USRP2 receiver that captures and stores data on the rising edge
of the pps input. Is there a gnuradio block or C++ function that would allow me
to monitor the pps input or see when its rising or falling edges occur?
Thanks,
Mike
This reminds me of a question. What do you guys use for profiling native code
on Linux? I have a lot more experience on Mac OS where we have Shark,
Instruments and the like.
-Marc
On Nov 4, 2010, at 2:23 PM, Josh Blum wrote:
> Well, there is extra overhead. A "pirate" thread in the the receive
Well, there is extra overhead. A "pirate" thread in the the receive path
spins on the socket and inspects the contents. The packet may be an
asynchronous message packet for flow control or destined for the user.
Or it may be a data packet, in which case it is placed into a queue to
be popped of
Hi All,
I've noticed that the C++ interfaces provided in gnu-radio and UHD for usrp2
data streaming are CPU-intensive (UHD moreso than gnu-radio). I am wondering
if
there are easy ways to mitigate this or are there plans in the future to
diminish these. For UHD a decimate by 16 process che
You don't need to build everything by your own. Just download the RPMs
from http://software.opensuse.org, put them on your usb-stick and
install them with "rpm -Uvh blablub.rpm"
As I mentioned above, it's no big deal to install and use an older gcc-version.
Alternatively, you could try to patch t
Dear all!
Myself and my colaborators have 2 USRP2+WBX boards. We use them in the
500-700 MHz band.
The boards worked just fine until today, when we have used a stronger input
signal generated by an Agilent signal generator connected directly via
cable. The generated signal, a 2 MHz - large wideb
It took me a while to get some time to go back to my openSUSE 11.3 machine and
regenerate the error message. Sorry, I should have done this when I made the
initial post.
So I successfully installed the following from source under openSUSE 11.3:
Cheetah-2.4.2.1.tar.gz
Markdown-2.0.3.tar.gz
cppun
On Thu, Nov 04, 2010 at 12:30:51AM -0400, Achilleas Anastasopoulos wrote:
> Nick and others,
>
> I have decoded a capture of ATSC that Nick provided (many thanks).
> Here are some numbers for double-checking:
> 3) the output of the field_sync_demux (pipe_5) is ~455MB which i don't
> know what it
I just followed the build instructions for GnuRadio 3.3.0 on
Ubuntu 10.04 LTS. All the dependencies updated/installed without
trouble, and the
./configure
make
sudo make install
worked fine. However, trying to run gnuradio-compainion failed, and
produced a misleading suggestion to check the PYTH
Tom,
Thanks for the input. I follow your philosophical point: multiple rate
limiting blocks are at best redundant, and at worst may cause problems.
But in my case, I'm trying get something "nearly synchronized" with a
user-interface action: a button press. Thus, all the buffering is
workin
On Tue, Nov 2, 2010 at 8:24 PM, Dan Harasty wrote:
> Hello, all.
>
> I'm still getting up to speed on gnuradio (does that make me a gnoob?
> or maybe a gnuub?)... ;-)
>
> Anyway, to learn how to instrument a simple flowgraph with a wxPython GUI
> elements, I conceived of something simple to j
Hi,
I found the appended THread in the archive.
That time, there was no answer to this mail.
But I have exactly the same problem to understand the architecture of
the packets.
It would be nice, if anyone could write a short explanation why the \x55
and the preamble are added to the packet.
I know time stamped tx/rx with usrp2 is supported in uhd.
According to past posts, support for usrp1 was worked on.
Could anyone give an update on that progress? Is it already done?
Regards
Kyle
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
Hi Marcus,
thanks a lot for sending the flowgraph. I completely understand it and I
am very confident that I can get this going. Only thing, I currently
don't have an external 3,5mm plugged microphone :-)
BR
Markus
DL8RDS
Am Mittwoch, den 03.11.2010, 23:54 -0400 schrieb Marcus D. Leech:
> On 11/
33 matches
Mail list logo
