Preamble detection

>On 3/8/13 7:22 AM, radams2000@gmail.com wrote:
>> I would try taking the ratio of Pc/Pm instead of the difference. This
should make he decision independent of absolute level.
>>
>> If doing a division is hard, you could also take the difference of the
log() of Pc and Pm. Fast log approximation is pretty easy, maybe easier and
faster than doing a true divide.
>>
>
>dunno what Pc and Pm are (are they in that paper?) but comparing Pc/Pm 
>to some fixed threshold, a, should be the same as comparing Pc to a*Pm.
>
>no division or logs needed.  maybe there is a numerical problem when 
>levels get very low, but i would think you would have that anyway with 
>the ratio.
>
>-- 
>
>r b-j                  rbj@audioimagination.com
>
>"Imagination is more important than knowledge."
>
>
>

Very good idea, it should work much better.

On Sun, 10 Mar 2013 06:59:41 -0500, "nahemoth" <59513@dsprelated>
wrote:

>>On Fri, 08 Mar 2013 01:33:29 -0600, "nahemoth" <59513@dsprelated>
>>wrote:
>>
>>>Hi,
>>>
>>> I am working on a short packet transmission system which uses a QPSK
>>>preamble (01 10 01 10 01 10 ...) for timing and frequency offset
>recovery.
>>>I am trying to design a preamble detector in order to enable the
>estimators
>>>when a packet is coming.
>>>
>>>I tried a very interesting algorithm based on the spectral properties of
>>>the preamble:
>>>
>>>http://w3.ele.tue.nl/fileadmin/ele/MBS/SPS/Files/Posters/SPS30/SPSciacci.pdf
>>>
>>>It uses a notch filter to eliminate the spectral line of the preamble
>and
>>>compares the power of the received signal. When you receive the preamble
>it
>>>should cross a threshold. But at this stage there is no digital AGC, so
>the
>>>received signal amplitude can change, therefore the threshold also
>>>changes.
>>>
>>>I also read about using correlation for preamble detection (not for sync
>>>word detection), but I guess that this is more useful for detecting
>>>boundaries of the preamble. 
>>>
>>>Any suggestion for preamble detection?
>>>
>>>Thanks in advance.
>>
>>That's just a string of 180-degree  transitions at each symbol
>>boundary.   That's a good sequence for joint symbol timing and
>>frequency estimation, but it's not good for marking the beginning of
>>the message.
>>
>>How long is the sequence?   What is your maximum frequency
>>uncertainty? How long can the acquisition process take?
>
>I use this preamble for timing (signal oversampled 4 times) and frequency
>coarse acquisition, which uses 10 and 20 symbols, respectively. After the
>preamble, it comes a UW to estimate the phase and mark the beginning of the
>data. These algorithms are feed forward, and taking into account that the
>payload is quite long, I use two closed loops for timing and phase tracking
>in decision directed mode.
>
>>Sorting out a suitable preamble depends on a lot of variables and
>>requirements that will affect the design the of the preamble.   In
>>some systems no preamble is required, in other systems just a Unique
>>Word works well, in other systems the preamble contains multiple
>>sequences to facilitate things like coarse and fine synchronization.
>>You haven't given enough info to make any sort of determination about
>>whether the sequence you have is suitable or something else (or
>>nothing at all) would be better.
>
>I would like to use the preamble (180-degree  transitions at each symbol
>boundary) for packet detection. That is, the feed forward estimators are
>disabled until the preamble detector wakes up the receiver. Is is possible
>to discriminate the preamble from the data symbols and noise? It should
>detect the preamble in less than 30 symbols.

You can correlate on that sequence in the time domain and set some
thresholds for detection for whatever SNR range you intend to run in.
High SNRs tend to need less time than low SNRs.


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com