MSK Loopback question

Hi Everyone,

I apologize ahead of time if this question seems stupid or if the answer
already exists somewhere and I haven’t been able to find it. I am
working
with a group that is attempting to recreate a 56kb/sec RF Modem
nominally
operating at 29MHz using Minimum Frequency Shift Keying. The end goal is
to
have the modem we are building using gnuradio and the usrp to
communicate
with one of the original hardware modems. As a proof of concept, I am
attempting to have my gnuradio code loopback on itself, to show that the
modulation-to-demodulation works as expected. I am attempting to do this
by
simply reading from a file, modulating, passing it through a channel
model,
demodulating, and writing to a new file. The problem I am encountering
is
that the write data comes out as garbage, and I’m not sure what I’m
doing
wrong. Here is the test code that I am trying to run:

from gnuradio import gr, gru, blks2
from gnuradio import usrp
from gnuradio import eng_notation
import copy
import sys
from gmsk import gmsk_demod

class my_top_block(gr.top_block):
def init(self):
gr.top_block.init(self)

self._file_name = 'testdata.dat'
self.src = gr.file_source(gr.sizeof_char, self._file_name, False)
self.unpacker = gr.packed_to_unpacked_bb(1, gr.GR_LSB_FIRST)
self.mod = gr.cpfsk_bc(.5, 1, 2) #Modulation index = .5 for MSK, 1 

bit
per symbol for BFSK, 2 samples per symbol
self.chanmod = blks2.channel_model()
#self.demod = gmsk_demod(2)
self.demod = gr.quadrature_demod_cf(1)
self.dec = gr.keep_one_in_n(gr.sizeof_float, 2) #2 Samples Per
symbol
self.slicer = gr.binary_slicer_fb()
self.repack = gr.unpacked_to_packed_bb(1, gr.GR_LSB_FIRST)
self.out = gr.file_sink(gr.sizeof_char, ‘outdata.dat’)
self.out2 = gr.file_sink(gr.sizeof_char, ‘testout.dat’)
self.connect(self.src, self.unpacker, self.mod, self.chanmod,
self.demod, self.dec, self.slicer, self.repack, self.out)
#self.connect(self.src, self.unpacker, self.repack, self.out)

if name == ‘main’:
tb = my_top_block()
try:
tb.run()
except KeyboardInterrupt:
pass

I originally tried this code, as seen from the commented section, using
the
demodulation method from gmsk included in blks2, as per my understanding
that demodulating a gmsk signal would be the same as an msk signal. When
this did not work correctly, I then searched the boards and found that
demodulating a BFSK signal had been done using the method I show above,
yet
I’m still recieving incorrect data on the write side. I would really
appreciate any help on this, as I’ve been trying to solve it on my own
with
no success. The testfile ‘testdata.dat’ consists of a single line of
text
‘This is a test file for GNU Radio’. Below are some examples of the
recieved
data that I have captured.

Run 1: Sensitivity = 1, Keep-N-In-One = 2

ZÚ HÚ H ]Ù Y [ Ù È S T YÚ

Run 2: Sensitivity = 20, Keep-N-In-One = 2

ZÚ HÚ H ]Ù Y [ Ù È S T YÚ

Run 3: Sensitivity = 1, Keep-N-In-One = 3

Ã<< ª "EURO £ŠÕ) EURO a3 #Õ

Run 4: Sensitivity =1, Keep All samples
g g çá a çá a æg çá æ g g ç á á ff af g ç


Thanks again for any help on this, I’m basically hitting my head against
a
brick wall.

-Dan

On Tue, 2009-03-24 at 11:59 -0400, Dan Tarr wrote:

Thanks again for any help on this, I’m basically hitting my head against a brick wall.

What is happening is that the data coming out of the demodulator no
longer has the same byte boundaries as the data going into the
modulator. Your output files are bit-shifted. In your script using the
quadrature demodulator, just take out the channel model. It will work
(I’ve verified this.)

The channel model contains a block (the fractional interpolator) that
can delay outputting samples during startup, that is, it might eat a few
bits on the input before it starts outputting samples. So, when you
have the channel model in place, the slicer bits are missing the first
four bits, and the repacker is placing the next four bits at the start
of the byte.

So that will get your artificial example working, but also understand
that during “real” reception, your receiver will need to handle
arbitrary bit offsets like this. Generally, in data transmission
systems, this is handled by having a frame sync word or flag, which,
when detected, indicates the next bit is the start of the data boundary.

By the way, I debugged this by attaching file sinks to each of the
blocks in your flowgraph and viewing them using Octave, where it became
obvious what was happening.

Johnathan