I've always used a "skip head" block after the descrambler to remove these erroneous items that come out. "skip head" will drop whatever number of items on the floor you tell it to and there after pass everything.
Rich On Tue, Mar 22, 2016 at 10:24 AM, devin kelly <dwwke...@gmail.com> wrote: > 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 <nowl...@gmail.com> 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/patch-gnuradio@gnu.org/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 <dwwke...@gmail.com> 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 >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
