ATSC Magic coupling constant

GNU Radio
1

Hello all,

I’m working on fixing up gr-atsc and I have been working on a little
problem for a while now, there is a constant (
FPLL_BTLOOP_COUPLING_CONST )
that sets the reference for an AGC, the value is ( 2.5 * 3.125 ) and is
literally defined as “Magic”, so it seems to be a value that “just
works”.
With that value the AGC filters the real input and then this is
multiplied
by a NCO part of a PLL. This puts the value of the +/- 5 timing sync
levels
at about +/- 5. The problem is when I pass samples though the AGC and
then
do ‘complex’ multiplication on them the +/- 5 values end up at about +/-
7.
I’m not sure why but it seems like the values coming out of the complex
multiply are not the same as the real multiply. The original code is:

nco.sincos (&a_sin, &a_cos); // compute cos and sin
float I = input * a_sin;
float Q = input * a_cos;

My code is:

nco.sincos (&a_sin, &a_cos); // compute cos and sin
gr_complex result = (gr_complex(input_real, input_imag) *
gr_complex(a_cos,
a_sin));
float I = result.real();
float Q = result.imag();

I is larger in my version and so the equalizer and slicer fail
downstream.
I built a coherent AGC into the sync timing loop but it still fails with
large gain differences.

My question is whether there is anyone around who worked on gr-atsc who
could give me a hint as to how the “Magic coupling constant” was derived
in
the first place so I can build a new one so I don’t have to rebuild the
equilizer.

Thank you
Andrew D.

2

On Tue, Jul 30, 2013 at 5:55 PM, Andrew D.
[email protected]wrote:

I’m not sure why but it seems like the values coming out of the complex
gr_complex(a_cos, a_sin));
equilizer.

I can’t help you with your MAGIC, but if you say the real signal is
mixed
then filtered in the original code that works, whereas it is just mixed
with your code - maybe it’s just off by a sqrt(2) since you’re filtering
off your image after the NCO happens and losing 1/2 power?

I did notice that sqrt(2)*5 = 7 - so maybe making your NCO a little less
powerful might bring you to the correct power levels since I am assuming
you aren’t filtering in your chain since there is no image to filter
out?

Brian

3

The filter doesn’t seem to decrease the pass-band signal, also I’ve
tried
adding back the unneeded filter just to be sure and it doesn’t change
anything. I will try the off by sqrt(2), that might put me back in
range.
Also my NCO is the same in both cases and I believe it is normalized to
1.

The ATSC signal randomly changes between +/- 1,3,5,7 so the average
power
should be 4 and when using this as the reference this puts my signal
were
it should be and at the same level as the old code with the average
power
set to 7.8125 ( written in code as 2.5 * 3.125 for some reason ) yet it
still must be off by just enough to mess up the slicer in the viterbi
but
not the equalizer as it locks on correctly ( it is very finicky ).

Thanks for the idea, I will try it tomorrow when I get back to the test
machine ( which is powerful enough to be within reach of real-time
decoding
if I get this figured out :slight_smile:
Andrew

4

Ok, I tried the off by sqrt(2) and it put me close but now the
bit_timing
_loop is running short on data again, which as a disseminator means it
probably cant find a good sync for timing and just eats all its input
samples. So I pushed my changes to where i’m at now to github, could you
see if that compiles for you, then I could walk you though whats all
going
on with this and where i’m at.

Thank you
Andrew

On Tue, Jul 30, 2013 at 8:12 PM, Johnathan C.

5

Hello All,

Just an update for those following along, I have ( somewhat ) finished
the
ATSC transmitter, most of the blocks needed were all ready made, but
they
stopped right before pilot insertion and VSB modulation ( my guess is
since
the hardware back then was receive only they stopped there ), so I added
the needed blocks, and transmitted with my USRP1 to a television. It is
much faster than real time and so i’m trying to encode and transmit my
webcam live but i’m still working on getting gstreamer to output the
correct stream :slight_smile:

Also the receiver is coming along but i’m still stuck with the magic
constant. I have a nice sample data recording from my USRP of my local
TV
station, it is just above the threshold for decent recovery and so
should
be good for testing improvements the the receiver. Would anyone like
this
sample for testing?

Thank you all
Andrew

6

On 07/30/2013 04:28 PM, Andrew D. wrote:

Thanks for the idea, I will try it tomorrow when I get back to the test
machine ( which is powerful enough to be within reach of real-time
decoding if I get this figured out :slight_smile:

If you don’t get this straightened out, I’d be happy to work with you by
phone or chat.