Hi Ernest,
Don’t be afraid of experimenting with different .dfu files/foimware (scuse the Bronx accent), I think you’ll find that there a re many that will work and some that don’t. What’s important is the feature sets that the programmers are working hard to provide . . .

Regds Ross

Ross Filippi
0424-317-705
VK2ATA

From: ERNEST AEC-RADIO<mailto:aecradio1@gmail.com>
Sent: Tuesday, 13 October 2020 4:55 AM
To: nanovna-users@groups.io<mailto:nanovna-users@groups.io>
Subject: Re: [nanovna-users] Help! My NanoVNA bricked after a firmware update! #firmware

I found (by accident), that my version of the H-4 WITH the card holder,
would NOT work with the firmware update for the card. This is why the
screen went windows on me.
For the usual fecal funnies, I loaded the firmware that had no SD card
support...BINGO!
Back to normal!
V.0.9.1.0.dfu is the correct version (for my unit).
I hope this helps others suffering from SD card delusions of grandeur.
73!
KA9UCE

On Sun, Oct 11, 2020, 10:26 PM Ross Filipi <rossfi@hotmail.com> wrote:

Hi Larry/OneOfEleven,
Many Thanks for the replies and
advice, much appreciated . . And apologies for the slowww response, weekend
obligations . . .

These days I tend to just dive in and follow the RTFM Rule; “When all else
fails – RTFM” 😊 And since I’m building some Experimental Antennas that I
plan to use for mobile emergency volunteer work I just need to ‘get
comfortable’ enough with these gizmo’s to get some idea of how a wire will
perform Before I try and poke a few hundred watts into it with an expensive
radio . . .

Having said that I did manage to find a few moments to research & scan
some info on the DFU mode vs USB protocol by way of getting my head around
that.

A few further clarifications if I may . . .

“The White Screen of Death” was just a bit of tongue in cheek based on
memories of a great many Windows NT “Blue Screens of Death” most of which
were also recoverable.

When I say “bricked” what I mean is that the device becomes completely
unresponsive; No screen data, No input, No comms, the physical connection
is Not recognised by Windows (no Ping), device is Not in DFU Mode, Nada,
Zip . . . In short no apparent way to communicate with the device. This is
the ‘shcary’ part . . And it always seems to be displaying a white screen
when it goes into this state, hence the “White Screen of Death”.

For some people who may well be expert in Radio/Electronics but are not
familiar with microcontroller based devices such as the NanoVNA, that
becomes the end of the matter and the device is binned or left in a drawer
to gather dust (I inherited an early model & very dusty Pi in just that
way).

So knowing how to physically put/’force’ the device into DFU Mode** & to
try a different Firmware/.dfu file is what matters. Given that this could
also happen during a normal/’routine’ firmware upgrade I think it’s
important to be aware that there is a simple reliable physical solution
[**By shorting the Boot & VDD pins on the board].

BTW The NanoVNA App does appear to allow me to upload the ‘H4’ firmware to
a working ‘H’ model device – it does complain if I try and load it to a
‘bricked’ device. A minor bug/oversight perhaps or does it automagically
default to the correct ’H’ firmware?

Hope this helps . .

Kind Regards

Ross

Ross Filippi
VK2ATA

From: Larry Rothman<mailto:nlroth@rogers.com>
Sent: Friday, 9 October 2020 1:51 AM
To: nanovna-users@groups.io<mailto:nanovna-users@groups.io>
Subject: Re: [nanovna-users] Help! My NanoVNA bricked after a firmware
update! #firmware

Ross,
Welcome to the forum.
Please remember, you can only use nanovna-H4 firmware on an H4 with the 4
inch display and H firmware on anything that is either a Nanovna-H or just
Nanovna, with the 2.8 inch display.
If you are using 1of11's app to flash firmware, make sure it matches the
family of board you have: H (or earlier) or H4 !!
You cannot brick this unit and there is no 'white screen of death' - a
white screen just means you flashed the wrong family of firmware - just
flash the correct firmware and you're ready to go.
During DFU mode, there is no active comm port on the nanovna - that is why
it's called DFU mode.
Please read up on flashing ST32F series of microprocessors at the ST Micro
website.

On Thursday, October 8, 2020, 8:03:35 a.m. EDT, Ross Filipi <
rossfi@hotmail.com> wrote:

Hi All,
I'm new to the NanoVNA too (but fortunately not to
microcontrollers) and also managed to 'brick' mine and get the "white
screen of death". As one does I had a look around, came across this thread
and various others as well as this from Owen Duffy;
https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fowenduffy.net%2Fblog%2F%3Fp%3D16699&;amp;data=02%7C01%7C%7C27e9199e34e64353eebe08d86ed7fbac%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637381221231672388&amp;sdata=pdR4XkdMKWam%2FY17Fam%2Fc9KLSwlbMUTdGHIN%2BwKlWKA%3D&amp;reserved=0

Long story short I wasn't able to connect to the serial/usb port as that
had stopped working too - so was unable to apply CT2FZI's solution as
neither Putty or Tera-Term (or Windows(10) for that matter) could see a
comms port.

What I did find was that if I kept the Boot pin continuously shorted to
VDD on the P1 I/face, I was able to get the NanoVNA App by OneOfEleven to
upload a new .dfu file (either the preselected ones in the App or external
.dfu files (so long as they were 'good')). After that I just rebooted and I
was back in business. Bit shcary but all good . . .

Being a brave soul I repeated the process a number of times and have noted
that I appear have either;
- a number of bad dfu files or
- a number of dfu files that wont work with the NanoVNA App or
- a flakey NanoVNA Device
At any rate I've established that shorting the Boot pin to VDD &
repowering the VNA causes Windows(10) to 'see' the comms port allowing the
NanoVNA App to re-load a .dfu file (Reckon I'll be stopping in at Jaycar
tommorrow for a tiny switch). Since I've only been 'playing' with this
device for a few days I've not yet had a look at other DFU Manager apps as
the upload capability in the NanoVNA App was so convenient I just went
straight to that.

One odd thing to Note though; Apart from having to keep the boot pin
continuously shorted during the reload process - I also noticed that while
the NanoVNA App was able to communicate with the VNA for the upload process
it didn't seem to be able to recognise a comm port as such (see attached
pic) though I could hear the Windows 'ping' that signaled a new usb device.

I hope these observations are helpful . . .

Kind Regds
Ross VK2ATA

DiSlord:
The version I had issues with, was v 0.9.1.1, with SD card option.dd
I had to downgrade to v0.9.1.0 without the SD card option.
It works normally now.
Although I did lose the scale on the right side.

Sent from Mail for W

From: DiSlord
Sent: Monday, October 12, 2020 11:29 AM
To: nanovna-users@groups.io
Subject: Re: [nanovna-u
sers] Help! My NanoVNA bricked after a firmware update!#firmware

What version of firmware not work? You can run for example LSE version and not install external quartz (then firmware not run).

Your most welcome. Here is a picture of what the "pin connector" load looks like:
https://www.amazon.com/DHT-Electronics-coaxial-connector-Termination/dp/B00BXUYDMM/ref=sr_1_3?dchild=1&;keywords=sma+male+coaxial+termination&qid=1602538805&s=electronics&sr=1-3

Regards
wb7ond

Hi folks!

after quite a long time without using it, today I switched on my nanoVNA-H 3.4 and it got stacked at the first screen.
Version 0.4.5-1-gfbbceca / Build Time: Dec. 26 2019 - 19:32:31

I looged into it with a console and launched the "clearconfig 1234" command, without any success, the console just gets stacked at that command too.
USB cable is working, because other commands such as info, or threads are working properly.
Any suggestion?
Thanks a lot!

César, EA5IOQ.

Hello,


I recently flashed hugen79's firmware just because it seems to be the latest, but how do all the other firmwares actually compare?
https://github.com/hugen79/NanoVNA-H/releases

Many thanks

https://groups.io/g/nanovna-users/files/Firmware/All%20%28known%29%20publicly%20available%20NanoVNA%20DFU%20files%20from%20May%205,%202019%20through%20to%20Sept%2029,%202019

On Mon, Oct 12, 2020 at 03:36 AM, Christian Zietz wrote:

Among other things, this script can be used to derive the equations for the
SOLT error terms e22 and e10e32 for an arbitrary (but fully known!) through,
i.e., also including reflections. Or you can solve the equations for the DUT's
S parameters to get the equations that link error terms and measured S
parameters to the actual, corrected S parameters.

Hi Christian,

I just wanted to add that I solved the Forward and Reverse model equations for the four 2-port error terms a few days. ago, thus allowing one calculate all 12 error terms even if a non-ideal THRU is used during the two-port calibration.

The equation are in my blogpost (I scrapped the earlier work based on Schreuder's "De-embed" documentation"): http://k6jca.blogspot.com/search/label/VNA%3A%20Thru%20De-embedding

By the way, I also included a thanks to you at the end -- your earlier post in this thread got me to re-examine Rytting's equations, and I discovered the solution for THRU de-embedding was sitting in front of me.

Best regards,

- Jeff, k6jca

What version of firmware not work? You can run for example LSE version and not install external quartz (then firmware not run).

Some further comments on my post:

- The attenuator method may be required in cases where the output of the NanoVNA is too high for the device being tested and will either damage or overload it. This is the case when testing pre-amplifiers or the input of radio receivers. With NanoVNA's the lowest output possible is about -10 to -13 dBm with 2 ma. of Si5351 drive current which is quite high for many DUT's.

- In this example only CH0 is being used. An antenna would normally not be tested with this method. But I used an antenna for this example only because it shows a wide range of complex impedance (R and X) and SWR.

- If the gain versus frequency of an amplifier is being measured then 2 attenuators may be required. One on CH0 with enough attenuation to not overload the amplifier input and another on the input of CH1 so that the maximum level is kept below 0 dBm. For example if the NanoVNA output is 0 dBm; the amplifier has a gain of 30 dB, and the maximum amplifier input is -20 dBm you would need a 20 db attenuator on CH0 and a 10 dB one on CH1. You would do the SOL, Isolation and Through with both in place.

Roger

I found (by accident), that my version of the H-4 WITH the card holder,
would NOT work with the firmware update for the card. This is why the
screen went windows on me.
For the usual fecal funnies, I loaded the firmware that had no SD card
support...BINGO!
Back to normal!
V.0.9.1.0.dfu is the correct version (for my unit).
I hope this helps others suffering from SD card delusions of grandeur.
73!
KA9UCE

Last summer I saw something about new VNAs. Nano Vna v3 sounds especially interesting.

In new firmware you can reduce output power in CALIBRATE->POWER (need also made calibrate if change)

Or use 'power' console command

or use NanoVNA-App - and set power in it

in any case need recalibrate for new power value!

Thanks for sharing - I had plans to do this very same thing for testing bandpass filters that utilize a LNA, so as to prevent overloading. My interpretation of the effect shown with the attenuators added, is the detected result appears to be down closer to the noise floor of the device... not a major game changer - you can still get the results you're looking for when testing for the cutoff of a bandpass filter, or similar device...

Richard,
Thank you for the very clear explanation!
Michael

Sorry, I wanted to attach the files, as well.

On Fri, Oct 9, 2020 at 06:26 PM, Christian Zietz wrote:

Since parts of the VNA script where written during a previous employment [1],
I'm not free to share the script. Sorry!

What I can share, however, is the MATLAB script that I hacked together yesterday that contains the full (6 term) forward error model of a VNA. It requires MATLAB's symbolic toolbox. However, with a few changes, it can also be used with the free Octave and its respective symbolic package, as I've verified on Octave Online [1].

Among other things, this script can be used to derive the equations for the SOLT error terms e22 and e10e32 for an arbitrary (but fully known!) through, i.e., also including reflections. Or you can solve the equations for the DUT's S parameters to get the equations that link error terms and measured S parameters to the actual, corrected S parameters.

Enjoy,
Christian

[1] https://octave-online.net/bucket~DqDGMfxwwMKyMsmk4yDvHo
Note that you may have to click the "add 15 seconds" link while running the script to give it enough CPU time.

Hi Larry/OneOfEleven,
Many Thanks for the replies and advice, much appreciated . . And apologies for the slowww response, weekend obligations . . .

These days I tend to just dive in and follow the RTFM Rule; “When all else fails – RTFM” 😊 And since I’m building some Experimental Antennas that I plan to use for mobile emergency volunteer work I just need to ‘get comfortable’ enough with these gizmo’s to get some idea of how a wire will perform Before I try and poke a few hundred watts into it with an expensive radio . . .

Having said that I did manage to find a few moments to research & scan some info on the DFU mode vs USB protocol by way of getting my head around that.

A few further clarifications if I may . . .

“The White Screen of Death” was just a bit of tongue in cheek based on memories of a great many Windows NT “Blue Screens of Death” most of which were also recoverable.

When I say “bricked” what I mean is that the device becomes completely unresponsive; No screen data, No input, No comms, the physical connection is Not recognised by Windows (no Ping), device is Not in DFU Mode, Nada, Zip . . . In short no apparent way to communicate with the device. This is the ‘shcary’ part . . And it always seems to be displaying a white screen when it goes into this state, hence the “White Screen of Death”.

For some people who may well be expert in Radio/Electronics but are not familiar with microcontroller based devices such as the NanoVNA, that becomes the end of the matter and the device is binned or left in a drawer to gather dust (I inherited an early model & very dusty Pi in just that way).

So knowing how to physically put/’force’ the device into DFU Mode** & to try a different Firmware/.dfu file is what matters. Given that this could also happen during a normal/’routine’ firmware upgrade I think it’s important to be aware that there is a simple reliable physical solution [**By shorting the Boot & VDD pins on the board].

BTW The NanoVNA App does appear to allow me to upload the ‘H4’ firmware to a working ‘H’ model device – it does complain if I try and load it to a ‘bricked’ device. A minor bug/oversight perhaps or does it automagically default to the correct ’H’ firmware?

Hope this helps . .

Kind Regards

Ross

Ross Filippi
VK2ATA

From: Larry Rothman<mailto:nlroth@rogers.com>
Sent: Friday, 9 October 2020 1:51 AM
To: nanovna-users@groups.io<mailto:nanovna-users@groups.io>
Subject: Re: [nanovna-users] Help! My NanoVNA bricked after a firmware update! #firmware

Ross,
Welcome to the forum.
Please remember, you can only use nanovna-H4 firmware on an H4 with the 4 inch display and H firmware on anything that is either a Nanovna-H or just Nanovna, with the 2.8 inch display.
If you are using 1of11's app to flash firmware, make sure it matches the family of board you have: H (or earlier) or H4 !!
You cannot brick this unit and there is no 'white screen of death' - a white screen just means you flashed the wrong family of firmware - just flash the correct firmware and you're ready to go.
During DFU mode, there is no active comm port on the nanovna - that is why it's called DFU mode.
Please read up on flashing ST32F series of microprocessors at the ST Micro website.

On Thursday, October 8, 2020, 8:03:35 a.m. EDT, Ross Filipi <rossfi@hotmail.com> wrote:

Hi All,
I'm new to the NanoVNA too (but fortunately not to microcontrollers) and also managed to 'brick' mine and get the "white screen of death". As one does I had a look around, came across this thread and various others as well as this from Owen Duffy; https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fowenduffy.net%2Fblog%2F%3Fp%3D16699&;amp;data=02%7C01%7C%7C7d6c4a22ff09470f104908d86b99b27a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637377655148915989&amp;sdata=c55dniJwSiHSYfs5y2X9Y5TmWKH9LX6T5EQGyI4jWSA%3D&amp;reserved=0

Long story short I wasn't able to connect to the serial/usb port as that had stopped working too - so was unable to apply CT2FZI's solution as neither Putty or Tera-Term (or Windows(10) for that matter) could see a comms port.

What I did find was that if I kept the Boot pin continuously shorted to VDD on the P1 I/face, I was able to get the NanoVNA App by OneOfEleven to upload a new .dfu file (either the preselected ones in the App or external .dfu files (so long as they were 'good')). After that I just rebooted and I was back in business. Bit shcary but all good . . .

Being a brave soul I repeated the process a number of times and have noted that I appear have either;
- a number of bad dfu files or
- a number of dfu files that wont work with the NanoVNA App or
- a flakey NanoVNA Device
At any rate I've established that shorting the Boot pin to VDD & repowering the VNA causes Windows(10) to 'see' the comms port allowing the NanoVNA App to re-load a .dfu file (Reckon I'll be stopping in at Jaycar tommorrow for a tiny switch). Since I've only been 'playing' with this device for a few days I've not yet had a look at other DFU Manager apps as the upload capability in the NanoVNA App was so convenient I just went straight to that.

One odd thing to Note though; Apart from having to keep the boot pin continuously shorted during the reload process - I also noticed that while the NanoVNA App was able to communicate with the VNA for the upload process it didn't seem to be able to recognise a comm port as such (see attached pic) though I could hear the Windows 'ping' that signaled a new usb device.

I hope these observations are helpful . . .

Kind Regds
Ross VK2ATA

Micheal Greene

I looked at that Amazon link for those loads, I noticed those load connectors were "RP" which is reverse polarity connector.
There is a "hole" where there should be a pin in a non "RP" connector.
The NANOvna is expecting a center pin to be on the load. When the load is measured with an external VOM it will measure 50 ohms, because one probably puts the test lead into the hole. but
when plugged into the NANOvna there is no connection to the NANO via a center pin.
Regards
wb7ond

Herb,

Thanks. That looks like a nice firmware release.

Roger

On Sun, Oct 11, 2020 at 03:25 PM, Roger Need wrote:

DiSlord,

Is there a menu option in your firmware to set the Power level or must it be done by a console command?
==========================================

Roger,
See attachment. In version 1.0.39 the option is under the 'Calibrate->Power' menu. Per DiSlord, changing the power level requires the
SOLT calibration to be re-done.

- Herb

Wondered if I’d catch someone with that – I rarely misspell unless it’s intentional (think about it) 😊

Regds Ross

Ross Filippi
0424-317-705
VK2ATA

From: Danny K5CG via groups.io<mailto:k5cg=hamoperator.org@groups.io>
Sent: Sunday, 11 October 2020 5:04 AM
To: nanovna-users@groups.io<mailto:nanovna-users@groups.io>
Subject: Re: [nanovna-users] KIND REMINDER

bored

The same in American and British English.

----- Original Message -----

From: "Ross Filipi" <rossfi@hotmail.com>
To: nanovna-users@groups.io
Sent: Saturday, October 10, 2020 2:47:34 AM
Subject: Re: [nanovna-users] KIND REMINDER

Somebody’s board . . .

Thanks Jim’s – Very Amusing 😊

Regds Ross

Ross Filippi
VK2ATA

From: Jeff Anderson<mailto:jca1955@sbcglobal.net>
Sent: Saturday, 10 October 2020 7:57 AM
To: nanovna-users@groups.io<mailto:nanovna-users@groups.io>
Subject: Re: [nanovna-users] KIND REMINDER

Thanks very much, Carsten. I appreciate your checking of ISO 80000.1.

Yes, British English is different from American English in surprising ways. I
understand they even pronounce the "L in "SOLDER." Yikes!

Best regards,

- Jeff, k6jca