Re: [Discuss-gnuradio] Post Binary Slicer question

[Andre Puschmann]

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 <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
>>