A wire harness promoting proper dental hygiene.

I don’t pretend to be a master of wire lacing. To be honest this is my first attempt but I am thoroughly pleased with the results. I was inspired by a recent article by Keith Neufeld in which he showed off his x0xb0x Wiring Harnesses.

This is my latest arcade joystick build incorporating my recent teensy++ based controller. Locating resources on the web describing the art of wire harness lacing can be tricky as it doesn’t seem to be a popular practice but I found a decent writeup here. The wires on my controller are 24 gauge so the thick string Keith used would have been overkill. Instead I opted for waxed dental floss to wrap the wires (tip: waxed is important as it helps the knots stay tight).

Full harness

Teensy++ on a breakout board

It’s no secret the PS3 will work with most USB HID gamepads or joysticks. However the Home button is something special. If you connect your sixaxis controller to your PC and monitor button presses, the Home button comes up as button number 13. If you then create a standard gamepad with the same button mapping, the PS3 will refuse to recognize the Home button.

After some tracing of the USB traffic from an official Madcatz Street Fighter IV FightStick I was able to come up with a solution! There are 8 bytes transfered during the enumeration phase, just after the device sends it’s report descriptor. Mimicking the same exchange results in the Home button functioning correctly when button 13 is pressed.

I used the amazingly awesome Teensy++ development board after being inspired by this guys work. I also used the report descriptor from Toodles UPCB project which appears to come from the SEGA VIRTUA STICK. This descriptor is very similar to the one from the Madcatz controller, except their is one endpoint instead of two which simplifies things somewhat.

I also created a shield (pictured above) which brings several pins on the Teensy to convenient screw terminals.

Source code and Eagle files are available in a git repository. Code is licensed under the GPL v3 and the PCB design is distributed under a Creative Commons license Attribution-ShareAlike 2.5.

Terminal reference

This document can be printed onto transparency for exposing your pre-sensitized copper clad. To use this for toner transfer, be sure to mirror the image first.

And a compiled version of the code in ihex. This is for the teensy++ 2.0. The code might work with other versions of the teensy, but a re-compile will be required.

Gamepad Circuit Board

Export from EagleCAD with terminal labels

It’s based on another design by Raphaël Assénat.

You’ll find the source code and Eagle files here, both licensed under the GPL.

PS: It’ll also work just fine on a Window/Linux/Mac OS X computer as well since all operating systems come with drivers for USB HID gamepads.

OH NOOZ!!1!

I thought to myself, self: “certainly there must be some way to tame this beast?”. Wouldn’t you know it, there certainly is.

Start by plugging in your fancy pants USB device and running dmesg to get the kernel output for the event. It will look something like this:

input: Sony PLAYSTATION(R)3 Controller as /devices/pci0000:00/0000:00:04.1/usb2/2-4/2-4.2/2-4.2:1.0/input/input16
sony 0003:054C:0268.000F: input,hiddev0,hidraw3: USB HID v1.11 Joystick [Sony PLAYSTATION(R)3 Controller] on usb-0000:00:04.1-4.2/input0

The first line input: … is what we want. It contains the full device path and in this case we are interested in third last component of the path: 2-4.2:1.0.

Now run lsusb and locate the entry for your device.

Bus 002 Device 024: ID 054c:0268 Sony Corp. Batoh Device

Using the VendorID:ProductID pair from the output we can get verbose output from lsusb for just the device we are interested in and nothing else:

lsusb -vd 054c:0268

This is when we see that lsusb flat out refuses to show us the report descriptor. To get it, we need to unbind the device first (as root).

sudo bash -c "echo -n 2-4.2:1.0 >/sys/bus/usb/drivers/usbhid/unbind"

Now run lsusb again for the device and you should see the report descriptor in the output!

lsusb -vd 054c:0268

If you attempt to sign a .cod file larger than 64KB (ie: contains sibling files or child files or whatever files) then you will likely get a file created in your current working directory that looks something like kd8m34jkf/my_lame_app-1.cod. When you load the file to the device it will result in an error of some sort. The fix for this is relatively simple. Read on for the details.

Edit class file

Go back and read my other post for instructions on extracting the jar file and for packaging it up again. I’m going to leave out some details here since they are covered previously.

Note: this is based on the SignatureTool.jar file from JDE 4.7. I have not verified that this procedure is the same for other versions of the JDE.

We will use good old ClassEditor again. Open q.class and change string constant at index 253 from a back slash to a forward slash.

Edit string constant at index 253 in q.class

The simulator doesn’t sim and the signing tool doesn’t sign. These two issues cause a serious problem.

First the simulator. If you take an OS 4.3.1 simulator and a device also running OS 4.3.1 the two will behave very differently in a few subtle, but important ways. My gripe is localized to the mmapi api (handles audio/video playback). Long story short, the simulator can’t be trusted so we have to debug device/OS idiosyncrasies on the device itself.

But hold on a second. The signing servers aren’t working so I can’t debug on the device in all it’s developer friendly glory with lack of usable debugger and lack of even something as simple as a means to read text written to freaking standard output!

Thank you RIM! Thank you for wasting my valuable time. Thank you for reminding me that no amount of money can justify writing software for this platform any longer.

(10:30, signing servers still not working)

jQTemplate in action

Some time ago I started a little experiment to see what this whole “Web 2.0″ development thing was all about. The goal of the experiment was to develop a simple application without the help of any server side web framework, and instead use JSON as a data interchange format. All HTML, CSS, and JavaScript should be cleanly separated.

Cleanly separating the HTML from the JavaScript posed a challenge and thus jQTemplate was born. The concept is simple: write snippets of HTML code with annotations (in the form of special XML attributes) that can be used to transform the snippet into elements in the DOM.

The result I think is actually quite nice, and I love me some pretty code!

Assembled controller

This is mainly a show and tell post. What we have here is a NES controller that has been converted into a USB HID device. This means it can be connected to a computer without installing any drivers (Linux, Mac OS X, and Windows XP).

The circuit, PCB design, and firmware for the Atmega8 micro-controller are courtesy of Raphaël Assénat. His website is a veritable cornucopia of awesome circuitry. And the best part? All of his work is fully documented and provided for use under the GPL license where applicable.

Now the show part is over, time for the tell.

PCB Fabrication

First I would like to say I am no electrical engineer. I love building circuits and playing with micro-controllers but I have very little knowledge of the theory behind a circuit. That said, I learned a few things during this project that I would like to share.

The first lesson: surface mount PCB’s are painful! The actual soldering isn’t so bad. Search YouTube for surface mount soldering and you will get a ton of great instructional videos.

Isn't it cute!

The real issue for me was fabricating the PCB. I usually use the photo fabrication method but one of the tiny traces would get burned off every time. It’s poossible through some trial and error with expossure time I might have been able to get this to work but each failure is expensive! Pre-sensitized copper clad can cost up to $10 per sheet (aprox. 6×6 inches).

I ended up using the toner transfer method which I found tedious at best. I had to experiment several times over with different laser printers, print settings, iron temperature, iron pressure, and ironing time. Too many variables! That said, failures are cheep. If the artwork did not stick to the copper correctly, just clean the copper and try again.

Atmega8 Micro-controller

I actually built this circuit a few months ago. After assembling the circuit and connecting the ICSP programmer I successfully:

1. flashed the firmware
2. burned the fuses

Then I connected the USB cable to the computer but the device failed to register! I was so frustrated that after all of that work, I just stuck the project on the shelf and forgot about it.

Recently I was working with another Atmega8 based board when I realized my error. See, when you receive your AVR chip from the factory it is configured to use an internal oscilator. This internal osilator circuit tells the AVR what speed to run at (eg: 1 MHz).

The fuses are a set of bytes in the flash that determine how the chip operates. One of the fuse settings tell the chip to ignore the internal osilator circuit and look for an external one. The NES USB board is an example of a circuit that uses an external oscilator in the form of a crystal.

Beside the crystal are two capacitors and here is where I went wrong. These capacitors are 27pF on Raphaël’s circuit but I used a through hole crystal instead of the surface mount variety and these capacitor values are specific to the crystal! You can find the appropriate values in the crystals datasheet, in my case 18pF.

This explains why I was able to flash the firmware and the fuses. Once the fuses where flashed the AVR chip expected to have a working external oscilator but due to incorrect capacitors the external oscilator couldn’t function and neither could the chip. After replacing the capacitors the circuit sprang to life.

So in closing I hope this helps another noob like me out there.

1. Rapc compiler
2. Signature tool
3. Simulator
4. Javaloader

At the time of writing the first two worked fine. The third, Simulator, is if’y at best. And the fourth was just not possible.

Until now. In late December, a saviour by the name of Nicolas Vivien dropped by the barry mailing list to let everyone know that he was hard at work on reverse engineering the Javaloader USB protocol. Within a few weeks he had developed a proof of concept that enabled users to load cod files to the BlackBerry.

Since then several developers (including myself) have chipped in to implement all of the crucial aspects of the Javaloader needed for day-to-day use.

Which Commands are Supported?

• list modules on handheld, including siblings
• get handheld info
• load one or more cod files onto the handheld
• save one or more cod files from the handheld
• erase cod files from the handheld
• dump the eventlog
• clear the eventlog
• get screenshot of the handheld and save as bmp
• set time on the handheld
• wipe the applications and/or file system on the handheld

As you can see, most of the important stuff is already finished. And more is being added all the time.

I’ve Heard Enough… Gimme, Gimme, Gimme!

The Javaloader is slated to be included in the next release of Barry; version 0.15. If you would like to test it right now, you’ll need to compile from source or find a binary package for your OS/distro.

Here are some instructions for compiling from source. If you get stuck, someone on the mailing list might be able to lend a hand.

Hopefully this fixes the sporadic behavior people have reported with their LCD’s. It certainly fixes the problem with the two LCD’s I have tested.

I also added a schematic to the package. It just outlines where to connect VCC, GND and where to put the 10K pot.