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

[Andy Walls]

On Mon, 2016-04-18 at 00:44 +0000, Landsman, Arik wrote:
> So the generic_mod() shifts the expected output by 50 samples to the right, 
> thus dropping 50 samples off the end. with this in mind, generating *two* 
> modulated vectors should do the trick: 
> 
> - generate an untrimmed sequence 2 preambles long (seq1)
> - generate another sequence 3 preambles long (seq2)
> - samples_per_preamble = (preamble_length_bytes * [8*2/mod_order] * sps)     
> #[8*2/mod_order] is the symbols_per_byte  for a given mod_order
> - in seq2, start_of_preamble = len(seq1) + <lost samples in generic_mod>
> - in seq2, end_of_preamble = len(seq1) + samples_per_preamble + <lost samples 
> in generic_mod>
> - lost_samples = seq1 - 2 * samples_per_preamble   #remainder after 
> subtracting all preamble lengths from seq1
> 
> this works, at least manually, and should be generic enough to work for all 
> cases, e.g. mod orders, preamble lengths, etc and regardless of the inner 
> workings of generic_mod (which is good in case it gets changed). 

Hi Arik:

Glad you found a way to make things easier.  Be advised that other
modulators (e.g. GFSK_mod, GMSK_mod) probably have different properties,
so what you've come up with may only work for QAM and PSK modulations
using generic_mod. 

Regards,
Andy

> Just need to python it into the Rx in a neat way.


> 
> 
> 
> 
> ________________________________________
> From: Landsman, Arik
> Sent: Sunday, April 17, 2016 7:44 PM
> To: Andy Walls
> Cc: address@hidden; address@hidden
> Subject: RE: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block 
> in qpsk
> 
> 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
>