[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Modulation problem ?

From: irene159
Subject: Re: [Discuss-gnuradio] Modulation problem ?
Date: Thu, 22 May 2008 08:46:48 -0700 (PDT)

Steven Clark-2 wrote:
> hex 00 and 01 are not visible characters, which is why you aren't
> seeing anything. Looking at the data, it looks like unpacked data (ie
> only the bottom bit of each byte is being used). If you convert it
> back to packed data, it may be you'll get your original message back.
> GNURadio has a unpacked_to_packed block for this purpose.

Why does GNURadio dqpsk demodulator code use unpack_k_bits_bb instead of
unpacked_to_packed_bb (since modulator uses packed_to_unpacked_bb)?

Indeed, it works much better replacing 
                self.unpack = gr.unpack_k_bits_bb(self.bits_per_symbol())
                self.unpack =
gr.unpacked_to_packed_bb(self.bits_per_symbol(), gr.GR_MSB_FIRST)
in the dqpsk demodulator code.

Demodulated data doen't look at all like original data but thanks to WinHex
I realised that the problem comes from bit shifting due to the filter. How
can I solve this? Would implementing simple_framer and simple_correlator
work? I have tried using them but I always get the following error:
ValueError: source and destination data sizes are different: x
(I have tried several input blocks). 

I am trying to connect my original file to the simple_framer and then to the
dqpsk modulator-demodulator. Then, I connect output to the simple_correlator
and then to my Resultat.txt file. Is this OK?

I've seen that the simple_correlator expects its input to be oversampled 8
times[1], but I don't know how I can do this... Could this be the solution?
I haven't seen oversampling in the gmsk-test.py[2] example but I haven't
been able to test either...

Thank you for your help!


View this message in context: 
Sent from the GnuRadio mailing list archive at Nabble.com.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]