>
>
> I thought the 1 thread execution scheduler was deprecated in gnuradio?
>
> al fayez
>
You may still turn it off, but the TPB scheduling policy is now the default.
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
__
I thought the 1 thread execution scheduler was deprecated in gnuradio?
al fayez
-Original Message-
From: Michael Dickens
To: Alexander Chemeris
Cc: Gnuradio-discuss
Sent: Sat, May 28, 2011 11:38 am
Subject: Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
On
Well if you're sensing a 40 MHz band you have to retune. The largest band
you can sense without retuning is about 25 MHz.
Also I would try higher FFT sizes, like 1024, 2048, or 4096. Watch your CPU
load when you run your script, your processor probably isn't slowing you
down even with large FFT
On 05/28/2011 04:28 PM, Alexander Chemeris wrote:
So, while this method is simple and good for non-realtime
applications, it doesn't fit our needs. It may be usable for PHY<->MAC
interaction, but even here I'm not sure it would work well.
PS I test on Core 2 Duo 1.6 GHz with all the GUI stuff ru
On 05/28/2011 06:28 PM, Josh Blum wrote:
Just want to throw this out there because it seems relevant:
http://gnuradio.org/cgit/jblum.git/tree/gruel/src/include/gruel/high_res_timer.h?h=wip/high_res_timer&id=71b911d28a391ad0c67540e3658a6680d7449e1f
Yup, I know about clock_gettime().
But really
Just want to throw this out there because it seems relevant:
http://gnuradio.org/cgit/jblum.git/tree/gruel/src/include/gruel/high_res_timer.h?h=wip/high_res_timer&id=71b911d28a391ad0c67540e3658a6680d7449e1f
On 05/28/2011 02:42 PM, Alexander Chemeris wrote:
> On Sat, May 28, 2011 at 22:06, Marcus D
On 05/28/2011 02:01 PM, Brett L. Trotter wrote:
> With UHD, what's the proper way to use the A and B connectors on an LFRX
> to get quadrature sampling? I've tried setting subdev spec as A:AB but
No, AB is correct, and it all boils down to a simple mux setting:
http://www.ettus.com/uhd_docs/manu
Hi Alex,
On May 29, 2011, at 1:04 AM, Alexandru Csete wrote:
>
> Can you see which package requires fortran?
> It sounds like a false dependency and if there actually is something
> that requires fortran it might not be important.
>
> I looked through my config.log file but the only place where
On Sat, May 28, 2011 at 10:34 PM, Elvis Dowson wrote:
> Hi,
> One of the build dependencies for gnuradio on Mac OS X 10.6.7 is a
> version of gfortran.
> The compiler supplied with Xcode 4.0.2 on Mac OS X 10.6.7 is gcc version
> 4.2.1 (Apple Inc. build 5666) (dot 3).
> The most recent versio
On 05/28/2011 03:11 PM, Brett L. Trotter wrote:
I just discovered the not well published --with-fusb-tech=libusb1 option
to configure, hoping to resolve the USRP1 non-uhd crashing issues myself
and one other person are seeing when the flowgraphs do a lock or stop.
Unfortunately, I still see the s
Hi,
One of the build dependencies for gnuradio on Mac OS X 10.6.7 is a
version of gfortran.
The compiler supplied with Xcode 4.0.2 on Mac OS X 10.6.7 is gcc version 4.2.1
(Apple Inc. build 5666) (dot 3).
The most recent version of gfortran-4.2.1 that I could find was for build 5664.
htt
I just discovered the not well published --with-fusb-tech=libusb1 option
to configure, hoping to resolve the USRP1 non-uhd crashing issues myself
and one other person are seeing when the flowgraphs do a lock or stop.
Unfortunately, I still see the same lockup, which rules out any
libusb-0.1 possibi
On Sat, May 28, 2011 at 22:06, Marcus D. Leech wrote:
I evaluated latency of a FIFO (actually an ordinary pipe, but the kernel
mechanisms are identical), and measured 30usecs average on my
1.2GHz AMD Phenom system with plenty 'o memory.
I sent timestamps across the FIFO (struct timeval), and
On Sat, May 28, 2011 at 22:06, Marcus D. Leech wrote:
> I evaluated latency of a FIFO (actually an ordinary pipe, but the kernel
> mechanisms are identical), and measured 30usecs average on my
> 1.2GHz AMD Phenom system with plenty 'o memory.
>
> I sent timestamps across the FIFO (struct timeval)
I evaluated latency of a FIFO (actually an ordinary pipe, but the kernel
mechanisms are identical), and measured 30usecs average on my
1.2GHz AMD Phenom system with plenty 'o memory.
I sent timestamps across the FIFO (struct timeval), and the reader
grabbed the local time of day, and computed
With UHD, what's the proper way to use the A and B connectors on an LFRX
to get quadrature sampling? I've tried setting subdev spec as A:AB but
it doesn't seem to work with the UHD source at anything other than 0 for
the frequency for both USRP1 and USRP2 via UHD.
_
On Sat, May 28, 2011 at 6:50 AM, Tom Rondeau wrote:
> On Wed, May 25, 2011 at 3:16 PM, Marius wrote:
>>
>> Hi!
>>
>> - To my background there's to say - before you read this - I'm just a
>> software-dev. I have little expertise when it comes to hardware.
>>
>> I support the development of a real
On Sat, May 28, 2011 at 21:04, Marcus D. Leech wrote:
>> Hi all,
>>
>> I'm not sure whether to post this to GnuRadio or to USRP-users, so I
>> post it here.
>>
>> We've started a project to implement a custom SDR hardware (which we
>> plan to open-source later) and we want to reuse as much of USRP
Hi all,
I'm not sure whether to post this to GnuRadio or to USRP-users, so I
post it here.
We've started a project to implement a custom SDR hardware (which we
plan to open-source later) and we want to reuse as much of USRP FPGA
code as possible. But it will require a good deal of customization
Hi all,
I'm not sure whether to post this to GnuRadio or to USRP-users, so I
post it here.
We've started a project to implement a custom SDR hardware (which we
plan to open-source later) and we want to reuse as much of USRP FPGA
code as possible. But it will require a good deal of customization a
Is there information about what is the biggest latency-injector in GnuRadio?
Nearly all of the basic computational blocks are as blazing-fast as they
can be on a general-purpose
CPU. The biggest latency injector is the scheduler in general, and
the buffer management part of
that scheduler
On Sat, May 28, 2011 at 19:59, Marcus D. Leech wrote:
>> Real-time is not about performance, but about predictability ;) I have to
>> be sure that my flowgraph always executes before the deadline is hit. So
>> everything that introduces jitter is a no-no.
>
> In general, Gnu Radio executes on gene
On Sat, May 28, 2011 at 19:52, Marcus D. Leech wrote:
>> Problem here is that FIFO's are not very well suited for real-time
>> operation, IIRC. Have you tried a shared memory and shared signals
>> across applications?
>>
> It depends on what you mean by "real time". Certainly FIFO I/O will be
> s
Real-time is not about performance, but about predictability ;) I have
to be sure that my flowgraph always executes before the deadline is
hit. So everything that introduces jitter is a no-no.
In general, Gnu Radio executes on general-purpose OSes, which means that
there will *always* be micros
Problem here is that FIFO's are not very well suited for real-time
operation, IIRC. Have you tried a shared memory and shared signals
across applications?
It depends on what you mean by "real time". Certainly FIFO I/O will be
slower than
intra-flowgraph ring buffers, but not so horribly slugg
On Sat, May 28, 2011 at 19:38, Michael Dickens wrote:
> On May 28, 2011, at 11:26 AM, Alexander Chemeris wrote:
>> 5) How well is GnuRadio suited for real-time operation?
>
> In a general sense, yes, GNU Radio is well suited for real-time signal
> processing of data streams. That said: "Real tim
On May 28, 2011, at 11:26 AM, Alexander Chemeris wrote:
> 5) How well is GnuRadio suited for real-time operation?
In a general sense, yes, GNU Radio is well suited for real-time signal
processing of data streams. That said: "Real time" is only meaningful knowing
the performance criteria. What
On Sat, May 28, 2011 at 18:23, Marcus D. Leech wrote:
>> Cool! It would be truly great to see a simplified example of this in
>> the GnuRadio repository, and at least somehow mentioned on the wiki.
> Yes, I suppose it would. I'll put it on my list, but so many other
> things to do :-(
>
>>> The o
Hi community,
On Mon, May 23, 2011 at 23:50, Alexander Chemeris
wrote:
> Hi community,
>
> Our WiMAX Scanner project (http://code.google.com/p/wimax-scanner/)
> approaches the moment when we should start writing C/C++ code - our
> Matlab model decodes broadcast messages from all recordings we hav
> Cool! It would be truly great to see a simplified example of this in
> the GnuRadio repository, and at least somehow mentioned on the wiki.
Yes, I suppose it would. I'll put it on my list, but so many other
things to do :-(
>> The other "trick" that I use is to use the XMLRPC server stuff that
On Wed, May 25, 2011 at 3:16 PM, Marius wrote:
> Hi!
>
> - To my background there's to say - before you read this - I'm just a
> software-dev. I have little expertise when it comes to hardware.
>
> I support the development of a real-time application that uses
> 802.15.4 on an AT86230RF Chip. Th
On Wed, May 25, 2011 at 8:19 PM, Igor Almeida wrote:
> Hi all,
>
> I have been familiarizing myself with the inner guts of gnuradio and
> hacked together the attached patch, applied to tag v3.3.0. It is an
> extended version of gr_ofdm_cyclic_prefixer which can add cyclic
> suffix and symbol overl
On Fri, May 27, 2011 at 3:21 AM, Marcus D. Leech wrote:
> >
> > USRP1:
> > - When we have a very simple flowgraph with a USRP1 sink connected to a
> > signal source and a USRP1 source connected to a WX scope- trying to shut
> > down the app using the close box causes the USB on the host system to
Anti-tivoization is one of main differences (but not the only), but
it's about a different issue.
http://en.wikipedia.org/wiki/Tivoization
On Sat, May 28, 2011 at 05:14, Colby Boyer wrote:
> Isn't the main difference between v2 and v3 the "Tivo Exception" as
> the call it? Not sure.
>
> I guess I
On Thu, May 26, 2011 at 18:10, Marcus D. Leech wrote:
> On 26/05/2011 9:55 AM, Michael Dickens wrote:
>>
>> It would be great if you could share with the list example code snippets
>> of how you do the pipes. For example: Where in an online repository one can
>> find such code.
>>
>> I think that
On Wed, May 25, 2011 at 23:21, Jeff Brower wrote:
> Michael-
>
>> Hi Alexander - I think Martin & Tom covered that GNU Radio
>> is quite capable of being programmed for the basic receiver
>> processing. You might need to play around a bit with your
>> DSP blocks, but otherwise I think GNU Radio's
On Wed, May 25, 2011 at 22:29, Michael Dickens wrote:
> Hi Alexander - I think Martin & Tom covered that GNU Radio is quite capable
> of being programmed for the basic receiver processing. You might need to play
> around a bit with your DSP blocks, but otherwise I think GNU Radio's data
> process
On Tue, May 24, 2011 at 13:55, Tom Rondeau wrote:
> On Tue, May 24, 2011 at 7:04 AM, Martin Braun wrote:
>>
>> On Mon, May 23, 2011 at 11:50:52PM +0400, Alexander Chemeris wrote:
>> > Hi community,
>>
>> Hi Alex,
>>
>> > Our WiMAX Scanner project (http://code.google.com/p/wimax-scanner/)
>> > app
Hi Martin, hi all,
I'm sorry for delayed replies. That's not because I don't care - I
just have very tight schedule at this moment.
On Tue, May 24, 2011 at 10:04, Martin Braun wrote:
> On Mon, May 23, 2011 at 11:50:52PM +0400, Alexander Chemeris wrote:
>> Hi community,
>
> Hi Alex,
>
>> Our WiMA
39 matches
Mail list logo
