We have seen the same behaviour when trying to run overnight on the USRP1,
the flowgraph was just doing FM mod (LFRX in LFTX out) and it had a
graphical sink. Have the flowgraphs you used been made in GRC (ie could this
be a wx issue?).
Kieran
On Fri, Sep 10, 2010 at 5:32 AM, Marcus D. Leech wro
Hi Venkat,
A couple of things to try:
Try removing the tb.stop() call, lock will stop the flowgraph anyway.
You may need to 'disconnect' (essentially undo all the connect calls) the
path before recreating it. In the first instance try the
disconnect_all() method,
but from memory that had some issu
Hello All,
Attempting to sign in using a username I made a long time ago I seem to have
forgotten my password, I then attempted the password reset, followed all the
steps and attempted to login, still says my username / password is wrong
though. Weird.
Anyway, I was attempting to raise an issue o
For the usrp_am_mw_rcv.py; if you have an USRP you should just be able to
run it and it will work, ie (may need to be in the right directory?):
python usrp_am_mw_rcv.py
As for making in GRC I am afraid I cannot help much since I never use it. It
shouldn't be to hard to pick up the level of python
Hello all,
I am very interested in using mblocks to implement a TDMA system. All that
the information I can find (mainly old discuss posts) say that an
'acceptable solution' has not been found for communicating between the
mblock domain and the gr-block domain, I am curious as to what 'acceptable'
Hello all,
I am not sure whether this is strange behaviour or I am misunderstanding
what you can do with hier_blocks.
Problem is best described with an example:
from gnuradio import gr
class h_block(gr.hier_block2):
def __init__(self):
gr.hier_block2.__init__(self,
"h_blo
My advice would be to go read up on downsampling (especially anti-aliasing
filters). :)
The short answer is you need to low pass filter the incoming signal so when
you perform the down sampling you do not get aliasing of the signal.
Kieran
On Wed, Apr 1, 2009 at 10:47 AM, E. Ornelas wrote:
>
>
I don't actually know but I would assume keep_one_in_n is not actually doing
any Anti Aliasing for you, that may explain why you are getting a worse
result.
I recently implemented a system for doing what you are describing and it may
be easier for you to just increase the size of your FFT. My syst
Hello all,
I have some interesting behaviour using a stream_to_vector with a large
number of inputs items (12800).
The standard method of top_block.connect(), top_block.start() works fine but
when I try and perform the same operation after a top block has already been
started I get a sched error.
optfir.low_pass() returns the coefficients for the desired filter, use the
python len() method to get the number of taps.
Kieran
On Tue, Mar 24, 2009 at 11:08 AM, Francesco B. wrote:
>
> Is there any way to determine the order of the filter that
> optfir.low_pass()
> is generating in any given
On Wed, Mar 18, 2009 at 8:01 AM, Eric Blossom wrote:
>
> FWIW, your code works for me using the trunk as of r10628.
> That is, it prints "Reconfiguring h_block", and then hangs.
> (The hang is a different bug that will be addressed soon.)
>
Is the hang coming from the lock? Since it seems to be
Hello all,
Is the code designed so you can .lock() a individual hier_block2 and
reconfigure it without having to lock the overall top_block? IF you do have
to lock the top block, why?
The code below causes a seg fault on my 3.1.3 and 3.2 installations.
Sample code (http://pastebin.com/d413db7f7)
Which version of GNU Radio are you using? USRP2 support isn't in 3.1.3.
Kieran
On Mon, Feb 23, 2009 at 12:04 AM, Yc Park wrote:
> Last week, I succeed to get a response from my usrp2.
>
> After that, however, when I try usrp2_fft.py, or anything *.py related
> with usrp2, I get the "Import Erro
On Fri, Feb 27, 2009 at 9:14 AM, Bruce McGuffin wrote:
>
> ImportError: No module named gnuradio
Python doesn't know about the gnu radio libraries, did you do a make
install? (as root)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http:
at 1:08 PM, Johnathan Corgan <
jcor...@corganenterprises.com> wrote:
> On Wed, 2009-02-25 at 12:27 +1300, Kieran Brownlees wrote:
>
> > There are 3 threads running, I posted thread 1 before,
> >
> > Here is thread 2:
>
> When unlock() is called, it stops the flowgraph,
xb80b850f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#7 0xb80067ee in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb)
On Wed, Feb 25, 2009 at 12:23 PM, Johnathan Corgan <
jcor...@corganenterprises.com> wrote:
> On Wed, 2009-02-25 at 12:19 +1300, Kieran Brownlees wrote:
>
&
0x080edf8f in PyRun_FileExFlags ()
#17 0x080ee25a in PyRun_SimpleFileExFlags ()
#18 0x080595e7 in Py_Main ()
#19 0x08058962 in main ()
(gdb)
Kieran
On Wed, Feb 25, 2009 at 12:01 PM, Johnathan Corgan <
jcor...@corganenterprises.com> wrote:
> On Tue, Feb 24, 2009 at 2:54 PM, Kieran Brownlees
Hello all,
I seem to be having some strange behaviour when trying to lock and unlock
multiple times. I am using a USRP2 with the latest trunk of GNU Radio (just
compiled/update the firmware and updated FPGA code to the latest release),
and Ubuntu 8.10 Server as the OS.
The test script I am using
Hello all,
Seem to be experiencing an unusual bug with lock() and unlock(). The example
code can be found at http://pastebin.com/m1dd34f80
The problem seen is first time around the loop it works perfectly, the usrp
source is created connect then destroyed. The second time around the loop
however
Hey all,
I have a quick question about connecting and disconnecting a usrp within
the same python run.
My test program creates a top block, within the top block it attempts to
create a usrp.source_c(0), it then deletes the source goes to sleep and
waits for a KeyboardInterrupt, when this is de
20 matches
Mail list logo
