Doubts About the Polyphase Clock Sync Block

[Saurav Roy]

Dear all,
I have a few questions about the Polyphase Clock Sync Block in reference to 
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/pfb_clock_sync_ccf_impl.cc


  1.  line no 67:d_damping = 2 * d_nfilters;   -->  d_nfilters=32, should 
this not be around 0.707

  2.  line no 366:  based on the 'time_est' tag, determine the filter index, 
d_k. But, this completely bypasses the TED and the control loop as in line no 
374 d_filtnum = (int)floor(d_k);
then why do we need this Polyphase Clock Sync Block at all?


  1.  How does the main loop take care of which input samples are selected for 
the determination of d_error and d_k such that all the input samples come from 
the same input symbol?

With thanks and regards
Saurav

Re: Σχετ: Re: QAM constellation script

[Marcus Müller]

Hi George,

that flow graph doesn't frequency-hop :) It does something different, 
rather cool. Please correct me if I got anything wrong about your 
self-written blocks below:


What you do is:

"VCO generator":

Produces always the same 10240-long vector with pseudo-random values,


"Repeat":

Repeat that vector you get 100 times (but that makes no difference, you 
could have just taken 100 vectors from "VCO generator", they are all the 
same)

This does **not** repeat the elements within the vector 100 times


"VCO (complex)":

Takes every input values and uses it (scaled with a factor) as phase 
increment relative to the last value it has generated.
With the uncorrelated random [0,1] source at the input, and the scaling 
being such that the phase increment range is always [0;2pi], this just 
generates a pseudo-random point on the unit circle each output item



"Complex Conj":

Well, takes the complex conjugate of each item individually – still just 
points of uncorrelated random phase!



"Multiply":

You're multiplying the samples from your reception with a different 
sample each from a repeating, white pseudorandom noise:

This is spectral whitening :) But not frequency hopping.


Best regards,
Marcus

On 4/28/23 14:03, George Katsimaglis wrote:

Hi,

Thanks for the answers.
I attach the Rx flowchart and grc of the frequency hopping. I have 
successfully used it on QO100 satellite.


George SV1BDS


Στάλθηκε από το Ταχυδρομείο Yahoo σε Android 



Στις Πέμ, 27 Απρ, 2023 στις 14:57, ο χρήστηςMarcus Müller
 έγραψε:
Hi George,

> Also I have implemented 1.000.000 hops/sec frequency hopping at
QO100 satellite, spread
> over 1 MHz, using 10240 different frequencies.
> Is this project of general interest?

Well, that's impossible to say, but honestly: it probably is! And
also, you shouldn't care
too much :) It's cool in any case!
My advise is: Just put it out there.

But I do have signal theory questions:

We know that if a signal has a bandwidth of 1 MHz, we can
(complex) sample it and contain
all its signal content with a sampling rate of 1 MS/s.

If you're doing a million hops per second, how are you achieving a
bandwidth of only 1
MHz? That means that every hop only gets a single sample, and you
can't signify
"frequency" with just a single number.

So, I might have misunderstood you there, but it would seem what
you claim to have done is
mathematically not possible :(

> I create this script using Python to create QAM constellations
points.
> May be of general interest.

It's nice, but GNU Radio already comes with that!

from gnuradio import digital
constellation = digital.constellation_16qam()
points = constellation.points()

(and you can just use digital.constellation_16qam().points() in a
GRC block parameter, no
need to build a string!)

These are also power-normalized to 1.

If you don't want normalized (or different sizes of) QAM
constellation,

digital.qam.make_non_differential_constellation(M, gray_coded)

is your friend;

digital.qam.make_non_differential_constellation(4096, True)

makes a nice 4096-QAM, but it's average power isn't 1; you can fix
that

points = digital.qam.make_non_differential_constellation(4096, True)
average_pwr = sum(point**2 for point in points) / len(points)
print(f"Average power: {average_pwr}; normalization factor hence:
{average_pwr**(-1/2)}")
normalized_points = [ point * average_pwr**(-1/2) for point in
points ]

Similarly, since you're doing satellite communications, you might
be interested in PSKs,
an A-PSKs.

You can create a PSK using

digital.psk.psk_constellation(m=4, mod_code='gray', differential=True)

e.g.

digital.psk.psk_constellation(16, differential=False)


If you don't have GNU Radio but just python,

str([(i, j) for i in range(-n, n, 2) for j in range (-n, n, 2)])

does the same as your code, but might be a bit easier to read
(again, if you want to use
this in GRC, don't do the conversion to `str`; GRC accepts any
valid Python in its fields).

Best regards,
Marcus

Σχετ: Re: Σχετ: Re: QAM constellation script

[George Katsimaglis]

Hi Marcus ,

Στάλθηκε από το Ταχυδρομείο Yahoo σε Android 
 
  Στις Σάβ, 29 Απρ, 2023 στις 14:23, ο χρήστηςMarcus 
Müller έγραψε:   Hi George,

that flow graph doesn't frequency-hop :) It does something different, 
rather cool. Please correct me if I got anything wrong about your 
self-written blocks below:

What you do is:

"VCO generator":

Produces always the same 10240-long vector with pseudo-random values,


It produces two different vectors depending of fh Boolean value. A sawtooth 
vector of values between  -0.5 and 0.5 or the same random values between -0.5 
and 0.5. The sawtooth values used in alignment phase (adjusting myblock).
"Repeat":

Repeat that vector you get 100 times (but that makes no difference, you 
could have just taken 100 vectors from "VCO generator", they are all the 
same)
This does **not** repeat the elements within the vector 100 times


This block offloads the previous block as is too heavy to produce random 
numbers at the rate needed.
"My block"Shift the vector in order to match the receiving keys.

"VCO (complex)":

Takes every input values and uses it (scaled with a factor) as phase 
increment relative to the last value it has generated.
With the uncorrelated random [0,1] source at the input, and the scaling 
being such that the phase increment range is always [0;2pi], this just 
generates a pseudo-random point on the unit circle each output item

The VCO complex, with the values specified, produce frequencies between -500 
kHz for -0.5 and +500 kHz for +0.5 input. This block creates the frequency 
change. All values between -0.5 and +0.5 produce frequencies between them.VCO 
is voltage controlled oscillator. It produces frequencies depending of 
"voltage" input.

"Complex Conj":

Well, takes the complex conjugate of each item individually – still just 
points of uncorrelated random phase!

Inverse the frequencies created.

"Multiply":

You're multiplying the samples from your reception with a different 
sample each from a repeating, white pseudorandom noise:
This is spectral whitening :) But not frequency hopping.

It moves the USB voice signal by frequency created from previous steps.

You can better understand it considering frequencies rather than phases.
Best regards,
Marcus
Best regards,George SV1BDS 
On 4/28/23 14:03, George Katsimaglis wrote:
> Hi,
>
> Thanks for the answers.
> I attach the Rx flowchart and grc of the frequency hopping. I have 
> successfully used it on QO100 satellite.
>
> George SV1BDS
>
>
> Στάλθηκε από το Ταχυδρομείο Yahoo σε Android 
> 
>
>    Στις Πέμ, 27 Απρ, 2023 στις 14:57, ο χρήστηςMarcus Müller
>     έγραψε:
>    Hi George,
>
>    > Also I have implemented 1.000.000 hops/sec frequency hopping at
>    QO100 satellite, spread
>    > over 1 MHz, using 10240 different frequencies.
>    > Is this project of general interest?
>
>    Well, that's impossible to say, but honestly: it probably is! And
>    also, you shouldn't care
>    too much :) It's cool in any case!
>    My advise is: Just put it out there.
>
>    But I do have signal theory questions:
>
>    We know that if a signal has a bandwidth of 1 MHz, we can
>    (complex) sample it and contain
>    all its signal content with a sampling rate of 1 MS/s.
>
>    If you're doing a million hops per second, how are you achieving a
>    bandwidth of only 1
>    MHz? That means that every hop only gets a single sample, and you
>    can't signify
>    "frequency" with just a single number.
>
>    So, I might have misunderstood you there, but it would seem what
>    you claim to have done is
>    mathematically not possible :(
>
>    > I create this script using Python to create QAM constellations
>    points.
>    > May be of general interest.
>
>    It's nice, but GNU Radio already comes with that!
>
>    from gnuradio import digital
>    constellation = digital.constellation_16qam()
>    points = constellation.points()
>
>    (and you can just use digital.constellation_16qam().points() in a
>    GRC block parameter, no
>    need to build a string!)
>
>    These are also power-normalized to 1.
>
>    If you don't want normalized (or different sizes of) QAM
>    constellation,
>
>    digital.qam.make_non_differential_constellation(M, gray_coded)
>
>    is your friend;
>
>    digital.qam.make_non_differential_constellation(4096, True)
>
>    makes a nice 4096-QAM, but it's average power isn't 1; you can fix
>    that
>
>    points = digital.qam.make_non_differential_constellation(4096, True)
>    average_pwr = sum(point**2 for point in points) / len(points)
>    print(f"Average power: {average_pwr}; normalization factor hence:
>    {average_pwr**(-1/2)}")
>    normalized_points = [ point * average_pwr**(-1/2) for point in
>    points ]
>
>    Similarly, since you're doing satellite communications, you might
>    be interes

Re: Doubts About the Polyphase Clock Sync Block

[Jeff Long]

1. Given that set_damping_factor() requires the value to be in [0.0, 1.0],
2 * d_nfilters looks quite wrong. I wonder if it was supposed to be 2.0 /
d_nfilters. This is probably overridden by a call to set_damping_factor()
in a typical flowgraph.

I'm not familiar enough with the block to comment on 2 and 3 without some
study. Please submit an issue at https://github.com/gnuradio/gnuradio/issues
so we don't lose this info.

On Sat, Apr 29, 2023 at 3:56 AM Saurav Roy  wrote:

> Dear all,
> I have a few questions about the Polyphase Clock Sync Block in reference
> to
> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/pfb_clock_sync_ccf_impl.cc
>
>
>1. line no 67:d_damping = 2 * d_nfilters;   -->  d_nfilters=32, should
>this not be around 0.707
>
>2. line no 366:  based on the 'time_est' tag, determine the filter
>index, d_k. But, this completely bypasses the TED and the control loop as
>in line no 374 d_filtnum = (int)floor(d_k);
>then why do we need this Polyphase Clock Sync Block at all?
>
>
>
>1. How does the main loop take care of which input samples are
>selected for the determination of d_error and d_k such that all the input
>samples come from the same input symbol?
>
> With thanks and regards
> Saurav
>
>