Re: [Discuss-gnuradio] pipes for today

[Damien B.]

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
> 
> 
> 
>