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: NanoVNA H4 calibration anomaly
John,
toggle quoted message
Show quoted text
Are you sure that your phase trace is looking at S21 phase and not S11 phase? --John Gord On Thu, Jan 26, 2023 at 08:47 PM, John Kaufmann wrote:
|
|
NanoVNA H4 calibration anomaly
John Kaufmann
I'm running into an issue trying to calibrate my NanoVNA H4 so that I can run S21 scans. I've done the calibration two ways: (1) using the NanoVNA-saver software and (2) using the on-screen menu on the VNA itself. The first method works fine but the second one does not. I don't know why there is this discrepancy.
Using the on-screen method, I run through the calibration menu procedure: open, short, load (50 ohms), isolation, and through (using a short SMA jumper cable between the CH0 and CH1 ports). I happen to be doing this over a frequency range of 100 kHz to 5 MHz. When I'm done I save the result and apply the calibration. Next I check the calibration by running an S21 scan, leaving the jumper cable in place between the CH0 and CH1 ports, If the calibration has been done correctly, I should see an S21 magnitude of 0 dB and S21 phase of 0 degrees across the frequency range. I do see 0 dB but the phase is wildly inaccurate, and varies between 177 degrees at 100 kHz to 141 degrees at 5 MHz. When I do the same calibration using the NanoVNA-saver software and following the calibration steps in the software, I get the correct S21 results with the jumper cable connecting the CH0 and CH1 ports. It shows 0 dB and 0 degrees phase from 100 kHz to 5 MHz. If I run an S21 scan of a two-port device like a filter, both the on-screen and NanoVNA-saver scans produce the same S21 magnitude but not phase. The phase that's displayed in the on-screen method varies all over the place and is clearly erroneous. What am I doing wrong that I cannot get a correct calibration and S21 phase measurement with the on-screen method? John W1FV |
|
Re: Very compressed SWR scale
#nanovna-h
The standards by their nature are delicate, as the manufacturer attempts to minimize parasitic capacitance/inductance. This often results in mechanically less-than-robust construction.
This mechanical weakness is exacerbated by the fact that many inexpensive standards do not have a place to hold the standard from rotating when mating/demating the connectors; the resulting rotation of the standard can unscrew a threaded center pin, or worse, extend it out so that it damages another connector. Metrology grade calibration kits include gages to ensure that the connector pins are properly positioned and connectors are gaged before beginning a calibration. "Turn the nut, do not turn the connector body" is the mantra. A useful habit to develop before calibration is to watch the screen as you connect each standard in turn, to ensure that the expected, or at least different, response is obtained. This will help to pick up gross problems with the cal standards. Another is to closely examine the mating surfaces of the standards for bent, distorted or missing pins or damaged outer conductors. I have even found a male pin which someone left in a female standard. 73, Don N2VGU |
|
Re: NanoVNA Not Recognized by Laptop over USB After dfu Upgrade
Thanks,
The question is which statement in the manufacturer's brochure is incorrect. But the "other cable" is the one that came with the NanoVNA and it worked a few minutes prior to the point at which it didn't work. I have a ISB-A to USB-C adapter I bought yesterday, and a USB-A Male to Male cable coming tomorrow. That setup will implement a USB-A to USB-C cable that whould work. If it does then we will know the problem was the cable. I suspect it will not. |
|
Re: NanoVNA Not Recognized by Laptop over USB After dfu Upgrade
Hi,
toggle quoted message
Show quoted text
In point 8 you say that the new cable is identified as a "charging cable" and this type of cable is only for charging but not for data transfer. After that you say that in the description they say that you can transfer data while charging, so this is not what a "charging cable does", this description applies to a "normal" cable.? I would check both cables with a phone for transferring files or images between the phone and a PC. It they work the cables are OK. Regards, Ignacio El 27/01/2023 a las 1:59, Al Waschka escribi¨®:
Chronology of the Problem --
Este correo electr¨®nico ha sido analizado en busca de virus por el software antivirus de Avast. www.avast.com |
|
Re: Very compressed SWR scale
#nanovna-h
hah, and I just sent a suggestion - yeah, it happens. And to someone with your callsign, how ironic.
I've had more than one 50 ohm load turn into an open - or what's worse, 50 ohms at high frequencies, but open at low - a break, with sufficient capacitance that at some GHz, the capacitive impedance was negligible - so it was a fine S band load. If you have a spare 3-10 dB pad around, that's a handy thing to use as a cross check, too. |
|
Re: Very compressed SWR scale
#nanovna-h
If you clear the calibration (reset), so it's totally uncalibrated, what does it show? It should show S11 fairly low with a load, and close to zero with either open or short. If it does, then check your calibration standards. It's not unheard of for shorts or loads to change - I have a load that decided to become an open one day, close to 50 ohms, then it wasn't the next day. Who knows what happened (probably some sort of tiny crack that developed and finally went open).
Also check your frequency range. Set it to something "moderate" like 1-100 MHz |
|
Re: NanoVNA Not Recognized by Laptop over USB After dfu Upgrade
Chronology of the Problem
1. Unpacked NanoVNA ordered from eBay vendor as a non-H unit, powered up and operated, including calibration, configuration, and testing an existing antenna system until the display started to dim. VERSION identified the dfu as NanoVNA-H Version 1;1 Build Time Dec 21 2021 2. Plugged the unit into a powered USB hub to charge the battery. The laptop powered up but not active. 3. After charging, played with it some more, including trying to install and operate VNA Saver on a laptop, with no success. The device would be detected by the laptop as an ¡°Unidentified Device¡± and would not allow me to update the driver to the STM USB CommPort driver in the 32102(?) zip file. As a result, I decided to change the firmware load. I picked a load identified as nanoVNA_800_ch_20190920.dfu and after calibrating and configuring it realized it was substantially less capable than the original load. I decided to replace the dfu with another. 4. I went through the documented process for installing DfuSe demo on my laptop. When I tried to complete the verify drivers step, I found that the laptop was reporting ¡°STM Bootloader¡± as the device, instead of the correct ¡°STM Device in DFU Mode¡±. After several iterations I found that it might be necessary to manually install the proper driver. When I did that the proper designation appeared and I installed nanoVNA_800_ch£º50K-900MHz dfu. 5. Immediately on started the new firmware I noticed the lack of features. There was no CONFIG menu. The list of parameters available for display in the FORMATS menu significantly less than in the original version and lacked the R and X values that I am particularly interested in. I decided to change back to the original version and immediately noticed there was no DFU option in the menus. After some research I discovered that pressing the jogwheel down while powering the device up might put in in DFU mode. When I did that, I got a white screen which is allegedly indicative of being in DFU mode. 6. When I connected the device to the laptop used to load the new firmware onto the device the computer did not react at all. When I went into device manager, I expected to see the ¡°STM Device in DFU Mode¡± identified but it wasn¡¯t there. Neither was the ¡°STM Bootloader¡±. 7. When I posted these facts on Groups.io several members responded with suggestions including that the cable might be bad, or something changed in the computer. 8. I purchased and tried a new cable without success. The new cable came from the phone section and was identified as a charging cable, but the description said you could transfer data while charging. I tried the device on another computer with both cables with no success. Even on the new computer which did not have the DFU mode driver there was no indication of the ¡°STM Bootloader¡±. 9. At various points during this process while testing DFU mode I would try powering on with the Vcc to Boot0 jumper in place, which also produced the white screen response but didn¡¯t change the way the device enumerated on the laptop, i.e it didn¡¯t show up in device manager. 10. Also at various points in the process I tried to update the driver with the device on normal operating mode, but was never able to successfully install the Com Port driver. 11. I am pursuing two paths to identify the guilty party, i.e. the device or the computer. I am trying to get my hands on a Liinux device to see how it responds in both modes to Linux commands and trying to locate an Android device capable of loading the NanaVNA app. 12. More as it happens¡¡ |
|
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.
|
Donald S Brant Jr
Roger Need
to navigate to use esc to dismiss