¿ªÔÆÌåÓý

I started a separate topic on measuring the CH1 noise or leakage

There are many discussion on this forum around the "noise" on CH1 limiting the dynamic range and weather the noise is influenced by the termination of CH1 or by good or bad SA612
So I decided to measure.
First 3 measurements of the "noise floor" in CH1 with a load on CH0 and an open, load or 50ohm on CH1. These are 1001 point measurements with 1/8 exponential averaging
As you can see the phase at higher frequencies is much too consistent to be caused by noise and this suggest leake of the test signal from the SI5351 to be the problem.

So using the "sample ampl" command I disabled the reference signal impact and you can see the switching of the ADC sensitivity when measuring a thru signal
The same measurement without input signal on CH1 does show approx the same as the first three measurements.
The I disabled the impact of the CH0 output signal generation by using a little known command that you can use to set the offset between the CH0 output and the SA612 LO signal to something different from the 5000Hz as hard encoded in the dsp.c (co)sine table and I set "offset 7000" to move CH0 signal outside the dsp filter window and this delivers a somewhat different picture
Apart from the step up at 300MHz where the switch to overtone is made and you loose 17dB sensitivity and this is compensated in the amplification setting of the adc, the noise floor shows a very different pattern suggesting the biggest impact on the dynamic range of the NanoVNA is leakage and NOT noise on CH1.

Goddammit...

Have I waste $1 / 1€ / ?1 on these now ;-)



Please, no (mass) debates ;-)

For info only.


73 de Andy

Rune where can I find the 1500 mhz code?

Thx 73 Dana VE3DS
===================================

Dana, it's not Rune's firmware, but see:

/g/nanovna-users/message/2391

73,
David GM8ARV
--
SatSignal Software - Quality software for you
Web:
Email: david-taylor@...
Twitter: @gm8arv

Hi qrp.ddc and Rune
I think it is time to get this discussion straightened out..
Doing a simulation of an SMA female adaptor with e.g. the program FEMM and by basing the simulation on mechanical dimension/drawings from a well know manufacturer e.g. Rosenberger, the Fringe C of the female adaptor is 32.24fF equal to an one way offset of 1.612ps. If the designer of the NanoVNA is using the fringe C of 50fF as a delay=2x the Offset then it correspond to a Fringe C of 25fF = an offset of 1.25ps and not that bad
I have just measured these parameter using my HP85033C 3.5mm calibration kit and a good VNA and the SMA female had an one way offset of 1.03ps=20.6fF. Calibration is of course pending the state of the calibration kit which has served my for some years and provide superb calibration when doing T-Check and sweep of my APC7 airlines
Measuring the Open adaptor supplied with my NanoVNA (in the center of image) the one way offset was 1.45ps=29fF an increase of 0.42ps=8.4fF
Measuring an open adaptor from Fairview Microwave or Pasternak (lower part of Image) no increase registered compared to the female SMA left unterminated
Measuring 3 pc. Huber Suhner Open adaptors (top of the image), which has a disk fitted towards the calibration plane, had a one way offset as 2.16 +-0.1ps equal to 43.2fF average.
These Offset are pending the mechanical design as shown in attached image. The open adaptor supplied with the NanoVNA is in the center and as the cylinder mating the reference plane has same inner diameter as the inner diameter of the mating ring of the calibration plane. then it will interact with the field lines form the center conductor.
These field line does not range outside the end of the SMA female adaptor so that is why the Fairview Microwave /Pasternak Open adaptor/Dustcover has not influence. (I have tested to 8GHz and the impact is hard to detect)
An open adaptor from Amphenol RF having a disk (like the Huber Suhner) even caused a short when using my torque wrench.
So I plainly love to use nothing as Rune mention, but the big question is what the designer of the Firmware for NanoVNA has defined the referred 50fF (I have even seen 60fF mentioned) to be an offset = one way or a delay = 2x Offset.
It also depend what the NanoVNA user gets delivered or purchase later on. If it is one with a disk, then throw it away
Regarding the Short which is supposed to be 0ps delay/offset I measured the supplied short to be -0.65ps (yes negative) whereas my simular short from Farview Microwave measured -0.1ps. The reason being the insufficient thickness of the shorting disk and the turned center pin for the one delivered has a small chamfer.
All in all clarification of the (bloody) 50/60fF would be nice
That was my humble contribution
Kind regards
Kurt OZ7OU (calibration nerd)



-----Oprindelig meddelelse-----
Fra: [email protected] <[email protected]> P? vegne af qrp.ddc@...
Sendt: 18. september 2019 12:11
Til: [email protected]
Emne: Re: [nanovna-users] Filter measurement

Rune Broberg, the problem with "nothing connected to CH0" case is that it has different geometry configuration than usual SMA connector. It leads to insufficient capacitance and different delay line, which leads to incorrect measurement. But it depends on what you needs. If you're work in 1-30 MHz range, you may keep "nothing connected to CH0" it will not affect result much. But if you want to use frequencies above 30 MHz, you're needs to use proper open terminator.

Further thoughts.

Best evidence presented so far shows two plots, one with a noise floor of abut -80db,
the other with a load connected to Ch1 shows a -85db noise floor.

But that noise floor wobbles about by plus/minus 5db
Average of that is..zero.

If we also consider a previous statement that the input amp is best measure with the correct load,why was there no difference between
doing a calibration routine with a SHORT or an OPEN with regards to the noise floor ?

These are the two extremes that an input amp could have on Ch1.

And yet my own test (which I am still puzzled by) is WITH a 50R load.

Maybe the amp IS working properly when it sees it's designed load, because it's designed to amplify when terminated
correctly. As an amplifier, it's function is to amplify when terminated with the correct load. Well if that's the case then
this is the time when it's able to amplify any noise present most efficiently ;-)

That would correlate nicely with my increased noise observations, and the degradation of the noise floor.

Not arguing, just exploring and learning.

73 de Andy

Glad to help Joe.
I recognise your callsign from the QRSS Grabber that I have monitored in the past.
I think it got zapped by a lightning strike ?

73 de Andy

Don't forget to upgrade NanoVNASaver - that phase error was fixed in 0.0.9,
and 0.0.10 will be out "soon" :-)

--
Rune / 5Q5R

Several days ago I reported stability issues with some usb commands (
/g/nanovna-users/message/2379 ) . This is a follow-up...

First, to summarise the issue, a number of commands sent on the usb port
leads to nasty stability issues (frequency freezing, the screen going
white). The problem commands are: "freq", "scan", "offset", "power". (These
all make calls to an internal routine called set_frequency() to set the
output frequency).

I was surprised at the time that more people weren't reporting similar
problems, especially given the popularity of nanovna-saver, which uses the
usb interface. However I've since looked at nanovna-saver and discovered
that the only commands is uses are "info", "sweep", "data", "frequencies".
These commands instead rely on the UI Thread to call set_frequency() for
all 101 data points. It very nicely avoids the problems I encountered.

This means that the issues I've found will *not* affect most users. However
if you are dabbling with writing your own pc software you should stay clear
of the problem commands.

The following is therefore only relevant to those that want to use these
problem commands, and to those wanting to improve overall firmware
stability.

I continued to investigate the cause of the instability, partly because I
was concerned there was a random "rogue pointer" bug somewhere, and that my
test case just made the bug more easily reproducible - therefore finding
and fixing it might lead to other benefits.

I had previously found that stability was improved by having the UI thread
avoid calling draw_all_cells() (which updates the screen) whilst the usb
interface was active. I therefore focused my efforts on the screen drawing
code. The screen drawing logic is long and complicated (partly described by
ttrf here:

(use
google translate). It's therefore a perfect candidate for a subtle bug
causing a buffer's bounds to be exceeded.

However, instead I isolated the problem to inside the screen-driver itself:
ili9341.c. The source code includes 2 alternate implementations
of ili9341_bulk(), selection between them being via an #ifdef. This routine
outputs a large amount of data to the LCD screen. The "live" version uses
DMA to transfer the information fast and without CPU intervention. The
commented-out version transfers the data via the CPU alone, without DMA.
When I switched to building with the CPU version the stability issue had
gone! I have tried to narrow down what specifically about the DMA version
causes stability issues, but have made no further progress. However I have
eliminated memory corruption issues in the screen drawing logic as the
cause of the instability.

Note: the DMA version doesn't cause problems normally because the UI thread
only ever calls set_frequency() and ili9341_bulk() sequentially; the
problem only arises if the calls occur in parallel.

Next steps:
Permanently reverting to the non-DMA version of ili9341_bulk() isn't really
an option as the screen refresh is considerably slower.

It therefore appears that the "temporary" workaround I suggested earlier is
perfectly viable longer term, at least until someone can work out why the
DMA version causes issues.

The stack size changes also make sense.

I've extensively tested my own version of the firmware that includes the
fix and it works very reliably both with the usb commands above, and also
with nanovna-saver.

Rgds,
Dave

forgot

Hi Andy,

you make my day ;o)
The error was before the "nano" :o))
I had probably callibrated correctly, but was of the opinion DONE = Done, saved. I wondered why the Save window would appear again and again.
I confess, I didn't have time to read the manual yet, or was I of the opinion, as an experienced VNA user I wouldn't have to... the next mistake ...
But I promise to read the fine manual tonight (rtfm)

73 and thanks again for your help
Joe

Did you look at the phase of CH1?
If its coherent (not all over the place but a more or less straight line with frequency) then its not noise that is limiting the CH1 measurement but leakage from the SI5351.

Well folks, I just found a second load to put on Ch1 for a test.

Using my calibration method, with nothing on Ch1 at all, just open with a 50R load on Ch0 gives me about -80db noise floor at 250Mhz.
NOTE - That's an averaged figure in my head because there was plus/minus 5db variation on the readout anyway.
Plus/minus 5db, which could also have been advantageous at the right point if anyone was trying some comparison and not using averaging.

Then I did the same but placed a SHORT on Ch1 = no difference,

Did another re-calibration with a load on Ch1. Oh dear big surprise, about 6db WORSE.

Thermal noise in the load being introduced ?

Full reset and full calibration each time, repeated several times.

This was a genuine test, I'm not here to try prove me or anyone else right or wrong here. I just wanted some real evidence for a real education.

Well that's the test, make of it what you want folks ;-)

73 de Andy

On Wed, Sep 18, 2019 at 04:24 AM, <qrp.ddc@...> wrote:

For ISOLN calibration there is almost no difference if CH0 has load or not.
But it has noticeable lower noise with load on CH1.

That leads to the question on how to calibrate for best filter rejection measurements as many filters have impedance far from 50ohm outside passband.
Should you compare with isolation measured with 50ohm or isolation measured far from 50ohm????

Andy G0FTD>> Why not do a port isolation calibration using the 50R load supplied on Ch0, and the supplied SHORT on the input of Ch1 ?

Both ways - to use short or open on CH1 for isolation calibrate are bad. The amplifiers and other circuits have best performance at limited input impedance.

So, it's better to use 50 ¦¸ terminator to reduce noise. Because short or open terminator will leads to higher noise and as result worse calibration.

For ISOLN calibration there is almost no difference if CH0 has load or not. But it has noticeable lower noise with load on CH1.

On Wed, Sep 18, 2019 at 11:59 AM, <qrp.ddc@...> wrote:

Andy G0FTD>> Does anyone have data on measurements taken with or without ?

yes, here is measurement. First one is without load on CH1. And the second one
with load on CH1. As you can see, with load on CH1 there is less noise

Thanks.

I'd say that there's no discernible difference for S11 measurements (expected) but the lower limit of noise floor
has been extended by about 5db.

Not got my reading glasses on for my laptop though ;-)

So being able to measure a filter's attenuation at -80db rather than -75db @ 200Mhz (your marker) I'm presuming is the practical outcome ?

I won' pass comment on that, because for some users, -75db might be good enough, depends what the operator whats.

But I suppose 5db is 5db and in some cases that could be everything.

I've had another thought on this too.

Why not do a port isolation calibration using the 50R load supplied on Ch0, and the supplied SHORT on the input of Ch1 ?

Any noise drifting around entering the port would surely be eliminated too ?

73 de Andy

erik@, the black cable supplied with NanoVNA is a crap :) I don't recommend to use it for calibration or precise measurement.

It's better to buy 10-15 cm RG405 with soldered SMA connectors:

Andy G0FTD>> Does anyone have data on measurements taken with or without ?

yes, here is measurement. First one is without load on CH1. And the second one with load on CH1. As you can see, with load on CH1 there is less noise.

This is why CH1 needs 50 ¦¸ terminator for ISOLN calibration. The difference is not much, but it clearly visible.

Using a calibrated nanoVNA (0.5-900MHz) using the supplied black cables and a female-female barrel for connecting the calibration OPEN/SHORT/LOAD to the black cable connected to CH0 I tested if I could see any difference between having an OPEN connected to the female-female barrel connector to the black cable to CH0 or only the female-female connected to the black cable to CH0

I could not see the difference between with of without OPEN on the display of the nanoVNA at 900MHz.

But with or without the female-female from the black cable is very visible at 900MHz
Maybe I need better glasses, or a nanoVNA with a bigger screen.

Andy G0FTD, for proper calibration, you're needs to use all terminators (open, short and load) with the same geometry and length.If you will try to use different geometry/length load it leads to calibration error.

This is why you're needs to buy calibration kit instead of separate terminators from different sources.

I'm not sure if this cal kit supplied with NanoVNA is precise, but I tested 50 ¦¸ load from NanoVNA cal kit and it looks better than all other 50 ¦¸ loads that I bought on aliexpress before. So, it seems that supplied cal-kit is good enough for NanoVNA. But there are a lot of sellers and no guarantee that other NanoVNA will come with the same cal kit.