Re: [Discuss-gnuradio] Post Binary Slicer question

[Andre Puschmann]

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 <address@hidden
> <mailto: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 <mailto:address@hidden>
>     LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
> 
> 
>     On Wed, Apr 30, 2014 at 9:09 AM, John Malsbury
>     <address@hidden <mailto: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 <mailto: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 <mailto:address@hidden>
>             LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
> 
> 
>             On Sun, Apr 27, 2014 at 9:28 PM, John Malsbury
>             <address@hidden <mailto: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
>                 <mailto: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
>                     <mailto:address@hidden>
>                     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>