Hi Paul,
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:
flowgraph
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
tx_ofdm packetizer
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 <p4sc...@yahoo.de> 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
> 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
