Modulation problem?

GNU Radio
1

Hello,

I am testing QPSK modulation. To do so, I have created a text file that
I
modulate and demodulate with blks2impl dqpsk.py. The problem is the
resulting demodulated file, which I can not open:

“Could not open the file Resultat.txt.
gedit has not been able to detect the character coding.
Please check that you are not trying to open a binary file.
Select a character coding from the menu and try again.”

Help would be appreciated. Please find code files below.

Regards,
Irene

http://www.nabble.com/file/p17316660/Modulation.py Modulation.py
http://www.nabble.com/file/p17316660/Demodulation.py Demodulation.py

View this message in context:
http://www.nabble.com/Modulation-problem---tp17316660p17316660.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

This is not surprising. It is likely that you are getting some initial
garbage (non-standard-ascii characters) coming out, or that you have
some bit errors.

Don’t open it in gedit. Try:
python
f = open(‘Resultat.txt’)
d = f.read()
f.close()
print(len(d))
print(d)
(or if d is really long, print(d[:50]))

3

On May 19, 2008, at 8:15 AM, irene159 [email protected] wrote:

Please check that you are not trying to open a binary file.
Select a character coding from the menu and try again."

Help would be appreciated. Please find code files below.

I’m on a mobile so I can’t look at the files. But look at the file
sink type of your final output and the block that feeds it. My guess
is that its of type float or something where each float represents a
bit in “unpacked” binary format… Not the bit packed ASCII you are
expecting.

  • George
4

On Mon, May 19, 2008 at 05:15:12AM -0700, irene159 wrote:

Select a character coding from the menu and try again."

Help would be appreciated. Please find code files below.

Regards,
Irene

http://www.nabble.com/file/p17316660/Modulation.py Modulation.py
http://www.nabble.com/file/p17316660/Demodulation.py Demodulation.py

How about:

$ cat Resultat.txt

or

$ less Resultat.txt

5

Eric B. wrote:

Select a character coding from the menu and try again."
How about:

$ cat Resultat.txt

or

$ less Resultat.txt

Or :

od -tx1 Resultat.txt | less

to get hex bytes to see what’s going on at a binary level.

@(^.^)@ Ed

6

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.

7

Steven C.-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())
by
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
simple_correlator
(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!

Irene

[1]http://www.nabble.com/Help-using-simple_framer-and-simple_correlator-td1515282.html#a1538068
[2]http://noether.uoregon.edu/~jl/gmsk/

View this message in context:
http://www.nabble.com/Modulation-problem---tp17316660p17407191.html
Sent from the GnuRadio mailing list archive at Nabble.com.

8

Steven C.-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)? What
is
it used for?

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

Thanks to WinHex I realised demodulated data is bit shifted (due to the
filter). Implementing simple_framer and simple_correlator should solve
this
problem. I have tried using them but I get the following error:
ValueError: source and destination data sizes are different:
unpacked_to_packed_bb simple_correlator

I am connecting my blocks as follows:
Original text file > simple_framer > dqpsk modulator > Modulated.dat
file
Modulated.dat file > dqpsk demodulator > simple_correlator >
Resultat.txt
file.

I’ve seen that the simple_correlator expects its input to be oversampled
8
times[1], I think the code honors this requirement : dqpsk_mod
interp_fir_filter_ccf does oversampling and dqpsk.py samples_per_symbol
value is 8.

I haven’t found information for simple_framer/simple_correlator inputs
and
outputs and have no idea where my “ValueError: source and destination
data
sizes are different” problem comes from. Any hints would be appreciated!

Thank you for your help!

Irene

[1]http://www.nabble.com/Help-using-simple_framer-and-simple_correlator-td1515282.html#a1538068

View this message in context:
http://www.nabble.com/Modulation-problem---tp17316660p17420699.html
Sent from the GnuRadio mailing list archive at Nabble.com.

9

I haven’t found information for simple_framer/simple_correlator inputs and
outputs and have no idea where my “ValueError: source and destination data
sizes are different” problem comes from. Any hints would be appreciated!

Thank you for your help!

Irene

Make sure you know what type of stream each block wants for
input/output. When I see that ValueError that you are seeing, it is
usually because I am trying to connect a block that produces a stream
of floats into a block that expects a stream of 8-bit chars, for
example. Sometimes the last two letters of the name are a clue…
“foo_fc” for example, means that foo takes in floats and outputs
complex. Absent this information, you may have to dig into the code to
find the stream types.

10

I finally found the information I was looking for. For those who might
be
interested:

simple_correlator(payload_bytesize)
input : a stream of float
output : a stream of unsigned char

GNU Radio has some functions to convert stream type (ex :
uchar_to_float)

View this message in context:
http://www.nabble.com/Modulation-problem---tp17316660p17470809.html
Sent from the GnuRadio mailing list archive at Nabble.com.

11

Steven C.-2 wrote:

print(len(d))
print(d)
(or if d is really long, print(d[:50]))

When I tried this and
$ cat Resultat.txt
or even
$ less Resultat.txt
on the Terminal I didn’t see anything at first but copying what seemed
empty
into a file, I got:

George N. wrote:

I’m on a mobile so I can’t look at the files. But look at the file
sink type of your final output and the block that feeds it. My guess
is that its of type float or something where each float represents a
bit in “unpacked” binary format… Not the bit packed ASCII you are
expecting.

The file sink type of my final output is gr.sizeof_char and the block
that
feeds it is
objDemod = dqpsk.dqpsk_demod() whose output type is a stream of bits
packed
1 bit per byte (LSB):
objDemod = dqpsk.dqpsk_demod()
fg.connect(gr.file_source(gr.sizeof_gr_complex, “Modulated.dat”),
objDemod,

gr.file_sink(gr.sizeof_char,“Resultat.txt”))
Is this correct?
I have seen an example of almost identical code working with dbpsk
instead
of dqpsk[1].

However there might be an important difference (I am only a beginner and
I
am not really sure of the impact it can have). In DBPSK last block (the
block feeding the result file) is:
self.unpack = gr.unpacked_to_packed_bb(self.bits_per_symbol(),
gr.GR_MSB_FIRST)

While as for DQPSK, it is:
self.unpack = gr.unpack_k_bits_bb(self.bits_per_symbol())

Ed Criscuolo-2 wrote:

Result was :

0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01
0000040 00 00 00 00 00 00 01 01 01 01 01 01 01 01 00 00
0000060 00 00 00 00 00 01 00 00 00 01 01 01 00 01 00 00
0000100 01 01 01 00 00 01 00 01 00 01 00 01 00 00 01 00
0000120 00 00 00 00 00 01 00 01 00 00 01 00 00 01 01 00
0000140 00 00 00 01 00 01 01 00 00 01 00 00 00 01 01 00
0000160 01 00 00 01 00 01 01 00 01 01 01 01 00 00 00 00
0000200 01 00 01 00 00 00 00 00 01 00 01 00 00 01 00 01
0000220 00 00 00 00 00 01 01 01 00 00 01 00 00 01 01 00
0000240 01 01 01 01 00 01 01 00 01 00 01 00 00 01 01 00
0000260 00 01 00 01 00 01 01 00 00 00 01 01 00 01 01 01
0000300 00 01 00 00 00 00 01 00 00 00 00 00 00 01 01 00
0000320 01 01 00 01 00 01 01 00 00 01 00 01 00 01 01 00
0000340 01 01 00 01 00 01 01 00 00 00 01 00 00 01 01 00
0000360 00 01 00 01 00 01 01 01 00 00 01 00 00 01 01 01
0000400 00 00 01 01 00 00 01 01 01 00 01 00 00 00 01 00
0000420 00 00 00 00 00 01 00 01 01 00 01 00 00 01 01 00

…

I would like to be sure data has been modulated/demodulated correctly.
Isn’t there a way of opening this file as text?

Thank you for your help,
Irene

[1] - GNU Radio

–
View this message in context:
http://www.nabble.com/Modulation-problem---tp17316660p17345229.html
Sent from the GnuRadio mailing list archive at Nabble.com.