PSK modulation (along with packed vs unpacked bytes)

GNU Radio
1

Twoish questions:

I’ve done a lot of code reading the last 2 weeks and worked on a custom
PSK
modulator (basically hierarchical 2/4psk). I’ve tested it at baseband on
everything seems good, so I’m hoping now to use something like
benchmark{rx,tx} to test it ota.

I’ve built a couple of sample flowgraphs. The first one is a BPSK
loopback:

flow graph

tb = gr.top_block()
tb.connect(src, mod, demod, repacker, dst)
tb.run()
print dst.data()

It’s output is almost correct:

207, 79, 208, 80, 209, 81, 210, 82, 211, 83, 212, 84, 213, 85, 214, 86,
215, 87, 216, 88, 217, 89, 218, 90, 219, 91, 220, 92, 221, 93, 222, 94,
223, 95, 224, 96, 225, 97, 226, 98, 227, 99, 228, 100, 229, 101, 230, 102,
231, 103, 232, 104, 233, 105, 234, 106, 235, 107, 236, 108, 237, 109, 238,
110, 239, 111, 240, 112, 241, 113, 242, 114, 243, 115, 244, 116, 245, 117,
246, 118, 247, 119, 248, 120, 249, 121, 250, 122, 251)

The first few bytes are 0’s, which as I understand has to do with the
RRC
filters, frequency correction, and possibly agc filter. Then it starts
at
128, 0 and increments by 1. I think I would expect it it to go from
0…255
but it looks like something else that’s also incrementing by 1 is
interleaved in there. Looking at the output before the repacker confirms
that each byte appears repeated twice, but the first instance has the
MSB
set to 1.

Doing a similar loopback in GRC with PSK Mod/Demod results in what I
would
expect (non-repeated bytes with MSB not set to 1). Would this be the
proper
way of using these blocks?

A related question, where is the packing being done in the benchmark_rx
path? The generic_demod does an unpack_k_bits, but doesn’t appear to
pack
them back up. In the benchmark_rx callback it looks like the packet is
already full of packed bytes, but I haven’t seen the unpacked_to_packed
in
pkt.py.

Thanks for any help,
-Nathan

2

I’ve done a lot of code reading the last 2 weeks and worked on a custom
PSK
modulator (basically hierarchical 2/4psk). I’ve tested it at baseband on
everything seems good, so I’m hoping now to use something like
benchmark{rx,tx} to test it ota.

demod = digital.bpsk.bpsk_demod()

190, 62, 191, 63, 192, 64, 193, 65, 194, 66, 195, 67, 196, 68, 197, 69,
filters, frequency correction, and possibly agc filter. Then it starts at
128, 0 and increments by 1. I think I would expect it it to go from 0…255
but it looks like something else that’s also incrementing by 1 is
interleaved in there. Looking at the output before the repacker confirms
that each byte appears repeated twice, but the first instance has the MSB
set to 1.

It turns out that this was a synchronisation/filter initialisation issue.
The bytes are packed 1 bit off so that the MSB of each byte is the LSB
of
the previous byte. It alternates because the input data is counting by
1s.
It just happens that for the particular set of filters in this path the
first bit is apparently eaten and at the end an extra bit is tacked on.

A related question, where is the packing being done in the benchmark_rx
path? The generic_demod does an unpack_k_bits, but doesn’t appear to pack
them back up. In the benchmark_rx callback it looks like the packet is
already full of packed bytes, but I haven’t seen the unpacked_to_packed in
pkt.py.

I think I found this in gr-digital/lib/digital_framer_sink_1.cc. There’s
some bit shifting to reassemble the payload in there.

Just posting an update so that no one spends needless time trying to
help
me and for anyone in the future that finds this in a search.

3

Thanks for the update Nathan, I’ve actually been trying to figure out
where
the payload reassembly occurs.

Al Fayez