discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in


From: Landsman, Arik
Subject: Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in qpsk
Date: Sun, 17 Apr 2016 23:44:41 +0000

Hi Andy, 

Just a quick update - I changed sps from 10 to 5 to repeat your trimming 
procedure. Works like a charm. Certainly clear why you picked the 2nd preamble 
copy and not the 1st.. 

as expected correlation is not as strong with decreasing sps (assuming unmod 
preamble stays same size). 

Looks like it is possible to come up with an "auto-trimming" algorithm after 
all. if the number of lost samples (distorted, nulled, etc) is a function of 
sps, modulation order, and preamble length (and lost samples in 
digital.generic_mod that I guess just don't get shifted out), then exact 
placement can be calculated based on these parameters alone and some initial 
experimentation.  

i'll try experimenting, lets see if this holds :)

Best Regards,
Arik 


________________________________________
From: Landsman, Arik
Sent: Sunday, April 10, 2016 4:25 PM
To: Andy Walls
Cc: address@hidden; address@hidden
Subject: RE: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block 
in qpsk

Hi Andy,

Sorry for delayed response, the weekend finally arrived.. added some comments 
inline below. Your comments on zero-IF receiving are well taken - going to try 
a low-IF approach instead. This maybe the source of some phase noise issues I 
had on the hardware last night. Using the USRP N210 btw.

Overall, the aim in this case, at least for now, is three-fold:

- design / fine tune a QPSK Rx capable of performance similar to a diff-encoded 
Rx. Thus, at low SNR we could use non-diff and at higher SNR use diff encoding. 
Or possibly just non-diff if the latter outperforms.
- implement it as a testbed for encoding/networking algorithms for 
heterogeneous networking (big topic for 5G). Not an expert in networking, but 
we have RA's devoted to the topic. So ultimately the Tx-Rx network should work 
reliably enough to allow performance testing their algorithms without hardware 
bottlenecking the performance.
- on the personal front I am here for the long howl, as the topic is of 
personal interest. And contribute back into gnu-radio. Looks like this 
flowgraph is going in the "psk mod" footsteps as a non diff-encoding 
implementation. so if it appears feasible to create a python wrapper and a 
block i'll certainly start there. the big hurdle is the hand-tuning the 
corr_est block, which I'm going to contemplate a way to auto-cal it.

Best Regards,
Arik


 Andy Walls address@hidden
Sent: Tuesday, April 05, 2016 7:23 PM
To: Landsman, Arik
Cc: address@hidden; address@hidden
Subject: Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block 
in qpsk

On Tue, 2016-04-05 at 00:00 +0000, Landsman, Arik wrote:
> Hi Andy,
>
> Added a few comments inline (marked with "==" in lieu of a better email 
> client)..
>
> But overall corr_est works very consistently. I did have a few observations:

Hi Arik:

For my responses to the next two, I'm assuming that ultimately you'll be
working with a radio modem that sends bursts of energy and then cuts off
RF energy.   And that yoHi Andy,

Sorry for delayed response, the weekend finally arrived.. added some comments 
inline below. Your comments on zero-IF receiving are well taken - going to try 
a low-IF approach instead. This maybe the source of some phase noise issues I 
had on hardware last night. Using the USRP N210 btw.

Overall, the aim in this case, at least for now, is three-fold:

- design / fine tune a QPSK Rx capable of performance similar to a diff-encoded 
Rx. Thus, at low SNR we could use non-diff and at higher SNR use diff encoding. 
Or possibly just non-diff if the latter outperforms.
- implement it as a testbed for encoding/networking algorithms for 
heterogeneous networking (big topic for 5G). Not an expert in networking, but 
we have RA's devoted to the topic. So ultimately the Tx-Rx network should work 
reliably enough to allow performance testing their algorithms without hardware 
bottlenecking the performance.
- on the personal front I am here for the long howl, as the topic is of 
personal interest. And contribute back into gnu-radio. Looks like this 
flowgraph is going in the "psk mod" footsteps as a non diff-encoding 
implementation. so if it appears feasible to create a python wrapper and a 
block i'll certainly start there. the big hurdle is the hand-tuning the 
corr_est block, which I'm going to contemplate a way to auto-cal it.

Best Regards,
Arik


 Andy Walls address@hidden
Sent: Tuesday, April 05, 2016 7:23 PM
To: Landsman, Arik
Cc: address@hidden; address@hidden
Subject: Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block 
in qpsk

On Tue, 2016-04-05 at 00:00 +0000, Landsman, Arik wrote:
> Hi Andy,
>
> Added a few comments inline (marked with "==" in lieu of a better email 
> client)..
>
> But overall corr_est works very consistently. I did have a few observations:

Hi Arik:

For my responses to the next two, I'm assuming that ultimately you'll be
working with a radio modem that sends bursts of energy and then cuts off
RF energy.   And that you'll also be tuning the RF down-conversion
receiver such that the RF channel of interest is either completely above
or below the DC spike in the receiver.

== going to look into this, the N210 appears to be centered at DC with slight 
freq offset, I imagine due to discrete LO steps. Maybe tunning to an offset LO 
on the Rx and freq correcting on the DSP is a better approach.


> - changed feed-forward AGC num_samples = 128 (from 2048, to allow
> faster recovery with fading ch sim). The value has some effect on
> whether the first packet correlates or gets scrambled.

When you have a constant envelope waveform that's transmitted in bursts,
you should use a smarter AGC.

Some other oh b the ways:
- you may want to keep your bursts short relative to the fade variation
time.

== for sure, i.e. slow-fading

- you may want to perform AGC before the channel is frequency rotated
down to baseband.  For complex streams it doesn't matter so much, the
magnitude when passing through DC will still be OK; but for real streams
with components near DC, the instantaneous phase can really throw off
the magnitude computation.

== I suppose implying a non-zero IF into ADC. The N210 has a 400msps ADC, so 
ample of bw (btw, the bottle neck is actually the gigabit ethernet at 50msps 
max. and pc hardware). Just to clarify, do you mean  "freq rotating" as in what 
the FLL does when tracking? going to give it a go, I was having phase noise 
issues last night with hardware and I wonder if this was it.

- don't receive with your direct down-conversion receiver tuned to the
center of the channel of interest, the DC spike and images from I/Q
imbalance will mess with the envelope.

== yes point well taken, going to play with this next

So, one sketch for implementing a smarter AGC is, for example:
a) Write yourself a burst/energy detector block (ideally one that has a
message input port for noise floor estimate messages from another block)
that tags at least the start of a burst with a "rx_sob" tag.  You can
tag the "rx_eob" too, if it helps you.

(Be warned, writing a robust energy detector in gnuradio, where bursts,
including declaration windows, can span calls to work() or be completely
contained in a call to work, is not as easy as it first seems.)

b) Write a Feed Forward AGC block that is sensitive to the rx_sob tag
(and rx_eob tag if needed), looks at the envelop somewhere after the
tag, and then applies an appropriate gain until the next rx_sob tag is
encountered.  You at least want the preamble to have a nice, constant
envelope.

c) The extra mile: Write a noise floor estimation block that uses a
Forward Consecutive Mean Excision algorithm that periodically, on a
random subset of time domain samples in the interval, estimates a noise
floor threshold with a certain probability of false alarm.  It should
emit a message each interval that the burst detector block can use as
it's new threshold between signal and noise.

== this makes sense, although I am a bit green on actual implementation in C++ 
for now. I would have to write from scratch, not even a C++ IDE set up, using 
existing code for reference and with little to no knowledge on UHD. Might be a 
bit of a learning curve for now to be honest. e.g., your comment on work() and 
bursts in gnuradio went a bit over head.. :/

> - added FLL for course freq alignment, which you alluded to below.
> this works well only on a uniform spectrum, so repeating 4B 4B symbols
> was causing issues.. initially setting eb=0.5 and increasing the
> filter size helped a bit.

Well, in reality, in a system with bursts with a preamble, you can do
better than the FLL. You can implement a Data-Aided coarse frequency
correction.

One possible implementation:

1. As with the AGC above, use a burst/energy detector to mark the start
of burst with a rx_sob tag.

2. Since the first 6 bits (i.e. three symbols) of your preamble are
constant 1s, the slope of the phase, i.e. d(phi)/dt (aka the
instantaneous frequency) of the center of this group of three symbols
should be 0.  If d(phi)/dt is not 0, the properly scaled d(phi)/dt is
the carrier frequency offset of your signal.  You can write a block to
look for the rx_sob tag, and compute the frequency correction from the
preamble, and tag the burst with the freq_offset value.  The quadrature
demodulator block has the math you need for computing d(phi)/dt.

== I like this, and going to look for a way to implement rx_sob without writing 
a whole new block. Maybe that power-squelch block could help, it can gate noise 
to keep only the burst passed through. this leaves just tagging the stream on 
the first incoming sample, unless I'm oversimplifying..

3. Write a block that watches for the freq_offset tags, and then
performs a frequency rotation (aka spectrum rotation) of the signal in
the opposite direction by that amount, to remove the frequency offset.
The rotator block has the math you need to do the rotation.
Writing your own "rotate by tag value" block should be pretty easy.

== agreed :) as soon as I get my first one written. plenty to look into.

>
> - with tx_sps=10, setting *output* sps values for the polyphase block
> to anything other than 2, 5, or 10 results in a periodic phase
> rotation. my guess is the tagged packet was getting dropped at the
> polyphase output when tx_sps % osps != 0, i.e. tx_sps/osps should be
> an integer.

Proper tag propagation through rate changing blocks is a known
headahce. :(

I'm sure Tom wouldn't mind you testing out these fixes for him:

https://github.com/gnuradio/gnuradio/pull/758

== wouldn't mind at all, although I hear Tom was moving on to other endeavors 
soon.. Without debugging too much looks like with sps_in/sps_out = <some 
integer> works. I imagine the bigger issue here is actual rate change using 
interpolation. again, it feels like integer divisions is a good idea.


> I was half-expecting your answer on alternate way for generating the
> samples via a separate flowgraph :)  nevertheless thank you for the
> level of detail, as always.

The modulate vector block was supposed to eliminate the need for that.
Unfortunately, unpredictable filter delays mean that one almost has to
do something equivalent in effort to a separate flowgraph anyway, to
find the correct sample sequence. :(

== If the filter taps are fed into the block the delay should be known in the 
scope of the block. I wonder if this tuning process can be automated in some 
way. a bit off-the-cuff here, need to try it for myself first :)

> My plan is to change tx_sps to something other than 10, and try to
> repeat your calibration method (i.e. the symbol trimming). I hope you
> don't mind another question or two as I go along.

> Best Regards,
> Arik


> == very much appreciated, lots of good information here. Going to spend a bit 
> more time on it in the next couple of days.

You're welcome.

Regards,
Andy


________________________________________
From: Andy Walls address@hidden
Sent: Tuesday, April 05, 2016 7:23 PM
To: Landsman, Arik
Cc: address@hidden; address@hidden
Subject: Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block 
in qpsk

On Tue, 2016-04-05 at 00:00 +0000, Landsman, Arik wrote:
> Hi Andy,
>
> Added a few comments inline (marked with "==" in lieu of a better email 
> client)..
>
> But overall corr_est works very consistently. I did have a few observations:

Hi Arik:

For my responses to the next two, I'm assuming that ultimately you'll be
working with a radio modem that sends bursts of energy and then cuts off
RF energy.   And that you'll also be tuning the RF down-conversion
receiver such that the RF channel of interest is either completely above
or below the DC spike in the receiver.


> - changed feed-forward AGC num_samples = 128 (from 2048, to allow
> faster recovery with fading ch sim). The value has some effect on
> whether the first packet correlates or gets scrambled.

When you have a constant envelope waveform that's transmitted in bursts,
you should use a smarter AGC.

Some other oh b the ways:
- you may want to keep your bursts short relative to the fade variation
time.
- you may want to perform AGC before the channel is frequency rotated
down to baseband.  For complex streams it doesn't matter so much, the
magnitude when passing through DC will still be OK; but for real streams
with components near DC, the instantaneous phase can really throw off
the magnitude computation.
- don't receive with your direct down-conversion receiver tuned to the
center of the channel of interest, the DC spike and images from I/Q
imbalance will mess with the envelope.


So, one sketch for implementing a smarter AGC is, for example:
a) Write yourself a burst/energy detector block (ideally one that has a
message input port for noise floor estimate messages from another block)
that tags at least the start of a burst with a "rx_sob" tag.  You can
tag the "rx_eob" too, if it helps you.

(Be warned, writing a robust energy detector in gnuradio, where bursts,
including declaration windows, can span calls to work() or be completely
contained in a call to work, is not as easy as it first seems.)

b) Write a Feed Forward AGC block that is sensitive to the rx_sob tag
(and rx_eob tag if needed), looks at the envelop somewhere after the
tag, and then applies an appropriate gain until the next rx_sob tag is
encountered.  You at least want the preamble to have a nice, constant
envelope.

c) The extra mile: Write a noise floor estimation block that uses a
Forward Consecutive Mean Excision algorithm that periodically, on a
random subset of time domain samples in the interval, estimates a noise
floor threshold with a certain probability of false alarm.  It should
emit a message each interval that the burst detector block can use as
it's new threshold between signal and noise.


> - added FLL for course freq alignment, which you alluded to below.
> this works well only on a uniform spectrum, so repeating 4B 4B symbols
> was causing issues.. initially setting eb=0.5 and increasing the
> filter size helped a bit.

Well, in reality, in a system with bursts with a preamble, you can do
better than the FLL. You can implement a Data-Aided coarse frequency
correction.

One possible implementation:

1. As with the AGC above, use a burst/energy detector to mark the start
of burst with a rx_sob tag.

2. Since the first 6 bits (i.e. three symbols) of your preamble are
constant 1s, the slope of the phase, i.e. d(phi)/dt (aka the
instantaneous frequency) of the center of this group of three symbols
should be 0.  If d(phi)/dt is not 0, the properly scaled d(phi)/dt is
the carrier frequency offset of your signal.  You can write a block to
look for the rx_sob tag, and compute the frequency correction from the
preamble, and tag the burst with the freq_offset value.  The quadrature
demodulator block has the math you need for computing d(phi)/dt.

3. Write a block that watches for the freq_offset tags, and then
performs a frequency rotation (aka spectrum rotation) of the signal in
the opposite direction by that amount, to remove the frequency offset.
The rotator block has the math you need to do the rotation.
Writing your own "rotate by tag value" block should be pretty easy.


>
> - with tx_sps=10, setting *output* sps values for the polyphase block
> to anything other than 2, 5, or 10 results in a periodic phase
> rotation. my guess is the tagged packet was getting dropped at the
> polyphase output when tx_sps % osps != 0, i.e. tx_sps/osps should be
> an integer.

Proper tag propagation through rate changing blocks is a known
headahce. :(

I'm sure Tom wouldn't mind you testing out these fixes for him:

https://github.com/gnuradio/gnuradio/pull/758



> I was half-expecting your answer on alternate way for generating the
> samples via a separate flowgraph :)  nevertheless thank you for the
> level of detail, as always.

The modulate vector block was supposed to eliminate the need for that.
Unfortunately, unpredictable filter delays mean that one almost has to
do something equivalent in effort to a separate flowgraph anyway, to
find the correct sample sequence. :(


> My plan is to change tx_sps to something other than 10, and try to
> repeat your calibration method (i.e. the symbol trimming). I hope you
> don't mind another question or two as I go along.

> Best Regards,
> Arik


> == very much appreciated, lots of good information here. Going to spend a bit 
> more time on it in the next couple of days.

You're welcome.

Regards,
Andy

u'll also be tuning the RF down-conversion
receiver such that the RF channel of interest is either completely above
or below the DC spike in the receiver.

== going to look into this, the N210 appears to be centered at DC with slight 
freq offset, I imagine due to discrete LO steps. Maybe tunning to an offset LO 
on the Rx and freq correcting on the DSP is a better approach.


> - changed feed-forward AGC num_samples = 128 (from 2048, to allow
> faster recovery with fading ch sim). The value has some effect on
> whether the first packet correlates or gets scrambled.

When you have a constant envelope waveform that's transmitted in bursts,
you should use a smarter AGC.

Some other oh b the ways:
- you may want to keep your bursts short relative to the fade variation
time.

== for sure, i.e. slow-fading

- you may want to perform AGC before the channel is frequency rotated
down to baseband.  For complex streams it doesn't matter so much, the
magnitude when passing through DC will still be OK; but for real streams
with components near DC, the instantaneous phase can really throw off
the magnitude computation.

== I suppose implying a non-zero IF into ADC. The N210 has a 400msps ADC, so 
ample of bw (btw, the bottle neck is actually the gigabit ethernet at 50msps 
max. and pc hardware). Just to clarify, do you mean  "freq rotating" as in what 
the FLL does when tracking? going to give it a go, I was having phase noise 
issues last night with hardware and I wonder if this was it.

- don't receive with your direct down-conversion receiver tuned to the
center of the channel of interest, the DC spike and images from I/Q
imbalance will mess with the envelope.

== yes point well taken, going to play with this next

So, one sketch for implementing a smarter AGC is, for example:
a) Write yourself a burst/energy detector block (ideally one that has a
message input port for noise floor estimate messages from another block)
that tags at least the start of a burst with a "rx_sob" tag.  You can
tag the "rx_eob" too, if it helps you.

(Be warned, writing a robust energy detector in gnuradio, where bursts,
including declaration windows, can span calls to work() or be completely
contained in a call to work, is not as easy as it first seems.)

b) Write a Feed Forward AGC block that is sensitive to the rx_sob tag
(and rx_eob tag if needed), looks at the envelop somewhere after the
tag, and then applies an appropriate gain until the next rx_sob tag is
encountered.  You at least want the preamble to have a nice, constant
envelope.

c) The extra mile: Write a noise floor estimation block that uses a
Forward Consecutive Mean Excision algorithm that periodically, on a
random subset of time domain samples in the interval, estimates a noise
floor threshold with a certain probability of false alarm.  It should
emit a message each interval that the burst detector block can use as
it's new threshold between signal and noise.

== this makes sense, although I am a bit green on actual implementation in C++ 
for now. I would have to write from scratch, not even a C++ IDE set up, using 
existing code for reference and with little to no knowledge on UHD. Might be a 
bit of a learning curve for now to be honest. e.g., your comment on work() and 
bursts in gnuradio went a bit over head.. :/

> - added FLL for course freq alignment, which you alluded to below.
> this works well only on a uniform spectrum, so repeating 4B 4B symbols
> was causing issues.. initially setting eb=0.5 and increasing the
> filter size helped a bit.

Well, in reality, in a system with bursts with a preamble, you can do
better than the FLL. You can implement a Data-Aided coarse frequency
correction.

One possible implementation:

1. As with the AGC above, use a burst/energy detector to mark the start
of burst with a rx_sob tag.

2. Since the first 6 bits (i.e. three symbols) of your preamble are
constant 1s, the slope of the phase, i.e. d(phi)/dt (aka the
instantaneous frequency) of the center of this group of three symbols
should be 0.  If d(phi)/dt is not 0, the properly scaled d(phi)/dt is
the carrier frequency offset of your signal.  You can write a block to
look for the rx_sob tag, and compute the frequency correction from the
preamble, and tag the burst with the freq_offset value.  The quadrature
demodulator block has the math you need for computing d(phi)/dt.

== I like this, and going to look for a way to implement rx_sob without writing 
a whole new block. Maybe that power-squelch block could help, it can gate noise 
to keep only the burst passed through. this leaves just tagging the stream on 
the first incoming sample, unless I'm oversimplifying..

3. Write a block that watches for the freq_offset tags, and then
performs a frequency rotation (aka spectrum rotation) of the signal in
the opposite direction by that amount, to remove the frequency offset.
The rotator block has the math you need to do the rotation.
Writing your own "rotate by tag value" block should be pretty easy.

== agreed :) as soon as I get my first one written. plenty to look into.

>
> - with tx_sps=10, setting *output* sps values for the polyphase block
> to anything other than 2, 5, or 10 results in a periodic phase
> rotation. my guess is the tagged packet was getting dropped at the
> polyphase output when tx_sps % osps != 0, i.e. tx_sps/osps should be
> an integer.

Proper tag propagation through rate changing blocks is a known
headahce. :(

I'm sure Tom wouldn't mind you testing out these fixes for him:

https://github.com/gnuradio/gnuradio/pull/758

== wouldn't mind at all, although I hear Tom was moving on to other endeavors 
soon.. Without debugging too much looks like with sps_in/sps_out = <some 
integer> works. I imagine the bigger issue here is actual rate change using 
interpolation. again, it feels like integer divisions is a good idea.


> I was half-expecting your answer on alternate way for generating the
> samples via a separate flowgraph :)  nevertheless thank you for the
> level of detail, as always.

The modulate vector block was supposed to eliminate the need for that.
Unfortunately, unpredictable filter delays mean that one almost has to
do something equivalent in effort to a separate flowgraph anyway, to
find the correct sample sequence. :(

== If the filter taps are fed into the block the delay should be known in the 
scope of the block. I wonder if this tuning process can be automated in some 
way. a bit off-the-cuff here, need to try it for myself first :)

> My plan is to change tx_sps to something other than 10, and try to
> repeat your calibration method (i.e. the symbol trimming). I hope you
> don't mind another question or two as I go along.

> Best Regards,
> Arik


> == very much appreciated, lots of good information here. Going to spend a bit 
> more time on it in the next couple of days.

You're welcome.

Regards,
Andy




reply via email to

[Prev in Thread] Current Thread [Next in Thread]