Hi Sylyain, thank you for your quick response.
Sylvain Munaut-2 wrote > Demodulation is not an exact process and the various loops in there > will take some time to lock and so the beginning will be corrupted and > your output won't be synced on the bytes boundaries of your input. Ok, this is a behavior I expected. Sylvain Munaut-2 wrote > Before modulation you need some kind of pre-processing to add > synchronization patterns and stuff like that and eventually some > padding data both at the beginning and the end to let the loop lock > and let stuff flush at the end if you want the full data to be > recovered, then you need to detect, align and remove all of that at > the output. For this issue I've tried [Packet Encoder] and [Packet Decoder]. 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. 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]. 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. 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 -- 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 [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
