开云体育

Hi hwalker
One comment to you BNC calibration test. Are you cal kit home made with three bulhead adaptors where 2x100 ohm SMD fitted to the centerpin as load and the open as well the load has the center filed down flush with the rear of the adaptors and the short is with a copper or brass disk soldered to the rear then you are "calibrating to the rear" and not to the BNC reference plane then you pretty well calibrated as such a kit is sort of ideal. However if another sort of kit you are trouble by delays in open and short and load may be quit reactive inductive or capacitive you do not encounter for.
The NanoVNA-saver has facilities for entering such delays of short and open.
Kind regards
Kurt

-----Oprindelig meddelelse-----
Fra: [email protected] <[email protected]> P? vegne af hwalker
Sendt: 19. september 2019 00:47
Til: [email protected]
Emne: [nanovna-users] Electrical Delay_Port Extension

Most of the RF equipment I own have BNC connectors, so one of the first things I did was install SMA-BNC adapters on channels 0 and 1 of my nanoVNA. After recalibrating using a 50 ohm BNC OSL kit, the Smith chart display looked as expected when BNC OSL standards were sequentially connected to CH0. BNC mismatches of 33, 75, 100 and 150 ohms all looked good with expected return losses. I saved the BNC calibration data in "SAVE 1" and retained the original SMA calibration in "SAVE 0" in case I need to remove the SMA-BNC adapters.

qrp.ddc's discussion in group regarding the electrical delay menu option reminded me of how the port extension feature of the HP8753C was used to correct for an adapter attached to the native "N" connector. The HP8753C has a menu option allowing you to enter an electrical delay value, extending the measurement plane out to the end of the adapter and correcting for its additional length. I wondered if this would work with the nanoVNA and so tried the following:

1.Turn on nanoVNA. With nothing connected to the CH0 BNC adapter, the Smith chart displays an open with a tail corresponding to the reactance of the SMA-BNC adapter.

2. On the nanoVNA select DISPLAY_SCALE_ELECTRICAL DELAY.

3. I didn't have a clue as to the electrical delay value for the SMA-BNC adapter, so starting at 100 (ps?) I tried successive values until the nanoVNA displayed a single dot with no tail to the far right of the Smith Chart display. The value needed to achieve this for my SMA-BNC adapter was 180 x 1 as entered on the nanovna screen keypad.

4. With BNC OSL standards sequentially connected to CH0, the results looked almost as good as the original SMA calibration data.

5. BNC mismatches of 33, 75, 100 and 150 ohms looked as good or better than the values obtained during the earlier calibration using my BNC OSL kit.

6. I saved the port extension corrected data in "SAVE 2" .


Thanks qrp.ddc for pointing out the electrical delay menu option and how it could be used for correcting for port extensions. For those users that want to add different adapters to channels 0 and 1 but don't have a suitable OSL kit to correct for the adapters, give the electrical delay menu option a try.

Hi. I just bought the NanoVNA and want to make some tests on some LNAs.I have 2 SMA 20db Attenuators.How to setup the VNA & how S11 is important in the Tuning.Very thanks for answers.Regards Sid.

Edit:
A warning. I was inspired to use another USB-C cable. Very strange is that with the supplied USB (black) cable the NanoVNA won't start connected to the PC.
I did a test with a self-purchased (white) USB-C cable, and guess what: the NanoVNA will now start up if it is connected to the PC when I press the PWR switch.
So be careful with the supplied USB cable.

With all that new firmware, I now work a lot with the NanoVNA connected to the PC. With my modification in message # 967 I can start the NanoVNA with the placed switch on the IP5303.
But once connected via USB to the PC, that is no longer possible. As soon as the USB is connected to the PC, I can no longer start up, and the circuit of the IP5303 no longer works.
When disconnecting the USB and reconnecting, the NanoVNA will start up, but then the running PC program will be interrupted. Someone a solution?

Hi Andy,

Hi, Andy,

but your call also seemed familiar to me ;o)
Yes, it's true, on 17.07.2017, in the morning at 04:30 I had a direct hit in my LF antenna. The antenna was disconnected but unfortunately not grounded. Because of this the flash could jump over to the VHF/UHF mast, 6m away. So it was in the shack and left a smoking ruin :o((
I found parts of the 4m transverter 15m away, around the corner, which must have flown like projectiles through the shack. All 3 main fuses (63A) it "atomized". All electronics in the house were destroyed, even sockets were blown out of the wall. I could repair a lot since then but a lot is lost.
In the meantime I have also changed the QTH and only very limited antenna possibilities. But this will change in spring, when we move to a farm at the Dutch border, with a lot of space.
Then the grabbers will go online again. At the moment I'm experimenting with a frame antenna on LF/MF incl. transmission attempts, but so far nobody has heard me in WSPR. The power from the Ultimate 3 is too low, but I'm working on a small 400 W PA, with 50 - 70 W in the frame I should be heard then, hopefully ;o)))
Information about the frame experiments can be found here:

73 Joe

Hi Hugen,
this sounds very good! Are you looking at expanding the
frequency/measurement range by a change of components as well?

I'm happy to hear that you will stay consistent with the NanoVNA, but any
necessary improvements to the commands will, of course, be quickly
implemented by the application developers. :-)

--
Rune / 5Q5R

Using the cho45’s web interface can use nanoVNA very good on the phone , I think this is a very good expansion screen scheme. I'm also trying a 3.5-inch LCD, maybe working with the STM32F303 to create a new NanoVNA, and I want to be as consistent as possible with the NanoVNA for better community support. NanoVNA-F is a very good project to use a larger LCD, but it uses the expensive MDK compiler.

Thank You！

hugen

This is the latest version of the edy555 that includes the TDR feature. I have modified the touchscreen calibration value before compiling and can be used directly with the 2.8-inch NanoVNA.

Done

Maybe it would fit better in the Firmware section? ;-)

Good work!

--
Rune / 5Q5R

I pulled edy555 release 0.1.1 and merged with my scan command extension

/g/nanovna-users/files/NanoVNA%20PC%20Software

Contains an experimental TDR functionality and 1500MHz as upper limit

Yes,

I did send him a pull request to have the my scan command in his code as his scan command does not work

Hi Andy,
what errors are you seeing?

--
Rune / 5Q5R

On Thu, 19 Sep 2019 at 10:01, Andy G0FTD via Groups.Io <punkbiscuit=
[email protected]> wrote:

OK thanks for the feedback.
I just wanted to know before I took the time to start testing, and
possibly avoiding a learning curve.
That would have been nice, because I can get vnaJ working fine on a
Raspberry Pi.
Unfortunately I can't with Rune's Python software.
After a lot of messing about upgrading Python and getting modules
installed, I got a errors.
I just thought it might be a back door route for Pi users.
Not a real problem since I can run it perfectly ok on my Linux Mint 18.3
system.


73 de Andy

OK thanks for the feedback.
I just wanted to know before I took the time to start testing, and possibly avoiding a learning curve.
That would have been nice, because I can get vnaJ working fine on a Raspberry Pi.
Unfortunately I can't with Rune's Python software.
After a lot of messing about upgrading Python and getting modules installed, I got a errors.
I just thought it might be a back door route for Pi users.
Not a real problem since I can run it perfectly ok on my Linux Mint 18.3 system.


73 de Andy

No, it cannot. I spoke to Dietmar about him making changes or facilitating others by opening the source, and he was not in favour of either case.
-------- quote -----------
Yes, I’m aware of a bunch of cheap VNAs – but I do not find the time to support them all – sorry to say this.

vna/J is closed source due to some reasons …
-------- quote -----------
We can ask why he takes this position, but it's his software and his prerogative.
It may be possible to take the other route - modifying the NanoVNA code or shimming the interface to provide compatibility that way. There would be a degree of reverse engineering the protocols used by VNA/J.
/ Gerry

On Thu, Sep 19, 2019 at 04:22 AM, Tom VA7TA wrote:

The return loss of my low cost Asian SMA/BNC adapter with my 50 Ohm DIY BNC
load seems surprising good at 53dB/VSWR 1.005:1 up to 450+ MHz.

In my case the return loss of 53dB at 450 MHz equates to less than 1.005:1 VSWR.

According to S1P file that you shared above, your BNC has VSWR=1.008 at low frequency (below 100 MHz) up to VSWR=1.0953 on 800-900 MHz.

Hi Erik,
As far as I could tell, the "official" firmware also moved to 1500MHz now.
I see there's also a scan command in the code, but it's commented out. Have
you had any communications with edy555 on including it? ?

--
Rune / 5Q5R

On Thu, 19 Sep 2019 at 02:22, Tom VA7TA <tma.7ta@...> wrote:

Greetings All,

Many thanks for your interest and info! This thread has been very helpful
for me and I hope also found useful by others.

The return loss of my low cost Asian SMA/BNC adapter with my 50 Ohm DIY
BNC load seems surprising good at 53dB/VSWR 1.005:1 up to 450+ MHz.

I may have misunderstood your point here, as I am not 100% sure of what you
are saying. I apologise if I have misunderstood you.

There’s no way you can *measure* a 53 dB return loss. You can get
circumstances where you can *display* such a high return loss, but your
uncertainty would be *huge*. I have some very expensive VNA calibration
kits, one of which costs over $20,000. None of them have loads with a
specification of even 50 dB, and it be obvious that one can not measure
anything better than the load used during calibration. In fact the
calibration standard needs to be much better than the device you are
trying to measure.

There seems to be concern about the use of the BNC connector series with

the NanoVNA. The BNC connector series specification states a maximum VSWR
of 1.3:1 to 4GHz. In my case the return loss of 53dB at 450 MHz equates to
less than 1.005:1 VSWR. But even if my SMA/BNC adapter presented a somewhat
higher mismatch the resulting Z discontinuity would be compensated for by
the calibration process.

This is where I am concerned that I might be misunderstanding you, so I
apologise if I have done so.

However, the directivity after calibration will not be that high.

Without question the SMA connector series has much better impedance

characteristics than the BNC series and can be used at much higher
frequencies but I wonder if there is much practical difference for VHF and
lower frequency measurements.

No, there’s not.

The practical use reality is that for most common amateur radio

applications the NanoVNA SMA connection will need to be adapted to some
other more commonly used connector series for doing most measurements.

Agreed. I would however suggest that the VNA has a good solid large
connector, then you adapt that to a smaller connector if required. That is
why all modern professional VNAs under 18 GHz use N connectors.* I
personally believe that the only sensible connector to use, even on an
amateur product, is N. *Unless one goes above 18 GHz, stick to N.

My HP 8720D works for to 20 GHz, so is outside the specification for N
connectors, so 3.5 mm is used. That mates with SMA, so is physically not a
good idea. However, to get around that, there’s a special sort of connector
called NMD, designed to given a good stable connection, even where the



which has a large nut on it, that’s 20 mm across the flats. It is a bit
difficult to describe, but some characteristics of it are

* The male 3.5 mm connector on the VNA will mate with a female SMA, but it
is not intended to be done.
* The cable that fits onto the female connector can not mate to a standard
SMA connector.

If people want I can post some pictures of the bizarre, but well thought
out 3.5 mm NMD connector. But it would have no practical use on any VNA
under 18 GHz.

The bottom line for myself is that after doing this batch of measurements

and discussing them here I now have a much better understanding of the the
NanoVNA capabilities. I think it will serve me well for my applications.
Many thanks again for the help!

Good. I believe that it will serve 99.99% of all amateur applications. The
only exception I can think of up to 300 MHz, would be for those tuning
cavity filters and duplexers, where a better dynamic range is needed. For
those, even the 100 dB dynamic range of my laboratory VNAs is not ideal.

Enjoy!

Tom
VA7TA

Dave.

--
Dr. David Kirkby,
Kirkby Microwave Ltd,
drkirkby@...

Telephone 01621-680100./ +44 1621 680100

Registered in England & Wales.
Company number 08914892.
Registered office:
Stokes Hall Lodge,
Burnham Rd,
Althorne,
Chelmsford,
Essex,
CM3 6DT,
United Kingdom

Gary,

Edy555 increased the stack size of one of the threads and as my firmware is tracking his changes (as it is identical except scan command and 1500MHz upper limit) I will be releasing a new firmware soon
But it might be a good idea to also test edy55 his firmware to eliminate possible causes

The challenge in the resizing - it already works for most of them - is
having the "square" ones not resize out of square ? I've tried to get that
to work, but I think they need another shot - and a smaller minimum size.

--
Rune / 5Q5R

On Thu, 19 Sep 2019, 07:51 Jeffrey Vandenbroucke, <jeffrey@...>
wrote:

Yeah, the "about" was an easy victim to hide, but I agree it needs to stay
:) Collapsing widgets would probably be the most handy thing. Responsive
charts should be doable, I just think you would need to put them in some
kind of subthread. If the window then gets resized, the charts are redrawn
(with a chartWidth and chartHeight minimum defined as to not have errors in
your calculation which would lead to negative values).