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 <[EMAIL PROTECTED]> 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 > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio