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.
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. On a general note- I think there should be two new block sets added: 1) A simple source block that provides samples in the appropriate format (float, complex, etc depending on the _f / _c etc) which generates as fast as possible and counts how many it generates in a second which gets output on a float output. 2) The same thing but a consumer. The idea being it would help diagnose blocks that end up putting out more or less data than they take in and whose decimation/interpolation rates aren't apparent. For instance, I have a decimating filter block that appears to actually be producing more samples than it takes in, causing the data to show up almost 30 seconds later on the scope which is set at the source's data rate. I'd love to put the timed consumer and timed provider blocks on either side and see how the in/out amounts compare. _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
