|
From: | Bastian Bloessl |
Subject: | Re: [Discuss-gnuradio] 802.15.4 Frame sync confusion |
Date: | Thu, 19 Oct 2017 10:33:37 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
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
SumitOn 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,
[Prev in Thread] | Current Thread | [Next in Thread] |