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.


Tuesday, February 14, 2012

AT&T Throttling Their Top 5% Unlimited Data Users

You may or may not be aware of it, but there have been reports that AT&T is throttling their "Unlimited Data" customers, essentially making a limit of a supposedly "unlimited data plan".

This has been a long time coming.  Last year, AT&T and Verizon Wireless began forcing new users into tiered (limited) data plans, with a certain amount of data allowed per month.  The typical allotments are 500MB, 2GB, 5GB, 10GB, etc.   The price of the plan rises with the amount allowed.  Meanwhile, old users are supposedly "grandfathered" into the unlimited data they signed up for.  Apparently, AT&T has decided that there needs to be a certain amount of pressure to steer people in the direction of tiered data plans.  I haven't heard of anyone having this experience with Verizon Wireless.

As a side note, I find it interesting that people use that much data on their phones.  As an example, I consider myself to be a smartphone power user, and my cell data usage is somewhere between 500M and 1GB a month.

On one hand, I think a lot of new smartphone owners are prone to much higher cell data usage than they actually need, because they don't bother to set their phones up to use their own WiFi connection at home.  Going by my own experience, I've had 3 users in the last 2 days tell me they didn't even know that was possible, let alone preferential.  At the risk of sounding like I am inciting a holy war between Android and iPhone (trust me, plenty of others have done this for me, thank you very much), I'll also point out that they were all iPhone users.

On the other hand, in fairness, I don't have 4G coverage, and I don't watch Netflix on my phone when I am not at home.  Also, after some quick research, most of the major data consumers do appear to be Android users, and that makes sense when you consider that the iPhone doesn't have access to real 4G networks.  I got a chance to play around with 4G the other day when I was out of Vermont (see my previous post about Vermonters being Verizon Wireless second-class citizens), and my first thought was, "Wow, look how quickly I rack up some serious data usage!"  Not having to wait for anything removes all of the subconscious internal limiters I have about using certain functions (or, put simply: my phone is more fun to use!)

I still think there are a lot of people using cell data when they don't need to, and as smartphones become more and more accessible, this issue will become more of a trend.

Saturday, December 17, 2011

A Second Class Citizen at the Verizon Wireless Store

A couple of days ago, a new, large Verizon Store sprung up down the road.  At about the same time, Verizon finally announced the availability of the new and long awaited Samsung Galaxy Nexus phone - The phone that was hyped by Google and Samsung in early October, announced in Late October, promised to be released in November, and then delayed and delayed until the middle of December.  It's been all over the news and in people's faces.

I figured the timing was no accident, and sauntered in to see if I might be able to have a look at this Ice Cream Sandwich laiden beast.  To be honest, I was half expecting them to tell me they didn't have one.  As a Verizon Wireless customer in Vermont for over 15 years, I've gotten used to being a second-class citizen.  We are the usually the last to get network upgrades, good stores with good phones, or sales people who can handle technical questions.

I walked in and quickly surveyed the store, before I was immediately swooped down upon by an overly-smiley sales lady.  The first red flag: all of the showroom phones were phonnequins (faux plastic mock-ups with stickers instead of a real display).  There were no functional units anywhere.

I asked her if I could see the new Samsung Galaxy Nexus, and she said "sure". She "just needed to know my account info", so she could look it up.  This was new and weird to me, as all I wanted to do was look at a phone.  I gave her my account info, and she returned a few minutes later with a brand-new-in-box Galaxy Nexus.  It had never been opened (and, as you may have guessed, was not activated).  She took it out and fiddled with the phone, which was sitting at the activation wizard.  She tried to subtly ask her colleague what the "unlock code" was for the phone (lol). Unsurprisingly, he was not much help.  She then cheerfully handed me the phone, saying "well, at least you can get your hands on it!".  Today would not be the day I would get to play with Ice Cream Sandwich.

As I inspected the phone's physical attributes, namely its bigness in the hand, and the appearance of its SuperAMOLED 4.65" high def screen, the sales lady pointed out that it was about the same size as the Samsung Charge, but, and I quote, "the big thing with that is the face unlock."  I almost burst out laughing, but she was serious.

I'd had all I could take, and I got out of there as fast as I could.  I think I'll wait until one of my friends gets a Gnex so I can look at it for real, since I apparently can't see one at my local Verizon Store.  Wait, what am I thinking?  I can just download a face unlock app to the Samsung Droid Charge, and I'd basically have myself a Samsung Galaxy Nexus!

Congratulations, You're BLACKLISTED!

A long time ago, I posted The Trouble With Greylisting.  My latest rant is brought to you by the current state of e-mail server blacklisting.  I'll relate to you the following anecdote, to help with the specifics:

My client recently purchased a new internet pipe from their ISP - (I won't specify, but let's just say they're "Vermont's largest wireline provider.")  Along with this new connection came a new block of public IP addresses.  This has been standard fare - they have switched connections 3 times in the last 2 years, and for a variety of reasons, each time it's been a fiasco to get everything migrated to the new block.

This time it almost went incredibly smoothly (without question, this was at least partly due to the help of an Astaro Security Gateway, and its almost infinite flexibility).  The only snag was when I moved the mail server over to the new IP block.  Within 20 minutes, people were reporting bounces (undeliverable message reports).  The new IP address was blacklisted for sending spam.  I moved the server to another IP in the block, and an hour or so later, received another report of the same issue.  For the record, this server is totally clean, and sends maybe 50 totally legit messages an hour, during peak.

The only explanation is that some (perhaps all?) of the IPs that were given to us were previously used by spammers.  As I played the scenario through in my head, it all made sense.  Due to the severely overtaxed IPv4 address space, addresses are constantly recycled.  Furthermore, every IP address in that space has probably used by a spammer at some time or another, given the number of spammers in the world.  Ok, perhaps that's a bit of an exaggeration, but still...  It was enough for me to get the picture.

I moved the mail server back to the known good IP, and then set out to start the long and arduous process of delisting all these IPs.  Even though I don't plan to use more than one for sending mail, I need to have options, as obviously I can't predict what is going to happen to my IP reputation, regardless of what is actually my fault.

Throughout the process, one interesting thing I got to see was the variety of different types of blacklists out there.  They range from reasonable and responsible (think Spamcop), to strange, and obscure.  Some blacklists are very straightforward about removal requests.  The policy is simply "check yourself, and then click the removal button."  Some blacklist providers investigate reports of spam before listing a host.  However, the lower end providers take a very lazy approach to blacklist management.  They blacklist everything based on loose criteria, don't expire anything, and make it very difficult for hosts to request removal.  One delisting form was actually punctuated with a lecture about how

So, to review, we have 2 problems:

1. (some) ISPs sell IP blocks with no guarantees about the reputation of IPs within that block

2. (some) Blacklist providers use lazy tactics to manage their lists, including listing without due process, with complicated and indefinite delisting requirements, and without expiration of highly outdated listings.

With these 2 factors at work, it's a very disconcerting direction for private mail hosting in general.

Monday, October 24, 2011

Whether Steve Jobs Liked It Or Not, Apple Created the Market For Android

As Steve Jobs' authorized biography is released, we are getting some of the first public looks at his perspective.  I'm not surprised to hear about his view of Android as a "stolen" product.  Android is a smartphone OS that features a lot of the same usability aspects as the iPhone OS.   However, the reality is that Android fills a need that the iPhone's closed architecture doesn't: The freedom to run almost anything you want on the device you own.  Apple created the market, now largely owned by Android, when they decided to withhold that freedom from their developers and users.



What does Suno mean for us producers & musicians?

 I've been thinking about this for a month or two now, and there is still a lot to process (obviously).  In a way for us musicians and p...