Re: [Discuss-gnuradio] Post Binary Slicer question

[Michael Ossmann]

Oops.  I forgot part of it:

def advance(lfsr, num):
        for i in range(num):
                nextbit = (lfsr & 1) ^ ((lfsr >> 5) & 1)
                lfsr >>= 1
                lfsr |= (nextbit << 8)
        return lfsr


On Wed, Apr 30, 2014 at 10:38:54AM -0600, Michael Ossmann wrote:
>
> Cool!  In case either of you doesn't have this yet, here is an
> implementation of the CC11xx whitening algorithm:
> 
> # XOR the output of this with a packet
> def whitening(length):
>       lfsr = 0x1ff
>       white = 0
>       for i in range(length):
>               white <<= 8
>               white |= (lfsr & 0xff)
>               lfsr = advance(lfsr, 8)
>       return white
> 
> Not all implementations use the whitening feature, but I once reversed
> one that did.  The algorithm is described in the data sheet, but the
> description is lacking a couple details that I had to figure out.
> 
> Mike
> 
> 
> On Wed, Apr 30, 2014 at 09:15:11AM -0700, John Malsbury wrote:
> >
> > Jay,
> > 
> > As it turns out I am working on an out-of-tree module to work with the
> > CC1101, which I think I'll be able to release.  The number of possible
> > formats for the frame are relatively few if you know they are using CRC and
> > you know the packets aren't fixed length. (use_sequence_number?,
> > use_address_field?).  By definition, we know there will be length field
> > since these are not fixed length packets.  It would probably just make
> > sense to test the handful of options until CRC passes.
> > 
> > Of course, this changes if the device isn't taking advantage of CC1101s
> > packet handling functionality, and instead the MCU is providing more than
> > just the "payload".  In such a case, there is potentially larger feature
> > space for the frame.
> > 
> > I'll let you know about the CC1101 OOT.
> > 
> > -John
> > 
> > 
> > On Wed, Apr 30, 2014 at 8:22 AM, Jay Radcliffe <address@hidden>wrote:
> > 
> > > Maybe I should rephrase: I don't know the entire protocol. I know there is
> > > a preamble, and I know the sync word.  I know the packets are not fixed
> > > length, I know there is a CRC. This can all be determined from looking at
> > > the register settings for the CC1101 chip.  The format of the data portion
> > > of transmission I do not know. In order to reverse that I need raw data 
> > > for
> > > analysis.
> > >
> > > That is how I am handling it right now.  I stream the output of the
> > > Correlate Access Code to a file sink.  What is in that file though is 
> > > data,
> > > not readable binary stream (or readable hex stream). What I want is 
> > > tcpdump
> > > like output.
> > >
> > > Jay Radcliffe
> > > Twitter: @jradcliffe02
> > > E-Mail: address@hidden
> > > LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
> > >
> > >
> > > On Wed, Apr 30, 2014 at 9:09 AM, John Malsbury <address@hidden>wrote:
> > >
> > >> Jay,
> > >>
> > >> If you stream the output of the correlate access code to file, and you
> > >> leave them unpacked, Bit 1 being set will show where the sync word is (I
> > >> think the bit after).  Of course Bit 0 will be the data.  This assumes
> > >> you're using correlate access code, and not "correlate access code - 
> > >> tag".
> > >> This should allow you to store everything including the preamble.
> > >>
> > >> Also, if you don't know the protocol, how do you know what the preamble
> > >> is?
> > >>
> > >> -John
> > >>
> > >>
> > >> On Tue, Apr 29, 2014 at 1:43 PM, Jay Radcliffe <address@hidden>wrote:
> > >>
> > >>> The protocol is unknown at this time.  I need to see the packets to
> > >>> figure some of this out.
> > >>>
> > >>> Ideally, I would like to see the entire packet (including the preamble
> > >>> and sync word) to start to work my way to the format of the packets from
> > >>> there.  I am using the power squelch with the gate to limit the 
> > >>> captures to
> > >>> just when a signal is over a certain strength. In a perfect world, I 
> > >>> would
> > >>> like to have "Binary Slicer" -> "File Sink" where the file contents are 
> > >>> the
> > >>> binary stream (10101010101010 not to be confused for a binary file) or 
> > >>> hex
> > >>> output (0xAA 0xAA).  I could probably tag the preamble in with the
> > >>> Correlate Access Code?
> > >>>
> > >>> Jay Radcliffe
> > >>> Twitter: @jradcliffe02
> > >>> E-Mail: address@hidden
> > >>> LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
> > >>>
> > >>>
> > >>> On Sun, Apr 27, 2014 at 9:28 PM, John Malsbury <address@hidden>wrote:
> > >>>
> > >>>> Jay,
> > >>>>
> > >>>> Thanks for the inquiry.  Is there a specific protocol or format you are
> > >>>> trying to work with?  Are the frame size fixed in length or variable?  
> > >>>> The
> > >>>> answers to these questions will dictate whether you can use an existing
> > >>>> block or if you will need to write your own.
> > >>>>
> > >>>> Writing a block to parse things after the correlate access code block
> > >>>> is relatively straight-forward.  If you are using the (tag) version of 
> > >>>> that
> > >>>> block, you simply need to look for the presence of that tag to 
> > >>>> delineate
> > >>>> the start of a frame.
> > >>>>
> > >>>> -John
> > >>>>
> > >>>>
> > >>>> On Sun, Apr 27, 2014 at 4:27 PM, Jay Radcliffe <address@hidden
> > >>>> > wrote:
> > >>>>
> > >>>>> I have a question about handling data after binary slicing in the
> > >>>>> demodulation portion of handling a signal. Currently I am taking that 
> > >>>>> data
> > >>>>> and pushing it through the Correlate Access Code block then into a 
> > >>>>> file
> > >>>>> sink. This produces a data file.  I didn't know if someone could tell 
> > >>>>> me a
> > >>>>> block or method that will output the binary stream (or hex stream) to 
> > >>>>> a
> > >>>>> file or stdout for real-time view of the pack contents. Currently I 
> > >>>>> have
> > >>>>> some python code that converts that data file into binary/hex which 
> > >>>>> is not
> > >>>>> idea.
> > >>>>>
> > >>>>> Thanks,
> > >>>>>
> > >>>>> Jay
> > >>>>>
> > >>>>>
> > >>>>> Jay Radcliffe
> > >>>>> Twitter: @jradcliffe02
> > >>>>> E-Mail: 
> > >>>>> address@hidden<https://mail.google.com/mail/?view=cm&fs=1&tf=1&address@hidden>
> > >>>>> LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> Discuss-gnuradio mailing list
> > >>>>> address@hidden
> > >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >
> 
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio