开云体育

Wow I just found a Q curve function in the nano menus! The beauty of calibrating this way with the edelay command is that the Q curve it displays is valid because the nanovna is calibrated rather than just the remote PC display. I can also look at a valid display of ESR and I don't have to have the computer connected.

I'm seeing a very useful increase in performance with 1.0.52 FW now. The only downside is that the increased performance has made it all too apparent that my old nanoVNA-H needs to have the 100nF caps added to the mixers!

See the plot below. This is a fresh attempt to measure the Q of the old Philips poly 470pF cap and I'm using V1.0.52 FW and 100Hz RBW. The graph below shows a significant improvement for the nanoVNA. The marker shows a stubborn blip at about 6.6MHz but I'm pretty sure this is the mixer decoupling issue with the V3.3 board.

In the next series of tests several SMD resistors were measured using the nanoVNA-H4 at all the power levels. Calibration this time was done in the NanoVNA app with the averaging option set to 8. The power level can be set from the NanoVNA app but the levels used are Auto, 0, 1, 2, 3 instead of the Auto, 2, 4, 6, 8 in the -H4 firmware. Users need to be aware that when re-using a saved calibration you must set the power level to that used at the time of calibration. The 1.0.45 firmware does this automatically when you Save/Recall but the NanoVNA app does not and you have to set it manually.

Results for a 10 pF SMD capacitor, 1 ohm, 1K ohm and 3K ohm resistors are attached. In all cases using the 0 (2 ma.) setting gave the best results.

Roger

On Fri, Mar 26, 2021 at 12:41 PM, Roger Need wrote:

If you want an in depth technical explanation on series and parallel resonant
circuits and how the Q of the LC components affects the resonant frequency it
was well covered by the Terman in his Radio Engineers handbook in 1943.

Great, Roger, I have downloaded the handbook and will read.

But this is about an abnormality in relation to what is though about parallel circuits. But often the guys of old knew other tings ... information are getting lost :(

--
Simen Tobiassen

In the "Pitfalls" topic a comment was made that the older NanoVNA firmware gave better results when measuring some parameters of components. I wondered if this might be due to the power output level used in the older firmware. The clock generator chip used in the NanoVNA can be set to have a drive current of 2, 4, 6 or 8 ma. Older firmware has it set to 2 ma. and newer firmware sets it to the maximum of 8 ma. On my NanoVNA-H with Oct. 2019 firmware the measured output is -13 dBm at 30 MHz. A NanoVNA-H4 using DiSlord 1.0.45 firmware in the default 8 ma. "Auto" mode outputs 0.8 dBm at 30 MHz. and -10.4 dB at 2 ma.

One reason for using a higher power level is that for S21 measurements it gives more dynamic range. For S11 measurements with a reflection coefficient that is fairly low ( low SWR and high Return Loss) it might give more accurate measurements. But for measuring components where the reflection coefficient is approaching 1 this might not be the best option. My rationale for this is that the SA612 will be operating at the top of its power level input under these conditions and less power should result in better measurements.

To test this out I constructed a 100 nH inductor from AWG 14 copper wire with 3 widely spaced turns to reduce self capacitance and obtain a high SRF. A female SMA connector with a pin header and SMD cal loads was used for the test jig. The inductor was measured from 1 to 100 MHz. on a NanoVNA-H ver 3.3 with the original Oct. 2019 firmware. Calibration was done using NanoVNA Saver with 4 segments and multiple averaging during the calibration. The results were exported as a S11 Touchstone file. The next series of tests were done on a NanoVNA-H4 with DiSlord 1.0.45 firmware. Multiple calibrations were done on the -H4 itself using power levels of Auto (8 ma). and 2 ma. The latest version of the NanoVNA app by OneOfEleven was used because of its excellent plotting and scaling options. The -H touchstone file was imported so a comparison could be made to the -H4 results.

The results are attached and two observations can be made. The best estimate of Q was made using the lowest power output setting and the -H4 results are considerably less noisy than the -H. Note the low ESR that was measured although a better jig with cal load parameter entry capability would give even better results.



Roger

Thank you for good ideas and info, but in this simulation case I guess it is the CPU and my head that need to be immersed in LN2 ;)

You say low Q will drag the frequency down - but the Q factor is high in this case: 4174.

--
Simen Tobiassen

Doing the calibration this way is doubly nice for me because it means the nanovna is corrected after the calibration so the nano display reads correct and it can be removed from the PC if required. My next VNA will hopefully be able to exploit your SDcard feature so I can cal with the PC and then collect s1p and s2p data away from the PC.

As Donald suggests, it would be wonderful to be able to store all the classic cal kit corrections in the nanoVNA as a user file.

Another nice feature would be to be able to add a fixture reverse feature as an option when measuring s2p data. I can do this remotely with my PC tools to generate full 2 port s2p data.

However, I'm more than happy with what I already have with V1.0.52. Thanks again!

Tomorrow i look at this edelay multiplier, possibly i change it.
About nanoVna-Apo, im nor autor of this software, sources not open

Wow that was quick, thanks!... I've downloaded 1.0.52 and just tried it. I've only done a basic SOL cal for s11 but it seems to be working with edelay during the calibration. Many thanks!

To describe how I tested it, I deliberately added an extra (59.9ps delay) SMA 'connector saver' inline, but only with the SHORT standard. If I do nothing about the extra delay with the SHORT the calibration will be corrupt because of this extra 59.9ps on the SHORT.

To correct this and achieve an accurate calibration I have to tell the nanoVNA over the USB port that this 59.9ps has to be accounted for with the edelay command. However, to get the right result I have to tell it to correct by 59.9 x2 = 118.9ps for the SHORT standard.

I'm not used to having to do this scaling with other VNAs. I'm aware of it so I just scale x2 every time I need to correct for a delay in the OPEN SHORT THRU standards.

Thanks for the amazing firmware! Have you any plan to build the NanoVNA-App for MacOs? ?

Many thanks!

Yes i know, need rebuild calibration tables vs apply this.
Upload v1.0.52
Apply edelay for all device measures (include calibration and external data)

You can change edelay for every step, just set edelay. go to calibration made measure, go back, set new edelay ... go calibration made new measure ... at end need press done

For more options need more code change.
/g/nanovna-users/files/Dislord%27s%20Nanovna%20-H%20Firmware/NanoVNA%20v1.0.52.rar

Adding delay would be a first-order improvement. Even better would be to allow calibration standard definitions with Z0, delay, loss and frequency-dependent C0-C3 capacitance and L0-L3 inductance factors. These factors become increasingly important as one goes higher in frequency.
73, Don N2VGU.

Dave: The ~1.53 dielectric constant of the LN2 will likely have an effect on the inductor value which may obscure the temperature effect. 73, Don N2VGU

If you add this edelay enabling feature for OPEN SHORT and THRU and you have some memory free somewhere then the nanoVNA can save/store a basic 'user' cal kit correction lookup in the same way a regular VNA does for delay settings for OPEN SHORT THRU.

Oh yes please. Ideally, I want to be able to set/reset edelay for each stage of the calibration. If it has this I can go back to using your latest firmware.

And yes edelay not apply on calibrations measure
Hmm, need add it?

Yes, edelay not apply for external program (used only for internal calculations)
Last NanoVNA-App/NanoVNA Saver software appy this by self

I found that I could no longer experiment with the edelay command during the SOLT process when carried out remotely with a PC. It seemed to override or forget the edelay command as I go through each stage of the SOLT. I do it this way to keep the nanoVNA portable after a calibration.

The edelay has also always (on all FW versions I've tried) required a scaling factor when I experiment to offset deliberately added delays using connectors. I'm OK with this but it did catch me out at first.

latest FW doesn't support the edelay command

hmm, i check edelay, and it should work as before
And console command and input on Nano
edelay input from console command in pico second (1e-12)

For general purpose use the bundled cal kit is probably fine. I've avoided using the cal kit that came with the nano because I try to avoid using anything other than high quality connections that come from a known manufacturer. This isn't just for performance reasons, it's because you never know how accurately the cheap connectors have been designed in terms of tolerances. They may well accelerate wear or even cause damage to other connectors and this can then be transferred from the now damaged (high quality branded) connector on to other connectors. This might not apply to the nano cal kit but I don't want to take the chance. I have Gore SMA cables here that cost over ?1000 each new and my Agilent N4431B 60006 Ecal module has their special version of the 3.5mm connector that is very fragile and can be damaged by a tiny burr on an SMA male connector pin.

I'm also not using the cal standards that came with the nano because if I did I would have to include de-embedding corrections for any test fixture I would use and I don't want to try and reverse engineer what those corrections might be. Even if I tried I would have doubts about the accuracy.