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: Very compressed SWR scale
#nanovna-h
Terry Perdue
I would think that someone with a call like yours would have checked the load first! (Just kidding!)
toggle quoted message
Show quoted text
On Jan 26, 2023, at 2:47 PM, Marc VK3OHM <vk3ohm@...> wrote: |
|
Re: Very compressed SWR scale
#nanovna-h
Thank you Owen Duffy for an off list suggestion. Turns out the 50 ohm load had failed open circuit, so it was not calibrated. Replaced the load and now working perfectly. Who'd have thought one of those could fail?
|
|
Re: Very compressed SWR scale
#nanovna-h
On Thu, Jan 26, 2023 at 01:03 PM, Marc VK3OHM wrote:
I suggest you do a Clear Config before you calibrate. Also remember to Reset before you do the calibration. Check your cal loads and make sure they measure open , 0 ohms and 50 ohms. Then cal and when done the dot should be in the middle of the Smith chart for 50 ohms, on the far left for short and far right for open. Roger |
|
Re: Very compressed SWR scale
#nanovna-h
Thanks for all your assistance - I'm pretty sure my NanoVNA has a serious fault. A new one is on order. I checked the antenna with a SARK 110, and got exactly the result I expected, so that eliminates the antenna and feed as the problem. My NanoVNA is actually not the H model, but the vanilla one. Have upgraded it to what I believe is the latest firmware - v0.8.0. Development of this branch seems to have ceased in 2020, so time for an upgrade anyway. Have bought the latest 4" H model.
|
|
NanoVNA Not Recognized by Laptop over USB After dfu Upgrade
This is the third Topic generated during my trip along the path to becoming a NanoVNA user.
toggle quoted message
Show quoted text
In the first I described a problem with getting the NanoVNA to be recognized by my laptop running W10, either in the normal NanoVNA operating mode or in DFU mode. With the Group's assistance I was able to get the device to respond to the USB port only in DFU mode. Unfortunately I upgraded to an older, less capable dfu without clearing the device or saving the originally dfu. So I decided to return to the original dfu which I neglected to save but have tentatively identified as DisLord's NanoVNA-H Version 1.1 dfu. Unfortunately I was unsuccessful in that attempt and generated the second Topic. In the second Topic I used the term "Bricked?" in the subject and repeatedly described the unit as bricked which was technically incorrect. Many users responded with helpful suggestions but I was unable to get the unit to work in any way other than to execute the loaded firmware to analyze the spectrum. I apologize for any confusion caused by describing the unit as bricked. I am generating this Topic to describe the current problem which is that the unit is detected but not recognized in its normal operating mode and will not allow me to change the driver, and it is not recognized at all in what appears to be the DFU mode. The question to be answered is whether the problem is in the unit, or in the computer I am trying to connect to. In the second thread, Ho-Ro has commented: QUOTE Ho-Ro 9:12am #31144 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 UNQUOTE I am currently following that path, but I have to acquire a Linux capability first. |
|
Re: Very compressed SWR scale
#nanovna-h
I have done the calibration a few times so I think it's OK. Leaving the NanoVNA connector open gives an SWR of 1.183 right across 1MHZ to 40MHz. I think it's broken. I have measured a different antenna, and I get similar results.
|
|
Re: Very compressed SWR scale
#nanovna-h
Feedline is ~30m of RG213. Not really practical to disconnect coax at antenna as it's 15 meters in the air. This NanoVNA has correctly measured the SWR 2 years ago. I think it has died.
|
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
Apparently my use of the (Bricked?) description was confusing, and I apologize.
I am going to open a new thread with the subject "NanoVNA not recognized by computer after upgrading Firmware with DfuSe Demo SW" I suggest that no more replies be made to this thread. Please see the new thread for any further developments. I appreciate everyone's helpful comments and will try to be clearer in the new thread. |
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
The time from working with the original fw load and not identifying as a DFU unit was literally minutes, on the same cable, computer, software and drivers.
The Version Page of the hardware with its original fw load said it was a NanoVNA-H Version 1;1 Build Time Dec 21 2021 13:46:37. I only reloaded DfuSe and the driver when I couldn't get the hardware to show up at all when I put it in DFU mode (or thought I did) by pressing the jogwheel when powering up. I got the white screen which is supposed to indicate DFU mode. When none of that worked I used the hardware method of shorting the Vcc test point to the Boot0 test point When I powered up I got the white screen. Unfortunately the computer did not recognize the unit when I plugged it in. The NanoVNA User Guide contains a schematic. The Boot0 pin (which is set to 1 when it is shorted to Vcc, along with two programmable bits, control which portion of memory is selected during boot. So if different fw loads control those two programmable bits differently, it would seem possible that a fw load could change how the hardware boots up and also casts some doubt on the prevalent opinion that the boot code is controlled by separate hardware, making the units "unbrickable". This is just my assessment as a retired engineer reading schematics and chip data manuals, and may not be correct. I am running a current version of Windows 10, so not W11. |
|
Re: New Problem (Bricked?) Re: Trouble Setting Up DFuSE Driver
OK, synthesizing Stan and Tim's replies with what I read in the STM device data,
From STM RM0091 Sec. 2.5: Under normal circumstances (Boot0 pin = 0) the device will boot from Main Flash Memory. I presume this is where the NanaVNA code is stored. This mode works normally in that the loaded fw esecutes when the deice starts normally and the operation was changed when I uploaded new FW using the DFU mode from the original fw load. When DFU mode is desired (Boot0 pin = 1) the device will boot from either System Memory if <nboot1> = 1 or Embedded Static Ram if <nboot1> = 0. I presume one of these locations (probably System Memory) is where the DFU mode software is located. So it seems possible that improper configuration of the device w.r.t. <nboot1> could cause a boot error. Assuming that the DFU code is in System Memory which is programmed at the factory, a fw up load could not overwrite it. The remaining cause is a bad cable, as several have suggested. I was reluctant to conclude that was the cause, and I will have to purchase another cable to test that hypothesis. |
|
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 |
Roger Need
Donald S Brant Jr
Ho-Ro
HA3HZ
to navigate to use esc to dismiss