[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] pipes for today
From: |
Damien B. |
Subject: |
Re: [Discuss-gnuradio] pipes for today |
Date: |
Thu, 21 Apr 2005 10:18:37 +1000 |
Hi,
i think i just hit the same issue
>From this simple code (no display what so ever):
fg = gr.flow_graph ()
u = usrp.source_c (0, 64, 1, 0xf0f0f0f0, 0)
n = gr.null_sink(gr.sizeof_gr_complex);
fg.connect(u, n);
dest = usrp.sink_c (0, 64)
siggen = gr.sig_source_c (dest.dac_freq()/64, gr.GR_SIN_WAVE,100e3, 16e3,0)
fg.connect(siggen, dest)
fg.start ()
raw_input ('Press Enter to quit: ')
fg.stop ()
TX and RX part are working independently... but in the same code, i
have a whole bunch of messages.
* one (length can change)
_reap: usb->status = -108, actual_length = 3584
* a lots of:
_reap: usb->status = -108, actual_length = 0
* And then a lots of:
fusb: (rd status -108) Cannot send after transport endpoint shutdown
with a few Uu and U0 scattered around....
Cheers
Damien
On 4/21/05, Krzysztof Kamieniecki <address@hidden> wrote:
> Eric,
>
> Have you made any progress with this?
>
> I'm having a problem that may be related. The blocks are layed out like this.
>
> USRP Rx -> ... -> pipe
>
> gr_sig_source -> ... -> USRP Tx
>
> When running in gdb:
> 1. I wait for it to lockup
> 2. hit Ctrl-Z (to get into gdb)
> 3. type continue
> 4. more data is processed with a bunch of uU printed
> 5. software lockups again
> 6. goto 2
>
> When I hit Ctrl-Z the Tx thread always seems to be in ioctl in _reap. Is this
> normal?
>
> Attached is a file with bt's for each of the threads
> Thread 1 is Python/Wx, which seems to lockup
> Thread 2 seems to be the USRP Tx graph
> Thread 3 seems to be the USRP Rx graph
> Thread 4 is my pipe monitoring thread, which does not lockup
>
> Quoting Eric Blossom:
> > On Fri, Apr 08, 2005 at 04:10:20PM -0400, cswiger wrote:
> > > This is a curious behavior: if
> > >
> > > 1) Use a vector source at the head and the USRP at the tail all is OK
> > >
> > > 2) Use the pipe fd source at the head and a file sink at the tail all is
> > > OK
> > >
> > > but if
> > >
> > > 3) Use a pipe fd source at the head and the USRP (with a parallel file
> > > sink to monitor) at the tail data very slowly trickles into the file,
> > > much slower than the 1.6Msps that it should - UNTIL I close the process
> > > feeding the pipe, THEN it goes full blast and processes the backed up
> > > pipe A-OK.
> > >
> > > very interesting ;)
> >
> > Chuck, if you send me the code to test example (3), I'll take a look at it.
> >
> > Eric
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>