Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- Nanovna-Users
- Messages
Search
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,
toggle quoted message
Show quoted text
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 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 --
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
toggle quoted message
Show quoted text
Old. Celeron processor over 1 GHz 960MB Ram (1G?) CD Drive Ethernet and USB -----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: 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:
toggle quoted message
Show quoted text
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 |
Re: Very compressed SWR scale
#nanovna-h
On Thu, Jan 26, 2023 at 09:03 AM, Michael Black wrote:
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
Thanks Stan.
toggle quoted message
Show quoted text
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 -----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 |
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
toggle quoted message
Show quoted text
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 |
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?
toggle quoted message
Show quoted text
Thanks, Al -----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: 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
On Thu, Jan 26, 2023 at 05:19 PM, Al Waschka wrote:
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.
toggle quoted message
Show quoted text
This precludes me from changing the dfu. That is the problem I need to solve. On Jan 26, 2023, at 4:50 AM, HA3HZ <gyula@...> wrote: |
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:
toggle quoted message
Show quoted text
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 On Jan 26, 2023, at 4:39 AM, HA3HZ <gyula@...> wrote: |
Re: Very compressed SWR scale
#nanovna-h
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 |
Re: Very compressed SWR scale
#nanovna-h
Michael Black
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.
toggle quoted message
Show quoted text
What if you disconnect the feed line at the antenna?? That should be infinite SWR. Mike W9MDB 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 |
Very compressed SWR scale
#nanovna-h
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.
|
to navigate to use esc to dismiss