Skip to content

gradev broken, especially for frequency data #60

@jleute

Description

@jleute

The gap resistant ADEV functions have some issues that should be easy to fix and a more serious issue concerning frequency data.

The easy to fix issues:

  • calc_gradev_phase() calls the function uncertainty_estimate() that doesn't exist.
  • the parameters mj and stride are not converted to integers in calc_gradev_phase().

The more important issue is that gradev() doesn't work properly for frequency data. If the input data is a frequency array with NaN values, the frequency2phase() function is called and it sets all phase values to NaN after the first NaN value occurs in the frequency array. That's a property of np.cumsum(). If you are unlucky and the first value is a NaN you lose all data in this step. There is a function called trim_data() that trims NaNs from the beginning of an array, but it is not used anymore (since the API change).

Additionally, since the API change, the gradev example uses data_type='freq' and the example doesn't work very well due to the issue discussed above.

The core issue here is that for frequency data with gaps, the frequency data can not be converted to phase data and the gradev must be calculated based on the equations for the adev for fractional frequency data.
At the moment all *dev calculations in allantools are based on phase data. What do you think about *dev calculations based on frequency data?

As discussed in I. Sesia and P. Tavella, Metrologia, 45 (2008) p. 134, using the phase data for the adev calculation is preferred in the presence of data gaps, but sometimes there is no choice.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions