Quantcast

Post Binary Slicer question

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Post Binary Slicer question

Jay Radcliffe
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.radcliffe@...
LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post Binary Slicer question

madengr
mkfifo my_fifo.bin
hexdump my_fifo.bin

Point your file sink to the my_fifo.bin and turn off the buffering.  It will then dump the data to the terminal in real time.

Lou
KD4HSO


Jay Radcliffe 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: [hidden email]<https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=[hidden email]>
LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post Binary Slicer question

John Malsbury
In reply to this post by Jay Radcliffe
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 <[hidden email]> 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.radcliffe@...
LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post Binary Slicer question

Jay Radcliffe
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: [hidden email]
LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02


On Sun, Apr 27, 2014 at 9:28 PM, John Malsbury <[hidden email]> 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 <[hidden email]> 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.radcliffe@...
LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post Binary Slicer question

Martin Braun-2
On 29.04.2014 22:43, Jay Radcliffe wrote:
> The protocol is unknown at this time.  I need to see the packets to
> figure some of this out.

Jay,

does the QT GUI Time Raster sink help you in any way?

M


> 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: [hidden email] <mailto:[hidden email]>
> LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
>
>
> On Sun, Apr 27, 2014 at 9:28 PM, John Malsbury <[hidden email]
> <mailto:[hidden email]>> 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
>     <[hidden email] <mailto:[hidden email]>> 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: [hidden email]
>         <https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=jay.radcliffe@...>
>         LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
>
>         _______________________________________________
>         Discuss-gnuradio mailing list
>         [hidden email] <mailto:[hidden email]>
>         https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post Binary Slicer question

madengr
In reply to this post by Jay Radcliffe
I guess I'm confused then.  I'm using the hex FIFO dump as I described to examine AX.25 packets one bit at a time.  Since the output of the slicer is a byte whose LSB is the only thing you are interested in, I believe you can use the unpacked-to-packed block to strip off the LSB from 8 bytes and pack those into a single byte; at least I'm using packed-to-unpacked to feed a binary file to a modulator so the reverse should work.  Run that into a FIFO and dump with xxd - bits.  Baudline is also handy for visually scrolling through the binary stream, although it's visually irritating with only one sample per symbol.

Lou


Jay Radcliffe 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: [hidden email]
LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post Binary Slicer question

John Malsbury
In reply to this post by Jay Radcliffe
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 <[hidden email]> 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: [hidden email]
LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02


On Sun, Apr 27, 2014 at 9:28 PM, John Malsbury <[hidden email]> 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 <[hidden email]> 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.radcliffe@...
LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio





_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post Binary Slicer question

Jay Radcliffe
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: [hidden email]
LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02


On Wed, Apr 30, 2014 at 9:09 AM, John Malsbury <[hidden email]> 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 <[hidden email]> 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: [hidden email]
LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02


On Sun, Apr 27, 2014 at 9:28 PM, John Malsbury <[hidden email]> 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 <[hidden email]> 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.radcliffe@...
LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio






_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

> _______________________________________________
> Discuss-gnuradio mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post Binary Slicer question

John Malsbury
In reply to this post by Jay Radcliffe
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 <[hidden email]> 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: [hidden email]
LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02


On Wed, Apr 30, 2014 at 9:09 AM, John Malsbury <[hidden email]> 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 <[hidden email]> 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: [hidden email]
LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02


On Sun, Apr 27, 2014 at 9:28 PM, John Malsbury <[hidden email]> 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 <[hidden email]> 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.radcliffe@...
LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio







_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post Binary Slicer question

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

> _______________________________________________
> Discuss-gnuradio mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post Binary Slicer question

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

> _______________________________________________
> Discuss-gnuradio mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post Binary Slicer question

Michael Ossmann
In reply to this post by 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 <[hidden email]>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: [hidden email]
> > > LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
> > >
> > >
> > > On Wed, Apr 30, 2014 at 9:09 AM, John Malsbury <[hidden email]>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 <[hidden email]>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: [hidden email]
> > >>> LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
> > >>>
> > >>>
> > >>> On Sun, Apr 27, 2014 at 9:28 PM, John Malsbury <[hidden email]>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 <[hidden email]
> > >>>> > 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: [hidden email]<https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=jay.radcliffe@...>
> > >>>>> LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> Discuss-gnuradio mailing list
> > >>>>> [hidden email]
> > >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >
>
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > [hidden email]
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post Binary Slicer question

Andre Puschmann-4
In reply to this post by John Malsbury
Hi,

By chance I am also working on an OOT module for a CC1100-based device.
I started out with a Python version as Michael also suggested, but now I
am migrating it to C++. I actually plan working on it during the EU
Hackfest next week in Karlsruhe.

John, Jay, perhaps we can create a single module for this as those chips
are very similar, something like gr-cc110x perhaps.

Cheers,
Andre



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



_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post Binary Slicer question

Andre Puschmann-4
Hi,

as I have mentioned a few weeks ago I was working on a GR module that
can be used for receiving and decoding messages sent from TI CC11xx
based devices.

I've now pushed a first version of it to my github repo [1]. It features
a 2-FSK receiver entirely built from stock GR blocks and a deframer with
a message output port that also does de-whitening and CRC checking.

Hope anybody else has use for it.

Cheers
Andre


[1] https://github.com/andrepuschmann/gr-cc11xx


On 02.05.2014 14:46, Andre Puschmann wrote:

> Hi,
>
> By chance I am also working on an OOT module for a CC1100-based device.
> I started out with a Python version as Michael also suggested, but now I
> am migrating it to C++. I actually plan working on it during the EU
> Hackfest next week in Karlsruhe.
>
> John, Jay, perhaps we can create a single module for this as those chips
> are very similar, something like gr-cc110x perhaps.
>
> Cheers,
> Andre
>
>
>
> On 30.04.2014 18:15, 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 <[hidden email]
>> <mailto:[hidden email]>> 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: [hidden email] <mailto:[hidden email]>
>>     LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
>>
>>
>>     On Wed, Apr 30, 2014 at 9:09 AM, John Malsbury
>>     <[hidden email] <mailto:[hidden email]>> 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
>>         <[hidden email] <mailto:[hidden email]>> 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: [hidden email] <mailto:[hidden email]>
>>             LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
>>
>>
>>             On Sun, Apr 27, 2014 at 9:28 PM, John Malsbury
>>             <[hidden email] <mailto:[hidden email]>>
>>             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
>>                 <[hidden email]
>>                 <mailto:[hidden email]>> 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: [hidden email]
>>                     <https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=jay.radcliffe@...>
>>                     LinkedIn + Resume:
>>                     http://www.linkedin.com/in/jradcliffe02
>>
>>                     _______________________________________________
>>                     Discuss-gnuradio mailing list
>>                     [hidden email]
>>                     <mailto:[hidden email]>
>>                     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> [hidden email]
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>



_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Loading...