Ah, thanks for that, I tried looking for a block that does this and figured it would be called something like "drop ..." or "discard ...".
This does work but it has it's one problem: My tagged stream to PDU block has to wait for all the bytes specified by the length_tag to come in before it forms the PDU. This means a packet will be delayed until the packet after it comes in. For example, if I have a 120 bit (15 byte) packet and I drop the first byte that comes that comes out of the descrambler I now have the tagged stream to PDU block receiving 14 bytes and waiting for the descrambler to emit that last byte (since my packet_len is still 15). The descrambler will only emit the last byte when the next packet shows up. On Tue, Mar 22, 2016 at 1:34 PM, Richard Bell <[email protected]> wrote: > 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 <[email protected]> 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 <[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 >> >> >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
