> > USRP1: > - When we have a very simple flowgraph with a USRP1 sink connected to a > signal source and a USRP1 source connected to a WX scope- trying to shut > down the app using the close box causes the USB on the host system to > freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids > this problem. This problem exists on many flowgraphs, both GRC generated > and not- as far as I know it is limited to flowgraphs with both USRP1 > source and sink. This is a serious problem that has hit us on multiple > platforms and machines and causes unnecessary reboots. It is honestly an > unacceptable bug. > > My intuition here is that the "close" box doesn't cause the flow-graph to do the usual "finish the flow-graph" thing. Which means that the USRP1 is still streaming, and nobody is listening. For the 'power off' case, the USRP1 resets itself, and stops streaming data, and for ctrl-C, there's built-in logic that causes the flow-graph to shutdown "politely", and send a "please stop streaming" command to the USRP1. My suspicion about USB freeze-up is that the problem is due to the USB drivers in the kernel not doing the right thing with a deluge of data still arriving when nobody is actually listening. Which makes it a not-strictly-GnuRadio thing, and more of a USB drivers thing. Also, USB is inherently half-duplex, which may (somehow) play into scenarios like this--some kind of weird deadlock problem in the kernel USB drivers?
> USRP2 / UHD: > - With a similar flowgraph to the one above, changing the secs/div > causes the various traces to change phase relative to one another but > this doesn't happen when a USRP1 source is substituted. However, I > believe this is indicative of a deeper problem. We also see with the > same flowgraph and a slider that controls both the TX and RX frequencies > simultaneously, the flowgraph gets into a place where it seems to be > getting data but it no longer represents the state of what's coming in > and we also see the phase slippage. Long story short, create a flowgraph > with a UHD (USRP2) sink and source with a siggen at a fixed > frequency/amplitude, a wx scope, and a slider that sets the TX+RX > frequencies to the slider value. Direct connect the TX to the RX with an > SMA cable. Run the flowgraph and move the slider. At least on LFTX/RX > this seems to give various results. Do the same thing with a USRP1 for > comparison. To me it seems like UHD is losing data or the various paths > in the flowgraph get out of whack with eachother. There were no O's or > U's printed. > > We were trying to do a simple VNA in UHD and it just doesn't work as > expected, but switching it all over to a USRP1 its fine and dandy. > > > There's a tremendous amount of buffering inside a Gnu Radio flow-graph, which can easily cause *seconds* of latency. The buffer-sizing algorithm is complicated, and the buffering at any point in the graph is calculated by whatever is downstream, including decimators. I've long opined that the buffer-sizing (with its inherent latency) isn't actually correct all the time, but I admit to not having offered any meaningful solutions. I don't know whether UHD exacerbates this problem or not. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
