Hi guys, I've just finished testing my fully assembled (i.e. intended-to-be-permanent) LPFK-to-USB cable. It uses an FTDI TTL-232R USB-to-RS232/TTL converter, a MAX232 level translator, five 0.1uF 0805-size surface-mount ceramic capacitors, a BC547 transistor (well, actually the SMD variant, the BC857), a 4k7 0805 SMD resistor, an 8-pin Mini-DIN plug... and a plastic Maxim/Dallas Semiconductor antistatic box. I did end up using a bit of copper tape and superglue as well (to hold the 4k7 and BC857 on the body of the MAX232)... First problem: if the connector is assembled as recommended by the manufacturer, it's too big to fit in the LPFK's rather small connector port. The solution to this is simple -- ditch the thick (2mm on my connector) rubberised outer cover and use heatshrink instead. As long as you're quick, the plastic inner support won't melt, but assembly is pretty much one-way. It's not easy to assemble, fairly easy to cut apart again, but $DEITY help you when you need to put it back together again. Six wires to desolder, *then* you can put the heatshrink back on. Thankfully properly-soldered mini-DIN connectors are usually quite reliable... Next problem is that the LPFK speaks 12V RS232, while the TTL-232R uses TTL-form inverted RS232. Another easy solution -- put a MAX232 between the LPFK and the TTL-232R to bump the levels. I also added a transistor and a 4k7 resistor to toggle the LPFK's reset line from the serial port's RTS output. That means that when the PC is idle, the LPFK is held in reset, and when the port is open the LPFK is released from reset. Advantage being that if you manage to crash the LPFK, you just need to toggle RTS and wait a few seconds for the LPFK to restart. It does tend to blink a few times when the USB drivers pick up the cable, but only on Windows. Maybe it's the software for my mobile phone trying to pick up a serial cable (despite the fact my phone connects over USB.. natch). I couldn't find any small plastic cases in my junk box, so I used an empty Maxim/Dallas antistatic plastic box. As in, the little clear plastic boxes that hold the parts they send out as free samples. These are small, relatively tough (though a bit thin) and ideal for small projects. Speaking frankly, I'd much rather have unclipped a ferrite EMI bead from a USB cable and used that, but the only ones I could find were moulded onto the cable. Shame, they were a perfect fit. Lastly, I had to reprogram the TTL-232's descriptor table so it claimed the full 500mA of current from the PC. Unplugging the cable from the LPFK will allow the TTL-232 (and MAX232) to start up and enumerate, then you can use FTDI's MProg tool to reprogram the power consumption descriptor (and the description strings too, if you like). Some USB chipsets / motherboards / etc. are more fussy about power consumption than others. 99.5% of the machines I've used seem to ignore the USB port's power consumption unless you short it out, in which case the machine tends to reboot in short order... I've also got an LPFK driver library that works with the USB cable, but should also work with a standard serial cable. You can grab the source code from <http://hg.philpem.me.uk/liblpfk/>, and it should work on any OS that supports POSIX serial communications (that would be Linux, OSX, the BSDs and most of the other Unices, and possibly QNX and Slowlaris - sorry, Solaris - as well). Porting to Win32 is left as an exercise to the reader. The library can do LED setting in both cached and uncached modes (translation: you can change one LED's state and have the LPFK update immediately, or change a dozen at the same time). Key processing is done with an lpfk_read() function that returns LPFK_E_NO_KEY if no keys have been pressed recently, or alternatively returns the first key code in the serial FIFO buffer. Thanks, -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/