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
> > <jay.radcli...@gmail.com>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: jay.radcli...@gmail.com
> > > LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
> > >
> > >
> > > On Wed, Apr 30, 2014 at 9:09 AM, John Malsbury
> > > <john.malsb...@ettus.com>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
> > >> <jay.radcli...@gmail.com>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: jay.radcli...@gmail.com
> > >>> LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
> > >>>
> > >>>
> > >>> On Sun, Apr 27, 2014 at 9:28 PM, John Malsbury
> > >>> <john.malsb...@ettus.com>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 <jay.radcli...@gmail.com
> > >>>> > 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:
> > >>>>> jay.radcli...@gmail.com<https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=jay.radcli...@gmail.com>
> > >>>>> LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> 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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
