I'd like to second Kevin's notion that if anything is limiting your sample flow, it's the filter in the resampler. I don't know exactly what type of filter you chose, but I did the following (in python):
from gnuradio import filter as gr_filter
res = gr_filter.rational_resampler_ccf(200,1) # this is a 200-interpolation, floating point taps filter resampler
taps = res.taps()
print "length of taps is {:d}.".format(len(taps))
and it gave me 6600 taps.
Which is a lot. But then again... at these rates, I'd expect this to be computationally limiting on a beefy toaster, but not on a PC; for example, the following flow graph:
gives me the info that my trusty old subnotebook on battery does nearly 20 MS/s per second... I don't see how doing 48kS/s would become a problem quickly.
Which leaves us with your band pass filter; what's that?
I also don't have overly much trust in your "Packet Encoder" block; it's an ancient, hopefully-soon-to-be-dead Python block, which doesn't care or know about tagged streams etc. It might really be inefficient (but usually not to the point of limiting usefulness).
If you find /usr/(local/)share/gnuradio/examples/digital/ofdm/tx_ofdm.grx (or wherever GNU Radio is installed), you'll find, instead of that, something that does
and the header and payload streams are/can be then modulated with different constellations separately, and then, using "Tagged Stream Mux" be put together to one sample stream again. This should behave nicer! However, this is missing some kind of preambling. It might be worth it to simply "mux" in a "known preamble" stream from a vector source into the header bit stream, and use that for correlation on the receive side. Felix Wunsch built something like this a couple of days ago for some educational reason, I think he might share his wisdom if we ask nicely :)
Best regards,
Marcus
On 06/19/2016 10:46 PM, Kevin Reid
wrote:
On Jun 18, 2016, at 19:07, Paul S <address@hidden> wrote:Currently, I am trying to send data over ultrasound signals based on [1], using the audio sink and several sources. The problem is that I get often consecutive audio underruns (for several seconds straight). This is my flowgraph: <http://gnuradio.4.n7.nabble.com/file/n60547/flowgraph.jpg> The TunSource just reads data from a Tun-Device but I get these underruns with other blocks like the depicted Socked PDU or even a File Source, too (though not as frequently). So it basically boils down to (Byte?)-Source -> GFSK Mod -> Rational Resampler -> Frequency Xlating FIR Filter-> Audio Sink.[...]My assumption is that this is a "two clock problem" which I've read about in other posts.If you get this underrun when you are using a file source then you definitely do not have a two-clock problem, because the only clock in your flowgraph is the audio sink. That being the case, the only reason you should see underruns is if your CPU is not able to keep up, but that seems unlikely at your low sample rates. Check your system monitor for any cores running at 100% -- that would indicate that some one of your blocks is doing too much work. If that actually is the problem, the most likely culprit is your 200:1 resampler -- you could try breaking it up into multiple stages (e.g. interpolate by 20 then interpolate by 10) or using a FFT filter block to do the antialias filtering. _______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
