Re: Weird behaviour of the analog signal source (was: Re: How ensure consistency with timing signals)

[Sylvain Munaut]

Hi,

> I am by no means an expert on this but just for my understanding I would be 
> curious:
>
> 1.) I still do not understand why for 1 Hz at 5MSps I can get a period that's 
> "500578.5" on average. The frequency error is a whopping 0.1158%! 
> ((5005789.5-5000000)/5000000*100). Huge.

That's because you're a rather extreme case. The ratio between your
frequency and the sample rate is pretty large.
The precision of the block would be somewhere around 0.25 ppb of the
_sample_rate_ which is not that bad, but in case of huge oversampling
obviously that can become significant ...
It's just a use case this block was not really designed for.


> 2.) Why is it implemented that way? Why does Simulink, ADS, Cadence Spectre 
> et.al. provide correct and accurate results?

Phase increment is a pretty common way to implement digital
oscillator. The advantage is that it's pretty fast, the state variable
is limited (you just have the phase) and whatever error you have is
constant and time-invariant.


> 3.) What would you do if you would want to create precise timing signals? Is 
> a custom block really the only way? And then, how would you implement it?

Yes, custom block is the only way. And really for _anything_ where you
depend on precision, you _must_ be 100% in control of the arithmetic
and how you deal with precision. And GR never guarantees
implementation so using any default block that does math and the error
might change from one version to the next. So IMHO any "metrology"
type thing must re-implement every math operation and control how they
deal with errors.

For the cases where you have huge oversampling handling it the other
way around would probably make more sense. You just keep "how many
samples per cycle". Then you keep both an integer counter of how many
sample you are in this cycle and a fractional offset and generate the
sin/cos values based on that. This would probably perform worse for
low oversampling signals (like if you generated a 1 MHz sine sampled
at 5 Msps), but for your case, it will be better (actually given
you're an exact divider, it would be perfect with no frequency error
and as little phase noise as permissible with double precision).


> I know that it is impossible to give a solution to this remotely but this is 
> so weird that don't even know where to start looking.
>
> If it were you, how would you approach debugging this?

Look at the code ... at no point did you state which git commit you're
working of so can't help there, but that's the only source of truth.
Randomly adding block is useless. The only thing is points toward is
that depending on how the block gets scheduled (i.e. how many samples
it generates at each call to work()) changes the result, which should
not happen.


Cheers,

     Sylvain