|
| From: | John Malsbury |
| Subject: | Re: [Discuss-gnuradio] Post Binary Slicer question |
| Date: | Wed, 30 Apr 2014 09:41:23 -0700 |
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
> >>>>> E-Mail: address@hidden<https://mail.google.com/mail/?view=cm&fs=1&tf=1&address@hidden>
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
> >>>>> 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
| [Prev in Thread] | Current Thread | [Next in Thread] |