Posts tagged iPhone
I’ve made a habit of only ever looking at signal level in numerics on iOS since the iPhone 3GS days. This has paid off a few times in the past (notably the iPhone 4 antenna situation) but in general just gives a better perspective for network conditions. I regularly post screenshots with both cellular and WiFi in numerics instead of the default bars, and on iOS this is pretty simple to make happen, at least to the cellular signal level indicator, without jailbreaking.
To do this the basic workflow is to enter FieldTest.app, then force quit the application. When FieldTest launches, it changes a .plist file for springboard which controls whether numerics are being shown for cellular signal. This is exactly the file that SBSettings tweaks if you’re toggling “Numeric GSM” and “Numeric WiFi.” I should note that these settings also stay around across iOS restores. Anyhow a lot of people have been asking on Twitter lately for some reason how to make this happen, so I thought I’d write it up.
Anyhow to show cellular signal without using SBSettings:
- Launch FieldTest.app by going into the dialer and dialing *3001#12345#*
- Hold down standby/lock like you’re going to turn the phone off
- Release standby/lock after the power off slider appears, then hold home (this is force quit on iOS – it’s impressive so few people know it)
- Boom, you have numerics instead of bars
This can now be tapped to switch back and forth. Launching FieldTest again and quitting will restore the file however, so every time you quit this will have to be a force quit to preserve the setting without jailbreaking or restoring an iOS backup with the plist file set how you want it.
I should also note that on LTE this number is RSRP (Reference Signal Received Power) in units of dBm. On WCDMA this is RSCP (Received Signal Code Power) in dBm, and on CDMA2000 1x/EVDO this is RSSI I believe (or EC, I haven’t ever carried a CDMA2000 iPhone for an apreciable amount of time). On WCDMA and 1x/EVDO values between -50 and -113 dBm are typical, with -50 being at cell center and -113 dBm being at cell edge. On LTE because the iDevice is showing RSRP, values between -75 and -120 dBm are typical, with RSRP showing ~20 dB lower than the analogous RSCP/WCDMA-land signal if you’re trying to compare.
Update/Note: In iOS 7 the signal bars were changed to dots, but the trick still works. Although switching into numerals by force quitting Field Test still works, sometimes it takes a few tries before it works. I’m not sure why that is, but keep force quitting or try quitting and coming back and force quitting again and eventually you’ll switch over.
See the update at the bottom for the real deal, I was partly wrong about some of the antennas in iPhone 4, though I was indeed right about the connector locations for the bottom, and partly for the top.
I’ve been following the iPhone 4G/HD leak saga like a hawk, and until now I haven’t been able to really add anything to all that’s been said. However, today, Gizmodo published pictures of the inside of the iPhone 4G hardware they obtained. They didn’t talk about much other than the absurd number of screws (upwards of 30), battery size, packaging, and potential ease of replacement. In fact, their primary aim seems to have been locating “APPLE” markings on the few ribbon cables inside, rather than picking apart Apple’s hardware choices. No doubt disassembly was challenging, potentially explaining why there aren’t any photos of the iPhone with the “connect to iTunes” lock screen (broken after disassembly?).
They neglected to remove the EMI shields atop the interesting bits on the PCB, what I would’ve considered the biggest news about the device. So we still don’t know virtually anything about SoC, how much NAND flash there is onboard, RAM, the hugely important baseband (and whether this thing is potentially dual CDMA/GSM and UMTS for it to work on Verizon/Sprint alongside T-Mobile and AT&T), WiFi or Bluetooth choices (likely the same as the iPad, however), or anything else you’d expect to glean without those shields in place. In short, all the squares in this diagram from the iPhone 3GS are big question marks for the iPhone 4G. Still, we can make very good guesses about what the likely choices are.
However, being the RF-obsessed dude I am, I scrutinized the photos for some time looking for other interesting bits. I think I’ve found some interesting things.
First and foremost, I think that there are two discrete antenna assemblies in the phone. One at the top, one at the bottom (as you’d hold it in your hand).
Note that the phone in this picture has been rotated; the red circled area on the hardware is actually the bottom. Now, look at the two places I’ve marked with the white arrows. You can very clearly see a pigtail and standard radio connector on the top one, and a connector pad at the tip of the arrow at right. This is 100% certainly an antenna, and it’s also in the same region of the hardware (at the bottom) as the 3GS.
Above is what I’m talking about at 100% resolution.
Above shows the antenna before being removed, with the pigtail clearly connected to the mainboard PCB. We can make an educated guess that whatever is under the EMI shield next door is the baseband.
Now, compare and contrast to the iPhone 3GS’s ribbon/kapton antenna assembly:
And see it inside the black plastic holder (only the trailing ribbon connector is visible at bottom left):
If I’m not mistaken, the two connectors there are for discrete antennas inside, for cellular radio and WiFi/Bluetooth. I’m not infinitely familiar, but there only seems to be one antenna assembly in the 3GS at the bottom.
Now, on the iPhone 4G photos, there appears to possibly be a second possible antenna at the top.
I’ve labeled the connector that I can make out. Given the similar black packaging (possibly housing the flex PCB like in the 3GS), it seems likely this is another antenna.
I’ll leave you to speculate about why Apple might potentially want two discrete cellular antennas in their next generation phone…
After looking through the FCC OET internal photos of a huge number of other dual CDMA/UMTS design phones, all of which only require one antenna, I’m pretty sure the other top component is something less insidious. It’s entirely possible this is nothing more than a connector, some support structure, or perhaps maybe it is indeed an antenna, but for WiFi (N?). Whatever the case, I’m completely uncertain what this thing is, or if it’s part of the baseband. Obviously, the part at the bottom is an antenna, but the top part I’m more and more uncertain about.
We’ll see as time goes on and better pictures are made available what it is, but I’m not confident it’s an antenna anymore.
Of course, we now know the real deal with the iPhone 4. I was wrong about what the antennas were, but right about the connectors. Up at the top, if you scrutinize iFixit’s teardown, you can see a small gold pad right above a test junction for the WiFi/GPS/BT 2.4 GHz antenna. There’s a trace on the EMI shield which leads to a contact screw (gold, so it’s visible) leading directly to the antenna. So the connector for the 2.4 GHz antenna is up at the top near that seam.
For the UMTS/GSM antenna, the connector snakes across from the PCB to the left side of the phone facing up (facing down, it snakes to the right, like in this photo):
You can see the test point and connector at the left, the pigtail leading to the right across the EMI shield, and the gold screw which connects the whole deal to the aluminum antenna.
Of course, the interesting part is that this becomes the most active region of the antenna. It’s a monopole, rather than a dipole – in this configuration. The result is that for 1/4 wavelength, that part of the aluminum is very active at radiating RF. This is also the location your palm rests, interestingly.
I’m going to talk about the real deal on AnandTech shortly, so stay tuned…
It’s live here now: http://www.anandtech.com/show/3794/the-iphone-4-review/1
A few months ago, I made a post about what changes I would love to see in iPhone OS 4.0 when it rolled around, if it ever rolled around. Flash forward to today, where iPhone OS 4.0 is an officially announced, almost ready for release platform update. In the spirit of conclusion, let’s see how much I wanted that actually made it into the update:
1 – Google Voice Integration: No Go
This still remains a no-show. Apple and Google relations have only continued to sour, despite the Steve-Eric coffee shop
PR stunt meeting that was hugely popularized a few weeks ago. In fact, because Apple has repeatedly demonstrated no motivation to popularize any Google services anymore, it’ll likely never happen. This is yet another unfortunate artifact of the ongoing Google and Apple divorce process, and it just ends up stifling innovation. Apple and Google both give end-user focused experience an awful lot of lip service, up to the point where they have to integrate with other competitors offerings.
Google Voice is just one such example, but there are others. Mail on the iPhone still lacks support for Google’s unique organizational methods, and for the same token, Google refuses to this day to make their own iPhone OS gmail client. It works both ways, and both are equally guilty.
Back to that lip service I was talking about, you can really see just how far that philosophy goes from both companies actions – they still speak louder than words. As an end user, I don’t care about corporate bickering or what the political reasons are for Google not making a Gmail app for the iPhone, or Apple not integrating Google Voice – I just want the best experience.
2 – Google Latitude: Maybe
I’m not sure how to mark this one down. On one hand, there is indeed multitasking present in the operating system, as well as the ability to have certain applications periodically get location through location services. Thus, it’s finally possible for some enterprising third party developer to make their own google latitude updater, or for Google themselves to do it. We’ll probably see the former much earlier than the latter for the reasons I mentioned in part 1.
Of course, the software to do continual scheduled Google latitude position updating already exists through the Cydia store. It’s called Longitude, and it work fabulously. I’m relatively puzzled by Apple’s claims that getting a full GPS fix requires too much battery, since I already run Longitude on a 15 minute update interval and have experienced negligible battery degradation. In fact, even with updating set on a 10 minute schedule, there was no perceptable difference in battery life.
I really have to wonder whether location services through Skyhook without using AGPS (eg only WiFi triliteration augmented with cellular positioning data) will be accurate enough for services like Foursquare. Time will tell, and arguably GPS won’t solve everything since users that are already inside those locations can’t get a GPS fix anyways.
3 – Better Gmail Integration: Sort of
So the Mail application is getting a definite overhaul in this new revision of iPhone OS – more than one exchange account, faster switching between each inbox, unified inbox, and support for threaded conversations. These are long overdue features that the competition has had almost forever. WebOS has had it, BlackBerry is famous for it, Android has it alongside even a Gmail-specific version, and even Windows Mobile had multiple exchange account and fast switching integration.
So it’s nice to see everything finally getting revamped. Apple’s interface still is minimalist though; there’s no font settings or style options to be found.
4 – Notification Overhaul: Nope
This is probably the most sorely lacking area, and simultaneously the most inexplicably neglected. Every single other mobile platform has better notifications than iPhone OS. Every one of them, even old and exiled Windows Mobile. In fact, during the Stevenote today Apple showed off some local application notifications (from applications running in the background) that still resulted in annoying centered blue bubbles – and touted them as being a good thing!
I don’t know what more there is to say here other than that with a more robust multitasking framework needs to come a better notification framework. The two go hand in hand completely: if you lack the screen real estate to show more than one thing at a time, but can still run it on the hardware, get information to the user effectively. That shouldn’t still equate to pausing and interrupting the current interaction with a gigantic blue popup that needs to be dismissed before interaction can continue.
5- Background apps done right: Yes
Apple needed to nail this one, and they did. There’s no arguing that the multitasking framework they’ve demoed is the way things should be. I’ve argued a few times with developers that the best way to deliver multitasking without sacrificing performance is to open APIs for the most common use scenarios. Apple enumerated all of them: music in the background, task completion, location-specific scenarios (turn by turn GPS, Google Latitude, e.t.c.), and a few others. This is effectively what I’ve heard described as a secondary “lite” binary running the core services in the background, using fewer resources and a few background specific APIs the OS can manage. That way, the background experience is consistent across use scenarios.
I think that this will work really well in the long run. In fact, Apple really did have little choice but to adapt a scheme employing lite binaries; they’re limited to 256 MB of RAM on the 3GS and iPad. Steve Jobs gets it – giving the user a task manager might appeal in the short term for how much control it offers, but it’s just too much. If the user is honestly expected to micromanage application launches and closes, they’ll eventually forget and nuke the battery. It just happens.
6- Better App organization: Yes
Thank goodness this is finally being addressed. I’ve almost reached the 180 application limit for the iPhone 3.x’s page specific interaction schema, and getting to applications on pages at the very end is as frustrating as it is time consuming. Finally getting some high level organization in the picture, even if it isn’t forward thinking, revolutionary, or something new, still is valuable.
7- Better power management: Nope
Definite no, in fact, we’ll probably never see this, at least on the iPhone OS. This particular platform is all about lowest common denominator usability – it’s simultaneously what makes the platform so alluring and magical, and the subject of so much griping. You can’t build something a baby can use, and then expect them to understand how to manage their power.
At the same time however, the option should be there for those of us that are knowledgeable about it. I realize I’m asking too much, but it’d be amazingly cool to see hardware reports on projected battery longevity, current draw from individual hardware components, and a trend of power use.
Conclusions: 4/7 ~ 57% Nailed
So Apple implemented 4 out of the 7 things I outlined, if we’re pretty generous about our criteria. You know, on the whole, 57% isn’t bad, but it simultaneously isn’t a slam dunk on my part.
In fact, that’s what makes this industry so interesting. Unlike the desktop, we haven’t yet settled on a paradigm user interaction model – each major platform is actively innovating and evolving, and it’s happening rapidly. Even in the last two years, we’ve seen Android go from being an iPhone OS wannabe to a seriously polished, worthy competitor. We’ve seen that cross carrier availability is hugely important for success (people just don’t want to switch, and they’ll convince themselves that their network is best). We’ve seen that none of the platforms have it all worked out. Apple’s iPhone OS platform is too closed, while Android’s might be just too open (a-la Windows Mobile). It’s a rapidly evolving market out there folks; I’m enjoying scrutinizing every bit of it.
The other day, one of my Twitter followers asked if I could post a list of iPhone applications I have installed that are useful. Right now, there are quite a few (145 icons by my count). I’ll share a gallery of all of them, and post a list with links to the ones I really like or use a lot.
It’s a definite goal to reach the installed application limit, and admittedly the organization of just a bunch of tiles on a grid is already stretched thin. I originally did a better job organizing applications by page such that similar tasks or groups were all consolidated. For example, games are all on one page, utilities are on another, e.t.c., but it’s fallen apart lately.
The irony is that there isn’t an app you can install that will tell you what other apps are installed because of sandboxing reasons and App Store restrictions. Oh, Apple…
Some of my favorite and most used applications are:
- Speedtest.net – This is the iPhone version of Ookla’s speedtest.net. It used to be absolutely positively horrible. I mean not just totally false – but boldfaced staring you in the face wrong. They’ve improved it a ton in recent updates, and it now supports exporting to CSV as I’ve mentioned before, including all the geospatial, test results, and other relevant data. Makes analysis possible for end users, not just them.
- Xtreme Speedtest – Before Ookla got off their collective arses and made the speedtest.net application work, this was my favorite. I’m ashamed to admit I ran it as much as I did. Lately there haven’t been any updates or any love for even the paid “pro” version.
- Jaadu RDP – Hands down the best remote desktop application. It’s also the most expensive at $24.99, which is annoying, but it truly does work the best. Integration is just extremely smooth and well executed. There’s also Jaadu VNC.
- Mark the Spot – This should come preinstalled on every single iPhone. If you’re on AT&T, this is your best friend. It’s both a way to report bad connectivity and vent when coverage sucks too.
- BeeJive IM – All around best IM application. It was one of the first to really leverage push notifications well, and keeps you logged in for as long as you’d like. It’s a brave new world being logged into IM on the phone all the time, but if you want it, this is what’s awesome.
- Gass Cubby – Keeps track of gas mileage. It does an awesome job, and is fast and easy enough that I do it every time. It even syncs back up to the cloud for backups and storage, or if you have multiple drivers on a car. The graphical visualization and ability to correlate fuel economy changes with service is what really makes it stand out.
- iStat – Although the real beauty of this application is that it ties into the dashboard widget and server daemons of its namesake, it also works great as a simple resource monitor and informational view. There’s more info about everything here.
- SpaceTime – This is the absolute best computer algebra system for the iPhone. It’s that simple. There’s 3D plotting, derivatives, integrals, and just about everything else you can get from a Ti-89. I still like my 89, but this is the next best thing.
- Pi Cubed – Another really good mathematical tool, this one finally leverages the full capacitive touch screen of the platform. There isn’t a virtual keyboard or buttons, but rather a more intuitive interface with pretty print that’s better. I really like that it can export to PDF and LaTeX dynamically.
- iSynth and Seadragon - These are both awesome Microsoft Research Labs applications that exist on the iPhone. The former is a photosynth viewer created by a software intern as an independent project, and it works surprisingly well. The Seadragon viewer lacks the photosynth code and just displays images using the same sort of algorithm.
- iRa Pro and IP Vision – If you have a network camera that has MJPEG streaming outputs, these should be on your phone. No excuses. iRa Pro is an $899 application (last I checked, the most expensive in the App Store) but delivers absolutely unparalleled integration with the big enterprise camera setups including PTZ and up to 6 camera streams at a time. If you don’t have a fancy enterprise setup, IP Vision lets you view one MJPEG stream and 2 stills at a time, which is totally adequate for most everything. It’s what I end up using most of the time, and is considerably cheaper at $7.99 – there’s also a more expensive version that works with PTZ cameras.
- Pocket Universe – This was the first augmented reality application, and for its purpose, the implementation is superb. It’s designed to be an aide for amateur astronomers trying to find a particular celestial body of note. It uses compass and accelerometer data to point you in the right direction, toward finding it.
- JotNot – It’s a document scanner using your iPhone’s camera. The beauty here is that it removes the distortion based on edge detection, works for large documents, posters, books, and other rectangular, er, media. The other awesome part is that it tightly integrates for output over email, evernnote, WebDAV/iDisk, Google Docs, Dropbox, and Box.net. Either PDF or JPEG output with optional OCR to boot! I use this one a lot.
There are a ton of others that are installed, but these are the ones that really stick out to me as being relatively undiscovered. If you’ve got others you think are useful or related, I’d love to hear about ‘em in the comments section!
In case you missed it early, early this morning, my AT&T 3G MicroCell review is up and live at AnandTech here.
I played around with the product all last week and finally think I know all there is to be gleaned about it - undoubtedly in time the handover performance (which is pretty abysmal) will improve. It’s something that I talk about a lot in the article itself, but exists across all the major femtocells, and T-Mobile’s implementation of UMA. From a technical standpoint, the problem seems to be that the phone almost treats the femtocell like a roaming tower – implicitly disabling soft handovers to the public network. It’s handled this way most likely for a billing segmentation reason, but that’s unclear.
I learned in the comments that there are enterprise picocells, although I’m not sure what kind of carrier interaction is required for installation. I’d really like to investigate those for something future. Whatever the case, if you’re interested definitely give it a read!
Tomorrow’s big unveiling will likely be focused around the much-hyped, illusory tablet (whose name nobody even knows), but a large part of its launch will be iPhone OS 4.0.
Much debate has taken place regarding whether the tablet will run OS X, iPhone OS, or something in-between. Thanks in large part to an errant comment by the McGraw Hill CEO on MSNBC, I think it’s safe to assume that iPhone OS was the right guess all along.
Or was it? It’s likely that instead of releasing the tablet running the 3.x line OS, apple will launch a 4.x fork to bridge the handheld iPhone/iPod Touch experience with that of the tablet, and in so doing bring the mobile OS closer to its desktop counterpart. It makes sense considering keeping two disparate app stores running could cause a colossal flustercuck.
Since its launch in March of 2009, OS 3.x has begun showing some signs of age, especially compared Android 2.x. Here’s a list of what I think OS 4.0 needs to really keep the platform competitive:
1- Google Voice integration
Although Google just launched an HTML5 version of the google voice interface (no doubt specifically targeted at the iPhone and WebOS platforms), it still pales in comparison with how seamless Google Voice integration is on Android. Users of that platform can completely transition to their new number.
Plus, let’s be honest, using a web based version is just hackety compared to being able to use a much more responsive app without having to jailbreak. Until the day comes, I’ll stick with using the still-banned GV Mobile.
2- Google Latitude integration
This is the one that actually started the whole Google – Apple divorce, in case you have forgotten. It’d be amazing to finally see latitude integrated into the maps app the way it should have been the same month latitude launched.
Even better, the maps application (maintained by google) on BlackBerry OS and Android allows for seamless background position updating. As it is right now, iPhone OS users have to go to an HTML5-based version of the same application to update their position. Or jailbreak and use a solution like longitude (some screenshots/info here) and have it done on a schedule by a persistent background process. This is the solution I ultimately decided on
Perhaps this functionality isn’t allowed because of “duplication of functionality” with Mobile Me? Whatever.
3- Better gmail integration in the mail app
Let’s just come out and say it, the mail app on the iPhone is extremely barebones. Coming from Windows Mobile, I was kind of shocked at how barebones, in fact. No ability to change font, underline, bold, italicize, or do anything regarding formatting. As it is right now, the best you can do is some copy paste.
ArsTechnica really did a good job highlighting a number of subtleties that I’ve noticed in their article here. The most annoying of which is that folders aren’t fully synchronized until you go into them. For example, opening a sent folder will cause all the sent emails to load chronologically. This can get frustrating if you’ve sent a lot and just want to look at one; instead, you’ll have to wait for all of them to load. I can do without a unified inbox or unified messaging app, because honestly I view that as a more of a nightmare to be avoided than a feature.
But those aren’t my main gripe, it’s that there isn’t a gmail app (like what Android has) that supports Labels, Stars, or any of the features that make Gmail integration with email clients over IMAP or Exchange difficult. It’s that whole decision they made to not use “folders” and instead use labels that drives me crazy, and to this day, I’m lucky if I can find any sent email in my google apps account.
Forget about background and push, just fix the email client.
4- Notification customizations for SMS, scheduling
Even though the platform has good customization for ringtones, the alert sounds for system events such as email and new SMSes are surprisingly limited. In fact, at first, I assumed I was “doing it wrong” and failing at finding the proper way to load them. Nope, turns out, what you have is what you have, and what you will have forever.
That default “Tri-tone” sound is what everyone uses, and it’s annoying as hell to have it go off in a crowded room and watch 8 people all go for their phones (myself included). Allow some variety, without the need to jailbreak.
A lot of the other platforms also have alert profile scheduling. Namely, you can specify whether you should be alerted audibly, with vibration, or not at all, on a time schedule throughout the day. I’ve defaulted to always leaving my phone on vibrate simply because this is missing.
5- Background apps done right
This is probably everyone’s #1 wish for OS 4.0. Multitasking done right. Sure, you can jailbreak and do it, but it doesn’t lend itself to having a nice task-switcher. Instead, you’re left using what amounts to a task manager, which is completely the wrong way to do it.
Every other platform has it, only one platform (WebOS) has done it right so far. Can you, apple?
6- Better App organization
If you’re like me, you have 9 pages of applications that you’ve tediously organized. But sometimes, categories that are logical don’t come in sets of 16 (how many you can fit on one ‘page’). The real solution is to allow some sort of management. Be that folders, a menu, or something else.
Also, there’s no reason that people should be limited to 4 apps on the bottom row just for aesthetics when you have the room for 5. I couldn’t live without having 5 anymore.
7- Better power management – centralized reporting, on/off, scheduling
Something that I think Android really executed properly was the centralized power management screen. HTC has added this to virtually every single device in recent memory as well. That feature is centralized management of radio hardware and other large current draws.
This is something that, if executed properly, could also be a selling point for making hardware “green.” Hell, as a potential EE, I’d be absolutely in love with a screen showing current consumption from all the chipsets in the hardware that report it, plots of use vs. time, and more intelligent prediction of how much life I’ll get out of the device with current use.
But on a more basic level, what we really need is a feature that allows users to schedule the hardware itself. Imagine you’re on a trip without your charger; odds are, you don’t need the radio hardware on while you’re sleeping, but you do need the device on so the alarm works. Allowing users to schedule power events lets you balance use ahead of time.
But a feature I think is really needed is a so-called “last legs” setting. Basically, after the battery has crossed a user-defined threshold (say 15-25%), the software automatically does everything it can to preserve battery life; WiFi is turned off, 3G is turned off in favor of EDGE, screen brightness is reduced to 20%, push services are put on hold, email fetch intervals are doubled or quadrupled, background processes are killed.
The hardware and software essentially would work together to squeeze every last minute of use out of the hardware when battery gets low. This is especially important for when you cross the threshold while the phone is in your pocket, when you probably don’t even know it’s dangerously close to death.
Historically, Apple delivers products that have extremely polished, working features. Essentially, they err on the side of only releasing features that work, always work, and work well, instead of releasing features that don’t always work, or lack polish.
That said, a lot of the market has caught up since 2009. It’s time to address all of those gripes, and I’m hoping OS 4.0 fills some of the glaring holes in the feature set tomorrow. We’ll find out soon.
Something that’s bugged me for a long time is how crude and arbitrary signal bars on mobile phones are. With a few limited exceptions, virtually every phone has the exact same design: four or five bars in ascending order by height, which correspond roughly to the perceived signal strength of the radio stack.
Or does it? Let me just start by saying this is an absolutely horrible way to present a quality metric, and I’m shocked that years later it still is essentially the de-facto standard. Let me convince you.
It isn’t 1990 anymore…
Let’s start from the beginning. The signal bar analogy is a throwback to times when screens were expensive, physically small, monochromatic if not 8 shades of grey, and anything over 100×100 pixels was outrageously lavish. Displaying the actual RSSI (Received Signal Strength Indicator) number would’ve been difficult and confusing for consumers, varying between 8 already difficult to distinguish shades of grey would have been hard to distinguish, and making one bar breathe in size could have sacrificed too much screen real estate.
It made sense in that context to abstract the signal quality visualization into something that was both simple, and readable. Thus, the “bars” metaphor was born.
Since then, there have been few if any deviations away from that design. In fact, the only major departure thus far has been Nokia, which has steadfastly adhered to a visualization that makes sense:
Namely, their display metaphor is vertically ascending bars that mirror call quality/strength. This makes sense, because it’s an optimal balance between screen use and communicating the quality in an easy to understand fashion. Moreover, they have 8 levels of signal, 0-7 bars showing. Nokia should be applauded for largely adhering to this vertical format. (In fact, you could argue that the reason nobody has adopted a similar metaphor is because Nokia has patented it, but I haven’t searched around)
It’s 2010, and the granularity of the quality metric on most phones is arbitrarily limited to 4 or 5 levels at best.
Thus, an optimal design balances understandability with level of detail. On one hand, you could arguably simply display the RSSI in dB, or on the other hand sacrifice all information reporting and simply report something boolean, “Can Call” Yes/No.
Personally, I’m waiting for something that either leverages color (by sweeping through a variety of colors corresponding to signal strength) or utilizes every pixel of length for displaying the signal strength in a much more analogue way.
Green and red are obvious choices for color, given their nearly universal meaning for OK and OH NOES, respectively. Something that literally takes advantage of every pixel by breathing around instead of arbitrarily limiting itself to just 4 or 5 levels also wouldn’t be hard to understand.
Fundamentally, however, the bars still have completely arbitrary meaning. What constitutes maximum “bars” on one network and device has a totally different meaning on another device or carrier. Even worse, comparing the same visual indicator across devices on the same network can often be misleading. For example, the past few months I’ve made a habit of switching between the actual RSSI and the resulting visualization, and I’ve noticed that the iPhone seems to have a very optimistic reporting algorithm.
There’s an important distinction to be made between the way signal is reported for WCDMA versus GSM as well:
First off one needs to understand that WCDMA (3G) is not the same thing as GSM (2G) and the bars or even the signal strength can not be compared in the same way, you are not comparing apples to apples. The RSCP values or the signal strength in WCDMA is not the most important value when dealing to the quality of the call from a radio point of view, it’s actually the signal quality (or the parameter Ec/No) that needs also to be taken into account. Source
That said, the cutoff for 4 bars on WCDMA seems to be relatively low, around -100 dB or lower. 3 bars seems around -103 dB, 2 bars around -107 dB, and 1 bar anything there and below. Even then, I’ve noticed that the iPhone seems to run a weighted average, preferring to gradually decrease the report instead of allowing for sharp declines, as is most usually the case.
Use dB if you’re not averse to math
What you’re reading isn’t really dBm, dBmV, or anything really physical, but rather a quality metric that also happens to be reported in dB. For whatever reason, most people are averse to understanding dB, however, the most important thing to remember is that 3 dB corresponds to a factor of 2. Thus, a change of -3 dB means that your signal has halved in power/quality.
The notation dBm is refrrenced to 1 mW. Strictly speaking, to convert to dBm given a signal in mW:
Likewise, to convert a signal from dBm back to mW:
But even directly considering the received power strength or the quality metric from SNR isn’t the full picture.
In fact, most of the time, complaints that center around iPhones failing to make calls properly stem from overloaded signaling channels used to setup calls, or situations where even though the phone is in a completely acceptable signal area, the node is too overloaded. So, as an end user, you’re left without the quality metrics you need to completely judge whether you should or should not be able to make a data/voice transaction. Thus, the signal quality metric isn’t entirely a function of client-tower proximity, but rather node congestion.
Carriers have a lot to gain from making sure their users are properly informed about network conditions; both so they can make educated decisions about what to expect in their locale, as well as to properly diagnose what’s going on when the worst happens. Worse, perhaps, carriers have even more to gain from misreporting or misrepresenting signal as being better than reality. Arguably, the cutoffs I’ve seen on my iPhone 3GS are overly optimistic and compressed into ~13 dB. From my perspective, as soon as you’re below about -105 dB, connection quality is going to suffer on WCDMA, however, that shows up as a misleading 3-4 bars.
What we need is simple:
- Transparency and standardization of reporting – Standardize a certain visualization that is uniform across technology and devices. Choose something that makes sense, so customers can compare hardware in the same area and diagnose issues.
- Advanced modes – For those of us that can read and understand the meaning of dB and real quality metrics from the hardware, give the opportunity to display it. Hell, perhaps you’ll even encourage some people to delve deeper and become RF engineers in the future. It’s annoying to have to launch a Field Trial application every time we want to know why something is the way it is.
- Leverage recent advances in displays - Limiting display granularity to 4 or 5 levels doesn’t make sense anymore; we aren’t constrained by tiny monochromatic screens.
- Tower load reporting - Be honest with subscribers and have the tower report some sort of quality metric/received SNR of its own so we know which path of the link is messed up. If a node is congested, tell the user. Again, people are more likely to be happy if they’re at least made aware of the link quality rather than left in the dark.
Today, Google finally announced the much-hyped, finally-official googlephone at their Mountain View office. Admittedly, there wasn’t much about the actual announcement that wasn’t previously known; specs, photos, and even an entire review had already leaked out before the official announcement. But the announcement marks google’s first real step into distributing google-branded hardware directly to consumers, the entry of another google-blessed flagship for the Android platform, and a different, long-needed business model for selling phones and wireless contracts.
It’s been a year, 2 months, and 14 days since the launch of the T-Mobile G1, and Android has matured into a serious contender since its beginnings as an aspiring platform in a market dominated by Windows Mobile, Symbian, and the iPhone OS. While the G1 seemed awkward in a kind of adolescent manner, it’s chin a strange design ‘feature,’ its storage ultimately limited, and design-by-committee UI/navigation (anyone remember “how many clocks does it take for google engineers to tell time?”) the Nexus One is finally enough to make it a real iPhone contender alongside the Droid.
That said, the platform does still suffer from a number of notable shortcomings:
- Application storage limited to 512 MB partition
- (Which google says it will fix by allowing applications to reside on an encrypted partition on removable storage, soon)
- No multitouch within official applications
- (This strange choice likely stems from legal and patent concerns between Google using Apple IP/prior artwork. Google likely doesn’t want the whole board-member-sharing fiasco to undergo any more scrutiny than it already has)
- Slower web browsing
- (Flash? more on that in a second)
- No support for CDMA (Verizon) until spring, AT&T 3G band support unclear
- (Rumors abound that Google is working on an AT&T version, but only a “dozen or so employees have access to this hardware”)
I’m going to expand on numbers 2 and 3, since personally I find these the most interesting immediately.
Engadget did a rather thorough of the Nexus One, pre-empting it’s announcement (karma for the same way Google tried to pre-empt CES?), and notably included a quick and dirty comparison of the loading speed of browsers on the iPhone 3GS, Nexus One, and Droid. Qualitatively, the winners and losers are painfully obvious from the video, but I took down some times and came up with the following:
- iPhone 3GS – 17 seconds
- Nexus One – 71 seconds
- Motorola Droid – 82 seconds
What immediately sticks out is that it took both of the Android 2.x platforms roughly 4 times longer to load the same website as it did the 3GS.
Initially, this doesn’t make sense. The 3GS is sporting a relatively recent ARM Cortex A8 underclocked from 800 MHz to 600 MHz, while the Nexus One is running the latest (also much-hyped) Qualcomm Snapdragon SoC running at 1GHz (Qualcomm QSD 8250 according to Google). The Snapdragon SoC is extremely similar architecturally to the Cortex A8, so comparing clock speeds is roughly applicable. Then, why the heck is a newer, faster generation chipset clocked 66% faster 4 times slower? Heck, the Android browser even runs lean and mean WebKit at its core, same as Mobile Safari on the iPhone, and Chrome and Safari on the desktop. Why then is it so much slower?
My theory? Flash.
The same multimedia platform hogging resources on the desktop is now hogging resources and slowing down browsing on mobile devices. Excellent. Sure, there’s a lot of content out there that’s driven by Flash that’s useful: videos, games, navigation, photo websites, fancy UI. But what’s the biggest reason? Advertising. Adobe knows it, I mean, just watch their video on mobile flash and notice what they highlight. Advertising.
Up until now, browsing just about everything on all the modern smartphone browsers I’ve used (mobile safari, opera mobile, opera mini, IE mobile) has been usable without adblock primarily because they didn’t have support for flash. Unless mobile browsers begin allowing plugins such as adblock or similar (similar to how mobile firefox, aka Fennec has begun doing), Flash is something I’d rather see disabled than enabled. How much of a feature is it to waste not just performance, but ever-critical battery on a mobile device primarily to show animated and intrusive advertising?
No AT&T 3G, Just T-Mobile
A lot of what Google was really trying to do with the Open Handset Alliance, launching a phone that customers can buy almost directly from HTC (the Nexus One OEM) and introducing essentially a new mobile business model at the same time was abstracting the carrier away from the device.
That is, handsets are increasingly moving towards being carrier-agnostic. In reality, this is the way it was intended to be (and moreover, should have been, at least in GSM-land). In fact, while this business model is entirely new to the US, the portability of handsets using SIMs is nothing new to customers in Europe, who frequently purchase handsets unlocked and bring plans (and SIMs) with them. (As an aside, much of the reason CDMA became dominant in the US was because this same flexibility wasn’t part of the specification; the unique identifier is built into the phone itself in the form of an ESN/MEID.)
It follows, then, that if Google truly wanted to create a splash in the industry and achieve its goal of creating and directly selling the ultimate flagship device that’s totally carrier agnostic, they would have made absolutely certain that HTC built in either multiple radios for UMTS and CDMA, or some modern, hybrid UMTS/CDMA chipset similar to the Qualcomm MSM6200 (PDF link) rumored to be at the core of the next-gen iPhone.
Whatever the case, the decision to launch hardware that at present restricts it to T-Mobile for 3G, EDGE on AT&T, and no CDMA functionality at all, extremely limits the device and ultimate impact. Moreover, it means that HTC and Google are going to have to support 3 sets of unique hardware for the “Nexus One” name. One with a CDMA-stack version for Verizon/Sprint, the current incarnation for T-Mobile, and a final version supporting AT&T’s 3G frequencies. Perhaps even more if they eventually move to support additional carriers in Europe and Asia.
Personally, I find it heartily ironic that rumors abound Apple is using a hybrid UMTS/CDMA chipset in the next gen iPhone. If so, that would make the same iPhone so many complain about because of its exclusivity with AT&T, the most open.
More open, in fact, than the Nexus One.