Re: [Discuss-gnuradio] Simple Frame Detection

[Martin Braun]

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



> 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
> <mailto:address@hidden>>:
> 
>     On Sun, Feb 8, 2015 at 11:01 AM, Aditya Dhananjay <address@hidden
>     <mailto: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
> 
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>