-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Johnathan Corgan wrote:
> On 12/11/07, Johnathan Corgan <[EMAIL PROTECTED]> wrote:
>
>> I see this as well now. It can be attributed to a check-in on the trunk
>> 2 days ago that Martin did to fix an iir bug (r7089). I suspect the iir
>> QA needs to
General curiosity questions:
Are you using oprofile to measure performance?
I am a bit of a maverick, and for various reasons am using a pure C++
environment. I hacked my own 'connect_block' function (can;t wait for
v3.2, where these will be part of native gr). I am measuring the
perform
On 12/11/07, Johnathan Corgan <[EMAIL PROTECTED]> wrote:
> I see this as well now. It can be attributed to a check-in on the trunk
> 2 days ago that Martin did to fix an iir bug (r7089). I suspect the iir
> QA needs to be updated.
The changeset for r7089 has been reverted on the trunk.
--
Joh
Correction. The "-O" fix that I thought I had only works some of the
time. This is a very peculiar bug.
On Dec 11, 2007 8:24 PM, Ketan Mandke <[EMAIL PROTECTED]> wrote:
> I recently created an object which spawns an omni_thread and then
> cleans it up when stop() is called. The object that I creat
I recently created an object which spawns an omni_thread and then
cleans it up when stop() is called. The object that I created works
fine during normal operation, however when I run make check I get very
strange behavior. In Ticket #180
(http://gnuradio.utah.edu/trac/ticket/180), Eric describes th
Michael Dickens wrote:
> I finally got around to updating to the new top-block code, and 'make
> check' now fails on both Intel-Mac and PPC-Mac running OSX 10.4.11. The
> QA code is fine. Anyone else see this issue? - MLD
I see this as well now. It can be attributed to a check-in on the trunk
I finally got around to updating to the new top-block code, and 'make
check' now fails on both Intel-Mac and PPC-Mac running OSX 10.4.11.
The QA code is fine. Anyone else see this issue? - MLD
Making check in gnuradio-core
Making check in src
Making check in python
Making check in gnuradio
Eric Blossom wrote:
> On Tue, Dec 11, 2007 at 03:41:46PM -0800, Eugene Grayver wrote:
>> Please see answers in-line.
>>
>> Thanks!
>
>> General curiosity questions:
>>
>> Are you using oprofile to measure performance?
>>
>> I am a bit of a maverick, and for various reasons am using a pure C++
>
On Tue, Dec 11, 2007 at 04:03:28PM -0800, Dan Halperin wrote:
> Eugene Grayver wrote:
> > Please see answers in-line.
> > Which blocks are causing you the biggest problem?
> >
> > I got a 2x improvement on all the filtering blocks. About a 40%
> > improvement for sine/cosine generation blocks.
On Tue, Dec 11, 2007 at 03:41:46PM -0800, Eugene Grayver wrote:
> Please see answers in-line.
>
> Thanks!
> General curiosity questions:
>
> Are you using oprofile to measure performance?
>
> I am a bit of a maverick, and for various reasons am using a pure C++
> environment. I hacked my ow
Don Ward wrote:
> "Philip Heron" <[EMAIL PROTECTED]> wrote:
>
>> Martin Braun wrote:
>>> RXing with the USRP simply doesn't work, though, neither with
>>> usrp_rx_nogui.py nor with anything I could come up with. I get lots
>>> more noise than expected and usually I get a very loud buzz or
>>> whis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eugene Grayver wrote:
> Please see answers in-line.
> Which blocks are causing you the biggest problem?
>
> I got a 2x improvement on all the filtering blocks. About a 40%
> improvement for sine/cosine generation blocks. This includes gr_expj,
>
Please see answers in-line.
Thanks!
Eric Blossom <[EMAIL PROTECTED]>
12/11/2007 02:31 PM
To
Eugene Grayver <[EMAIL PROTECTED]>
cc
discuss-gnuradio@gnu.org
Subject
Re: [Discuss-gnuradio] Re-writing blocks using intel libraries
On Tue, Dec 11, 2007 at 10:13:32AM -
On Tue, Dec 11, 2007 at 10:13:32AM -0800, Eugene Grayver wrote:
> Hello,
>
> We are working on some systems that require high sampling rates. I am
> already using the Intel C++ compiler at the highest optimization ratio,
> but a lot of the blocks are very slow still. It appears that intel C++
Patrick Strasser wrote:
> Martin Dvh schrieb am 2007-12-07 18:28:
>
>> The second thing I want to do is detecting if multiple transmitters
>> (at different locations and frequencies) transmit the same radiostation.
>> With a single tuner I can capture all these signals at the same time.
>
> Provi
"Philip Heron" <[EMAIL PROTECTED]> wrote:
Martin Braun wrote:
RXing with the USRP simply doesn't work, though, neither with
usrp_rx_nogui.py nor with anything I could come up with. I get lots more
noise than expected and usually I get a very loud buzz or whistle which
is a lot louder than the
Martin Braun wrote:
RXing with the USRP simply doesn't work, though, neither with usrp_rx_nogui.py
nor with anything I could come up with. I get lots more noise than expected
and usually I get a very loud buzz or whistle which is a lot louder than the
TXed signal. Has anyone else had this probl
Hello,
We are working on some systems that require high sampling rates. I am
already using the Intel C++ compiler at the highest optimization ratio,
but a lot of the blocks are very slow still. It appears that intel C++
does not properly vectorize data type.
I have been replacing almost ev
It's actually reasonably simple to design your own hardware interface. All
you need are hw_source_c and hw_sink_c. I designed one for the
Nallatech/XtremeDSP from Xilinx. As long as you already have functions to
read and write to/from hardware, the blocks are actually very simple.
On Mon, Dec 10, 2007 at 12:34:07PM -0800, Brook Lin wrote:
> However, by given the lower bound and the upper bound of the freq range,
> next_freq can be get and "Failed to set frequency to", self.next_freq" is
> also get. and all the plots are the same, seems
> self.set_freq(self.next_freq) doesn't
On Tue, Dec 11, 2007 at 01:21:09PM +0100, Martin Braun wrote:
> Hi block developers,
>
> I've some questions regarding block development. First of all, what I did was
> take the gr-howto-write-xxx package, chuck out anything that was
> howto-specific and replace it with my own code. Is this how
FYI,
Eric
--- Begin Message ---
Hi all,
Is anyone here interested in helping out with extension module support
in Shed Skin? Shed Skin is an experimental Python-to-C++ compiler,
that takes implicitly statically typed Python code and converts it (at
the source level) to relatively readable C++. For
http://www.wired.com/science/discoveries/news/2007/12/time_hackers
--
Ramakrishnan VU3RDD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hi block developers,
I've some questions regarding block development. First of all, what I did was
take the gr-howto-write-xxx package, chuck out anything that was
howto-specific and replace it with my own code. Is this how everone else goes
along?
Next, I realized that if I don't want to call
Martin Dvh schrieb am 2007-12-07 18:28:
The second thing I want to do is detecting if multiple transmitters (at
different locations and frequencies) transmit the same radiostation.
With a single tuner I can capture all these signals at the same time.
Provided they are within 8 or 16MHz.
The
Martin Braun schrieb am 2007-12-10 17:06:
Hi,
RXing with the USRP simply doesn't work, though, neither with usrp_rx_nogui.py
nor with anything I could come up with. I get lots more noise than expected
and usually I get a very loud buzz or whistle which is a lot louder than the
TXed signal. Ha
26 matches
Mail list logo
