Replying to self- here's another case on the USRP2/UHD- TX Path: Sig Source -> UHD (USRP2) Sink
RX Path: UHD (USRP2) Source -> Band Pass Filter -> Scope Sink It seems that any kind of filter, even with appropriate calculation of the rate coming out of the filter taking into account decimation will yield a very delayed signal on the scope sink. The same problem does not happen on USRP1 when the sinks are swapped out and the sample rates adjusted appropriately. On 05/26/2011 07:29 PM, Brett L. Trotter wrote: > 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 > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio