Hi, I am working on a QPSK receiver (20 Mbps) for short packet reception and based on a preamble. In a first step I use a CW preamble for timing and coarse frequency acquisition, and with a differentially coded UW the receiver gets the frame synchronization and tries a second data-aided frequency adquisition (Mengali 1997) for the residual error left by the first frequency estimator. But the data-aided algorithm (128 symbols length) does not work well for small residual frequency offsets: i.e. normalized frequency offset = 5e-5. Do I need more training symbols to get better estimation resolution? Thanks in advance.
Fine frequency offset estimation
Started by ●March 16, 2012
Reply by ●March 16, 20122012-03-16
On Fri, 16 Mar 2012 17:00:15 -0500, nahemoth wrote:> Hi, > > I am working on a QPSK receiver (20 Mbps) for short packet reception > and > based on a preamble. In a first step I use a CW preamble for timing and > coarse frequency acquisition, and with a differentially coded UW the > receiver gets the frame synchronization and tries a second data-aided > frequency adquisition (Mengali 1997) for the residual error left by the > first frequency estimator. > > But the data-aided algorithm (128 symbols length) does not work well > for > small residual frequency offsets: i.e. normalized frequency offset = > 5e-5. Do I need more training symbols to get better estimation > resolution?128 symbols is my idea of a short packet!! Why do you need finer resolution? Why can't you continue to do frequency corrections on the body of the packet? What are you normalizing to? Symbol frequency? If so, getting 5e-5 error from 128 symbols sounds pretty good to me. (I'm not sure you need the CW preamble: it seems like a 10101010... preamble may be better -- but I haven't thought about this deeply). -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Reply by ●March 17, 20122012-03-17
>Hi, > > I am working on a QPSK receiver (20 Mbps) for short packet reception and >based on a preamble. In a first step I use a CW preamble for timing and >coarse frequency acquisition, and with a differentially coded UW the >receiver gets the frame synchronization and tries a second data-aided >frequency adquisition (Mengali 1997) for the residual error left by the >first frequency estimator.If the preamble is a pure CW, how do you do timing estimation?> But the data-aided algorithm (128 symbols length) does not work well for >small residual frequency offsets: i.e. normalized frequency offset =5e-5.>Do I need more training symbols to get better estimation resolution?Steve
Reply by ●March 17, 20122012-03-17
>On Fri, 16 Mar 2012 17:00:15 -0500, nahemoth wrote: > >> Hi, >> >> I am working on a QPSK receiver (20 Mbps) for short packet reception >> and >> based on a preamble. In a first step I use a CW preamble for timing and >> coarse frequency acquisition, and with a differentially coded UW the >> receiver gets the frame synchronization and tries a second data-aided >> frequency adquisition (Mengali 1997) for the residual error left by the >> first frequency estimator. >> >> But the data-aided algorithm (128 symbols length) does not work well >> for >> small residual frequency offsets: i.e. normalized frequency offset = >> 5e-5. Do I need more training symbols to get better estimation >> resolution? > >128 symbols is my idea of a short packet!! > >Why do you need finer resolution? > >Why can't you continue to do frequency corrections on the body of the >packet? > >What are you normalizing to? Symbol frequency? If so, getting 5e-5 >error from 128 symbols sounds pretty good to me. > >(I'm not sure you need the CW preamble: it seems like a 10101010... >preamble may be better -- but I haven't thought about this deeply). > >-- >My liberal friends think I'm a conservative kook. >My conservative friends think I'm a liberal kook. >Why am I not happy that they have found common ground? > >Tim Wescott, Communications, Control, Circuits & Software >http://www.wescottdesign.com >Hi Tim,>128 symbols is my idea of a short packet!! > >Why do you need finer resolution?a short packet for me is for example an Ethernet frame (aprox. 6400 symbols), then I need a precise frequency offset estimation in order to avoid a rotation of the symbol constellation.>Why can't you continue to do frequency corrections on the body of the >packet?I also have PLL to track phase changes, but it should have a small loop bandwidth (lower noise effect), so initial frequency estimation must be as precise as possible.>What are you normalizing to? Symbol frequency? If so, getting 5e-5 >error from 128 symbols sounds pretty good to me.Yes, I normalize to the symbol time. I get this error with the first estimator, but I would like to have a smaller error for feeding the PLL.>(I'm not sure you need the CW preamble: it seems like a 10101010... >preamble may be better -- but I haven't thought about this deeply).Yes, I mean a 10101010 preamble.
Reply by ●March 17, 20122012-03-17
>>Hi, >> >> I am working on a QPSK receiver (20 Mbps) for short packet receptionand>>based on a preamble. In a first step I use a CW preamble for timing and >>coarse frequency acquisition, and with a differentially coded UW the >>receiver gets the frame synchronization and tries a second data-aided >>frequency adquisition (Mengali 1997) for the residual error left by the >>first frequency estimator. > >If the preamble is a pure CW, how do you do timing estimation? > >> But the data-aided algorithm (128 symbols length) does not work wellfor>>small residual frequency offsets: i.e. normalized frequency offset = >5e-5. >>Do I need more training symbols to get better estimation resolution? > >Steve > >Sorry, I mean a 10101010 preamble.
Reply by ●March 17, 20122012-03-17
On 3/17/12 7:55 AM, nahemoth wrote:> > I also have PLL to track phase changes, but it should have a small loop > bandwidth (lower noise effect), so initial frequency estimation must be as > precise as possible.this area in the industry is not my forte. so i'm looking at it as a grad student in the 80s would. so you want to surmise the initial frequency from the preamble?>> What are you normalizing to? Symbol frequency? If so, getting 5e-5 >> error from 128 symbols sounds pretty good to me. > > Yes, I normalize to the symbol time. I get this error with the first > estimator, but I would like to have a smaller error for feeding the PLL. > >> (I'm not sure you need the CW preamble: it seems like a 10101010... >> preamble may be better -- but I haven't thought about this deeply). > > Yes, I mean a 10101010 preamble.so, if the clock frequency is sorta known but you have a few slightly different frequency candidates, then would you want something like a bank of matched filters that matches the preamble at these finely different clock rates? you pick the matched filter that resonates or lights up the most. from that you can pick a model preamble to cross-correlate the detected preamble with to get the phase down, and then you have both the clock and a frame origin. if your preamble is as short as 10101010, then i presume you need to disaallow that in the rest of the data. if you get this sequence of bits; 1010101, you must append a 1 to it and the receiver ignores it and continues on with the next bit. sorta like SDLC was s'posed to be. what do you do if the link is idle? or what are the "stop bits"? or is that never the case? -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
Reply by ●March 19, 20122012-03-19
On Friday, March 16, 2012 6:00:15 PM UTC-4, nahemoth wrote:> Hi, > > I am working on a QPSK receiver (20 Mbps) for short packet reception and > based on a preamble. In a first step I use a CW preamble for timing and > coarse frequency acquisition, and with a differentially coded UW the > receiver gets the frame synchronization and tries a second data-aided > frequency adquisition (Mengali 1997) for the residual error left by the > first frequency estimator. > > But the data-aided algorithm (128 symbols length) does not work well for > small residual frequency offsets: i.e. normalized frequency offset = 5e-5. > Do I need more training symbols to get better estimation resolution? > > Thanks in advance.Well since you are using a short packet, then capture the whole packet in memory and make as many passes as you need to get the frequency error reduced down to acceptable. Don't be struck in the paradigm that you have to do all of the processing on one pass in only one direction. Clay
Reply by ●March 19, 20122012-03-19
On 3/19/12 11:39 AM, clay@claysturner.com wrote:> On Friday, March 16, 2012 6:00:15 PM UTC-4, nahemoth wrote: >> >> I am working on a QPSK receiver (20 Mbps) for short packet reception and >> based on a preamble. > > Well since you are using a short packet, then capture the whole packet in memory and make as many passes as you need to get the frequency error reduced down to acceptable. Don't be struck in the paradigm that you have to do all of the processing on one pass in only one direction.so Clay, i am wondering, how do you know that you've received a preamble without some kind of continuous, first-in-first-out kinda process (that is simply monitoring the signal and lights up when a legit preamble has been received)? for the rest of the packet, i can see what you mean. i s'pose for really good timing precision, you have to align the 01 and 10 transitions (that are assigned quadrature phasor values) with a sorta comb in the time domain. and you can analyze that with multiple combs with slightly different spacing of the teeth. the preamble, as the OP has spec'd it, gives you a lot of that. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
Reply by ●March 19, 20122012-03-19
On Monday, March 19, 2012 2:36:03 PM UTC-4, robert bristow-johnson wrote:> On 3/19/12 11:39 AM, clay@claysturner.com wrote: > > On Friday, March 16, 2012 6:00:15 PM UTC-4, nahemoth wrote: > >> > >> I am working on a QPSK receiver (20 Mbps) for short packet reception and > >> based on a preamble. > > > > Well since you are using a short packet, then capture the whole packet in memory and make as many passes as you need to get the frequency error reduced down to acceptable. Don't be struck in the paradigm that you have to do all of the processing on one pass in only one direction. > > so Clay, i am wondering, how do you know that you've received a preamble > without some kind of continuous, first-in-first-out kinda process (that > is simply monitoring the signal and lights up when a legit preamble has > been received)? > > for the rest of the packet, i can see what you mean. i s'pose for > really good timing precision, you have to align the 01 and 10 > transitions (that are assigned quadrature phasor values) with a sorta > comb in the time domain. and you can analyze that with multiple combs > with slightly different spacing of the teeth. the preamble, as the OP > has spec'd it, gives you a lot of that. > > -- > > r b-j rbj@audioimagination.com > > "Imagination is more important than knowledge."Hello Robert, One may use received energy to know when a packet is started to be received. I did this with an INMARSAT recever. The up front preamble was incredibly short - something like 32 bits. I used circular queues and ran a bit behind real time throwing away data when I knew it was garbage. A standard INMARSAT unit watches the overhead channel and knows the timing info based upon it as to when reverse channel communications occur. I had a very simple receiver (per cust. spec.) that only tuned the reverse channel of interest. I didn't care if I lagged 100ths of mSec behind. The important thing for me was to not miss a message. It was a fun project. Clay
Reply by ●March 19, 20122012-03-19
On Mon, 19 Mar 2012 17:44:38 -0700 (PDT), clay@claysturner.com wrote:>On Monday, March 19, 2012 2:36:03 PM UTC-4, robert bristow-johnson wrote: >> On 3/19/12 11:39 AM, clay@claysturner.com wrote: >> > On Friday, March 16, 2012 6:00:15 PM UTC-4, nahemoth wrote: >> >> >> >> I am working on a QPSK receiver (20 Mbps) for short packet reception= > and >> >> based on a preamble. >> > >> > Well since you are using a short packet, then capture the whole packet = >in memory and make as many passes as you need to get the frequency error re= >duced down to acceptable. Don't be struck in the paradigm that you have to = >do all of the processing on one pass in only one direction. >>=20 >> so Clay, i am wondering, how do you know that you've received a preamble= >=20 >> without some kind of continuous, first-in-first-out kinda process (that= >=20 >> is simply monitoring the signal and lights up when a legit preamble has= >=20 >> been received)? >>=20 >> for the rest of the packet, i can see what you mean. i s'pose for=20 >> really good timing precision, you have to align the 01 and 10=20 >> transitions (that are assigned quadrature phasor values) with a sorta=20 >> comb in the time domain. and you can analyze that with multiple combs=20 >> with slightly different spacing of the teeth. the preamble, as the OP=20 >> has spec'd it, gives you a lot of that. >>=20 >> --=20 >>=20 >> r b-j rbj@audioimagination.com >>=20 >> "Imagination is more important than knowledge." > >Hello Robert, > >One may use received energy to know when a packet is started to be received= >. I did this with an INMARSAT recever. The up front preamble was incredibly= > short - something like 32 bits.=20 > >I used circular queues and ran a bit behind real time throwing away data wh= >en I knew it was garbage. A standard INMARSAT unit watches the overhead cha= >nnel and knows the timing info based upon it as to when reverse channel com= >munications occur. I had a very simple receiver (per cust. spec.) that only= > tuned the reverse channel of interest. I didn't care if I lagged 100ths of= > mSec behind. The important thing for me was to not miss a message. It was = >a fun project. > >ClayThe preamble, at least the early portion of it, is often designed to be able to be detected reliably with a frequency offset. Since the frequency uncertainty is by definition not known ahead of time, detecting the beginning of the packet happens before the offset is removed. So detecting the onset of the packet and storing the entire packet for offline processing as Clay suggested is often possible. Usually what prevents that is some maximum latency time or minimum response time for an ACK or other ARQ processing. Eric Jacobsen Anchor Hill Communications www.anchorhill.com
