search

NanoVNA-Saver / nanovna-saver

A tool for reading, displaying and saving data from the NanoVNA
GNU General Public License v3.0
874 stars 272 forks source link

Connecting to NanoVNA ends in unresponsive state of nanovna-saver #134

Closed mklengel closed 4 years ago

mklengel commented 4 years ago

Describe the bug After the installation (python3 -m pip .) everything works up to the point when I try to start the connection between the App and the NanoVNA-H. Then nanvna-saver doesn’t respond and I have to kill it. The device file seems correct (/dev/cu.usbmodem4001).

To Reproduce Steps to reproduce the behavior:

  1. Terminal: NanoVNASaver
  2. Click on: Connect to NanoVNA

Expected behavior I expect a working connection.

Screenshots

Bildschirmfoto 2020-01-15 um 19 47 33

Desktop (please complete the following information):

Additional context To kill NanoVNASaver I have to type Ctrl-C in the terminal, which gives the following output:

MacPro-MK:nanovna-saver mklengel$ ls -l /dev/cu.*
crw-rw-rw-  1 root  wheel   18,   5 15 Jan 11:06 /dev/cu.Bluetooth-Incoming-Port
crw-rw-rw-  1 root  wheel   18,   9 15 Jan 11:06 /dev/cu.LGSOUNDPLATE4B54-BTSPP2
crw-rw-rw-  1 root  wheel   18,   1 15 Jan 11:06 /dev/cu.SLAB_USBtoUART
crw-rw-rw-  1 root  wheel   18,   3 15 Jan 11:06 /dev/cu.SLAB_USBtoUART1
crw-rw-rw-  1 root  wheel   18,   7 15 Jan 11:06 /dev/cu.iPhone8-mk-WirelessiAPv2
crw-rw-rw-  1 root  wheel   18,  15 15 Jan 19:45 /dev/cu.usbmodem4001

MacPro-MK:nanovna-saver mklengel$ NanoVNASaver
NanoVNASaver 0.2.2
Copyright (C) 2019 Rune B. Broberg
This program comes with ABSOLUTELY NO WARRANTY
This program is licensed under the GNU General Public License version 3

See https://github.com/mihtjel/nanovna-saver for further details
Settings: /Users/mklengel/.config/NanoVNASaver/NanoVNASaver.ini
^CTraceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/NanoVNASaver/NanoVNASaver.py", line 637, in serialButtonClick
    self.startSerial()
  File "/usr/local/lib/python3.7/site-packages/NanoVNASaver/NanoVNASaver.py", line 656, in startSerial
    self.vna = VNA.getVNA(self, self.serial)
  File "/usr/local/lib/python3.7/site-packages/NanoVNASaver/Hardware.py", line 49, in getVNA
    return NanoVNA_H(app, serial_port)
  File "/usr/local/lib/python3.7/site-packages/NanoVNASaver/Hardware.py", line 235, in __init__
    self.version = Version(self.readVersion())
  File "/usr/local/lib/python3.7/site-packages/NanoVNASaver/Hardware.py", line 338, in readVersion
    data = self.serial.readline().decode('ascii')
  File "/usr/local/lib/python3.7/site-packages/serial/serialposix.py", line 483, in read
    ready, _, _ = select.select([self.fd, self.pipe_abort_read_r], [], [], timeout.time_left())
KeyboardInterrupt
Abort trap: 6

MacPro-MK:~ mklengel$ head /usr/local/bin/NanoVNASaver
#!/usr/local/opt/python/bin/python3.7
# -*- coding: utf-8 -*-
import re
import sys
from NanoVNASaver.__main__ import main
if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0])
    sys.exit(main())
MacPro-MK:~ mklengel$
mihtjel commented 4 years ago

Hi, it looks like the NanoVNA is detected (I assume the port name is autodetected?) and that the connection does open - and that the device does then not respond. To me, this looks like a defective device or defective firmware. From the trace, you can see that the connection is stuck in "self.serial.readline()", which is a system call to read bytes from the device.

Have you had your NanoVNA working with any other software? Have you tried connecting directly to the serial port interface?

mklengel commented 4 years ago

Hello mihtjel, I don't like Windows that much but I gave it a try. The windows version works, the macOS version doesn’t. I flashed the same firmware with dfu-util on macOS, the problem on macOS remained. During the "Non-Source" flash procedure I was not sure which file I had to use. I decided to give the .bin file a try just because I've found the same one in the "build from source" documentation.

I used the precompiled firmware files and dfu-util gave me a message:

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!

but the procedure continued successfully.

MacPro-MK:Firmware mklengel$ ls
NanoVNA-H_20191125.bin  NanoVNA-H_20191125.dfu  NanoVNA-H_20191125.hex
MacPro-MK:Firmware mklengel$
MacPro-MK:Firmware mklengel$ dfu-util --list --device 0x83:df11
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [0483:df11] ver=2200, devnum=2, cfg=1, intf=0, path="93-1", alt=1, name="@Option Bytes  /0x1FFFF800/01*016 e", serial="FFFFFFFEFFFF"
Found DFU: [0483:df11] ver=2200, devnum=2, cfg=1, intf=0, path="93-1", alt=0, name="@Internal Flash  /0x08000000/064*0002Kg", serial="FFFFFFFEFFFF"
MacPro-MK:Firmware mklengel$
MacPro-MK:Firmware mklengel$
MacPro-MK:Firmware mklengel$ dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D NanoVNA-H_20191125.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Downloading to address = 0x08000000, size = 96488
Download    [=========================] 100%        96488 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state
MacPro-MK:Firmware mklengel$

Did I use the wrong file?

Building from source according to https://github.com/ttrftech/NanoVNA was my last action and it doesn't work either on macOS.

MacPro-MK:NanoVNA-H mklengel$ git clone https://github.com/ttrftech/NanoVNA.git
Klone nach 'NanoVNA' ...
remote: Enumerating objects: 38, done.
remote: Counting objects: 100% (38/38), done.
remote: Compressing objects: 100% (27/27), done.
remote: Total 1366 (delta 19), reused 25 (delta 11), pack-reused 1328
Empfange Objekte: 100% (1366/1366), 1.24 MiB | 2.79 MiB/s, Fertig.
Löse Unterschiede auf: 100% (955/955), Fertig.
MacPro-MK:NanoVNA-H mklengel$ cd NanoVNA/
MacPro-MK:NanoVNA mklengel$ git submodule update --init --recursive
Submodul 'ChibiOS' (https://github.com/edy555/ChibiOS.git) für Pfad 'ChibiOS' in die Konfiguration eingetragen.
Klone nach '/Volumes/Macintosh SR0/Users/mklengel/Development/NanoVNA-H/NanoVNA/ChibiOS' ...
Submodule path 'ChibiOS': checked out '669d4bbc8da1ee0e4ccdf93a472b06d183922320'
MacPro-MK:NanoVNA mklengel$ pwd
/Users/mklengel/Development/NanoVNA-H/NanoVNA
MacPro-MK:NanoVNA mklengel$ ls
ChibiOS         STM32F072xB.ld      ffconf.h        main.c          prog.sh         ui.c
Font5x7.c       adc.c           fft.h           mcuconf.h       python          usbcfg.c
Makefile        chconf.h        flash.c         nanovna.h       si5351.c        usbcfg.h
NANOVNA_STM32_F072  doc         halconf.h       numfont20x22.c      si5351.h
README.md       dsp.c           ili9341.c       plot.c          tlv320aic3204.c
MacPro-MK:NanoVNA mklengel$ make
Compiler Options
arm-none-eabi-gcc -c -mcpu=cortex-m0 -O2 -fno-inline-small-functions -ggdb -fomit-frame-pointer -falign-functions=16 --specs=nano.specs -fstack-usage -ffunction-sections -fdata-sections -fno-common -Wall -Wextra -Wundef -Wstrict-prototypes -Wa,-alms=build/lst/ -DCORTEX_USE_FPU=FALSE -DSHELL_CMD_TEST_ENABLED=FALSE -DSHELL_CMD_MEM_ENABLED=FALSE -DARM_MATH_CM0 -DVERSION="0.5.4-5-g38e64a6" -DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -MD -MP -MF .dep/build.d -I. -IChibiOS/os/license -IChibiOS/os/common/startup/ARMCMx/compilers/GCC -IChibiOS/os/common/startup/ARMCMx/devices/STM32F0xx -IChibiOS/os/common/ext/CMSIS/include -IChibiOS/os/common/ext/CMSIS/ST/STM32F0xx -IChibiOS/os/rt/include -IChibiOS/os/common/oslib/include -IChibiOS/os/common/ports/ARMCMx -IChibiOS/os/common/ports/ARMCMx/compilers/GCC -IChibiOS/os/hal/osal/rt -IChibiOS/os/hal/include -IChibiOS/os/hal/ports/common/ARMCMx -IChibiOS/os/hal/ports/STM32/STM32F0xx -IChibiOS/os/hal/ports/STM32/LLD/ADCv1 -IChibiOS/os/hal/ports/STM32/LLD/CANv1 -IChibiOS/os/hal/ports/STM32/LLD/DACv1 -IChibiOS/os/hal/ports/STM32/LLD/DMAv1 -IChibiOS/os/hal/ports/STM32/LLD/EXTIv1 -IChibiOS/os/hal/ports/STM32/LLD/GPIOv2 -IChibiOS/os/hal/ports/STM32/LLD/I2Cv2 -IChibiOS/os/hal/ports/STM32/LLD/RTCv2 -IChibiOS/os/hal/ports/STM32/LLD/SPIv2 -IChibiOS/os/hal/ports/STM32/LLD/TIMv1 -IChibiOS/os/hal/ports/STM32/LLD/USARTv2 -IChibiOS/os/hal/ports/STM32/LLD/USBv1 -IChibiOS/os/hal/ports/STM32/LLD/xWDGv1 -I./NANOVNA_STM32_F072 -IChibiOS/os/hal/lib/streams -IChibiOS/os/various/shell main.c -o main.o

Compiling crt0_v6m.s
dyld: Library not loaded: /usr/local/opt/isl/lib/libisl.21.dylib
  Referenced from: /usr/local/Cellar/arm-none-eabi-gcc/7.4.0/libexec/gcc/arm-none-eabi/7.4.0/cc1
  Reason: image not found
arm-none-eabi-gcc: interner Compiler-Fehler: Abort trap: 6 (Programm cc1)
Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein;
inclusive vorverarbeitetem Quellcode, wenn es dienlich ist.
Weitere Hinweise finden Sie unter »<https://gcc.gnu.org/bugs/>«.
make: *** [build/obj/crt0_v6m.o] Error 4
MacPro-MK:NanoVNA mklengel$ brew tap px4/px4
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/cask).
No changes to formulae.

MacPro-MK:NanoVNA mklengel$ brew install gcc-arm-none-eabi-80
Warning: px4/px4/gcc-arm-none-eabi-80 20181220 is already installed, it's just not linked
You can use `brew link gcc-arm-none-eabi-80` to link this version.
MacPro-MK:NanoVNA mklengel$ brew link gcc-arm-none-eabi-80
Linking /usr/local/Cellar/gcc-arm-none-eabi-80/20181220...
Error: Could not symlink bin/arm-none-eabi-addr2line
Target /usr/local/bin/arm-none-eabi-addr2line
is a symlink belonging to arm-none-eabi-binutils. You can unlink it:
  brew unlink arm-none-eabi-binutils

To force the link and overwrite all conflicting files:
  brew link --overwrite gcc-arm-none-eabi-80

To list all files that would be deleted:
  brew link --overwrite --dry-run gcc-arm-none-eabi-80
MacPro-MK:NanoVNA mklengel$ brew link --overwrite gcc-arm-none-eabi-80
Linking /usr/local/Cellar/gcc-arm-none-eabi-80/20181220... 482 symlinks created
MacPro-MK:NanoVNA mklengel$ make clean
Cleaning
rm -fR .dep build

Done
MacPro-MK:NanoVNA mklengel$ make
Compiler Options
arm-none-eabi-gcc -c -mcpu=cortex-m0 -O2 -fno-inline-small-functions -ggdb -fomit-frame-pointer -falign-functions=16 --specs=nano.specs -fstack-usage -ffunction-sections -fdata-sections -fno-common -Wall -Wextra -Wundef -Wstrict-prototypes -Wa,-alms=build/lst/ -DCORTEX_USE_FPU=FALSE -DSHELL_CMD_TEST_ENABLED=FALSE -DSHELL_CMD_MEM_ENABLED=FALSE -DARM_MATH_CM0 -DVERSION="0.5.4-5-g38e64a6" -DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -MD -MP -MF .dep/build.d -I. -IChibiOS/os/license -IChibiOS/os/common/startup/ARMCMx/compilers/GCC -IChibiOS/os/common/startup/ARMCMx/devices/STM32F0xx -IChibiOS/os/common/ext/CMSIS/include -IChibiOS/os/common/ext/CMSIS/ST/STM32F0xx -IChibiOS/os/rt/include -IChibiOS/os/common/oslib/include -IChibiOS/os/common/ports/ARMCMx -IChibiOS/os/common/ports/ARMCMx/compilers/GCC -IChibiOS/os/hal/osal/rt -IChibiOS/os/hal/include -IChibiOS/os/hal/ports/common/ARMCMx -IChibiOS/os/hal/ports/STM32/STM32F0xx -IChibiOS/os/hal/ports/STM32/LLD/ADCv1 -IChibiOS/os/hal/ports/STM32/LLD/CANv1 -IChibiOS/os/hal/ports/STM32/LLD/DACv1 -IChibiOS/os/hal/ports/STM32/LLD/DMAv1 -IChibiOS/os/hal/ports/STM32/LLD/EXTIv1 -IChibiOS/os/hal/ports/STM32/LLD/GPIOv2 -IChibiOS/os/hal/ports/STM32/LLD/I2Cv2 -IChibiOS/os/hal/ports/STM32/LLD/RTCv2 -IChibiOS/os/hal/ports/STM32/LLD/SPIv2 -IChibiOS/os/hal/ports/STM32/LLD/TIMv1 -IChibiOS/os/hal/ports/STM32/LLD/USARTv2 -IChibiOS/os/hal/ports/STM32/LLD/USBv1 -IChibiOS/os/hal/ports/STM32/LLD/xWDGv1 -I./NANOVNA_STM32_F072 -IChibiOS/os/hal/lib/streams -IChibiOS/os/various/shell main.c -o main.o

Compiling crt0_v6m.s
Compiling chcoreasm_v6m.s
Compiling crt1.c
Compiling vectors.c
Compiling chsys.c
Compiling chdebug.c
Compiling chtrace.c
Compiling chvt.c
Compiling chschd.c
Compiling chthreads.c
Compiling chregistry.c
Compiling chmtx.c
Compiling chevents.c
Compiling chcore.c
Compiling chcore_v6m.c
Compiling osal.c
Compiling hal.c
Compiling hal_st.c
Compiling hal_buffers.c
Compiling hal_queues.c
Compiling hal_mmcsd.c
Compiling hal_dac.c
Compiling hal_ext.c
Compiling hal_gpt.c
Compiling hal_i2c.c
Compiling hal_i2s.c
Compiling hal_pal.c
Compiling hal_rtc.c
Compiling hal_serial.c
Compiling hal_serial_usb.c
Compiling hal_spi.c
Compiling hal_usb.c
ChibiOS/os/hal/src/hal_usb.c: In function '_usb_ep0in':
ChibiOS/os/hal/src/hal_usb.c:842:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
     if ((usbp->ep0n < max) &&
        ^
ChibiOS/os/hal/src/hal_usb.c:851:3: note: here
   case USB_EP0_WAITING_TX0:
   ^~~~
In file included from ChibiOS/os/rt/include/ch.h:82,
                 from ChibiOS/os/hal/osal/rt/osal.h:32,
                 from ChibiOS/os/hal/include/hal.h:28,
                 from ChibiOS/os/hal/src/hal_usb.c:27:
ChibiOS/os/rt/include/chdebug.h:129:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
   if (CH_DBG_ENABLE_ASSERTS != FALSE) {                                     \
      ^
ChibiOS/os/hal/osal/rt/osal.h:241:34: note: in expansion of macro 'chDbgAssert'
 #define osalDbgAssert(c, remark) chDbgAssert(c, remark)
                                  ^~~~~~~~~~~
ChibiOS/os/hal/src/hal_usb.c:873:5: note: in expansion of macro 'osalDbgAssert'
     osalDbgAssert(false, "EP0 state machine error");
     ^~~~~~~~~~~~~
ChibiOS/os/hal/src/hal_usb.c:875:3: note: here
   case USB_EP0_ERROR:
   ^~~~
In file included from ChibiOS/os/rt/include/ch.h:82,
                 from ChibiOS/os/hal/osal/rt/osal.h:32,
                 from ChibiOS/os/hal/include/hal.h:28,
                 from ChibiOS/os/hal/src/hal_usb.c:27:
ChibiOS/os/hal/src/hal_usb.c: In function '_usb_ep0out':
ChibiOS/os/rt/include/chdebug.h:129:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
   if (CH_DBG_ENABLE_ASSERTS != FALSE) {                                     \
      ^
ChibiOS/os/hal/osal/rt/osal.h:241:34: note: in expansion of macro 'chDbgAssert'
 #define osalDbgAssert(c, remark) chDbgAssert(c, remark)
                                  ^~~~~~~~~~~
ChibiOS/os/hal/src/hal_usb.c:932:5: note: in expansion of macro 'osalDbgAssert'
     osalDbgAssert(false, "EP0 state machine error");
     ^~~~~~~~~~~~~
ChibiOS/os/hal/src/hal_usb.c:934:3: note: here
   case USB_EP0_ERROR:
   ^~~~
Compiling nvic.c
Compiling hal_lld.c
Compiling stm32_dma.c
Compiling hal_st_lld.c
Compiling hal_dac_lld.c
Compiling hal_ext_lld.c
Compiling hal_ext_lld_isr.c
Compiling hal_pal_lld.c
Compiling hal_i2c_lld.c
Compiling hal_rtc_lld.c
Compiling hal_i2s_lld.c
ChibiOS/os/hal/ports/STM32/LLD/SPIv2/hal_i2s_lld.c: In function 'i2s_lld_start':
ChibiOS/os/hal/ports/STM32/LLD/SPIv2/hal_i2s_lld.c:461:19: warning: assignment to 'uint32_t' {aka 'long unsigned int'} from 'volatile uint32_t *' {aka 'volatile long unsigned int *'} makes integer from pointer without a cast [-Wint-conversion]
       i2sp->rx_dr = &i2sp->spi->DR;
                   ^
Compiling hal_spi_lld.c
Compiling hal_gpt_lld.c
Compiling hal_serial_lld.c
Compiling hal_usb_lld.c
In file included from ChibiOS/os/rt/include/ch.h:82,
                 from ChibiOS/os/hal/osal/rt/osal.h:32,
                 from ChibiOS/os/hal/include/hal.h:28,
                 from ChibiOS/os/hal/ports/STM32/LLD/USBv1/hal_usb_lld.c:27:
ChibiOS/os/hal/ports/STM32/LLD/USBv1/hal_usb_lld.c: In function 'usb_lld_init_endpoint':
ChibiOS/os/rt/include/chdebug.h:129:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
   if (CH_DBG_ENABLE_ASSERTS != FALSE) {                                     \
      ^
ChibiOS/os/hal/osal/rt/osal.h:241:34: note: in expansion of macro 'chDbgAssert'
 #define osalDbgAssert(c, remark) chDbgAssert(c, remark)
                                  ^~~~~~~~~~~
ChibiOS/os/hal/ports/STM32/LLD/USBv1/hal_usb_lld.c:588:5: note: in expansion of macro 'osalDbgAssert'
     osalDbgAssert(false, "isochronous support disabled");
     ^~~~~~~~~~~~~
ChibiOS/os/hal/ports/STM32/LLD/USBv1/hal_usb_lld.c:590:3: note: here
   case USB_EP_MODE_TYPE_BULK:
   ^~~~
Compiling board.c
Compiling chprintf.c
Compiling memstreams.c
Compiling nullstreams.c
Compiling shell.c
Compiling shell_cmd.c
Compiling usbcfg.c
Compiling main.c
Compiling si5351.c
Compiling tlv320aic3204.c
Compiling dsp.c
Compiling plot.c
Compiling ui.c
Compiling ili9341.c
Compiling numfont20x22.c
Compiling Font5x7.c
Compiling flash.c
Compiling adc.c
Linking build/ch.elf
Creating build/ch.hex
Creating build/ch.bin
Creating build/ch.dmp

   text    data     bss     dec     hex filename
  92572    5040   11536  109148   1aa5c build/ch.elf
Creating build/ch.list

Done
MacPro-MK:NanoVNA mklengel$ ls
ChibiOS         STM32F072xB.ld      dsp.c           ili9341.c       plot.c          tlv320aic3204.c
Font5x7.c       adc.c           ffconf.h        main.c          prog.sh         ui.c
Makefile        build           fft.h           mcuconf.h       python          usbcfg.c
NANOVNA_STM32_F072  chconf.h        flash.c         nanovna.h       si5351.c        usbcfg.h
README.md       doc         halconf.h       numfont20x22.c      si5351.h
MacPro-MK:NanoVNA mklengel$ make -n flash
dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D build/ch.bin
MacPro-MK:NanoVNA mklengel$ make flash
dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D build/ch.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Downloading to address = 0x08000000, size = 97612
Download    [=========================] 100%        97612 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state

Do you see any chance to solve the problem with macOS?

Regards Michael

mklengel commented 4 years ago

In the meantime I've found a workaround using an USB hub, which uses this kernel extension: SiLabsUSBDriver CP210x USB to UART Bridge VCP Driver 5.2.4

See the screenshots of the working configuration (NanoVNA attached to the USB hub):

Bildschirmfoto 2020-01-16 um 19 34 52 Bildschirmfoto 2020-01-16 um 19 40 12

and the IOJones screenshot of the non-working configuration (NanoVNA attached to the native USB port of my MacPro 5,1):

Bildschirmfoto 2020-01-16 um 19 39 22

I have no explanation but the problem seems to be the communication to the native USB ports/drivers/extension(s).

Regards Michael

mihtjel commented 4 years ago

Hmm, this is a very odd problem - but it does not sound related to NanoVNA-Saver as much as to the operating system/device/hardware. I'm happy that you found a solution, and I hope you enjoy using the software!

mklengel commented 4 years ago

Hello mihtjel,

I can live with my solution. May be its useful to mention another great open source app, which works on the native USB ports of the MacPro 5,1 too:

https://gitlab.com/DavidGriffith/minipro

Regards Michael

mihtjel commented 4 years ago

I know that NanoVNA-Saver works with the native ports on macs from other users - exactly what's the issue on your particular setup is difficult to diagnose remotely :-)

mklengel commented 4 years ago

Nothing special - its a standard macOS Mojave installation. Is there a flag for debugging purposes?

mihtjel commented 4 years ago

Yes, -d gives you debugging output, -D file.txt to save it to a file.

On Fri, 17 Jan 2020 at 11:32, Michael Klengel notifications@github.com wrote:

Nothing special - its a standard macOS Mojave installation. Is there a flag for debugging purposes?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/mihtjel/nanovna-saver/issues/134?email_source=notifications&email_token=AGLTTOKS6AYE2VW4WFIPMSLQ6GCMNA5CNFSM4KHIIUG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJHIBEQ#issuecomment-575570066, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGLTTOMPRILTSWHBGCEBU6DQ6GCMNANCNFSM4KHIIUGQ .

mklengel commented 4 years ago

The NanoVNA works also on a PCIe based USB Host-Controller. Has anyone working the NanoVNA on a native USB port of a MacPro 4,1 or 5.1?

mihtjel commented 4 years ago

I don't know - sounds like a question for the nanovna-users mailing list :-)

-- Rune

On Fri, 17 Jan 2020 at 12:51, Michael Klengel notifications@github.com wrote:

The NanoVNA works also on a PCIe based USB Host-Controller. Has anyone working the NanoVNA on a native USB port of a MacPro 4,1 or 5.1?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/mihtjel/nanovna-saver/issues/134?email_source=notifications&email_token=AGLTTOLSTDYEUQ7VL7LNR5LQ6GLTPA5CNFSM4KHIIUG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJHONHI#issuecomment-575596189, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGLTTOJIORILGQEVQIGOMI3Q6GLTPANCNFSM4KHIIUGQ .

mklengel commented 4 years ago

Thx for the hint :-)