When trying to run comms/nanovna-saver, it crashes with:
Copyright (C) 2019, 2020 Rune B. Broberg
Copyright (C) 2020 NanoVNA-Saver Authors
This program comes with ABSOLUTELY NO WARRANTY
This program is licensed under the GNU General Public License version 3
See https://github.com/NanoVNA-Saver/nanovna-saver for further details.
Traceback (most recent call last):
File "/usr/local/bin/NanoVNASaver", line 11, in <module>
load_entry_point('NanoVNASaver==0.3.8', 'console_scripts', 'NanoVNASaver')()
File "/usr/local/lib/python3.7/site-packages/NanoVNASaver/__main__.py", line 80, in main
window = NanoVNASaver()
File "/usr/local/lib/python3.7/site-packages/NanoVNASaver/NanoVNASaver.py", line 366, in __init__
File "/usr/local/lib/python3.7/site-packages/NanoVNASaver/NanoVNASaver.py", line 469, in rescanSerialPort
for iface in get_interfaces():
File "/usr/local/lib/python3.7/site-packages/NanoVNASaver/Hardware/Hardware.py", line 69, in get_interfaces
vid_pid = usb_vid_pid(d.device)
File "/usr/local/lib/python3.7/site-packages/NanoVNASaver/Hardware/Sysctl.py", line 20, in usb_vid_pid
result = (posix_sysctlbyname(b'dev.umodem.'+bytes(digit,'ascii')+b'.%pnpinfo')).decode('ascii')
File "/usr/local/lib/python3.7/site-packages/NanoVNASaver/Hardware/Sysctl.py", line 15, in posix_sysctlbyname
raise Exception('sysctlbyname returned with error %s' % result)
Exception: sysctlbyname returned with error -1
It turns out it simply uses the digits from the device names, and tries to use them as indices into sysctl("dev.umodem.<N>.%pnpinfo"). That just does not work as intended.
List of (accessible by users) serial devices here is:
Python 3.7.9 (default, Oct 16 2020, 21:50:54)
[Clang 10.0.1 (email@example.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611a on freebsd12
Type "help", "copyright", "credits" or "license" for more information.
>>> from serial.tools import list_ports
>>> s = list_ports.comports()
>>> for p in s:
Actually /dev/cuaU3 is the device in question, which corresponds to dev.umodem.0:
$ sysctl dev.umodem.0
dev.umodem.0.%pnpinfo: vendor=0x0483 product=0x5740 devclass=0x02 devsubclass=0x02 devproto=0x00 sernum="00000000001A" release=0x0200 mode=host intclass=0x02 intsubclass=0x02 intprotocol=0x01 ttyname=U3 ttyports=1
dev.umodem.0.%location: bus=5 hubaddr=2 port=4 devaddr=6 interface=0 ugen=ugen5.6
dev.umodem.0.%desc: SYSJOINT NanoVNA-F Virtual COMPort, class 2/2, rev 2.00/2.00, addr 6
When proceeding to digit 1 (from /dev/cuaU1), it hits the above error.
Created attachment 222957 [details]
Suggested new files/Sysctl.py
With the suggested new Sysctl.py, the port is found correctly.
However, when trying to attach to it, it still crashes:
2021-03-03 23:57:47,037 - NanoVNASaver.NanoVNASaver - ERROR - Unable to connect to VNA: read failed: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/NanoVNASaver/NanoVNASaver.py", line 516, in serialButtonClick
File "/usr/local/lib/python3.7/site-packages/NanoVNASaver/NanoVNASaver.py", line 548, in connect_device
frequencies = self.vna.readFrequencies()
File "/usr/local/lib/python3.7/site-packages/NanoVNASaver/Hardware/VNA.py", line 144, in readFrequencies
return [int(f) for f in self.readValues("frequencies")]
File "/usr/local/lib/python3.7/site-packages/NanoVNASaver/Hardware/VNA.py", line 178, in readValues
result = list(self.exec_command(value))
File "/usr/local/lib/python3.7/site-packages/NanoVNASaver/Hardware/VNA.py", line 88, in exec_command
File "/usr/local/lib/python3.7/site-packages/NanoVNASaver/Hardware/Serial.py", line 33, in drain_serial
cnt = len(serial_port.read(128))
File "/usr/local/lib/python3.7/site-packages/serial/serialposix.py", line 478, in read
serial.serialutil.SerialException: Attempting to use a port that is not open
Abort (core dumped)
Created attachment 222984 [details]
Updated patch file
Slightly updated version to the Sysctl.py fix, avoiding use of a variable that has not been assigned to.
The crash appears to be a different issue: I notice that as soon as opening the serial port (regardless which program is used), it disconnects from the system. Plugging the USB cable into a completely different host port (direct one rather than through USB hub) fixes that, and the program works as expected then.