Up front I want to make it clear that I do not have (and have never had) Sprint mobile phone service in my name. Based on my experiences with them over the past few days, I am pretty certain I never will either. Let me explain more…
Continue reading
I have been carrying a Nexus 5X for a while now, and for the most part I love it. Having a pure Android experience, rather than one with a UI skin forced over the top of it, makes the Android experience very close to the iOS one for the most part in my opinion.
Partly because it is not the only phone I carry, I also decided a few weeks ago to sign it up for the Android beta program. I was already running Nougat (Android 7.0), but I wanted to see what else they were planning in the Wi-Fi space particularly. Everything seemed to be going well until the beta 7.1.1 drop landed on the phone. At that point, I started having problems with Wi-Fi stability and, worse, lost LTE completely.
After a few days of that, and at least one attempt to find where I could send feedback that might be noticed (Google really needs to learn from Apple here and include a dedicated beta program feedback app in the builds), I gave up and worked out how to get the phone out of the beta program. This is one place where Google beats Apple; as soon as I did that on their site, the phone indicated that it had an “update” to revert me to Android 7.0. It was a full install (so all data wiped), but that’s OK.
Missing Backups
At the end of that I opted to setup using a backup. There was the first problem. The latest backup it showed me was from my old Nexus 5. Nothing from the 5X despite it being setup for backups all the time I’ve been running it. No big deal, the Nexus 5 backup will be 90% or more, and the photos (which are all I really need) are all in Google Photos anyway.
The process was as smooth as usual, and in no time I was back to running Android 7.0 and my LTE signal was connected again. Then, it offered me an update to the public Android 7.1.1 release. This had a different build ID to the one I had been running, so I took a chance (didn’t really have much to lose).
Public Android 7.1.1
This is an OTA upgrade, so not a full wipe & it doesn’t take long. When it was done, the phone restarted and my LTE was gone again. Seriously. In a public release of their new flagship OS, LTE is not working on the Nexus 5X device (connected to AT&T). It works fine with Android 7.0 (and previous releases too). It amazes me that nobody at Google had noticed this before they shipped it!
Maybe this is not a common thing for folks to do with their phones these days, but I have a few numbers programmed into my contacts that include access codes, or similar, to be dialed after the main number. Some of them are conference service access sequences, one is a calling card from my home VoIP provider (CallCentric) that lets me make international calls at VoIP rates (a fraction of what AT&T would charge me if I just dialed direct from the phone) and one connects me to my mother’s SIP line in the UK via a service called SIP Broker, giving me free calls to her even when I am on my mobile phone here.
While I certainly could remember all the access codes, PINs and even my mother’s SIP number, it is much simpler to just program them into contacts so they are dialed automatically. This has worked beautifully on all my iPhones to date and even on my Android phones. Until iOS 10. When I first upgraded my iPhone 6s to iOS 10 GM, I noticed that the tone replay was much faster. I also noticed that SIP Broker was having trouble understanding it sometimes (I would estimate around 25% of the time). When the iPhone 7 arrived though, that failure rate jumped to 100%. I could not get these numbers to dial at all unless I did it manually.
I believe the tones are long enough on iOS 10, but I suspect the gaps between them are too short. That is somewhat confirmed by the fact that adding a pause between each digit allowed it to work (but it took nearly 30 seconds to dial the number!).
Analyzing the Tones
Since the tone replay is audible, I fired up Audacity on my Mac and simply recorded three phones replaying the tones to access the CallCentric test number via a local SIP Broker PSTN gateway:
(415) 594 0355,*462,17770000001
On the iPhone 7 (running iOS 10.0.2), the trace looked like this:
You can see from there that the gap between the tones is very, very short. In fact, just 5-10ms compared to a tone time of around 200ms. This reinforces the belief that it is the gap that is the problem.
For comparison, here is iOS 9 running on an iPhone 5c:
This one has slightly longer tone periods (about 250ms), but the gaps are much, much longer at around 100ms. That is 10x the length of the gaps on the iPhone 7.
Finally, I tried my Nexus 5X running Android 7 to see whether they’d had the same idea of reducing the gaps, but no, the Nexus has both longer tones (over 300ms of tone) and longer gaps (around 150ms):
What Does the Spec Say?
So, there was always a chance that this is something that an engineer at Apple, for whatever reason, decided they could adjust to make their tone replay feature more compliant with a standard specification. Indeed, there is a specification for DTMF (pdf) from the European Telecommunications Standards Institute (ETSI). In that specification there are defined minimum durations for both the tone and the pause between tones.
The tone duration is defined like this:
Where the DTMF signalling tone duration is controlled automatically by the transmitter, the duration of any individual DTMF tone combination sent shall not be less than 65 ms. The time shall be measured from the time when the tone reaches 90 % of its steady-state value, until it has dropped to 90 % of its steady-state value.
The pause duration is defined like this:
Where the DTMF signalling pause duration is controlled automatically by the transmitter the duration of the pause between any individual DTMF tone combination shall not be less than 65 ms. The time shall be measured from the time when the tone has dropped to 10 % of its steady-state value, until it has risen to 10 % of its steady-state value.
So, that iPhone 7 time, looks to me to be well below the minimum pause time!
I upgraded my Nexus 5 to the latest Android version. 6.0 aka Marshmallow, and didn’t really think much of it. Then, on Monday, I needed to run a test on some software that required the Wi-Fi to be turned off. I noticed at the time that the GMail app was having some problems; I received regular crash notifications from it (while it was running in the background).
Then tonight I checked in on my test and was surprised to see an Android mobile data warning in the notifications area. Tapping through, I saw that in the last few days I have consumed ~5GB of mobile data. On a phone that has been sitting on my desk without me touching it. The culprit? You guessed it, the GMail app was responsible for almost the entire 5GB. In less than five days.
I also received an OS update this evening, and since then the GMail app seems happier. I am back on Wi-Fi now though and will continue to monitor it. Had I been on a 3GB plan, I would have been more than a little annoyed (and had to pay for the extra data). As it happens, this phone is on a 20GB shared plan, so I have some headroom.