Paul Creekmore wrote:
> The only package I've ever installed was 3.0.2. I've done so once with
> Synaptic Package Manager and once with apt-get.
>
> I see no mention of usrpm. Specifically, usrp_fft.py imports usrp.py,
> and usrp.py imports usrp_prims and usrp_dbid, neither of which exist in
>
The only package I've ever installed was 3.0.2. I've done so once with
Synaptic Package Manager and once with apt-get.
I see no mention of usrpm. Specifically, usrp_fft.py imports usrp.py,
and usrp.py imports usrp_prims and usrp_dbid, neither of which exist in
my installation.
--Paul
John
Eric Blossom wrote:
> Looks like the current Debian packages are out of date.
The "current" Debian packages are 3.0.2. The uber-secret location of
the release 3.1 experimental Debian packages has not yet been disclosed :-)
> Johnathan Corgan can give an update in a bit. I know he's busy during
Paul Creekmore wrote:
> When I attempt to run any python example script or utility that includes
> usrp.py, I get the following error message:
>
> Traceback (most recent call last):
> File "./usrp_fft.py", line 24, in ?
>from gnuradio import usrp
> File "/usr/lib/python2.4/site-packages/gnu
On Wed, Oct 10, 2007 at 11:46:41PM +0200, Martin Dvh wrote:
>
> Any other ideas?
>
This worked for me. It seems to be somewhat confused about the
address to source line mapping, but setting the breakpoint using the
address [ b *0x ] worked.
Eric
an tests]$ libtool --mode=execute gdb test_
On Wed, Oct 10, 2007 at 06:07:04PM -0400, [EMAIL PROTECTED] wrote:
> Ok, that works in principle, but I'm finding that I cannot sustain the
> same data rate as before on a fast dual core machine.
>
> I'm acquiring all 4 channels, and I'm doing both low-pass and high-pass
> filtering on all of th
Ok, that works in principle, but I'm finding that I cannot sustain the
same data rate as before on a fast dual core machine.
I'm acquiring all 4 channels, and I'm doing both low-pass and high-pass
filtering on all of them. I am also displaying 5 sinks simultaneously; 1
fft and 4 scopes.
I s
Eric Blossom wrote:
> On Wed, Oct 10, 2007 at 11:02:52PM +0200, Martin Dvh wrote:
>> Hi All,
>>
>> I am writing some new optimized SSE assembler routines.
>>
>> I am trying to debug them with gdb but are having the following problems.
>>
>> For some reason gdb doesn't find the source right, or show
On Wed, Oct 10, 2007 at 04:54:10PM -0400, [EMAIL PROTECTED] wrote:
> Well, this seems logical, and if so then we've finally stumbled on the
> point of the matter. So what's the fix? Is it a simple matter of
> extending the "definitions" to other decimations in the file Brian cites?
>
> thanks B
On Wed, Oct 10, 2007 at 11:02:52PM +0200, Martin Dvh wrote:
> Hi All,
>
> I am writing some new optimized SSE assembler routines.
>
> I am trying to debug them with gdb but are having the following problems.
>
> For some reason gdb doesn't find the source right, or shows the wrong source.
>
> W
On 10/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Well, this seems logical, and if so then we've finally stumbled on the
> point of the matter. So what's the fix? Is it a simple matter of
> extending the "definitions" to other decimations in the file Brian cites?
Either that or just do
On Wed, Oct 10, 2007 at 01:56:11PM -0700, Eric Blossom wrote:
>
> What does the output of usrp_fft -d 8 -f 587 look like?
Should be
> What does the output of usrp_fft -d 8 -f 587M look like?
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gn
Hi All,
I am writing some new optimized SSE assembler routines.
I am trying to debug them with gdb but are having the following problems.
For some reason gdb doesn't find the source right, or shows the wrong source.
When I set a breakpoint on float_dotprod_sse it thinks it is in file
../../../
On Wed, Oct 10, 2007 at 04:02:45PM -0400, Paul Creekmore wrote:
> When I attempt to run any python example script or utility that includes
> usrp.py, I get the following error message:
>
> Traceback (most recent call last):
> File "./usrp_fft.py", line 24, in ?
>from gnuradio import usrp
>
Well, this seems logical, and if so then we've finally stumbled on the
point of the matter. So what's the fix? Is it a simple matter of
extending the "definitions" to other decimations in the file Brian cites?
thanks Brian and Eric,
eric
On Wed, 10 Oct 2007, Brian Padalino wrote:
On 10/10/
On Wed, Oct 10, 2007 at 03:23:51PM -0500, Nirali Patel wrote:
> Hello everyone,
>
> I am trying to capture a few seconds of over the air HDTV on a file and then
> decode using the files in gr-atsc module according to the instructions in
> the README at gr-atsc/src/python. I am using the following
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Padalino wrote:
> The CIC filter has some bit-growth associated based on your decimation
> rate. This growth is deifned for decimations up to 128 in that file.
> It basically takes a different "slice" of the CIC "comb" section at
> the end.
>
>
On 10/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Can you give me an example? I've never worked with verilog code before.
>
> Also- this fix you are proposing- is it a simple scaling of gain that
> would be independent of decimation? Because as you can see from the
> following figure,
Can you give me an example? I've never worked with verilog code before.
Also- this fix you are proposing- is it a simple scaling of gain that
would be independent of decimation? Because as you can see from the
following figure, the amplitudes scale directly with the decimation for
values ab
Hello everyone,
I am trying to capture a few seconds of over the air HDTV on a file and then
decode using the files in gr-atsc module according to the instructions in
the README at gr-atsc/src/python. I am using the following command to
capture the signals off the air: /usrp_rx_cfile.py -R B -d 10
When I attempt to run any python example script or utility that includes
usrp.py, I get the following error message:
Traceback (most recent call last):
File "./usrp_fft.py", line 24, in ?
from gnuradio import usrp
File "/usr/lib/python2.4/site-packages/gnuradio/usrp.py", line 24, in ?
im
On Wed, Oct 10, 2007 at 03:14:21PM -0400, [EMAIL PROTECTED] wrote:
> The figures I showed you previously used std_4rx_0tx.rbf.
>
> To test with the standard std_2rxhb_2tx.rbf, I use the usrp_fft.py (with
> -S). I tested two cases, both with decimation 180, 1 kHz input, tuned to
> 0 Hz with 0 db
On Oct 10, 2007, at 2:49 PM, Matt Ettus wrote:
I think the problem is that the CIC interpolator needs to be stopped
before you change the rate. It may also need to be reset, but I don't
think so. I think the decimator had the same problem a while ago, and
it was fixed by stopping, changing the
The figures I showed you previously used std_4rx_0tx.rbf.
To test with the standard std_2rxhb_2tx.rbf, I use the usrp_fft.py (with
-S). I tested two cases, both with decimation 180, 1 kHz input, tuned to
0 Hz with 0 db gain. The first is with the voltage level of 1.4 V P-P
(which cuases the
On Wed, Oct 10, 2007 at 12:50:35PM -0400, [EMAIL PROTECTED] wrote:
> Eric-
>
> using -d 160 the problem goes away with this latest build, but remains for
> higher decimation values. For example, at decimation of 180, I can
> reproduce the problem. As a picture is worth a thousand words, I've p
I think the problem is that the CIC interpolator needs to be stopped
before you change the rate. It may also need to be reset, but I don't
think so. I think the decimator had the same problem a while ago, and
it was fixed by stopping, changing the rate, and then restarting. This
should be somew
On Wed, Oct 10, 2007 at 12:36:37PM -0400, George Nychis wrote:
>
>
> Eric Blossom wrote:
>
> >>>well as the basic [ $ time ] numbers. We may find wildy
>
> What times are we shooting for per-run? a minute? I know it will vary
> by machine, but I want to ask for a lower bound on time for re
does ./benchmark_loopback.py work?
If this works then the generic vs simd is not an issue for you.
If the loopback does not work I would try an svn update and rebuild. Eric
fixed
the issue with the simd code last week.
The original poster (dev) had some issues with the _tx and _rx but I have
bee
Eric-
using -d 160 the problem goes away with this latest build, but remains for
higher decimation values. For example, at decimation of 180, I can
reproduce the problem. As a picture is worth a thousand words, I've put
two jpg's up online at:
www.nd.edu/~ematlis/z.gnuradio/multi_scope_180
Eric Blossom wrote:
well as the basic [ $ time ] numbers. We may find wildy
What times are we shooting for per-run? a minute? I know it will vary
by machine, but I want to ask for a lower bound on time for results.
- George
___
Discuss-gnu
Thanks Brian.
Updates made.
Andrew
> -Original Message-
> From: Brian Padalino [mailto:[EMAIL PROTECTED]
> Sent: 10 October 2007 13:06
> To: Andrew Rose
> Cc: Francesco Marzano; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Cygwin build success
>
> On 10/10/07, Andrew Ros
Revisiting this topic, since it's been 3 weeks and I've heard back
nothing ... which probably means that everyone is too busy trying to
get release 3.1 out the door to deal with this issue? Should I just
enter this as a bug to be fixed?
My original observation is that the USRP's TX interp
On 10/10/07, Andrew Rose <[EMAIL PROTECTED]> wrote:
> In terms of publishing what I did, I was going to put my workarounds on the
> wiki, but I don't have an account, and I don't think I can make any
> modifications without one.
It hasn't been mentioned in a while, but guest/gnuradio should work
f
Francesco,
> Will you so kind to "publish" your "cooking recipe" ( "help yourself
and others ") ?
I assume it's the installation hacks that you want to know about? If
you read my previous two posts "Cygwin build problem: *", that - along
with the Cygwin instructions on the wiki - should give
Just to let you know that, having worked around the python & portaudio
problems, I seem to have a working Cygwin build. I don't have a USRP,
so that rules out most of the samples, but the audio samples all work
correctly, including oscope/fft. This includes using portaudio for the
spectrum invers
35 matches
Mail list logo
