Re: [Discuss-gnuradio] 802.15.4 Frame sync confusion

[Bastian Bloessl]

Hi,

On 10/19/2017 09:00 AM, Sumit Kumar wrote:
> Yes but even to get the chip sequences, which are nothing but bits, the 
> incoming complex samples have to be decoded i.e. OQPSK demodulation.
>
> I saw MATLAB implementation by Rice University as well in the latest 
> release of MATLAB 2017b (they have included a 802.15.4 toolbox)
>
> All of them employ the same technique i.e. first do a OQPSK demodulation 
> and then find preambles.
>
> I was wondering why not do auto correlation or cross correlation of 
> incoming complex samples as there is a repetition of samples in the 
> beginning.

Currently, the receiver looks like this:

IQ -> FM demodulation -> clock recovery (extract chips) -> search for 
the chip sequence of the preamble.

It's only one simple way to do it. I'm sure you could get higher 
performance with more complicated algorithms that consider the signal at 
an earlier stage, i.e., you could work with the baseband signal or the 
signal after FM demodulation. However, both approaches would increase 
(at least) computational complexity. It's a trade-off.

Best,
Bastian



> Sumit
>
> On Wed, Oct 18, 2017 at 3:50 PM, Bastian Bloessl <address@hidden 
> <mailto:address@hidden>> wrote:
>
>     Hi,
>
>     On 10/18/2017 01:24 PM, sumit kumar wrote:
>
>         Hi,
>
>
>         If my understanding is correct, most of the 802.15.4 receiver
>         implementations perform frame synchronization i.e. find the
>         start of the frame using the preambles which are nothing but 8
>         zeros(each of which is further converted to 32 bit chip).
>
>         This is done after the OQPSK symbols (complex samples) are
>         already decoded to bits. Same does the gr-ieee 802.15.4
>
>
>     It's actually working with the chip sequences not the data bits.
>     When the receiver is not synchronized is searches for the chip
>     sequence that corresponds to the zero data bits, i.e., the preamble.
>     Once the sequence is found (when the chip sequence matches
>     reasonably well), it continues to decode chip sequences with the
>     known alignment (and looks for the SFD data bits).
>
>     That means the algorithm works already on a rather deep layer. I'm
>     sure it could be much improved. It is just a simple approach that
>     presents a tradeoff between performance and complexity (in terms of
>     CPU time and implementation complexity).
>
>     Best,