开云体育

On 7/22/21 2:48 PM, Kent AA6P wrote:

Dave - I had one other thought. Would differences in Velocity Factor explain the different results?

The velocity factor can vary quite a bit across different types of coax. I really noticed that when using the TLDetails program from AC6LA software. There is also a big difference between solid dielectric and foam.

A different velocity factor would change the electrical length of the transmission line. That would change the frequency differences between the various peaks and valleys.

I believe my cable is 14 feet 10 inches plus another 6 inches for the SMA to SO-239 adapter.

Sure.. what phase shift do you measure with the far end open at your frequency of interest.. Divide by 2, and that's your cable length (electrically)

My new NanoVNA-H is working very well - it is an impressively capable, wonderful, little device!

I send along very big Thank-You's to edy555, HuGen and those who provided earlier designs for the hardware, to DisLord for new firmware, to Rune Broberg for the great NanoVNA-saver software that makes the hardware more practical and a delight to use and to all those others who have and continue to support this project. You have created a remarkable package that provides utility and pleasure to many people.

Best wishes to all of you.

Dave - I had one other thought. Would differences in Velocity Factor explain the different results?

The velocity factor can vary quite a bit across different types of coax. I really noticed that when using the TLDetails program from AC6LA software. There is also a big difference between solid dielectric and foam.

A different velocity factor would change the electrical length of the transmission line. That would change the frequency differences between the various peaks and valleys.

I believe my cable is 14 feet 10 inches plus another 6 inches for the SMA to SO-239 adapter.

73, Kent
AA6P

On Thu, Jul 22, 2021 at 10:07 AM, Lou W7HV wrote:

Certainly in production you can run into problems relying an unspecified
characteristic of a component. Those characteristics may be different from
different vendors

That's why you have an approved vendor list, and only allow purchasing from that list. You still have to worry about the possibility of your approved vendor changing their part, but at least you don't have to worry about the vendor-to-vendor variations.

A company I worked for once upon a time had to recall and rework a considerable amount of product after the purchasing agent bought something that engineering hadn't approved, because "the salesman said this was just as good." It wasn't.

Thanks so much Jim, Dave, and Ron for your replies and all the information. I really appreciate the modeling and all the documents. I will need some time to review and understand all this information.

The coax is marked RG-58A/U on the outer jacket. It was purchased 40 years ago but is in perfect condition and has never been used outside. It is a smaller diameter than RG-8X or RG-59 and requires a thicker reducer when used with a PL-259 connector. I am actually using a UG-176 reducer but with some RG-8X outer jacket placed over the smaller coax.

The Smith Chart circles are centered on 50 ohms. I tried a 25 foot length of RG-8X and the Smith Chart circles were also centered on 50 ohms. However, with the longer feed line the frequency difference between the various peaks was about 15 MHz rather than 24 MHz.

I'll check the Smith Chart one more time with the RG-58A/U.

I attached an image of the adapter used for the calibration at the end of the coax cable. It may not be ideal, but it appears to work over a reasonable frequency range and it also allows use of the SMA calibration standards supplied with each NanoVNA.

73, Kent
AA6P

Raspberry Pi wants to be a Bluetooth host, not a Bluetooth client.

I’m sure there are ways to do it the other way around, but it doesn’t work that way out of the box.

73, Willie N1JBJ

On Thu, Jul 22, 2021 at 09:55 AM, Jim Lux wrote:

Then you can use any wireless interface available on the Pi

Funny you posted that.
I am up to my eyeballs in playing with Bluetooth and just found out that NOBODY can tell me what is the passcodde to get into RPi.
My OS identifies two HC_05 and I can get in one with 1234 passcode.

It does identify my RPi with name, but I do not know the passcode .
Tried 0000 and it did not work.

Well I got RPi few inches next to nanoVNA but I think just replacing the USB cable with Bluetooth would be more KISS.
I think if you "warm-up / /charge" the nanoVNA first then replace the cable with Bluetooth would be slick.

On Wed, Jul 21, 2021 at 06:27 AM, Jim Lux wrote:

On 7/20/21 7:11 PM, Roger Need via groups.io wrote:

How did you calibrate? If you keep clips at a fixed distance during

calibration and measurement you will get better results.

calibrated using a 50 ohm BNC load, a BNC short, and left it open.

Yes, if I were to tape the leads down, it would probably work better,
but this was a first try at a "rough and ready" measurement

You will get much better results if you calibrate using the clips as the "reference plane". You just clamp them in a fixed position a short distance apart and then use a shorting wire, an open and a 50 ohm resistor (two 100 in parallel with short leads) to calibrate. Results are OK for HF but not much above that.

For serious measurements you need a much better test jig. I use this one made from an SMA female connector and some pin sockets/

Roger

Or, even better, designing the circuit so it doesn't rely on undocumented behavior.

Certainly in production you can run into problems relying an unspecified characteristic of a component. Those characteristics may be different from different vendors and may become different from a given vendor if it changes is process, materials, or design in ways the doesn't affect and may improved the specified characteristics. If you really need or want to do that, lot testing of that component can help spot potential problems. .

On 7/22/21 9:39 AM, Anne Ranch wrote:

You do not have to talk me out of soldering to the CPU.
I am really not trilled to do that anyway.
As far as model number - the battery seem to be "superguled" with sticky tape ( ?) so I did no attempt to
remove it. But the model # is irrelevant at this point anyway.

Being a coding geek I just got this "brilliant " idea.
The nanoVNA communicate with PC using USB - we have working nanoVNA-saver -
so why not
add another USB device - USB works in parallel - sort off - that device being ordinarily
Bluetooth adapter ( USB to Bluetooth )
and add this adapter as another means of communication

Or even better - replace the USB cable connection with such external ( no soldering to CPU ) USB - Bluetooth adapter .
All done in software...

PS anybody ported Python to C /C++ ?

If you're going to do that, why not just slap a RPi on the back of the NanoVNA.? Then you can use any wireless interface available on the Pi - I've used VNC over WiFi to run NanoVNA-saver on the Pi talking to the NanoVNA.? $50 and a battery for the Pi and you're done.


I have done some limited recoding of algorithms originally in Python to C, but one comes up against the question of "why?"? - For all the things one might do with a NanoVNA, none are particularly compute intensive, so as long as Python runs on your chosen platform, there's not much need to move to C to get better performance.

If you wanted to try and write a C "interface handler", I'd just start with something like nanovna.py (which is basically a command line interface to the nanovna, with more sophistication than the native USB serial interface) and write the code in C to do the same things as you need.

Another possibility is to use a Pi (or something cheaper/smaller) to just be a RFC2217 server for the USB/Serial port, and then run whatever you want, with the "serial" connection over the wireless interface of choice.

You do not have to talk me out of soldering to the CPU.
I am really not trilled to do that anyway.
As far as model number - the battery seem to be "superguled" with sticky tape ( ?) so I did no attempt to
remove it. But the model # is irrelevant at this point anyway.

Being a coding geek I just got this "brilliant " idea.
The nanoVNA communicate with PC using USB - we have working nanoVNA-saver -
so why not
add another USB device - USB works in parallel - sort off - that device being ordinarily
Bluetooth adapter ( USB to Bluetooth )
and add this adapter as another means of communication

Or even better - replace the USB cable connection with such external ( no soldering to CPU ) USB - Bluetooth adapter .
All done in software...

PS anybody ported Python to C /C++ ?

There were MMIC amps that liked using carbon composite as the bias resistor,
since the large temperature coefficient made it well matched to keep the MMIC
biased properly.

Such is part of the art in electronics. But if a designer wants to get an advanced degree in electronic art, then he also needs to match the composition resistor's long-term drift to that of the MMIC! ;-)

Attached are some useful info for making VHF and UHF reference dipoies including a neat design for an impedance matching balun using semi-ridgid coax.

Thanks for the explanation. It's been quite a while since I studied the system design.

Have Fun!
Reg

Is it possible that your coax is not really RG-58A/U?

I created an EZNEC model of a free space 340 MHz inverted vee. The element lengths and angle between them were optimized for a 50+j0 ohm feedpoint impedance at 340 MHz. The complex feedpoint impedance between 200 and 500 KHz was then calculated over 101 steps and exported to SimSmith.

In SimSmith, 15 ft of various types of coax were added. The results are interesting. (This could have been done in EZNEC, but I find it easier to use SimSmith for this type of thing.)

With 15 ft of 75-ohm RG-59, the FREQ vs SWR plot looks almost identical to yours. The lowest SWR is at 352 MHz which is very close to the 353 MHz point you observed. My plot is attached.

Here's a quick and easy way to tell whether your coax is 50 ohm or 75 ohm. Calibrate the NanoVNA at the port as you originally did. Now connect the antenna with your 15 ft of coax. Sweep from 200 to 500 MHz. Now display the Smith chart instead of the SWR plot. If overall, the plot circles are roughly centered on 75 ohms, the coax is 75 ohms. (The 75-ohm point will be to the right of the chart center by about 10% of the chart width.) If the plot circles are roughly centered on 50 ohms (at the center of the chart), the coax is 50 ohms. Two example plots are attached.

When you calibrate at the end of the coax, you remove its effect, and you'll get the same results whether you calibrated with 50 ohm or 75 ohm coax. The SWR plot will then look like the one you got just as it did with my modeled version. Plot attached.

73, Dave
NU8A

Certainly, the feedline can act as an impedance transformer - but it's also a phase shift. In particular, it will change the phase of the reflected wave. Let's say I have an antenna that is resonant (X=0) but is a slight reflector (S11 mag = -20dB). If I had the VNA at the feedpoint, the SWR would be low, and the phase of S11 would be zero. Now, let's put in 50 degrees of feedline. Now, the S11 phase will be 100 degrees - 50 degrees on the way out, the reflection at zero phase, then 50 degrees more on the way back.

So that's why you want to calibrate at the end of the feedline - it also accounts for the loss in the feedline so you can measure the true SWR at the antenna. While everyone *says* "the SWR is the same every where on the feedline" that's not true for a lossy transmission line. The SWR gets better, the farther from the mismatch you are. Go out and get 100 feet of RG-174 and put any antenna at the far end for 2.4GHz. With 60 dB of loss, any antenna will have an awesome VSWR at the transmitter end. It's the MaxComm matching unit all over again.

Why you think it bug?
NanoVNA use 5k IF for measure (this firmware). But as it VNA and not SA - not need add filter for mirror supression.
So you see main IF peak and mirror 5+5kHz

Frank - Thanks for the comments and information. The calibration for the first attachment was the standard Open, Short, and 50 ohm Load calibration done at the Channel 0 SMA connector on the NanoVNA. The first attachment would show the antenna with transmission line as seen by a transmitter or receiver.

The calibration for the second attachment used the same Open, Short, and 50 ohm Load calibration but at the antenna end of the transmission line. That effectively removes the transmission line from all measurements to show the characteristics of the antenna itself. That is one of the more powerful features of a NanoVNA.

The two legs of the dipole were bent down slightly to improve the match. Technically it is an Inverted V Dipole. The feed line does come straight down from the feed point.

The coax is Berk-Tek RG-58A/U low loss foam coax. The characteristic impedance is 50 ohms.

I believe the first attachment shows the resonant frequency of the antenna just ahead of the low point in SWR. Compare that low with the second attachment.

73, Kent
AA6P

On 7/21/21 12:33 PM, Manfred Mornhinweg wrote:

We always knew clipleads are bad, the question is really "how bad is it"

- A 1/4W carbon composition resistor. It has an interesting but pretty bad behavior: Only at very low frequencies it has its rated resistance value, along with considerable parallel capacitance. By about 20MHz the resistance has dropped by 20%, then stays about constant! At 500MHz it's significantly inductive, and I don't know why, being the same size as the film ones. This is very much worse RF behavior than any of the film resistors! I have been preaching for decades that film resistors are a lot better than composition, but some people keep believing that carbon composition is good for RF, because very old books say so. Sure, back when the only choice was between carbon composition and wirewound, carbon composition was by far the better choice! But since the appearance of cheap film resistors about a half century ago, carbon composition is obsolete for RF.

There were MMIC amps that liked using carbon composite as the bias resistor, since the large temperature coefficient made it well matched to keep the MMIC biased properly.