Hi Folks, This is a new thread regarding elimination of the libusb dependency. To start things off, there are two options current on the table. 1) Moving to a USB/Serial implementation. 2) Moving to a HID implementation. All are welcome to provide insights into this topic. USB is not a strong suit for me.
Libusb-win32 Drivers Download This page contains the list of Libusb-win32 drivers available for download. To download the proper driver, please find the category of.
The crew members plan to deliver an integrated cargo carrier and a Russian-built mini research module to the station. They also plan to bring a set of batteries for the station's truss and dish antenna, along with other replacement parts, NASA said.
Any help is appreciated. One thing is for sure, elimination of the libusb dependency is an absolute.
We need something that is universally supported by the various current operating systems. Internal medicine essentials for clerkship students pdf free. -- Thank you for your support and business, 73, The Multus SDR,LLC Team, Ron / W4MMP.
Hey Ron, I've reviewed the source and driver files briefly, but since libusb has a long and storied history, it helps to get understanding straight from the developer. First question: Does the ExtIO DLL use the older libusb-win32 library () or the newer libusb for Windows ()? The older library is tightly bound to the decrepit libusb-0.1 API and driver, and requires the libusb0.sys kernel driver in order to function. The newer library updates to the libusb-1.0 API, and is highly flexible about driver target. It can work with the libusb0.sys driver, but specifically, it allows communication with devices that are attached to the WinUSB driver too. Secondly, as far as I can tell we only use the driver for the Si570 interface, and the audio I/O is strictly USB audio class device (driver-less), is that right?
Does band/ptt control go through the same Si interface/endpoint or something else? -- Brian AF7MD.
Hi Ron, Sorry if I missed some recent discussions about this topic, but I am a bit confused about what the problem is and what you are are trying to accomplish. As I see it, eliminating libusb as a dependency and moving to serial or HID protocol are two completely different things. Libusb is just a cross platform API that provides USB access to applications running in user space.
It doesn't really care what protocol you are sending over it. For example, the libftdi [1] library uses libusb to access FTDI serial devices. Similarly, the cross platform hidapi [2] has an option to use libusb instead of OS system calls. If you have problems with libusb on windows, you can replace libusb with windows system calls without switching to serial or HID. Other SDR applications will continue to work without changes. However, if you decide to switch to a different serial or HID, existing softrock applications will no longer work.
Alex, OZ9AEC [1] [2]. On Fri, Jun 16, 2017 at 9:04 PM, Ron / W4MMP via Groups.Io wrote: Hi Folks, This is a new thread regarding elimination of the libusb dependency. To start things off, there are two options current on the table. 1) Moving to a USB/Serial implementation. 2) Moving to a HID implementation. All are welcome to provide insights into this topic. USB is not a strong suit for me.