Re v0.8 bandwidth feature

[owenduffy]

I expected that the bandwidth feature could be used to reduce measurement jitter.

I took two sets of s11 measurements from1-30MHz of a)OC termination and b)50ohm termination using BW=1000 and 10Hz.

I expected to see an obvious reduction in jitter at 10Hz BW, but I cannot distinguish the 10Hz measurements from the 1000Hz measurements (other than that the 10Hz took much longer to sweep).

I repeated on measurement using nanovna-saver v0.2.2 and 1000Hz bandwidth, and 16x averaging and there was an obvious reduction in jitter.

Have I misunderstood the purpose and effect of the bandwidth feature?

[Pmax65]

Hi owenduffy, What nanoVNA are you using? I don't want to teach the cat climb the roof (maybe that you already know what I'm writing below) In case you are using the nanoVNA version with the IP5303 PSU, the noise is coming from the supply rails and the bandwidth narrowing is useless against that noise, while averaging works anyways because that noise has almost no coherence with the testing signal. BTW I don't know what is the rejection of the stop-bands of the DSP based IF filter, but I suspect it's not that high, at least in the close of the pass-band, since applying a strong signal in the fundamental range, the 1.66kHz apart tones generated by the interference with the 3rd harmonic signal passes with an attenuation of only 30dB as you can see here: https://github.com/hugen79/NanoVNA-H/issues/40#issuecomment-640090225 The red trace is the S21 nanoVNA measurement of a VHF/UHF duplexer compared to an HP8711A VNA measurement of the same DUT (the black trace). The only reason that signal is there is that it passes through the IF filter despite its offset respect the oscillator LO signal is 1.66kHz instead of 5kHz. By the way, did you measure the clock jitter too? AFIK, Being a PLL based generator, the Si5351 is very sensitive to the supply rail noise, maybe that you are measuring the effects of that noise. Have a great day. Massimo - IK1IZA

[owenduffy]

Hi Massimo, Thanks for your response. I should have mentioned that I am using a nanoVNA-H v3.3. I think it is a 'true' version, but the Chinese are such copyists, it is hard to be absolutely certain. Yes, it does use the IP5303 battery management chip, and despite assurances from developers that there was nothing wrong with these chips, I think the next version used a different chip. I also performed the test with the device stand-alone (ie self powered, no USB) and made the same observation that S11 on an O termination showed no sensitivity to BW setting. I realise this does not eliminate the IP5303, but at least it is not regulating charge rate at this time. I did not directly measure clock jitter, I just observed the end measurement noise. In this model hardware, the BW feature certainly slows the scan rate but does not appear to materially improve measurement jitter.

Owen

[Pmax65]

Hi Owen, I evaluated and solved the noise issues about the IP5303 in this thread: https://github.com/hugen79/NanoVNA-H/issues/14 This chip is very noisy in charging the battery while powered by the USB port, so I had to switch off the charging when the nanoVNA is turned on attached to the PC. The battery charging is allowed only when the instrument is turned off.

In this model hardware, the BW feature certainly slows the scan rate but does not appear to materially improve measurement jitter.

The scan slowdown is needed to avoid the degradation of the sampled signals due to the longer response time of narrower filters (it doesn't matter if they are HW analog filters or SW DSP digital filter, the narrower they are the slower is their pulse response time). Despite this, if the noise is coming from the clock there is no way to reduce it by narrowing the IF filter, while averaging the sample data along time is effective reducing that noise, because it's almost completely uncorrelated with respect the sampling rate.

I honestly don't know if it has any sense implementing the narrow bandwidth in this tiny instrument, because of its noisy environment I suspect it get almost nothing doing that, anyways it's an option worthy of being tempted.

Just to know: What's the jitter amplitude you are arguing about? At which frequency did you performed your test?

Have a great day.

Massimo - IK1IZA

[owenduffy]

Hi,

I mentioned the longer scan time not as a complaint, but as evidence that the lower BW was activated.

I mentioned in my post that I made a really simple set of measurements from 1-30MHz.

I am not commenting on the amplitude of the jitter in absolute sense, but that reduced BW did not seem to have any effect. We might expect that if the noise is Gaussian, then reducing bandwidth would reduce jitter... so perhaps the noise is not Gaussian but systematic in some way.

I previously reviewed an averaging feature in IIRC -Q firmware and it did not seem to reduce jitter. I did browse the code, and it looked ok, but the jitter did not seem to be improved whereas the averaging in nanovna-saver did reduce jitter.

Since both of these approaches did not seem to reduce jitter in my tests, it questions the nature of the measurement noise.

Owen

[Pmax65]

Hi Owen,

so perhaps the noise is not Gaussian but systematic in some way.

I think you are absolutely right, but it's just a thought of course, I didn't check this issue indeed.

I did browse the code, and it looked ok, but the jitter did not seem to be improved whereas the averaging in nanovna-saver did reduce jitter.

This is just a thought yet, but this could be well explained with your systematic noise hypothesis: until the averaging is executed using successive samples synchronized by the CPU timings, the average can't cleanup that time-coherent noise, while passing through the asynchronous USB streaming, that noise is well cleared away, even if only partially (I suppose, of course).

Have a nice day.

Massimo

[Pmax65]

Hi Owen, I see that you closed this issue. Did you reach any conclusion about it? Have a great day. Massimo

[owenduffy]

Because of the failure of two different statistical approaches to reducing measurement variance, I accept your suggestions that the noise is systememic and inherent in the nanoVNA-H v3.3 and there may be no 'on-board' fix.

[Pmax65]

Hi Owen. I never checked for the bandwidth and avg function of the nanoVNA indeed (I'm using the nanoVNA-H FW without those options), my assertions were just guess. Anyways, since I'm having fun with cutting off the fundamental for the odd harmonics mode, I discovered that the last nanoVNA 3.4 version is at least 10dB much noisy than the previous power rail filtered PCB that I modified. I'm not sure where is the source of that additional noise. I'll try to add an independent 8MHz crystal oscillator for MCU and DSP, because that older PCB had it modified that way. Maybe that the "jerking" clock from the Si5351 is the culprit of that noise. In case I'll get improvements, I tell you here.

In the meantime, have great days.

Massimo