Category Archives: DIY

Blog Move

This blog is in the process of moving in from it’s previous location at http://www.engr.uky.edu/~pseber0/ to it’s new home at pappp.net on bluehost. This current page will no doubt be repeatedly created and destroyed in the process, as I try to explain to the terrible migration tool about internal linking, resources, categories, and a variety of other things it is doing it’s best to lose or mangle. Things should be up and running in a couple of days, when the links will be updated, and the relocation notice will go up at the old location. This post also has a full set of categories, to force updates.

Posted in Announcements, Computers, DIY, Entertainment, FoodBlogging, General, Meta, Music, Navel Gazing, Objects, OldBlog, School | Leave a comment

Pionier Button Hacking: Step 2

It took over a year for me to get back to it, but I finally sat down and made some progress on hacking the Buttons Pionier was giving away at SC09.

When I last posted about it, I had drawn out all the USB identification information, as well as disassembled one, identified all the hardware components, and tracked down data sheets for the important bits.

Now that I have a Bus Pirate, I decided to dump the 24c64 EEPROM. A 24c64-type EEPROM speaks standard I2C, with the addition of three dedicated address pins (for banking chips), and a hardware write protect pin.

My first attempt was a little troublesome, because attaching the chip in-place was (as is often the case) powering the whole board, leaving two I2C bus masters, and confusing the situation.

The following is basically a reference for communicating with 24c32/64 EEPROMs.

To remedy the problem, I simply desoldered the 24c64 from one of the buttons, soldered pins 1-4 (one full side) to a bit of wire, so I could ground GND, A2, A1 and A0 with a single clip, and attached the bus pirate leads to the floating chip (Yes, SOIC8 packages are rather small):

24c64dump_sm.jpg

To be specific the connections are GND to pins 1-4 (Gnd, A2, A1, A0) 3.3V to Vcc (8) and WP(7), CLK to SCL (6), and MOSI to SDA (5) like so:

24c6pins_sm.png

To write the ROM, the WP pin would need to be grounded instead of powered, but preventing writes is a good safety measure when exploring.

Software-side, I ended up following the communication instructions in the Bookly 24c64 datasheet, because I found them asier to interpret, but the datasheets from Atmel or any other manufacturers that make a compatible part will do as well. Start with the usual bus pirate setup of ‘m’ for menu, ‘4′ for I2C, Chose a clock (I used 100kHz for fear of interference from the long-for-I2c leads), ‘P’ to turn on pull-up resistors, and ‘W’ to turn on the power supplies.

Then, to read out a 24C64, you feed it (this is a commented log of the terminal session)

I2C>[0xA0 -- Start, Send 1010, the Values on the A2-A0 pins (000 if grounded), Followed by 0 write for and 1 for read -- dummy write to set address pointer
I2C START BIT
WRITE: 0xA0 ACK
I2C>0x00 -- Send the start address to the chip, the 24c64 ignores first three bits. 0x0000 to start at the beginning of the ROM.
WRITE: 0x00 ACK
I2C>0x00
WRITE: 0x00 ACK
I2C>[0xA1 -- Starts, then random read (same as first byte of dummy write, with R/W high instead of low)
I2C START BIT
WRITE: 0xA1 ACK
I2C>r:255 -- Sequential read out the whole ROM (Overflows most terminal's history, I pulled 256 or 512 at a time.)
READ: 0x5A  ACK 0xA5  ACK...

I dumped it twice to cross-check that I didn’t make any dumb mistakes the first time, then massaged the dump with some regexes to get rid of the communication details and extract a pure hex dump. Only the first 4608 bytes of the ROM are written, so there is even room to tamper, if I can figure out the encoding. Note that the posted string is NOT S-records or Intel HEX, but raw ASCII-encoded two-characters-per-byte hex. In order to get it into an 8051 disassembler for further analysis, I will either need to figure out how to coax the Bus Pirate to generate a formatted dump, or write a script to segment and prefix the existing string, but neither has happened yet.

Giving analysis a first pass, I looked for pieces of the string it prints when activated as ASCII and raw USB HID Scancodes, but didn’t find them… which either means there is a problem with the dump (byte order?), or some clever and inconvenient encoding was used. I’m not terribly familiar with 8051s and their associated tools, so that will be the rather large next step. If nothing turns up in analyzing the dump, I may have to sniff the bus while the board is in operation to see if there is some funky data layout obfuscation.

Posted in Computers, DIY, Electronics, Objects, OldBlog | Tagged , , | 1 Comment

Pacman Brownies!

I’ve had the idea of icing classic video games onto brownies rattling around in the expanse between my ears for a while. I haven’t tried to pipe ice anything in quite some time, and it never has come out terribly well, but it’s fun tedium damn it…
I made a measurement mistake somewhere, so it compressed toward the bottom, and I forgot some flanges on the edging, but for a roll of parchment paper, a tub of white icing, and a pack of food dye, it worked out pretty well. I suspect in two or three tries I could make it look good instead of merely fun.
pacmanbrownies_sm.jpg

Posted in DIY, Entertainment, FoodBlogging, General, OldBlog | Leave a comment

Spiffchorder rides again

I’ve been putting a couple hours every evening into the long, long list of hobby projects that haven’t been touched for the last 10 or so weeks. One of the successes on this front is getting to touch the Spiffchorder I was working on.

I had to pull the reusable parts (always socket your uC…) and trash the one I assembled on perfboard; after all the modifications and false starts it was a non-functioning mass of solder balls and lifted pads. I then threw one down on a breadboard, as other had reported sucess starting that way even though breadboarding something with a 12Mhz clock is a little bit electrically dubious.
bbspiff_sm.jpg
I got this version working on the second try, and second only because the version of the code I modified to work with a (generally drop-in compatible and easier to source) ATMega 328p, instead of the 168 or 8 recommended by the original design is still not working properly. I suspect it is more of the issues with V-USB interrupt behavior on -p type chips, but haven’t attached it to anything that can trace fast enough to watch USB. That said, the code works fine on the one 168 I have in the parts bin (I think it was stolen from an updated arduino diecimila?), and the crappy first-pass keyboard I made for testing is… good enough to feel out the chords on, but not much else. The chord-set is actually pretty easy to work with, and I can see how it would be a comfortable (particularly in terms of “not further accelerating the joint damage to my hands”), convenient and fast input system.
spiffuse1_sm.jpg
Now to build a working board, a better keyer/keyboard[s], and fix the 328p code so I’m not tying up my only 168.

Posted in Computers, DIY, General, OldBlog | 3 Comments

Bus Pirate!

I lost yesterday evening to the happy distraction that usually follows a little red box showing up in the mail – The Bus Pirate and cables I ordered from Sparkfun with my Free Day winnings arrived.
It is a very cool little tool, and the accessories all work nicely – with the slight caveat that the Sparkfun cable is the reverse of the seedlabs/adafruit layout. There is a handy guide, but there are references to the colors in the firmware which don’t match… neither layout has any intrinsic advantage, although I do like that the Sparkfun model has GND on the black conductor. The test hooks I got with it have EXCELLENT grabby little tips, and are small enough to attach to adjacent pins of an SOIC, but do have an occasional problem with the jacket/part you press to extend the tip sliding back too far. That said, they are overall better than the ones on the expensive old logic analyzers on campus, so no complaints.

As for set up, the BusPirate just presents itself as a 115200/8/n/1 USB serial device, with a simple textual interface, so it will work on any machine with a USB port and serial terminal software (I like gtkterm on Linux and PuTTY on Windows). The developers offer regular firmware upgrades, and the SparkFun model ships with woefully out of date firmware and bootloader, to the point that the upgrade process is now mildly nontrivial (follow the instructions carefully). I did end up booting a machine into Windows for the update because the python update script was being problematic, and I wasn’t especially keen on bricking brand new hardware, but I got up to the current v4.3 bootloader and 5.10 firmware without too much fuss.

For a quick test, I grabbed my wiimote nunchuck and connected it up to the BusPirate. Wii accessories just speak slightly-obfuscated I2C among themselves, and there is a handy example for the process of reading one with a bus pirate. That whole process only took maybe half an hour, including plenty of time to explore the bus pirate’s features. The only slight hangup was that the BusPirates’ pullup line needs to be EXTERNALLY connected to a power source, even though the resistors can be software enabled. It would be nice to be able to connect (jumper block style) it to the on-board Vregs without extra loops in the wire harness.

wiimote_i2c_sm.jpg

One of the first things I want to do with it is tinker with the PIONIER Button that I have lying around from a conference giveaway a few years ago. The hold-up on that little project was getting access to the 24c64-type EEPROM which (presumably) holds at least the written string it writes, and probably the code it runs. I’m hoping for obvious “string preceded by length in bytes” type encoding. The 24c64 speaks two wire serial (which *usually* means not-quite-compliant I2C) with some external address lines, and the address lines are pre-grounded on the board, so at least reading the thing out shouldn’t be too hard, even if I may have to lift pins to separate it from the uC and enable writes…

Posted in Computers, DIY, General, Objects, OldBlog | 1 Comment

EE281 Car: Mixed Success.

281car.jpg
This week we did the lab the parts in my New Teaching Robots post were for, and it was very much a “mixed success” sort of situation. I put a test chassis and circuit together about a week and a half ago, and modified the sample solution from the crappy old cars to work with the new ones, and that was reasonably successful, although it did exhibit a little bit of sluggishness and jitter, which, in retrospect, I should have taken as a warning sign.

Last week we had a build party to put the chassis together, so that interested students in the class, as well as other people interested in robotics, could come play with the parts (and perform the repetitious part of assembling a small fleet of identical machines). That event was quite successful, resulted in a collection of 6 mostly complete chassis, and a lot of enthusiasm. I even had one student build a circuit to ensure that would be reasonable, and that went well.
281car_bottom.jpg

For the lab, we told students upfront that it was an experimental new lab they were participating in the design of, rather than something routine they were simply expected to perform. This was a good call, as it immensely with investment in the activity, and to reduce frustration when things didn’t work as planned for reasons outside of their control.
There turned out to be three basic problems with my design for the lab:
– In our enthusiasm for the new cars, both the faculty instructor for the course and I forgot that the protoboard power supplies usually used in this lab don’t tolerate the >1.5A spikes from driving substantial inductive loads well. This was a major compounding factor, and the most likely cause for the sluggishness I observed in the test case. This was fixed for the last section (there are nice 4-channel 5A variable output supplies in the lab), which helped alleviate some of the flaky behavior.
– I seriously overestimated the fabrication skills of most of the students. They haven’t developed what I consider “natural” design practices as far as physical layout or EMC, so constructing physically and electronically robust circuits on the small section of breadboard attached to the backs of the chassis was out of reach for many of them. I was very hands on with each group once the problem became clear, and had the latter two sections build some parts of the circuit off-board with suggestions, but it was still an issue.

281car_cable.jpg
6+ feet of Cat5 cable (twisted pairs) carrying ~5V signals switching at various speeds in the 0-100kHz range are one hell of an electromagnetic echo chamber, and I didn’t adequately account for that in the design. I’m still not sure how much of the strange behavior this can be blamed for, but there were sufficient effects to require substantially different passive components depending on which end of the cable which section of the circuit was built.

The latter two problems could have been alleviated, and the first one discovered much earlier, if we had stuck with the original plan to have PCBs milled and pre-assembled for all the discrete components, with fixed cables for attaching the FPGA boards the state machines were designed on. Hopefully at some point in the not-too-distant future there will be a chance to get that done for next semester.

Despite the problems, all the students were engaged, and a lot of them stayed and played with their design even after we told them they had done enough to be counted as completing the lab. In terms of educational outcome, we lost the excitement of making something which can move around reliably on its own (except for several groups who set up simple wired feedback from the sensor to the FET while they finished their sate machines…), but in explaining the various ways in which things went wrong, gained brief, simple, practical exposure to concerns in drive systems, emc, fabrication, and at least half a dozen other topics they will be taking courses in over the next two years. Most importantly it exposed students to some of the process of engineering whole systems, which is something one rarely gets until working on one’s own projects. I do wish it had gone as smoothly as the adder lab I replaced with a comparison of different adder designs (in Verilog) last semester, to introduce size/speed performance metrics, procedural test-benches, and the RTL/Tech schematics generated by ISE, while still teaching the basic lesson in binary arithmetic, but things did go surprisingly well for the level of unforeseen technical difficulties.

I feel almost as bad about spewing the above stream of awful loaded-meaning education jargon as the shortcomings of my plan, but there is no language I’m aware of for discussing the education process that hasn’t been co-opted by idiots.

Posted in DIY, Objects, OldBlog, School | Leave a comment

New Teaching Robots

281botparts_sm.jpg
Some days, I really love my job. That is the mechanical parts for 8 little teaching robot chassis I quickly designed, which will be used for, among other things, a late-in-the-semester EE281 lab where students develop their own line-following state machine and PWM motor control. Nice little Tamiya modular platforms with infrared reflectivity sensors to replace of the horrible, flaky, ten year old toy trucks with de-soldering braid brush sensors that are currently used. I will be recruiting folks (preferably undergrads with an interest in robotics) to assemble sometime next week after the rest of the parts get in.

Posted in DIY, Objects, OldBlog, School | 1 Comment

Spiffchorder Progress

As I mentioned when the parts arrived, I recently decided I wanted to build myself a Spiffchorder to play with, and, more generally, play with the VUSB Stack, which provides software USB for most AVR microcontrollers, using a few cents worth of extra passive components. This seems to be an excellent generic solution to the “Modern computers don’t have hobby-accessible I/O” problem for most applications. I’ve actually been using a VUSB device for a while since my usbtiny AVR programmer is an ATTiny2313 running VUSB with some additional support chips and code.

When I ordered parts, Newark was out of suitably-packaged ATMega168 chips, and their larger (RAM/ROM), pin-compatible sibling the ATMega328p was so close in cost I would have ordered them anyway. There is a warning(#8) about -p suffix chips (stands for PicoPower, meaning some additional power staving features) and VUSB, but it seems to be a simple problem with naming conventions in the interrupt vectors, and is fixed in recent versions.
I’ve been grabbing an hour here and there to put it together over the last week. So far, I’ve already spent some time on one of my favorite activities…
spiffwork_sm.jpg
which produced a nice tight board (The back isn’t quite as neat, and the socket I ended up using suuccckkkks)
spiffboard_sm.jpg
which, as far as I’ve discovered, had only one assembly error (the pull-up network on D- was between ground and… ground because I counted wrong), which was easily remedied.
While I was assembling I also put together a half-assed first approximation keyboard to test with
spiffkeys_sm.jpg
Which will eventually be upgraded… I’m thinking something flexible that can be clipped to the outside of my left pants pocket, or flopped on a flat surface such that the clip maintains the curvature, but I really just want to play with it and see how (un?)comfortable it is to use a chording keyboard. Maybe I’ll get bored and build a key-glove, those always look fun (and useless).

Now for the real problems… even after I fixed the wiring glitch, and touched up the code (minor fixes to make it recognize the 328p and set the fuses correctly), I wasn’t getting anything when plugged into USB. I borrowed a 168 from another project (and transparently swapped in a 328p there) to test the vanilla code, and it resulted in a board that generates a stream of errors like

usb 2-1.1.3: new low speed USB device using ehci_hcd and address 15
usb 2-1.1.3: device descriptor read/64, error -32

when plugged into any of my various Linux boxes. I then decided to upgrade the VUSB version (the one the 0.98 release is built against is truly ancient), which only took a few minutes of tampering to set up the usbconfig.h (and Makefile) to work with the Spiffchorder sources and IDs. Unfortunately, this only fixed the 328p problem… it now does exactly the same thing as the vanilla 168 version, and produces a string of USB enumeration errors when plugged in.

My understanding is that -32 errors are usually something to do with devices that aren’t correctly handled by ECHI (USB2) mode controllers, but a device that requires you disable ehci mode on a modern computer is pretty much useless, and it doesn’t appear VUSB should have that limitation. This is my current working tree, it seems to be at least as sound as the distributed version; when I get it working I’ll ping the original author about the update, and replace these if it turns out to be a software problem. I’m going to hook it up to some instrumentation on campus tomorrow to see if I can find the problem, I suspect something screwy with the voltages on the USB Data lines.

Posted in Computers, DIY, Entertainment, General, Objects, OldBlog | 1 Comment

SC’09 Video

I did a taped group-promotion and demonstration of the MOG Maze at Supercomputing last year, but we were never able to actually find the video posted online. I was doing an unrelated identity-management search while working on Ph.D. applications, and … here it is at techinsight.tv, with somewhat illogical search terms. Embedded below.

*obligatory listening-to-recording-of-own-voice cringe*

Posted in Announcements, Computers, DIY, General, OldBlog, School | Leave a comment

The best kind of box

newarkbox_sm.jpg
is the kind full of TOYS (or, well, toy parts).

This order has some bits and bobs (optoisolators, limit switches, etc.) for the never-ending milling machine project, a couple spiffchorders worth of parts (more on that later), and some spare ATMega328s, because they seem to be a universal solution to “medium” microcontrollers.

This is the first time I’ve made a personal order through Newark, their “We won’t tell you exactly how much this will cost to ship until you’ve agreed to pay” policy is more than a little customer-unfriendly for small orders, and their website is the furthest thing from user friendly… I AM an electrical engineer, and picking what I want there is a challenge. I made a couple mistakes in this order: I grabbed 15.24 mm (as opposed to 7.62 mm) 28pin DIP sockets (just not reading), and apparently not all 12×12mm MCDTS2 switches can accept the caps described as “Switch Cap; For Use With:12×12mm MCDTS2 Series of Multicomp Tactile Switches; ” because the ones I ordered sure as hell don’t have attachment points for the covers like the picture in the datasheet.

Otherwise, very satisfied. Low price, massive selection, and fast ship. I think I’ll add them to the list. For the curious, my parts usually come from DigiKey, Sparkfun, and AllTronics, which are broad, easy, and cheap respectively, although other vendors don’t have the cachet of the little red Sparkfun boxes.

Posted in DIY, Entertainment, General, OldBlog | Tagged | 1 Comment