Hi Sean, Thanks for taking the time. You're definitely right about setting the parameters for the scrambler/descrambler, it seems like I can get my descrambled signal to look pretty close to my original signal or I can totally screw it up by changing the parameters. What I don't know is whether I can get the output of my descrambler to match the input of my scrambler.
With mask = 0x61 and seed = 0x7f I get (the first message is the input to my scrambler and the second is the output): length = 6 * MESSAGE DEBUG PRINT PDU VERBOSE * () pdu_length = 14 contents = 0000: d0 22 e7 d5 20 f8 e9 38 a1 4e 18 8c 47 30 *********************************** * MESSAGE DEBUG PRINT PDU VERBOSE * () pdu_length = 14 contents = 0000: 00 68 91 f3 6a 10 fc 74 9c 50 27 0c c6 23 *********************************** length = 7 * MESSAGE DEBUG PRINT PDU VERBOSE * () pdu_length = 14 contents = 0000: d0 22 e7 d5 20 f8 e9 38 a1 4e 18 8c 47 30 *********************************** * MESSAGE DEBUG PRINT PDU VERBOSE * () pdu_length = 14 contents = 0000: 06 d0 22 e7 d5 20 f8 e9 38 a1 4e 18 8c 47 *********************************** Neither of these messages are what I expect but length = 7 is pretty close. Does anyone know if it's possible to configure the scrambler and de-scrambler so the message I get out of my descrambler is exactly the same message I put into my scrambler? Thanks, Devin On Tue, Mar 22, 2016 at 11:45 AM, Sean Nowlan <[email protected]> wrote: > Devin, > > I haven't used the multiplicative scrambler/descrambler, although I've > used the additive scrambler. Both blocks use the same underlying LFSR > implementation. I noticed that there is some sensitivity in how the LFSR > parameters are specified. Judging by the parameters in your flowgraph, > you're using the polynomial: 0x61 --> 0b1100001 --> x^6 + x^5 + 1, which is > listed as an example in > gnuradio/gr-digital/include/gnuradio/digital/lfsr.h. This suggests a > degree=6 polynomial. However, according to [1] there is an implied 1 at the > highest order bit, so this is in fact a degree=7 polynomial: x^7 + x^6 + > x^5 + 1. Also in [1] it mentions that "length" is not the shift register > length but the length of the bit shift when a new bit enters the shift > register. Hence, length should be length=(degree - 1). > > I would modify your scrambler/descrambler parameters to be the following: > > Mask: 0x61 (degree=7) > Seed: 0x7f > Length: 6 > > Perhaps the junk you're seeing can be explained by the LFSR configuration. > > Note that I figured this out by trying to get a compatible LFSR > implementation for the CCITT polynomial x^9 + x^5 + 1, which has an LFSR > specification: > > Mask: 0x21 (degree=9) > Seed: 0x1ff > Length: 8 > > [1] https://www.mail-archive.com/[email protected]/msg00180.html > [2] http://cache.nxp.com/files/rf_if/doc/app_note/AN5070.pdf > > > On Mon, Mar 21, 2016 at 2:40 PM, devin kelly <[email protected]> wrote: > >> Hello, >> >> I'm a little confused on how to use the scrambler and descrambler, it >> looks like the descrambler always preprends a byte to my stream. When I >> run this flowgraph I get this from the message ports (the first message is >> the original message, the second message is from the descrambler): >> >> * MESSAGE DEBUG PRINT PDU VERBOSE * >> () >> pdu_length = 10 >> contents = >> 0000: d0 22 e7 d5 20 f8 e9 38 a1 4e >> *********************************** >> * MESSAGE DEBUG PRINT PDU VERBOSE * >> () >> pdu_length = 10 >> contents = >> 0000: 06 d0 22 e7 d5 20 f8 e9 38 a1 >> *********************************** >> >> >> I'm not totally sure what do about this, I've tried adding a delay block >> but that screws up my packet_len tags. >> >> Here's the original work function: >> >> { >> const unsigned char *in = (const unsigned char*)input_items[0]; >> unsigned char *out = (unsigned char*)output_items[0]; >> >> for(int i = 0; i < noutput_items; i++) { >> out[i] = d_lfsr.next_bit_descramble(in[i]); >> } >> >> return noutput_items; >> } >> >> I've also tried this work function (my approach here is to ignore the >> first byte out of the descrambler and then put junk into the last byte >> which would then be ignored on the next call to work() and yes I realize >> this isn't a general solution) >> >> { >> const unsigned char *in = (const unsigned char*)input_items[0]; >> unsigned char *out = (unsigned char*)output_items[0]; >> >> unsigned char junk; >> for(int i = 0; i < noutput_items + 8; i++) { >> if (i < 8) { >> junk = d_lfsr.next_bit_descramble(in[i]); >> } else if (i > noutput_items) { >> out[i - 8] = d_lfsr.next_bit_descramble(0xff); >> } else { >> out[i - 8] = d_lfsr.next_bit_descramble(in[i]); >> } >> } >> >> return noutput_items; >> } >> >> I run the flowgraph and now my last byte is junk (argh!) >> >> >> *********************************** >> * MESSAGE DEBUG PRINT PDU VERBOSE * >> () >> pdu_length = 10 >> contents = >> 0000: d0 22 e7 d5 20 f8 e9 38 a1 4e >> *********************************** >> * MESSAGE DEBUG PRINT PDU VERBOSE * >> () >> pdu_length = 10 >> contents = >> 0000: d0 22 e7 d5 20 f8 e9 38 a1 3d >> >> Does anyone have any advice on how to use to the scrambler and >> descrambler? Would writing my own message blocks that use the LFSR be a >> better approach? >> >> Thanks for any help, >> Devin >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
