¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
Date

Re: F303 and 4" LCD for next generation NanoVNA #circuit #flash_size #improvement #enclosure #battery

 

Hi Oscar,

Use it and don't worry about being a clone or not a clone.
If Hugen hadn't cloned from edy555, you wouldn't have to worry now.
By the way, everyone works from a set, if there is a difference, it is revenge of the scrap.

73, Gyula, HA3HZ

On Mon, Dec 16, 2019 at 10:27 AM, Oscar A wrote:


Hi Hugen,

I recently purchased my from ALI Express.

I am totally new to the VNA.

How can one identify if it is a clone or not.

Regards

Oscar


Re: My nanoVNA does't go into DFU mode #improvement

 

Hi Luciano,

You are writing that there was no D2 diode, which is likely to give you an earlier firmware version of nanoVNA.
Therefore, ignore the "Menu -> Config -> DFU" message as you do not have it in the firmware yet.
Download USBDeview (92kB) to see which USB drivers have been installed on your machine since your operating system was installed, and a green circle at the beginning of this line indicates what is in use.
For the DFU (Device Firmware Upgrade) to work properly, you need the en.stsw-stm32080.zip file, which contains the installation program and the driver needed to detect nanoVNA. Download and install it after a short registration. Then short-circuit the VDD and BOOT0 points of the P1 connector and insert the USB plug into the PC. NanoVNA with white screen indicates that it is in DFU mode. If your machine really sees nanoVNA, you can use DfuSe to update the firmware.
If the above process does not work, you will need to extract a ST-Link v2 dongle that you can use with en.stsw-stm32102.zip. I do not write down the details because can read to the forum many times. Use the "Search" button with short sentences.
Note that for the first time I only succeeded with the ST-Link v2 dongle.
I wish you a successful update.

73, Gyula HA3HZ


Re: Homebrew Female SMA standards and T-Check

 

Hello Jeff,

You have made an interesting T-Check measurement in post 8236, date 2015-12-15 16:19.

Is your MATLAB script "Cal_T_Check.m" also usable with Octave under Linux?

73, Rudi DL5FA


Re: F303 and 4" LCD for next generation NanoVNA #circuit #flash_size #improvement #enclosure #battery

Oscar A
 

Hi Hugen,

I recently purchased my from ALI Express.

I am totally new to the VNA.

How can one identify if it is a clone or not.

Regards

Oscar

On 16-Dec-2019, at 11:31 AM, hugen@... wrote:

I have made these changes, but I always get an error interrupt. It may be caused by some register values not being reset properly.

hugen



Re: My nanoVNA does't go into DFU mode #improvement

 

On Mon, Dec 16, 2019 at 03:56 PM, Ady, YO2NAA wrote:


Dear Hugen,

that's good news. I would recommend the store to my friends. We appreciate
your work.
I see that shipping is 15$ for my country (Romania), also for some EU
countries, but for other EU countries shipping is free.
Is there a way we can order with free shipping?

Thank you and best regards,
Adrian

You can contact Maggie to modify, Maggie will choose the appropriate courier, most European countries do not need to add additional postage.

hugen


Re: My nanoVNA doesn't go into DFU mode #improvement

Dave W6TE
 

Greetings,

I am unable to complete the checkout process with two different credit cards. Do you take Paypal?

Dave W6TE

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of hugen@...
Sent: Sunday, December 15, 2019 9:33 PM
To: [email protected]
Subject: Re: [nanovna-users] My nanoVNA does't go into DFU mode #improvement #improvement #improvement #improvement #improvement

There are more than 5 clones of NanoVNA-H at present, some are with shielding cases. But due to their wrong assembling, the performance decreases. Assembling the shielding case is to isolate effectively, but if they connect the shielding case of CH0 with CH1, it will sharply decreases the performance. Although some clones are with good performance, we could only make judgement after testing. I am quite annoyed, because some irresponsible agents sell inferior clones which marks as my version, it is a serious cheating. I have updated NanoVNA-H to version 3.4 after I received much feedback from the community. It is under assembling&testing at present. It works well till 1.5GHz in the present testing. Meanwhile, I changed the power chip and the battery to 650mAH which further decreases the noise from the usb charging. In addition, it could work 4 hours after these changes. If everything goes well, the new version will come to the market on Dec.20. You could buy from Maggie through this link: ;data=02%7C01%7C%7C9324efba68a34e01c22508d781e96641%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637120711744625610&amp;sdata=KJ6pthWOruJKO%2Fb46zH%2BrjiqaR3KxChn1BIrCrGifig%3D&amp;reserved=0

hugen


Re: My nanoVNA does't go into DFU mode #improvement

 

Dear Hugen,

that's good news. I would recommend the store to my friends. We appreciate
your work.
I see that shipping is 15$ for my country (Romania), also for some EU
countries, but for other EU countries shipping is free.
Is there a way we can order with free shipping?

Thank you and best regards,
Adrian

On Mon, Dec 16, 2019 at 7:32 AM <hugen@...> wrote:

There are more than 5 clones of NanoVNA-H at present, some are with
shielding cases. But due to their wrong assembling, the performance
decreases. Assembling the shielding case is to isolate effectively, but if
they connect the shielding case of CH0 with CH1, it will sharply decreases
the performance. Although some clones are with good performance, we could
only make judgement after testing. I am quite annoyed, because some
irresponsible agents sell inferior clones which marks as my version, it is
a serious cheating. I have updated NanoVNA-H to version 3.4 after I
received much feedback from the community. It is under assembling&testing
at present. It works well till 1.5GHz in the present testing. Meanwhile, I
changed the power chip and the battery to 650mAH which further decreases
the noise from the usb charging. In addition, it could work 4 hours after
these changes. If everything goes well, the new version will come to the
market on Dec.20. You could buy from Maggie through this link:


hugen




Re: F303 and 4" LCD for next generation NanoVNA #circuit #flash_size #improvement #enclosure #battery

 

I have made these changes, but I always get an error interrupt. It may be caused by some register values not being reset properly.

hugen


Re: F303 and 4" LCD for next generation NanoVNA #circuit #flash_size #improvement #enclosure #battery

 

The firmware for NanoVNA-H needs to be recompiled before it can be used. You need to modify the MCU and LCD drivers and some UI changes. You can view the code of AA6KL. AA6KL has completed most of the work. Measurements up to 1.5G are difficult to guarantee 50dB dynamics. The current test results seem to be able to obtain relatively accurate measurements in a dynamic range of 40dB.

hugen


Re: Are any of the NanoVNA sold on Amazon any better or worse than any others? Is there a better U.S. site to order from?

 

There are more than 5 clones of NanoVNA-H at present, some are with shielding cases. But due to their wrong assembling, the performance decreases. Assembling the shielding case is to isolate effectively, but if they connect the shielding case of CH0 with CH1, it will sharply decreases the performance. Although some clones are with good performance, we could only make judgement after testing. I am quite annoyed, because some irresponsible agents sell inferior clones which marks as my version, it is a serious cheating. I have updated NanoVNA-H to version 3.4 after I received much feedback from the community. It is under assembling&testing at present. It works well till 1.5GHz in the present testing. Meanwhile, I changed the power chip and the battery to 650mAH which further decreases the noise from the usb charging. In addition, it could work 4 hours after these changes. If everything goes well, the new version will come to the market on Dec.20. You could buy from Maggie through this link:

hugen


Re: errors of "error" models

 

ann : we just finished the experimental comparison - the results verified
our predictions for two constructed two-ports - #83 : On the Doubtfulness -
13 December 2019 - /g/nanovna-users/message/8173


Re: Homebrew Female SMA standards and T-Check

aparent1/kb1gmx
 

One last, many of the HP loads are air, the most often home made open and
short are PTFE loaded, there is a VF difference.

The HP load is definately air (minimal dielectric) to the resistance.
The open and short are for my set air.

I have them to calibrate the HP4191A I have and work well for the nanovna.

Allison
--
-----------------
I do not accept private email due to forum scraping groups.io


Re: My nanoVNA does't go into DFU mode #improvement

 

Menu -> Config -> DFU

nothing else need

vy73 de Teo

Am 16.12.2019 um 00:01 schrieb Herman De Dauw:

Have you read the Wiki files for upgrading ? Zadig is not nessecary. And you need to place the boot switch of jumpers needed to start in DFU mode.



Re: My nanoVNA does't go into DFU mode #improvement

 

Have you read the Wiki files for upgrading ? Zadig is not nessecary. And you need to place the boot switch of jumpers needed to start in DFU mode.


Re: Homebrew Female SMA standards and T-Check

 

Hi Jef
One more comment. The load being 50 ohm it is not sensitive to a small displacement of the calibration plane.
You will soon see a perfect T-Check
Kind regards
Kurt

-----Oprindelig meddelelse-----
Fra: [email protected] <[email protected]> P? vegne af Jeff Anderson
Sendt: 15. december 2019 16:19
Til: [email protected]
Emne: [nanovna-users] Homebrew Female SMA standards and T-Check

A few years ago I made an open and a short female SMA standard for calibrating my HP 8753C VNA (for the load I used a very nice 85052 female 3.5mm load). I never used the open and short above about 30 MHz, so I didn't worry too much about their accuracy.

With my purchase of a NanoVNA I thought I could put them to use in lieu of the male standards the NanoVNA comes with. And so I thought I'd check their accuracy, using my 8753C and the Rohde & Schwarz T-check method.

Of course, I had not characterized my standards, and so I thought, as a first attempt at checking them, I would use the "stock" 3.5mm cal-kit definitions that are stored in the 8753C.

The key parameters of the "stock" 3.5mm definitions (to match HP's 85033C kit) are:

Open: C0 = 53, C1 = 150, C2 = 0, C3 = 0, and Offset Delay = 14.491 ps
Short: Offset Delay = 16.695 ps
Thru: Offset Delay = 0 ps

Much to my surprise, the results were very good, as you can see in the attached T-check plot.

But, I wondered, do the "stock" HP delays bear any resemblance to the actual delays of my SOLT standards?

Assuming HP's Offset Delays were not the same as my SOLT Offset Delays, why not change HP's "stock" Offset Delays (as defined above) to move the reference plane to the end of my standards (i.e. at the location of the actual open and short).

So, as an experiment, I decided to subtract 14.491 ps from HP's "stored" 3.5mm definitions. In other words,

o The Open Offset Delay changed from 14.491 ps to 0 ps.
o The Short Offset Delay changed from 16.695 ps to 2.204 ps
o The Thru Offset Delay changed from 0 ps to -14.491 ps

The results weren't quite as good as I expected (see attached T-check PNG).

Maybe, I thought, the Thru's delay change needed to be positive, not negative, so I changed its Offset Delay from -14.491ps to +14.491ps. Even worse results!

So I tried doubling the Thru's Offset Delay. That is, rather than making it -14.491 ps, make it -30 ps. The results now look pretty good.

But why does doubling the Thru delay give these results? And so my questions are:

1. Why did doubling the Open/Short Offset Delay delta of -14.491 ps to be the Thru's Offset Delay give the results it did?

2. Why are the Thru Offset Delays in HP's Cal Kits all spec'd to be 0 ps? (Clearly the length of the thru's are not zero, so what is HP referencing to determine that an Offset Delay is 0?)

Thanks for any insight provided!

- Jeff, k6jca


Re: Homebrew Female SMA standards and T-Check

 

Hi Jeff

It is not a mystery why it work ?

You open offset delay is not 14.491ps but 17.15ps with the C0 and C1 included

Then the difference between the short and open is 17.15-16.695=0.45ps so the open is a bit longer than short by open air displacement of 0.45/.3=1.5mm You homemade female open has a fringe c so also a bit longer than the homemade short and 0.45ps correspond to 9fF as 1 ps=20fF. The fringe C for your open can be simulated by the program FEMM and will be about 25fF (I just simulated a female SMA adaptor) so in reality you home made open has a delay 1.25ps longer than the short. Now comes the fun part. If the electrical length of you homemade adaptor is from calibration plane to rear of adaptor was 16.695ps then you had as HP85033C male clone with the exception that the open was 1.25-0.45=0.8ps longer. Find the electrical length of the homemade adaptor as the length from calibration plane (2 mm recessed from the front) to the read of adaptor and divided by 0.3 and divide once more with 0.695 being the VF of Teflon. The you can figure out how much to compensate as X - 16.695ps being positive or negative

The reason for Thru set to 0 is the VNA probably has adaptor removal included

Kind regards

Kurt



-----Oprindelig meddelelse-----
Fra: [email protected] <[email protected]> P? vegne af Jeff Anderson
Sendt: 15. december 2019 16:19
Til: [email protected]
Emne: [nanovna-users] Homebrew Female SMA standards and T-Check



A few years ago I made an open and a short female SMA standard for calibrating my HP 8753C VNA (for the load I used a very nice 85052 female 3.5mm load). I never used the open and short above about 30 MHz, so I didn't worry too much about their accuracy.



With my purchase of a NanoVNA I thought I could put them to use in lieu of the male standards the NanoVNA comes with. And so I thought I'd check their accuracy, using my 8753C and the Rohde & Schwarz T-check method.



Of course, I had not characterized my standards, and so I thought, as a first attempt at checking them, I would use the "stock" 3.5mm cal-kit definitions that are stored in the 8753C.



The key parameters of the "stock" 3.5mm definitions (to match HP's 85033C kit) are:



Open: C0 = 53, C1 = 150, C2 = 0, C3 = 0, and Offset Delay = 14.491 ps

Short: Offset Delay = 16.695 ps

Thru: Offset Delay = 0 ps



Much to my surprise, the results were very good, as you can see in the attached T-check plot.



But, I wondered, do the "stock" HP delays bear any resemblance to the actual delays of my SOLT standards?



Assuming HP's Offset Delays were not the same as my SOLT Offset Delays, why not change HP's "stock" Offset Delays (as defined above) to move the reference plane to the end of my standards (i.e. at the location of the actual open and short).



So, as an experiment, I decided to subtract 14.491 ps from HP's "stored" 3.5mm definitions. In other words,



o The Open Offset Delay changed from 14.491 ps to 0 ps.

o The Short Offset Delay changed from 16.695 ps to 2.204 ps

o The Thru Offset Delay changed from 0 ps to -14.491 ps



The results weren't quite as good as I expected (see attached T-check PNG).



Maybe, I thought, the Thru's delay change needed to be positive, not negative, so I changed its Offset Delay from -14.491ps to +14.491ps. Even worse results!



So I tried doubling the Thru's Offset Delay. That is, rather than making it -14.491 ps, make it -30 ps. The results now look pretty good.



But why does doubling the Thru delay give these results? And so my questions are:



1. Why did doubling the Open/Short Offset Delay delta of -14.491 ps to be the Thru's Offset Delay give the results it did?



2. Why are the Thru Offset Delays in HP's Cal Kits all spec'd to be 0 ps? (Clearly the length of the thru's are not zero, so what is HP referencing to determine that an Offset Delay is 0?)



Thanks for any insight provided!



- Jeff, k6jca


Re: errors of "error" models

 

Dear Gary,

Well, allow us, please, to underline what we already said in:

#83 : On the Doubtfulness - 13 December 2019:
/g/nanovna-users/message/8173

that is : it is just a "new" -but careful- formulation which generalizes
not only the aforementioned paper by Hackborn, but also the idea
expressed in the following paper by W.P. Wheless, Jr. and C.S.
Wheless:

"Two-Port Network Specification of Baluns for NEC Analysis
and Other Applications", 1996-03, 12th Annual Review of
Progress in Applied Computational Electromagnetics at the
Naval Postgraduate School, Monterey, CA, March 18-22, 1996,
Conference, pp 69-74, PDF pp 96-101:



plus, once more, as it seems it has its practical limitations of:

/g/nanovna-users/message/8239
/g/nanovna-users/message/8240

which were already implied at:

#83 : On the Doubtfulness - 13 December 2019:
/g/nanovna-users/message/8173

obviously due to the facts already mentioned at section (9) of:

#73': On the sine qua non Core Uncertainty of AnyVNA - incl. NanoVNA - System
6 November 2019 - /g/nanovna-users/message/6529

Anyway, we will see.

Sincerely,

gin&pez@arg


My nanoVNA does't go into DFU mode #improvement

 

I received a nanoVNA last week and tried to upgrade it. I ran Zadig and updated the drive according to Zadig's default suggestion.
Once done, I sort circuited the boot0 and Vcc terminals, connected the USB cable to my computer running Win10, but couldn't see it in DFU mode under Device Manager. Am I missing something?
I did installed the D2 diode before all that so to have a battery level on display.

73,

Luciano PT9KK


Re: errors of "error" models

 

Thank you again GIN&PEZ;

This is both an interesting and exciting journey of discovery and understanding for me. Your diligence and persistence, along with the availability and convenience of modern mathematical tools like Maxima, are managing to win at least one follower of your work. :-)

It is most interesting that this new two port model appears to implicate a savings in hardware as well as computational efficiency.

I am looking forward to ¡°testing¡± the algorithm with my limited resources for this, and attempting to formulate ideas for non-symetric 2-port devices to flip and compare for example S11 with S22 when the DUT is reversed.

FACUPOV, I suspect that the indirect S22 measurement is going to yield a most controversial result when pitted against its direct measurement. Also FACUPOV, equivalence to the latter is easily achieved by simply flipping the DUT, repeating the test, and acknowledging the additional set of uncertainty introduced by that action.

I anticipate that the uncertainty in S21 and S12 will be reduced, but a similar controversy may arise over differences in S12 results.

I will maintain sensitivity to clues of the aforementioned controversies as I evaluate and compare 2-port measurements.

--
73

Gary, N3GO


Re: Homebrew Female SMA standards and T-Check

 

On Sun, 15 Dec 2019 at 15:19, Jeff Anderson <jca1955@...> wrote:

A few years ago I made an open and a short female SMA standard for
calibrating my HP 8753C VNA (for the load I used a very nice 85052 female
3.5mm load). I never used the open and short above about 30 MHz, so I
didn't worry too much about their accuracy.
Fair enough.


With my purchase of a NanoVNA I thought I could put them to use in lieu of
the male standards the NanoVNA comes with. And so I thought I'd check
their accuracy, using my 8753C and the Rohde & Schwarz T-check method.
I'm a bit sceptical of the T-check method. R&S don't sell the device to do
this any any more, but they used to. They only sell verification kits based
on airlines and attenuators. Ken Wong at Keysight looked at it, and was not
impressed.

There's not the proper error correction in a nanoVNA to perform a T-check
anyway.



Of course, I had not characterized my standards, and so I thought, as a
first attempt at checking them, I would use the "stock" 3.5mm cal-kit
definitions that are stored in the 8753C.

The key parameters of the "stock" 3.5mm definitions (to match HP's 85033C
kit) are:

Open: C0 = 53, C1 = 150, C2 = 0, C3 = 0, and Offset Delay = 14.491 ps
Short: Offset Delay = 16.695 ps
Thru: Offset Delay = 0 ps
Depending on how you construct the standards, you are likely to get delays
longer than those. They are very short.

If you make your own standards, the parameters of the males and female will
almost certainly be different. I would suggest you modify the 85032B N cal
kit, as that has different parameters for the opens and shorts, which you
will have.



2. Why are the Thru Offset Delays in HP's Cal Kits all spec'd to be 0
ps? (Clearly the length of the thru's are not zero, so what is HP
referencing to determine that an Offset Delay is 0?)
Because they are based on a *"flush thru".* In other words, one standard is
male, and the other standard is female, so they connect together with zero
delay. HP can't guess the delay of your thru. For a "typical" female-female
thru the delay will be 41 ps, which should be entered into the calibration
standard #4 as 41 ps.


Thanks for any insight provided!

- Jeff, k6jca
Dave, G8WRB