开云体育

As an update.

The seller has kindly updated the post and even going to give a donation to a good cause. They have lots of good feedback on eBay, so I assume the quality is good. So I have no issue at all with it.

Interesting: Does the use of the ADF4350 mean the minimum frequency will be
137MHz+? Or do you have plans for handling that?

Are you and your project associated to edy555/ttrftech, to hugen, or to
neither?

--
Rune & 5Q5R

On Sun, 29 Sep 2019 at 19:22, Gabriel Tenma White <OwOwOwOwO123@...>
wrote:

Hi, NanoVNA V2 layout designer here. Here is what I know:
* V2 won't have a bigger display because it is too expensive
* frequency range will go to at least 3.5GHz; PLL limit is 4.4GHz.
* ADF4350 is used because of cost reasons; ADF4351 is more expensive by a
factor of 5.
* The layout is already fairly packed, so modular is not possible without
a huge form factor.
* Layout and shielding are much improved for higher dynamic range.
* Price will be around the same as the existing NanoVNA. The design is
already cost limited, so we can not do anything that will further add cost.
* PC interface will be completely reworked. A binary protocol will be used
similar to the xaVNA (we are going for full compatibility with the xaVNA PC
software). If you are writing custom PC software for the Nano, please make
sure the USB interfacing part is well abstracted away and easy to change.

The development timeline is going to be pretty long (by Chinese standards
at least). We will iterate on PCB layout to get the best dynamic range. I
think we might see initial (quantity limited) sales in ~3 months.

Forgot to mention...the 85050B’s calculation were for 1500 MHz (corrected this -- I'd originally typed 900 MHz)

- Jeff

This post is somewhat off topic but I am so happy with what I achieved I felt I earned some bragging rights

For those that need a nanoVNA V2 for tuning their 2GHz antennas there is no real reason to wait.
If you have a close look at the attached picture you will notice the main nanoVNA V2 components in a home build.
In the middle back-to-back are two ADF4351 modules. On top of the aluminium bar on the left is the 0.1MHz till 3GHz bridge and on the right is a PCB with three IAM81008 mixers dead-bug style. All controlled by an Arduino zero hiding at the top. Audio goes to a line in of a PC and that is all you need for a GHz VNA.
With this home build VNA I was able to solve a problem of my home build 2GHz Spectrum Analyzer that is hiding underneath the VNA.
The aluminium bar at the bottom of the picture is actually a 5 resonator interdigital cavity filter. I have been trying to buy one for a long time but as I wanted to convert the 2GHz first IF of the SA directly to the second IF at 10.7MHz I was not able to find one narrow enough and finally decided to build it myself.
So I first had to build the 35MHz till 3GHz VNA, just like the NanoVNA V2 (although not so portable)
The construction of the cavity filter proved to be doable without any special tools except a 4mm tap. The aluminium bar for the housing and the copper rods for the resonators can be bought cheaply per meter.
Tuning the cavity filter proved to be more difficult than expected as there is absolutely nothing that gets thru if out of tune. So I used a simple trick that is of interest only for people that want to build their own cavity filter and now it works!
Center frequency 2019MHz, 2dB bandwith 4MHz. Better than -70dB at 10MHz offset. Passband attenuation is -7dB
The spectrum analyzer has hardware RBW filters at 300kHz and 30kHz (top tin box at right) and a log amplifier (top tin box at left) and variable FFT stitching RBW filters to a minimum resolution of 1Hz. IIP3 is +17dBm and noise floor at 300kHz BW is around -100dBm.
To prove it is working I added a 0 to 1GHz scan of the spectrum around my house using a small antenna. You will notice the FM and DAB transmitters and the rather strong cell phone base stations
Again apologies for the off topic post.

Erik, PD0EK

Steve,
That's good information. Some Linux user's with bricked devices may not have been aware that a Windows PC might be able to recognize the device (if they still had a Windows PC available) and un-necessarily ordered the ST Programmer.

reply to kb3cs
That's certainly annoying.
I'd like to have a reference for where these regulations abide.
Do you have it handy?

thanx
W5VZB

On Sun, Sep 29, 2019 at 04:16 AM, Kurt Poulsen wrote:

Hi Kurt,

Thanks for the reply.

My humble opinion is like your indications that L and C coefficient are not
relevant for the calibration kit delivered with the NanoVNA and in particular
as we have no idea if the kit are the same for all deliveries.

Agreed.

Until there is a full blown calibration kit definition embedded in the NanoVNA
this is the way forward to use the NanoVNA-saver.

Agreed.

again my opinion is that would be an overkill for the majority of NanoVNA
users. It is far better to focus on how and with simple means to find the
needed delays for a homemade kit or e.g. a BNC kit bought from SDR kits where
all these data are supplied with the kit.

Agreed. Describing how to characterize a homemade BNC kit would be a great idea.

I did measure the
supplied kit based on calibration by my HP 3.5mm kit on another VNA and I will
repeat and publish the result for those values to be entered in NanoVNA saver.

Kurt, that would be excellent! I'm looking forward to seeing these values

Best regards,

Jeff, k6jca

I finally got mine unbricked using "conventional" methods.

Here's the story:

1) Used ubuntu dfu-tool to load CLEAR_MEMORY_DFU.dfu . That left the NanoVNA white screened.
2) Tried to use dfu-tool to load a NanoVNA dfu. Couldn't: ubuntu no longer found NanoVNA, even in boot mode.
3) Installed DfuSe Demo on Windows.
4) Plugged NanoVNA into Windows box, in boot mode (2 pins shorted). Windows Search found and installed the STM driver (on the 3rd try). After that, Windows device manager always found the NanoVNA when in boot mode.
5) Used DfuSe to install the current NanoVNA dfu using Hugen's excellent instructions at . The important thing is that you are -upgrading-, not -uploading-. Use the Choose and Upgrade options on the right side of DfuSe.

Steve

Steve,
The following is what another user wrote:

// Begin Quote //

There are two ways to update firmware: DFU and ST-LINK. So, it depends on what method you're want to use.

1) DFU update. This is simple but not reliable way. If something will going wrong, you may brick your NanoVNA with this method and the only way to restore it is to update firmware with the second method. DFU method doesn't requires any special hardware and you can update it just through USB.

For DFU method, you will need the file with DFU extension: e.g. "nanoVNA_900_ch_20190920.dfu"

In order to upload it into NanoVNA you will need DfuSe software.

You will need to power-off your NanoVNA, connect USB to PC, short BOOT jumper with tweezers and power on NanoVNA. It will be booted in DFU mode. The display will be white. Now you can release BOOT jumper and then use DfuSE Demo tool to upload firmware file into NanoVNA.

2) ST-LINK update. This is native and reliable way. But it requires a ST-LINKv2 dongle. This dongle allows to flash even bricked device and also allows to use in-circuit debugging.

For ST-LINK update, you will need the file with HEX or BIN (any of these) extension: e.g. "nanoVNA_900_ch_20190920.hex"

In order to upload it into NanoVNA you will need ST-LINK Utility software.

You will need to connect ST-LINK to NanoVNA with 4 wires:
- 3.3V to VDD,
- GND to GND,
- SWDIO to SWDIO,
- SWCLK to SWCLK

There is no need to solder, you can just connect wires to the pads and press it with finger during upload. Then you will need to use ST-LINK Utility tool with the following memory parameters:
- Address: 0x08000000
- Size: 0x20000
- Data Width: 8 bits

I strongly recommend to save your current firmware before update. Just in case. Both software tools allows it. "

// End Quote//

After having read the above, I bought a second nanoVNA and use it as a sacrificial device when trying upgrades. I haven't had any problems upgrading with DFUSe Demo through USB, but I'm prepared in-case Murphy decides to pay me a visit.


Herb

It's alive !

For anyone patient enough to be following this, here's what happened and what fixed it:

1) Used ubuntu dfu-tool to load CLEAR_MEMORY_DFU.dfu . That left the NanoVNA white screened.
2) Tried to use dfu-tool to load a NanoVNA dfu. Couldn't: ubuntu no longer found NanoVNA, even in boot mode.
3) Installed DfuSe Demo on Windows.
4) Plugged NanoVNA into Windows box, in boot mode (2 pins shorted). Windows Search found and installed the STM driver (on the 3rd try). After that, Windows device manager always found the NanoVNA when in boot mode.
5) Used DfuSe to install the current NanoVNA dfu using Hugen's excellent instructions at . The important thing is that you are -upgrading-, not -uploading-. Use the Choose and Upgrade options on the right side of DfuSe.

Mine using Kapersky Antivirus have a same problem with hanging black screen
after execute the program. Then turn off protection for a while, voila.. it
running flawlessly.

Regards

On Sun, Sep 29, 2019 at 03:43 AM, Dr. David Kirkby from Kirkby Microwave Ltd wrote:

The 85032F is not one of Keysight’s best kits.

Hi Dave,

You are probably right. I chose this kit because, of the 50-ohm cal-kits listed by Keysight as supported for the 8753D, it seemed to have the worst higher-order capacitance terms, thus a good choice for testing my theory.

It would be interesting to know what errors you get with your simplified
model for the 85050B 18 GHz APC7 calibration kit. That kit is often
available cheaply on the used market, yet has a good specification on phase
at +/- 0.3 degrees to 2 GHz, and it good at 18 GHz too.

Ask and you shall receive!

First, Keysight's values defining the 85050B open:

C0 = 90.4799e-15;
C1 = 763.303e-27;
C2 = -63.8176-36;
C3 = 6.4337e-45;
Delay_Open = 0;
Loss_Open = 0;
Offset_Zo_Open = 50;

Now, the results of my calculations...

1. Open using C0 - C3 : rho = 1.0000, theta = -4.9381 degrees

2. Open using only C0: rho = 1.0000, theta = -4.8830 degrees
(Note: the angular delta between the two thetas is 0.055 degrees)

3. Open using "full" keysight model: Results same as '1', above. (To be expected because Loss is 0 and Zo is 50, thus the "full" equations ought to collapse down to my "simple" (i.e. C0-C3 only) model).

Best regards,

- Jeff, k6jca

On Sat, Sep 28, 2019 at 11:28 PM, Starsekr wrote:

Jeff, if I understand what you wrote, you would like the NanoVNA to have the
ability to include custom standard characterization by inputting C0 and Offset
Delay for both the open and short, while assuming the reference load is
exactly 50 ohms. Per your calculations, including higher order terms only
results in a trivial (for most uses) correction.

Hi Jim,

You are essentially correct, but I was thinking more of Rune's Nanovna-Saver application (which allows the user to specify C0-C3, L0-L3, and delays for the two) rather than the NanoVNA, itself. (I should have been more explicit).

Anyway, I was wondering how important it was to enter the various C and L terms for the standards, or if, for expediency, most of them could be left as zero. And, at least for the commercial standards I looked at, it would seem that only C0 and Delay have a significant impact.

Best regards,

- Jeff, k6jca

On Sun, 29 Sep 2019 at 14:29, <erik@...> wrote:

I'm assuming (based on my over 40 years ago systems modeling lessons) they
are making a numeric model to translate uncertainties/noise in one domain
into the measurement outcome domain so you can interpret the level of
(un)certainty in you measurements.
I am unable use to the provided documents

I don’t see any document they have provided - plenty of links to other
tools, but I am still at a loss of knowing much about what they are
actually doing.

or tools (for sure have no plans to install a fortran compiler)


I have gcc installed on my Sun, with support for Fortran built in. I
downloaded the Fortran source code and attempted to compile it. The GCC
version I have does not recognise it as Fortran. I am not a Fortran
programmer myself, but the code a bit like Fortran.

There are no significant comments in the Fortran source code, so I didn’t
bother looking any more. There are some data files too, but there’s no
mention of how to use them.

If above statement from me is correct would it be possible to have a
statistical error model of the measured raw data and then use a monte carlo
simulation to estimate the uncertainty in the to be measured data?

I expect a Monte Carlo simulation is a good way to go. All the
uncertainties I have seen for instruments are based on a statistical model,
expressed as a confidence level (typically 95%). Monte Carlo methods are
good for that.

However, I believe that they are taking a purely analytical approach. Files
have been distributed for Maxima which is a symbolic computational program.
Also Mathematics too.

(40 years is a long time so I may be wrong here)
Anyway, I'd like to contribute if possible by providing measurements in
some form but by mathematics are no longer fit for any real contribution.

Hopefully you can make a useful contribution. Personally I am going to give
up unless I can see a written description of the aims and methodology.

Dave.
--
Dr. David Kirkby,
Kirkby Microwave Ltd,
drkirkby@...

Telephone 01621-680100./ +44 1621 680100

Registered in England & Wales, company number 08914892.
Registered office:
Stokes Hall Lodge, Burnham Rd, Althorne, Chelmsford, Essex, CM3 6DT, United
Kingdom

Did you succeed in getting your NanoVNA unbricked with ST-LINK ?

I'm in the same boat. Before throwing good money after bad, I would like to hear from folks who have successfully used ST-LINK to unbrick a whitescreened NanoVNA that failed using DFU.

Thanks,
Steve, N2IC

On Sun, 29 Sep 2019 at 12:16, Kurt Poulsen <kurt@...> wrote:

Hi Jeff

However the NanoVNA has already a build in correction for the open in the

form of 50fF which is pretty much correct for the CH0 Female SMA left open,
so to use the supplied open standard is wrong and is adding further delay.

That is acceptable if your DUT has a male SMA connector, but it is not if
you wish to use any other sort of connector.

Basicly the NanoVNA is for me the "engine" and for using other calibration
kits the way is to use the NanoVNA-saver

That is your intended use Kurt, but it is certainly not how I intend using
the NanoVNA. For my use, which is to use it as an entirely self-contained
unit, being able to define calibration kits in the NanoVNA is important,
whereas using the NanoVNA with external software is less so.

where you can enter delays and L and C coefficient IF YOU HAVE THEM and

that is not the case for the majority of NanoVNA users for whatever
homemade kit they want to use.

You can estimate that based on physical measurements as you well know.

One must remember to subtract the 50fF from the Open as the NanoVNA is

internally pre-compensated by 50fF equal to a one way delay of 2.5ps.

Or better still remove that 50 fF, and let the user define calibration
kits. Let the NanoVNA default to using the calibration kit supplied, but
allow the user to enter a kit(s) with defined parameters.

David is giving a comment the a short always has a longer delay than open,

and that can be misunderstood. That is not the caser for the supplied kit
for the NanoVNA.

I was talking about the vast majority of professional calibration kits.
Clearly Jeff is thinking about the higher quality kits. When I mentioned
that supporting C1, C2, C3, L0, L1, L2 & L3 would be better for homemade
kits, he pointed out that was not his main aim.

I have made a comment on this on this reflector as it is anticipated to be

0ps by design but it has a very small negative value. I did measure the
supplied kit based on calibration by my HP 3.5mm kit on another VNA and I
will repeat and publish the result for those values to be entered in
NanoVNA saver. It would be nice if David had done that instead of lecturing
about the way he seem everything.

Initially people were saying that the NanoVNA assumed ideal standards. Now
I believe it’s a 50 fF open and probably an ideal short. As you say, the
short supplied has a small negative delay.


Long live a pragmatic approach


The correct pragmatic approach depends very much on ones intended use,
which will be either

* *Use the NanoVNA standalone*, requiring support for calibration kits
internally *in* *firmware*. Jeff has convinced me that a delay for the
opens and shorts, as well as C0, is adequate for the HP calibration kits. I
don’t think that’s the case for homemade kits though.

* *Use the NanoVNA as data collection device*, and perform other functions
with external software.

That’s two very different uses, requiring a totally different approach

Kind regard

Kurt

Dave
--
Dr. David Kirkby,
Kirkby Microwave Ltd,
drkirkby@...

Telephone 01621-680100./ +44 1621 680100

Registered in England & Wales, company number 08914892.
Registered office:
Stokes Hall Lodge, Burnham Rd, Althorne, Chelmsford, Essex, CM3 6DT, United
Kingdom

Yes

Sorry to be such a PITA, but at this point I'm nervous about bricking it...

When I select your white.dfu, then press Upload, I get this message box:

Your device was plugged in DFU mode.
So the DFU mode Vid, Pid and Bcd will be put in the .dfu file.
Continue ?

Yes or No ? If No, what's the next step ?

Thanks,
Steve

Last firmware 29.09.2019

Install the program, the device should be detected (switch the jumper to boot mode again). Indicate the path to the firmware and flash.