Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
You are correct, in that by the strict definition of bricked, it is not. However it might as well be because the firmware in it is not very good and I cannot get it to respond to the USB port at all. It runs the loaded firmware in that it can be calibrated and sweeps the band, indicating whatever parameter I can designate in the FORMAT menu. It appears to imitate DFU mode in that the screen turns white when either I power up with jogwheel pressed or with jumper installed.
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
Al,
Just to verify: if you turn the device on, it's working with some version
of NanoVNA firmware.
It's not dead or bricked, it's just running firmware that's missing
features and you're trying to re-flash it.
The way you've been describing this has all of us assuming that it's
bricked because you keep using that word, but "bricked" means completely
dead, nonfunctional, where the only thing it's good for is a paperweight.
If it's running some level of NanoVNA, has a good display, then it's
working OK. The chances that this isn't able to get into DFU mode is
pretty low.
Please verify that it's in fact working.
73,
-Rick
toggle quoted message
Show quoted text
On Thu, Jan 26, 2023 at 2:47 PM Al Waschka <awaschka@...> wrote: I didn't answer your question about the source of my firmware. I can't
find the specific download site, but it was listed in "NanoVNA Very tiny
handheld Vector Network Analyzer User Guide" by gen111.taobao.com:
The 800MHz firmware works better at higher temperatures.
nanoVNA_800_ch£º50K-900MHz£¬5*7 Bitmap font£¬4 tracks(Recommended)
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Stan
Dye
Sent: Thursday, January 26, 2023 1:21 PM
To: [email protected]
Subject: Re: [nanovna-users] New Problem (Bricked?) Re: Trouble Setting Up
DFuSE Driver
So based on your detailed description, there are two other possibilities I
see in addition to what Gyula and others have noted:
1 - Infant mortality. Sometimes electrical components fail. If this all
happened within the first several hours of power-on of your nano, something
inside could have gone kaput. It would have to be the STM-32 processor or
some of the discrete logic forming the USB interface to the processor.
2 - Bad firmware, i.e not made for your device. It is conceivable, though
rare, that an incorrect firmware could put the hardware in a mode that
would cause it physical damage. For example, putting two gpio pins in
output mode that were externally connected together, or externally driven.
Or a firmware that was purposely created to make havoc. So that would beg
the question, where did you get this "800" firmware that you used from? (I
personally have never heard of it.) Are you sure it was created for a
nanovna-H model?
Sidenotes:
1 - I would personally do the linux test that was suggested, it may reveal
something.
2 - The 0.50 Hugen firmware that I think you said was in your device was
excellent firmware, stable and with a good set of features which may have
given you lots of good service (I used it for many months before
updating). We are often encouraged to upgrade when there is no real reason
for our use case to do so.
3 - Other than the intellectual challenge, how many hours of effort is a
$50 part worth? It may be better to give more value to your time, and get
a new nanovna-H4 (or maybe a litevna64 if you need accuracy on >>1.5GHz
frequencies) - these have hardware advantages, and are not much more
expensive.
Stan
On Thu, Jan 26, 2023 at 9:46 AM Al Waschka <awaschka@...> wrote:
You are telling me to use DFU mode to fix the problem and I have
repeatedly said I can't get into DFU mode and told what I have done to try.
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of
HA3HZ
Sent: Thursday, January 26, 2023 12:28 PM
To: [email protected]
Subject: Re: [nanovna-users] New Problem (Bricked?) Re: Trouble
Setting Up DFuSE Driver
I'm starting to feel like I want to help a person cross the busy road,
but he doesn't want to cross. While he was asking for help.
--
Gyula HA3HZ ( )
--
Rick Murphy, D. Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
HP Pavilion ZE 4220 Laptop
Old.
Celeron processor over 1 GHz
960MB Ram (1G?)
CD Drive
Ethernet and USB
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] < [email protected]> On Behalf Of Ho-Ro Sent: Thursday, January 26, 2023 2:15 PM To: [email protected]Subject: Re: [nanovna-users] New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver On Thu, Jan 26, 2023 at 06:42 PM, Al Waschka wrote:
I have an older HP Pavilion laptop that I could load a Linux build onto.
Please provide more information about the device, type / model, how old, etc...
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
I didn't answer your question about the source of my firmware. I can't find the specific download site, but it was listed in "NanoVNA Very tiny handheld Vector Network Analyzer User Guide" by gen111.taobao.com:
The 800MHz firmware works better at higher temperatures.
nanoVNA_800_ch£º50K-900MHz£¬5*7 Bitmap font£¬4 tracks(Recommended)
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] < [email protected]> On Behalf Of Stan Dye Sent: Thursday, January 26, 2023 1:21 PM To: [email protected]Subject: Re: [nanovna-users] New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver So based on your detailed description, there are two other possibilities I see in addition to what Gyula and others have noted: 1 - Infant mortality. Sometimes electrical components fail. If this all happened within the first several hours of power-on of your nano, something inside could have gone kaput. It would have to be the STM-32 processor or some of the discrete logic forming the USB interface to the processor. 2 - Bad firmware, i.e not made for your device. It is conceivable, though rare, that an incorrect firmware could put the hardware in a mode that would cause it physical damage. For example, putting two gpio pins in output mode that were externally connected together, or externally driven. Or a firmware that was purposely created to make havoc. So that would beg the question, where did you get this "800" firmware that you used from? (I personally have never heard of it.) Are you sure it was created for a nanovna-H model? Sidenotes: 1 - I would personally do the linux test that was suggested, it may reveal something. 2 - The 0.50 Hugen firmware that I think you said was in your device was excellent firmware, stable and with a good set of features which may have given you lots of good service (I used it for many months before updating). We are often encouraged to upgrade when there is no real reason for our use case to do so. 3 - Other than the intellectual challenge, how many hours of effort is a $50 part worth? It may be better to give more value to your time, and get a new nanovna-H4 (or maybe a litevna64 if you need accuracy on >>1.5GHz frequencies) - these have hardware advantages, and are not much more expensive. Stan On Thu, Jan 26, 2023 at 9:46 AM Al Waschka <awaschka@...> wrote: You are telling me to use DFU mode to fix the problem and I have
repeatedly said I can't get into DFU mode and told what I have done to try.
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of
HA3HZ
Sent: Thursday, January 26, 2023 12:28 PM
To: [email protected]
Subject: Re: [nanovna-users] New Problem (Bricked?) Re: Trouble
Setting Up DFuSE Driver
I'm starting to feel like I want to help a person cross the busy road,
but he doesn't want to cross. While he was asking for help.
--
Gyula HA3HZ ( )
|
On Thu, Jan 26, 2023 at 09:03 AM, Michael Black wrote:
What if you disconnect the feed line at the antenna?? That should be infinite
SWR.
The return loss (related to VSWR) will be twice the feedline loss, so not infinite VSWR. It should show very high VSWR (low return loss) when the analyzer connector is open- or short-circuited at the point where the calibration was done. however. 73,. Don N2VGU
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
On Thu, Jan 26, 2023 at 06:42 PM, Al Waschka wrote:
I have an older HP Pavilion laptop that I could load a Linux build onto.
Please provide more information about the device, type / model, how old, etc...
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
Thanks Stan.
I am working on the Linux angle.
I am less concerned with saving this $50 part than learning what happened so I will not repeat any mistake I might have made with a new unit.
I hope I can get the Linux angle working. That would seem to conclusively prove that there is something wrong with the device. Maybe I didn't brick it, it just failed.
The initial firmware load was apparently DisLords NanoVNA-H 1.1. Thinking some oddities I observed in operation were due to an -H dfu being loaded on a non-H device (which is what I thought I bought) I loaded nanoVNA_800_ch_20190920.dfu and things went downhill from there.
I have been thinking about what to replace this with assuming it is not recoverable. I am currently considering the hugen non-H 3.6 MS available from R&L or the contemporary -H model from the same vendor. I have also considered the -F for its reported better screen for outside use.
I am reluctant to purchase a more expensive unit unless and until I understand what happened to this one. In addition the unit as it was (without the oddities I observed, which I can't even remember now) was ell suited to my needs.
I'll report on the results of my Linux efforts.
Thanks and 73,
Al
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] < [email protected]> On Behalf Of Stan Dye Sent: Thursday, January 26, 2023 1:21 PM To: [email protected]Subject: Re: [nanovna-users] New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver So based on your detailed description, there are two other possibilities I see in addition to what Gyula and others have noted: 1 - Infant mortality. Sometimes electrical components fail. If this all happened within the first several hours of power-on of your nano, something inside could have gone kaput. It would have to be the STM-32 processor or some of the discrete logic forming the USB interface to the processor. 2 - Bad firmware, i.e not made for your device. It is conceivable, though rare, that an incorrect firmware could put the hardware in a mode that would cause it physical damage. For example, putting two gpio pins in output mode that were externally connected together, or externally driven. Or a firmware that was purposely created to make havoc. So that would beg the question, where did you get this "800" firmware that you used from? (I personally have never heard of it.) Are you sure it was created for a nanovna-H model? Sidenotes: 1 - I would personally do the linux test that was suggested, it may reveal something. 2 - The 0.50 Hugen firmware that I think you said was in your device was excellent firmware, stable and with a good set of features which may have given you lots of good service (I used it for many months before updating). We are often encouraged to upgrade when there is no real reason for our use case to do so. 3 - Other than the intellectual challenge, how many hours of effort is a $50 part worth? It may be better to give more value to your time, and get a new nanovna-H4 (or maybe a litevna64 if you need accuracy on >>1.5GHz frequencies) - these have hardware advantages, and are not much more expensive. Stan On Thu, Jan 26, 2023 at 9:46 AM Al Waschka <awaschka@...> wrote: You are telling me to use DFU mode to fix the problem and I have
repeatedly said I can't get into DFU mode and told what I have done to try.
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of
HA3HZ
Sent: Thursday, January 26, 2023 12:28 PM
To: [email protected]
Subject: Re: [nanovna-users] New Problem (Bricked?) Re: Trouble
Setting Up DFuSE Driver
I'm starting to feel like I want to help a person cross the busy road,
but he doesn't want to cross. While he was asking for help.
--
Gyula HA3HZ ( )
|
Re: Running NanoVNA-App under Wine
Mike,
yesterday I spent my free time trying to install Wine, but it didn't work on Vanilla OS. I tried several emulators though.
Then I started a search and found the Twister OS 2.1.2 OS, which already has Wine built into it.
I had to configure it before when doing two additional installs.
After that, I placed NanoVNA-App-v1.1.211.exe in the Documents folder, which logged in fine on the first start.
link:
I hope that your problem has been solved as well.
--
Gyula HA3HZ ( )
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
So based on your detailed description, there are two other possibilities I
see in addition to what Gyula and others have noted:
1 - Infant mortality. Sometimes electrical components fail. If this all
happened within the first several hours of power-on of your nano, something
inside could have gone kaput. It would have to be the STM-32 processor or
some of the discrete logic forming the USB interface to the processor.
2 - Bad firmware, i.e not made for your device. It is conceivable, though
rare, that an incorrect firmware could put the hardware in a mode that
would cause it physical damage. For example, putting two gpio pins in
output mode that were externally connected together, or externally driven.
Or a firmware that was purposely created to make havoc. So that would beg
the question, where did you get this "800" firmware that you used from? (I
personally have never heard of it.) Are you sure it was created for a
nanovna-H model?
Sidenotes:
1 - I would personally do the linux test that was suggested, it may reveal
something.
2 - The 0.50 Hugen firmware that I think you said was in your device was
excellent firmware, stable and with a good set of features which may have
given you lots of good service (I used it for many months before
updating). We are often encouraged to upgrade when there is no real reason
for our use case to do so.
3 - Other than the intellectual challenge, how many hours of effort is a
$50 part worth? It may be better to give more value to your time, and get
a new nanovna-H4 (or maybe a litevna64 if you need accuracy on >>1.5GHz
frequencies) - these have hardware advantages, and are not much more
expensive.
Stan
toggle quoted message
Show quoted text
On Thu, Jan 26, 2023 at 9:46 AM Al Waschka <awaschka@...> wrote: You are telling me to use DFU mode to fix the problem and I have
repeatedly said I can't get into DFU mode and told what I have done to try.
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of HA3HZ
Sent: Thursday, January 26, 2023 12:28 PM
To: [email protected]
Subject: Re: [nanovna-users] New Problem (Bricked?) Re: Trouble Setting Up
DFuSE Driver
I'm starting to feel like I want to help a person cross the busy road, but
he doesn't want to cross. While he was asking for help.
--
Gyula HA3HZ ( )
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
You are telling me to use DFU mode to fix the problem and I have repeatedly said I can't get into DFU mode and told what I have done to try.
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] < [email protected]> On Behalf Of HA3HZ Sent: Thursday, January 26, 2023 12:28 PM To: [email protected]Subject: Re: [nanovna-users] New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver I'm starting to feel like I want to help a person cross the busy road, but he doesn't want to cross. While he was asking for help. -- Gyula HA3HZ ( )
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
I have an older HP Pavilion laptop that I could load a Linux build onto. Wouldn't that work? Any suggested build?
Thanks,
Al
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] < [email protected]> On Behalf Of Ho-Ro Sent: Thursday, January 26, 2023 12:13 PM To: [email protected]Subject: Re: [nanovna-users] New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver On Thu, Jan 26, 2023 at 05:19 PM, Al Waschka wrote:
will not recognize the device as being in dfu mode
As a simple test you could connect the NanoVNA to a Linux computer, e.g. a Raspberry Pi and look what the command "lsusb" or "sudo dmesg" will tell you. If you do not have a Pi, just ask one of your friends, a lot of people with a technical hobby have these liitle boards in their drawer. Linux has the big advantage, that this nasty USB driver hell of Windows does not exist - USB just works out of the box. "lsusb" for normal mode (relevant line): Bus 006 Device 008: ID 0483:5740 STMicroelectronics Virtual COM Port "lsusb" for DFU mode (relevant line): Bus 006 Device 007: ID 0483:df11 STMicroelectronics STM Device in DFU Mode This is the output of "sudo dmesg" when switching the NanoVNA on in normal mode: [Jan26 06:05] usb 6-2: new full-speed USB device number 5 using uhci_hcd [ +0,181664] usb 6-2: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00 [ +0,000009] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ +0,000006] usb 6-2: Product: NanoVNA-H [ +0,000004] usb 6-2: Manufacturer: nanovna.com [ +0,000004] usb 6-2: SerialNumber: 1.2.19_noSD [ +0,003171] cdc_acm 6-2:1.0: ttyACM0: USB ACM device And this is "sudo dmesg" for "Jog-press-switch-on": [ +4,991887] usb 6-2: new full-speed USB device number 7 using uhci_hcd [ +0,180616] usb 6-2: New USB device found, idVendor=0483, idProduct=df11, bcdDevice=22.00 [ +0,000010] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ +0,000005] usb 6-2: Product: STM32 BOOTLOADER [ +0,000005] usb 6-2: Manufacturer: STMicroelectronics [ +0,000004] usb 6-2: SerialNumber: FFFFFFFEFFFF HTH Martin
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
I think that is unfair. How do I some combination of two computers and two cables to recognize that the NanoVNA has been plugged in?
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] < [email protected]> On Behalf Of HA3HZ Sent: Thursday, January 26, 2023 12:28 PM To: [email protected]Subject: Re: [nanovna-users] New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver I'm starting to feel like I want to help a person cross the busy road, but he doesn't want to cross. While he was asking for help. -- Gyula HA3HZ ( )
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
I'm starting to feel like I want to help a person cross the busy road, but he doesn't want to cross. While he was asking for help.
--
Gyula HA3HZ ( )
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
On Thu, Jan 26, 2023 at 05:19 PM, Al Waschka wrote:
will not recognize the device as being in dfu mode
As a simple test you could connect the NanoVNA to a Linux computer, e.g. a Raspberry Pi and look what the command "lsusb" or "sudo dmesg" will tell you. If you do not have a Pi, just ask one of your friends, a lot of people with a technical hobby have these liitle boards in their drawer. Linux has the big advantage, that this nasty USB driver hell of Windows does not exist - USB just works out of the box. "lsusb" for normal mode (relevant line): Bus 006 Device 008: ID 0483:5740 STMicroelectronics Virtual COM Port "lsusb" for DFU mode (relevant line): Bus 006 Device 007: ID 0483:df11 STMicroelectronics STM Device in DFU Mode This is the output of "sudo dmesg" when switching the NanoVNA on in normal mode: [Jan26 06:05] usb 6-2: new full-speed USB device number 5 using uhci_hcd [ +0,181664] usb 6-2: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00 [ +0,000009] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ +0,000006] usb 6-2: Product: NanoVNA-H [ +0,000004] usb 6-2: Manufacturer: nanovna.com [ +0,000004] usb 6-2: SerialNumber: 1.2.19_noSD [ +0,003171] cdc_acm 6-2:1.0: ttyACM0: USB ACM device And this is "sudo dmesg" for "Jog-press-switch-on": [ +4,991887] usb 6-2: new full-speed USB device number 7 using uhci_hcd [ +0,180616] usb 6-2: New USB device found, idVendor=0483, idProduct=df11, bcdDevice=22.00 [ +0,000010] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ +0,000005] usb 6-2: Product: STM32 BOOTLOADER [ +0,000005] usb 6-2: Manufacturer: STMicroelectronics [ +0,000004] usb 6-2: SerialNumber: FFFFFFFEFFFF HTH Martin
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
Since installation of the current 800ch dfu, my computer and cables, in exactly the same configuration used to load that dfu, will not recognize the device as being in dfu mode whether it is placed in white screen mode by jogwheel press at power on or by Vcc to Boot0 jumper.
This precludes me from changing the dfu.
That is the problem I need to solve.
toggle quoted message
Show quoted text
On Jan 26, 2023, at 4:50 AM, HA3HZ <gyula@...> wrote:
?The answer to your last question: Yes, the previous firmware can be restored, if you saved it before the update using DfuSe (in the window on the left) or if you can find the previous firmware somewhere, then with that. You can see a picture on my website. DFU mode will remain on the device until you upload a dfu that was written for this device. Then you can log in the next time you turn it on.
When the device is in DFU mode, it will remain in this mode until you have uploaded a usable firmware. Even if you turn it off and on again.
--
Gyula HA3HZ ( )
|
Long, sorry. Re: [nanovna-users] New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
I am not insulted because I don¡¯t think you or anyone else (perhaps because of my stepwise description of symptoms and actions) have understood my problem well enough to guide me to a solution. These are the salient facts:
1. As delivered, the device was sold as a NanoVNA
2. When I clicked on VERSION in the menus, it identified as a NanoVNA-H. The version number and build date were the same as that shown for one of DisLord¡¯s NanoVNA-H builds.
3. In the operational mode it identified as an unrecognized device and would not allow a different driver to be installed, saying the best driver was already installed. I was never able, following the procedures in either the NanoVNA Users Guide, the link you sent me, or the ABG to successfully load a driver (from the USB Comm Port zip) that would connect to VNASaver. I did plug it in to charge the battery without installing drivers. As I know this could create a problem, I deleted the device in device manager, unpluggedit, and restarted the computer before installing any software and drivers.
4. When placed in DFU mode and plugged into my laptop, it identified as an STM Bootloader When I installed DfuSe (but had to manually install the driver) from the 32080 zip it identified as an STM Device in DFU Mode. Thinking it was a NanoVNA, I installed a firmware build identified as an 800Mhz version because it was described as being better at high temperatures. Under this dfu the device operates normally with a very limited set of capabilities. There is no CONFIG menu option. The formats are very limited - for example there is no option to set a trace to display R or X. I decide I wanted to load a different dfu.
5. Since there was no option in the menu for DFU mode I tried depressing the jogwheel while powering up. I got the white screen which is alleged to indicate the unit is in DFU mode. When I plugged it into my computer using the cable, computer, software and drivers that worked with the previous dfu load, the device was not identified. It was not even enumerated as a USB device when plugged in and did not show up in Device Manager or USBDeview. The previous configuration was listed in USBDeview but was shown as not connected. Deleting and reinstalling DfuSe and the driver didn¡¯t help. Deleting the entry in USBDeview didn¡¯t help.
6. Following suggestions on here I tried a different cable on the original computer and both cables on a different computer with a no software or drivers installed. The response was the same. The device was not recognized when plugged in in either normal operations mode or DFU mode set when booting with the jogwheel depressed.
Questions:
1. Why, when connected to either computer in alleged DFU Mode (white screen), isn¡¯t the computer detecting that a new device is being plugged in and showing it in Device Manager or USBDeview, at least as STM Bootloader?
2. Why would neither dfu setup accept a driver for the ¡°Unrecognized USB Device¡±?
3. If this is recoverable, why can¡¯t anyone tell me how to do it? At least three of us have apparently managed to brick or partially (in my case) brick versions of the NanoVNA.
Background:
I am a trained BEE, MSEE electrical engineer with experience in analog and digital design and system engineering. I have technically directed significant system, hardware, and software development projects. I have written, loaded, and troubleshot microcomputer code on the metal and in assembly language, finding both hardware and software errors. It was said, during my career, that one of my strong skills was troubleshooting at the system, hardware, and software level. Full disclosure, I am not a coder, and have only a basic understanding of a few higher level languages, but that would not seem to be a shortcoming in this situation.
Please don¡¯t take this as an insult. If the problem is not in the device, please help me to figure out what the problem is. I think I have followed a logical process that, at least in my mind, concludes the problem is in the hardware, software or a combination of both, in the specific clone I purchased.
Thanks to everyone one here who tried to help, and especially to Gyula for his help and contributions to the community.
Al, K5TAN
toggle quoted message
Show quoted text
On Jan 26, 2023, at 4:39 AM, HA3HZ <gyula@...> wrote:
?Al, I know that everyone has different tolerances and the basic knowledge of technical things is different.
If you have read and understood my writing, you should know that the firmware can be installed on an old device and a newly manufactured device (differentiated by the version number on the pcb) in the same way.
The difference is that what users and developers saw as possibilities in the meantime were incorporated into the firmware (i.e. the dfu file). I also have a device manufactured before August 2019, but I can update it in the same way as with the latest version.
I think that your problem is not the device, but its lack of knowledge of computer applications, which is why you now think that it is not good.
The next device will be no different, but you will have to replace the knowledge. If many people give different ideas, they only increase the uncertainty. The knowledge required for this device can be acquired. All it takes is persistence.
You should also know that computer knowledge is constantly changing, because software developers always encourage you to buy newer versions, because they make a living from it.
The foundations of this device were conceived in Japan in 2016, although earlier traces could certainly be found.
The technology at that time was between windows 7 and 10.
What dfu drivers were used at that time, the drivers were made for these versions. The Virtual Communication Port (VCP), which is needed to access the NanoVNA with a PC - there is even a driver for XP.
You have to be able to understand and separate how I can use the device itself. How can I use it with a computer (with VCP driver). And you need to know when you've had enough of the old firmware and want to get to know the newer one as well. This requires the dfu driver, which can be seen in the Device Manager as "STM Device in DFU mode". Knowledge of use must be constantly updated. As my daughter saw above the school board when she was in high school: "Only change is permanent".
So with this comment I just want to say that the problem is not in the device.
Please do not take this writing as an insult. I tried to describe the essence.
--
Gyula HA3HZ ( )
|
Marc,
Perhaps your NanoVNA calibration is bad. If you leave the NanoVNA connector open does it show an extremely high SWR, as it should? If you place the calibration load on the NanoVNA connector does it show 1.0:1 VSWR, as it should?
Another possibility is that your feedline has become very lossy. A feedline with 10 dB loss would produce results similar to what you are seeing.
Jon w2anz
|
What does your coax feed to the antenna contain?? Since SWR is a voltage measurement either the return voltage is getting attenuated or the NanoVNA isn't measuring one of the voltages correctly.
What if you disconnect the feed line at the antenna?? That should be infinite SWR.
Mike W9MDB
toggle quoted message
Show quoted text
On Thursday, January 26, 2023 at 07:37:08 AM CST, Marc VK3OHM <vk3ohm@...> wrote:
I have a NanoVNA-H which I haven't used for 2 years. Just pulled it out of the cupboard and upgraded to latest firmware (1.0.69). The spane is set to 1MHz to 40MHz, and it has been calibrated. It seems to be working of sorts measuring SWR, but the SWR figures are not credible. Attached is a portion of the SWR graph for my 4 band trapped dipole (80-40-20-15-10m). The general shape of the graph is correct, with the minimums in the right place, but the SWR never gets above 1.18. I wish my antenna was that good, but it should be going off the chart literally for most of the time. Any idea why it should give misleading results like this.
|
Updating the firmware on a nanoVNA-H4 with a Mac
I've ordered a new nanoVNA-H4 . As it is new, I don't expect I will immediately need to upgrade the firmware. However, I want to be prepared.
I use this command to upgrade the firmware on my tinySA ultra:
dfu-util -a 0 -s 0x08000000:leave -D tinySA.bin\
This command will upgrade both a tinySA and a tinySA Ultra. I feel more comfortable in the terminal using dfu-util and lesserly comfortable in adding yet another program to my Mac. Though I've not searched the web yet, I've not seen a program like the many I see for windows being used in this forum for upgrading. I there a similar usage of the dfu_util command for the nanoVNA - H4?
Thank you, larry
|
I have a NanoVNA-H which I haven't used for 2 years. Just pulled it out of the cupboard and upgraded to latest firmware (1.0.69). The spane is set to 1MHz to 40MHz, and it has been calibrated. It seems to be working of sorts measuring SWR, but the SWR figures are not credible. Attached is a portion of the SWR graph for my 4 band trapped dipole (80-40-20-15-10m). The general shape of the graph is correct, with the minimums in the right place, but the SWR never gets above 1.18. I wish my antenna was that good, but it should be going off the chart literally for most of the time. Any idea why it should give misleading results like this.
|
Donald S Brant Jr
Ho-Ro
HA3HZ
Jon MacGahan
