¿ªÔÆÌåÓý

On Wed, 18 Sep 2019 at 16:39, John Baines via Groups.Io <jbaines=
[email protected]> wrote:

Checking with my ¡®scope, at 7MHz I get 0.2V pk-pk which is -10dBm.

Passed through a 40m lpf it is still 0.2V pk-pk but the scope trace looks
a lot nicer!

Thanks for the help.

The filter will obviously chop off the harmonics,

The high-end VNAs, like the Keysight PNA-X, have the harmonics suppressed
by 60 dB or so. Obviously, they work a very different way to the NanoVNA,
but one could buy 10,000 NanoVNAs for the cost of even a modestly equipped
PNA-X,

73
John
M0JBA

On 18 Sep 2019, at 16:21, John Baines via Groups.Io <jbaines=

[email protected]> wrote:

Thanks Erik,

I¡¯m in the right ballpark.

73
John
M0JBA

On 18 Sep 2019, at 16:19, erik@... wrote:

-10dBm

--
Dr David Kirkby Ph.D C.Eng MIET
Kirkby Microwave Ltd
Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, CHELMSFORD,
Essex, CM3 6DT, United Kingdom.
Registered in England and Wales as company number 08914892

Tel 01621-680100 / +44 1621-680100

Rune,
The new "Using the software" section on your GitHub page () is much appreciated! The new pip installation also is nice, although on Windows I prefer to just download your release and run the executable from my "C:\NanoVNA" directory.

Nice to see the output verification with an oscilloscope. I guess in theory, with a completely different firmware it could be re-purposed as an extremely low power WSPR mode transmitter (0.1 mW)....but the catch being that an external clock of some kind would be needed to keep the proper transmission cadence. In the past I've had some success running WSPR mode at 0.1 mW power output. But I digress...what an amazing thing the nanoVNA is.

Checking with my ¡®scope, at 7MHz I get 0.2V pk-pk which is -10dBm.

Passed through a 40m lpf it is still 0.2V pk-pk but the scope trace looks a lot nicer!

Thanks for the help.

73
John
M0JBA

John,
From the specs below, expect -13 to -9 dBm. Since you are a ham, the power to voltage calculation should be trivial to you.

Basic Parameters:
- PCB: 54mm x 85.5mm x 11mm (without the size of connectors, switches)
- Measurement Frequency: 50KHz ~ 300MHz (50KHz -900MHz, enable extended firmware)
- RF Output: -13dbm (maximum -9dbm)
- Frequency Accuracy: ???0.5ppm
- Measurement Range: 70dB (50kHz-300MHz), 50dB (300M-600MHz), 40dB (600M-900MHz) enable extended firmware)
- Port SWR: < 1.1
- Display: 2.8 inch TFT (320 x240)
- USB Interface: USB Type-C; Communications Mode: CDC (Serial)
- Power Supply: USB 5V 120mA, built-in 400mAh electricity, maximum charging current 0.8A
- Number of Calibration Points: 101 (Fixed)
- Number of Scanning Points: 101 (Fixed)
- Display Tracking: 4, Marking: 4, Save Setting : 5
- Measuring S parameters, voltage standing wave ratio, phase, delay, Smith chart and the like

Thanks Erik,

I¡¯m in the right ballpark.

73
John
M0JBA

-10dBm

Hello Erik
Super if that is so then no open adaptor should be used for minimum fringe C not encountered for
It seems sensible not to embed anything in the firmware
I suppose more comment on the topic so lets see how it evolves
I will demonstrate the NanoVNA to night in the local Hamclub ?
Kind regards
Kurt

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

On Wed, Sep 18, 2019 at 06:39 AM, Kurt Poulsen wrote:

All in all clarification of the (bloody) 50/60fF would be nice

@Kurt,

Are you referring to the "open_model" data in the firmware?
I could not find any reference to that model in the firmware so I guess it is not used.

Hi all,

What output voltage should I expect from the NanoVNA into a 50 ohm load with CW FREQ selected under the STIMULUS menu.

73
John
M0JBA

On Wed, Sep 18, 2019 at 06:39 AM, Kurt Poulsen wrote:

All in all clarification of the (bloody) 50/60fF would be nice

@Kurt,

Are you referring to the "open_model" data in the firmware?
I could not find any reference to that model in the firmware so I guess it is not used.

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