GMSK receiver question, USRP tuning?

GNU Radio
1

Hi all,

I’m using benchmark_tx.py to transmit a GMSK sequence at 10MHz. As some
of you know, I’m trying to debug my own GMSK m-block receiver.

If I use test_usrp_standard_rx -F 10000000 (not the in-band receiver) to
capture the incoming signal and plot it, I get the graph on the top, and
if I dump the data coming out of the usrp1_source_c block when running
benchmark_rx.py -f 10000000, i get the bottom graph:
http://www.andrew.cmu.edu/user/gnychis/std_gmsk.png

I can successfully decode the transmission with my receiver using the
data output from usrp1_source_c and benchmark_rx.py … however I cannot
decode it using the samples from test_usrp_standard_rx.

So I’m wondering, what is benchmark_rx.py tuning on the USRP differently
than test_usrp_standard_rx? Of course, my goal is to duplicate this
action because my in-band code is also dumping data similar to the top
graph.

Thanks!
George

2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The default decim in the C++ program (which, IIRC, is deprecated) is 8.
What decim (what bitrate?) are you using for GMSK?

  • From the graphs, it looks like data from the C++ app is coming in
    about
    4x too fast.

  • -Dan

George N. wrote:

George

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHaCW8y9GYuuMoUJ4RAq6KAJ9x/+6giS5yTx0or7u+x7HdckW3jgCgtbfw
CaRXWRqSIabSD6HaqF2+loI=
=PZlq
-----END PGP SIGNATURE-----

3

The decimation should not affect the amplitude of the waves, right?
Which if you look at the graph, the GMSK receiver has ~4x the amplitude.

I agree that the decimation has affected what looks like the frequency,
but otherwise it should look the same and not affect my ability to
decode it. Something else seems different between test_usrp_standard_rx
and the GMSK receiver.

  • George
4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

George N. wrote:

The decimation should not affect the amplitude of the waves, right?
Which if you look at the graph, the GMSK receiver has ~4x the amplitude.

Actually, it may. Imagine you decimate by a factor of 4, that’s sort of
like adding every 4 samples together – amplitude grows by 4.

Now, I think there is (or there ought to be) some code that, at lower
decimation levels, shifts which bits of the register it outputs
(presumably, takes 2 more significant bits) to keep the amplitude
constant, but that code may not be there in your new version, or the
FPGA might do it differently that I imagine.

I agree that the decimation has affected what looks like the frequency,
but otherwise it should look the same and not affect my ability to
decode it. Something else seems different between test_usrp_standard_rx
and the GMSK receiver.

If the decimation factor is not correct there’s no way it’s going to
work.

  • -Dan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHaDWoy9GYuuMoUJ4RAqA+AKCxTe9CwmLMa+Q78nDQbVclZFeSLQCgzixz
s69aw69eVhxAf4j2cy1NUmo=
=MpH6
-----END PGP SIGNATURE-----

5

Actually, it may. Imagine you decimate by a factor of 4, that’s sort of
like adding every 4 samples together – amplitude grows by 4.

Ah, you’re right… so much to learn.

If the decimation factor is not correct there’s no way it’s going to work.

You nailed it on the head… I set my decimation to 64 to match
benchmark_rx.py and I am actually decoding my frames now!! Missed
something some simple… yessss :smiley:

grabs root beer ahhhh

  • George