开云体育

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……