# Simple Frame Detection **URL:** \ **Category:** GNU Radio\ **Created:** [February 7, 2015, 7:17pm UTC](https://www.ruby-forum.com/t/simple-frame-detection/234114 "2015-02-07T19:17:30Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [February 7, 2015, 7:17pm UTC](https://www.ruby-forum.com/t/simple-frame-detection/234114/1 "2015-02-07T19:17:30Z")
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 ---
**Author:** ![arachnd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@arachnd](https://www.ruby-forum.com/u/arachnd)\ **Post date:** [February 8, 2015, 4:23pm UTC](https://www.ruby-forum.com/t/simple-frame-detection/234114/2 "2015-02-08T16:23:25Z")
I’m very interested to learn the answer to this. I’m trying to do the same thing right now. Rich ---
**Author:** ![arachnd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@arachnd](https://www.ruby-forum.com/u/arachnd)\ **Post date:** [February 8, 2015, 5:03pm UTC](https://www.ruby-forum.com/t/simple-frame-detection/234114/3 "2015-02-08T17:03:28Z")
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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![arachnd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@arachnd](https://www.ruby-forum.com/u/arachnd)\ **Post date:** [February 8, 2015, 5:29pm UTC](https://www.ruby-forum.com/t/simple-frame-detection/234114/4 "2015-02-08T17:29:02Z")
On Sun, Feb 8, 2015 at 11:01 AM, Aditya D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![arachnd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@arachnd](https://www.ruby-forum.com/u/arachnd)\ **Post date:** [February 9, 2015, 2:59pm UTC](https://www.ruby-forum.com/t/simple-frame-detection/234114/5 "2015-02-09T14:59:55Z")
On Mon, Feb 9, 2015 at 7:59 AM, Martin B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](https://github.com/trondeau/gnuradio/tree/packet_handling) Needs a bit more work, cleanup, and docs, though. Tom ---
**Author:** ![arachnd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@arachnd](https://www.ruby-forum.com/u/arachnd)\ **Post date:** [February 9, 2015, 2:01pm UTC](https://www.ruby-forum.com/t/simple-frame-detection/234114/6 "2015-02-09T14:01:45Z")
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 ---
**Author:** ![arachnd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@arachnd](https://www.ruby-forum.com/u/arachnd)\ **Post date:** [February 9, 2015, 9:08pm UTC](https://www.ruby-forum.com/t/simple-frame-detection/234114/7 "2015-02-09T21:08:08Z")
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](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 ---
**Author:** ![arachnd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@arachnd](https://www.ruby-forum.com/u/arachnd)\ **Post date:** [February 9, 2015, 4:34pm UTC](https://www.ruby-forum.com/t/simple-frame-detection/234114/8 "2015-02-09T16:34:31Z")
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: > **[GitHub - franchenstein/tcc: Trabalho de conclusão de concurso - sistema de...](https://github.com/franchenstein/tcc)** > > Trabalho de conclusão de concurso - sistema de rádio definido por software. - GitHub - franchenstein/tcc: Trabalho de conclusão de concurso - sistema de rádio definido por software. 2015-02-08 14:27 GMT-02:00 Brian P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):