Of course - I forgot whitening as a nother parameter to be tried. Thanks! -John
On Wed, Apr 30, 2014 at 9:38 AM, Michael Ossmann <m...@ossmann.com> 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
