Simple Frame Detection

GNU Radio
1

Hello,

I have been searching for a simple frame detection scheme for GNURadio
for a while, but everything I’ve found either doesn’t work or it is more
complicated than I expected.

What I needed was a block that would be searching for a predetermined
sequence used by the transmitter. While it doesn’t find this sequence,
it should give no output. Once it is found, it should output everything
that came after the sequence and discard the rest as “garbage”.

I tried using the simple framer and simple correlator. I created a
simple example that just took a random source, created a frame,
converted it to float, added some delay and then the correlator would
try to find the sequence. But this didn’t work. I got a constant zero
signal as output. The documentation on these blocks is really poor and I
couldn’t find any good example to clarify its usage.

On the other hand, I found plenty of examples of the header/payload
demux. But it seems more complicated than what I need. I don’t quite
understand the tags and streams portion of GNURadio and I am not sure on
what I should use as header data.

I have been trying to create a block that will try to check for a known
sequence in the incoming stream. Once it is detected, it will read the
next
L samples (L will be the message length defined by the user) and create
a
frame, which will be sent as a message. Everything before the detection
of
the known sequence will be ignored. The message will then be read by
further blocks as the received frame. Unfortunately, creating a message
passing block from scratch is turning out to be way harder than I
expected.

Is there any easier way to do this?

Thanks in advance,
Dan Franch

2

I’m very interested to learn the answer to this. I’m trying to do the
same thing right now.

Rich

3

Hello Daniel,

Are you using OFDM? If so, read on, otherwise disregard the rest of the
email.

Please look at the Schmidl-Cox synchronization method (Robust Frequency
and
Timing
Synchronization for OFDM). In a nutshell, the frame detection works like
this:

At the transmitter, the packet is created such that the first ODFM
symbol
has only the even numbered subcarriers filled up (with some random PN
sequence) and the odd subcarriers are set to 0. When this sequence is
passed through the IFFT block, the symbol (in the time domain) has its
first half identical to the second half. For example, if the FFT size is
1024, then in the time domain, the symbol has its first 512 samples
identical to the next 512 samples.

Therefore at the receiver, the detection becomes rather simple. The
incoming stream (in the time domain) is correlated against a 512-sample
delayed version of itself. A peak in this correlater output will
indicate
the boundary of the first symbol in the packet.

Hope this helps.

On Sun, Feb 8, 2015 at 10:21 AM, Richard B. [email protected]

4

On Sun, Feb 8, 2015 at 11:01 AM, Aditya D. [email protected]
wrote:

Hello Daniel,

Are you using OFDM? If so, read on, otherwise disregard the rest of the
email.

This sounds much less like a problem with regards on how to figure out
the synchronization but more about how to do it inside the confines of
GNU Radio.

The original post wants to discard everything before a preamble they
detect. Once preamble is detected, I assume a state machine down
stream will decode some information in the samples coming down which
says “The length of this transmission is 12345 symbols”. At this
time, the downstream block will send a message to the upstream block -
holding off the samples until it knows how many more to send down -
and finish up.

The feedback loop cannot be realized inside the flowgraph since
everything needs to be feed forward.

This is a great example of how someone may want to do RF burst
processing which may not necessarily be “real-time” but due to
dead-air or guard bands might be able to catch up on the processing if
you didn’t have to keep processing every last incoming sample -
especially at a higher sample rate. Moreover, it shows how blocks
could be used to message each other to create feedback loops and
convey downstream information to upstream processing elements which
may care - things like SNR estimation, timing information, etc.

I’m very interested to see how this all ends up.

Brian

5

On Mon, Feb 9, 2015 at 7:59 AM, Martin B. [email protected]
wrote:

convey downstream information to upstream processing elements which
may care - things like SNR estimation, timing information, etc.

Well, even if you’re not using OFDM, have a look at the codes (and the
ofdm_rx GRC example). We have state machines and feedback loops for
bursty reception, just as you described.

M

You can look at my work-in-progress branch where I’m taking the OFDM
frame
header/parser concept and generalizing it even more for easier use with
other non-OFDM modems:

https://github.com/trondeau/gnuradio/tree/packet_handling

Needs a bit more work, cleanup, and docs, though.

Tom

6

On 02/08/2015 05:27 PM, Brian P. wrote:

may care - things like SNR estimation, timing information, etc.
Well, even if you’re not using OFDM, have a look at the codes (and the
ofdm_rx GRC example). We have state machines and feedback loops for
bursty reception, just as you described.

M

7

On 02/09/2015 04:32 PM, Daniel Franch wrote:

Actually, I am not using OFDM. What I wish to do is way more simple than
OFDM, but at the same time there seems to be little to no documentation
on how to do it. I will attach a screenshot of how my system is
supposed to be.

Sorry, this is a bit much to read right now. However, we do have some
docs on doing these things, e.g.
http://gnuradio.org/doc/doxygen/page_packet_data.html. And I still
recommend understanding the OFDM demod, since the basic principles
should be the same no matter what.

Also, of course, Tom’s branch he mentioned, which expands this stuff.

Cheers,
M

8

Actually, I am not using OFDM. What I wish to do is way more simple than
OFDM, but at the same time there seems to be little to no documentation
on
how to do it. I will attach a screenshot of how my system is supposed
to
be.

The blocks I’ve programmed are the interleaver, the preamble detector
and
the deinterleaver. These last two are a tentative solution to the
problem
I’m having, but they still don’t work as expected. I gave up on trying
to
discard previous samples, as I feel this is not in the nature of
GNURadio
and its flow of samples. I’ve decided that something that outputs 0
while
it is not synchronized is good enough for me. Specially because later on
I
will test this system with a USRP, substituting that channel model by
UHD
source and sink.

The interleaver fills an N*M matrix line by line and once it is full,
sends
it column by column.

The deinterleaver works almost exactly the same but, for synchronization
reasons, waits for a threshold signal different from zero to start its
process. Once it starts it, it will descramble a number of samples equal
to
message length and then go back to a state where it waits for a
threshold
signal. When it is not deinterleaving, it outputs zero.

The preamble detector is the block responsible for sending that
threshold
signal. It starts in a state where it is waiting to detect the sent
preamble. Not with correlation. Simpler stuff. It just compares the
input
to the sequence. Each time there is a match, it increments a counter.
Once
the counter has a value equal to the preamble length, it will start
sending
the threshold signal. As there is a Pack K Bits block after the preamble
detector, I had to do some adaptations on this threshold signal. The
threshold signal has to be just one sample different from zero so the
deinterleaver can start working. As the output of the detector will be
packed in groups of 8 (the item size parameter), it sends 8 samples of
255
(the threshold signal) that will be packed together to form just one
threshold sample. Once the threshold signal is sent, the detector will
send
a number of samples of 8 * message length, as they will be packed
together
and form a proper message.

In order to send a threshold sequence of the proper size, the preamble
detector counts the number of zeroes it sends and adapts the threshold
sequence appropriately. For example: the item size is 8 and in case it
has
sent 18 zeroes while detecting a preamble sequence. In order to produce
only one packed sample different from zero, it will send 6 threshold
samples. The total output sequence will then be 24 samples long, that
will
be packed in 3 samples, where the first two will be zeroes but the last
one
will be different than zero and serve as threshold for the
deinterleaver.

I had to place the detector where it is, because if it was placed after
the
pack K bits block, the output from the detector would sometimes be
misunderstood as threshold by the deinterleaver. I’ve tried it before
and
the results were horrible even in some tests.

These setup I have now went really well in the unit tests. But once I’ve
tried to plug it in the whole system, the output is unpredictable. It
usually outputs lots of garbage. Sometimes it outputs the original
message
in a scrambled way and rarely it outputs the correct message.

I will attach the files for the preamble detector and the deinterleaver.
They are not well documented, sorry. I have been desperately working on
this during the weekend with barely no sleep, so the current form is the
result of lots of desperate work.

The codes and flowgraphs for the rest of the system can be found on my
github page, in the gnuradio folder:

2015-02-08 14:27 GMT-02:00 Brian P. [email protected]: