I bought this tablet back in July because I wanted to free myself from the lab computers. Since 99.9% of my open notebook requires cloud utilities I figured I could get away with it. I’ve been playing with it since the beginning of August so I thought I’d offer a review, it should be noted that I do not have the laptop dock which may sway my feelings on this a bit more towards the positive side.
The short: The Eee Pad Transformer is a powerful device that can handle most anything Android throws at it. I didn’t think I would use it so much as an e-reader, but that’s probably it’s best function for me. It can do a whole slew of things but in terms of using it for open science, sadly it’s just a giant phone. This isn’t to say it doesn’t have its uses, but it is a little too clumsy to use it for much in the lab outside of answering emails on the go, reading papers, and occasionally blogging (notice I said occasionally). While I do like it, I still much prefer the 5 year old laptop I use in lab and my phone (Droid Bionic) to using this in the lab. (Caveat: Until this week I had an OG Droid and that thing was atrocious, so I used the tablet more. But the Bionic has the same specs (maybe better!) than the Transformer so it is starting to fall by the wayside.)
The Full Review: I bought the 16GB, wifi version of the Asus Eee Pad Transformer. It’s only real flaw is that it has a goofy name (please remove the Eee and Pad parts Asus!). It is loaded with Android 3.2 (Honeycomb), has 16GB storable memory, 1GB RAM, 1GHz dual core processor and comes with an HDMI port and a Micro SDHC card slot (to expand the memory). The company claims there are 2 USB ports and a regular SD card slot but those must be on the laptop doc.
The tablet also gets excellent battery life. I typically charge it up once every 2/3 days depending on how much I use it. The day I received the tablet I used it for about 16 hours straight! I did everything there was to do and it lasted from morning until night. Unfortunately my hygiene that day wasn’t too spectacular…
The performance is really good as well. The tablet switches between apps quickly and can keep several apps in memory for a while. There are times when I have had about 10 apps running at once and can easily switch between any of them. The only problem I have had is with Adobe Reader. It seems to be really slow when you use pinch-to-zoom, and the pdf’s take a long time to load (it seems to load pages in blocks as if it were a big image). I’ve also encountered a few low memory errors when reading. These problems though may be the app itself rather than the tablet because I’ve read a couple of reviews that mentioned this error.
The tablet came with a few apps of its own that aren’t in the android market. There is an Asus cloud app that provides you free cloud storage for a year (a la DropBox) and let’s you remote desktop your computer or laptop from the tablet. Asus claims that the Transformer can be synced with both Mac and PC but as of the time of this writing only the PC option is available and that goes the same for the remote desktop functionality.
There is also an office suite that is (supposedly) compatible with office, but I’m a Google Docs person so I wouldn’t know about that. It also comes with it’s own e-reader app but it works only slightly better than adobe reader so I don’t use it that frequently.
The Transformer has a front and rear camera. The front camera is pretty useful for video calling. The rear camera is a 5MP camera, but the size of the tablet makes it awkward to take pictures. I also don’t think the software for taking images is very functional. The shutter is slow and you have very limited control of camera functions. I haven’t tried it for video yet, but I have a couple projects coming up that will be great for video that I could try the tablet on.
My biggest pet peeve with the tablet is typing. The stock Asus/Android keyboard has both Swype style typing and sentence prediction typing like Swiftkey X. Neither of these works very well and I would say the swiping keyboard doesn’t work at all. Because of this typing is awkward. If you hold it like a phone your thumbs won’t reach the middle buttons. If you hold it with one hand you have to regress to the primitive style typing you learned when you first touched a keyboard (the finger poking of doom!). Holding the tablet in portrait mode (vertically) is really the only compromise, but for some reason I just don’t like it.
With that said, I really like using the tablet over using a phone. The larger screen makes surfing the web and reading academic papers much easier and more comfortable than a phone, and obviously more portable than a laptop/desktop (funny how laptops now a days aren’t that portable anymore). The abundance of apps in the app market provide the tablet with more functionality than it would right out of the box. The front and rear cameras have their uses and could be made more useful in the lab environment. Surfing the web is a breeze (as it should be) and reading papers are now ultra portable. While typing is annoying it is tolerable in small blocks.
I still think tablet computing has a ways to go to integrate themselves into societies technological hands, but if you need a tablet now the Asus Eee Pad Transformer has a place in the lab. At $400 the Transformer is the best bang for your buck and you really can’t go wrong. Even though I haven’t tested the keyboard dock, I think it is definitely worth the extra ~$100 to make typing a little easier and more comfortable. Hopefully science on the web catches up and the Android Market becomes host to plenty of excellent science apps that makes owning a tablet even more worthwhile!
Yesterday, Tito Jankowski sent me an email requesting to see the log files from the OpenPCR machine. Part of the software function is to record the programs used and possibly error reports (I didn’t ask too much in this regard). Immediately I noticed something interesting. According to Windows XP, the log files did not exist on the computer!
OpenPCR calls saved programs from a directory hidden in the logged in user’s application directory. If there are no files in this directory then you should have no saved programs. Interestingly enough there were saved programs, but the files were no where to be found. I tried a Windows search on the whole computer and nothing could be turned up. Somehow the machine was calling files that either didn’t exist or were extra hidden.
I ran some tests to try and repeat the glitches from my last report. I was able to repeat the hold screen glitch (shown in the featured image at the top of the page), I was able to repeat the crash and restart on completion (which interestingly only happened in the saved program), and I was able to repeat the error that wouldn’t allow OpenPCR to run immediately after a completed program.
Then I remembered that I had initially installed the OpenPCR software on the lab’s laptop (that I mostly monopolize for my computing pleasures). I actually found the log files from the initial setup on that computer and Tito suggested I run the same tests on the laptop to generate the errors (he was convinced that the glitches were a hardware malfunction).
Turns out, NONE of those errors were repeatable on the laptop! In fact every error I had from my previous tests with OpenPCR did not occur, and every trial I ran went swimmingly. I did not receive the glitch shown above, I was able to start a reaction immediately after a completed reaction, and the restart crash did not happen. As of now it appears that all the problems were caused by the other computer to which OpenPCR was tethered.
So I want to thank Tito for his support throughout the afternoon yesterday and his suggestions on how to possibly fix the errors. When all looked bleak, a simple last minute trial ended up being the solution. Chalk this up as a win for open science, and open notebook science!
Update: I thought it would be fun to show you my actual notes of the experiments which are usually short enough so that I can recall what I did in more detail for posting here as soon as possible.
It should be noted that this isn’t all the notes from my experiment, but just the ones that I definitely wanted to remember in detail. The remainder are just upwards of the frame edge but the earlier tests were an identical repeat of the tests shown under the page separation that I drew.
Today I ran the same reaction that I ran on Friday, this time I did two sets of reactions. One set, I put in the OpenPCR machine and the other set I placed in our Thermo thermal cycler. The image on the left shows the results. Lanes 1-5 contain the samples from the OpenPCR machine (Lane 5 also contains a 1kb ladder), and lanes 6-10 contain the samples from the Thermo machine. The bands are brighter towards the top than towards the bottom because I stained prior to running the gel (and the stain runs in the opposite direction from the DNA). I tried to post-stain for about 15 min to improve image quality.
Notice that the bands are all the same length and the same brightness, which was not the case in the reaction from last week. The spreadsheet of the reaction can be found below.
This reaction is based on the reaction for making the 1.1kb anchor used in the unzipping construct, which I haven’t discussed in this space, will in the future, and some background can be found on OpenWetWare.
This particular reaction makes a 1.1kb dsDNA product that is labeled on one end with a digoxygenin molecule and has no label on the other end. The reaction can be found here.
Several months ago, a colleague (Andy Maloney) found out about a movement to make an open source PCR machine (thermal cycler) and signed the lab up immediately to receive one of the first ones off the assembly line. It is produced by a company known as OpenPCR and was made by two amazing gentlemen (Tito Jankowski and Josh Perfetto) with support from a great community.
The machine itself costs $599 which is considerably cheaper then the cheapest options (a quich search revealed a low of at least $1500 new). It is a Do-It-Yourself (sort of) build with very detailed step by step instructions, which helps keep the cost low. Also the implementation of the Arduino chip also helps in the cost department but is also why OpenPCR can be completely open sourced.
Above is an image gallery of the build. I took a picture after I completed each section of the build instructions, which thankfully were meticulously detailed and very easy to follow. I liken it to building lego playsets in my childhood. Along with the detailed instructions, all the parts were contained in numbered and lettered boxes and bags (respectively) which would be called in the instructions. This made finding parts extremely easy and quick.
Once the build was complete the machine needed a quick power test and connection to a computer or laptop. The PCR reaction programs are set via this connection through a very elegant and simple user interface. If you are constantly changing programs the thermal cycler will need to remain tethered to the computer, but if you use the same cycle over and over you can unplug and the program will run when the machine is turned on again.
I ran a series of tests to determine the capabilities and consistency of the machine. They provide a simple program appropriately named “Simple Experiment” that will do two PCR cycles (90C, 55C, 72C) and hold at 20C to test the machine. There is even a heated lid which you can set the temperature of, a very nice feature. The software gives you great flexibility when designing a reaction program. You can adjust temperatures, time, cycles, add steps, remove steps, change the lid temp, and set the final hold temp (but from my own studies and from email communiques the machine can’t handle anything below 10C).
After running the “Simple Experiment” I discovered that there were some errors with the cool down and hold feature. In some cases the hold temp works just fine (unless the temp is set too low), in others the hold feature crashes and the machine will just naturally cool instead of being temperature controlled. In one (and only one) test, the reaction program restarted when the hold stage was reached and then initiated when that program ended.
Other than this one issue, I’ve found that OpenPCR is very consistent temperature and time wise. I ran a reaction that would cycle between 94C, 55C, and 72C ten times (for 30 sec each step), then go to 37C and hold there for 10 min, then hold at 20C. It seems to never accurately reach temperature (it goes to 90C but that may be an upper limit, then 55C, then 70C), but it is very close and perhaps close enough. The main problem like I said is the hold programming which in this data set does not work. After the 37C for 10 min the program ended and the heating block (where the PCR tubes sit) cooled via air conduction instead of temperature cooling. It never reached 20C.
Here is the link to the data.
Bottom line though is that OpenPCR works very well and the support staff (Tito and Josh) are very helping, knowledgeable, and open to improving the product. In fact I’m scheduled to meet with them via phone tomorrow to share with them all of my findings in gory details. I’ll let you know how it goes! Until then…