Re: [Discuss-gnuradio] Post Binary Slicer question

[Michael Ossmann]

My workflow in this case is to dump the output of Correlate Access Code
to a file and then write small Python programs to read that file.  Yes,
the tools within GNU Radio for handling this kind of thing are getting
better, but they still haven't been as useful (to me) as a few lines of
Python here and there for reverse engineering packet formats.

An example of a framework I might start with:

import struct

maxbytes = 255
data = open('/tmp/bits').read()
symbols = struct.unpack('1B'*len(data), data)
pkts = []

# extract an integer value from bitstream
def extract(start, len, bits):
        val = 0
        for i in range(start, start + len):
                val <<= 1
                val += (bits[i] & 1)
        return val

# make a big integer out of a packet's bits and display it in hex
def decode_packet(start):
        print("decoding packet %d" % (len(pkts)))
        pkts.append(extract(start, maxbytes*8, symbols)
        hexformat = "%0" + str(maxbytes * 2) + "x"
        print(hexformat % pkts[len(pkts) - 1])

# look for correlations flagged by correlate_access_code_bb (second bit set)
for i in range(len(symbols) - maxbytes*8):
        if symbols[i] & 2:
                print
                decode_packet(i)

You could modify this to print in binary instead of hex.  If you want to
display the preamble and/or sync word or not, you can subtract a fixed
value from the frame start index.  From there I start adding functions
as I figure things out.  For example: de-whitening, extracting length
fields (and using that length instead of maxbytes), manchester encoding,
error correction, xor packets against each other for differential
analysis, etc.

Mike


On Wed, Apr 30, 2014 at 09:22:54AM -0600, Jay Radcliffe 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