开云体育

WB2UAQ,

Between the HP8721 directional coupler and HP 85032 calibration standard you've got some pretty expensive toys there. The NanoVNA must feel outclassed when used with them :)


Herb

Hi Alan
Yes the type J pots are good. Years ago I built a K2BT noise bridge and also a Wilford Caron bridge. The pot called out for one side of the bridge was a 250 ohm type J linear pot. I still have these bridges as I don't throw anything away:) The K2BT bridge was published in Ham Radio Magazine in the 80's when money for ham radio projects was hard to come by. It was the best bridge I homebrewed and made the old Palomar noise bridge look pretty bad. If a type J pot would fit in the Palomar I would have installed one.

$ python3.7 -m pip install --upgrade --force-reinstall numpy

That solved the problem. NanoVNASaver now runs on my Mint workstation.

Hi, I'm looking for drivers for windows 7 nanovna usb port. thanks

/g/nanovna-users/search?q=windows+7+usb

From Nigel ZS6RN:
"I have updated with the newer version based on the file name (en.stsw-stm 32080 vs en.stsw-stm 32102)
and after a re-boot and changing device driver from ChibOS/RT Virtual Com port
to the one from st.com, the nanovna now has a port number"
/g/nanovna-users/message/3660

Oristo, I forgot to mention that I use the NanoVna to measure return loss with good dynamic range. First I tested the S21 performance of the NanoVna with an HP 355D and found that I could measure the 10 dB steps nicely down to about 60 dB. Then I attached an HP 8721 directional coupler with the Ch 1 watching the reflected port. With a BNC short across the 8721's test port I did a through cal. I now have a pretty good RL measuring system with the 44 dB directivity that the HP8721 offers. The 50 ohm load from an HP 85032 shows the S21 going into the mud as it should.

Here, I experienced that a USB 5 GHz Wi-Fi dongle was substantially slowed in
speed by having a USB mouse plugged into the same hub.
So some USB appears to "work that way".

Yes, slow devices >>on the same hub<< can impact thruput of faster devices.
USB is, after all, "Universal Serial Bus". so faster devices must toe-tap
while slow ones (e.g. HID keyboards and mice) clutter the bus with short slow packets.
Wi-Fi has a comparable situation..

Windows users can launch Device Manager and View Devices by connection,
since multiple case ports may share the same internal hub.

When it does get control, a USB device sends packets at negotiated speed.
I suspect, with no proof, that nanoVNA may negotiate a faster speed that it can
maintain under worst case conditions, so I insert a USB 2.0 hub to limit speed.

Thanks for the explanation! I haven't tried this yet but will do what the manuals for the old Gen Rad bridges suggest. They suggest "shunting down" the unknown and out of range impedance with a capacitance that will drop the impedance across the bridge to within the range of the bridge and then the mathematically remove the admittance of the known shunt capacitance to reveal the impedance that was out of range. I have done this with an old MFJ 259 (type that can measure Z's R and X but has a limit of about 1.6 k) to get an idea of the common mode impedance of a current balun......it worked well enough.

Hi, I'm looking for drivers for windows 7 nanovna usb port. thanks
Gaetano

Hi Herb -

My reading of Alan's post is that he performed a normal OSL calibration at
port 0. After that he connected his shorted clips to port 0 and noted the
difference between the OSL short and the fixture (test lead) short which was
300 nH. He then measured the inductor and subtracted the 300 nH fixture
inductance for his final value.

I understood that.

No "Mickey Mouse" calibration involve

Exactly, but (lacking another impedance bridge) I would like to know how far off
is nanoVNA measurement using >>MY<< "Mickey Mouse calibration"

they are mixed to 5kHz to make it easier for DSP and so on

They are mixed down for the analog-to-digital converter (ADC),
which arguably makes DSP harder, since it has to sort opposite side band suppression.

Here is a collection of articles that I find helpful:


.. specifically:

* Kurt Poulsen's 30 minute video of Michael Knitter's presentation for FA-VA 5,
which has architecture similar to nanoVNA


* DF8OE's opposite side band suppression discussion

Oristo,
My reading of Alan's post is that he performed a normal OSL calibration at port 0. After that he connected his shorted clips to port 0 and noted the difference between the OSL short and the fixture (test lead) short which was 300 nH. He then measured the inductor and subtracted the 300 nH fixture inductance for his final value. No "Mickey Mouse" calibration involve. I'm sure Alan will correct me if I misread.

Herb

Hi Alan -

This measured value of above returns 1.37 uH.
Now I must remove the stray 300 nH and I arrive at a corrected value of 1.07 uH.
This value correlates with an independent vector Z meter measurement within 50 nH, measured at the same operating frequency.

I would be very interested to know what value is reported by nanoVNA for that inductor @ 3 MHz
after "Mickey Mouse calibration" by short, open and ~ 50 Ohm resister in alligator clips.

Herb,
the "cutoff frequency" is the -3 dB point. I should make that more clear, I
suppose :-)

--
Rune / 5Q5R

Rune,
The international definition of bandwidth is actually the -3 dB points. That is what most manufacturers mean in their literature unless specified otherwise. The -6 dB and -60 dB points are more often used when specifying receiver bandwidth if my time in the military serves me correctly. Wouldn't hurt to include all three for the inevitable request you will probably receive.

Herb

Hi Bryan,
I just confirmed by installing 0.2.2 on my NanoVNA that it does indeed have
problems interfacing to my application. I have asked edy555 about it on
Twitter, and for my own testing purposes, increases the delay to 1 second -
which fixes the issue, but also makes the software feel *a lot* slower.

I need a 1500MHz firmware for some of the tests I'm making at the moment,
though, so I will stick with this for the next few days at least.

--
Rune / 5Q5R

On Wed, 2 Oct 2019 at 16:45, bryburns via Groups.Io <bryburns=
[email protected]> wrote:

Rune,

Thanks for the tip on using Hugen's firmware. I finally found the latest
version of his firmware which has TDR capability and works with both
nanoVNA-Saver 0.0.12 and 0.1.0. The version of firmware I am now using is
NanoVNA-H__900_ch_20190924.dfu which I downloaded from

.

I no longer have issues with getting bad data at the start of scans where
the frequency has changed. I can use any number of scans and the data is
correct.

I am just beginning to look at other features of the newest version.

Bryan

On Tue, Oct 1, 2019 at 08:58 AM, Rune Broberg wrote:

Hi Bryan,
sweeping currently works as follows:
1) The requested frequency range is set (start and stop frequency)
2) A delay of 300 ms
3) The frequencies are read back by sending the text "frequencies",

waiting

50 ms, and then reading them
4) The S11 data is read (again, 50 ms delay included)
5) The S21 data is read

I decided on 300 ms after testing a few times, and figuring that it was
"probably fine". Setting no delay sometimes let to errors, and more than
250 ms seemed to be fine, so I set it to 300. Maybe it's too low? But
then I was using Hugen's firmware.

If you can make a non-continuous sweep that produces a noticeable error,
you can try exporting the S1P/S2P Touchstone file, and looking at the
frequencies. The Touchstone export reads the exact frequencies reported
back by the NanoVNA, so it should tell you what frequencies it thinks

it's

reporting data for.

Sadly I don't think it's something I can really address in the

application

- I believe it has to be accounted for in the firmware.

Thanks for the work you're doing on this issue, though! Good luck with

it!

--
Rune / 5Q5R

On Tue, 1 Oct 2019 at 16:40, bryburns via Groups.Io <bryburns=
[email protected]> wrote:

Rune,

Thanks for taking a look at this thread!

My biggest concern is that with the firmware 0.2.2 from edy555 I always
see incorrect data in the second scan when using 2 scans between 80

and 120

MHz. With a single scan there are no errors over the same frequency
range. The incorrect data is always wrong in the same way. I.E. it is
actual measurements but they are from the wrong frequencies. If I do 5
scans, it appears that the first part of scans 2 through 5 is almost

always

incorrect data. If it were occasional errors, I could work with it;
however, it is repeated with my nanoVNA and this firmware. When I

request

a single scan over the exact same frequencies as the 2nd or 3rd or 4th

or

5th scan, I very rarely, if ever, see an error in the nanoVNA-Saver

data,

even in continuous sweep mode. What is different about continuous

sweep

mode? Is there a pause between the scans?

I very rarely, if ever, see it with firmware from hugen dated August 2,
2019 using the exact same scan settings 2 or 3 or 4 or 5... Yes, I

will

occasionally see errors with the hugen firmware but they are quite

rare and

usually pretty obvious. Repeating a sweep or measurement will clear

the

errant data.

I don't know much about the transfer protocol between the nanoVNA and

the

PC. From your comment above, I would have to assume that you do not

get

the frequency information in the same message as the data so there is

no

way to throw out data based on the fact that the frequencies you

requested

are not the frequencies sent from the nanoVNA. Is that correct?

A few questions, mostly thinking out loud. :>) I wonder if data is

being

sent from the firmware before the hardware has actually stabilized at

the

new frequencies you have requested? Would it help to pause a bit after
requesting a new set of frequencies?

I will continue looking for more clues to this issue.

--
Bryan, WA5VAH

--
Bryan, WA5VAH

On Thu, 3 Oct 2019 at 22:14, Oristo <ormpoa@...> wrote:

You got a nice smith chart blank on one side to photocopy and own use

etc :-)

Here is a Smith Chart that need only be printed:


It is generated using gnuplot, my favorite data plotting package:


Do you have any gnuplot code which can import a Touchstone file and plot

it on the Smith Chart? I produce all my plots for VNA cal kits usin
gnuplot, as one can automate everything, reducing the risk of errors. But I
have never plotted it on a Smith Chart - only amplitude and phase on the
same graph, using two y-axes,

My company logo has a Smith Chart in it - I generated that with gnuplot.

Dave
--
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

On Thu, 3 Oct 2019 at 21:38, Bear Albrecht <W5VZB.NM@...> wrote:

Here's United Parcel Service's reference material about shipping Lithium
batteries:


Covers air and ground, and lithium ion and lithium metal. Flow charts
galore.

There's more stuff out there on the web that I'm still reading.

W5VZB

Test certificates, flow charts, not more than 30% charged, 27 pages in
length. Irrespective of what air regulations state, a lot of couriers have
much more restrictive practices. I wanted to get a battery for my
multimeter some time ago, and Digikey had exactly what I wanted, but would
not ship it to the UK. The small batteries from Farnell are often in
containers with warning labels on the outside. The courier company probably
insists on it.

I can understand why some sellers ship batteries - it makes their products
more attractive. I can understand why others will not - they feel it is too
risky.

I had a VNA calibration kit returned once from one country (forget which),
by a courier (DPD) as it was considered dangerous goods.

I had another VNA cal kit get held in customs somewhere, on the basis of it
being dangerous goods. After making various comments, the courier was
finally satisfied the goods were safe, so they were accepted. I can imagine
if anything has batteries in it, there's a far greater risk of things being
returned or even destroyed if a courier does not want to handle it.
--
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

You got a nice smith chart blank on one side to photocopy and own use etc :-)

Here is a Smith Chart that need only be printed:


It is generated using gnuplot, my favorite data plotting package:

Same here, but i stil i no negative Feedback for the seller. Strange.

Indeed. Downmixing retains phase difference