After the release of Mortal Kombat X, [Zachery’s] gaming group wanted to branch out into the fighter genre. They quickly learned that in order to maximize their experience, they would need a better controller than a standard gamepad. A keyboard wasn’t going to cut it either. They wanted a fight stick. These are large controllers that look very much like arcade fighting controls and include a joystick and large buttons. [Zachery’s] group decided to build their own fight stick for use with a PC.
[Zachery] based his build around the TeensyLC, which is a 32 bit development board with an ARM processor. It’s also compatible with Arduino. The original version of his project setup the controller as a HID, essentially emulating a keyboard. This worked for a while until they ran into compatibility issues with some games. [Zachery] learned that his controller was compatible with DirectInput, which has been deprecated. The new thing is Xinput, and it was going to require more work.
Using Xinput meant that [Zachery] could no longer use the generic Microsoft HID driver. Rather than write his own drivers, he decided to emulate the XBOX 360 controller. When the fight stick is plugged into the computer, it shows up as an XBOX 360 controller and Windows easily installs the pre-built driver. To perform the emulation, [Zachery] first had to set the VID and PID of the device to be identical to the XBOX controller. This is what allows the Microsoft driver to recognize the device.
Next, the device descriptor and configuration descriptor had to be added to the Teensy’s firmware. The device descriptor includes information such as USB version, device class, protocol, etc. The configuration descriptor includes additional information about the device configuration. [Zachery] used Microsoft Message Analyzer to pull the configuration descriptor from a real XBOX 360 controller, then used the same data in his own custom controller.
[Zachery] programmed the TeensyLC using the Arduino IDE. He ran into some trouble here because the IDE did not include the correct device type for an Xinput device. [Zachery] had to edit the boards.txt file and add three lines of code in order to add a new hardware device to the IDE’s menu. Several other files also had to be modified to make sure the compiler knew what an Xinput device type was. With all of that out of the way, [Zachery] was finally able to write the code for his controller.
[Bbraun] has an old Macintosh SE computer. He was looking for a way to view the video output from the SE on a newer, modern computer. He ended up working out a pretty clever solution using a stm32f4discovery board.
First, the SE’s logic board was removed from its case and placed onto a desk for easier access. The discovery board was then hooked up to the SE’s processor direct slot (PDS) using normal jumper wires. The discovery board acts as a USB COM port on a newer Mac OSX computer. The discovery board watches the SE for writes to video memory. When it sees that the R/W pin goes low, it knows that a write is occurring. It then waits for /AS to go low, which indicates that an address is on the bus. The discovery board reads the address and verifies that it falls within the range of the video frame buffer. If it does, then the discovery board writes a copy of the data to a local buffer.
The OSX computer runs a simple app that can make a request to the discovery board via USB. When the board receives the request, it sends its local frame buffer data over the USB connection and back to the host. The OSX computer then displays that data in a window using CGImage. The demo video below was captured using this technique. Continue reading “Viewing A Macintosh SE’s Video On A Modern Computer”→
[pmf], like most of us, I’m sure, spends most of his days on a computer. He also has a smartphone he keeps at his side, but over the years he’s grown accustomed to typing on a real keyboard. He came up with the idea of making a USB switch that would allow his keyboard to control either his computer or his phone, and hit upon a really neat way of doing it. He’s using a BeagleBone Black and a Teensy to switch his keyboard between his computer and his phone with just a press of a button.
This homebrew smart KVM uses a BeagleBone Black for most of the heavy lifting. A keyboard and mouse is connected to the USB host port of the BeagleBone, and the main computer is connected to the device port. The BeagleBone is set up to pass through the USB keyboard and mouse to the computer with the help of what Linux calls a ‘gadget’ driver. This required an update to the Linux 4.0 kernel.
With the BeagleBone capable of being a USB pass through device, the next challenge was sending keypresses to another USB device. For this, a Teensy 2.0 was connected to the UART of the BeagleBone. According to [pmf], this is one of the few examples of the Teensy serving as a composite USB device – sending both keyboard and mouse info.
There are a few neat features for [pmf]’s build: the keyboard and mouse don’t disconnect when switching, and thanks to a slight modification of the USB OTG adapter, this will also charge a phone as well as allow for the use of a keyboard. Because the BeagleBone Black has more than one UART this build can also switch keyboards and mice between more than two computers. For those of us who invest heavily in keyboards, it’s a godsend.
USB has become pretty “universal” nowadays, handling everything from high-speed data transfer to charging phones. There are even USB-powered lava lamps. This ubiquity doesn’t come without some costs, though. There have been many attacks on smartphones and computers which exploit the fact that USB is found pretty much everywhere, and if you want to avoid these attacks you can either give up using USB or do what [Jason] did and block the data lines on the USB port.
USB typically uses four wires: two for power and two for data. If you simply disconnect the data lines, though, the peripheral can’t negotiate with the host for more power and will limp along at 0.5 watts. However, [Jason] discovered that this negotiation takes place at a much lower data rate than normal data transfer, and was able to put a type of filter in between the host and the peripheral. The filter allows the low-frequency data transfer pass through but when a high-frequency data transfer occurs the filter blocks the communication.
[Jason] now has a device that can allow his peripherals to charge at the increased rate without having to worry about untrusted USB ports (at an airport or coffee shop, for example). This simple device could stop things like BadUSB from doing their dirty work, although whether or not it could stop something this nasty is still up in the air.
There was a time when computers had parallel ports. For the hacker types, this meant an eight bit data port, and nine additional pins which could be interfaced with the real world via the 25 pin connector. This is no longer the case, although USB does help with suitable hardware. [Jabi] was working on a project that required controlling one relay to switch a strip of LED’s. His solution was to use a USB to Serial Adapter as an I/O device (Spanish, translated here).
He wrote a short C program, SioFus (Simple Input Output from USB2SERIAL), that converts a simple USB to Serial Port Adapter into an I/O device with 4 inputs and 2 outputs. It’s simple and gets the job done. The code uses ioctl and allows DCD, DSR, CTS and RI to act as inputs while DTR and RTS act as outputs. These pins then likely control transistors that switch the relays. The SioFus code is available on github and there are a couple of to-do’s on [Jabi]’s list if you would like to chip in.
The video after the break supposedly shows the hack in action. Seems like some kind of photo booth which then spits out a QR code, possibly a URL to the picture (post in the comments if you figure out what it does).
If you are looking for a more dedicated hardware, check out the Tiny Bit Dingus – a microcontroller stuffed into a USB plug with a few controllable pins.
Over the last decade or so, USB has somehow changed. It’s not just for connecting printers, keyboards, mice, and webcams any more. It’s not even just for stuff you would have plugged into a serial port. It’s a power outlet. If you want to charge your phone, plug it into a power outlet that can deliver up to 2.5 Watts. Unintended consequences, I guess. If you ever find yourself in 1995 again, go over to Intel and tell them to bump up the current limit.
Being a power outlet, having a device to measure current, voltage, power, and all the other intricacies of the what’s going on inside a USB cable would be neat. The USB Tester from Fried Circuits is that device.
The Fried Circuits USB tester isn’t so much a single device, but a small set of tools that allow you to probe everything going on inside a USB cable. In its simplest form, it’s just a board with a USB A connector at one end, a USB micro connector at the other, and breakouts for measuring current, voltage, the differential data signals, and that weird ID pin that’s useful if you’re working with USB chargers or OTG devices.
This breakout board also has two rows of five pins broken out. That’s for the USB Tester Backpack, which is really the heart of this device. This backpack features a microcontroller and a 128×64 resolution OLED display for current, voltage, and power monitoring, reading the voltage on the data lines, and graphing everything on the display. Everything you would ever want to know about a USB port – except for the actual bits being shoved through, of course – is right there on the display. Press the button on the side a few times, and whatever info you need will be presented in tall, very readable numbers.
The Entire Reason For Buying One
If you’re only going to use this to look at voltages, amps, and current flowing through a USB cable, you’re throwing your money away with this USB Tester. If simple, at-a-glance monitoring is what you need, you can hop on Amazon and get a USB current/voltage meter for $15. Even Adafruit has one for $7.50. If you only need to read the volts and amps for a USB device, your money is better spent elsewhere.
The Fried Circuits USB tester does something none of these other USB meters can do. It can log all the data to a computer over USB.
In my initial review of the USB Tester for the Hackaday Store, the only ‘official’ option for recording data from the Tester to a computer was a Java app. The developer of the USB Tester, [Will], chose Java because of the ‘write once, run anywhere’ Sun and Oracle have been shoving down our throats for the last 20 years. In theory, Java was an excellent choice for a datalogging solution for the USB Tester.
In practice, however, it just didn’t work. By [Will]’s own admission, it was the first thing he’s ever done in Java, and I think he set some of the options in NetBeans wrong. I could not get the data logging app to run on my Windows 8 box, or my OS X box, or my Linux boxxen. The only way I could run this app was by digging out an old XP box. Apparently, [Will]’s copy of NetBeans was configured for Java 5 or something.
[Will] knew about this problem, and last month he officially teamed up with [Edouard Lafargue] of wizkers.io. This is a platform for scientific instruments that runs in a Chrome App. The choice of running instrumentation in a Chrome app may seem odd, but this is apparently the new hotness; you can program an Arduino in a Chrome app, and there’s a lot of interesting stuff happening in this space.
The Wizkers.io app can do everything you would expect from a datalogging app. It will tell you the volts, amps, watts, mWh, and mAh of the device currently under test. There are pretty graphs, and everything can be downloaded to a computer for further analysis.
It might seem like cheating to review this device with a 3rd party app, but by [Will]’s own admission, there were problems with the Java-based logger, and the Chrome app works perfectly. There’s also the delicious irony that a Chrome app is more portable than one written in Java. I appreciate that.
Of course the USB Tester also outputs this data over a serial connection (in JSON format, too!). If you just want to connect this to a computer, solder up some wires to the TX and RX lines.
If you want a device that just tells you how many mA a USB device is sucking up, you don’t need this. You can buy something for less than $10 that will tell you that. If you’re developing some USB hardware, you’ll eventually want to characterize how much power your device is drawing and when it’s drawing that much power. This will require a data logging tool, and apart from cutting up a few USB cables and wiring it into an expensive power supply, you can’t do better than the Fried Circuits USB tester.
[Daniel] found himself with a need to connect a single USB device to two Linux servers. After searching around, he managed to find an inexpensive USB switch designed to do just that. He noticed that the product description mentioned nothing about Linux support, but he figured it couldn’t be that hard to make it work.
[Daniel] started by plugging the device into a Windows PC for testing. Windows detected the device and installed an HID driver automatically. The next step was to install the control software on the Windows system. This provided [Daniel] with a tray icon and a “switch” function. Clicking this button disconnected the HID device from the Windows PC and connected the actual USB device on the other side of the USB switch. The second computer would now have access to the HID device instead.
[Daniel] fired up a program called SnoopyPro. This software is used to inspect USB traffic. [Daniel] noticed that a single message repeated itself until he pressed the “switch” button. At that time, a final message was sent and the HID device disconnected.
Now it was time to get cracking on Linux. [Daniel] hooked up the switch to a Linux system and configured a udev rule to ensure that it always showed up as /dev/usbswitch. He then wrote a python script to write the captured data to the usbswitch device. It was that simple. The device switched over as expected. So much for having no Linux support!