tech.am

It actually indicates GPRS attachment status, the capability (or lack thereof) of sending and receiving data, be it over plain old GPRS, or the faster EDGE. I was going to comment on the original Engadget blog post, but after seeing a few pages of comments already, I doubt they would have noticed it. This is where they get it wrong:

You’ll notice the iTunes WiFi Store icon, and an O2-UK network symbol up top. If you look carefully, you’ll see that the E logo for EDGE is missing: we guess that 30% network coverage on O2 don’t quite stretch inside the Apple Store.

A bit further down, they mention this again:

O2 iPhone on the left, unlocked US iPhone on the right (running on T-Mobile’s UK network). Note that the O2 iPhone doesn’t show the EDGE logo, but the unlocked phone on T-Mobile does. You can probably guess at what we’re getting at here: O2’s EDGE coverage sucks.

In this particular side-by-side photo, T-Mobile’s coverage is marginally lower than O2’s, but they should both be capable of sending GPRS traffic. Another reason they get this wrong is that the waves icon ‘overwrites’ the E symbol while the iPhone is connected to a WiFi network, so you could still have GPRS/EDGE attachment in the background, so-to-speak. In my particular case, the iPhone is happily registered on Vodafone Spain, and is attached to GPRS (no EDGE here at all), showing the E while I’m not in range of WiFi.

The iPhone also does something very clever – when you open an application that requires a data connection, it will start a GPRS attach and session, while it asks you if you want to join any of the nearby WiFi networks (if any). In case you say no, the alternative data connection is already established, cutting down on extra waiting time before you start seeing content on your screen. This may seem stupid to Europeans, by default stuck with hugely expensive pay-as-you-go data (50 Euro cents per 250kB!!), but with the original AT&T voice + data plan, it does not really matter.

I’m pretty amazed at the latest gadgets coming out from the R&D departments of consumer electronics companies, such as Nokia and Apple – the N95 is a super-duper, do-it-all, cellphone (sorry, Nokia wants us to call it a ‘multimedia computer’), featuring multiple bands, HSDPA 3G (Europe only), WiFi, GPS, and a 5Mpixel camera, apart from a wide array of software tools for blogging, posting pictures online, navigation and more. What price does this device pay? A meager 950mAh battery, which lasts less than a day under normal use, considering ‘normal’ as actually using the functionality it offers. I guess you can get more if you turn off the GPS, WiFi, don’t use the camera, and make almost no calls…but then what good are all the bells & whistles for?

The iPhone case is even more interesting, as the device has not been released yet, but Apple has already reported an increase in battery life with respect to the initial quoted value. The iPhone will have 8 hours of talk time, and some 250 hours of standby time, with 5 hours of video and 24 hours of audio playback. Apple’s stock has jumped $3 since the announcement, something that will make losers in the fake email crash happy.

Let’s try to make a simple breakdown of power consumptions, and see if manufacturers are being overly optimistic.

WiFi

One of the biggest power drains, as there is no built-in power management into the WiFi protocol, contrary to GSM and 3G. When transmitting over GSM, a phone makes calculations from data received from the network and its own measurements in order to adjust RF power to the minimum required to reach the cell’s base station. Thus, in areas of good coverage, a phone can be consuming far less power than in rural areas with more spotty coverage. While on a 3G network, the rate of adjustment is even higher. WiFi chipsets in mobile phones have basically two settings, “high” and “low”. Most times, unless you are sitting right next to the access point, and without any major interference, the setting the phone will use is “high”.

Assuming that the WiFi chipset used by the Nokia N95 and the iPhone use little power, for example, by fitting the Nanoradio solution, the power consumption would stand at 130mA in transmit mode, 53mA in receive mode, and 50uA in standby mode. Assuming we are receiving 80% of the time, for example, by browsing the web, the average consumption would stand at around 68mAh. The N95’s battery would last 13 hours, if it had to power the WiFi chipset alone.

GPS

Even though GPS technology has advanced a lot since the early days, GPS chipsets can draw upwards of 80mA. Special trickle-power configurations (which also impact performance) can reduce this to 50mA or so. Thus, the N95’s battery could power the GPS for around 19 hours.

Processor

The Nokia N95 features an ARM11-based Texas Instruments OMAP2420 running at 330MHz, featuring 2D/3D video acceleration on top of whopping performance. What does this mean in electrical power terms? Even though this processor features SmartReflex technology, which reduces static leak currents (a good technical overview is available here [pdf]), the net current drawn is around 30mA. The N95 battery could power the main processor for around 32 hours.

Display

The display on the N95 is very good, beautiful, 16M colors, 240×320 pixel resolution. It is also power hungry, taking around 30mA, thus, the battery could also power the display for around 32 hours.

Phone

Assuming that you talk 5% of the time on the phone, the average power consumption by the phone subsytem alone would stand around 20mA, resulting in a battery life of 47 hours.

Adding things up

So far, we have seen how much the battery could keep running each individual system on the phone, but adding things up, we have a power consumption of about 100mA (taking into account that we are not using everything at once, I halved the figures). This results in around 9.5 hours of operation, more or less an average day. This ties in with most users’ experiences, as shown in many reviews done so far on the N95.

The iPhone, being much thinner, wider and taller than the N95, probably won’t have that much larger battery capacity – why does Apple give the figures they do, I can only blame on the marketing department. This is not as uncommon as it seems, R&D provides a set of carefully calculated and actually measured results, then the marketing guys take them and multiply them by two. Anyone who has used a modern, high-end phone or PDA, will attest to the fact that quoted battery life figures differ from reality by far. I don’t know of many companies that can raise their stock $3 by simply increasing the value of the battery life in one of their products – this shows how much hype there is around the iPhone (of which I’ll most definitely get one…they are soooo sexy!).

No pun intended, honestly, but Tony Smith’s article on The Register’s RegHardware ‘How to get your Wi-Fi working again‘, while making a nice and broad effort at examining the problems plaguing WiFi nowadays, and reviewing several options to improve your experience around WiFi, also uses somewhat pseudoscientific methods to measure things like signal strength.

Not that the N1 is a poor choice. Belkin’s software makes set-up a doddle and it’s handily compatible with both 802.11b and 802.11g for older, un-upgradeable devices. I hooked the N1 up to my cable modem, and was quickly up and running with the 802.11n USB adaptor plugged into my Vaio in the next room. Here, the signal registered as four blocks, two higher than the 802.11g RangeMax router yielded in the same location, albeit at a different time.

What exactly is four blocks? -60dBm? -110dBm? Cutting Tony some slack, he attempts to explain the issues and measurements in layman’s terms, so that as many people reading the article as possible will understand what he is talking about, but still, there are better ways to measure performance of WiFi networks. Signal strength readings are as reliable as my 90-year-old granny at the shooting range, save for a few cards which provide pretty accurate figures. A good measure of the performance, or lack thereof, in the various setups he studies, could have been net throughput. There are various tools to do this, such as the excellent yet very simple NetCPS from Netchain Communications. In WiFi, throughput is proportional (amongst other things) to available wireless bandwidth, that is, theoretical bandwidth minus artifacts such as interference and background noise – thus, between two particular machines, NetCPS would provide a good sense on how good a combination of routers, bands and adapters is performing.

You probably have seen the video on YouTube about a molten Fonera, apparently due to overheating, which shows the plastic case completely deformed. Gizmodo (also in spanish) and other sites are also reporting on this. As usual, Fon has censored the post on their forums that broke the story, but alas, thanks to their partners at Google, here is a cached version. Even Martin Varsavsky seems worried about this. It seems the damage is obviously from heat, but could it have come from the Fonera itself?

I, and others, have our doubts about wether this video is a fake stunt, or a true story. It is true that the Fonera overheats, much more than would be expected from a consumer-electronics product, but to the point of causing physical damage to the plastic case?

The heat problem

Heat in electronics mostly comes from dropping voltage by converting current into it, in our case, the voltage regulator in the Fonera drops 5V to 3.3V at 500mA, resulting in the dissipation of 850mW. That’s right, we are dumping 850mW right into the atmosphere in the form of heat. This brings the operating conditions very close to the maximum ratings for this regulator, which has a maximum rated thermal resistance of 90ºC/W, my calculations put the operating conditions at 88ºC/W. Additionally, the wireless section of the Fonera is also converting a lot of energy into heat.

The measurements

After I finished my tests, I got a comment from Pobletewireless, regarding his own measurements of the heat problem, which are shown in very cool thermographs (no pun intended!) – much nicer than my rather rudimentary method.

I measured the temperature of the Fonera using a thermocouple connected to a Fluke 123 Scopemeter via an 80TK thermocouple module. The thermocouple was placed in between the heatsink and RF shield, the case closed, and the Fonera powered, as can be seen in this picture:

After 10 minutes operating normally, the temperature had risen to an average of 72ºC, with a peak of 80ºC.

The second batch of measurements were performed drilling four small holes to allow the thermocouple into the casing, the locations are shown in the following picture:

Maximum temperature at one corner was 43ºC. Next, an attempt was made to melt the white lid of the Fonera, by exposing it to a high temperature airflow from a paint-stripping gun, and at the same time, applying slight pressure from below. The thermocouple was used to measure at which point the plastic became maleable, and deformation started. At around 100ºC, the plastic was soft enough that a solid object could change its shape – this is in line with ABS plastic thermal properties, which state a deflection temperature around 100ºC, depending on specific material composition.

As the deflection point test resulted as expected, the lid was then exposed to an airflow at 280ºC for two minutes. The result of this exposure is shown in the pictures below:

It’s obvious that some deformation has taken place, with discoloration and charring on the point where heat was directly applied. However, the front side of the lid had mostly retained its shape.

Conclusions

The Fonera does indeed run very hot, much hotter than it should, if anything, for the good of the internal parts. Electronic components are sensitive to heat, with maximum ratings given by each manufacturer in terms of storage and operating conditions. The higher the temperature, the lower the service life of any given component. Some are affected more than others, most notably, electrolytic capacitors have a high sensitivity to heat, as it can evaporate the electrolyte quicker, causing it to fail. The capacitors in the Fonera are made by Taicon, a taiwanese manufacturer, and are max-rated for 105ºC. From the datasheet [PDF], at this temperature, the capacitor will fail after some 2000 hours, around 83 days. Following Arrhenius’ Law, and since the area around the capacitors was found to be at around 52ºC, their expected life would be 7800 hours, or about 325 days – what a coincidence, almost a full year, after which your warranty has expired. Comparing the Fonera to a Meraki Mini, one realises that there is a serious design flaw, as apart from the Mini having a switched-mode regulator, the wireless section shares exactly the same design as the Fonera. The temperature measured outside the casing of the wireless section indicates that the junction temperature of the components inside has to be ridiculously high. So, one conclusion is that the Foneras will eventually fail due to overheating, and it will probably happen sooner than later.

On the deformation / melting video – in my opinion, it’s not real. At least, it couldn’t have happened without the Fonera reaching temperatures around the whole casing that would have caused some components to blow up (for example, the capacitors). The Fonera could not have undergone such an extreme temperature, and still function as shown on the video. The temperature gradient between the heatsink and one corner of the case is almost 2:1, thus, to reach a deformation temperature of say 200ºC at the corner, the heatsink must have been running at 400ºC! A final bit of evidence – the sticker. If you look closely at the video, the sticker on the bottom of the Fonera looks almost unscathed. Here is a picture of what it looks like after applying a 250ºC airflow for 30 seconds, which causes the plastic to deform:

Obviously, a more prolongued exposure would have damaged it even more. In all honesty, I would love to get more details from the guy who made the video, as it stands right now, I’d call it a hoax.

I got a tip today that Fon is looking at launching a new router with a LAN port, apart from the WAN port found in the current Fonera (they seem to privately admit not having a LAN passthrough was a rather big mistake).

With the current Fonera, you cannot access devices on the wired side of the network (such as a SAN drive or printer) from the wireless side, be it using the public or private SSID, you are effectively NATted from your own network. A LAN port would solve this the same way as it is done in higher quality devices such as the Linksys WRT54 series.

What really surprised me was to see that these routers have already been shown by Accton, the OEM that manufactures the Fonera on their website for a few weeks. Check out these links, datasheets in PDF available, for a white-label Fonera, a Fonera with LAN passthrough, and what looks to be the Fon Liberator, having a USB port and BitTorrent client built-in! Martin Varsavsky recently put the release date of the Liberator back a few months, originally scheduled for Christmas 2006, citing technical difficulties.

Now, either Accton wants to score a goal taking advantage of the publicity offered by Fon, or Fon didn’t pay an exclusivity fee for the design of these routers, or both. One million routers by 2010 is nothing by asian manufacturer standards, but they do allow buyers to secure exclusive designs. Copies could still be found, but not as prominently and by the same manufacturer making their own.

I wasn’t sure that Accton was the designer behind the Fonera, and gave Fon the benefit of the doubt of actually having developed something themselves in the electronics field, but now it seems clear that Accton is the designer of the hardware platfom, so there wasn’t that much development by Fon after all (the firmware was created by the hackers behind DD-WRT and OpenWRT).

It was only a matter of time until the developers of open-source firmware OpenWRT and DD-WRT managed to port the OS to the Fonera, which is based on an Atheros chipset. As described in this thread of the DD-WRT forums, there is a firmware package available for download, which can be flashed onto the Fonera, thus replacing FON’s original firmware and functionality. I think it will be a matter of time until we see reflashed Foneras on eBay, just like we saw Linksys once upon a time.

The hack is not for the faint-hearted, and so you risk bricking your router if the flashing fails – there is still a way to de-brick using the serial port, but in any case, don’t try this at home unless you know what you are doing. We are on the cutting edge of the development, which eventually trickles down into easier-to-follow HOWTOs and step-by-step guides.

Leaving aside regulatory issues that may turn this particular setup into an illegal operation, I will better not describe the quality of the installation to be polite. Check out this picture:

Spotted the problem yet? Radio antennas are affected by any element that is present around them, even non-metallic elements, such as the ground. In this particular case, kanijo, a Fonero, has attempted to provide more “range” to his FON hotspot, which is in itself commendable, however, the means may not result in the desired end – original FON forum thread here.

You can see that the vertical omni antenna, a carefully tuned radiating element, has been strapped to a metallic pole, which also runs a coaxial cable into a TV antenna right on top. The router is inside a sealed plastic box, with power and Ethernet going into it from below. There is no way that this antenna is radiating correctly, as the pole that supports it is probably grounded (if it has been installed according to regulations), and even if it is not, it is inducing an imbalance into the tuned element, causing a large amount of RF to be attenuated. The user reports good results with it, which are most likely due to good luck.

The second problem with this type of setup is that vertical antennas don’t emit downwards, and thus will provide very limited coverage to users below the antenna. There is some downwards bleed of course, but it will only reach lower users that are some distance away from the antenna.

Recommendations for these sort of setups: install the antenna right at the top of its own pole, and ground the pole. If you have no choice but to use an existing pole, get a T arm fitting and mount the antenna at least 1 meter (3 feet) away from the pole. A perfect example of such as setup, in this case with two supports as the antenna is rather large and care for wind load is needed, is this (credit to Roger Halstead):

Check out Roger’s page, it is a very good read if you are interested in radio installations.

The guys at Pobletewireless have been busy with the Fonera lately, and have now posted a step-by-step hack to add a DB9 connector that allows easy access to the built-in serial port, without having to make IDC cable headers and so on. [Link]

The hack gives access to the console, with which you can do all sorts of nice and interesting things.

You probably remember the post I made regarding FON’s figures, and how much I thought they differed from reality. It got quite a lot of attention, particularly from detractors, and from Martin Varsavsky himself. Many comments were posted on my blog and some others, which pointed towards the fact that I am involved in a startup which supposedly is a clone of FON, and thus I was biased and in no position to comment on FON. To cut a long story short, Martin posted a rather vicious personal attack on his blog, which I answered, he counter-commented, to which I again answered, but he never conceded a bit.

During my investigations that led to the statistics post, I also discovered a serious flaw in the maps management system, which would allow anyone to re-position any FON hotspot and change its address without first logging into the user area.

All that was required was the node’s ID and the hotspot owner’s user ID, both easily obtainable from the public queries that maps.fon.com launches against the database where hotspot data is held, and which I used to gather the statistics. For a determined attacker, it would have been very easy to place every single FON hotspot right in the middle of 1600 Pennsylvania Avenue, Washington DC.

I could have very easily posted about this, but I refrained from doing so for a reason – while I do not work full-time in the IT security industry, I have done quite a bit of consultancy work in the past, related to IT security, particularly in the wireless field. This means that I am fully aware of the industry-approved vulnerability disclosure procedure, which can be explained simply as:

• Document the vulnerability, and inform the company about the fact that you have found it.
• Wait for an initial response, establish contact points, and work a schedule for fixing the issue.
• Work with the company to help them solve the issue.
• Once the issue has been fixed, make a public disclosure on both sides about the vulnerability, giving credit to the person or company that discovered it.

You can find more references to this policy at Microsoft’s Security Response Center, here and here. A PDF from oisafety.org also describes this process in detail. A perfect example on how not to do things is the recent disclosure of a code injection vulnerability, which allowed manipulation of FON’s routers without even having to open them – even though their points are valid, they should have given FON the chance to fix the problem before going public.

In this case, I contacted FON’s support email first September 27th, and received a response on the 29th. This was really generic, only wanting to know about the details, and not acknowledging the normal procedure as I have explained above. On October 2nd, I emailed them again, asking to confirm that they understood the procedure, and on the 3rd they replied that they agreed on following the procedure.

I started compiling the information I had into a working document, but after becoming so frustrated at the attacks received as a result on my post about the statistics, the decision was to simply let the issue go, forget about FON, and concentrate on my own project. A couple of days ago, browsing around for stuff to clean up on the laptop, I came across the half-written report, and decided to finish it and send it to FON support, with CC to Martin, just to close the case. I received a reply today that they have in fact fixed the vulnerability, with a short ‘thanks’ (actually, quoting his email in full: “thanks Mike, i understand its been fixed”) from Martin.

The public acknowledgement of the discovery posted by FON is found in this forum post. Only in the English forums, by a user created apparently for this particular purpose, as this is his first post ever, where it is not likely to draw much attention. This would be fine by me, had not there been the precedent of Martin’s fierce replies to my statistics post, followed by countless attacks by FON’s followers, including an unfortunate incident better left forgotten. What I really cannot understand is that, when I criticize FON, I get such a huge public lashing, whereas when I help them out, I get a three-line remark in a forum where it will go mostly unnoticed. The end result may well be that other vulnerabilities, and it is likely they exist, go unreported.

Whatever the case, this should show those who accused me of unfair, biased attacks on FON that I really just call the shots as I see them, when I smell bullshit, I will point to it, when I see a hole, I will help them fix it – again, IMHO, blogging is not about being or not biased, it is about being ethical and maintaining a set of standards. In my view, it should also prompt Martin to write an apology, but I am not holding my breath. Not that I care much either, what is most important is my work; this is my blog, where I spend part of my spare time, which is not actually that much.