开云体育

Yes, saver has some bugs. In particular I have noted some inconsistencies
when trying to set it for 401 pts on the H4 (it works better if I let it
use 201 or 101 pts and then let Saver control additional segments for more
points).

But please note that many of us who use it want Saver to be in control, and
do not want to worry about what state their device was left in before they
attach it. And we do any required setup through Saver.

You obviously have a different idea/use case. If you haven't tried
nanovna-app, you may find you like it better. In that app, you need to
understand that the many graphing and charting options are only seen after
right-clicking on a graph pane.

Stan

Hi
I have this hardware on this attached photo.

All seems running as expected except for the touchescreen , it's arratic .
i tryed to calibrate it , test function still showing erratic behavior and the menu is hard to handle.

Any help will be appreciated .
73's Nizar

On 5/15/22 3:00 PM, Rich NE1EE wrote:

That's just wrong.
Every time it connects, it reset the H4 to what someone else thinks it should be. The user should be the one to determine that. I even changed the Manage settings to agree with my device.
1. I could not change them until I had connected. Not good.
2. Even after connecting, changing settings, disconnecting....changed them back to some default.

I don't think I'll be using Saver much. Too many problems and bugs.

Maybe it's not the way to go for your use case.

Have you tried editing the .ini file?

That's just wrong.
Every time it connects, it reset the H4 to what someone else thinks it should be. The user should be the one to determine that. I even changed the Manage settings to agree with my device.
1. I could not change them until I had connected. Not good.
2. Even after connecting, changing settings, disconnecting....changed them back to some default.

I don't think I'll be using Saver much. Too many problems and bugs.

On 2022-05-15 17:58:+0200, you wrote:

clean socket AND plug!!

dg9bfc sigi

+1

clean socket AND plug!!

dg9bfc sigi

Am 15.05.2022 um 16:51 schrieb Zack Widup:

I use a Q-tip dipped in alcohol to remove the particles that accumulate
inside a female SMA connector. As for deformity in the center conductor, I
don't think there's much you can do for that.

Zack W9SZ

<>
Virus-free.
www.avast.com
<>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Fri, May 13, 2022 at 12:16 PM Roger Need via groups.io <sailtamarack=
[email protected]> wrote:

The # of mating cycles for a NanoVNA will be much lower than that of
commercial grade connectors for several reasons.

- Low-cost Asian connectors are used to keep the cost down
- Users often rotate the centre pin while tightening which "drills out"
the female SMA socket. A telltale sign of this is metal dust on the white
dielectric. (photo attached)

I use SMA connector savers on all my NanoVNA and TinySA devices. (photo
attached)

Roger

Electrical tape as a 'condom'. Put them in separate places could control mating.

--
KT0TT
Allen Kiddoo

On 2022-05-14 11:07:-0700, you wrote:

From your reference links it looks like the "offset delay" should be entered as a positive number representing the one way delay through the port extension. I have modified my fork of NanoVNA Saver to do this. You can download it from my Box account >>

I did download, and will use it on my next tests. Thanks also for the writeup. It is very useful to keep in mind when using Saver. I think that I must
start and connect nVNA to PC
start Saver
immediately config Saver to match nVNA
connect (button) Saver to nVNA...all to avoid Saver from changing my config. I will be testing this specifically, because it is annoying to setup the nVNA, only to find it changed after connecting to Saver.

I did try deleting the ini file, but it did not correct the behaviour I saw.

In addition, I read that Saver stops the nVNA from sweeping. I have seen this, and not been able to restart the sweep without power cycle.

I renamed it to Saver 0.4.1 Roger, to keep it separate from the others.

If you want to see this change in a future "official" version you will have to raise it as an "issue" on the NanoVNA Saver github >> . The developer zarath will decide if it will be implemented.

I will see how to do that.
~R~

On Fri, May 13, 2022 at 08:12 AM, Rich NE1EE wrote:

I wish that Saver would not automatically change the H4 when it connects.
I think the sequence should be to read the H4, and then we can change Saver
and send that to the H4.

The initial releases of NanoVNA Saver were developed by Rune B. Broberg for the NanoVNA-H and nanoVNA-H4. Unfortunately he became ill and development stopped at version 2. Further development of V3 codewas done by "zarath" and many changes and bug fixes were done with input from others. Other NanoVNA products like the V2 and -F were now supported and DiSlord's new transfer protocol was added to give faster sweeps. In order to get faster sweeps the display was frozen on the NanoVNA and unfortunately operation was not restored on the nanoVNA after exiting the program. So users have to power off and on again after using Saver.

Not sure how to do that, because there is a Manage dialog, but its use is not
clear, and when I try to use it I get errors.

The Manage entry screen was enhanced so that the number of data points used by Saver in transfer mode could be selected by the user. It defaults to 101 to be compatible with older NanoVNA devices and older firmware. With the -H4 you can increase the number of data points transferred in one sweep to 401.

If you are having problems with NanoVNA Saver it can sometimes be due to a corrupted .ini file. Just delete it and a new one will be created when the program starts. You will find it in this directory in Windows.
C:\Users\Your-User-Name-Here\AppData\Roaming\NanoVNASaver\NanoVNASaver.ini

Roger

On Sat, May 14, 2022 at 06:33 AM, Rich NE1EE wrote:

I actually don't know much about the VNA industry, so I am pleased to see this
write up. I found it curious to find

"Time The amount of port extension delay in time. Enter a positive value."

Rich,

From your reference links it looks like the "offset delay" should be entered as a positive number representing the one way delay through the port extension. I have modified my fork of NanoVNA Saver to do this. You can download it from my Box account >>

If you want to see this change in a future "official" version you will have to raise it as an "issue" on the NanoVNA Saver github >> . The developer zarath will decide if it will be implemented.

Roger

yes ... a short male to female adaptor is a good advice to keep the built-in connectors in good shape ... if worn out just replace :-)

i use a similar thing on my rf explorer (also sma connector)

hopefully those metal chips are from the pin of the plug (scraped off when turning on) and not from the socket

greetz sigi dg9bfc

Am 13.05.2022 um 19:16 schrieb Roger Need via groups.io:

On 2022-05-13 18:05:-0700, you wrote:

If you want to add an extension to a calibrated "reference plane" you can do this in NanoVNA Saver by determining the delay in picoseconds through the extension and entering this as a negative number in the Calibration screen. The negative number is by industry convention when a port extension is connected to a reference plane.

Please take all of the following bearing in mind that I am a VNA novice...it is nice to have this perspective on the table. I intend to search the forum for the threads mentioned...

I actually don't know much about the VNA industry, so I am pleased to see this write up. I found it curious to find

"Time The amount of port extension delay in time. Enter a positive value."

and
"Keysight Technologies Specifying Calibration Standards and Kits for Keysight Vector Network Analyzers"
Enter the delay from Table 1: OFFSET DELAY, 0.0108309, ns.

"Agilent_Advanced_VNA_calibration.pdf"
positive delay for port extension

"TTR500-User-Manual-077125400.pdf"
only mentions choosing twixt "Length Delay" and "Time Delay", but no mention of sign.
Enter the delay value as a length of lossless transmission line (m) or a measure of time (seconds).

"R&S� ZNB Vector Network Analyzers User Manual"
3.6.1.1 Definition of Offset Parameters The delay is the propagation time of a wave traveling through the transmission line. The electrical length is equal to the delay times the speed of light in the vacuum and is a measure for the length of the transmission line between the standard and the actual calibration plane....
In the "CHANNEL > OFFSET EMBED > Offset" tab, "Electrical Length, Mechanical Length" or "Delay" are coupled parameters. When one of them is changed, the other two follow.

"user-guide-keysight-agilent-n9923a-fieldfox-rf-vector-network-analyzer-2-mhz-4-ghz-6-ghz.pdf"
Emacs!


Everyone should understand that I take these snippets out of context, because I am not experienced with VNAs. But there is no "requirements spec" or "design spec" which would contain these specifications and their basis, at least in my business.

A nice video on this topic was done by W2AEW >>
It's a well-done vid on port extensions...

these is still the question of whether to enter the round trip delay ... it doesn't matter to the user if the software/firmware processes it as a round trip...
note that the extension produces a ?positive phase shift?, indicating that a negative phase shift might be needed to compensate..but that is not the same as a negative offset delay.
I see in the vid that the length is displayed as roughly twice what I'd consider the length of the extension used.

I usually start my delay estimates at length/(VoP*c). And then I double that for the nVNA.

When the author of NanoVNA saver implemented "offset delay" it was discussed in this group. The consensus was that it should be in accordance with the standard definitions used for calibration kit parameters. If a set of commercial loads is supplied they will provide this data. In fact one of the members of this group generated the parameters for the cal loads shipped with the NanoVNA and published them in this group. A screenshot of the calibration entry screen is below.

If you want to add an extension to a calibrated "reference plane" you can do this in NanoVNA Saver by determining the delay in picoseconds through the extension and entering this as a negative number in the Calibration screen. The negative number is by industry convention when a port extension is connected to a reference plane.

An example of this is attaching a 15.5 cm (6 inch) RG-316 cable to a calibrated VNA port. The velocity factor is about 70% so the "electrical length" of the cable is 22.2 cm. The speed of light is about 3.33 ns per meter so the delay is 3.33 * .222 = .74 ns or 740 picoseconds. Entering -740 in NanoVNA Saver gives the result below.

If we do the port extension on a NanoVNA-H4 we need to be aware that the device does not always conform to industry standards. For example the CH0 and CH1 ports should be designated as Port 1 and Port 2 (they are on later generation products). The firmware has had different developers and they chose to use the term "e-delay" or "electrical delay" and used it differently than "offset delay". The correct input for a port extension requires the "round trip" delay to be entered as a positive number . So in this case +1480 picoseconds is required. A screenshot after this entry is attached.

A nice video on this topic was done by W2AEW >>

Summary: NanoVNA Saver uses the conventional term "offset delay" and implements it correctly. Some NanoVNA firmware uses a different variable e-delay and users need to be aware of how to use it correctly.

Roger

The # of mating cycles for a NanoVNA will be much lower than that of commercial grade connectors for several reasons.

- Low-cost Asian connectors are used to keep the cost down
- Users often rotate the centre pin while tightening which "drills out" the female SMA socket. A telltale sign of this is metal dust on the white dielectric. (photo attached)

I use SMA connector savers on all my NanoVNA and TinySA devices. (photo attached)

Roger

On 2022-05-13 11:00:-0500, you wrote:

I have thought of this as well, but what they have done actually follows
the practice used on many commercial test instruments. I would like to see
them make the box green if on or gray if not. However, I realize that many
color blind operators would not benefit from that.

I don't think that we are using the same device! :-)
1. The MODE button shows what IS selected, not what WILL BE selected.
2. TRANSFORM OFF mean that it is OFF.
These are the reverse of what I suggest.
3. BUT...PAUSE SWEEP is the reverse of these!!! I suspect that is because originally it had check box, and now it has a text state change. But the confusing part is that it is reversed from the other 2.
I just happened to be using these today, and thought to write, but there might be others.

I think that it makes sense for the button text to change to what the button /will do/, but I am open to other ideas.

Perhaps you could be more specific about commercial test instruments?
I'm happy w color changes, too. I worked on an international project a short time ago, and we all agreed that we needed to have a 'color-blind' standard. We researched the options, and came up with a good range of colors.

Th H4 currently uses green to show that the selected cal is not the saved cal...something, such as the freq range, has changed. And when it is green, if you tap it, you get back the saved cal state. It could just as easily be a * on the button, just like in an editor. Again, I don't have a specific standard in mind. I would like to see the UI behave the same for every button.

I have thought of this as well, but what they have done actually follows
the practice used on many commercial test instruments. I would like to see
them make the box green if on or gray if not. However, I realize that many
color blind operators would not benefit from that.

On Fri, May 13, 2022 at 10:12 AM Rich NE1EE <TheDustyKey@...>
wrote:

I suggest that all buttons that can change state
- show the state that they will change TO, which is what we expect when we
see a button of any sort to press

TRANSFORM ON - should turn on transform
MODE MS5351 - should enable MS code
PAUSE SWEEP - should pause the sweep, and //there should be no check box//
The box is superfluous, because the button text provides context, and the
box is confusing because its check state is not clear.

I might have missed some.

--
Eric M. Gildersleeve ~ KD7CAO
Google Voice: 940-784-3029

I wish that Saver would not automatically change the H4 when it connects.
I think the sequence should be to read the H4, and then we can change Saver and send that to the H4.

Not sure how to do that, because there is a Manage dialog, but its use is not clear, and when I try to use it I get errors.

I saw a post about problems with Saver, and the ini file, so I renamed mine, and ran Saver.

I have a cal that is reliable.
The H4 shows the proper e-delay and phase change for an SMA adapter and for a coax extension.

Saver?
Rats. The e-delay is way off...
Then I looked at it not for its value, but for how it related to the H4.
It is half the H4.
The delay in Saver was 730 ps and when I shutdown Saver, disconnected, and restarted H4, I put 1460 ps in e-delay. That zeroed phase.

This is another example of how the lack of consistency across product lines and the lack of docs causes problems.

I don't understand why some earlier posters in threads related to this didn't comment. Surely mine cannot be the only H4 and Saver combo that works this way. I don't care which method is used, but I should not have to experiment to see what fields mean.

I suggest that all buttons that can change state
- show the state that they will change TO, which is what we expect when we see a button of any sort to press

TRANSFORM ON - should turn on transform
MODE MS5351 - should enable MS code
PAUSE SWEEP - should pause the sweep, and //there should be no check box// The box is superfluous, because the button text provides context, and the box is confusing because its check state is not clear.

I might have missed some.