The waterfall rate is exactly like the fft rate: a decimation is
computed so that the actual rate of fft frames per second (from the log
power fft block) is approximately the given fft rate.
The reason for adding a new preference is that the CPU and graphics
requirements are different for the
On Fri, Aug 22, 2008 at 11:33:18AM -0700, Josh Blum wrote:
> I think we need another preference parameter for the "waterfall rate". It
> should not be the same rate as the fft rate.
>
> Howabout "waterfall_rate"?
OK. What are the units, and how would it behave?
Eric
__
I think we need another preference parameter for the "waterfall rate". It
should not be the same rate as the fft rate.
Howabout "waterfall_rate"?
On Fri, Aug 22, 2008 at 11:27 AM, Eric Blossom <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 22, 2008 at 07:26:07PM +0200, Stefan Bruens wrote:
> > On Mond
On Fri, Aug 22, 2008 at 07:26:07PM +0200, Stefan Bruens wrote:
> On Monday 18 August 2008 18:04:23 Johnathan Corgan wrote:
> > On Mon, Aug 18, 2008 at 4:57 AM, Firas A. <[EMAIL PROTECTED]> wrote:
> > > 2) I think screen refresh (drawing times) is too high (on my system) that
> > > leads to flickeri
On Monday 18 August 2008 18:04:23 Johnathan Corgan wrote:
> On Mon, Aug 18, 2008 at 4:57 AM, Firas A. <[EMAIL PROTECTED]> wrote:
> > 2) I think screen refresh (drawing times) is too high (on my system) that
> > leads to flickering.
>
> You can lower the frame rate from the default of 30 by adding t
On Tue, Aug 19, 2008 at 11:41 PM, Josh Blum <[EMAIL PROTECTED]> wrote:
> The flickering issue is fixed in the trunk r9333.
>
> Certain machines defaulted to "single" buffering. Double buffering is now
> explicitly enabled.
>
> cd gnuradio
> cd gr-wxgui
> svn up
> sudo make install
While this will
The flickering issue is fixed in the trunk r9333.
Certain machines defaulted to "single" buffering. Double buffering is
now explicitly enabled.
cd gnuradio
cd gr-wxgui
svn up
sudo make install
-Josh
___
Discuss-gnuradio mailing list
Discuss-gnurad
On Mon, Aug 18, 2008 at 1:22 PM, Eric Schneider
<[EMAIL PROTECTED]> wrote:
> I was bit by this as well. In my case I get the AttributeError error if
> config.conf is missing or has a typo ("type=nogl"). A present and correct
> config.conf works fine.
Okay, as of r9315 on the trunk, the type sel
To: Firas A.
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] New OpenGL-based FFT, Waterfall, and Scope
displays in trunk
On Mon, Aug 18, 2008 at 4:57 AM, Firas A. <[EMAIL PROTECTED]> wrote:
> 2) I think screen refresh (drawing times) is too high (on my system) that
> lea
Hi,
> Johnathan Corgan wrote :
>
> What directory were you running 'usrp_fft.py' from?
I was running from gr-utils/src/python/
Regards,
Firas
--
View this message in context:
http://www.nabble.com/New-OpenGL-based-FFT%2C-Waterfall%2C-and-Scope-displays-in-trunk-tp18988013p19035634.html
S
On Mon, Aug 18, 2008 at 4:57 AM, Firas A. <[EMAIL PROTECTED]> wrote:
> 2) I think screen refresh (drawing times) is too high (on my system) that
> leads to flickering.
You can lower the frame rate from the default of 30 by adding the
following line(s) to your config.conf:
[wxgui]
fft_rate=15 (..
Hi,
1) Great Work.
2) I think screen refresh (drawing times) is too high (on my system) that
leads to flickering.
3) Compiling a fresh trunk copy (rev 9311) on my C2D running Ubuntu 8.04,
the running of usrp_fft.py for the first time leads to the following error :
File "./usrp_fft.py", line 3
Rakesh Peter wrote:
Hi Josh..
The CPU usage goes around 75% for the application when I goto the
millisecond scales. Do take a look at the snapshot..
http://imagebin.ca/view/3ZJeY0.html
I am thinking that this is probably a limitation of the graphics
pipeline. The screen updates are too lar
On Sat, Aug 16, 2008 at 4:03 AM, Rakesh Peter <[EMAIL PROTECTED]> wrote:
> Just tested the opengl implementation... Rocks hard ! Update times are
> really up on my C2D 2.4G E4600 / 2GB / Intel 82G33/G31 / Ubuntu Hardy.
>
> Had to do a "make clean" also, since it was reporting some top_block4dump
>
Just tested the opengl implementation... Rocks hard ! Update times are
really up on my C2D 2.4G E4600 / 2GB / Intel 82G33/G31 / Ubuntu Hardy.
Had to do a "make clean" also, since it was reporting some top_block4dump
error while running any GR code. Probably a lone case. In Ubuntu, you can
get pyth
Awesome. 1000% Performance improvement under OSX.
Waterfall was completely unusable for me before. Thanks
ksh.
On Aug 14, 2008, at 9:21 PM, Johnathan Corgan wrote:
Josh Blum has implemented OpenGL-based versions of the FFT, waterfall,
and scope sinks in gr-wxgui. These have been merged into th
Quoting Johnathan Corgan <[EMAIL PROTECTED]>:
We are looking for testers, to measure the difference in performance
between the non-GL and GL versions, and in particular, the performance
of the GL versions when using a non-accelerated host-based GL
implementation like Mesa (without DRI).
In part
17 matches
Mail list logo