*"Doesn't NPN based oscillator reacts on LC resonant frequency change (C change) faster than external PLL?" - Buggins*

Yes. But above some level the rate of change is meaningless to our human senses. And changing C in a high Q LC too quickly could perhaps kill resonance?

But when I say "phase error" I'm talking about the oscillator drive and sense not being optimally aligned. All single transistor / logic (non PLL) oscillators I've investigated have some phase error, and this limits the voltage swing at the antenna. The phase detector in my DPLL measures the phase difference between the drive and the antenna, and maintains it at exactly 90 degrees, giving the highest theoretical swing possible.

*"Frequency of oscillator output is being measured with very high precision using ISERDES/DDR components (e.g. it's equivalent of counter with 1600MHz rate, but there can be several such meters fed with OSC signal via slightly different delays - for 8 ISERDES meters it becomes 12.8GHz).**It gives a lot of bits. E.g. if time interval between OSC edges is 1us (1MHz), single measure will give count ~ 12800. Summarized for one 48KHz sample period (~20 measurements) it gives value near 266000 (18 bits). Since OSC frequency changes only in range 6-8%, 4 higher bits do not have a meaning. **So, we have about 14 bits of oscillator frequency information collected during one sample.**Averaging will increase this value.*

*Does your PLL based method give more bits?"*

No. The DPLL I/O pins are DDR and driven by a 196.666MHz clock, which gives an effective sampling rate of ~400MHz, or 2 bits less than your arrangement. I've looked into this before, and I don't believe I can use the SERDES construct in the Cyclone 4 because it is tightly integrated into the LVDS logic, which requires 2.5V bank voltage and differential I/O. Xilinx is often a bit more basic about how things are implemented, so you can mix and match more, but sometimes that means a reduction in speed.

Since the DPLL is also driving the LC tank, everything is synchronous to the FPGA clock, which means I have to use 48kHz triangular dither to increase resolution, and to break up synchronous dead spots. With your separate analog oscillator and very high input sample rate, I don't think you'll have that problem.

Anyway, as you know, not all bits are created equal :-). I've got a 4th order LPF (string of 4x 1st order LPFs) for doing the hardware downsampling to 48kHz, as well as a series of notch filters in SW, and a final 4th order low-pass tracking filter that seems to effectively remove all noise. I can see actual bit stepping changes on the LED tuner in the far field. But I've gone a little crazy reducing all the noise I could everywhere.

It's interesting examining your register set interface. I see you're using a moving average filter for the pitch and volume axes. Is this for downsampling? If so, a simple first order low-pass filter might be better suited. A moving average weights everything the same over an interval, while low-pass weights it towards the present, otherwise they're fairly equivalent (learned this in communications class). Moving averages can also alias more, and can require lots of memory. My "fast" low-pass filter works up to quite high frequencies, and chaining a bunch together can give you fairly aggressive anti-aliasing. I've got a spreadsheet on that if you're interested. On the D-Lev I set the aggregate -3dB point to 416Hz, and the response is down -112dB at 24kHz, which gives ~18 bits of clean anti-alias action at the HW / SW interface. Probably overkill, but at least it's blameless in terms of causing trouble.