I’ve been thinking hard about selling it because I didn’t think that rooting it and installing a tweaked ROM was going to be enough to fix it. I decided to try anyway with the new Android 4 (ICS) release. It only took about five minutes using the Xoom with ICS to realize how wrong I was and how good Android 4 is for the Xoom. Everything is better.

As usual with hacking all things mobile, you will be heading over to XDA if you want your Xoom to behave like it should. I’m writing a quick tutorial here since the information is pretty spread out on XDA. I had a couple issues that had me searching through pages of threads, so this is what worked for me.

Step 1: Unlock your Xoom. You can’t do anything until this is complete, and in the process it will void your warranty and wipe your device. Back up any important data first. The instructions on unlocking your Xoom are here. After you install the Android SDK, you will need to install the Android tools and a platform (4.0) from the SDK manager. This will install fastboot, which will be in the platform tools folder you installed. You will run a command window in the folder where fastboot is located in order to send the commands to the device.

Step 2: Install a new recovery console. Use the instructions here. Use the non-CWM method. You will be sending it through adb and the command window you used earlier. There is a trick though: you can’t reboot into recovery with the adb commands unless you are already rooted, and if it’s your first time you obviously aren’t. So instead of rebooting via the fastboot command, reboot by pressing the volume up key and the power key until the screen goes black. Then count for 3.5-4 seconds after you see the Motorola logo and press volume down. “Android recovery” should appear on the screen. Press volume up to select. If the next screen you get is an Android robot with an exclamation mark, you pressed volume up into recovery too soon. Reboot, reflash the recovery file, reboot, and try again. When you get the timing right you will see the ClockworkMod screen and the recovery console.

Step 3: Root your Xoom. Once you can get into the CWM screen at will, download and install the Universal Xoom Root zip file from here. You now have control of your Xoom, it’s time to load new software on it.

Step 4: Install a new ROM. Download the latest ROM and Google apps package from here. This is the team EOS ICS ROM, you can pick from any ROMs available on XDA at this point though. Furthermore this is the wi-fi only Xoom ROM (MZ604). If you have a 3G/4G device you will need to get the appropriate ROM from XDA. Place the two zip files on your SD card and install as before, but make sure you do a factory reset first and clear the caches. After you have installed the two zip files, reboot and enjoy your Xoom.

As usual, do this at your own risk. You can ruin your device if you mess something up. If you aren’t sure about what you are doing, head over to the XDA Xoom Android development forum and start reading. This tutorial isn’t a substitute for any of the information at XDA, just a sequence of events that makes first time rooting a little easier to understand. Much respect to the developers at XDA for making this possible. Good luck!

This review will cover getting the SKDE up and running with the TCPIP Demo App from the application libraries in MPLAB X.

Download and install:

Java

MPLAB X

Microchip Application Libraries

When you run the CD that comes with the ethernet starter kit, you will have an option to install from CD. This will also install MPLAB 8. I couldn’t find a way around doing this, as the driver for the board is buried somewhere in that install. It won’t install the starter kit otherwise.

When the install is completed, start the driver switcher application from the Microchip program directory. Select PIC32 SK, and the radio button to configure for MPLAB X. Apply the setting and wait for it to complete. Then launch MPLAB X. Select Open Project from the file menu. Navigate to the Microchip Solutions directory, then TCPIP, finally select Demo App and MPLAB X. When you open the project it will start loading. It takes a while since the code stack is large. When it loads set the project configuration to the ethernet starter kit (C32-PIC32_ETH_SK). Finally you should be able to build and load the project to the target.

Once complete, plug the ethernet port into a router, where it will get an IP address. Logging on to the router will let you see attached devices and find the assigned IP. You should be able to put the IP in your browser now and see the Microchip demo page.

There are video tutorials on Microchip’s website that detail the dynamic webpage capabilities of the device. The demo application supports a lot of processors and protocols, so my next task will be to dig in and figure out the smallest code necessary to just run HTTP on the PIC32.

I did some more digging and figured out that the router doesn’t really have a WAN port, despite the port on the back being labeled as such. The switch controller is actually a six-port controller, and only five are used. Even though the WAN port on the router is physically separated from the other four ports, the switch controller sees it exactly the same as the rest. All five of the ethernet ports on the back are auto-sensing ports so any one has uplink capability. The polarity of the connection is tested during link or when more than three packets are received with inverted end-of-packet pulses. If any of the ports exhibit this behavior the switch controller reverses the port polarity and stores that status in a register. That port then becomes an uplink.

What I figured out was that if the switch ports are used for other devices, the router will eventually fail to uplink. That is, if you use it as an access point instead of a router, it’s fine. When you start using the  switch ports it gets confused. I have successfully had the router running for a while by connecting my wired devices through a switch and then uplinking just the switch to port 2, with the router then uplinking to the gateway. Evidently the router’s processor has an issue with its mapped memory.

I’ve now bought a Linksys E2500 wireless N router to replace this thing. You can get refurbished wifi routers at Cisco’s store for about half price.

The product is based on a PIC18, with an FTDI FT232R serial to USB converter. Use FTDI’s driver when you connect it to your PC though. I used the driver included on the CD that came with the tool, and it enumerated as a “high speed USB serial UART” and wouldn’t communicate.  I had to use FTDI’s driver removal tool to get rid of it so I could reinstall the correct one.

I tried the device on my truck with a couple different software programs: ScanTool.net, OBD2Spy, and wOBD. However the results were underwhelming, as I got two different sets of codes with the first two and the last program wouldn’t communicate with the tool.  ScanTool.net reported P0403, P0405, and P0460. OBD2Spy gave me P0204, P0304, and P0500. Obviously that’s not very helpful.

So I opened up the ELM327 datasheet and Realterm.  Realterm is always my favorite terminal program, but in this case I had to switch to Hyperterminal since Realterm doesn’t have the “Append line feeds to incoming line ends” feature. Realterm overwrites everything from the device on the same line.

I started with a simple protocol test, to make sure everything is working. Then I tried pulling PID 05, which is coolant temperature. It responded with the proper value. So I moved on to checking the number of codes. There were two. Finally I pulled those codes. They turned out to be P0204, P0304, and P0500. I’m not sure why the ECU thought there was two codes but listed three. Anyway, OBD2Spy gets the nod here. If you look at the output you can see that the other program was off by one byte, which is why the codes are similar but incorrect.

So the emulator works as advertised, at least in this test. The next problem though is that there are only a handful of previously defined PIDs that auto manufacturers use so that they can get diagnostic tool companies to pay for the extended PIDs required to actually do any useful troubleshooting. In order to get real-time data of detailed systems, you have to pay for software that has the extended PIDs.

I used a dremel this time instead of a router, since the router was pretty much overkill for engraving anything. I made a mount for the dremel by cutting up the little plastic guide that comes with it. It has an approximate O.D. of 1″ and acts as a nut that you can clamp with a shaft collar, and still unscrew the dremel from the mount if you need to get it out. I welded the shaft collar to a stainless steel bracket.

I haven’t made any boards yet to see if the dremel has much z-axis play.

There’s nothing special about this machine electronics-wise. Since I have NEMA23 steppers and 16TPI lead screws I don’t need a really high voltage drive or anything special. I’m using a 24VDC linear power supply with two automation direct stepper drives and one from Schneider. I didn’t connect the home and limit switches as I don’t think they have much value on machines this small. It’s a lot of work to do proper limit switches that disable the drive and signal the controller that a limit has been reached. Also to have home and limit switches on each axis you need two parallel ports. TurboCNC, being run in DOS, can only use the onboard parallel port so you can’t use PCI parallel port cards with TurboCNC. Only Mach3 can recognize inputs on the extra card since it’s address will map outside of the legacy range.

Recently though the connection speed over wifi plummeted. I was going to buy a new wireless AP, but I’m pretty cashed at the moment so I took the router apart to see if I could buy some time.

You could pretty clearly see that the microprocessor has overheated. The conformal coating is brown on the bottom side of the PCB. I used an infrared thermometer to measure the temperature of the chip, it was running at about 74°C. The ethernet switch controller IC had a similar temperature, but it’s a larger leaded package whereas the CPU looks like a BGA package. I had some memory heatsinks that I cut to fit the two chips, and with that and some thermal paste I had heatsinks for the two heaters in my router case. They are low profile enough that the case will still go on.

My router works like it should again: speedtest.net reports an average of 18Mbps download speed. The heatsinks keep both ICs at about 49°C now. Guess I won’t need that new AP for a while.

It’s pretty straightforward, there’s three metal contacts. The lowest one is ground, the next one is prefocus, and the last one is the shutter release. The signals are active low. I wired the three to a headphone jack on the bottom of the remote. To test it out I bought a ten dollar motion sensing security light and took out the motion sensor, then wired the output of the sensor to a 120VAC relay. The relay contacts trigger the shutter whenever the motion sensor sees anything.

You can use anything with a switch contact to trigger the camera, just remember that it’s not protected. If you mess up, you can easily fry your camera. Look for “dry” contacts if you are unsure. Canon DSLRs might allow for transistor pull-downs, but I haven’t tried that. It’s easier to just create an isolated contact through a relay for the safety of your camera.

So this got the lights working. Unfortunately, they aren’t all that simple to work with. The earliest version of Alienware’s command center works and allows you to set the colors, fades, etc. It won’t write to the AlienFX EEPROM though, and later versions of CC can’t communicate with the AlienFX board at all (This is a pre-Dell Alienware machine, the Dell version has different hardware). The lights are controlled by this AlienFX board (which I’m guessing lives on the motherboard), which enumerates as a USB device. Once you have an OS installed, you can try and write directly to the device. I haven’t been able to get successful EEPROM writes to the device though, and since I hacked the registry on mine to get the backlit keyboard working, the colors flash somewhat randomly during boot until Windows loads and starts the AlienFX software. Then the lights resume doing whatever you set them to. Evidently it’s writing stuff to the EEPROM, but it’s just not the right stuff.  I tried using AlienFX Lite from notebookreview.com, but I only get an error message that the packet was the wrong size.

Since I had to add a couple registry keys and reboot to force the BIOS / AlienFX controller to recognize the keyboard, I’m guessing there is another key that I’m missing to get the board to recognize the proper programming sequence. Or maybe I need a different BIOS, but I can’t find one for this older version of the m15x. I suppose I don’t really care at this point, since the FX does what I want in Windows anyway.

The only thing I’d like to fix is that with CC A03 the power light flashes off briefly every time it repeats the color cycle. It gets pretty annoying looking at the screen when the power light just below it is monotonously flashing. The way I get around this is by creating a bunch of themes in A03, and then uninstalling A03 and installing A05. A05 automatically picks up the previous theme, and uses it. If you start the AlienFX editor it crashes, so if you need to edit one of your themes you have to install A03 again. You can also edit the script but it’s cumbersome.

It turns out that the CCD wasn’t what was wrong with my camera though. Canon repaired a slew of these cameras saying that some of the CCDs they sourced were faulty. On my camera the problem was the connector on the mainboard for the CCD, not the CCD itself. The latch that locks in the CCD’s flexible circuit board was incredibly frail. I figured it out by powering up the camera while I had it apart and lightly pressing on the CCD connector. I ended up fixing it with a small piece of foam. There is just enough of a gap between the flash memory housing and the CCD connector to wedge a bit of foam and keep the CCD circuit board contacts securely connected.

The video embed didn’t seem to stay so here is the link to the video instead: http://youtu.be/9Znno5MhP2k

Of course you can always find my videos at YouTube from my channel, imsolidstate.

It’s not too hard to fix. You have to get some of the plastic covers off of your Keurig though. You will need a philips screwdriver and a T15 Torx driver. All of the Keurigs are a bit different on the outside, but they all appear to have the same mechanism for handling the K-cup. So your covers might be different but the internals are probably the same. Take the covers off so you can get to the internal plumbing. 

Now that the covers are out of the way, remove the two screws that hold the top needle assembly in place, along with the two screws holding down the clamp for the silicone tubing that connects the needle to the check valve. Next work the silicone tubing off of the check valve. The needle assembly should come out now. You don’t need to do anything special here, just run the needle under the faucet and watch the coffee pour out. Now put it back together. Brew some coffee and go back to your day.

Of course, you do this at your own risk and I take no responsibility if you break your Keurig. If you aren’t comfortable taking apart your Keurig, return it for replacement or repair. Or buy a Tassimo which is a better machine anyway.

This only took me about twenty minutes to figure out so it wouldn’t be too big of a deal to have to do this every couple months. However, I’m guessing that closing the lid slowly would reduce the amount of coffee making it’s way into the water line. If the pressure is allowed to escape before the needle is fully inserted into the cup it might help. [edit: Thanks to Lindsay, who identified the best solution: manually press down on the k-cup to puncture the bottom before closing the lid. I've also guessed more recently that this might only be a problem for those of us living at high altitude, since most packaging is positively pressurized by the time it gets here.]