Hello Everyone,

Currently I am working on interesting problem which is related to implementation of #QPSK receiver. I made several solutions. However, still I am not fully satisfied with my algorithms for packet (burst signal) detection.  So I would like to check what you think would be most appropriate way to perform packet detection for this problem. Here is short description of problem:

There is need to develop receiver for bursty QPSK signal, every burst contains preamble + unique word header. Symbol rate of system is 1Msym/s, and sampling rate is 4Ms/s. Preamble is CW shifted signal (it is composed of 8 ('0110 0110') bytes - 64 samples). QPSK signals will perform 180 degrees shifts for every symbol (this is shown on constellation plot - figure below). This preamble sequence does not have good correlation properties. It is also important to emphasize that signal can have +-100KHz frequency offset.

I developed several algorithms for packet detection. Below is short description of each:

1. Most robust approach is based on parallel search.  With this approach I manage to perform packet detection and coarse frequency offset correction in same time. I split (multiply) input stream of samples into 9 streams. On each of these 9 streams I perform blind FO correction (-fmax/8, ... 0 ..., +fmax/8) and I perform cross-correlation between blindly corrected samples and known UW samples. I will detect several peaks, but one which has maximum value is one which performed blind frequency offset closest to real frequency offset. This algorithm is really robust however it is computationally intensive, and I would like to lower computational requirements. Also here I used UW for cross correlation as it has better correlation properties then preamble and I ignored preamble (not nice).

2. Second approach is based on Goertzel algorithm. Here I compute DFT power over 5 bins in which I expect preamble (CW) to have peaks due to frequency offset. This approach is less computationally intensive however it introduces false detection's especially in case when SNR is relatively low (7.6dB) and frequency offset is not ideally covered by 5 bins in which I performed Goertzel algorithm.

3. Third approach is based on 4 symbols delayed auto correlation correlation of input samples and energy variance estimation of input samples. After averaging values of auto correlation and variance of signal, if delayed auto correlation is fairly close to variance, I assume there is packet in the air (AutoCorrelation/Variance = 0.85). This is similar to Schmidl-Cox method that is used in WLAN systems. 

4. Forth approach could be based on RSSI envelope detection. However I did not implement it yet.

Do you have any advice's what would be more appropriate way of performing packet detection based on such 180 degree shift preamble? If you have any advice or reference please share it with me.

This is interesting reference that I found:

https://www.dropbox.com/s/mis5w5cdo2m95m9/10.1109%...

I also found that there was similar question 3-2 years ago, here on forum. However seems it did not led to constructive discussion and conclusion.

https://www.dsprelated.com/showthread/comp.dsp/201...

Thanks in advance. 

I assume that you don't have the option to change the preamble?

Hi Tim,

I do not have option to change preamble :(. But might be it is usefull, maybe I do not see how to use it in best way. 

Hi,

First, this is an interesting question.

Before suggesting another option I think you left out an important system parameter which is your target SNR. This depends on your data coding scheme and target PER. To support very low SNR more complicated algorithms will be required. It is all about good engineering.

As another option I may suggest running a DPLL which should converge during the preamble. Then execute the UW correlation. This solution can work for moderate SNR but might not be the best for very low SNR. When ever I see a CW preamble this is my first guess. This was the selected solution for old FSK systems for example.

For very low SNR your UW might not be long enough in any case for a reliable detection. I suggest seeing the required correlation length before adding FO. In severe cases where very low SNR is required an FFT per sample may be the only solution.

Good luck,

Moti

Hello Moti,

I would like to support operational region for SNR from 7dB up. I think this preamble is useful for coarse frequency offset estimation (I manage to make few nice algorithms for that). I have problem with packet detection. I would like to know how should I use it for packet detection. Maybe I am confused, but I do not think it would be good to trigger DPLL while packet is not detected. I assume that I should first detect packet and then trigger DPLL. 

In general I am interested what is the best way to do packet detection for such an system with CW as preamble. Maybe the best option is to use some kind of CFAR detector, or PAR detector based on envelope estimation?

Thanks,

Tarik

Hi Tarik,

A target SNR of 7dB is a moderate to high SNR in my opinion. For this SNR I think it can be safe enough to let the DPLL run with predefined limits on the expected frequency offset. While the DPLL is running, correlate with the UW. I do agree that when integrating this simple mechanism with other loops like AGC for example, the DPLL might not have enough samples to converge before the UW. Note that DPLL can still use gear shifting after detection to improve tracking after UW is detected. Before detection the loop bandwidth may be higher to support the fast convergence.

Another option is to use the cross correlation between the preamble symbols, as you proposed in option 3. The auto correlation should be calculated per sample for past symbols and produce a frequency estimation. the frequency estimation can then be used to correct the expected location of the UW which in tern be cross correlated to the UW. This will provide packet detection.

In any case I would not recommend implementing packet detection based on RSSI or energy alone. These mechanisms only work well in simulation. Once you try it in real life cases it will have too many false alarms.

Moti