I was having the rather irritating issue with my Surface Pro where I’d hop on the train for my morning or afternoon commute, and the screen wouldn’t rotate (change the orientation) when I was trying to read with my Kindle app. What made it frustrating was that it’d start working again when I arrived. I read the troubleshooting document and then contacted Microsoft support and they weren’t able to reproduce the issue. This morning, I finally figured out what was going on.

More...

Several people reported that they had attempted to use the auto-update feature in the Vista ICM, and that doing that had removed the files required to display devices.

It seems the auto-update procedure is buggy and erases the flash storage before checking if it’s able to successfully load any available updates. Since the device has been discontinued and (I think) In2Networks has gone out of business (or at least has shut down the related servers). This means that the auto-update feature is now an “auto-destruct” feature.

My ICM was still intact (though I did have to factory reset it since it wasn’t responding), I did some hunting and pecking, and in the end I was able to pull out the files from flash file. I’ve attached them below. You can use the Advanced / File System page to upload and save them to flash under http://[ipaddress]/setup. As usual: Use at your own risk.

• devices.tar.gz
• style.tar.gz

Thanks to Norman for agreeing to be the guinea pig to test these files out!

Other

Now for some geeky stuff:

1. To download files from the device, you can create files in the /var/fusion/web folder. The other option is to create a symbolic link to an existing file. This is especially useful for larger files. You can then download the file(s) with a browser from http://[ipaddress]/web/[filename].

2. I wasn’t able to download all of the flash files. In any case they are in /dev/flash:

• all
• boot
• bootarg
• config
• ethmac
• image
• settings
• storage

The reason I couldn’t get some of the larger files out is that the embedded shell does not support IO redirection, so I couldn’t cat to gzip to minimize the size.

3. I pulled the devices.tar.gz and style.tar.gz out of a flash image located at /dev/flash/storage. Since they were combined in a flash image, I had to remove a few bytes of the header before the first gzip file, and then split it into two (one for styles and one for devices). A test with 7Zip on Windows said the files were valid. I was also able to use gunzip on the ICM to extract the contained tar. However, tar failed as it ran out of space about halfway through (normally they packages are on another disk so the extraction works when it happens on startup.

I spent a moment this morning slapping together another application for the Nexus Q. This one is really simple, and all it does is to use the LEDs to show the time. There are three “hands” that show the hour in white, minutes in blue, and seconds in red.

The video doesn’t do full justice to the ability to read the time. The camera picked up too much light around each hand due to the diffusion the LEDs have. For example, the second hand looks fully red in real life, and doesn’t have the rainbow band around it as seen on the video.

The QRemote REST API documentation is now bundled into the application itself, but here’s a copy/paste for reference.

More...

I just finished setting up a repo on GitHub for QRemote: https://github.com/docBliny/qremote

It includes the source for both the Android application and the web interface.

I also updated the installable APK with the rough API documentation.

UPDATE July 14, 2012: I updated the APK to contain rough API documentation. Just navigate to http://192.168.1.1:8080/api.html adjusting the IP address to match your Q.

OK, it’s late (I mean early), but here’s a very rough alpha version of QRemote which let let you control the Nexus Q via a RESTful-ish API and your web browser. It’s developer-only friendly at the moment, but that shouldn’t a problem since only Google I/O attendees have them. If you’re brave enough to test it and have feedback, hit me up via Twitter, Google+, or email. I’m lazy at approving comments here on the site. Anyway, to the point…

GALLERY

Here it is in all it's glory.

Installation

• Download QRemote.apk here.
• Upload the file using adb with the following command: adb install QRemote.apk

Running

Unfortunately, you’ll have to manually start the application every time you power on the Nexus Q. I’m working on to get the boot message receiver to work with a signed package (seems to work fine with a debug build).

• Start the application with the following command: adb shell am start -a android.intent.action.MAIN -n com.blinnikka.android.qremote/.StartServiceActivity
• Open up a browser and navigate to port 8080. For example, http://192.168.1.1:8080/

Known Issues

• You need to start it manually every time you power up the Nexus Q.
• You have to know your Q’s IP address.
• You need to load up a playlist with the Play application on an Android device.
• Videos are not supported.

Uninstalling

• Run the following command: adb uninstall com.blinnikka.android.qremote

Upgrading

You will need to uninstall and re-install the application if you had the initial Alpha version as I changed the keys used to sign the application. Just follow the instructions above to uninstall and install again.

The video says it all.

Here are a few random tidbits I’ve come across while messing around with the Q.

SPECS

• Operating System: Android 4.0.4 Ice Cream Sandwich (SDK/API 15)
• Processor: OMAP4460 (dual ARM Cortex-A9 CPU and SGX540 GPU)
• RAM Memory: 1GB LPDDR
• Flash Memory: 16GB NAND
• Connectors: TosLink (S/PDIF) audio, 10/100BASE-T Ethernet RJ45, Micro HDMI (Type D), Micro AB USB, Banana jack speaker outputs (2 right, 2 left, 4 total), AC power (Figure 8)
• Wireless: Wi-Fi 802.11a/b/g/n
• Bluetooth
• NFC
• Lighting: 32 RGB perimeter LEDs, 1 RGB status/mute indicator
• Hardware controls: Rotating top dome (volume control), capacitive touch sensor (mute)
• Weight: 923 grams (2 pounds)
• Diameter: 116 mm (4.6 inches)

Random Stuff

• Product name: Tungsten
• Device name: Phantasm
• Board name: Steelhead
• Bootloader: steelheadB4H0J
• The Nexus Q Android application is called “setupwarlock”
• It looks like the hardware and software might support up to 2048x2048 resolution
• Closed captioning works for movies (or at least the Transformers movie that was given away)
• iFixit teardown: http://www.ifixit.com/Teardown/Nexus-Q-Teardown/9636/1

Power Usage

I’ve only quickly looked at the power consumption, but my Kill-A-Watt shows between 2-3W when the Q is on and playing music and the same based on a quick test of movie playback. This is with Ethernet and HDMI connected. The numbers will obviously be higher if you use passive speakers and the internal amplifier.

This is just a quick post to list out the applications that I’m aware of that use the LEDs on the Nexus Q and their priorities within the system. The priority determines which application gets to control the LEDs at any given moment. Higher numbers represent higher priority. I haven’t looked at the code close enough to see how duplicate priorities are handled, but I’m guessing that that situation is not deterministic.

I haven’t put a lot of effort into verifying whether the descriptions match reality of what the applications do. I’m sure I’ve missed applications, too. Feel free to let me know if something is off.

Here’s a quick list of ways I’ve been able to control playback using the adb developer tool.

1. Send media key codes.
2. Send broadcast Intents.

The values for both options are listed in the following tables.

adb shell input keyevent 85

adb shell input keyevent 88

adb shell input keyevent 87

adb shell am broadcast -a com.android.music.musicservicecommand.togglepause

adb shell am broadcast -a com.android.music.musicservicecommand.next

adb shell am broadcast -a com.android.music.musicservicecommand.previous

adb shell am broadcast -a com.android.music.musicservicecommand -e command play

adb shell am broadcast -a com.android.music.musicservicecommand -e command play

asb shell am broadcast -a com.android.music.musicservicecommand -e command stop