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