I am running a USRP source through a throttle to an FFT sink and a file sink. Last time I ran it, I got an "OSParam error", followed by a bunch of "D"s and the FFT was lagging and jumping. Any ideas as to what this is? My sample rate is 50M. Paul B. Huter
on 2013-11-17 23:57
on 2013-11-18 00:42
> Discussemail@example.com > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio You only ever need a "throttle" when you don't have hardware in the flow-graph pacing things. AT 50Msps, whatever your flow-graph is doing will be working *really, really* hard.
on 2013-11-18 00:50
As always, thank you, Marcus. I am thinking about getting rid of the graph (and throttle, now), and making another setup to run the output file from the original (through a throttle?) to the graph to look at smaller pieces. I want to be able to look at (say) 5MHz-10MHz, so my plan is to set the FFT to be 5MHz centered on 7.5MHz. However, I am not sure if that is correct. But - first step is to get my data. Thanks, again, Marcus. Paul B. Huter
on 2013-11-18 08:49
Don't use a throttle in a flow graph with a hardware source. A throttle block is software-limiting the number of samples that pass your flowgraph on average in a given time. You have an USRP that produces samples at a constant rate: Either this rate is significantly lower than your throttle rate, in which case throttle is superflous, or you'll run into problems because throttle is trying to throttle what it shouldn't throttle because the hardware defines how fast your samples must flow. For your file-sourced flowgraph, however, throttle is the right way to go -- but honestly, with 50Ms/s your PC will most likely get into such heavy work that it can't process everything in real-time (otherwise it could do it with live data, too) and your throttle doesn't do anything. I don't know your osparam error. But the D errors are likely caused by your computer being to busy to process the samples. Reduce the sample rate at the usrp, if you want to look at 10MHz of bandwidth, anyway.