Re: [Discuss-gnuradio] Simple Frame Detection

[Daniel Franch]

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: https://github.com/franchenstein/tcc 

2015-02-08 14:27 GMT-02:00 Brian Padalino <address@hidden>:

On Sun, Feb 8, 2015 at 11:01 AM, Aditya Dhananjay <address@hidden> 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

mpsk_sim.grc.png
Description: PNG image

deinterleaver_bb_impl.cc
Description: Text Data

deinterleaver_bb_impl.h
Description: Text Data

preamble_detector_bb_impl.cc
Description: Text Data

preamble_detector_bb_impl.h
Description: Text Data