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 <jay.radcli...@gmail.com >> <mailto:jay.radcli...@gmail.com>> 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: jay.radcli...@gmail.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 >> <mailto: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 >> <mailto: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 >> _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
