Re: [Discuss-gnuradio] simple mod-demod combinations doesn't work

[Marcus Müller]

Dear Mark,


On 09.10.2016 14:54, MarkO wrote:
>
> For this issue I've tried [Packet Encoder] and [Packet Decoder].
I'd say: don't. These blocks are pretty deprecated by now, being rather
inflexible, slow python blocks. For now, try
http://gnuradio.org/doc/doxygen/page_packet_data.html .

>
> With these blocks I get a noise-free connection if i downsample the audio
> signal to 3 kHz, otherwise the data rate is to high for a stutter free
> transmission - audio underruns (aU) occur.
That sounds like a unrelated thing; aU's typically happen when you have
two clocks in your system, for example, one SDR device's sampling clock
and a soundcard sampling clock, as those never align perfectly, and one
can drift away from each other, or if you actually made a mistake
somewhere and the rate conversions between signal source hardware and
signal sink hardware don't actually result in the sink's clock rate.
You're not using a throttle block together with an audio sink, are you?
> Now the problem is that I only receive parts of the audio signal. What i
> hear is like: second 1, 5, 9, 15, 17, .. and it's not to fast, what i hear
> are parts of the audio file in one consistent stream . The only solution i
> found so far is to place a [Throttle] with 3kHz right before [Packet
> Encoder].
The console output will tell you that using throttle + audio sink =
evil. Throttle must never be used with hardware that has its own sample
clock.
Of course, you'll here your output as one consistent stream: your GNU
Radio flow graph is probably faster at producing samples from simulation
than your audio sink is at consuming them (which happens at your audio
sampling rate, e.g. 44.1 kHz or 48 kHz), so whenever the audio sink is
done consuming the last sample of the first burst, GNU Radio has already
calculated the output of the next burst. That's how it's supposed to
work – GNU Radio's job is to process samples as fast as it can; it
doesn't care, or even know, about how fast these samples should occur
related to "real world time".
>  This way I receive a nearly flawless stream. A few aU still come
> up from time to time, i think this is because of the [Throttle]
> implementation - usage of OS clock.
Exactly! :)
>
> For details please check out the attached grc file:
> QAM_audio_clean.grc
> <http://gnuradio.4.n7.nabble.com/file/n61679/QAM_audio_clean.grc>  
>
> I'm pretty sure that [throttle] isn't the correct solution. Is there a neat
> way to solve this?
>
> Regards,
> Markus
Best regards,
Marcus
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/mod-demod-issues-tp61674p61679.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio