T-mobile Roaming in Japan

I was traveling Japan earlier, from March 23rd, to March 30th. This was my first time traveling with my phone set to roam. The last travel before that was precisely 7 years 1 month 24 days before this trip, and I did not roam for two reasons back then; one it was cost prohibitive, and secondly, back around that time, I did not have a phone capable of roaming; back in time, I was using T-mobile MDA, essentially a renamed version of the HTC Wizard, which was an EDGE capable, which basically meant there’s no roaming available in Japan. (Japan is one of the few countries out there never had seen GSM deployment.)

Forwarding the clock for 7 years 1 month, 24 days, now I have a Nexus 5, which supports LTE and UTMS. This meant finally I am capable of trying out roaming in Japan. Coincidentally, as a part of T-mobile’s Un-Carrier initiative, they have made available free roaming (albeit with some limitations) available to simple plan subscribers, which basically gave me a chance to try it out.
The premise is that, I get data and text roaming free of charge (data locked to 128Kbps) and calling at $0.20/minutes. Latter pricing is not actually too bad, as some of their domestic plan can come very close or even exceed that at high margins. (For example, Softbank would charge 20 yen — roughly 17 cents per 30 seconds in their White Plan, and DOCOMO would also charge up to 20 yen, but generally more like 11 to 15 yen, that’s 9 to 12 cents. Although in Japan, receiving the call is free as a caller actually picks up that bill, but in case of roaming, both making and receiving a call incurs charges, just like they would in domestic calls in the US.)

Getting off the plane, I have waited for a while, until the phone receives signal. Actually the phone force restarted, but it probably has nothing to do with the roaming; perhaps it’s something to do with the Android 5.1 issue, but once that’s over, it was a fairly smooth ride. The phone received a signal, showing JP DOCOMO as a carrier. Then I received the following two messages from 156 number:

Free T-Mobile Msg: Welcome to Japan. Unlimited text incl with your global coverage. Talk $0.20/min. More info http://t-mo.co/tc

Free T-Mobile Msg: Unlimited web included as part of your global coverage. To purchase high speed data please visit: http://t-mo.co/4G-Data

After a while, I have also received the following from 889 number:

Free T-mobile Msg: For faster web browsing, you can purchase a high speed data pass at: http://t-mo.co/4G-Data

The data pass, which I did not purchase, comes in three increments: 100MB for $15.00 (expires in a day), 200MB for $25.00 (expires in a week) and 500MB for $50.00 (expires in two weeks) — again, I did not purchase these so I can’t speak of experiences using those add-ons. These are still bargains, considering non-simple choice plan would incur $15.00 per MB. While connected to Japanese network, it was locked to UTMS. I am not sure if it’ll be the case with these optional packages or whether purchasing one of these options would unlock access to LTE network.

Pulling IP address of the device showed that it was T-mobile USA’s IP range, which was not surprising considering the packet would still go through their access point, even though it is piped through Japanese network. At 128Kbps, I was worried that my data experience suck, however, it handled fairly well, especially after I turned off most of background backups of photos. It handled things like Facebook post, and Instagram fairly well.

Messaging applications naturally did not have any issues. One thing I noticed is when I jumped from one carrier to another (the network I could roam was on DOCOMO, as well as Softbank) and occasionally, especially when I was emerging out from no-signal area to coverage area, for some reason, it took a while to phone to realize that I have a data connection. This intermittent connection issue was somewhat annoying, but not critical for most of my applications.

Google Maps operated and helped a lot navigating a massive network of Tokyo train systems. Browsing experience was not too bad either; this probably also have helped by the fact that Google Chrome compresses data for me in the background.

Softbank and DOCOMO mobile cell towers -- my device probably roamed both of those towers at some point!
Softbank and DOCOMO mobile cell towers — my device probably roamed both of those towers at some point!

In any case, having some form of connectibility was way better than having nothing, and the first try with T-mobile free roaming was a very pleasant one. Now I can’t wait to go back again! 🙂

Google Camera Depth Map Collection

Some pictures interpreted by Google Camera

You can extract these using the following:

exiftool -X -b $1.jpg | sed -n -e 's/.*<XMP-GDepth:Data>\(.*\)<\/XMP-GDepth:Data>.*/\1/p' | base64 -d > $1_depthmap.png
exiftool -X -b $1.jpg | sed -n -e 's/.*<XMP-GImage:Data>\(.*\)<\/XMP-GImage:Data>.*/\1/p' | base64 -d > $1_preprocessed.jpg

IMG_20140501_223102

IMG_20140428_213657

IMG_20140425_130548

IMG_20140422_105423

IMG_20140421_233153

IMG_20140421_201310

IMG_20140421_191650

IMG_20140421_190502

IMG_20140421_190310

IMG_20140420_180758

IMG_20140420_145350

IMG_20140419_214114

IMG_20140419_201449

IMG_20140418_204300

IMG_20140418_200805

IMG_20140417_100545

Fun With Wi-fi Monitoring Above 10000 ft

This was my first time flying on the airplane with Wi-fi service. The service was quite expensive so I did not purchase it.

Instead, I’ve decided to see what I will get if I do some magic using Wireshark. I’ve configured the wi-fi device into monitor mode. (in this mode, I am not connected to any wi-fi access points, and this only reads open communications, to prevent infringing both legal and usage term issues.)

What this provides are communications information between access point and device, and device information. Which means, as long as the devices are turned on with Wi-fi enabled, I would see something about it.

This essentially provided popularity votes on the plane:

  • iOS devices: 46
  • HTC: 1
  • Motorola, Microsoft, Nokia, Asus: 1 each
  • LiteOn: 1 (this seems to be mobile wireless access point, I don’t think it’d be useful inflight…)

Probably a lot of phones were turned off or were in an airplane mode, unless he/she was using the service, so this probably discounts any phone device pretty heavily. But 46 iOS devices… wow.

Something I’ve noticed about security:

  • One should use VPN or SSL while on the public non-secure networks. This is quite obvious.
  • Devices polls for previously connected access points, which means a device actually sends out SSID in plain text. This means, a device is essentially leaking SSID information, some of which I observed was internal networks of some of well known companies, as well as hotel and airport networks. This potentially can be used for social engineering attacks. Companies should use SSID that has no relationship with a company name.
  • Some people use their name as their system name, in which in conjunction with the above, someone can get pretty good idea about where he/she works for, and where he/she has been.

Why I decided to get Galaxy Nexus and go back to Vanilla Android

I have been Android user since T-mobile released their first Android phone, T-mobile G1 (HTC Dream), back in 2008. Couple years after that, I’ve moved to Nexus One, then on Sensation 4G (HTC Sensation) then recently, I’ve decided to move to Galaxy Nexus with vanilla Android.

Of course, Android 4.1 (Jelly Bean) was one of many reasons I’ve decided doing this, but there are more, inherently what I feel broken with manufacture/carrier customization to a device.

Yeah, I’m talking about HTC Sense, yeah, I’m also talking about other pre-installed softwares like T-mobile TV that I haven’t, and don’t use.

Why did they remove useful features?

Couple of months ago, T-mobile pushed out 4.0 updates to Sensation 4G. Which I was happy with — Google Chrome finally ran on my phone (it is only supported 4.0 and up) and the system was overall much more stable. (more to the stability later)

But one thing I haven’t understood, and I still don’t is, why did HTC remove some useful feature from vanilla 4.0. One example is the fact that you can’t uninstall application by dragging and drop from the application menu to the top of the screen. As far as I know, it was first introduced in 4.0, which could have been very useful feature. (and in fact, my 4.0 Acer tablet does it just fine.) While this is such a minor small detail, considering relatively small storage size of HTC Sensation was issue when I want to experiment with different application. Being able to uninstall application by moving icons around certainly beats inconveniences of navigating through Applications menu. (and try doing it for 10 different applications you are trying to uninstall!)

Another thing was small, but visual styling on the operating system. I thought it’d be that cool 4.0 look, right? Nope, it’s same old “round button” style. Couldn’t they give at least an option to change visual style?

To me, these seem like clear indication that designers at HTC are more on the ball of trying to push their own mobile experience than bringing the best and current experience on the Android platform.

Address book: Polluted

One of the big issue I had with HTC Sense was its address book. When I see number of contact, I see something like following inserted to my memo section of Google contacts.

Notes: xxxxxxxid:xxxxxxxxxx/friendof:xxxxxxxxxx

It looks like this is meta data for their account linking. Why?

It appears like it decided to pollute 200 of my contacts this way, and to get rid of them, I have to go one by one. (or perhaps I can write a program that talks with Google Contacts API and do that…)

It is came to my attention when I used dialer/address book feature is much nicer than I recalled when I was back in vanilla 2.3 on Nexus One. Even though I already had Android 4.0 on HTC Sensation, I did not see those changes because of HTC Sense.

2.3 launcher instability

Stability of the HTC Sense launcher was joke back in 2.3. It apparently got garbage collected way too many times, which if you try to do anything useful on your phone, and go back to launcher, then you will be greeted with green HTC logo on white screen for 20 seconds, which you can’t do anything. If you need to make a quick call after browsing a web for while? Nope, you’ll have to wait 20 seconds. It was annoying. Fortunately, they fixed most of these problem on 4.0.

Bloat and delays

Complaining about bloatwares (or “pre-installed softwares” to put it nicer way) maybe have nothing to do with device, rather choice of retail channel, Those pre-installed software have been bit of nuisance to the platform. The mere fact if they are on the device, will take up your storage should you choose to update it, and if you don’t, Play market will nag you to update, and renders “update to all” function unusable as pressing that button will also update the application you don’t want update. (at least they have fixed this issue starting 4.0 update by making it possible to disable applications you don’t use — which makes them disappear from the launcher, and stops update detection.)

Also looking how some “application such as wi-fi calling” contributed delay in ICS update, it is now clear that those pre-installed softwares are now affecting release timeline of update, not just because of manufactures, but because of carriers they are involved with.

I’m not against carriers developing a software for their customers, I’m just against those being pre-installed. All of the problem can be prevented by just distributing those Google Play.

In summary

I’m not necessary bashing HTC Sense here. HTC Sense might have played much more relevant role introducing relatively friendlier interface compared to vanilla Android in the past. Perhaps back in the day of Android 1.6, it was still augmenting vanilla Android quite a bit (I’ve briefly used HTC Sense running on Android 1.6 on my colleague’s phone), but in my opinion, they stopped innovating there. Did Android 2.3 with HTC Sense any different from one that was running on Android 1.6? No. Was it different on Android 4.0? Nope!

Probably HTC Sense cater more to those prefers no changes; actually, let me rephrase it, refusing changes. I can imagine a lot of support calls for such change distracting a lot of users, but still, insulating improvement on this major operating system was most disturbing fact that I realized once I moved to vanilla Android 4.1. I guess it is side effect of Android platform is so prolific that now is becoming commodity. When the platform is spread to many class of people, their common denominator is set to those who just seek for more consistent, but in turn, boring (to those seeking active improvements) experience. It’s just like early days of smartphones. Was Windows Mobile 6 so different from Windows Mobile 5? What about versions of Blackberry? The gap is that Android is still evolving platform and that what makes the platform great. It is such a shame that 90% of device out there seems to be intentionally left in vacuum just because customers wants it? (or manufactures/carriers think so?)

Clearly Google doesn’t want manufacture from “reskinning” the phone (not that they can stop it, considering the open nature of Android platform.) Now Android has caught up to the point it doesn’t need custom interface to accomplish anything you can with those custom interfaces.

I think I know what my future phones will be from now on.

On Flash and Mobile Device

Looks like there’s now out-of-beta version of Flash Player 10.1 for Android available on the Market. Something that makes Android platform one step superior to iPhone…

I have been using beta version of Flash Player on my Nexus One for few months now, and I found it actually beneficial to have it on my phone. Simply put, the web is all about diversity; there are many places still using Flash and I don’t think it’ll be gone any time soon. Hate it or not, there are certain thing that appropriate with Flash and not by HTML5. The article from YouTube API’s blog, the entry Flash and the HTML5 video tag summarizes some aspect of this very well.

Rather than displaying missing plugin on the page, having Flash Player actually displays contents, like it supposed to be. By Android supporting Flash Player, not only they give users the way to display contents as they are meant, it gives user a choice.

Biggest problem of Apple’s attitude, is that they don’t give users a choice. Let’s face it, Steve Jobs’s view of the whole Internet is mere ideology, which is bit of departure from how it is in the real life. His Thoughts on Flash attacks on Flash, but there’s no justification they wouldn’t give that choice to users.

The world that gives users a choice, or the world that choices are taken away by authority before you can even see there’s an option, which one do you prefer?

Update [August 17th, 2010 @ 18:48PDT]: Computerworld has a nice read about Flash, too.

Analysis of Nexus One’s 3G Issue

I have been try to figure out Nexus One’s 3G conductibility issues I have been experiencing.

Observation: Occasionally, data connection is disrupted randomly, causing application trying to connect to network reports timeout. This continues for few seconds to few minutes, depending on network access being attempted. (to the device to be able to recover, data transmission needs to cease completely.) Up arrow (send) indicator is lit while no activity is observed in down arrow. Data mode stays as “UMTS” while this is observed.

Hypothesis: The system is having problem transitioning to HSDPA from UMTS or PDP (Packet Data Protocol) context may be failing.

The following experiments are conducted. They are conducted after resetting the device to factory default.

Experiment 1: Radio band

I modified radio band to USA and other settings.

Result:

Setting any region in radio band did not eliminate the issue.

Experiment 2: APN reset

I have reset APN setting to factory default.

Result:

It initially thought to have improved the issue, however did not eliminated issue. Perception of improved connectivity may have came from randomness of the issue.

Experiment 3: Keeping alive using PING packet

Using ConnectBot, I have gone into console and set it to send out ICMP echo (ping) packet every five second.

Result:

This substantially increased availability of data by fixating phone data mode to HSDPA. However, this may be violation of T-mobile’s term of use, and is not deemed to be permanent solution.

Experiment 4: Analysis of the log

FRF72 allowed extraction of radio log, and analysis of the log could be conducted.

Result:

It was found that when the device is affected by this issue, the following pattern is observed in the log.

Whole lifecycle of the issue would leave such log as the following. (in the below, portion highlighted in red is logged during time of outage, and blue when the connection is reestablished.)

06-21 05:01:01.810 D/RILJ (162)[0797]> REQUEST_SET_LOCATION_UPDATES: true
06-21 05:01:01.830 D/RILJ (162)[0797]< REQUEST_SET_LOCATION_UPDATES
06-21 05:01:01.830 D/RILJ (162)[0798]> REGISTRATION_STATE
06-21 05:01:01.850 D/RILJ (162)[0798]< REGISTRATION_STATE {1, A1B5, 01A85AC1, 3, null, null, null, null, null, null, null, null, null, null}
06-21 05:01:01.850 D/RILJ (162)[0799]> REQUEST_SET_LOCATION_UPDATES: false
06-21 05:01:01.860 D/RILJ (162)[0799]< REQUEST_SET_LOCATION_UPDATES
06-21 05:01:01.940 D/RILJ (162)[0800]> REQUEST_GET_NEIGHBORING_CELL_IDS
06-21 05:01:01.950 D/RILJ (162)[0800]< REQUEST_GET_NEIGHBORING_CELL_IDS
06-21 05:01:07.340 D/GSM (162)[GsmDataConnectionTracker] no DATAIN in a while; polling PDP
06-21 05:01:07.340 D/RILJ (162)[0801]> DATA_CALL_LIST
06-21 05:01:07.350 D/RILJ (162)[0801]< DATA_CALL_LIST [DataCallState: { cid: 1, active: 2, type: IP, apn: epc.tmobile.com, address: 25.128.84.145 }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }]
06-21 05:01:07.350 D/GSM (162)GSMDataConnTrack handleMessage { what=11 when=2999942 obj=android.os.AsyncResult@449eb398 }
06-21 05:01:12.350 D/GSM (162)[GsmDataConnectionTracker] no DATAIN in a while; polling PDP
06-21 05:01:12.350 D/RILJ (162)[0802]> DATA_CALL_LIST
06-21 05:01:12.350 D/RILJ (162)[0802]< DATA_CALL_LIST [DataCallState: { cid: 1, active: 2, type: IP, apn: epc.tmobile.com, address: 25.128.84.145 }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }]
06-21 05:01:12.350 D/GSM (162)GSMDataConnTrack handleMessage { what=11 when=3004945 obj=android.os.AsyncResult@449bba38 }
06-21 05:01:17.350 D/GSM (162)[GsmDataConnectionTracker] no DATAIN in a while; polling PDP
06-21 05:01:17.350 D/RILJ (162)[0803]> DATA_CALL_LIST
06-21 05:01:17.360 D/RILJ (162)[0803]< DATA_CALL_LIST [DataCallState: { cid: 1, active: 2, type: IP, apn: epc.tmobile.com, address: 25.128.84.145 }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }]
06-21 05:01:17.360 D/GSM (162)GSMDataConnTrack handleMessage { what=11 when=3009954 obj=android.os.AsyncResult@449765f8 }
06-21 05:01:22.360 D/GSM (162)[GsmDataConnectionTracker] no DATAIN in a while; polling PDP
06-21 05:01:22.360 D/RILJ (162)[0804]> DATA_CALL_LIST
06-21 05:01:22.360 D/RILJ (162)[0804]< DATA_CALL_LIST [DataCallState: { cid: 1, active: 2, type: IP, apn: epc.tmobile.com, address: 25.128.84.145 }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }]
06-21 05:01:22.370 D/GSM (162)GSMDataConnTrack handleMessage { what=11 when=3014959 obj=android.os.AsyncResult@449ecb80 }
06-21 05:01:27.367 D/GSM (162)[GsmDataConnectionTracker] no DATAIN in a while; polling PDP
06-21 05:01:27.367 D/RILJ (162)[0805]> DATA_CALL_LIST
06-21 05:01:27.370 D/RILJ (162)[0805]< DATA_CALL_LIST [DataCallState: { cid: 1, active: 2, type: IP, apn: epc.tmobile.com, address: 25.128.84.145 }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }]
06-21 05:01:27.370 D/GSM (162)GSMDataConnTrack handleMessage { what=11 when=3019965 obj=android.os.AsyncResult@44a3e798 }
06-21 05:01:32.373 D/GSM (162)[GsmDataConnectionTracker] no DATAIN in a while; polling PDP
06-21 05:01:32.373 D/RILJ (162)[0806]> DATA_CALL_LIST
06-21 05:01:32.380 D/RILJ (162)[0806]< DATA_CALL_LIST [DataCallState: { cid: 1, active: 2, type: IP, apn: epc.tmobile.com, address: 25.128.84.145 }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }]
06-21 05:01:32.380 D/GSM (162)GSMDataConnTrack handleMessage { what=11 when=3024970 obj=android.os.AsyncResult@44a389b0 }
06-21 05:01:37.380 D/GSM (162)[GsmDataConnectionTracker] no DATAIN in a while; polling PDP
06-21 05:01:37.380 D/RILJ (162)[0807]> DATA_CALL_LIST
06-21 05:01:37.390 D/RILJ (162)[0807]< DATA_CALL_LIST [DataCallState: { cid: 1, active: 2, type: IP, apn: epc.tmobile.com, address: 25.128.84.145 }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }]
06-21 05:01:37.390 D/GSM (162)GSMDataConnTrack handleMessage { what=11 when=3029985 obj=android.os.AsyncResult@449f31a8 }
06-21 05:01:42.400 D/GSM (162)[GsmDataConnectionTracker] no DATAIN in a while; polling PDP
06-21 05:01:42.400 D/RILJ (162)[0808]> DATA_CALL_LIST
06-21 05:01:42.400 D/RILJ (162)[0808]< DATA_CALL_LIST [DataCallState: { cid: 1, active: 2, type: IP, apn: epc.tmobile.com, address: 25.128.84.145 }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }]
06-21 05:01:42.400 D/GSM (162)GSMDataConnTrack handleMessage { what=11 when=3034998 obj=android.os.AsyncResult@449b8908 }
06-21 05:01:47.400 D/GSM (162)[GsmDataConnectionTracker] no DATAIN in a while; polling PDP
06-21 05:01:47.400 D/RILJ (162)[0809]> DATA_CALL_LIST
06-21 05:01:47.410 D/RILJ (162)[0809]< DATA_CALL_LIST [DataCallState: { cid: 1, active: 2, type: IP, apn: epc.tmobile.com, address: 25.128.84.145 }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }]
06-21 05:01:47.410 D/GSM (162)GSMDataConnTrack handleMessage { what=11 when=3040003 obj=android.os.AsyncResult@449d1680 }
06-21 05:01:51.930 D/RILJ (162)[0810]> REQUEST_SET_LOCATION_UPDATES: true
06-21 05:01:51.990 D/RILJ (162)[0810]< REQUEST_SET_LOCATION_UPDATES
06-21 05:01:51.990 D/RILJ (162)[0811]> REGISTRATION_STATE
06-21 05:01:52.020 D/RILJ (162)[0811]< REGISTRATION_STATE {1, A1B5, 01A85AC1, 3, null, null, null, null, null, null, null, null, null, null}
06-21 05:01:52.020 D/RILJ (162)[0812]> REQUEST_SET_LOCATION_UPDATES: false
06-21 05:01:52.030 D/RILJ (162)[0813]> REQUEST_GET_NEIGHBORING_CELL_IDS
06-21 05:01:52.030 D/RILJ (162)[0812]< REQUEST_SET_LOCATION_UPDATES
06-21 05:01:52.040 D/RILJ (162)[0813]< REQUEST_GET_NEIGHBORING_CELL_IDS
06-21 05:01:52.400 D/GSM (162)[GsmDataConnectionTracker] no DATAIN in a while; polling PDP
06-21 05:01:52.400 D/RILJ (162)[0814]> DATA_CALL_LIST
06-21 05:01:52.410 D/RILJ (162)[0814]< DATA_CALL_LIST [DataCallState: { cid: 1, active: 2, type: IP, apn: epc.tmobile.com, address: 25.128.84.145 }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }]
06-21 05:01:52.410 D/GSM (162)GSMDataConnTrack handleMessage { what=11 when=3045005 obj=android.os.AsyncResult@44a1a028 }
06-21 05:01:57.410 D/GSM (162)[GsmDataConnectionTracker] no DATAIN in a while; polling PDP
06-21 05:01:57.410 D/RILJ (162)[0815]> DATA_CALL_LIST
06-21 05:01:57.410 D/RILJ (162)[0815]< DATA_CALL_LIST [DataCallState: { cid: 1, active: 2, type: IP, apn: epc.tmobile.com, address: 25.128.84.145 }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }]
06-21 05:01:57.410 D/GSM (162)GSMDataConnTrack handleMessage { what=11 when=3050009 obj=android.os.AsyncResult@44a107b8 }
06-21 05:02:02.420 D/GSM (162)[GsmDataConnectionTracker] no DATAIN in a while; polling PDP
06-21 05:02:02.420 D/RILJ (162)[0816]> DATA_CALL_LIST
06-21 05:02:02.430 D/RILJ (162)[0816]< DATA_CALL_LIST [DataCallState: { cid: 1, active: 2, type: IP, apn: epc.tmobile.com, address: 25.128.84.145 }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }]
06-21 05:02:02.430 D/GSM (162)GSMDataConnTrack handleMessage { what=11 when=3055026 obj=android.os.AsyncResult@449f9508 }
06-21 05:02:07.430 D/GSM (162)[GsmDataConnectionTracker] no DATAIN in a while; polling PDP
06-21 05:02:07.430 D/RILJ (162)[0817]> DATA_CALL_LIST
06-21 05:02:07.430 D/RILJ (162)[0817]< DATA_CALL_LIST [DataCallState: { cid: 1, active: 2, type: IP, apn: epc.tmobile.com, address: 25.128.84.145 }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }]
06-21 05:02:07.440 D/GSM (162)GSMDataConnTrack handleMessage { what=11 when=3060029 obj=android.os.AsyncResult@44972458 }
06-21 05:02:12.430 D/GSM (162)[GsmDataConnectionTracker] no DATAIN in a while; polling PDP
06-21 05:02:12.430 D/RILJ (162)[0818]> DATA_CALL_LIST
06-21 05:02:12.440 D/RILJ (162)[0818]< DATA_CALL_LIST [DataCallState: { cid: 1, active: 2, type: IP, apn: epc.tmobile.com, address: 25.128.84.145 }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }]
06-21 05:02:12.440 D/GSM (162)GSMDataConnTrack handleMessage { what=11 when=3065033 obj=android.os.AsyncResult@4495b7b8 }
06-21 05:02:17.441 D/GSM (162)[GsmDataConnectionTracker] no DATAIN in a while; polling PDP
06-21 05:02:17.441 D/RILJ (162)[0819]> DATA_CALL_LIST
06-21 05:02:17.441 D/RILJ (162)[0819]< DATA_CALL_LIST [DataCallState: { cid: 1, active: 2, type: IP, apn: epc.tmobile.com, address: 25.128.84.145 }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }]
06-21 05:02:17.450 D/GSM (162)GSMDataConnTrack handleMessage { what=11 when=3070039 obj=android.os.AsyncResult@44997de8 }
06-21 05:02:22.440 D/GSM (162)[GsmDataConnectionTracker] no DATAIN in a while; polling PDP
06-21 05:02:22.440 D/RILJ (162)[0820]> DATA_CALL_LIST
06-21 05:02:22.450 D/RILJ (162)[0820]< DATA_CALL_LIST [DataCallState: { cid: 1, active: 2, type: IP, apn: epc.tmobile.com, address: 25.128.84.145 }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }]
06-21 05:02:22.450 D/GSM (162)GSMDataConnTrack handleMessage { what=11 when=3075043 obj=android.os.AsyncResult@449f0108 }
06-21 05:02:27.451 D/GSM (162)[GsmDataConnectionTracker] no DATAIN in a while; polling PDP
06-21 05:02:27.451 D/RILJ (162)[0821]> DATA_CALL_LIST
06-21 05:02:27.451 D/RILJ (162)[0821]< DATA_CALL_LIST [DataCallState: { cid: 1, active: 2, type: IP, apn: epc.tmobile.com, address: 25.128.84.145 }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }, DataCallState: { cid: -1, active: 0, type: , apn: , address: }]
06-21 05:02:27.451 D/GSM (162)GSMDataConnTrack handleMessage { what=11 when=3080049 obj=android.os.AsyncResult@449e72c0 }
06-21 05:02:27.640 D/RILJ (162)[UNSL]< UNSOL_RESPONSE_NETWORK_STATE_CHANGED
06-21 05:02:27.640 D/RILJ (162)[0822]> OPERATOR
06-21 05:02:27.640 D/RILJ (162)[0823]> GPRS_REGISTRATION_STATE
06-21 05:02:27.640 D/RILJ (162)[0824]> REGISTRATION_STATE
06-21 05:02:27.650 D/RILJ (162)[0822]< OPERATOR {T-Mobile, T-Mobile, 310260} 06-21 05:02:27.650 D/RILJ (162)[0825]> QUERY_NETWORK_SELECTION_MODE
06-21 05:02:27.670 D/RILJ (162)[0823]< GPRS_REGISTRATION_STATE {1, null, null, 9}
06-21 05:02:27.690 D/RILJ (162)[0824]< REGISTRATION_STATE {1, A1B5, 01A85AC1, 9, null, null, null, null, null, null, null, null, null, null}
06-21 05:02:27.700 D/RILJ (162)[0825]< QUERY_NETWORK_SELECTION_MODE {0}
06-21 05:02:27.700 D/GSM (162)Poll ServiceState done: oldSS=[0 home T-Mobile T-Mobile 310260 UMTS CSS not supported -1 -1RoamInd: -1DefRoamInd: -1EmergOnly: false] newSS=[0 home T-Mobile T-Mobile 310260 HSDPA CSS not supported -1 -1RoamInd: -1DefRoamInd: -1EmergOnly: false] oldGprs=0 newGprs=0 oldType=UMTS newType=HSDPA
06-21 05:02:27.710 D/GSM (162)RAT switched UMTS -> HSDPA at cell 27810497

Further analysis of the log and the sourcecode revealed that this is emitted by Android sourcecode:
GsmDataConnectionTracker.java

Line 899 emits this error when WatchDog determines PDP context to be down when excessive number of outgoing packets are detected while there is no incoming packet.

Conclusion:

While it is still high speculative, the issue may be caused by failure of obtaining PDP context. Issue may be caused by radio not properly recovering its PDP context when it is lost. It is worthwhile to note that the code never progresses to line 909 to display recovery attempt.

Currently, this issue is discussed in the forum at AndroidSPIN and is being forwarded to HTC as well.

Working Around Nexus One’s 3G Issues

There seems to be several issue regarding 3G connection issue on Nexus One.

Issue range from fluctuation of signal strength depending on where you hold your phone, and others.

One issue I am experiencing, which some other people report is the fact that Nexus One causes network error while up arrow indicator was staying on.

This has been reported on several of help forums.

Investigating issue myself, it because evident that this problem was happening when the device is transitioning from UMTS to HSDPA.

I have observed that normally, the device claim it is on UMTS connection. But at the moment that something try to access the network, this mode changes to HSDPA. After few seconds of network inactivity, this mode turns back to UMTS.

Looking at pattern, there are quite common chance that this transition do not go smooth, and the device would stuck with UMTS, unable to send or receive data. Therefore, data is constantly resent, eventually timing out causing error. Problem is that timeout can get very long when applications are trying to gain access to the network connection, as it appears to be only chance it can reset is when the application attempts to transition to HSDPA from UMTS, after connection attempt is ceased. (Note this problem do not happen if you are on 2G (EDGE/GPRS) connection. Also there were some story that some people have their phone in HSDPA mode permanently. (perhaps they have very strong 3G signal?)

I found simple workaround to this issue. My idea was, if this is caused by failure of transition from UMTS to HSDPA, why not just force the device to be on HSDPA mode?

I downloaded the piece of program called ConnectBot, which is terminal emulator program. There is way to connect to local console using program. You’d login to your local console, then type in the following.

ping -i 5 1.1.1.1 &

Where 1.1.1.1 is some IP address. This particular command line will send out ping packet every five seconds. Now this IP address doesn’t have to be reachable. It is actually beneficial if it is not, as you only need to send out some packet and you don’t care about any reply. After you type in this command line (do not forget “&”) press enter, and then open up a menu and disconnect. This ping command will be running in background.

Alternatively you could create text file containing the command line above, then execute using the following command.

sh ./script &

Because it is merely running the program in the background, if you restart your phone, you will do this process again.

Trying this, now my phone stays on HSDPA all the time, and seems to be stable now. I had some concern about impact on battery life this may cause, but it seems to be minimal.

Please do note that this may potentially violate T-mobile’s term as described below

(e) running software or other devices that maintain continuously active Internet connections when a computer’s connection would otherwise be idle, or “keep alive” functions. For example, you cannot use a Data Plan for Web broadcasting, or for the operation of servers, telemetry devices and/or supervisory control and data acquisition devices.

Although purpose of this workaround is not to activate connection the internet, they may point out that by doing this, we are still shooting out ICMP packet though impact to infrastructure should be very minimal.

A Major Defect of the Android Platform

I haven’t bad mouthed too much of the Android platform, because I think I had some expectation that they are probably working on this to fix the problem. It has been some update release and they still haven’t figured out probably the most critical defect of the platform, so I will dump it out here now.

It’s the fact that on memory is constantly full that it causes all kind of nasty problems. Yes, I’m talking about storage space. If you have paying attention to my status, you know I have 8GB of memory. That won’t help me at all. It’s because software can only be installed on the device memory, and not to SD card. Yes you heard it right, even if you have many gigs on your SD, it doesn’t help. You have to rely on your on board storage space of, oh, 128MB or so.

Even if you have software library of 10000s on the market place, well there’s no point of it, because you can’t possibly get more than, perhaps 10 of those apps. Oh, forget about games, they take up too much space. Yeah, so if the big sales point of this device is extensibility by software, that’s big disappointment, because your device simply won’t let you do that.

I heard their side of story on this. It’s because of protected storage for paid apps. They basically have area in internal memory which has “do not let other applications copy this region.” In other word, they are putting this limitation, because if they’d allow installation of apps to SD rather than onboard memory, users will be able to copy softwares otherwise not accessible if they were saved in the protected storage. Hey Google, if that the only way you can implement DRM, I think it’s your time to start firing some of your engineers. You should have smarter people than that.

This not only causes inconvenience, but affects usability, too. Because, when this happens, it stops receiving E-mail, too. (Probably because E-mails are stored in the internal memory, too.) So newest E-mail in my mailbox is now two days old.

For those considering any Android phones, just because of the severity of the problem, at this point, I would recommend to wait until they fix this problem, if ever. I really like the platform and I want them to succeed, but I just had to make some rant on it, as the design is simply retarded.