Wednesday, April 04, 2012

If Tax Prep Options Were Airlines

1040EZ Airlines
Upon your arrival at the airport, you are given a red Radio Flyer wagon with the airline logo on the side, and a bag of peanuts.


Private CPA / Accountant Airlines
You book your own private jet.  The pilot meets with you and then decides how you are going to get where you are going.  Because of a ton of transportation regulations, the route ends up going half way around the world, and stops at 18 airports before you finally arrive back at the place you actually started from.  All of the ticket price is refunded, and you walk away bewildered and empty handed.


H&R Block Airlines
You line up with other passengers at the front door of the aircraft.  Eventually the flight attendant comes the door, and directs you to a seat.  The seat is a perfectly square box with only enough room for an average size man or woman.  Depending on your luck, the pilot is either a seasoned, ex-NASA aeronautics expert, or a nervous young pilot fresh out of flight school.  When the plane takes off, it goes directly to Kansas City, MO, regardless of where you bought your ticket for or how much you paid for it.  When you land, you're told that you owe thousands of dollars for your ticket, with no explanation given as to why.  Everyone is given a folder, business card, and a mint as they deplane.

TurboTax Airlines
You walk down the jetway and are shown into the cockpit of your own plane.  You are told you will be flying the plane yourself, however, instead of touching any of the actual controls, you will be just be interviewed by a computer program written by an ex-pilot.  As you fly, the computer program asks questions like "Where did you fly last year?", "what does the gauge labeled 'airspeed' read right now?", and "do you see any other planes in the sky?".  As the flight progresses, the altimeter reading varies all over the place from -10,000 to 30,000 feet, seemingly without any regard for what's actually happening to the aircraft.  Finally, either you safely land at the airport and are given thousands of dollars for reasons you don't fully understand, or the plane runs into the side of a mountain.

Sunday, April 01, 2012

Unleash Your Galaxy Nexus Screen: Tweak Auto Brightness

When I was shopping for my next phone, one of the main selling points of the Galaxy Nexus was its beautiful SuperAMOLED screen.  Because the screen pixels are actually light sources (as opposed to a more traditional LCD in which a backlight is filtered by an LCD screen), the contrast ratio and color vibrance are theoretically unmatched.  So why is it that, weeks after getting my long awaited gem, my assessment of the screen is that it is more lackluster than my 3 year old Moto Droid?

The answer lies in the combination of two factors:
  1. Different colored LEDs respond differently to various power levels, in terms of their brightness.
  2. The default screen-brightness-to-ambient-light mapping offered by Ice Cream Sandwich on the Galaxy Nexus (in auto brightness mode), is inadequate.
Here's the proof:  Turn your display brightness all the way up instead of using auto mode.  The screen looks beautiful, the colors are vibrant, and the promise of the SuperAMOLED screen is realized (not to mention that you can actually see the screen reasonably well in sunlight).  Ok, so it's probably not appropriate to leave your brightness cranked all the time, for a lot of reasons, but it's clear enough that there is a different world. 

So what's going on here?  Let's look at item #1 first.  Different colored LEDs respond differently to various power levels.  The reason for this is that different materials are used to create each color, and each respective material has a fairly unique, non-linear brightness curve.  So lowering the power going into the screen means that the colors will not be dimmed uniformly, causing color distortion.

#2, the auto brightness mapping just doesn't seem to cut it.  This is a complaint I have had with all of my Android phones, but this one is especially pronounced, perhaps because of the LED display.  The screen is very often too dim for a given situation.  The ambient light sensor is extremely directional, and if you are standing outside on a bright day, the display will very often switch down to around 50%!  This is unacceptable.  The other symptom this creates specifically on the Galaxy Nexus, is a dull and unremarkable screen color (greenish or yellowish tint, with reds and blues being very subdued).  In practice, it very rarely, if ever, actually gets to full screen brightness, which I found quite annoying.

My theory is that Google errs on the side of conservation in order to protect battery life.  However, in the face of some of the other battery drainers, and the rate at which they can consume energy, this seems like a drop in the bucket.  For me at least, I will take this small hit so that I can appreciate my phone when I am using it.  Let's talk about options.

Option 1: Leave your screen on full brightness all the time.  While this is certainly an option, this will have an unnecessary impact on battery life. Furthermore, this would be obnoxious when it is actually dark out. 

Option 2: Remap the brightness the way it should be.  This is possible with a custom ROM, such as Codename Android.  Codename Android's MO is to start out with all of its customizations the way they would be in stock ICS.  After that, the ROM allows you tweak lots of things, including the auto brightness mapping.  This does mean you will need to backup your phone, unlock it, root it, and install a custom ROM.  That's more than I want to get into on this blog post, but there are plenty of resources out there to get you started.

What I will offer is a brightness mapping that I have created, tested, and found to be very reasonable.   It's much simpler than the stock mapping, which has something like 20 discreet levels (which just seems like nonsense to me). 

First, you need to turn on the features of Codename Android to better manage the brightness.  Go to Settings->Interface (under CODENAME)->Automatic Backlight.  Enable the first checkbox, under "LIGHT SENSOR FILTER".  This will provide a moving average of the light level, which will help with the highly directional nature of the ambient light sensor (ideally, an actual ambient light sensor would be omnidirectional, but that's difficult to design into a device that is flat.  A better design would have a small semi-spherical protrusion, but I digress).   Change window length to 30 s.  This means that it will take 30 s before the light level perceived by the device is what the senor reports, assuming it stays the same for that long.  Until then, it will ramp up or down slowly to meet it.  Change the sample interval to 2 s, since it really doesn't need to be faster.

Next, let's edit the mapping.  Go to "Edit Other Levels..." and you will see a map of lower, upper, screen, and brightness.  This may look a little intimidating, but it's really simple.  At the very top, you can see what the sensor is actually reporting (raw), what the current average is (filtered), and what the resulting screen brightness is.  I believe "buttons" is reserved for devices that have separate backlit hardware buttons, as opposed to the onscreen ones that the Galaxy Nexus has.  We'll leave those alone. 

Push "set number of levels" and change to 7.  Now push each button for "lower" on the left side, and enter the numbers as shown above.  Then select the screen levels for each range and, again, enter the numbers as shown above.

Don't forget to push "Save and apply".  You may wish to make tweaks to the suggested levels, which you can do at anytime by coming back to this screen.  My advice is to note the sensor reading under "raw" when the screen brightness is something other than what you would prefer, and then you can modify the brightness for that range, or adjust the ranges themselves as necessary.

Now enjoy your Galaxy Nexus screen, the way everyone should have been able to from the factory!

Thursday, March 29, 2012

The Connection Between ICS, Battery Life Issues, and VOIP


Most of the smartphone owning population doesn't know or care about VOIP, or Voice Over IP.  They get phone calls through their cell provider (not to mention the phone itself), solely over cell tower signals, and that's that.  But as some know, there is another dimension to calling, and that is the world of VOIP.

VOIP allows a phone or computer user to make and receive phone calls over any medium that can carry IP.  This includes not only your 3G/4G data plan, but via a Wi-Fi signal at home, work, or in many public places.  It also means that you can make and receive these phone calls without necessarily being tied to a certain company or contract.  You can even use your own hardware to host these calls, and connect these calls to the outside world in a variety of ways in an openly-competitive market (in contrast to the world of cell carriers).  In short, VOIP is most likely the future of all calling, though the cell carriers will do their damnedest to delay this inevitability as long as possible.

As an Android user and VOIP fanatic, intrigued by the possibilities of combining cell and VOIP for the ultimate voice connectivity, I am constantly fiddling with my phone settings, and trying what most would consider to be "experimental" configurations.  Besides my usual cell phone number and contract, I have had at least the following VOIP connections configured on my phone in one form or another, since I got my first Android phone 2 years ago:
  • SIP connection to a cloud hosted PBX (PBXes.org)
  • Google Voice via Groove IP app (VOIP over Google Talk/Jabber/XMPP protocol)
  • SIP connection to my home Asterisk box server 
  • SIP connection to various other Asterisk boxes, such as those built for clients, test and demo units, etc.
  • Maybe some other stuff that I am forgetting
On Froyo and earlier, I used to use a third party SIP client (namely Sipdroid), as that was the only option.  I remember when Gingerbread came out and had native SIP support.  I was rather excited about that, since it meant two things:

  • As a memory starved OG Moto Droid owner, I was hopeful that this might offer a way to support my SIP habit without having to keep a 3rd party app running background all the time.  It also would be a little more elegant/less clunky.
  • Obviously this was a step forward for the VOIP world, if Google felt it was worthy enough to build it into the OS.
So since Gingerbread came out, I have been using the native SIP client on some level.  It's always worked pretty well, albeit with some reduced functionality and configurability (without getting into too many specifics right now), but simpler is sometimes better anyway.   All of this worked pretty well, on my OG Moto Droid running Gingerbread.  My phone would connect automatically to my home asterisk box when I got home, so I could use my phone like a cordless extension.  When I was away, the local IP address would be unreachable, and it would automatically disconnect.  I also had my work number through PBXes.org, and I had configured SIPdroid to connect to that.

Over the last few months, some things have changed.
  1. I switched to GrooveIP exclusively for my work number
  2. I decided to stop using a 3rd party SIP clients
  3. I moved our home number to the PBXes.org cloud PBX
  4. I got a Galaxy Nexus running Ice Cream Sandwich
I'm not sure about the exact order in which all of this stuff happened.  I had about a month or so of good time with my new GNex, but at some point, this is what I started having:


That's my phone chewing through over half the battery life in under 4 hours.  The only information I could get from the phone about why this was happening:


"Android OS".   Not very helpful.  After searching, searching, searching, online, I only found that other people were complaining about the same exact thing, and that this appears to be referred to in the singular as "the ICS battery bug/issue".  So that's what I had to work with.  With many different apps that are part of my regular Android setup, finding the culprit was like looking for a needle in a haystack.  The only other clue I had was this:


On Wi-Fi, the battery consumption was much BETTER, even normal(-ish).  At least what I would consider normal for a modern, powerful phone.

I spent the next month or more trucking around my charger and 2 spare batteries just to keep my phone running while I was traveling.  The phone would get extremely hot in my pocket, to the point where it was uncomfortable to even keep it there!

I decided that I wanted to unlock & root my phone, and install Codename Android (a highly customizable ROM for the Galaxy Nexus).  My reasoning was varied, but mainly I got tired of waiting around for updates. To my knowledge, Verizon still hasn't issue an update from 4.0.2, which has an NFC tag formatting bug, and some other known problems.  Having a custom ROM that is updated often gave me occasion to format my phone on a fairly regular basis.  I noticed the problem came back after I formatted and installed the latest version of ICS (4.0.3).  After a couple more tries, I eventually broke up the initial setup of all my config and apps into 3 or 4 parts.  Between each part, I would give it a rest and see if it had the issue. By process of elimination, I found out that it wasn't any of my apps at all that triggered this problem, it was my configuration of the native SIP client in ICS.  Furthermore, it was the native SIP client's connection to PBXes.org, which is maintained regardless of whether I am at home or away, connected to Wi-Fi or not (cloud connection).

Before I go any further, I should point out that I DID check the box that reads "receive incoming calls (reduces battery life)", so I suppose I asked for it on some level.  Also, I guess someone could also point out that it really was "Android OS" that was consuming all this battery life, so the chart wasn't lying.  However, I'll point out that this is not the first time I have configured my Android phone this way, and I never witnessed this issue when I was running 3rd party SIP clients.

So to wrap it up, I have reached the following conclusions:

  • Something about ICS uses a ton of power (at least as compared to 3rd party SIP clients) when the native SIP client is maintaining a connection over 3G/4G, but not when using Wi-Fi.  
  • Google really needs to break up the Android OS category in the battery usage report a little bit, so that users can see whether/which something that they have control over is consuming battery %.  There are lot of other people trying to figure out what the heck in this category is causing their problem, and it's causing a tough PR issue for ICS.
  • There really should be an option in the native SIP client config not to connect over 3G/4G
  • SIP was not designed to be used over 3G/4G data connections.  It is a busy protocol, sending keep-alive packets every 30 seconds or so, constantly using the radio and keeping the phone awake, even when there is no call going on.  The future of mobile VOIP will not necessarily be based on SIP/RTP (and probably won't be).


I am back to running a 3rd party SIP client, CSIPSimple, and excellent and highly configurable SIP client that allows me to better control when it connects to my cloud PBX.  Since then, my battery life is back to "normal".  On an average day, I use my phone 10-14 hours and I still have at least 25% battery left when I put it on charge for the night.



One more conclusion I reached: the world of mobile VOIP still seems to be in its infancy, as I could not find one other report of someone connecting the infamous "ICS battery bug" to this issue.  If a lot of people were using the native SIP client in Android, I would think this information would have been much more accessible.