An Ironic Quote

“It does not do to dwell on dreams and forget to live.” -― Albus Dumbledore (via J.K. Rowling, Harry Potter and the Sorcerer's Stone)

I saw this quote on a keychain, hanging amongst a sea of keychains and other assorted baubles on the side of a kiosk, in the middle of a recreation of Hogsmeade (complete with fake snow), with folks passing by, plastic wands in hand while shorn in robes gilded with the yellows, reds and greens of various houses, on their way to wait in a 35-minute line for the "Escape from Gringott's 3D experience" ride in a theme park whose sole purpose is to extract large quantities of money by capitalizing on said attendees' dwelling in a superficial manifestation of J.K. Rowling's dreams in an attempt to escape their own realities for just a little while.

Or maybe experiencing a highly commercialized interpretation of someone else's dreams is considered living?

    Don't fall for a magic world
    We humans got it all
    Every one of us
    Has a heaven inside
            -- Kate Bush

I can haz ID card?

And now for something not-completely different:


I just committed support to Gutenprint for a couple of Magicard ID card printers, the Rio 2E and Tango 2E. It's likely other models will work okay too, but that would require someone willing to test things a bit.

Most features of the printer are supported; overcoat including the so-called holokote, holopatch, and overcoat holes; fine-tuning card alignment and even mag-stripe encoding.

Notably missing are duplexing (My Tango2E's duplexer is busted), smartcard encoding, holokote holes, and non-CMYKO ribbon support -- eg monochrome-only and CMYKOKO ribbons. There's also no sane way to query and report the printer status, but that's something I intend to keep poking at.

Output-wise, the black layer is slightly misaligned with the color layers, and there also appears to be a problem with the gamma correction. Yhe former is probably a matter of some fancy footwork, but the latter is likely due to the dodgy print head on my unit that is also responsible for that mangled stripe down one side. One can't complain too much when one wins a lowball eBay auction for an "as-is, parts-only" printer!

So, if there are other folks out there who want to be able to create ID badges using on Linux and entirely Free Software, it's now not only possible, but will yield high quality results. Extending this support to other Magicard models should be straightforward, but I've pretty much done all I can with what I have access to.

So, I'm putting the Magicard models aside for the time being, and, time permitting, will turn my attention to a well-used but otherwise fully functional Zebra P120i printer I recently got for a song on eBay. This one came with a full set of programmer's documentation, so I won't have to spend time reverse engineering anything (you hear that, Magicard? Publishing documentation leads to good things happening, and can open up entirely new markets for you. Not everyone wants to run their systems on x86+Windows!)

Beyond Magicard and Zebra, there are three other major players in the ID card space; Evolis (full documentation, woo!), Fargo (no documentation) and DataCard (some documentation). I probably won't bother with any of these unless someone steps up with some hardware; my personal needs will be well met with what I have now, and my time for fun hacking is a lot more limited these days.

Happy printing, folks!

Update 2018/02/21: The gamma curve problems are resolved, but the black registration issue remains.

Cable Snarl


Wiring into the house's breaker panel, as of Memorial Day.

If there's a word to summarize the electrics in the new place, it's vast overkill. When they're eventualy finished, that is...

...And so it goes.

Magical Moments


We were under a total fire ban, so we were unable to build our usual drum circle bonfires. What we came up with instead... produced a sublimely magical, intimate evening.

All closed up

This is how the tick farmhouse has looked since May:

229231:339770 229228:339767

As you can see, the exterior is completely finished, complete with gutters and a rebuilt porch deck. The interior walls were also all framed in, giving a skeletal sense of the final configuration.

By mid-June, the external electrical work was all finished, with the new service lines to the house buried, and new sub-panels in the yard, well-house, and along the driveway put in. Plus an extra conduit for low-voltage stuff and plumbing!

As I write this, the interior electrical work is slowly progressing. Although I intend to put in gas for cooking, water, and drying, I'm having the place wired for both just in case. Plenty of outlets inside and out, the kitchen layout more or less sorted, and my current fun involves planning the (many) ethernet drops. Oh, what fun!

I'm hoping by the end of the summer I'll be able to drywall off the HVAC closet, get an air condiditioner installed, and maybe even close off the ceiling! Then it's just the new water heater (and natural gas piping for the kitchen and dryer) before the place is techically habitable again -- so I can take it easy and let my finances recover before moving onto the next phases -- namely the kitchen, bathrooms, and closing off the interior walls.

...And so it goes. :)

And the bombs bursting in air...


I think this photo nicely epitomises both the spirit of both our National Anthem and how we celebrate our Independence day.

This was taken from a nearly-perfect vantage point off of Duval St in Downtown Live Oak, Florida. It even made it into the local paper!

Mitsubishi CP-D70 family, now with more Raspberry Pi Goodness!

Back in March, my reverse-engineered processing library for the Mitsubishi CP-D70DW family of printers reached quality pairity with the official Windows/OSX drivers and their SDK. This was a huge milestone; it's now possible to drive these printers using entirely Free Software, with no quality compromises, on non-x86 CPU architectures. To do this, you will need Gutenprint 5.2.13-pre1 or newer, along with an up-to-date lib70x snapshot.

Here are the happy models:

  • Mitsubishi CP-D70DW
  • Mitsubishi CP-D707DW
  • Mitsubishi CP-D80DW
  • Mitsubishi CP-K60DW-S
  • Kodak 305
  • Fujifilm ASK-300 [completely untested]

I held off on announcing this achivement due to one rather annoying problem. It seems most folks interested in using this family of printers wanted to do so using the popular Raspberry Pi systems. Unfortunately, for (at the time) unknown reasons, the CP-D70DW spectacularly failed to print with RPi systems, with the image data failing to transfer to the printer.

To further complicate things, I was unable to recreate the problem on the Kodak 305 (aka a rebadged CP-K60DW-S) and an RPi2. Software-based sniffs were useless, and things stayed at this impasse for quite some time.

What finally broke the logjam was one particularly motivated user running into a similar problem with an RPi3 and a CP-D80DW model -- but only when there was nothing plugged into the ethernet controller. This was a bizarre development, and a working theory that there was something funky going on with the RPi's onboard SMSC USB hub/ethernet chip began to develop.

He convinced Mitsubishi/Europe that it was in their interests to help figure this problem out, and I soon found myself with a CP-D80DW and several boxes of media on my doorstep and a backchannel to their technical team.

Try as I might, I was unable to recreate the problem on a RPi1 or RPi2, but on an RPi3, I was finally able to trigger the failure. Armed with a true USB sniffer and a copy of the USB spec, I was able to rapidly identify what was acutally going on.

The USB2 spec (section 8.5.1) dictates that, when in high-speed mode, a flow control mechanism (NYET/PING/[N]ACK) be used to maximize transfer throughput. NYET is sent by the device after a successful transfer to signal that it can't accept more. The controller then starts polling the device with PING requests, with the printer responding with a NACK until it's ready, at which point it responds with an ACK.

The problem, in a nutshell, is that the RPi's USB controller ends up sending the PING requests so rapidly -- about 400 nanoseconds apart) that it effectively triggers a denial-of-service (DoS) situation in the printer. The funny thing is that the RPi's controller starts with a PING interval of about 1.2 microseconds, and everything is fine until it pulls in the timing, triggering the DoS.

(A regular PC with an xHCI controller demonstrates variable PING timing; it starts at about 400ns, but backs off to about a 4us interval)

If other USB traffic is present, then the bus is too busy to send the PINGs so rapidly, and the printer is fine. Notably, simply establishing a physical link with the onboard (USB-attached) ethernet controller (even if the interface is "down") generates sufficient traffic to mitigate the problem. Plugging in a thumbdrive and dumping data back or forth is also more than adequate.

I've reported this problem to both Mitsubishi and the RPi kernel folks. I don't think one can expect much progress on the root cause of this problem, but the above workarounds are at least adequate to using these printers with RPi systems.

...Enjoy, folks, and happy printing.