Is there a place where I can find documentation or an SDK about the Logitech Unifying Receiver?
I recently obtained a wireless mouse, which came with a Logitech Unifying Receiver (a small USB dongle that plugs into the computer and communicates with the mouse/other compatible devices (such as keyboards)).
I wanted to try writing an app for my smartphone that pretends to be a mouse and sends data to the receiver.
I was able to monitor the data from the USB bus by using usbmon, and could probably use that to hack something out, but wanted to know if I could find the info I need somewhere on the internet without having to derive it on my own.
I'm going to try using SL4A on Android, if that helps any.
I have discovered some Logitech documents on a shared folder in Google Docs via this Chromium bug report. For convenience, I converted all doc(x) files to PDFs and put those on https://lekensteyn.nl/files/logitech/.
You will find Logitech HID++ 1.0 Specification for Unifying Receivers (pdf) very interesting, it describes the USB traffic (instead of the 2.4GHz wireless traffic as noted by Avery). My article Logitech Unifying for Linux: Reverse Engineering and unpairing tool documents a way to capture the traffic with usbmon and QEMU. It also includes tools to make the usbmon output prettier to read (for this protocol).
This is Avery, aka Tequals0. The USB dongle is a USB HID mouse/keyboard device, so all that traffic that you are seeing is basically generic HID traffic- if you want to pair your phone to your dongle, you will have to emulate the wireless traffic, not the USB traffic-that is generated by the dongle.
There is some info at Tequals0 blog, and AveryLouie also got some python tool operating with unifying
Related
I made a custom USB sensor device that runs on a Windows 8.1 / 10 desktop computer using the WinUSB driver (I implemented Microsoft extended USB descriptors in device firmware to automatically install the driver when the device connected).
Can I use a WinUSB device on HoloLens2? Or, if there is no WinUSB support on HoloLens2, how can I use my USB device with a “custom USB device class”?
At the moment, I do not have a hololens2, but I need to understand how the USB works on it.
Edit: I found this link: https://learn.microsoft.com/en-us/hololens/hololens-connect-devices#hololens-2-connect-usb-c-devices
It says that hololens2 supports the following device classes:
Mass storage devices (such as thumb drives)
Ethernet adapters (including ethernet plus charging)
USB-C-to-3.5mm digital audio adapters
USB-C digital audio headsets (including headset adapters plus charging)
Wired mouse
Wired keyboard
Combination PD hubs (USB A plus PD charging)
My device does not implement any of these classes (custom class). Is there a chance to make it work on hololens2?
I finally tested my code and USB device on real Hololens 2. The USB device works great there because Hololens2 supports WinUSB! The WinUSB driver was installed automatically (my device has WinUSB descriptors).
According to the documentation you referred, all classes HoloLens2 supports have been listed, and unlisted classes are not supported.
Could you provide more information about your business request and submit a feature request via feedback hub on new feature request to be considered in future releases of HoloLens OS and devices?
If it’s a hot impacted feature, it will be possible to be given priority to jump in the development schedule. Actually, the existing classed on HoloLens 2 are also based on user’s feedback in such way.
For how to post feedback request, you can follow this doc: Send feedback to Microsoft with the Feedback Hub app.
Hopefully I will have more luck today. I have no prior USB integration and about 8 months of learning embedded systems on Atmel devices. I am trying to use an Atmel SAM L series to connect over USB to a computer. The use case is for data transfer. Specifically, the MCU will be gathering data from it's sensors and packaging it for USB transfer.
I have searched through and read up on all of Atmel's included USB examples. I have also started reading through usb.org's class specifications for CDC.
I have running now something that lets me send data along one com port, into the target usb and then out the debugger usb to another com port. However, I don't think this is real USB.
My problem is two fold.
1.) I do not fully understand what differentiates USB from serial communication on a com port.
2.) Even if I were doing it correctly, I'm not sure how to test and verify that I have indeed created a legitimate USB device that can be accepted by a host computer.
Links to documentation(Atmel or generic) or example code would be appreciated.
1) USB is defined in the USB specifications from http://www.usb.org. Serial ports were an older and simpler interface that involved sending data back and forth asynchonously on pins with names like TX and RX. The USB CDC class and its ACM subclass allow you to make a USB device that emulates a serial port. If you make your device be a USB CDC ACM device, then you don't need to supply any drivers for Windows 10, Linux, or Mac OS X.
2) You can read the USB specification and the CDC ACM specification. You can run the USB command verifier. You can test your device with a variety of different USB hosts to make sure it works.
For testing purposes I need to power off a USB device from my computer programmatically. The microprocessor in the USB device is ARM Cortex M4.
I have tried using Devcon, although the device was disabled, power was still provided to the device.
I have also tried to disable the USB root hubs ,that also didn't work.
I have read some other posts indicating that a SSR could be used, this option is not desired. I would rather choose the software solution(if there is one of course).
Some other answers have indicated that this is an OS issue, and some others a chip-set architecture issue.
So my question is what options are there available. And also is this purely something dependent on the computer side or do we need to implement something on the USB device side as well.
Thank you in advance.
I need to communicate with some custom hardware that will use either a FTDI or Silicon Labs usb to serial driver.
I found a couple examples but they are older and was hoping for a more up to date example. Plus, I have been confused by the new AppleUSBFTDI kernel driver in how that works with the IOKit and other chips like the Silicon Labs part. It would be nice to have one program that doesn’t care which driver is used.
I have already looked at this example:
FTDI Communication with USB device - Objective C
The nature of these drivers and devices is that they are supposed to function as a standard serial port virtually over USB. So in terms of access it should be no different than accessing a standard RS232 COM port.
I would suggest reading the Serial Programming Guide for POSIX Operating Systems. I'm not sure what older examples you're seeing but serial access itself is many years old, but the idea behind communicating to the serial device is the same in the case of these USB to serial bridge devices.
For information on some Objective-C frameworks, take a look at this Stack Overflow post.
Finally, here is an article directly from the Apple documentation, Working With a Serial Device, and you'll see it also references the POSIX style API.
You should simply need to install the driver associated with your device and plug it in for this to work. In terms of the Silicon Labs CP210x device just download and install the OSX driver. Then plug in your device. This is where the one difference may show up, the name of the tty device on the system (it will show up in the /dev directory). In the case of the CP210x it will show up and be accessible as tty.SLAB_USBtoUART or cu.SLAB_USBtoUART. This will be the name of the device you should open, then use and API from above to start your communication.
I have been tasked with writing a USB driver for our embedded software to send raw data to Host. This will be used to send some logging data to host. We are using iMX31 litekit for development.
From the documents that I have read on USB, my understanding is that the embedded device will be in device mode only. Also it will only be communicating with host machine.
So can any one guide me here? Any article, reference or code is welcome.
Some things to consider:
Is this a high bandwidth device like a camera or data recorder, or a low bandwidth device?
For low bandwidth, I would strongly consider making your device act as a USB HID class. This is the device class that supports keyboards, mice, joysticks, gamepads, and the like. It is relatively easy to send data to nearly any application, and it generally doesn't require that you write a custom device driver on the host side. That latter feature alone is often worth the cost of lightly contorting your data into the shape assumed by the HID class. All the desktop operating systems that do USB can use HID devices, so you get broad compatibility fairly easily.
For high bandwidth, you would still be better served if your device fits one of the well established device classes, where a stock device driver on the host end of the wire can be used. One approach that often works is to use the Mass Storage class, and emulate a disk drive containing one file. Then, your device simply mounts on the host as if it were a disk, and you communicate by reading and writing to one (or a few) file.
I would expect there to be a fair amount of sample code out there for any serious USB device chipset that implements either or both of HID and Mass Storage.
If you really must wander into fully custom device territory, then you will need to be building device drivers for each host platform. The open source libusb library can be of some help, if its license is compatible with your project. There are also ways in newer versions of Windows to develop USB drivers that run in user mode using the User Mode Driver Framework that have many of the same advantages of libusb, but are not portable off the Windows platform.
The last custom device I worked on was based on a Cypress device, and we were able to ship their driver and an associated DLL to make our application code easier to build. I don't know off the cuff if there is any equivalent available for your device.
For a really good overview, I recommend the USB FAQ, and the latest edition of Jan's book, USB Complete.