Linksys WRT54GL + Linux: how I did it using DD-WRT

I finally broke down and bought a Linksys WRT54GL the other day because I wanted my $60 router to become a $600 router. The process was pretty straightforward:

1. Go to the dd-wrt website and then to the "Supported Hardware" tab (the downloads tab was way too arcane to navigate). Type in the name of your hardware (my case: wrt54gl)


2. Download the "Mini-Build required for initial flashing via WEB." The other mini build didn't work for me and resulted in the lolcatesque error, "Upgrade are failed!" Also download the "Standard Generic" (I chose the non-usb one). See the picture for more info.



3. Log into the router admin interface at 192.168.1.1 and flash the firmware with the mini build. If you aren't just pulling the router out of its box, you might want to hard reset and power-cycle the unit before this step.


4. Hard reset and power-cycle the router, then upgrade the firmware again to the standard generic.


5. Another hard reset and power-cycle should have the router up.

All in all, it was a pretty painless process once I horsed around with it for a few minutes. I also found some other references to be helpful:

• Install 1


• Install 2


• Manual

New paper is up

It is entitled, "Theory of space charge limited regime of thermionic energy converter with negative electron affinity emitter." You can find it here, published in Journal of Vacuum Science and Technology B. The DOI is 10.1116/1.3125282.

Generating a multiple page 11x17 PDF from drawings in QCAD

During the course of my job, I've been generating a lot of technical drawings for various parts that I need in the lab. One such part was a panel on which to mount a bunch of valves to handle the various process gasses we need for our experiments, so I laid out the drawing using QCAD. In order to have this panel fabricated by Pittsburgh Valve and Fitting, I decided to generate an 11x17 PDF with several pages so that it would be clear what I wanted. Making this multiple page PDF was non-trivial. From QCAD, one can only print postscript files. Here's what I did to get what I wanted.

1. Select 11x17 paper size in QCAD for my drawing.


2. Use print preview to line up and scale the drawing on the page.


3. Export the drawing as a postscript file. I exported one .ps file for each page in my PDF. Now I have a bunch of postscript files laying around my filesystem named 1.ps, 2.ps, and 3.ps.


4. Use ps2pdf with some options to generate individual pdfs of each page. I found a very helpful post on a blog called The Open Access Peon.
   
   I executed essentially the following commands a few times:
   
   $ identify 1.ps

1.ps PS 791x1223 791x1223+0+0 DirectClass 16-bit 52.9277kb

$ ps2pdf -dDEVICEWIDTHPOINTS=791 -dDEVICEHEIGHTPOINTS=1223 1.ps
   
   That last command gave me the following PDFs: 1.pdf, 2.pdf, 3.pdf)
   
   
5. Use pdftk to cat all the resultant PDFs together:
   
   $ pdftk 1.pdf 2.pdf 3.pdf cat output schematic.pdf
   
   Result: schematic.pdf



6. Rotate the pages of the result 90 degrees CW:
   
   $ pdftk schematic.pdf cat 1-endE output schematicnew.pdf
   
   Result: schematicnew.pdf
   
   

I'm pretty sure those last pdftk commands could be collected together, but that exercise is left to the reader.

Ultimately, one could develop a workflow with scripts that would build a PDF document from a dxf file using QCAD.

It should be noted that the panel we are going to wind up with is fairly different than the example given in this post.

Question: REST or SOAP for data access in a research lab

I have a programming issue that I'm putting out to the lazyweb to see if I'm on the right track.

Here's the problem: we have a UHV system in our lab. At any point in time, there is a lot of information that we want to know about the status of this system. It should be noted that this information is simply a report on the status of the system, the data isn't necessarily actual experimental data. For example, we need to know the pressure in any one of the chambers (there are four). We would also like to know the temperature of any one of the sample stages of the system, the status of the pumps, the status of the gate valves, etc. etc. etc.

In principle, we can use labview or something to grab all of the data from the pressure gauge controllers, pump controllers, etc. and put it somewhere easily accessible in a useful format. No problem. Once we have the data, we need to be able to access it, and I think this is where SOAP or REST comes in. It would be really great to just be able to have some kind of API where we could go out and grab specific subsets of that data. Like maybe we want to know what the pressure of each individual chamber was over the past 24h in order to plot this data and see if somebody opened the loadlock.

Am I thinking about this right? Is SOAP or REST the way to get this data out there in a useful format?

I prefer programming in python, and I'm guessing that somebody has already written the framework for me.

One day I'd like to have a LaTeX blog

Yeah, HTML is ok, but I'd really like to be able to write my blog posts in LaTeX. I'd like to be able to compose my posts in straight LaTeX, then upload them to the blog and have the server convert the LaTeX to some form that a browser can render. I'd also like to be able to push a button and have a PDF of all of my blog posts. Not that I've ever built an index in a LaTeX document, but I'd use that functionality to tag my posts.

Maybe one day I will write this software.

How to share an HP photosmart 1115 printer in Mythbuntu to a MacBook

I have this old Compaq Presario laying around my apartment and recently I decided to horse around with it, so I installed mythbuntu just to see what would happen. As luck would have it, my boss was trying to get rid of his old HP Photosmart 1115 printer and he generously decided to donate it to the cause. I've been wanting a network printer that I could put in my closet to print my boarding passes and other miscellaneous debris, so I wanted to see if I could share the photosmart from the mythbuntu box. Mythbuntu is a stripped down distro of ubuntu with xfce, so it didn't come with any of the printing utilities. However, it does ship with samba. Here's how I got it to print:

1. Figure out the cups and printing xubuntu utils:
   jrsmith3@calculon:~$ apt-cache depends xubuntu-desktop | grep cup
Depends: cups
Depends: cups-bsd
Depends: cups-client
Depends: cupsys-driver-gutenprint
Recommends: bluez-cups
Recommends: hal-cups-utils

jrsmith3@calculon:~$ apt-cache depends xubuntu-desktop | grep print
Depends: cupsys-driver-gutenprint
Depends: openprinting-ppds
Recommends: system-config-printer-gnome
Recommends: xfprint4


2. Install all the depends and recommends:
   
   jrsmith3@calculon:~$ sudo apt-get install cups cups-bsd cups-client cupsys-driver-gutenprint bluez-cups hal-cups-utils openprinting-ppds system-config-printer-gnome xfprint4


3. Open the printer configuration: Applications -> Settings -> Printing


4. In the printer configuration window, add a new printer: Server -> New -> Printer


5. At this point, the printer was shown in the "Devices" window. I just selected it and followed the instructions. Once the printer was installed, I printed a test page that seemed fine except that there was no color. Whatever, I'm just going to use this printer to print out my boarding passes.


6. Now you have to set up samba to share the printer. Samba ought to be set up by default in mythbuntu. Right click the new printer icon in the Printer Configuration window, and make sure "Shared" is checked.


7. I think that should do it. On my macbook, I opened System Preferences -> Print & Fax, then clicked the "+" button to add a new printer. I saw the photosmart in the "Default" category. I guess bonjour picks it up.

I'm sure there are some security considerations here, but I don't ever plan on leaving the printer on unless I'm printing something. In fact, I've set up the mythbuntu box to sleep after about 20 minutes of no use in order to conserve electricity.

I have to give credit to the thread that essentially showed me how to do this.

Brother HL-2170W with Kubuntu 8.04

I recently installed the proper drivers for my Brother HL-2170W on my Kubuntu 8.04 box. Previously, I just found a printer driver that worked in the database and was using that, but the print quality of small text was illegible. The instruction page was a little obtuse, so for the purposes of my own memory, I am putting the ordered list of steps I took to get the thing working.

1. Get the cupswrapper driver deb archive from the download page


2. sudo aa-complain cupsd


3. sudo mkdir /usr/share/cups/model


4. sudo dpkg -i --force-all --force-architecture (cupswrapper-drivername)


5. Open a web browser and go to "http://localhost:631/printers"


6. Click "Modify Printer" and set following parameters
   
   • LPD/LPR Host or Printer for Device
   
   
   • lpd://(Your printer's IP address)/binary_p1 for Device URI
   
   
   • Brother for Make/Manufacturer Selection
   
   
   • Your printer's name for Model/Driver Selection

The printed text is now much sharper. Martin McDowell's blog was helpful to me during this project.

Email practices for 2009

I recently sent a version of this message to the members of the group with which I work at CMU. I wanted to have a copy of it out on the public net so that I could point people to it when necessary.

As one of my new year's resolutions I am trying to use email more efficiently, and I want to let you know of the changes I am making. As you are all aware, email can be an enormous time sink, especially when you receive messages whose purpose is amorphous or poorly articulated, or messages which have no purpose at all (thus effectively spam). Since I send many messages to this list, I wanted to let you know how I am adjusting my email practices to reduce wasted time, both mine and yours. I have six points in this plan. At the end of this message I have included some thoughts and links regarding the ideas contained herein which you can read at your leisure.

1. Each email I send will contain exactly one concept or purpose. Reducing each email to essentially one concept possibly means a higher volume of messages, but it eliminates the aggregation of disparate concepts in the same email. Therefore, each individual email message can be organized and summarized more easily.



2. As a result of including only one concept per email, I will be using a newspaper model for my emails: structuring them as headline, lede, and story, and top-loading the information content. I will explicitly state the purpose of the message in the subject line, much like the headline of a newspaper article. The one or two lines of the body of the email will be the lede: a summary of the most critical information (5 Ws) and the purpose of the email. Finally, the rest of the message will contain all the necessary details.



3. Each email I send will have a suffix or prefix letting you know if the content is informational or if it requires action on your part. If I prepend "FYI:" to the subject line, you can know that the email contains only information of interest, no action is required on your part. If I prepend "Action:" to the subject line, then you know that the email requires some action on your part. Some messages are so short that they can fit entirely in the subject line of the email. For these, I will append "EOM" to the subject indicating "End of Message." Finally, I will add the time I estimate the email will take to read in parenthesis at the end of the subject line whenever possible.



4. I will prefer to use listservs as much as possible. These listservs keep a threaded archive of all the email that passes through them. By practicing points 1-3 above, these threaded archives will become a useful repository of information about a project. Secondly, all of this information will be replicated in a searchable way in everyone's local email client. Obviously, email intended for an individual should not be sent to the listserv, but I encourage others to use this resource. Some tips on listserv etiquette can be found on the internets. (note: I removed references to our group's specific listserv).



5. I will make every effort never to compose an HTML email in favor of plaintext (ASCII text, whatever you want to call it), because I will write in plain English. I find that modifying the format of the email by using colors, fonts, italics, etc. is a distraction and a time waster. I intend to write in clean, straightforward English so that my words capture the story I am telling. If I need particular formatting like a list, I will make it like I made the list in this email. URLs will appear in a line by themselves as opposed to inline with the rest of the text. Plaintext is a far more universal format than HTML and, since none of us are graphic designers, it can always get the job done. (note: I compose blog posts in HTML because it necessarily winds up on the web and therefore makes more sense.)



6. Finally, due to high workload, I am resolving to check and respond to email twice per day: once before lunch, and once around 4:00 pm, usually in EST. If you require urgent assistance, my office is REH 232 and my office phone is (412) 268.4034. Email is necessarily an asynchronous medium of communication, but attempting to make it a synchronous form of communication causes endless interruptions. Since I'm imposing this twice-daily requirement, I won't expect immediate responses via email from any of you. If I need immediate assistance, I'll contact you in the appropriate synchronous way (visit or phone call).

The previous six points capture the essence of my new email strategy. I have a few more odds and ends if you are interested at the very bottom of this message which I will follow with some links.

Odds and ends:

• smime.p7s:
  You may have noticed a file called "smime.p7s" attached to my emails; this is my digital signature and assuming you have a suitable email client, your email client can verify that the message wasn't spoofed and that I actually sent it. If you don't understand the previous sentence, you can safely ignore it and the smime.p7s file. The topic of email encryption is important, and I recommend taking a look at it and trying to incorporate encryption into your workflow.



• responding and quoting:
  I haven't yet developed a good strategy for responding to and quoting emails. Therefore, I will just include the entire message I received at the bottom of my response like I've always done. If I devise a better plan, I'll let you know.



• threading:
  Sometimes the point of an email thread mutates: today's discussion of a fume hood turns into tomorrow's discussion of an abstract submission. I don't have a good way of shepherding or moderating email threads to keep them from meandering; I'll let you know if I figure something out.

links:

• 99 tips to make you more secure and productive: a list of tips on email best practices



• how to stop your inbox exploding: Cory Doctorow's tips for managing a high volume of email



• the future of ignoring things: More of Cory Doctorow's ideas on managing email and information



• inbox zero: a series of articles outlining a strategy to maintain an empty email inbox