discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] PSK modulation (along with packed vs unpacked byt


From: Almohanad Fayez
Subject: Re: [Discuss-gnuradio] PSK modulation (along with packed vs unpacked bytes)
Date: Sat, 23 Mar 2013 12:29:40 -0400

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

Al Fayez

On Mar 22, 2013 6:26 PM, "Nathan West" <address@hidden> wrote:
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:
from gnuradio import gr, digital

src_data = (range(0,256))

# blocks
src = "" src_data )
mod = digital.bpsk.bpsk_mod()
demod = digital.bpsk.bpsk_demod()
repacker = gr.unpacked_to_packed_bb(1, gr.GR_MSB_FIRST)
dst = gr.vector_sink_b()

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


It's output is *almost* correct:
(0, 0, 0, 0, 0, 0, 0, 20, 18, 128, 0, 129, 1, 130, 2, 131, 3, 132, 4, 133, 5, 134, 6, 135, 7, 136, 8, 137, 9, 138, 10, 139, 11, 140, 12, 141, 13, 142, 14, 143, 15, 144, 16, 145, 17, 146, 18, 147, 19, 148, 20, 149, 21, 150, 22, 151, 23, 152, 24, 153, 25, 154, 26, 155, 27, 156, 28, 157, 29, 158, 30, 159, 31, 160, 32, 161, 33, 162, 34, 163, 35, 164, 36, 165, 37, 166, 38, 167, 39, 168, 40, 169, 41, 170, 42, 171, 43, 172, 44, 173, 45, 174, 46, 175, 47, 176, 48, 177, 49, 178, 50, 179, 51, 180, 52, 181, 53, 182, 54, 183, 55, 184, 56, 185, 57, 186, 58, 187, 59, 188, 60, 189, 61, 190, 62, 191, 63, 192, 64, 193, 65, 194, 66, 195, 67, 196, 68, 197, 69, 198, 70, 199, 71, 200, 72, 201, 73, 202, 74, 203, 75, 204, 76, 205, 77, 206, 78, 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.


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.

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


reply via email to

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