Cubeternet 2MP UVC webcam teardown

August 25th, 2010
by Tim

For my pick and place project, I picked up a pair of too-good-to-be-true webcams: the Cubeternet no-name UVC webcam. For this project, there is a lot to like: 2MP resolution (claimed, at least), built-in LED ring, cross-platform UVC interface, hand-adjustable focus and a legitimate glass (no polycarbonate) lens…for $16! Alas, my review of this cam is currently mixed, since one of the cameras failed after being plugged in for more than a few minutes. This particular camera – the first I tested – became warm to the touch soon after plugging in; I assumed this was normal operation and that the cam’s solid metal “eyeball” enclosure was the heatsink for a voltage regulator screwed into it. Turns out this is not normal at all; the 2nd camera does not get even slightly warm after running overnight. Now, what to do with a broken webcam? Take it apart!

Teardown photos: In here

Opening the case reveals solid components, but an unfortunately typical “Chinese toy” construction with hand-bent and soldered leads everywhere, a couple stray solder balls and liberal application of hot glue (yes, really) to hold everything in place. If you’ve ever taken apart a cheap electronic toy for soundbending, you probably know what I’m talking about. Of the identifiable ICs, there are:

Controller:
Vimicro
0342PL
TS0340B
(Integrated USB2.0 UVC camera controller in 44-pin TQFP; its manufacturer denotes it as VC0342. This is driven by a 12MHz crystal oscillator.)

EEPROM:
Turbo IC, Inc.
TU24C64CSF
29830628
(64-Kbit I2C EEPROM in SOIC-8. Probably contains imager-specific register initialization values; possibly vendor-specific data such as USB ID and descriptors / vendor strings.)

Voltage regulator:
Kingbor 6206A
0947/33
(Ho-hum, 3.3V 3-terminal regulator.)

Imager:
Typical “big glass plate” CMOS image sensor, but actual manufacturer/part is anybody’s guess without a good microscope.

Misc:
There are six very bright LEDs hand-soldered into the board and bent into position; an electret microphone is also glued into the case. A handful of what appear to be discrete transistors/FETs deliver power to the LEDs and may serve a purpose switching/sequencing power to the imager.

In the images of the controller side, you can see a big solder blob dangling precariously off one of the FETs onto the PCB. While it’s not clear if this one was the culprit, this blob or one of a couple similar ones are the most likely cause of failure. Despite all this, the lens assembly is all glass as claimed, and seems to be of much higher quality relative to the rest of the guts. The minimum focus distance is well below 1 inch. On another bright side (no pun intended), the LEDs are bright as hell, adjustable via an analog thumbwheel on the USB cable, and holes in the four corners of the square board can allow easy attachment to the placement head. The untimely death of one of the cameras is certainly discouraging, and given the internals can’t be cleanly written off as a fluke. Still, even assuming a 50% failure rate, doubling up on these cams is still a good bit cheaper than the nearest name-brand equivalent.

Tags: , , ,
Posted in gEEk | Comments (0)

Image segmentation for PnP optical placement

July 27th, 2010
by Tim





Quick ‘n dirty (but working!) image segmenter for randomly-strewn part identification. About 1 page worth of scripting takes an image of objects on background, determines which part is the background, determines the outside contour of each object and numbers each as a separate object. Now that it’s known where to look for one specific object, the task of identifying that object (or just matching it to another just like it) becomes a whole lot simpler. Combined with the auto-aligner, this reduces a “naive” (bruteforce cross-correlation between needle and haystack images) image matcher to only having to scan against 4 orientations (90-degree rotations) to find which has Pin 1 in the right place (and whether it’s the same part, etc.) Hopefully as I dig deeper into opencv, there is a less-naive algorithm builtin for this that does not rely on contrast/color historgrams: most electronic parts basically consist of a flat black body and shiny reflective metal leads (i.e. appearing the same color as your light source and/or the background, and/or whatever happens to be nearby at the moment). Edge-based stuff still seems like a better approach, though I would welcome being proven wrong if it means not having to write the identifier from scratch myself :-)

Steps in brief:
The first image was taken using the actual webcam that will be attached to the pick n place head, looking at a handful of representative parts on a piece of white paper. This image was dumbly processed using a Sobel edge-detector (it’s builtin to Gimp and I was feeling lazy), Gaussian blur to expand the soon-to-be-resulting mask around the part a little and close any gaps in the edge-detection result, and finally threshold the result to produce the second image. The goal in these steps is to produce a closed-form contour blob for each part that’s at least as wide as the part, while minimizing stray blobs from random noise / dirt specs / etc. (internal, fully-enclosed blobs/noise due to part features/markings is OK). Finally, opencv’s FindContours function is run (mode=CV_RETR_EXTERNAL) on the resulting image, returning a vector that contains a polygonal approximation of each external contour found. Each discrete (non-touching) contour blob is returned separately, that is, every part in the frame is now effectively tagged and numbered!

There are a couple noise points identified in the image above. Better-chosen constants for the initial image operations (threshold, blur radius, …) may help, but I’ll probably end up having it measure the area of the blobs and throw away any that’s too small to possibly contain a valid part. Switching to a more advanced edge-detector, e.g. Canny, may help too. In any case, the full image matcher should figure it out eventually :-)

Code Demo – basically ripped straight from the pyopencv examples
Segmentation example – requires Python (2.6) and opencv 2.1.0 / pyopencv.

Tags:
Posted in General, gEEk | Comments (3)

Pick ‘n Place Head

July 26th, 2010
by Tim

This weekend I got some parts in and put together a preliminary placement head for my open-source pick ‘n place project. My requirements are that it be buildable with off-the-shelf parts (ideally same-source, to save on shipping) and no special equipment, allow +/-180 degree rotation while maintaining an undisturbed vacuum, and support interchanging of the “tools” (vacuum needles). All that’s really needed to build this are the discrete parts shown, a bit of drillable plastic (e.g. Delrin) for the base material, and a drill. A drill press would be handy (a CNC mill *really* handy, and not such an out-there thing to have considering you are probably retrofitting this onto one).

This head consists of a hollow rotary shaft with a Luer lock fitting on one end, right-angle flexible tubing barb on the other end, and a large toothbelt (notched belt, timing belt) gear in between. The shaft is held in place but allowed to rotate by a pair of bearings, and the rotation is provided by a small stepper motor at the other end of the toothbelt. The gear ratio is approximately 5.2:1, providing a rotational resolution of about 0.35 degrees/step with a common 200 step/rev stepper motor (if no microstepping is used). Finally, just to the left of it is a 1024×768 Webcam with manually adjustable focus and a ring of built-in LEDs for lighting. The webcam mounting is definitely not ideal, given the camera’s weird eyeball-like shape. Tentative plan is to lash it down with some string, align it nicely with respect to the CNC table, then backfill the opening the camera’s butt sits in with epoxy.

The hardest part was finding a combination of parts that would all fit together nicely. Currently, the fits are mostly exact to “pretty damn good”, but a bit of adhesive is needed to join them permanently.

Parts List
Unless otherwise noted, all of these parts were sourced from Small Parts Inc. in the US due to the large selection and an actually competent parametric search engine, which was a great help in finding combinations of mutually-fittable parts. Accordingly, measures are in Imperial unless noted otherwise (that’s just how they come here).

Partnumber Desc.
3002DSTNTG18 Nice Ball Bearing 3002DS, .250″ bore x .6875″ OD x .250″ width
BFM-250-P Mounted sleeve bearing, .250″ ID, 1 17/32 center-to-center bolt spacing
B00137SITY Steel tubing, 1/4″ OD .152 ID, 12″ long
40DP-14/S-01 Timing Belt Pulley Delrin, 0.0816 Pitch, 40DP, .350″ Diameter, 1/8″ Bore, For up to 1/4″ Wide Belt, 14 teeth
40DP-70/S-01 Timing Belt Pulley Delrin, 0.0816 Pitch, 40DP, 1.806″ Diameter, 1/4″ Bore, For up to 1/4″ Wide Belt, 70 teeth
TB188-090-01 Timing Belt Urethane/Polyester, Single-Sided, 0.0816″ Pitch, 0.1875″ Wide x 7.3440″ Long, 90 Teeth
LCX-LC005 Male Luer Lock to tubing adapter, .145″ OD hose barb (mates well enough with .152″ ID steel tubing)
F1-EL001 Elbow Connector , Classic Barbs for 3/32″ ID Tubing, .145″ OD
HSTA-08-24-10 1.5″ aluminum standoffs, 8-32 thread
B00137UP68 (Optional) 11ga Steel Tubing, .120″OD, .094″ID (for mating 2mm shaft stepper motors, if used, to the 1/8″ pulley

Misc. Parts
2x 2″ x 4.5″, 1/4″ thick pieces of Delrin or similar
4x 1/2″, #4-40 bolts and nuts (assuming 2 bolts for stepper motor)
4x 1/2″, #8-32 bolts for standoffs
1x Webcam, manual focus, hi-res and builtin lighting strongly recommended
1x 3mm shaft stepper motor*
1x Method of attaching to your mill – a bit of aluminum angle bracket, or a dovetail, etc., depending on your mill.

* The timing pulleys and stepper motors only come in a handful of diameters (imperial for the pulleys and usually metric for the small motors), so a 3mm (.118″) motor onto a .125″ ID pulley was the closest I could come up with in a reasonable amount of effort. Any small, el-cheapo permanent magnet (“tin can”) stepper motor should work here, but sourcing it may be annoying. Off-the-shelf 3mm-shaft motors I found are Jameco’s ValuePro 42BY48H08, Anaheim Automation’s TSM42 series, and Portescap’s 42/44 series e.g. 42×048 and 42S100. This surplus stepper is also worth a look, but you’ll have to remove a pre-attached plastic(?) gearhead. Beware, many of these smaller motors are 7.5deg/step, so even with the gear reduction, you will probably want to look at microstepping them to ensure adequate rotational resolution. Also, most of the companies selling them have no online click-and-buy ordering; you’ll have to phone up a salesdouche at the least, hope that you are worth their time to buy One Lousy Motor, and possibly haggle (“Request a Quote”). How companies that don’t know what their product costs stay in business is beyond me, but that’s a rant for another day.

If you want to skip that hassle, I’ve taken an alternative approach and simply bodged a surplus 2mm-shaft motor up to a 3mm shaft by gluing a short piece of thicker steel tubing onto the existing shaft (see partlist).

Design Files
CamBam drawings with machining operations for the top and bottom plates. The machining ops assume 1/4″ thick plastic, 1/8″ endmill for most cuts, and .166″ (#19) drill for the #8-32 bolt holes into the standoffs. It’s designed for the Cubeternet webcam (or equivalent eyeball-cam) and a stepper motor with 42mm center-to-center mounting holes. You can get the free CamBam at http://www.cambam.co.uk/.

Note, I made some small improvements to these files after the above prototype was carved, so what you see in the file will not match it exactly. In particular, the standoffs were moved to more optimal places and a feature has been added allowing the motor to be slid to remove any slack in the belt.

Assembly
The assembly should be pretty obvious. One bearing on each of the Delrin plates (inset the ball bearing if you can; otherwise gluing it down should be fine). The hollow shaft goes thru the bearings, Luer adapter and hose barb go on either end (use adhesive, just don’t clog the air path with it). The motor shaft center should sit just a hair (50-100 mils?) over 1.75″ from the hollow shaft. On mine, an online calculator produced the 1.75 figure, but the belt turned out to be a bit loose once built this way. If possible, make an elongated hole for one of the motor screws so the motor position can be adjusted to tension the belt. You could probably also insert a peg somewhere in the belt path to push it inward and take up the slack. With the camera focus set such that the largest part you will ever populate can fit in-frame, find the resulting camera height (distance from part) and set the depth of the shaft so that the camera is “in focus” maybe an inch or two above the placement position (i.e. with the needle touching the board). This will allow the head to focus on parts without touching the needle down.

Suggested “v2″ improvements
–Move air valve (if/when one is specified) onto head to minimize air volume between valve and head. Needed? (may be beneficial for reversed aquarium pumps or other weak vacuum sources)
–Bump detect: rather than firmly adhere the shaft into the bearing, allow it to float up and down, normally resting by gravity with the large pulley against the ball bearing. Place a contact switch just above the pulley: if the head/part contacts the surface with more than minimal force (enough to lift the shaft), contact switch is triggered. This could be used to halt the machine if a bump was not expected. If the switch’s trigger position is reliable enough, it could be used intentionally to automatically determine component heights.
–Probe function: There is a conductive metal path from the needlepoint all the way up to and including the bearing outer race, so it would be easy to touch a contact here and use the needle to probe for any conductive objects (e.g. find the tabletop if it is metal, or some capacitive shenanigans for PCBs/etc.). Useful?

Tags:
Posted in General, gEEk | Comments (2)

Toward an open-source Pick and Place machine

June 2nd, 2010
by Tim

So, there’s some really cool, empowering stuff going down these days with regard to manufacturing. Cartesian machines (i.e. CNC mills) are relatively simple to build from off-the-shelf parts; there are a bajillion people doing this and plenty of ready-made open-source designs available. More recently, hobbyists have gotten in on designing open-source rapid prototypers (3D printers); as a result, designs have now crossed the sub-$1000 threshold off-the-shelf, and you can even build a GPL’ed 3D printer that can almost replicate itself!

One thing that I haven’t seen cross the blood-brain barrier of proprietary commercial systems is pick-and-place machines that can assemble electronics. These things are badass; full of automated win and articulating robotic arms, but they’re also damned expensive: the crap ones start at >$10k and use literally a fishing-lure-and-weight type arrangement to peel back the tape covering tape-and-reel parts, so you have to keep resetting the weights. Those with more advanced / less manual feeders scale skyward from there. And of course, the software end of these things, especially machine vision algorithms to place parts more accurately, is some serious $ecret $auce. So… let’s change this!

Most of the “big stuff” is straightforward: The PCB layout software generates a list of coordinates for each part. A small vacuum needle mounted on a Cartesian head picks up each part from a known location, rotates it 90/180/etc. degrees as needed, and sets it down at its coordinates. It does not even need to be 100% accurate: surface tension of the solder during reflow will pull most minorly misaligned parts back into place.

The big barriers are:

1) Low cost / self-manufacturable feed mechanisms:
Electronic parts are packaged in several different ways, most commonly tape-and-reel, plastic tubes, or in trays. Each has a different, maybe cumbersome, way of knowing the location of the next part in the package and freeing the part from the package. Picking up stuff and putting it down is easy compared to dealing with the wide variety of tape and tube sizes reliably. Oh, and if your board uses 50 unique parts, you need 50 feeders. Hence the emphasis on making them cheap and mass-self-produceable, e.g. by CNC or casting or 3D printing.

and/or…

2) Machine Vision
For larger parts, once the first part is successfully picked (e.g. by human intervention), it is enough to know how many parts per inch of tape, advance the tape a known amount per pick, then just grab blindly for the part and plant it at its destination coordinates. But for smaller and finer parts, this is not accurate enough: the parts can be slightly off-center or crooked in their tape wells, and this becomes significant as the part size decreases. Professional machines use a set of cameras and image processing algorithms to recognize the part, find its dead center and correct any rotational error. In theory, a suitably good vision system would allow you to peel back the tape and just sprinkle the parts on the table, forgoing feed mechanisms entirely at the expense of some small manual labor. Actually programming this algorithm on the other hand…

Another nice thing to have would be:

3) Automatic needle swapping. Many more advanced CNC mills are able to spit out their current tool, e.g. a specific size drill bit (in a known location in a tool rack) and pick up a different tool. It would be nice for the pick and place machine to be able to change to smaller and larger needles/suction cups to handle large and small parts seamlessly. If not, placements can be sorted, e.g. smallest to largest, so that the needle only has to be manually changed a couple times.

I’ve made some very initial feasibility-study stabs at building such a machine, and begun building a bit of hardware. I created a separate page for this project with more detailed specs/documentation and progress so far:
Pick and Place Project

Tags:
Posted in General, gEEk | Comments (5)

I quit, I win, final, no talkbalks

May 24th, 2010
by Tim

It’s like third grade all over again, except that I could theoretically have ice cream for breakfast if I wanted to.

Tags:
Posted in General | Comments (0)

Windows 2000/XP Driver for (some) Veo Stingray and IBM PC Camera V5000 webcams

March 2nd, 2010
by Tim

UPDATE: For Veo Stingray drivers, try these first. In case they disappear… Stingray 300V (Win98/ME/2000/XP) and Stingray 323V (Win2k/XP only). The one sold by AllElectronics uses the 323V driver.

I picked up an old “Veo Stingray” camera from surplus dealer AllElectronics. These things are pretty junk by modern standards (320×240 resolution, unsightly rounded “looking through a tube” image), but it does have the variable (manual) focus I needed for an imaging project, and the price was right. As for drivers… the company that makes this thing seems to have evaporated, and the particular variant (USB product ID 808B) seems to have never been heard of by anyone, even though there are some identical cameras with slightly different internal hardware (and different Product ID) floating around. They all are (were?) manufactured by Xirlink.

This particular variant can be identifed by USB VID 0545 (Xirlink), Product ID 808B.

Here is a solution that might work (but see update above first): This camera and several IBM PC Cameras use the same or similar chipsets (Sunplus SPCA5xx)…with a small tweak, the IBM camera driver can also be tricked into supporting the ‘808B’ Stingray (maybe others?) by adding its VID/PID to the driver .INF file. Kinda like slipping your cuckoo egg into another nest.

This file includes the IBM driver and tweaked .INF. The following devices are supported:

%XIRLINK.DeviceDesc%=Xirlink.Device,USB\VID_0545&PID_8002
%XIRLINK.DeviceDesc%=Xirlink.Device,USB\VID_0545&PID_8080
%XIRLINK.DeviceDesc%=Xirlink.Device,USB\VID_0545&PID_8009
%XIRLINK.DeviceDesc%=Xirlink.Device,USB\VID_0545&PID_808B

To install, follow the README.TXT included.

Win2K/XP Driver for Veo Stingray (808B) and IBM V5000

Linux?
It looks like several open-source driver projects may support the Veo Stingray, IBM PC Cameras and similar SPCA50xx variants (not to mention the classic Dakota Digitals). Note, if your exact ID is not listed as supported, you may be able to get it working with a tweak similar to the above. Have a look at:

http://xirlinkwebcam.sourceforge.net/
http://www.linux-usb.org/ibmcam/ (older project)
In addition, the package ‘gspca’ may work for these and many other SPCAxxx-based (and other!) webcams. See here for the gspca/spca5xx project and a list of supported cameras.

Tags: , , , , , ,
Posted in General | Comments (1)

Tubthumping (or, Sears/Kenmore washers are shit, do not buy them)

January 11th, 2010
by Tim

So there we are, minding our own business, when an angry demon springs to life in the basement. He is on a rampage, pounding against the walls with all his might, THUMP THUMP THUMP THUMP BANG BANG BANG. We race downstairs. Turns out it is only the Sears Kenmore front-loading washing machine’s internals beating themselves to death during the final spin.

After ruling out an unbalanced load (even fully empty, BOOM BOOM BOOM), I lookup the symptoms online. After a few thousand pages of angry ex-customers’ rants, without even lifting a wrench, there is no doubt what the failure is.

All available evidence confirms that this machine is DESIGNED TO FAIL EVERY FIVE YEARS*. The fuse is an innocent-looking metal bracket on the back of the spinning clothes basket known as a spider; its purpose is to support the basket on the drive shaft leading back to the motor. This spider, an uncoated pot-metal part made of a brittle Al+Fe alloy, is fully exposed to and tumbles its way through all the detergent, bleach, dirty laundry water, etc. After a few short years of this, it corrodes through and shatters during the spin cycle! Of course, you can’t buy just this part; you have to plunk down for the entire basket/etc. assembly at $200 a pop**. Guess who now has a nice spare stainless steel basket laying around to turn compost in, heh.

My brief description does not do this problem justice, but there is an excellent video from a former Kenmore owner detailing this spider issue and several other, likely intentional, design flaws.

So, you probably guessed what I did next – took it apart. The insides of the plastic wash tub are a bitch to get at (nondestructively); the whole thing has to be carefully unhooked from a pair of shocks and large springs, liberated from half a dozen hard-to-reach hoses and tubes with fiddly retaining clips, and the glued-on rubber seal cut away from the front of the machine. There are also cinderblock weights (yes, really!) on the tub which ought to be removed unless Hulk Hogan is helping you lift it out. On mine, the bearing surfaces were also so rusted, it took beating the living hell out of the shaft with a big hammer to separate the assembly from the tub.

Here is what I found inside:



One rotted, broken-ass spider. Surprised? Also note all the "used to be spider" white crud packed in beneath the bearing.


One rusted-out shaft for a rotted, broken ass-spider.


One reaction vessel washtub for a rotted, broken-ass spider. Yuck, my clothes were in there? The white crap looking like crushed concrete at the bottom is corroded bits of spider that haven’t yet ground away at the pump impeller while making their way to the city’s sewer. You can also see where the grease has begun leaking out from the cheap rubber lip seal that’s supposed to be keeping water out of the bearings.


One rusted-out hole for a rusted-out driveshaft to grind slide into. "That’s not my mating surface, baby!"

All this because Sears/Kenmore*** could have easily solved this with $1 worth of engine paint (etc.) to coat this fiddly metal bracket, but chose not to. Also, like in the video above, my outer tub has a nice deep gouge line where the screws in the wildly-flailing basket tore it up. Luckily we were home when it went, and our catlike reflexes caught it before they could carve all the way through.

*says everyone on the Internets. Don’t McLibel me.

** and if you want to save the hassle of retaining clips patwanging across your basement and the Hulk sneaking looks up your skirt, and have the new part installed by an authorized repairman… there’s a reason they have those commercials with the repairman playing Solitaire all day because no support calls come in… it really is cheaper to buy a new machine. ($75 diagnostic visit + $450-$700 repair quotes vs. $500-600 for current units.)

***technically, Sears/Kenmore just buy the appliances from other OEMs and put their names on them. This particular model (417.42142100) is made by Electrolux; others are rebadged Frigidaire or Whirlpool units. Unfortunately, all seem to share a similar design, right down to the fail timer.

Tags: , , , , , , , ,
Posted in General | Comments (4)

No, she cannot has cheezburger. Laser pointer, yes!

December 20th, 2009
by Tim

We got a kitty last weekend. Like many new additions of the human kind, we hadn’t really planned on it*, but now we are in love with her. Her name is Spirit (she comes pre-named).

She had no trouble settling into the new house, except for spooking out at the noise from the radiators at first. She’s such a little attention whore – follows the hyoominz all around, and if we are on the couch, sits down next to someone and headbutts them ’til she gets belleh rubs.

So far she has also discovered that Christmas tree ornaments swing and make a tinkling noise when swatted at, knitting needles move and click while in use, and must therefore be attacked, and – OMG WIIMOTE CURSOR!

http://www.youtube.com/watch?v=pr2UmofoYAE

http://www.youtube.com/watch?v=dFuf_wMFs1E

*Somewhere between “rescue mission” and “interstate feline trafficking” does the truth lie.

Posted in General | Comments (0)

Banned from Google (or, How I Became A Dirty Rotten Spammer)

October 10th, 2009
by Tim

So, as of sometime within the last few weeks or so, I am a convicted Google Spammer! As you may guess from this tone, I have not actually done or considered any such thing. But as tends to happen when you take all humans out of the loop and put all faith in the smartness of an infallible Algorithm, you throw your fair share of babies out with the bathwater, and today, one of those babies is me. I discovered this (not like I would have gotten an email or anything) when I happened to Google the name of my product to get to its mainpage (much faster than typing the full URL, which is longish), and it wasn’t there. With some further digging, I found my entire domain and all subdomains have been blacklisted from Google’s index.

That particular level of digging leads to a tool called Google Webmaster Tools, which, after proving myself the owner of the site, returns this:

This site may be in violation of Google’s quality guidelines. More Details
Pages on your site may not appear in Google search results pages due to violations of the Google webmaster guidelines. Please review our webmaster guidelines and modify your site so that it meets those guidelines. Once your site meets our guidelines, you can request reconsideration and we’ll evaluate your site.
Submit a reconsideration request

Full stop.

These webmaster guidelines cover “quality” (i.e. don’t spam the index)–including such helpful first-grade spam no-nos as not stuffing pages with invisible keywords, bogus META tags, providing special fake pages to known search bots, and other stuff that might have worked on Lycos in 1996–as well as various style-guide suggestions, admonishing webmasters to be on their best grammar, and even going as far as discussing size and placement of images on the page. Is a webmaster really expected to perform feng shui to stay in Google’s good graces?

Anyway, I’m at quite a loss to explain why I would be banned from Google, as getting an entire high-ranking site removed from a search index seems like something that would require some pretty big-ticket shenanigans. Of course, this is The Algorithm we’re talking about; there seems to be no indication that a live human was involved in this decision*.

Of course, any of the usual SEO tricks would fit the bill. But I don’t engage in any of that (for here, the boards or the main site), and the only “optimization” I do to this blog’s traffic is to post something interesting once in a while. (Really, since everything on this server is ad-less and free anyway, the only thing More Traffic can get me is a bigger bandwidth bill.) I do know that Google will display warnings / block content if it detects a site has been compromised, but a thorough dig through the server-side files indicates this is not the case, either.

So what’s left are some straws to grasp at:

  • Legitimate incoming links from adult-ish sites and adult-ish search queries for my side project
  • “Bad Words” or links appearing in message board posts (forget this piddly blog, what the rest of the free world knows cexx.org for is one of the oldest continuously running spyware help forums in existence. Posts here–especially diagnostic logfiles posted by affected users– contain references to bad programs/sites, links to same, and repetitive content (e.g. Windows registry trees) that occasionally generate false positives. A human would easily see that we are helping people rather than spamming the world; The Algorithm may not do as well.)
  • Occasional comment spams slipping through in UGC (“User-generated content”, the current buzzword for “stuff the site owners didn’t write themselves”, such as blog comments, message board posts, every video on Youtube, etc.) As you can see from the numbers showing at the bottom of this page, comment spam is as fundamental to the Internet as the threat of rickroll, and the filter’s doing pretty well at blocking them. If transient v1@gra comment spams were grounds for being delisted, half the internet wouldn’t show up. Then again, for those of us who have not used Lycos et al lately, how would we google-addicts know if half the internet wasn’t showing up in our searches…?)
  • My content being scraped and appearing on third-party spamblogs (yes, it happens. I–of all people!– have fired off a couple DMCA takedown demands in the last couple years, but really, for splogs on splog-friendly Korean ISPs this has about as much effect as firing off complaints for every email spam your receive. These automated scrapers usually end up scraping from someone with deeper pockets and much better arm-twisting power at some point, and the problem (for lil old me) solves itself.)
  • Old pages/posts, dead links, occasional bad grammer or speling mistakes?
  • Maybe Google are still mad at me for exposing a huge bug in their search some years ago? (In theory, this would make it trivial for someone to determine whether they ranked higher than a competitor, or see how a specific tweak to their keywords/etc. affected their ranking. But since I’m pretty sure no humans were actually involved in this, I kinda have to rule this hypothesis out…)
  • Statistically anomalous distribution in keyword content of sites that link to mine?
  • Statistically anomalous distribution of topics I discuss, tag clouds, etc. (or as mentioned earlier, help forum posts)
  • Someone I’ve pissed off in the past robo-submitting my URL to the automated “report a spammer” page?**
  • Googlebombs or other shenanigans performed (maliciously or not) by third-party sites?
  • Wild Conspiracy Theories (paid off by a malware company? Malware authors have been trying to block their victims from being able to reach help forums such as cexx.org’s for years; maybe the’ve found a way to up the ante. Or maybe Sergey bought my Trance Vibrator and didn’t like it.)

The possibility that any site could be delisted by the actions of third-party sites (e.g. competitors) is simply disturbing. As unlikely as I’d hope it to be, Google’s complete secrecy regarding its delisting criteria (even I, after proving myself the legal owner, can’t get boo about what’s going on with my own site) makes such a scenario impossible to rule out. For what it’s worth, Google does explicitly mention links to “bad neighborhoods” in this Guidelines page, and some sites by and for the SEO people (who presumably know their stuff, this being their entire business model) seem to think this does apply to incoming links as well.
That is unacceptable.

If I haven’t gotten to the bottom of it soon, my only choice might just be to block Google from the site outright (why pay for the bandwidth their crawler uses if we are being excluded from the results?) and personally wean myself from Google search, for whatever that is worth as a personal stance. Is my best alternative really “Bing, and it’s done“?? Google, you really put me between a rock and a hard place.

* nor, based on analysis of the server logs, the “Reconsideration request” you can submit via the Webmaster tools thingy. Unless there are human reviewers lurking in an underground bunker somewhere disguised as residential cable customers from Peoria, or a vast distributed network of speed-readers who are each assigned one line to read, the speed of the hit-streams identifiable as coming from Google during the time of said review easily beat my personal best, and, much like the MTV Music Awards, show no evidence of human intelligence.

** From said page: “If you believe that another site is abusing Google’s quality guidelines, please report that site at https://www.google.com/webmasters/tools/spamreport. Google prefers developing scalable and automated solutions to problems, so we attempt to minimize hand-to-hand spam fighting. The spam reports we receive are used to create scalable algorithms that recognize and block future spam attempts.” Great, The Algorithm is now in charge of deciding who the humans on the Web are.

Tags: , , ,
Posted in General | Comments (1)

My quickie guide for setting up mspgcc for ez430-cc2500

August 23rd, 2009
by Tim

Mostly for my own reference for the next time I have to set it up on a new machine, but may help others on their first time install. Valid as of Feb. or so this year.

Software ’shopping’ list (all free/OSS tools)
Set up the toolchain (mspgcc). There seem to be several important tools
missing from the mspgcc distro as of this writing, including ‘make’ and
msp430-insight (graphical debugger) that the docs claim are included
with the package. So the complete shopping list is:

mspgcc-win32:
http://downloads.sourceforge.net/mspgcc/mspgcc-20081230.exe?use_mirror=voxel
NOTE: This binary IIRC was not linked on Sourceforge’s downloads page at the time; there was only an older build and this link had to be fished from semi-private newsgroup postings. If there is a newer binary available, download that one.

MinGW/msys (provides ‘make’ and some utilities) :
http://downloads.sourceforge.net/mingw/MinGW-5.1.4.exe?use_mirror=voxel
If it gives you the options of installing minGW and msys, say YES to both.

CoreUtils (provides unix-like ‘rm’ tool required by make) :
http://gnuwin32.sourceforge.net/packages/coreutils.htm

Skipping the debugger for now until I figure out how to use it myself ;-) Seems to work occasionally under win32, but it’s flaky.

Required Knowledge Assuming you already know C and have the appropriate chip documentation/datasheets.
Have a quick read-through of the mspgcc FAQ and manual. Both are
reasonably short for what they are.
FAQ: http://mspgcc.sourceforge.net/faq/t2.html
Manual: http://mspgcc.sourceforge.net/manual/

The manual contains a lot of advanced stuff you can skip at first, or
skip entirely. This includes (at minimum) the stuff about customizing
the startup/end procedures, stack, the entire ABI section, inline
assembly, and stuff about building mspgcc (the package you get is
already built).

Get familiar with ‘make’. Outside of kinky application-specific tools
like the Microchip assembler/compiler and ‘IAR Kickstart’, the rest of
the free world uses make to automate compiling, linking,
installing/running and packaging their code. Go into the mspgcc
‘examples’ folder and find the blinking LEDs example (e.g.
E:\mspgcc\examples\leds). Open up the file called Makefile in Wordpad
and have a look inside. This is the master script that will smartly
handle all your compiling, programming the chip, and avoid you rewriting
lots of code whenever you change chips. The contents will probably look
like gibberish, there are only a few parts that are important for our
purposes. The make tool installed by mingw32 is named ‘mingw32-make’.

How make works is you specify one or more ‘targets’, i.e. things make
can do. Running make with no target specified compiles your program.
Some other targets are ‘mingw32-make clean’ (delete your old build and
any scratch files), or ‘mingw32-make download’ (compiles your program,
downloads it to the chip and runs it). All the necessary commands to
handle each target are in the Makefile.

Since the top half of the ez430 kit is essentially the USB Sy-Bi-Wire programmer, you have to change the download command to:

msp430-jtag –spy-bi-wire -lpt=USBFET -e leds.elf

I.e. in the Makefile you’d find and change the download section to:

download-jtag: all
msp430-jtag –spy-bi-wire -lpt=USBFET -e ${NAME}.elf

As long as you have the Makefile open, now is a good time to find the
CPU= line and change it to match the msp430 variant you are actually
using. In the case of the eZ430 board:
CPU = msp430×2274

Now when you #include the base generic as you will for most any
mspgcc project, it will automatically switch in the correct headers and
peripheral support for that specific CPU.

Posted in General | Comments (6)

DIY-Spy: a homebrew 2.4GHz wi-fi spectrum analyzer

August 17th, 2009
by Tim

I was reading the Thinkgeek catalog a while back and an interesting gadget caught my eye: “Wi-Spy”, a 2.4GHz spectrum analyzer on a USB stick. Coming from the world where “spectrum analyzer” refers to a big benchtop box with a name like Le Croyright, we can’t afford those Agilent on it, my first thought was, “A good spectrum analyzer in the GHz range is like a gazillion bucks; what’s really inside this thing?”

Not much, it turns out. After seeing the guts I would not use this device for anything remotely demanding accuracy, but on the bright side, it would be pretty straightforward to make your own that works just as well! Possibly with parts that are already on your board (*cough*XBee).

According to this review and a couple other tech sites, the innards of the original are nothing more than a Cypress WirelessUSB SoC (CYWUSB6934) and USB interface. According to this updated review, the latest version switches to TI/Chipcon’s CC2500 radio ($2.15 USD in quantity) and retails for $399.

The “WirelessUSB” and CC2500 radios are inexpensive 2.4GHz radio chips used in devices such as cordless mice, game controllers and remote controls. What it has in common with many other digital radios is an RSSI (Received Signal Strength Indication) register, which can be read out to provide a measure of how much signal (i.e. interference) is present on any given channel. Wireless gadgets normally use such a mechanism to find the cleanest channel to broadcast on. Most any radio chip with an RSSI readout should work here: XBee, TI/Chipcon’s CC25xx parts, Nordic, etc. I have a big nut going right now for Nordic’s nRF24L01, but unfortunately this does not have an RSSI measurement to speak of (there is a 1-bit “collision detect” flag that warns if the RF energy on the current channel is above a set threshold).

So essentially, the firmware running on the dongle consists of:

for (channel=0; channel<255; channel++)
{
WriteReg(RF_CHANNEL, channel);
signal=ReadReg(RSSI);
send_usb(signal);
}

Hell, why didn’t I think of selling $2 of chip and 4 lines of code for $400? ;-) (I’ve even used those old Cypress radios before on a work project – Unigen’s ready-made JUNO module shown here is about 7 bucks.)

The DIY-Spy

As proof of concept (and a cool toy for anyone who has one of these lying around), I have implemented a working Wi-Fi spectrum analyzer on TI’s ez430-RF2500 development kit ($50), a 2-part USB dongle which consists essentially of a CC2500 radio strapped to an MSP430 low-power microcontroller (detachable bottom half) and a USB interface which enumerates as a virtual serial port (top half). The top half doubles as a standalone MSP430 programmer, so this kit is a great cheap way to get started playing with them.

Being the lazy efficient person that I am, I grabbed mspgcc and an existing ez430 RF demo program (JM Kikori’s RF2500 test application – raw transceiver) and just tossed the infinite RSSI loop into the middle of it.

Here is the main addition (simple & sweet). Forgive Wordpress’ complete mangling of the formatting.


static void dump_rssi()
{
int i;
char rssi;
for(i=0; i<256; i++)
{
hal_spi_radio_writeReg( MRFI_CC2500_SPI_REG_CHANNR, i); // Channel number. Default spacing is ~200KHz/channel
hal_spi_radio_cmdStrobe( 0x34 ); // enter Rx mode (not needed except to start autocal)
rssi = (hal_spi_radio_readReg(MRFI_CC2500_SPI_REG_RSSI));
uart0_polled_putc((rssi&0xFE) | (i==0)); // Cheap speed hack: write upper 7 bits of RSSI value (throw away LSB). Use LSB to signal start of 256-channel RSSI byte list
hal_spi_radio_cmdStrobe( 0x36 ); // enter IDLE mode (not needed except for autocal)
}
}

The only real divergence of this from the pseudocode loop above is that the CC2500 requires periodic (or frequent, depending who you ask) recalibration, which can be set to be performed automatically on certain conditions (such as entering Rx mode). This setting is enabled, and the code above toggles between Rx and Idle modes between each channel change to trigger auto-calibration. To make things faster (for me as well as the gadget ;-), rather than perform any kind of real serial handshaking to keep the dongle and the graphing script in sync, I just truncate the least significant bit of the RSSI reading (1/2dBm) and use it to flag the start of the 256-channel sweep.

A more efficient approach would be to perform such calibration once per channel and cache the results (writing them back along with each channel change), which would in theory allow for much faster channel changes. But it’s really a moot point since here the 9600-baud connection to the virtual COM port (MSP430 <–> USB controller) is the limiter of maximum speed.

Most of the time in this project went into tweaking around with the CC2500’s fifty billion or so configuration register bits, not all of which are really documented. In the end I just installed their win32 configuration wizard for the undocumented voodoo (e.g. correct IF setting) and annoying math, and hand-tweaked the remaining settings. For this I set the base frequency to 2400MHz, and the channel spacing to ~ 405KHz, providing the frequency range 2400MHz to 2505MHz across the 256 channel settings. This corresponds to the 2.4GHz ISM band and a little extra. All automatic gain control features are disabled.

Testing
I’ve actually been sitting on this project now for a couple months, since I wasn’t getting the results I expected initially (sitting close to my WiFi access point) and had no good way to test it. Luckily, as it turns out I was tasked with developing some RF gadgets (nRF24L01-based) at work, which could easily be set up to output a raw carrier wave at a programmable frequency. Sure enough, testing revealed some bugs in my initial CC2500 register settings, now corrected.

The video above shows the resulting spectrum output as the nRF’s naked carrier is swept through a handful of frequencies. As it progresses, it should also become evident where my WiFi access point is broadcasting. The green lines show instantaneous signal, the red shows the peak value at each frequency, and the blue shows a running average. The display script is written in Processing.

Downloads

Fairly undocumented; use at your own risk.
diyspy.zip – Source code and .elf binary for ez430 kit (use mspgcc to build from source), .inf file for virtual COM port (win32 only), and Processing script for display.

Posted in General | Comments (19)

Throwies overtake Kendall/MIT station sculpture

July 13th, 2009
by Tim

Blinking RGB LED throwies adorn the “Steaming Globe” sculpture near the Kendall/MIT station just after the 4th of July fireworks show. No idea how this could have happened.

Kids had a blast pulling them off and throwing them back onto the globe (and each other!). The whole rest of the night as we walked around, we saw blinking kids.



Posted in gEEk | Comments (0)

You are invited to participate in a research study. Afterward, there will be cake.

June 24th, 2009
by Tim

Heh… I’ve just completed NIH certification to administer human test protocols. I feel like that’s got to be worth a few mad scientist points.

So, I’m working on this project at work involving research into new forms of computer interface peripherals. (No, not that one.) As part of the project, we are required to test these interface concepts with live humans, survey them and see how well it works for them. The survey is positively harmless: basically like handing someone a shiny new cellphone set to vibrate, and programmed to vibrate in a different pattern depending who’s calling. Then run each pattern and see if the user can use it to successfully identify the caller. To make things simple, we had proposed to do these tests with our own employees (everyone pretty much said, “hell yeah, I’d like to play with that” when I described the project, and it sure as hell beats pulling in random strangers from the Craigslists to nose around in our secret lab).

Oh, for the catch: it’s a DARPA-funded project, and this required usability survey stuff constitutes Human Testing. To do any Human Testing, you need to draft a Human Test Protocol detailing exactly what you hope to get out of the research, intricate details of the exact test(s) that will be performed (down to the specific questions you will ask, and in what order) and the exact hardware involved in each test (note, this hardware hasn’t yet been designed by the time these forms/tests must be finalized…also remember that the entire point of these tests is to guide the design of said hardware, which now must be set in stone long before the test). So much for iterative development, that’s for sure. Add to that lengthy Informed Consent forms, confidentiality procedures, SOPs, HIPAA forms, risk assessments relative to daily activities (like, say, using your cell phone…), Conflict of Interest forms, Anti-Coercion Forms, and the whole shebang must be submitted to, and approved by, an IRB (Institutional Review Board), then the IRB’s approval approved by the governmental Office of Something Something Something. The package we submitted went up to Appendix V. (Not V as in roman numeral 5, V as in A thru… . I kid you not.). We each also had to take this lengthy “Protecting Human Research Participants” online course. Not that I’m not completely for protecting my human research participants, but come on – we’re asking them simple gadget usability questions, not giving them experimental drugs.

We got feedback from the IRB today, our protocol is NOT yet approved. They need more forms submitted and a bunch more specific details carved in stone.

I shouldn’t be complaining. Poor Jeff, my officemate, is handling the vast majority of this process in concert with a PhD consultant who is actually used to dealing with this crap. It just burns having to scramble around slapping together super-crude prototypes to test on-the-sneak to get even some rough semblance of how to structure the tests, not to mention the hardware, to get any kind of meaningful results (screwing the schedules on my other projects), how much of the project’s fixed budget will be swallowed up by this approval process instead of, say, actual R&D, and just how pointless the tests will be when it’s all said and done. Our money shot is 3 days’ worth of usability testing at the end of the program, predetermined at the start of the program.

Oh yeah, and letting your own staff participate instead of random losers from off the street? BIG MISTAKE. Far from simplifying the random Craigslist idiot, asking strangers medical screening questions, losers breaking our equipment, NDA, and losers selling our tech secrets to the Commies cans of worms, it actually hugely complicates things. Now you need to prove to the IRB, and the governmental IRB approval approvers, that employees’ participation in the research is indeed voluntary (not, “hey, participate in my research study or ur fired”), and all the steps you have taken to ensure that all participation is voluntary, that no one has the capability to bribe or coerce anyone into participating, that supervisors/bosses cannot determine who participated, etc.

Some notes, in case I EVER have to do this again:

Do Not promise, or get involved in a project where they will make you promise, human testing (no matter how harmless it seems) for any government project.

Do Not promise human testing -of anything- on a Phase I SBIR budget.

Do not write, review, modify or proofread human test protocols after playing Portal. Now the whole thing is in GLaDOS Voice. Likewise for the Big Red (supercolliding super-) Button that stops the test. (“The effects prolonged exposure to the e-stop are not a part of this test.”) I’m incredibly tempted to slip something into the protocol promising cake after the study, but then I’d probably have to get FDA approval too :-(

HIPAA stands for Highly Increased Paperwork and Annoyance Act.

(And yes, technically I *could* construct a test sequence in such a way as to make the prototype play music. But I haven’t gotten around to it yet choose not to. Yeah, that’s it.)

Tags: , , , ,
Posted in work | Comments (0)

Comcast, she’s at it again…

April 12th, 2009
by Tim

Just got the latest Comcast TOS patch with my bill (an adhesion contract officially titled, “Notice From Comcast Regarding Changes To Your Comcast Agreement For Residential Service” (try saying that three times fast)), stuffed inside of a cheerful note about their commitment to happy cheerful customers. What it actually entails is left intentionally vague, but it appears Comcast is trying to set itself up the legal ability to torpedo competitors’ VoIP equipment, and add/REMOVE functionality, via unauthorized firmware “upgrades” to customer-owned equipment. Sure, I would like to believe that they have my and other customers’ best intentions at heart, and just want to log in in the middle of the night and update our Linksys router firmware for us so that russian h4×0rz can’t store up to 256KB of kiddie porn in the flash ROM, but my experience is that contract-change stuffers are seldom in the customer’s interest.

Dan Kusnetzky at ZDNet got the new stuffer and also had concerns about the “downloads” and other rights asserted to open up and tinker with customer-owned equipment, including computers, voiding warranties as they go. While I agree with his guess that they probably just want to maintain their own equipment (e.g. Cable Cards) inside customer-owned cable boxes and TVs, there’s no reason to write such terms so overbroadly as to cover a wide spectrum of unauthorized, and potentially hazardous, modifications to customer-owned computers, access points, VoIP boxes and other equipment.

The actual stuffer is reproduced below. It’s lengthy! The important bits are in red, and my comments are in italics.

Customer Equipment.
Customer Equipment consists of software
or services that you elect to use in connection with the Services
or Comcast Equipment (the “Customer Equipment”). You agree
to allow us and our agents the rights to insert cable cards and
other hardware in the Customer Equipment, send software and/or
“downloads” to the Customer Equipment and install, configure,
maintain, inspect and upgrade the Customer Equipment
and
Comcast Equipment. You warrant that you are either the owner
of the Customer Equipment or that you have the authority to give
us access to the Customer Equipment. If you are not the owner
of the Customer Equipment, you are responsible for obtaining any
necessary approval from the owner to allow us and our agents
access to the Customer Equipment to perform the activities
specified above.

Comcast has no responsibility for the operation or support,
maintenance, or repair of any Customer Equipment including, but
not limited to, Customer Equipment to which Comcast or a third
party has sent software or “downloads.”
So, if Comcast bricks your expensive HDTV trying to perform a remote ‘upgrade’, boo hoo, better luck next TV. You acknowledge and
understand Comcast Digital Voice Service (“CDV”) may not
support or be compatible with non-recommended configurations
including but not limited to multimedia terminal adapters (“MTA”)
not currently certified by Comcast as compatible with CDV
;

Ah yes, now I remember Comcast’s stance on ‘Net Neutrality and the use of competing VoIP services on its network. A “Multimedia Terminal Adapter (MTA)” is the technical name for a VoIP box. I wonder why and how they are sending “downloads” to arbitrary third-party equipment? This might work as Apple’s ‘update’ for jailbroken iPhones.

Customer Equipment, including, but not limited to, non-voice
communications equipment, including certain makes or models
of alarm and security systems or devices, certain medical
monitoring devices, certain fax machines, and certain “dial-up”
modems; rotary-dial phone handsets, pulse-dial phone handsets,
and models of other voice-related communications equipment
such as private branch exchange (PBX) equipment, answering
machines, and traditional Caller ID units.

For Video and Comcast High-Speed Internet (“HSI”)
Customers. You agree that by using the Services, you are
enabling and authorizing Comcast, its authorized agents and
equipment manufacturers to send code updates to the
Comcast Equipment and Customer Equipment, including, but
not limited to
customer-owned cable modems and customer-owned digital interactive televisions
with CableCARDs, at any time
it is determined necessary to
do so as part of the Services. Such code updates may
change, add or remove features or functionality of any such
customer-owned equipment or the Services.

For HSI and CDV Customers. You can find Comcast’s current
minimum technical and other requirements for HSI
customers at http://www.comcast.com/Support/Corp1
/FAQ/Fag Detail2205.html and for CDV customers at
www.comcast.com/cdv/faqs. These requirements may be
located at an alternative site if we so notify you. To use CDV,
you will need a MTA that meets our specifications. In some
areas, we may permit you to use CDV with an MTA that you
have purchased. Depending on availability in your area, you
may have the option to install the MTA yourself or have
Comcast install it for you. You agree to keep the MTA plugged
into a working electrical power outlet at all times.

…and what if I don’t? Not that I expect them to do so (anymore than I expect to use “Comcast Digital Voice”), but this clause technically gives Comcast the power to terminate a customer’s account and levy damages against them for breach of contract if they inadvertently kick the plug out of the wall. (Or, for suitably perverse readings, have their power go out…)

Whether a
cable modem, gateway/router, MTA or other device is owned
by you or us, we have the right, but not the obligation, to
upgrade or change the firmware in these devices remotely or
on the Premises at any time
that we determine it necessary
or desirable in order to provide Services to you in accordance
with our specifications and requirements.

For CDV Customers. In order to use CDV, you are required
to provide certain equipment such as a phone handset or
equivalent, inside phone wiring and outlets, and an electrical
power outlet. If you live in an apartment or a similar multi-
tenant dwelling, you may have to provide a cordless phone
as well. If we do not have access to the inside phone wiring
in your home or if you are installing CDV yourself without the
assistance of a Comcast technician (“self-installation”) where
we make that option available, you will need to plug a
cordless phone into the MTA in order to use CDV throughout
your home. CERTAIN MAKES AND MODELS OF CORDLESS
PHONES USE THE ELECTRICAL POWER IN YOUR HOME. IF
THERE IS AN ELECTRICAL POWER OUTAGE, THE
CORDLESS PHONE WILL CEASE TO OPERATE DURING THE
OUTAGE, PREVENTING USE OF CDV VIA THE CORDLESS
PHONE. DO NOT ATTEMPT TO CONNECT CDV TO INSIDE
PHONE WIRING YOURSELF. In order to use online features
of CDV, where we”make those features available, you are
required to provide certain hardware, such as a personal
computer, software, an Internet browser, and access to
the Internet.

CUSTOMER EQUIPMENT – LIMITATION OF COMCAST’S
LIABILITY

CUSTOMER EQUIPMENT MAY BE DAMAGED
OR SUFFER SERVICE OUTAGES AS A RESULT OF THE
INSTALLATION, SELF-INSTALLATION, USE, INSPECTION,
MAINTENANCE, UPDATING, REPAIR, AND REMOVAL OF
COMCAST EQUIPMENT, CUSTOMER EQUIPMENT AND/OR
THE SERVICES
. Most probably, the “downloads”. Equipment failure due to botched or interrupted firmware updates is among the most common consumer electronics failure modes, and is in fact the very origin of the verb ‘to brick’. EXCEPT FOR GROSS NEGLIGENCE OR WILLFUL
MISCONDUCT, NEITHER COMCAST NOR ANY OF ITS
AFFILIATES, SUPPLIERS, EMPLOYEES, AGENTS, OR
CONTRACTORS SHALL HAVE ANY LIABILITY WHATSOEVER FOR
ANY DAMAGE, LOSS, OR DESTRUCTION TO THE CUSTOMER
EQUIPMENT
. IN THE EVENT OF GROSS NEGLIGENCE OR
WILLFUL MISCONDUCT BY COMCAST, ITS SUPPLIERS,
EMPLOYEES, AGENTS, OR CONTRACTORS, WE SHALL PAY FOR
THE REPAIR OR REPLACEMENT OF THE DAMAGED CUSTOMER
EQUIPMENT (AT OUR SOLE DISCRETION) UP TO A MAXIMUM
OF $500. THIS SHALL BE YOUR SOLE AND EXCLUSIVE REMEDY
RELATING TO SUCH ACTIVITY.
• For HSI and Video Customers. YOU UNDERSTAND THAT
YOUR COMPUTER OR OTHER DEVICES MAY NEED TO BE
OPENED, UPDATED, ACCESSED OR USED EITHER BY YOU
OR BY US OR OUR AGENTS, IN CONNECTION WITH THE
INSTALLATION, UPDATING OR REPAIR OF HSI OR VIDEO
SERVICES. THE OPENING, ACCESSING OR USE OF YOUR
COMPUTER, OTHER DEVICES USED IN CONNECTION WITH
YOUR COMPUTER, OR YOUR VIDEO DEVICES MAY VOID
WARRANTIES
PROVIDED BY THE COMPUTER OR OTHER
DEVICE MANUFACTURER OR OTHER PARTIES RELATING
TO THE COMPUTER’S OR DEVICE’S HARDWARE OR
SOFTWARE. NEITHER COMCAST NOR ANY OF ITS
AFFILIATES, SUPPLIERS, OR AGENTS, SHALL HAVE ANY
LIABILITY WHATSOEVER AS A RESULT OF THE VOIDING OF
ANY SUCH WARRANTIES.

Comcast Equipment. You agree that except for the wiring
installed inside the Premises (“Inside Wiring”), all Comcast
Equipment belongs to us or other third parties and will not be
deemed fixtures or in any way part of the Premises. Comcast
Equipment includes all software or “downloads” to Customer
Equipment
This makes determining legal ownership of the hardware, where Comcast-owned firmware is burned onto the customer-owned device, a legally sticky issue or Comcast Equipment and all new or reconditioned
equipment installed, provided or leased to you by us or our
agents, Including but not limited to, cabling or wiring and related
electronic devices, cable modems, MTA, wireless
gateway/routers, CableCARDs, and any other hardware. You agree
to use Comcast Equipment only for the Services pursuant to this
Agreement. We may remove or change the Comcast Equipment
at our discretion at any time the Services are active or following
the termination of your Servlce(s). You acknowledge that our
addition or removal of or change to the Comcast Equipment may
interrupt your Service. You agree to allow us access to the
Premises for these purposes. You may not sell, lease, abandon,
or give away the Comcast Equipment, or permit any other
provider of video, high speed data or telephone services to use
the Comcast Equipment. The Comcast Equipment may only be
used in the Premises. At your request, we may relocate the
Comcast Equipment In the Premises for an additional charge, at
a time agreeable to you and us. YOU UNDERSTAND AND
ACKNOWLEDGE THAT IF YOU ATTEMPT TO INSTALL OR USE
THE COMCAST EQUIPMENT OR SERVICES AT A LOCATION
OTHER THAN THE PREMISES, THE SERVICES MAY FAIL TO
FUNCTION OR MAY FUNCTION IMPROPERLY. You agree that you
will not allow anyone other than Comcast employees or agents
to service the Comcast Equipment. We suggest that the Comcast
Equipment In your possession be covered by your homeowners,
renters, or other insurance. You will be directly responsible for
loss, repair, replacement and other costs, damages, fees and
charges if you do not return the Comcast Equipment to us in an
undamaged condition.

Posted in Rants & Rambles | Comments (1)

Fun with MIDI, CNC and vector maths (mid2cnc.py)

April 3rd, 2009
by Tim

More playing:
Castlevania end credits
Tetris
Mario Bros. theme

Update: I fixed up the script to pull (usually) proper timing from the MIDI, threw together some minimal documentation and released it to the public (see link below).

Downloads
mid2cnc.py, sparse documentation and samples

Basically, it’s possible to compute a combination of (distance, feedrate) along an axis that will cause the stepper motor for that axis to spin at an exact frequency corresponding to a musical note. With a little vector magic, the same can be done for (x, y, z, feedrate) to produce chords as the machine follows a 3D line through space.

(For anyone wondering, the song is Jonathan Coulton’s Still Alive, better known as the end credits theme from Portal. The MIDI is from topazstorm.)

*whew* That was the easy part. The real magic will happen in a future post, if I ever get around to it :-) Hint: The fact that notes can and do swap arbitrarily among different axes (while still sounding passable) is important.

How This Works (for CNC-heads):

We have code G1 [pos]x F[feedrate] for linear interpolation at a specific feedrate. Thus need to convert between feedrate in IPM and frequency in Hz (steps per inch or inches per step). My machine as currently configured is 36000 steps/in, so if we wanted it to play middle A (440Hz) (440*60 = 26400 steps/min) we would want to move along a single axis at feedrate (26400/36000 = 0.7333..) IPM.
or more generally, (freq/600) IPM.

Here are the frequencies for one octave. The formula to convert semitones (notes) to their actual frequencies is

f = fRef*2^(x/12)

where fRef is an arbitrarily chosen reference frequency corresponding to a specific note, and x is the number of semitones difference between the note you want and the reference. Middle A (440Hz) is as good a reference note as any, and its MIDI note number is 69, so the formula to calculate frequency for any MIDI note number becomes:

f = 440*2^((x-69)/12)

; C4 = 261.63Hz
; D4 = 293.66
; E4 = 329.63
; F4 = 349.23
; G4 = 392.00
; A4 = 440.00
; B4 = 493.88
; C5 = 523.25

And the G-code with the resulting feedrates to play this scale on my machine:

G1 X1 F0.43605
G1 X2 F0.48943333333333333333333333333333
G1 X3 F0.54938333333333333333333333333333
G1 X4 F0.58205
G1 X5 F0.65333333333333333333333333333333
G1 X6 F0.73333333333333333333333333333333
G1 X7 F0.82313333333333333333333333333333
G1 X8 F0.87208333333333333333333333333333

; Unfortunately, our note duration is now frequency-dependent. If we wanted it to play for 1 minute, we should make the distance
; equal to the feedrate in IPM (or 1/60 of that to play for 1 second, etc.). Easy-peasy so far.

Now let’s complicate things a bit. Suppose we want to play 2 or 3 notes at once. G-code linear interpolation scheme is that in, say, an XYZ move, all the axes arrive at the same time. Feedrate is the speed the tool moves along this *vector*, not the speed of the fastest/arbitrary axis. In other words, you cannot specify individual feedrates for the (x,y,z) axis moves, only one for the resulting vector as a whole. So, since the vector that results from adding 2 ore more axis moves will always be longer than either of the individual axis moves (for the 2-axis case, think the hypotenuse of a right triangle) the feedrate we set will be faster than the highest note, and will depend on the individual notes and their contributions to that vector.

Assume the bog-standard C-E-G chord. To play each on its own for 1 second…

G1 X0.0072675 F0.43605 ; move this distance
G1 X0.0164238 F0.54938 ; move 0.009156333…
G1 X0.0273126 F0.65333 ; move 0.010888833…

…but we want to combine these into a single (x,y,z) vector at a single feedrate.
The vector is obviously (0,0,0 to .00726, .00915, .01088), and its length is given by sqrt(x^2 + y^2 + z^2). Remember we are playing all three notes for the same length of time. The vector has lengthened, but the desired playing time has not, so we need to choose the feedrate for this new distance that yields the same travel time.

Regardless of how the length or rate changes, the (x,y,z) components remain proportional to one another. Just pick one of the individual axes/notes as a reference, compare the final vector length to the length of the reference note and bump the feedrate proportionally to the change in length. In this case we arbitrarily select the highest note as the reference, and the ratio of the final feedrate (unknown) to the reference feedrate (known) should equal the ratio of the 3D vector length (known) to the reference length (known). It’s almost too easy!

3D Vector length: 0.015975658808286373765422932349422

Feedrate: (newlength/oldlength) * oldfeed

= 1.4671598699591015644580950363551 * 0.65333 = 0.9585395578403798251074072301019

G1 X0.0072675 Y0.009156333 Z0.010888833 F0.95853955

Just remember that *any* change of any note requires computing a fresh new vector, so long notes will have to be split up wherever another concurrent note changes.

Tags: , ,
Posted in gEEk | Comments (26)

(Also: An experiment…)

April 3rd, 2009
by Tim

In the last post, I made the unspeakable blargger mistake of linking to an article on a news site, which means in 7 days or so, instead of said article this link will return absolute crap and/or a “Buy membership now!” nag screen. Trying to keep up with such link rot (if anyone bothered) is a problem that grows linearly with the number of posts/articles written, until it reaches 100% of the blogger’s time and he/she/subject/verb has to stop writing any more posts and become a forest ranger. I’ve ranted this before with some possible solutions, but as you may have guessed based on my project completion record to date, didn’t get around to it (got maybe as far as writing a toy script that wget’s pages and stuffs the contents into a database record).

So a little experiment: Instead of linking to the article directly, I linked to a carefully-constructed “I’m Feeling Lucky” Google query containing unique phrases contained in the article. The idea is that as the site shuffles stuff around / deletes content / recycles numeric links, rather than a 404* the link should preferentially return a clean copy of the article from somewhere else on the Internet if it exists (syndicated copy, fulltext copy-paste into a blog/slashdot post somewhere, etc.).

Let’s see if it lasts any longer than a regular news-site link!

(For anyone interested, the actual query is:

http://www.google.com/search?q=%22A+company’s+backroom+mass+of+servers+and+switches+is+cloudlike.+So+are+social-networking+sites+like+Facebook+Inc.%2C+or+the+act+of+buying+a+book+on+Amazon.+Some+clouds%2C+like+Google’s+email%22&btnI=Lucky

The “%22″ at the beginning and end of the query string itself is the URL-safe encoding for a double-quotation mark (ASCII code 0×22), so that the quote marks in the query don’t conflict with the quote marks in the <a href=”…”> tag. To simulate a click of the “I’m Feeling Lucky” button, replace the button-type code that normally appears in the query (btnG=Search) with “btnI=Lucky”. Also note that apparently Google limits queries to a maximum of 32 words.)

* Modern commercial sites seldom, if ever, actually return a HTTP 404 code when a document is not found, since software including search-engine spiders detect these and drop 404′d pages from their listings. it’s far more profitable to pretend the user/bot has reached some kind of non-error document, swap in a generic landing page and stuff it full of keywords and advertising.

Tags: ,
Posted in gEEk | Comments (0)

Cloud Computing…cirrusly? (same trash, different bag)

April 3rd, 2009
by Tim

So, apparently I’m not the only one to notice the mid-level marketing types in IT having a big collective nut lately about “Cloud Computing”. This week even the Wall Street Journal ragged about this nonsense on the front page. For those who don’t spend their time around mid-level IT marketing types, cloud computing is… well, nobody who uses this term have actually agreed on a definition, but it can loosely be defined as “the processor and the data it processes are in different places”. I.e. Web apps, like Google Spreadsheet or some Myspace widget where you upload your AIM contact list and it returns some kind of graph of mutual acquaintences you’re all connected to. Search engines. X-Drive / Internet backups of your files. Stuff like that.

“Real Computer Is Elsewhere” has been around since computers; Cloud Computing is only the latest name for it. A little history: In the 1950s, any talk of electronic computers whatsoever assumed a ginormous shared, multi-user machine, since computers were far too new and expensive for everyone to have their** own. In fact, the entire concept of having the user, his data, and the computer in the same room at the same time came much later, when they became small and cheap enough to sit on a standard-sized desk and the term “personal computer” was born. Kind of like one of those little single-serving packets of Sweet ‘n Low, except it was a computer. Back in those days, sonny, you came down to the big mainframe room with a box of punched cards and submitted them to the white-jacketed mainframe acolyte, who (hope against hope) would run your job overnight and return your results in the morning. By the 60s and 70s, technology had advanced to teletypes and terminals (the infamous “glass titty”) – the computer itself was still in the basement of some university, but you could text into it from elsewhere and bask in the warm glow of an amber screen. Then computers started getting cheap enough that people who needed one could put the whole machine right in the same room with them, and from then on the idea of going back to dumb terminals and the big Elsewhere Machine seemed pretty silly.

But companies tried to bring Elsewhere Computing back, and still they do. In the 80s it was the diskless workstation (or as users called them, dickless workstations). People hated them. In the 90s they tried again under a new name, thin clients. Those who remembered the era of time-sharing on mainframes and the Diskless Workstation hated them because they knew it was a Diskless Workstation under a new name; everyone else hated them because they just didn’t work all that well. Now it’s the “todays”* and these guys are hoping this is the decade consumers will get back on board with using their computers as an expensive tool for borrowing time on someone else’s**. My guess is that once the Cloud Computing folks agree on what they’re selling, folks will soon enough figure out what this really means and we won’t have to hear all this hype anymore (it will go the way of “Multimedia”).

* what radio stations who played the greatest hits of the ’70s, ’80s and ’90s a decade ago play the greatest hits of, today. Only one more year until they will be forced to decide what to call this decade! The Zeros? The Aughts? The Double-Ohs? The suspense is killing me.

** the same decade where the concept of subject-verb agreement will go out the window as people try to terminate fractally-growing chains of awkwardness in sentences resulting from attempts to keep them gender-neutral.

Tags: , , ,
Posted in Rants & Rambles | Comments (3)

Optical Mouse Hacks: 2D Micropositioning using cheap mouse cameras

March 22nd, 2009
by Tim

Optical mice work by pointing a tiny cheap camera at the surface of your desktop, tracking the motion of ‘interesting’ points in the surface texture (woodgrain, imperfections, highlight/shadow) as the mouse slides around over it, and converting this to an X and Y motion. An LED is used to light the surface beneath the sensor, typically at a very low angle to help highlight any surface roughness (so the sensor still works on rough, but solid-colored, surfaces such as paper). Many of these sensors allow you to read out the raw image, too. Historically, the sensors in optical mice have been a standalone chip with SPI interface, leaving a separate microcontroller to handle button clicks and PS/2 or USB interface – so you could hack a cheap optical mouse to output position or image data for unique scanner or robotics projects. Unfortunately, more and more of these high-volume, low-cost devices are moving to all-in one camera+micro+USB chips under an epoxy blob, so you can’t just buy any old optical mouse and expect any access to this internal data.

Videos:
Absolute microposition sensing using image recognition
Relative position sensing (i.e. just like a mouse) using the DELTA_X/DELTA_Y registers
Downloads:
Arduino Library


Naked mouse cam and lens wired to a microcontroller

Fortunately, standalone SPI sensors are still alive and well. Mouser.com (no pun intended) sells some of these (Avago ADNS-2610 and ADNS-2620) for the exhorbitant price of $1.56 each. It’s a CAMERA for a buck fifty. Not exactly a *good* camera (grayscale, 18×18 resolution), but you can still do some neat tricks with it. Of course, you will still need a cheap optical mouse to steal the lens off of (or maybe an old CD player, etc.).

If you want to be all lame and boring, you could use this mouse camera as, well, a mouse. An onboard DSP is constantly watching the surface below as it slides by, giving you an up-to-date relative position (DELTA_X and DELTA_Y) just by reading a pair of registers. Each ‘delta’ reading contains the number of +/- pixels the mouse has moved in each direction since the last time you read it. Since you are only reading 2 registers, you can read this information at very high speed. There are some additional registers that will give you the max and min brightness, sum of all pixel values, and a ’surface quality’ value that represents the number of trackable points (divided by 2) under the imager.

But if you want to dig deeper, a builtin diagnostic feature lets you bang some other registers and return the entire image under the camera. A few things worth mentioning before you go further, though: this IS meant as a diagnostic feature only; they sell these things as mice and not cameras after all, and this feature is not the best implemented. There are 324 pixels (18×18 array), but you can only grab one pixel per frame. So when you get the image, you are actually seeing pixels composited together from 324 separate frames across maybe 1/2 second. If the camera is moving during this time, you’ll get a garbled image, so if you have this puppy strapped to a robot to take pictures (or position the robot), your robot has to stop for pictures. Also, your maximum full-image rate is only a couple images per second.

Following are some demos of monochrome and color image acquisition, surface identification and micro-position sensing down to the um range.

Circuit:
The ADNS-26xx parts only require a couple external components: an oscillator and a couple capacitors to stabilize its power supply and internal reference voltage. The oscillator frequency (about 20MHz-25MHz) is not critical; any cheap ceramic resonator will work fine here. So your complete parts list is:

1x ADNS-2620 mouse cam
1x 24MHz resonator (speed not critical)
1x 2.2uF capacitor
1x 0.1uF capacitor (optional but recommended power-supply bypass; value not critical)

Grabbing images:


The sensor’s great for reading that pesky fine print.

Above is a sample image taken from the sensor, looking at the little “Equal Housing Lender” glyph on some credit card junkmail. See below for some more. The process is straightforward; write once to the PIXEL_GRAB register to arm it, then read it 324 times (18*18) to read out the image bytes starting from the top left pixel. (Or use my Arduino library ;-)

And no, I’m certainly not the first to think of this. See here for a demonstration where someone combined the image and position readouts to use the mouse as a crude handheld scanner. I haven’t tried it, but I wonder how well this can see your fingerprints if the angle is right. (I assume not very well, otherwise mouse companies would have already enabled frame-grabbing on USB mice and tried to sell it as combination mouse and biometric ID thingy.)

Color imaging:
The grayscale sensor can be used as a crude color imager by replacing the standard red lighting with an RGB LED, and taking one frame with each color lit in turn. Depending on the LED, you may have to scale the R/G/B frame data differently for more accurate color representation. I assume like most photodiode technology the mouse cam pixels are most sensitive to the red-IR range, but the LED I used had a pretty weak red, so it was kind of a wash. (The image here is scaled red=0.75, green=1, blue=0.75).

2D position finding using the “Christopher Carter Algorithm”:
Very simple position-finding routine I wrote for testing purposes; named after a magician’s trick where the blindfolded practicioner (renowned hypnotist Christopher Carter, in the first case I saw it) “reads” a name written on a dry-erase board by swiping a finger across it at a few different heights. This is a similar idea, using a basic edge-detection to identify regions (“where to read”), then read them by the brightness at the center of each region.

In this method, you create a known optical pattern (in this example I used Gray Code) and apply it to the surface whose position you want to measure. Then aim the camera at it so that it looks at a small subset of the optical pattern at any given time. Ideally, each ‘pixel’ of the optical pattern should cover a 2×2 or more (3×3 or 4×4) pixel area on the sensor, since the optical pattern and the sensor’s pixels will never be *perfectly* aligned, and thus will blur across a couple neighboring pixels. Now you can identify the unique pixel pattern under the sensor and match it its position in the full optical pattern.


In a project at work, we needed to know how far a visual indicator pin on a piece of machinery was extended at any given time, and whether its position was in tolerance (reducing human observation error in dark and foul weather conditions). Since the sensor could not be permanently attached, we also wanted to be able to measure slop or shifting of the sensor itself relative to the pin, which would produce an incorrect reading. The small space, large pin travel and need for sensor cross-checking made common 1-D proximity sensors less attactive.

Definitions: The “pixel grid” is the actual sensor array. For ADNS-26xx, this is always 18×18. A “region” is one individual mark in the optical pattern, corresponding to a 3×3 (etc.) region of the pixel grid as mentioned above. The “region grid” is the array of these regions overlaid somewhere on the pixel grid. For example, with an 18×18 pixel grid and each region 3×3 pixels, the region grid overlaid onto the sensor can be as large as 6×6.

By performing this 2-stage lookup (find region grid offset on pixel grid, match region grid to known optical patterns), the total computation time is reduced by mainly working with only a small subset of the pixel data (the region grid), and the positioning resolution is at least (region size) and at most (pixel size). Working with only the center pixel of each region, to the extent possible (rather than e.g. averaging the entire region’s pixel values), is also beneficial since the regions may not be perfectly aligned to pixels and the focal plane at close range is very narrow (<1mm), thus the image may not be completely in focus – especially if looking at a curved or otherwise 3D surface. So all the pixels toward the edges of the region will tend to dilute the reading.


Absolute 2D position encoding/decoding using a Gray Code pattern. Position is resolvable generally to 1 pixel, in this case measured at about 2.4 mils (about 70um). The top-right shows the raw image with region grid (black squares) overlaid aligned to the strongest edges (pink crosshairs). The bottom-left shows the edge-detection itself, and finally, the top-left shows the recovered optical pattern. The actual position is the index of this pattern in the known fullsize pattern + the region grid’s offset.

Assuming an 18×18 image sensor:

Perform edge detection by taking the derivative of the image. Embedded systems such as Arduino are barely suited for non-integer math, let alone calculus, but we can take a poor-man’s “discrete derivative” easily by just subtracting neighboring pixels. Neighboring pixels on a uniform surface will not differ by much, so subtracting two neighbors will yield a low number, while along an edge, one will be very different from the other. We want to figure the vertical and horizontal edges separately. And we don’t care about the exact location of ALL the edges per se, just want to know on which rows and columns they occur. Once at least one good, strong edge is detected in each direction (horizontal and vertical), we know where to align the region grid so it is centered on valid regions.

For each horizontal row: For each pixel, its edginess (likeliness of being along a *vertical* edge) is given by the absolute value of (pixel – left neighbor) + the absolute value of (pixel – right neighbor).

v_edginess[row][col] = int(abs(image[row][col] – image[row][col-1]) + abs(image[row][col] – image[row][col+1]));

And of course that entire row’s vertical edginess is the sum of the edginess of all pixels in the row.

For each vertical column: Same thing, only going by columns, taking the pixel directly above and below. Again, the column’s edginess is the sum of the edginess of all the pixels in the column.

Obviously, the leftmost pixels has no left neighbors, and the rightmost pixels has no right neighbors (same goes for the top and bottom rows, they are missing neighbors on one side), so the easiest approach is to exclude them from the loops, e.g. for the 18×18 array, valid results start at (1,1) and end at (17,17). The result is an ‘edginess’ array of 16×16 pixels.

Once the region grid is positioned, threshold the region centers to black/white, then take the resulting region grid (4×4 in this example) and slide it around on an array containing the ‘known’ pattern until the best match is found. Obviously, in a real-world system subject to bad lighting, specks of dust, misalignment or misfocus, the match will not always be perfect. You might also want to know how well you can trust the measurement, so I compute a confidence value too. The confidence value is a function of the absolute % of regions matched, and the difference between the best match and the next best match. For example, if two different positions matched equally well (even if they are both “pretty good” percentage wise), you can’t uniquely identify a position and so your confidence must be zero.

Another thing briefly tested was to place an LED behind the pin and observe its side profile (Alfred Hitchcock Algorithm?), which worked surprisingly well.


Side profile of the pin showing the lower part of the indicator groove.

Tags: , ,
Posted in gEEk | Comments (15)

NinBendo (cont’d): Zero-knowledge, realtime music tweaking example

February 28th, 2009
by Tim

This is a followup to this post.

Quick video example of finding and bending the music data that plays during Super Mario Bros. 3’s World 1 map, using the FCEUX emulator’s advanced 6502 debugging features. Full-screen if you’ve got it – the video did not survive compression well, and I don’t feel like investing hours tweaking around with it…

Video: Using FCEUX features to bend SMB3’s World 1 map music

Once on the screen of interest, go to the Debug menu and open the Trace Logger window. Tick the two ‘Only log new data…’ boxes, choose a filename for ‘Log to file’, and press Start Logging. These options require the Code/Data Logger to also be running, so FCEUX will prompt you to open it (hit Yes). Pay attention to the ‘Bytes logged as data’ count, it is slowly increasing as data is fetched from the cartridge. Most of the game code is running a complete loop every frame, so the ‘Bytes logged as code’ count should max out quickly. Likewise, MOST of the data being accessed here (e.g. sprites, etc.) will go through their entire rotation within a second or so, but the music takes over 20 seconds to do a complete loop (you can see the data byte count roughly keeping time with the music). Thus the last >20 seconds of data in the logfile will consist of music data fetches. Open the log, scroll near the bottom and notice the resulting disassembly, consisting largely of e.g.:

$E47A:B9 71 A7 LDA $A771,Y @ $A7C5 …

In English that is: Cartridge address $E47A onward contains an instruction with data bytes (B9 71 A7). The first byte is a CPU opcode (LDA $xxxx), telling the CPU to load the data at memory address (specified by the next two bytes, $A771) into its A register. Some subsequent code (purposely omitted from your trace log since it runs every time new data is fetched) processes the sound data. Thus corrupting one or more of those address bytes will cause incorrect sound data to be fetched and parsed, causing audible glitching depending on what the fetched data tells the sound loop to do.

Tags: , , , ,
Posted in gEEk | Comments (1)

NinBendo – circuit bending by corrupting 8-bit game code.

February 28th, 2009
by Tim

Yeah, back in junior high I had not enough friends and too much time, and discovered that keying in random Game Genie codes would sometimes cause a NES game to (harmlessly) glitch out in interesting ways. :-p Some codes just locked up the game (drat!), while others caused screen glitches, messed with colors, and rearranged levels. Still others would screw up the game music or sound effects. I was always strangely mesmerized by the bleepy sonic barf of a good sound loop crash.

Of course, now that I’m all old and exposed to the Internets, I come to find out there are entire groups devoted to pretty much exactly this–glitching out electronic toys to produce interesting sound effects (circuit bending). So for those folks, here is some info and samples from codebending on the original NES. Hardcore circuit benders might consider this software-bending stuff cheating since the case never comes off ;-)
Read the rest of this entry »

Tags: , , , , , , ,
Posted in gEEk | Comments (2)