Woo! Prettified tweets!

It’s great to tweet, and it’s great that people tweet. But the timeline of your and your follower’s tweets gets big fast. It’s always been my opinion that Twitter should be as real-time as possible. I loved the text-message model of the Twitter days of yore, though didn’t love constantly checking my phone. I found that what I actually crave is knowing there are tweets waiting for me to read, not necessarily reading the tweets themselves.

In the past, I’ve connected my doorbell to Twitter. This was great, but I still had to go to Twitter to see the tweets. Talk about #firstworldproblems.

In the past, I’ve also seriously modified a Smith Corona typewriter. This clearly is a match made in heaven, why didn’t I combine the two earlier? In fact, I remember seeing an article about another bunch of people doing the same. It had to be done. This would give me the best of both worlds. I can hear the typewriter doing its thing when I’m doing my thing, and when I eventually walk past it I can catch up on the haps.

This mess printed the preface to Twilight!

First, I better clean up the electronics. My intention was to use the typewriter as a display piece of sorts. My living room is about as interesting as a 100-square-feet room can be. I imagine a Typist Typewriter (à la ”player piano”) could be a great conversation piece. But the breadboard everything lived on was an absolute mess, which meant for a low RAF (roommate-acceptance-factor). And in my previous testing it had to be tethered to my laptop, which meant for a low SAF (self-acceptance-factor).

I’ll explain my process and throw a gallery at the end.

The rat’s nest was easy to clean up. I ordered some DIP sockets and 30awg wire on Amazon (<3 prime) and went to work making things more manageable.

I started by soldering wires to each of the key matrix pins on the typewriter’s main logic board since I didn’t have a non-janky mating connector and I was going for low-profile. I made the mistake of cutting ~12″ leads of wire. I figured I’d trim them later, but in my excitement I never did. Next, I soldered in a couple DIP sockets for my multiplexers. Last time I soldered them directly, I ended up cooking them! I patched in the lines from the rows/cols and re-used the old colored twisted pairs as data lines so the Arduino can talk to the multiplexers.

Excited, I plugged everything in for a test using an older version of my Arduino firmware. As I sent serial data down the pipe, the Arduino responded appropriately, but the muxes never enabled! Ahh! I forgot to connect the enable lines! A quick trip back to the bench and I’m in business. Characters print, but the keymap is wrong. I must have swapped lines. Okay, fine. I went through the motions and created a new keymap (iterating over each of 64 row/col combos and documenting which character is printed). After that, it was set! The typewriter simply prints raw data fed to it via serial/UART. I have special cases for ASCII 10 and 13, and 127, that map to the return key and the special character-erase key respectively.

After updating and optimizing the Arduino firmware, I decided to dedicate a Raspberry Pi computer to be used as a controller. Since the typewriter prints raw data, all the text formatting has to be done by the controlling computer. I whipped up a script in Python to take data from the Twidge Twitter CLI and objectify and sort it. This creates a collection holding each tweet’s properties (author and body), which allows me to easily sort and format the tweets for printing. After parsing the Twidge output, the program iterates through the collection and (assuming the typewriter’s carriage is sitting at a blank line) prints the author of the tweet. It then adjusts the carriage to a set position and begins to print the tweet’s body. Should the tweet be longer than the remaining columns available on the page (This typewriter prints about 65 characters per 8.5″ wide page), it intelligently returns the carriage and advances it to the same start position for the body of the line above. This creates two columns on the page, one for authors and one for the tweet data.

This script is called via cron.

~$ twidge lsrecent -su | python /home/pi/tweetmash.py


That’s really all there is to it. Since the whole thing doesn’t fit in the typewriter without leaving the keyboard out, my next project is to eliminate the Arduino. The Raspberry Pi has plenty of GPIO pins to control the multiplexers directly, and WiringPi should allow me to control them with my existing Arduino firmware.

A Github repo with all the software is available.

TLDR;  A typewriter automatically types out tweets as they’re posted. 

Woo! It works great with my MacBook Air. One hiccup, for the number pad to work, you must hold “num lock” when connecting the keyboard. The “num lock” key and light don’t seem to work as they should. Small price to pay.

I’m lucky enough to have a fab Apple Extended Keyboard II that belongs to my Macintosh SE. Unfortunately, it wasn’t doing much good connected to my rarely-used SE, so I figured a better home for it would be on my desk at work, where I spend the day pounding away on a crummy keyboard anyway.

This keyboard is a dream to type on because it uses mechanical switches. And I lucked out: Apple made a lot of revisions of this keyboard with cheap switches, but it turns out that I got one of the good ones. Mine is a USA model with authentic Alps Cream key switches. Lovely!

The biggest stumbling block is the interface to the computer. The Apple Extended Keyboard II is from the days of ADB, Apple Desktop Bus. The internet revealed two solutions: An expensive and sometimes-hard-to-find adapter by Griffin, or a $16 microcontroller and some DIY elbow grease. Naturally I chose the latter.

Building It

All that’s in this project is a Teensy 2.0 microcontroller and the keyboard. You do have to compile and install the firmware, though.  A simple task, though on my Mac I had to install CrossPack to compile for the Teensy and TeensyLoader to flash code to it. Here I must give a shout out to the awesome folks who developed it - they also have support for a bunch of keyboard types.

~$ git clone git://github.com/tmk/tmk_keyboard.git
~$ cd tmk_keyboard/converter/adb_usb
~$ make


Then use the TeensyLoader app to flash the .hex image onto the uC.

Connect ADB pin 1 (data) to Teensy pin F0, pin 3 to Teensy vcc (5v), and pin 4 to Tesny gnd (ground). You could wire up a DIN-4 (“s-video”) connector if you wanted (female to use an authentic Apple cable, male to make your own cable), or you could completely enclose the Teensy into the keyboard like I did.

Here’s a gallery. The process is as simple as connecting the proper 3 pins to your ADB keyboard and then programming the microcontroller. I chose to enclose the entire converter inside my keyboard, as I didn’t want a little dongle hanging out to break and I also didn’t have the proper connecters to mate with the keyboard’s.

Excuse the poor quality.

Well, I decided to drag my SE home from my parent’s house when I came back from winter break. It sat in the laundry room for a couple weeks, but I was bored today so I decided to stretch its legs. I had also recently been reminded of the Hack A Day retro challenge and so I thought it might be the perfect way to spend my afternoon.

Back when I first got the SE, I was eager to connect it to anything that I could, so I had a ziplock bag full of all sorts of vintage-Mac cables. AppleTalk adapters, serial cables, etc. A quick dig through the bag netted me a mini DIN-8 to DB9 cable. I dug around another box and found a null modem cable and a USB-serial adapter. By connecting these three cables together and plugging the USB side into my MacBook Air and the mini-DIN into the SE’s modem port, I was able to quickly establish a serial connection with Zterm.

My initial intention was to download a TCP stack and a System 7 compatible browser, however I couldn’t get the TCP stack properly unzipped on my contemporary Mac and I couldn’t find a browser that was suitable for System 7.0. Most that I found required a later variant of System 7. While the later version is available from Apple for free, I would have no way to create an 800k floppy to install from as I only have 1.4m floppies. To boot, the only other machine I own with an 800k drive is at the very same parent’s house still.

Moving on from that idea, I decided I’d just use a terminal browser. Getting a console was a slight challenge, as Mac OS X doesn’t natively support hardware terminals. Attempting to enable one simply does nothing. As I recall, the only version of Mac OS X to support hardware terminals is Mac OS X Server, as Xserves are the only contemporary Macs that have hardware serial ports.

The solution came from everyone else who has ever used an Apple II as a terminal. Screen! Within screen, you can execute getty. Perfect. After fussing with baud settings and window sizes (I found that the screen session on OS X needs to match height and width of the SE terminal) I was in business. Now to find a suitable browser. Instead of installing Links or Lynx locally, I SSH’d right into my AWS instance, as I already had lynx installed there. Everything fell in place.

As you can see in the (rather poor) image attached, the HAD retro site loaded right up. There’s some issue with the terminal that I haven’t straightened quite out yet, but I have a feeling that it has to do with Screen on my MacBook Air. I’m going to connect the SE to a Raspberry Pi and see how that turns out. That’s a project for a later hour, though. I think I deserve a nap right now.

The first 100% successful string printed.

Typewriter hacking! Ahh!

Typewriters are pretty cool little devices. They’re keyboards directly interfaced with daisy-wheel printers. In our venture towards converting a typewriter into an old-school teleterminal, I’ve first dedicated myself to getting the thing to print autonomously. And I’ve succeeded!

This project is actually really exciting to me purely because of its novelty. I think it’s so super cool. Donny, my roommate, suggested building a web form that would allow people to send messages to it. Perhaps we would put a webcam on so you could watch your message get hammered out in real time.

After a really failed attempt with a Royal electric typewriter, I dragged home a Smith Corona DeVille 80. This puppy has a dead-simple keyboard that I was able to reverse engineer in a matter of 30 minutes. I built up a wiring harness to bring the signal/scan lines onto my breadboard so they could be multiplexed by the arduino, and then I built a keymap by closing every possible combination of signal and scan lines and writing down what each combo printed.

After building out the Arduino sketch, I have something that accepts characters over serial, parses them and simulates the proper keystrokes. In fact, the keystrokes it simulates are nearly the same ones a human would make. To type the character ‘A’, that is the capital letter  ’a', the arduino first sets the caps lock on the typewriter, then types the letter ‘a’, then disables caps lock. The same sequence is done for special characters like ‘!’, “@”, “#”, etc…

One of the first things I printed, naturally, was the preface and start of chapter 1 of the novel Twilight. It came out nicely.

Deaf, Dumb, and Mute… Until now!

So, most homes have doorbells. Do people really use them anymore? At our home, not only do we never have visitors, but the doorbell button is out of reach. It sits idle, its transformer slowly syphoning power.

Wouldn’t it be great to repurpose the doorbell into something that’s useful? I thought so. Some torrent clients have the nifty capability of running a command when a torrent downloads — so why not ring the doorbell? Not being that avid of a torrenter, I instead chose to give it a Twitter account and alert the house whenever my roommate or I tweet.

How do? Arduino, naturally. Also, Raspberry Pi.

The Arduino has a relay on one of its digital pins. When the relay closes, the doorbell button is “pushed” and the chime rings. The Arduino is programmed to wait for a character [1 through 4]over the serial port. A ’1′ is a short push (“dingdong”). A ’4′ is a push-and-hold (“ding…dong”). ’2′ and ’3′ are somewhere in between.

The Raspberry Pi runs Nginx as a web server and PHP5. When a request is made to the web server, a serial port is opened and a character is sent down the pipe to the Arduino.

Locally, I wrote a shell script that gets stuck in /bin/ called “doorbell”. When you run it, it makes a request with cURL to the Raspberry Pi, which rings the doorbell. Simple stuff.

For the Twitter part, I fell back onto the trusty Twidge CLI for Twitter. It keeps track of unread posts and all that jazz. I wrote a simple shell script (to be run each minute by Crontab) that gets the output of twidge, counts the number of characters, and if it’s more than zero (0), it rings the bell. In the future I’d like to implement the “feature” of it chiming once per new tweet, but for now it rings once if there are new tweets at all.

I’ve found two such projects. One’s a twitter monitor that types out tweets with a certain tag. It’s not interactive, it just prints. The other is a teleprinter that passes keypresses over serial, and prints out any characters received over serial. This was more the direction I wanted to go. My roommate was very excited about the concept of having a teleterminal, that is having a Linux console available on the typewriter. I thought, and continue to think that this is a reasonable goal to work towards. How many people can say they have a teleprinter? How many people can say that they built it themselves?

My roommate Donny had a typewriter in mind, so all that was left to do was figure out what needed to happen electrically. All of the typewriter-related projects that I’ve found online have been incomplete in their documentation. Both had code samples available, but no hardware or circuit diagrams. So for that I was on my own, so I picked an approach and I settled into it.

To understand how this approach works, it’s important to first understand how a typewriter’s keyboard works. Keyboards are simply matrices of switches. In the case of most typewriters, there are 8 electrical columns and 8 electrical rows. To detect a keypress, the controller will pull one column to a logical “high” and then sequentially check all the rows to see if they have become high. If one has, it means a connection was made by a particular key. The lines being pulled high are called signal lines, and the lines being checked against each signal line are called scan lines.

So, to electronically spoof keypresses, you must create a path between the row and column that corresponds to the character you wish to print. How? The answer I came upon was using a set of multiplexers connected together. Eight columns are connected to one mux, and eight rows are connected to another. The common i/o lines of the multiplexers are tied together. This way, all it takes to connect any two lines together is to set the select bits of each multiplexer and then lower the inhibit line, creating an electrical path and simulating a keystroke. All of this can be done using an Arduino microcontroller, which is perfect.

The parts themselves are relatively easy to come by. You can order them online or buy them at an electronic parts store. We ended up driving 60 miles round trip to get them, because we had nothing better to do and didn’t want to wait.

Hardware Used

• Arduino Uno
• 4051 CMOS multiplexers

This is the compilation of so much research and lots of help from the nice people of Reddit, and a few unhelpful comments from Experts-Exchange. The reddit thread is here.

Read on for the meat and potatoes.

I was able to get everything sorted out with a little experimenting. I’m writing this in newb layman’s terms because if you’re a CS student like me and new to Sun and Sparc hardware, it’s so much easier to understand this way.

If your Sun just has one of the things locked and you can’t boot, this may help you too! But I was cursed, and both were locked.

Hindsight: The most important step in this guide is clearing the OpenBoot Firmware Password. Without this password, you can’t choose the boot order or really do anything with the machine.

You will need:

• Sunfire v100/v120 with the case opened
• Metal jumper or screwdriver
• Console cable and terminal emulator
• A computer or virtual machine running Solaris (x86 or SPARC) setup as a JumpStart server
• A network to attach both machines to
• The Solaris DVD install image
• Solaris 9 Supplemental CD (source for LOMlite packages)

Steps:

0. Install Solaris on another machine. I virtualized this on my MacBook using Sun/Oracle’s own VirtualBox. Follow a guide you may find elsewhere online to set this up as a JumpStart server. This is where you will define the hostname and IP address of your Sunfire. This step is the second-trickiest to do and may take some time. Be patient and triple-check for typos in your configuration files.

1. Connect to the LOM console of the Sunfire using your terminal emulator and console cable. Connect the Sunfire to the network via ethernet using the net0 connection. On your terminal, you should see the LOMlite password prompt asking for a username and password. At this time, rapidly short and unshort the JP13 pins on the main motherboard with the screwdriver. You can find these pins easily- they’re between the CPU cooler and the motherboard’s watch battery, immediately next to the LOM MCU. If you do this a dozen or so times very rapidly, the LOM will fail to read the eeprom and the unprotected lom> prompt will show up.

1a. Try the “poweron” command. If the machine is already set to boot from the CD drive, you should monopolize this and get a bootable Solaris install CD in there ASAP! Don’t jumpstart boot if you don’t have to! If you can boot a Solaris cd, skip to step 4. If the machine boots to the internal drive, this could work if you know the root password. Skip to step 5 if this is the case. If it boots the internal hard drive but you don’t know the root password, or if the internal hard drive has been wiped/dban-ed/is otherwise unbootable, keep reading.

2. Issue a “bootmode reset_nvram” command. Then, try the “poweron” command. This will change the default boot order to net, allowing us to jumpstart the machine from the server you built in step 0. If you get the lom> prompt again, type “console”. If you get the “console not shared” message, wait about 2 minutes, and type “console” again. Keep trying until it works for you. If you’re lucky, you may catch the OpenFirmware header which shows the machine’s MAC address and specs. After this, it should drop you to a console that has a simple “>” prompt. This is called the “restricted monitor prompt”, which only allows you to issue “boot” without having the firmware password. There are other commands, but you aren’t allowed to use them. This prompt is the locked-down version of the OK prompt. You can not choose a boot device without the password, which is why we reset the nvram, which has the side effect of forcing network boot.

3. Type the “boot” command. This is the moment of truth. If your JumpStart server is configured properly, the console should output some hex-looking strings and a “spinning” character. Eventually, the Solaris installer will start and guide you through the installation. At the “disk selection” stage of the installation, make sure the installer knows to change the default boot order to the internal disk and to NOT continue booting from the network. It had done this by default for me and the installer pointed it out to verify, but it’s good to double check.

3a. If the Sunfire doesn’t find your Jumpstart server, go back and double check some things. Sit down at the jumpstart machine’s console. You’ll need to be root to edit most of these files. Make sure the Sunfire’s MAC address and desired hostname are in the ethers file. Make sure the MAC address digits are separated by “:” and it matches the MAC that’s listed on the System Configuration Card sticker and the OpenFirmware header that comes over the V100 console. One guide I followed said to use the “-” and that didn’t work for me. Make sure the Sunfire’s desired IP and hostname in the hosts file. Double check for typos. Run the “share” command on the server and make sure the /export/config and the /export/install directories are shared by NFS. Use the ./check command to check the configuration files. Re-run the add_install_client script double checking the parameters.

3b. If running through 3a doesn’t help, don’t give up. Find another guide and see if they say to do things differently. It can’t hurt to try different methods to find one that works.

4. When the install is done, reboot the system when it asks you to. I chose the option not to auto-reboot when finished, so this was a step for me- it might not be for you depending on what you chose. When the system is restarting, watch the console carefully. You should see the restricted monitor prompt automatically boot from the internal hard drive, yay!!! Then you should see that “spinning” character while Solaris bootstraps and initializes things. The first boot took a few minutes for me, be patient. Eventually you should get a console login. Login as root. I setup my Jumpstart server set a root password on the machine automatically, which was “password”. It may be different depending on the guide you followed.

5. Clear the OpenFirmware password. You must be root to do this. When you have a root command line in Solaris (#), issue the command “eeprom security-mode=none”. This shouldn’t return anything. Then issue “eeprom” and hit enter. This will print out the eeprom configuration to the console, where you can double-check the security mode. If it says “none”, be happy. You will now have a full ok> prompt at OBP. Yay!

6. Clear the LOM. This is by far the trickiest if you have no solaris resources (like me). To clear the LOM, you need the 3 SUNWlom* packages, called SUNWlomu, SUNWlomm, and SUNWlomr. These used to be freeware on the Sun site, but when Oracle bought them out they pulled them offline. Apparently, the only place to find them is on the Solaris 9 Supplemental CD. I have yet to find a copy of this CD online or these packages individually, so I wish you good luck. If you do find the packages, you can install them by following the instructions to do so in this doc. A nice redditor spent hours digging through the Oracle site and finally found them for me on the disk image of the Solaris Supplement CD, however you need login credentials to access the downloads. Next all you have to do is edit the lom configuration file and change “serial-security=1;” to  ”serial-security=0;” and reboot.

6a. If you can’t clear the LOM password because you don’t have the packages, make sure you have the eeprom set to auto-boot. You can use the eeprom utility to check this. Issuing “eeprom auto-boot?=true” will ensure that it does. This way, when you don’t have the lid off of the machine (and can’t reset the lom a bajillion times with a screwdriver), the power rocker switch on the back of the machine will start up Solaris with no console interaction, which is an okay trade off considering the machine used to not boot up at all.

6b. If you want to ditch Solaris, I recommend finding the lom packages first and clearing it too, because as far as I know, Debian Sparc or any of the other non-Solaris OSes can’t deal with the onboard lom or eeprom, so it’s best to keep them as vanilla as possible just in case something fails.

That’s it. You should now have a booting system. Enjoy!

So, not long ago I received a Raspberry Pi in the mail. Yep, that’s the ultra-coveted, ultra-backordered, ultra-low power, ultra-small, ultra-awesome single-board-computer that only costs $35 (give or take). I had it kicking around for a few weeks running Debian before I really had a solid idea of what I should do with it, which turned into an exercise in home automation. I plan to design a home automation system with my electrical-engineering-major roommate come September.

Essentially, this exercise serves as a proof of concept which demonstrates the reliability of the Arduino-Server communication as well as the viability of the Raspberry Pi as a platform for running the home automation software.

Overview

Anyway, the abstract design for our system will be a chain of microcontroller nodes all connected back to a server, which monitors the system, provides a web interface, and automates. I had already made a rudimentary web-arduino link over serial that could flash a light, so I thought hooking up a garage door opener would be cake. This system had been tethered to the server instance on my laptop, which is undesirable. Pair the Arduino with the Pi (instead of the laptop) and a wifi dongle and we’re in business. I also had written (quite a while back) an Android application to allow mobile actuation of that little LED blinky sketch I wrote, so adapting that isn’t even necessary because I built it to be user-configurable.

I will spoil the fun and say the project was successful. I can actuate the garage door from a web interface hosted from the Pi. However, this is not to say the project does not have it’s faults. Due to the hardware limitations of the Pi, I find the system to be completely unstable as the Pi cannot provide adequate power to the wifi adapter used to connect it to the network. Should the system be networked with Ethernet, or even assembled with a low-power wifi adapter or perhaps even utilize a powered hub with the current hardware, the stability would be greatly improved.

I also ran into an issue where the Pi refused to boot without a monitor connected over HDMI (headless), which I remedied by forcing HDMI-hot-plugging (the Pi always assumes a monitor is connected). This may have something to do with the Debian Wheezy beta that I am using.

Design

Starting out, I knew the basic design of the system. A server running LAMPP would interface with a microcontroller (in this case an Arduino Uno) via serial UART. A software package would have to be written on the server side to deal with automation events through a web browser. This software must also be able to communicate with the microcontroller.

The Arduino microcontroller has GPIO built in, but not much more. To interface with a garage door opener, I needed to be able to switch together two contacts. This is easily accomplished with a relay. There is a very helpful and very prolific wiring diagram of how to connect a relay to a digital output pin on an Arduino floating around on the internet; I used this and it helped me (a meager CS student, not EE) greatly. It can be found by searching “using a relay with arduino”.

One sunny afternoon I strolled down to RadioShack. I am very much partial to HSC/Halted, however it’s 15 minutes away and was closed at the time. I would have saved a chunk of change by buying parts there instead. At Radioshack, I acquired a small reed relay capable of switching .5A at 125v, which I felt (from absolutely no research or experience) would be sufficient for switching the garage door. I also got a small prototyping circuit board, the type which has a bajillion tinned holes and nothing more. I assembled the circuit as laid out in the diagram which I mentioned above. I actually bought two relays in case I should decide to add another channel of control at a later time. For now, I left it unpopulated.

Connecting this to the Arduino was cake. I connected the ground lead, the +5v lead, and finally the signal lead to digital pin 5 (a personal choice). I then adapted my LED-blinking sketch (which responds to bits over serial) to instead “push” the relay button.

The completed circuit can be seen in the photos above. It’s quite simple.

Making it Garage-Proof

I figured if it would be in the garage, it would need to be *proofed. I remembered a sample of watertight outdoor enclosures I had requested forever ago and figured one would be perfect for this application. Of course, I would have to destroy it’s water-tight properties to interface it with the outside world, but I wasn’t too worried about that.

The image shows the rPi nestled in its new home, with a notch dremel-ed out of the case for connectivity.

I wrapped the relay board and the Arduino together with electrician’s tape to keep them from knocking around and shorting on the Raspberry Pi.

I then fit that bundle atop the Pi inside the enclosure, seen in one of these photos.

After the USB cables were connected, I buttoned up the enclosure and taped the bundle of USB cables across the top for good measure.

The USB wifi adapter was then taped on top of said bundle. I am having

reliability issues with this particular adapter, so I do hope to replace it soon with a low-power module.

Installation

Installing the whole bundle was a piece of cake. I took the leads from the relay and screwed them into the garage door opener contacts. I placed the whole package on top of the opener motor itself, and plugged the Pi into the spare outlet in the ceiling. I was able to SSH into it almost immediately (yay for fast boot times), and echoed a “1″ over the serial port the Arduino sat on. The garage door moved, yay!

I also found (duh?) that I can use scp to send a “1″ directly from my own computer without having to do more than type the Pi’s password.

In the image showing the bundle above the opener, you can see a blue spot of projection on the ceiling from the wifi adapter. If this blue glow is solid, it means the network has gone down and the connection was lost. Sad times! If it flashes, it means there is an active connection between the adapter and my home router. Which is good. Unfortunately due to the Raspberry Pi not being able to provide enough power to the power-hungry wifi adapter, the connection is lost more than it’s active.

Aside from the wifi instability, this little proof-of-concept has been eye-opening. If it were hardwired into the network (like any of our actual home-automation gear would be), or even if it had a powered USB hub to give the wifi adapter some juice, I have few doubts that it would be rock-solid reliable.

Earlier in the week, I had won a thermal printer on Ebay. More specifically, it’s a Zebra LP-2443, commonly used by UPS and people who use UPS to print 4×6 sticky-backed shipping labels. I won it for the bargain price of a little under $13, plus flat-rate shipping. This particular machine features the most high-tech interfaces (heh), RS-232 and IEEE-1284. These are more commonly known as serial and parallel, respectively. Now, while I am the owner of several types of computers, none of them were graced with either of these interfaces. So, I was off to Monoprice.com (one of my favorite shopping sites) where I picked up this little baby: A USB-parallel adapter.

It didn’t advertise any compatibility with Mac OS X or Linux (the platforms that I run), but I bought it anyway, because who can go wrong at the low price of $6? And I didn’t go wrong, because it worked wonderfully.

At first, I attempted to connect the printer to my Mac via a PL2303 USB-Serial adapter, but for some reason I couldn’t manage to get any bits to flow. I suspect it may have had something to do with the fact that I didn’t have any thermal stock besides a bunch of old receipts taped together, which the printer wasn’t very happy with.

Next I moved to the parallel adapter (Above? At left? Who knows where that danged photo went.) with my Mac, and that proved more promising, even with the jank paper. The adapter showed up in the Printer dialog and there was a Zebra EPL2 driver, and I was thrilled. The first time I tried to print something, it printed it with a little delay. Rejoice! I tried it again: Nothing. Well, that sucked.

So, I moved to a Linux machine, an “old” formerly-Vista-laptop my sister gave me. I plugged the adapter in, fired up the printer and the print settings dialog, and whaddyaknow, it saw it and had the very same EPL2 driver as my Mac. I opened Vim, typed “Hello, world.” and sent it to the printer. And I’ll be damned, it printed. I did it again, and it printed again. Holy crap, it was working.

Now, this whole time, my objective was to somehow push tweets to it, but only the most recent unprinted tweets. Now that I was on Linux, I assumed Twidge (a Twitter CLI) would be the answer, and I was right. My initial evaluation of Twidge was that it could just automatically spit out the recent tweets to a file, using a little terminal redirection and the crontab. Then, I would use diff (with more redirection) to compare those tweets to a file containing the tweets that have already been printed. Then I would take that file and process it using a hand-coded (on paper in my math class) C program that I wrote to insert carriage returns after every ~20th character to make it printable. And then print that out. All using cron to automate it.

Seems logical, right? Yes and no. Yes, it’s logical, but it’s grossly unnecessary. After reading the Twidge help file, I learned that it knows which tweets are read and unread and will happily only spit out the unread ones, simply by adding the -su flag to the command. Lovely! Everything I wrote about above is nullified and life is easy again.

I then looked into printing out the output of Twidge. I had expected I would have to redirect it to a file and then print that file. But again, I was wrong. By throwing on a “| lp” to the command, all output was piped (excuse the pun) to the default printer. Lovely. But it’s upside down. No bother, just rotate the output in the printer settings by 180°. Lovely, now they’re right side up. But wait, if there are a lot of tweets, they get disordered because they’re being printed in order but upside down… After reading the lp man page, I came up with a super elegant solution. This time it was to change “| lp” to “| lp -o outputorder=reverse”. That forces the printer to collate the already-rotated pages in reverse order, correcting the issue I was having.

So it works. I edited my crontab to execute that command “twidge lsrecent -su | lp -o outputorder=reverse” once a minute, on the minute, sixty times an hour, etc. for as long as the computer is running. Note to self: Don’t leave it running at night, because it’s loud enough to keep me from falling asleep the night before I have two midterms.

A few footnotes: I bought the thermal rolls at Staples because I needed them and they were the cheapest ones they had, that’s why they’re so narrow (half of the printer’s supported width). I plan to order wider ones online. I gave it it’s own twitter account so it only prints things I care about. Sorry, Engadget, you didn’t make the cut. Also, it kinda formats things jankily at the moment because.. I really don’t quite know why.

Addendum: Since I wrote this post, I determined why things were being formatted funnily. Twidge formats it’s output for the screen with lots of extra spaces and line-breaks, so it was not pretty on the printer. I have since written two little C programs that I pipe the tweets through before hitting the printer to format everything properly and even make appendages to some tweets. I will eventually write these up. The first one, called TweetReplacer, simply reads standard input into an array of a struct I designed to represent each tweet, scans the usernames for my friend’s account, and then adds a (rather inappropriate) hashtag to the end of all his tweets. The next one, called TwitterFormatter, arranges the tweets into a single column of 23-character lines. It’s smart enough to not break words in half when changing lines, too. I’m rather proud of it.

Here are some final pictures for good measure.