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 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.
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?
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?
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 R. wrote
output (0xAA 0xAA). I could probably tag the preamble in with the
Correlate Access Code?
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.
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.
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 M. wrote:
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.
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 R. wrote:
not readable binary stream (or readable hex stream). What I want is tcpdump
Jay,
like to have “Binary Slicer” → “File Sink” where the file contents are the
On Sun, Apr 27, 2014 at 9:28 PM, John M. [email protected]wrote:
block, you simply need to look for the presence of that tag to delineate
sink. This produces a data file. I didn’t know if someone could tell me a
Jay R.
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.
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.