Hi, I haven't run the bbn-code with gnuradio 3.6 but I did with 3.3. The
omnitreads aren't used anymore so try to include pthread instead. I believe it
will be possible to get it running.
From: discuss-gnuradio-bounces+ulrika.uppman=foi...@gnu.org
[mailto:discuss-gnuradio-bounces+ulrika.uppman
Hi Martin and Andre,
We haven't got all the traveling plans yet, but me and Patrik are planning to
arrive at Karlsruhe the day before. It sounds really nice to meet for a
beverage of some kind in the evening.
Regards,
Ulrika
-Ursprungligt meddelande-
On Fri, Feb 03, 2012 at 10:51:51AM
Hello,
We have been seeing a similar problem when we tried to change a top block by
stopping it and then creating a new top block.
First it looked like the problem was related to the synchronization of uhd
sources, see
http://lists.gnu.org/archive/html/discuss-gnuradio/2011-05/msg00441.html (Th
essage-
> From: Tom Rondeau [mailto:trondeau1...@gmail.com]
> Sent: Monday, January 24, 2011 3:49 PM
> To: Ulrika Uppman
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] problem building next branch
>
> On Mon, Jan 24, 2011 at 7:02 AM, Ulrika Uppman
&g
Hi,
I'm trying to build gnuradio with uhd on my system with Ubuntu 10.4. When
building master branch everything seems ok, but I have some problems building
the next branch of gnuradio. In gr-msdd6000/src/ there is an error where the
compiler complains on "./python/msdd.cc: No such file or direct
tember 28, 2010 1:27 AM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] USRP2 LEDs using UHD
>
> I just added this to the documentation:
>
> http://www.ettus.com/uhd_docs/manual/html/usrp2.html#front-panel-leds
>
> -Josh
>
> On 09/27/2010 06:54 AM, U
Hi!
What does the LEDs indicate when running USRP2 with UHD?
I understand some information about whether rx or tx are running is presented
on the LEDs, but I cannot find any information on which ones that is and what
the other four LEDs are indicating?
Best regards
Ulrika
___
Yes, if I remember it right the executor only checks a source for output space
and then calls work. If the work function doesn't produce any output it's
"broken" according to the executor code.
/Ulrika
> -Original Message-
> From: discuss-gnuradio-bounces+ulrika.uppman=foi...@gnu.org
>
Original Message-
> From: discuss-gnuradio-bounces+ulrika.uppman=foi...@gnu.org
> [mailto:discuss-gnuradio-bounces+ulrika.uppman=foi...@gnu.org]
> On Behalf Of Ulrika Uppman
> Sent: Tuesday, February 23, 2010 3:54 PM
> To: discuss-gnuradio@gnu.org
> Subject: RE: [Discuss-gnu
Hi,
I believe the short format isn't implemented for the USRP2 yet, or has this
been done recently?
/Ulrika
> -Original Message-
> From: discuss-gnuradio-bounces+ulrika.uppman=foi...@gnu.org
> [mailto:discuss-gnuradio-bounces+ulrika.uppman=foi...@gnu.org]
> On Behalf Of TANGUY Philippe
d for the frequency?
> What cables do you use to connect your reference clock? We
> are currently using quite long BNC's so I think my next step
> is to try to reduce this by using much shorter SMA's.
>
> Best regards,
> Marc.
>
>
>
> Ulrika Uppman wrot
m the printouts.
Thanks for any hints.
Regards,
Ulrika
> -Original Message-
> From: discuss-gnuradio-bounces+ulrika.uppman=foi...@gnu.org
> [mailto:discuss-gnuradio-bounces+ulrika.uppman=foi...@gnu.org]
> On Behalf Of Ulrika Uppman
> Sent: Monday, February 22, 2010 10:11 AM
>
Hi,
What do we see in your example? Have you divided the clock by 10?
Is the output stable or are the edges jittering anything?
When I look at our clock outputs (in a very quick measurement) they are all
approximately in phase but the edges are jittering quite a bit, and I would
assume that to d
quot; than you are not
> running the vrt branch.
>
> -Josh
>
> On 02/19/2010 06:47 AM, Ulrika Uppman wrote:
> > Sorry I made a mistake, I used the wrong fpga-build and
> firmware when I ran the vrt branch. When I discovered my
> mistake I downloaded the files from
>
i...@gnu.org]
> On Behalf Of Ulrika Uppman
> Sent: Friday, February 19, 2010 11:48 AM
> To: Per Zetterberg
> Cc: Discuss-gnuradio@gnu.org
> Subject: RE: [Discuss-gnuradio] RE: Timestamp value
>
> Hi,
> I have now tried both the git master and the vrt branch and
> the
egards,
/Ulrika
From: Tim Pearce [mailto:timothy.pea...@gmail.com]
Sent: Thursday, February 18, 2010 9:35 PM
To: Ulrika Uppman
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Timestamp value
Ulrika,
I agree with how you think the timestamps are generated -- it seems to work for
me
at is the difference with regard to timestamps and timing when using
the vrt branch?
Regards,
/Ulrika
> -Original Message-
> From: Per Zetterberg [mailto:per.zetterb...@ee.kth.se]
> Sent: Thursday, February 18, 2010 6:16 PM
> To: Ulrika Uppman
> Cc: Discuss-gnuradio@g
es.com]
> Sent: Thursday, February 18, 2010 8:17 PM
> To: Veljko Pejovic
> Cc: Ulrika Uppman; Discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Error on make from git
> development trunk
>
> On Thu, 2010-02-18 at 11:07 -0800, Veljko Pejovic wrote:
>
> > Alth
= 3090005852, diff = 806813696
ts_in = 408731484, ts_last = 3896819548, diff = 806879232
> -Original Message-
> From: discuss-gnuradio-bounces+ulrika.uppman=foi...@gnu.org
> [mailto:discuss-gnuradio-bounces+ulrika.uppman=foi...@gnu.org]
> On Behalf Of Ulrika Uppman
> Sent: Thursd
Hi,
I wonder how the timestamps are being generated for each ethernet-packet sent
from the USRP2 to the host? My initial idea about how it works was that
timestamps are generated at 100MHz (same as the samples) and then the timestamp
associated with the first sample in an ethernet data packet wi
Hello,
I'm having trouble compiling the code I checked out from the latest dev trunk
from http://gnuradio.org/git/gnuradio.git.
I configure with a prefix and I have checked that my pythonpath and
pkg_config_path are properly set. I have also tried to run the uninstall,
distclean and git clean c
Here is another interesting presentation from the same conference (RFMTC09):
http://www.hig.se/filearchive/Centrumbildningar/Radiocentrum/RFMTC09/Dokument/1-2-Peter-Handel-slides.pdf
and their paper "Receiver I/Q Imbalance: Tone Test, Sensitivity Analysis, and
the Universal Software Radio Periphe
If you change the io_signature(1,2, ...) to io_signature(1,1, ...) I believe it
will work.
/Ulrika
Från: discuss-gnuradio-bounces+ulrika.uppman=foi...@gnu.org
[mailto:discuss-gnuradio-bounces+ulrika.uppman=foi...@gnu.org] För George Nychis
Skickat: den 24 novemb
Sorry, but it seems that the windows find-function wasn't finding all
occurrences as expected... I found that the USRP2_MIN_SAMPLES is actually used
several times in the usrp2 source block.
-Ursprungligt meddelande-
Från: Ulrika Uppman
Skickat: den 16 september 2009 10:46
Till:
later rev), or is USRP2_MIN_SAMPLES not used at all?
/Ulrika
-Ursprungligt meddelande-
Från: Eric Blossom [mailto:e...@comsec.com]
Skickat: den 15 september 2009 20:23
Till: Ulrika Uppman
Kopia: GNU Radio Discussion
Ämne: Re: [Discuss-gnuradio] about USRP2_MIN_RX_SAMPLES
On Tue, Sep 15
Hi all!
I ran into the constant USRP2_MIN_RX_SAMPLES = 371 defined in usrp2_base.h, but
I don't get what it is used for (it comes with the comment "BIG ASS FIXME: get
from lower layer MTU calculation").
Does anyone know anything about this constant and what it affects? ... what is
depending on
Till: Ulrika Uppman
Kopia: GNU Radio Discussion
Ämne: Re: [Discuss-gnuradio] fundamentals of block-connections, message queue
etc.
As far as the usrp->gnuradio block goes - the frame to stream 'conversion'
happens in the usrp (or usrp2) source block (and on the tx side that similarly
to extract messages from the queue. Take a look
in the bbn_80211b_pkt.py and I think you will see how the message queues are
used there.
/Ulrika
Från: Milo Wong [mailto:milo.gnura...@gmail.com]
Skickat: den 26 augusti 2009 06:47
Till: Colby Boyer
Kopia: Ulri
t the connection and starting of flow graphs, but I could still use some
hints...
Tnx,
/Ulrika
Från: Colby Boyer [mailto:colby.bo...@gmail.com]
Skickat: den 26 augusti 2009 05:09
Till: Ulrika Uppman
Kopia: GNU Radio Discussion
Ämne: Re: [Discuss-gnuradio] fundamenta
Hi everyone,
I'm trying to get a grip of how the software code works in gnuradio. At the
moment I'm looking at the bbn 802.11b rx implementation.
I would like to understand how the data stream is transported from the usrp
source block and further to the rest of the processing blocks that are
co
Hi,
I'm thinking about how to receive data in a wider frequency range width the
USRP2, and I stumbled over some questions:
Is it possible to set the decimation rate less than 4? All the documentation I
have found is saying that 4 is the least interpolation/decimation value, but is
there any act
Hi everyone,
I would like to set the data width to 8 bit I and Q (instead of 16 bit) on the
wire when receiving data from the USRP2 to be able to receive a wider frequency
range. I found the set_rx_format() and set_tx_format() functions in usrp2.h but
they aren't implemented. My question is if
Hi!
We have encountered the same phenomena. The spikes at the carrier frequency
seems to be especially large on the RFX400, but is also there on the RFX2400.
We haven't been able to get rid of it, it's always there when transmitting. We
think it might be an LO-effect.
Regards
//Ulrika and Patri
I was using the RFX2400 daughterboard.
/Ulrika
-Ursprungligt meddelande-
Från: Eric Blossom [mailto:e...@comsec.com]
Skickat: den 12 juni 2009 20:18
Till: Ulrika Uppman
Kopia: GNU Radio Discussion
Ämne: Re: [Discuss-gnuradio] Error message when setting new center frequency
On Fri, Jun
Hello everyone!
We are confused about the error returned by set_rx_center_freq. The code below
is executed while the USRP2 is running.
usrp2::usrp2::sptr u2;
//-- clip --//
usrp2::tune_result tr;
if (!u2->set_rx_center_freq(new_freq, &tr)){
fprintf(stderr, "set_rx_center_freq(%g) failed\n",
Hi everyone!
When transmitting with the USRP2 and the RFX400 daughterboard, we get a very
significant frequency spike at the tuned center frequency. The level of the
spike is almost as high as the signal level, and it will appear even when
transmitting a 0-amplitude sine wave signal. Does anyon
Ettus [mailto:m...@ettus.com]
Skickat: den 14 maj 2009 19:07
Till: Ulrika Uppman
Kopia: discuss-gnuradio@gnu.org
Ämne: Re: [Discuss-gnuradio] Syncrinization of two USRP2s
Ulrika Uppman wrote:
> Hi,
>
> We've set up a test comparing a recieved white noise signal recieved
> by two us
guess. The
firmware used is the built version of 10766.
/Ulrika
-Ursprungligt meddelande-
Från: Juha Vierinen [mailto:jvier...@gmail.com]
Skickat: den 14 maj 2009 12:39
Till: Ulrika Uppman
Kopia: discuss-gnuradio@gnu.org
Ämne: Re: [Discuss-gnuradio] Syncrinization of two USRP2s
I was
Hi,
We've set up a test comparing a recieved white noise signal recieved by two
usrp2 recievers. The two receivers were clocked (1PPS and refclk) by a GPS
diciplined OCXO which outpus a 1PPS signal which is phase locked to the 10 MHz
reference. The daughterboard was the RFX400 configured with a
39 matches
Mail list logo