开云体育

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.

U.FL connector mating cycles (from recent personal notes)

U.FL plugs and sockets. I just finished giving an intro lecture to NanoVNAs using these connectors. Went very well. I had read all the negative comments about U.FL connectors, and was concerned about how all that would go. I didn't want to be in the middle of the demo, and have a cable fail. After struggling with a few connect/disconnect cycles, I used a loupe to look at the U.FL plug and socket. I noted that the slotted flexible /sides/ of the /plug/ housing --- the parts that keep the plug in/on the socket --- are /open/ on the coax end, and there is a part of the housing that rounds the /end/ of the /plug/. Also, the internal part of the U.FL /plug/ that grips the socket pin is designed to rotate vertically in line with the coax axis, /not/ rock side-to-side. So I developed the habit of attaching the U.FL by "hanging" the end of the plug on the lip of the socket, then rotating the plug down toward the board in line with the coax axis. To get it to snap into the socket, I'd apply gentle pressure right at the plug as I was rotating downward. Removing is the opposite. I 'd guide it off as I lifted the coax end of the plug //using the fitting, not the coax//. I was concerned at first about them being "loose", until I learned that "looseness" is part of the design. I have used the same pair of SMA-U.FL extensions ~100 times, and there is no degradation of the connector, at least at this level of use. I don't get signal glitches, static, broken contacts, or changes in signal quality with the NanoVNAs. I think that many are too rough on the connectors.

Hirose Electric specs the mating cycles at 30 (2021), but experience shows mating cycles in the hundreds with no damage are possible. "Damage" is defined as noncompliance with any electrical specifications. Mating force seems to decrease. Two Uni EE profs I know relate that they are in regular use. The same mythology (mating cycle limits) (see also SMA connector mating cycles) applies to SMA and U.FL (I-PEX MHF) connectors. One of the manufacturers docs actually discussed how to mate and disconnect them.

U.FL male has a pin. U.FL has gender that is counter to typical RF terminology for gender, in that "jack" is more typically synonymous with "female". A U.FL jack on a PCB is the male U.FL

U.FL-IPX-IPEX MHF

I saw at least one tool ~$20USD that seems to do what I do connecting and reconnecting. It was very useful to me to see the connectors close up.



Attached images are from my presentation. One shows a well-used connector with minimal wear, the other with arrows pointing to the important details that I discussed. I continue to use them with homebrew boards.

~R~
72/73 de Rich NE1EE
The Dusty Key
On the banks of the Piscataqua

SMA connector mating cycles (from personal notes)(just an opinion; we've all got them ;-)



Mythology related to a MAX number of mating cycles seems to be related to a MIN specified in SMA specifications in MIL-C-39012.

When mating typical SMA connectors to 3.5 mm or 2.92 mm precision connectors the cycle specification is significantly degraded.
Manufacturing grade SMA connectors are not defined in the precision connector standard.
However, a "true" SMA manufactured to IEC 169-15 "Grade 0" specifications will mate with 3.5 mm and 2.92 mm connectors with minimal degradation in connector life cycle results.
The pin diameter specification for these "true" SMA connectors is in the same range as the precision 3.5 mm connectors.

The specifications are based on actual test data.
The test results "specify the minimum number of manual connection/disconnection operations of a connector pair under laboratory conditions that will not result in damage�.
"Damage" is defined as noncompliance with any specifications.

Connector Family Cycles
3.5 mm 3000
2.92 mm 2000
2.4 mm 5000
1.85 mm 4000

SMA and 3.5mm are mateable connectors.
The SMA connector is an economical, lower performance interface.
Mechanical tolerances, stability, temperature performance, SWR, repeatability, loss, and wear are all much better in the 3.5mm interface.

Cleaning the threads periodically may result in smoother mating.
See also U.FL connector mating cycles

~R~
72/73 de Rich NE1EE
The Dusty Key
On the banks of the Piscataqua

Rudi (DL5FA),
As Larry said, this is a goldmine of information and education especially for those of us who are not RF engineers by training but whose education and work-life intersected heavily with this discipline.
Thanks much.
will
w6swf

Hi,

It is a long time ago now that you experienced a startup error of NanoVnaSaver.
I do not know if it still actual for you, but recently I had the same startup problem with this application.
Normally the application does also startup without a NanoVna connected to your computer.
First I tried a newer version of this application. Same startup error.
In the promptscreen that you see on your picture made of that screen you see a line "Settings............./NanoVnaSaver.ini
If you delete that file (first copy this file to a temp folder as a back up) then a new ini file is made as soon as you restart the application NanoVnaSaver.exe
The application should startup the measurement screen now.

I hope this helps.
Kees, PE0CWK

On Fri, Apr 29, 2022 at 11:02 AM, Rich NE1EE wrote:

I have ordered 2 RF demo boards, one from DeepElec and one from NWDZ --- maybe
--- and I look forward to playing with them. I don't know what questions they
will raise, but when it comes to 2-port measurements, I don't have the
experience, so it will be fun learning.

Rich,

I wonder how your testing has gone with the NWDZ RF test board. I measured all the test positions and it was an interesting exercise. The quality of my NWDZ board was quite good. The SMD resistors were not factory sweeps but precision resistors. A nice Smith Chart Reference on the back.

The 5 dB attenuator measured -4.9 dB to -5 dB from 50 kHz to 400 MHz. The 10 dB attenuator measured -9.9 dB to -10.05 dB from 50 kHz to 400 MHz. 33 ohm resistor was 32.85 to 33.15 up to 450 Mhz. with about 1 nH of inductance.

Others have mentioned before that the weak part of the design is the u.Fl connectors. I took care when installing and removing them (used a small screwdriver to lift) but after 30 or so cycles they were beginning to show some wear. Attached are some magnified photos of the female showing how they deteriorate. Also a picture of the 5 dB attenuator position to show the assembly quality.

My board and connectors cost about $11 USD on Amazon so it was an inexpensive purchase for a few hours of fun.

Roger

I did a new cal on the H4. It turned out as before, so the old cal was good.

Here are my notes.

H4 phase 1.5 after cal, no cal devices attached. w coax (75 VoP) extension, 1475 ps delay to correct, phase -13.6
After power cycle, phase 1.8 !!
connected coax again, phase -17.0, delay 1460 ps to correct
So...it seems that I need to cycle power after a cal, and then reload the cal. Hmmm...every time I checked, after the first time, the results were close enough.

Saver v0.4.0 - what a mess. Windows 10 x64.
phase1.81 Error during sweep Stopped list index out of bounds
Manage. Don't know how this actually works.
Change to 101 point (H4 is 401), BANDWIDTH to 1000 Hz (H4 is 100)
No error this time, so it seems that Saver doesn't like 401 points. S11 phase -17.14, Saver apparently stops H4 from displaying the sweep, so tapping on screen updates. No. Not always.
Delay -731 ps - no delay applied in H4
Saver left H4 in unstable state, so cycled power
Saver after App
H4 phase -17.1, Saver -17.09
Saver delay -730 ps. as before.
** Note here that Saver is still reporting a delay way off from the H4 and App. And that these values are in the ballpark of what I observer previously, so Saver is consistent. I don't know what I am doing different from you folks, but I sure don't get useful delays. Sure the phase goes to zero, but the delay is way off from the H4 and App.

App v1.1.208 1.783
After power cycle, no delay on H4, phase 1.789
w coax (75 VoP) extension, H4 phase -17.1
App phase -16.84, delay 1463 ps
Disconnected. Closed App. H4 still sweeping.
Checked points, delay, bandwidth...all unchanged, BUT Saver changes those in ways I don't understand yet.
** At one point, App went into a loop on access violation. Needed to kill it. Wouldna shutdown.
Reran Saver. See above.
So at least App is in the same range as the H4. But they should all agree much closer than this. It's all just number crunching. Same numbers, should be same results.

If there is some trick to running Saver, I'm open to suggestions.

On 2022-05-12 15:23:-0700, you wrote:

Finally, NanoVNA Saver versions 2.2 and 4.0 were used with calibration done on NanoVNA itself. The offset delay was done in Saver. S11 phase was flat with - 14.56 nanoseconds required which is the one-way delay and negative in sign.

Summary - Offset delay was equivalent for all cases but required taking half the round trip delay and negating the sign for NanoVNA Saver. One wonders which one of these methods is used in commercial analyzers......

thanks for confirming
~R~

On 2022-05-12 11:57:-0700, you wrote:

H/H4 firmware by default apply internal delay if set and after send it ti CPU. You must reset on device before use Saver software.

Thanks...I was using an existing cal, and was resetting the delay to zero before connecting with the software. It makes sense that the delay will be sent to Saver if Saver uses VNA calibration.

I was puzzled by 2 things
1. The calibration I /thought/ I did a few days ago is actually off by 20 degrees now
2. Saver did not apply the same offset to get the same sweep to 0 phase degrees

I will reset, recal, rerun Saver. Having several ops here report that Saver worked as expected means that I don't have the cal I thought I had.

~R~

On Thu, May 12, 2022 at 08:46 AM, Rich NE1EE wrote:

Just tested -App v 1.1.208
It needed -1750 ps where I expected the same.
It is interesting that I calc the delay based on one way, but the H4 displays
it as round trip.

I attached 3M of RG-316 to a NanoVNA-H4 and used the TDR function to calculate the round-trip delay. It measured 29.5 nanoseconds.

Then the offset delay was adjusted on the NanoVNA until the S11 phase was fairly flat. Offset delay required +29.1 nanoseconds. Screenshot attached.

Next the NanoVNA was connected to NanoVNA app. +29.1 ns offset delay was required in the NanoVNA app program. Measurements were done using calibration the NanoVNA app and with NanoVNA calibration.

Finally, NanoVNA Saver versions 2.2 and 4.0 were used with calibration done on NanoVNA itself. The offset delay was done in Saver. S11 phase was flat with - 14.56 nanoseconds required which is the one-way delay and negative in sign.

Summary - Offset delay was equivalent for all cases but required taking half the round trip delay and negating the sign for NanoVNA Saver. One wonders which one of these methods is used in commercial analyzers......

Tested NanoVNA-H4 with Saver Version 4.

Offset delay works OK - same as version 3.10. Note S11 phase is flat after delay added....

Roger

H/H4 firmware by default apply internal delay if set and after send it ti CPU. You must reset on device before use Saver software.

On 2022-05-12 15:32:+0200, you wrote:

Exactly the same measurements made (from 50 kHz to 50 MHz).
Calibrated with SDR-Kits BNC Cal Kit.
Measurement done with NanoVna -H4 (fw. version 0.5.0) and NanoVna Saver version 0.3.9
Cable used: RG58 A/U

In your image, I see -1540 ps of correction. The value agrees w a VoP of .66 and .305 m of coax.
When do we expect to see a negative angle?
I cal'd with ~175 mm extensions, then when I ran the test this morning, I simply didn't add them. I got a +20deg phase, and needed -1750 to correct. But that seems to imply that you did the same, and I kinda imagined that you slapped a 1ft piece of coax on the calibration plane. When I do the same (add some coax), I get a +phase shift, and the H4 needs +1750 of delay.

Comment?

Just tested -App v 1.1.208
It needed -1750 ps where I expected the same.
It is interesting that I calc the delay based on one way, but the H4 displays it as round trip.

I ran a quick test this morn. Don't have time to investigate, BUT

nVNA-H4 v4.3_MS, firmware 1.1

Saver 0.3.10
Seemed to work better than 0.4, but still puzzling. On -H4, I corrected by -1750ps, as expected. In Saver, +900ps, even though it displayed the same phase angle to begin with.

Saver 0.4.0
Does not connect as reliably as 0.3.10

On both, as I change settings on the H4 and in software, I wind up with index errors, and the only way I can see to get around them is to restart both.
Both applied some correction immediately upon changing Offset Delay.

The important info is that both software versions report a different delay to offset the same phase.
~20deg CCW phase
H4 correction -1750ps
both Saver versions, 900ps