I've been continuing my investigation into improving the nanovna's
dynamic range above 900MHz, and have some further results to share.
Theory tells us that dynamic range can be improved by increasing the number
of readings that are correlated in the DSP - every doubling should increase
the dynamic range by 3 dB.
At the moment the firmware processes just one "frame" of 48 readings, 1
millisecond's worth at 48KHz sampling rate. It's astonishing that the
nanovna is so accurate with so few samples at frequencies below 300MHz.
It's almost trivial to modify the code to perform the correlation over a
number of frames; indeed there are vestiges of code there to do just that.
However, when I implemented the changes to correlate over 8 frames, which
should have improved the dynamic range by around 9dB, it actually got
worse! This surprise has led me to look further at the raw data.
My earlier investigation and work-around to the usb command instabilities
has been serendipitous in that I discovered a large chunk of memory that's
used only for screen-display. My stability workaround disables updates to
the screen, allowing this memory to be re-used. I've therefore created a
firmware version that dumps 10 consecutive frames worth of raw data via the
usb port. I run a FFT on this data. The FFT's 5KHz bucket tallies exactly
with what the firmware dsp calculates (apart from scaling).
What follows are some results.
*Attachment 1 - 190MHz with a cable connecting the 2 ports (48 samples
only)*
This is a "benchmark" reading showing normal operation. The upper graph is
of the raw data returned from the nanovna. The lower graph charts the
results of an FFT on the raw data what is plotted is logFFT =
10*log10(abs(FFT)). The Peak above noise floor calculation is max(logFFT) -
mean(logFFT). This calculation is a bit crude because the average also
includes the peak value, so understates the dynamic range.
*Attachment 2 - 190MHz with a cable connecting the 2 ports (48*10
samples)*
The same charts are displayed as in attachment 1, but with all 10 frames or
480 samples.
Note that the peak for both ref and sample is improved by ~9dB, and that
the noise floor remains at a similar level. This results tallies with
theory.
*Attachment 3, 4 - 1.23GHz with a cable connecting the 2 ports 48 samples,
and 480 samples*
These attachments are same as the first two, except at 1.23GHz. The
increased number of samples shows approx 8dB improvement (from 23dB to 30
dB for ref, and from 21dB to 30 dB for sample). Again this is about what is
expected. However the FFT shows some strong peaks at 1KHz rate (the frame
rate), hinting at one possible source of noise.
So far this is as expected. The problem arises a different frequency is
chosen:
*Attachment 5, 6 - 1.29GHz with a cable connecting the 2 ports 48
samples, and 480 samples*
The peak improvement here is negligible at only 3 dB and 0 dB. Note also
that the peaks are now very spread.
*Attachment 7, 8 - 1.29GHz, 6KHz offset with a cable connecting the 2
ports 48 samples, and 480 samples*
The same as the previous result, except with a 6KHz offset. The underlying
cause of the frequency spread appears to be unrelated to the offset value.
Different frequencies give a range of results, with the two at 1.23GHz and
1.29GHz appearing to be at two extremes.
I have no explanation for what causes these results, only guesses. However,
if we want to improve the dynamic range we need to get to the root cause -
no amount of averaging is going to help.
Any thoughts appreciated.
Rgds,
Dave
[image: 1_190MHz_48_samples.png]
[image: 2_190MHz_480_samples.png]
[image: 3_1.23GHz_48_samples.png]
[image: 4_1.23GHz_480_samples.png]
[image: 5_1.29GHz_48_samples.png]
[image: 6_1.29GHz_480_samples.png]
[image: 7_1.29GHz_48_samples6KHz.png]
[image: 8_1.29GHz_480_samples6KHz.png]
