Make course frequency correction more robust

[tomneda]

Regarding issue https://github.com/tomneda/DABstar/issues/19 it would be good that the coarse frequency correction does not only correct the input LO frequency resp. baseband frequency offset but considered the reference frequency of the device (also). This is necessary because of the drift in the sample frequency is not considered with only changing the LO resp. baseband frequency offset.

[old-dab]

I have a suggestion for this issue: https://github.com/old-dab/DABstar/commit/227ca29078d5072df174b822cf0f54c5c26f77e2 This allows synchronization up to +-150ppm deviation. However, there is another problem with USB sticks with separate quartz crystals for tuner and RTL2832, such as the Astrometa. The ppm correction affects both quartz crystals. So you have to decide whether you want the exact frequency or symbol rate. My worst USB stick needs +80ppm in the tuner quartz crystal and -50ppm in the RTL quartz crystal. A correct symbol rate seems to be better, as you can see in the pictures below.

[tomneda]

@old-dab : I tried out your version and it really performs much better. So I take it over but not all changes because I will maintain the "DC avoidance algorithm" which you removed. But it is still working well.

I wonder about the construct with the abs() method. I thought this is correlation sum and so also negative values should be summed ab.

  int16_t index = IDX_NOT_FOUND;
  {
    float MMax = 0;

    for (int16_t i = 0; i < SEARCHRANGE; i++)
    {
      float sum = 0;
      for (int16_t j = 0; j < CORRELATION_LENGTH; ++j)
      {
        sum += abs(mRefArg[j] * mCorrelationVector[i + j]);  // why this abs() method?
        if (sum > MMax)
        {
          MMax = sum;
          index = i;
        }
      }
    }
  }

Without this abs() method (which I would assume as more correct) it works also but a bit less reliable. Maybe you can explain the technical background of this part in the code?

Motivated with your changes I tried out other methods for frequency estimation and I found also one which performs similar; and I understand it better why it performs so :smiley:

But I want try out a bit more before you could see the results. I did not pushed the adaptions back if you liked to see them.

[old-dab]

In found these lines here in the processPRS function: https://github.com/AlbrechtL/welle.io/blob/master/src/backend/ofdm-processor.cpp