Martin – Page 148 – WirelessMoves

Two Updates Fail Massively Within The Hour – The Internet Came To The Rescue!

When updating the software of my devices I am usually a bit cautions and wait a couple of days after patches and updates are announced just in case it is discovered that the update breaks something and needs to be fixed. While this tactic usually works it somewhat failed me recently when two updates massively failed within the hour. Luckily the Internet came to the rescue.

The first major fail occurred when updating the Ubuntu distro on my media PC from 13.04 to 13.10. While everything looked fine during the update, the system would not let me log on after rebooting. All I saw was a mysterious error message after typing in my username and password before I was thrown back to the login prompt. WOT!? One can be skeptical about Google but they do find things quickly and thus rescued the day. Only a few hours before somebody posted a fix for the issue: Switch to the console and unistall Cinnamon and the Nemo file manager which I installed previously as Ubuntu has castrated the Nautilus file manager to be basically uselessness. Could this really be the issue? I was skeptical at first but it worked and I could log in again. So much about installing software from third party repositories… Fortunately, the Nemo file manager made it into the official Ubuntu repository in the meantime and I could re-install it from there without the issue re-appearing.

Once that was fixed I updated Thunderbird to apply the latest security patches on my production notebook. That can't possibly go wrong now can it? It seems it can as I stumbled right into the next issue. After restarting Thunderbird, the Lightning calendar just showed and empty window. WOT!? Two minutes and another Internet search and I found out that for a yet unknown reason, updating Thunderbird broke the plugin. The solution: Downgrade Thunderbird until Lightning is updated as well. Fortunately I do not use the pre-packaged Thunderbird so I can apply security patches quicker than with the default Ubuntu install. I guess that saved me this time as I just had to rename the directory and download the previous version again.

So was I too quick with the updates? Perhaps, but from a different point of view my somewhat cautious update behavior has saved me nevertheless. If I had updated both systems earlier I would probably not have found a fix for both issue on the net. And while I can live with a broken media PC for a while, a broken Thunderbird on my production notebook would have been totally unacceptable. So perhaps I waited just long enough.

Another takeaway from this is that without people out there sharing information via blogs, message boards and other means, things would be a lot more difficult and some even impossible. And it's not an overstatement, I still remember how desperate I was sometimes in the days when I 'only' had books e.g. to learn programming and getting stuck often meant hours searching for an answer in seemingly endless trial and error loops.

The Difference Between The Early Years of UMTS And LTE

Back last month I was musing about how 2G we still were only 10 years ago which makes it even more amazing what has happened since in the mobile domain. When looking at UMTS and LTE and how they were used in their early years I see a striking difference. When UMTS first launched it took quite a while for devices to actually become available and even longer before there was a general take-up. For quite a number of years, UMTS base stations were just sitting there producing heat but were actually little used.There were probably a number of reasons for this. One was certainly that mobile Internet access was a novelty and only used by few. In addition, content readable on small screens was even scarcer. And on top, screens were tiny by today's standards and devices were bulky. Not a good mixture for fast take-up.

With LTE the story is quite different. There was perhaps a time span of one year after the launch of networks during which networks were mostly used with LTE capable USB data sticks. The situation changed quite quickly, however, due to devices such as the Samsung Galaxy S-III and the iPhone becoming LTE capable. Yes, there were certainly other LTE smartphones available before those two but those still seemed to have something of an experimental character to me and probably weren't sold in high volumes. And LTE had the invaluable advantage that by the time the networks were launched, mobile Internet access had become mainstream, devices thin and screens large enough for enjoyable media consumption.

And here's my personal LTE timeline:

2009: Lot's of talk about it, but nothing commercially deployed
2010: Experimental network deployments
2011: Mass rollout of networks
2012: First LTE capable smartphones that could actually be bought became available
2013: Real LTE usage with the iPhone 5 and Samsung Galaxy S-III

The DIY-CPU Project – Experimenting With RAM Using a Raspberry Pi

Now that I know a couple of ways how to build a clock generator I've moved on to the next step and have started looking into what kind of RAM I want to use for my Do It Yourself CPU (DIY-CPU). Here's the story of how that went:

As it's an experimental system I only need a couple of bytes of RAM to hold a short program and a few bytes of data. I don't want to build it myself, however, as I feel confident that I understand how static RAM is composed of flip-flops, how flip-flops are built with gates and why they have two stable states. Therefore I had a look around for a small off-the-shelf RAM chip that I can.

The smallest static RAM chip I could find has a size of 8 kilobytes which sounds very little by today's standards of course. However, that is far beyond what I need anyway, I would have already been content with a 256 byte version. Anyway, so I bought an 8 kB CMOS RAM chip and for those who'd like to take a closer look you can find the datasheet of the WS6264 here.

To get a feeling of how I can write data into the chip and get it back out again I used a breadboard to experiment a bit. To make life a bit easier I decided not to use physical switches and LEDs to control and read data from the address and data buses. Instead I decided to use a Raspberry Pi with a Pi-Face extension board that offers 8 digital inputs and 8 digital outputs and the flexibility of Python programs to read and write data on the various pins of the RAM chip. As 8 inputs and 8 outputs are obviously not enough to control all of the 8 address bus pins, the 8 data bus pins and the various enable and set lines I had to simplify a bit and only use 3 bits of the address bus and 3 bits of the data bus and grounding all other lines. In other words I limited myself to reading and writing 2^3 = 8 bytes. More than enough to get a feeling for how to read and write data into the chip. In addition to the bus pins I also control the Output Enable line and Write Enable line of the chip with two output ports of the Raspberry Pi.

The first picture on the left shows this setup. The green cables between the breadboard and the Raspi go from the RAMs first three data bus pins to three input ports of the Raspi so I can monitor the data bus. The forth green cable is the common ground. The red cables between the Raspi and the RAM are the first three address bus pins that I can control with 3 output port pins of the Pi. The orange cable connects to the Write Enable line and the yellow cable connects to the Output Enable line.

To write something to a memory location I used a little Python program to put the address over the red cables on the address bus. The red button that can bee seen at the bottom of the image is used to set one of the 8 bits of the byte to either 0 or 1 while all other bits of the data bus are pulled to ground. This way I can cycle through the 8 bytes I can address and set one of the 8 bits to either 0 or 1 while all other bits are always 0. Remember, it's only to figure out how things work so there's no need to set all 8 bits of the byte. Just seeing that the bits come out correctly again later on is enough.

Once the address is on the address bus and I have either pressed the button or not to write a 1 or 0 respectively to one of the bits I activate the Write Enable line for a short time (by pulling it to ground) and release it again to commit the value to the chip. With a loop in the Python program I then go to the subsequent memory addresses and repeat the exercise seven more times. In a second loop that follows I cycle through all addresses again but this time I use the Output Enable line to put the stored data on the data bus and read it's values via the Pi-Faces input ports and display the result in a console window and also on the graphical simulation in the exported GUI as shown in the second figure on the left.

It took a couple of hours to get everything working but in the end I managed to figure out how to use the control lines to write and read my bits. Every day, I must read and write billions of bytes to a RAM chip by working with computers, smartphones and other devices. But that's something that happens in the background without me consciously doing it. With this experiment I have physically written and read bytes to and from memory by hand for the first time in my life. Quite an interesting thought 🙂

Also, I figured out how to pull the data bus lines to ground via 33k Ohm resistors so I can use the lines for both input and output which will be required in the next step when I hook up a number of other components such as registers to the bus that will be part of the CPU so I can transfer CPU instructions and data between them and the RAM chip. The order for the additional chips has already gone out and I will soon report how that went.

Mobile Activities in the Hong Kong Metro: Texting, Playing, Videos

A quick observational post today from the Hong Kong metro. Not surprisingly, smartphones and tablets are universally used by HK residents in the metro these days. What I found surprising, however, is what they do with them while commuting. While I was expecting that most of them would browse the news, this was actually an activity I couldn't only seldomly observe. Instead, by far the number one application is texting in all forms and shapes. Next is playing offline games, followed by watching videos and making phone calls. Only few people were actually using it for web browsing or reading and ebooks. Quite a different usage from my own in public transportation. But then I am fortunate enough that my suburban trains are usually only two thirds full and I usually get a place to sit and open up the notebook for writing blog posts, emails, etc.

Fixing ALL login issues for web service logins with SQRL

In the past couple of years we've become accustomed to weekly news of grand scale username and password thefts at major web services. As many people use very insecure passwords that can be cracked in seconds and by using the same passwords for many web services, usernames and passwords have become very insecure. In addition, viruses and Trojan horses try to get username and password combinations directly on PCs to get access to banking web sites and other high value targets. To me it looks like the situation is getting more and more out of control. While two factor authentication (e.g. an SMS with an additional code being sent by the bank before a transaction is made) fixes some of the issues for some web services, it's too cumbersome for everyday logins. But now Steve Gibson, famous for his SpinRite product and perhaps even more for his weekly Security Now podcast has come up with a solution that fixes all of this. Too good to be true? I thought so, too, at first but it seems he's really figured it out.

The core of his solution that he named SQRL (Secure QR Code Login) is that web services no longer store usernames and passwords but just a public key that was sent from the user when he first registered to the web site. For login, the web site sends a random number that is encrypted on the client side with the users secret key to generate a response. On the web service's side the response is decrypted with the public key agreed during initial registration. In other words, the secret password is no longer in the hands of the web service but in the hand of the user. That means that there is no longer a password database with millions of entries worth stealing on the web service's side. As each web service gets a different public key with the SQRL method and a different random number is used for each login, there's no password leakage between services due to the user of the same username and password for different sites as done by many users today to make their life simpler. Also not to underestimate is the advantage that no password has to be typed in, which fixes the issues that simple to remember and easy to crack passwords are used.

On the client side the use of SQRL is straight forward. Either a smartphone is used to scan a QR code on the login page for an out-of-band authentication which is the most secure way to access a web service in case the secret key can be stored securely on the mobile device. Also, implementations are possible with a browser plugin that detects that a web service offers SQRL login and automatically generates the response.

For more, head over to Steve's page that explains the details or listen to the podcast /videocast on the topic where he introduces SQRL starting at around 38 minutes into the podcast. I am amazed and very enthusiastic about it and hope we'll see implementations of this in the wild soon.

First Multi-Frequency LTE Networks Observed in the Wild

While LTE roaming and LTE for prepaid SIMs is still not really a reality so far I was positively surprised to see that a number of network operators are already deploying LTE on several frequency bands. This is unlike UMTS which most network operators have only deployed in one band at any one location (yes, there are a few exceptions but not many).

One multi-frequency LTE deployment I have recently observed, e.g. with my inexpensive layer 1 scanner solution (for details see here and here), is the Vodafone LTE network in Den Haag in the Netherlands where they have LTE active in the 800 MHz digital dividend band as well as in the 1800 MHz band. Add to that the capacity of their 3G network on the 2.1 GHz band and it's a fair assumption they won't run out of capacity any time soon.

And the second deployment I have observed is China Mobile Hong Kong. This one is very interesting. On the 1800 MHz band they have deployed a 3 MHz carrier (!!) while further up on the frequency dial, they are on air with a 15 MHz carrier in the 2.6 GHz band. As 3 MHz isn't really all that much I wonder if that 3 MHz carrier will still be on-air in a year or two down the road when not only most but all LTE capable phones that support the 1800 MHz band also support the 2600 MHz band. Another option would be of course to get some additional 1800 MHz spectrum and then to increase the bandwidth. But I'm not into Hong Kong spectrum assignment details so I don't know if that's an option for them down the road.

How To Get A SIM For Internet Access At Hong Kong Airport

I've been to Hong Kong recently and as I like to try out local networks and also to have a plan B just in case the hotel Wi-Fi is crappy I wanted to buy a SIM card at Hong Kong airport of one of the local network operators. It turns out that Hong Kong is one of the places where it's quite easy to get a SIM at the airport. A Google search brought me over to this recent blog entry that describes a number of options.

The blog entry recommended One2Free, an MVNO on the CSL network who offers a weekly all you can eat data plan on a prepaid SIM for 79 HK dollars which is around €8. Getting the SIM card took me about 10 minutes and in the five days I was in Hong Kong, I almost burned through a gigabyte of data for everything from email to Skype video calling without the connection being throttled at some point. Data rates were o.k. with up- and downlink speeds in the 3-4 Mbit/s range, thanks in part to the CSL in-house coverage in my hotel.

And it turned out that I was in dire need for a plan B as the hotel Wi-Fi network was slow in the evening to be positive about it and in addition my company VPN couldn't connect through that network. A colleague from another company had a similar problem. Over the CSL 3G connection, the VPN worked just fine. I'd say those were 10 very worthwhile minutes at the airport.

I’m Now Also Disabling 2G For Data – I Need a ‘3G/4G-Only’ Switch

If smartphone user interface designers are reading this blog I have a feature request: I need a 3G/4G only switch in the settings to disable GSM while leaving the device the option to roam between UMTS and LTE. Let me explain:

Last year I decided to set my smartphone I use for voice and small screen web browsing to '3G only' mode to prevent fallback to GSM, as HD-Voice (WB-AMR) continues to be only deployed in 3G, and dropping to GSM during a call results in a noticeably worse speech quality. Also, I like receiving my emails during lengthy conference calls and get some background information over the web sometimes which is also blocked after a fallback to 2G. Also, air interface security is better on 3G. So far, so good, this works well.

For data connectivity for my notebook on the daily commute and on longer train trips I use Wi-Fi tethering to another device that is LTE capable. Unfortunately, LTE is not as widespread as 3G yet so I have the network type selection set to 2G/3G/4G. This way, I get LTE when it's available in stationary places and 3G on the train as LTE coverage is still somewhat patchy. Hence the device is then stuck on UMTS for the rest of the trip because there is currently no way to get from UMTS to LTE while in Cell-DCH state. But it's still mutli-megabits per second so no real complaints here for the moment. Not so good, however, is that the connection sometimes even drops to GSM and then it takes quite a while to get back to UMTS as the device is busy transmitting data and has only little time to search for a reappearing UMTS network. But these days, GPRS or EDGE are almost unusable for the amount of data that I consume on the notebook so I wonder if that fallback still makes sense?

Therefore I'd rather like the Wi-Fi hotspot device not to fall back to GSM at all and just 'ride-out' the temporary lack of UMTS coverage as I have the impression that the device finds the UMTS network again much faster. Obviously I can set the device to UMTS only mode just like my smartphone but then I disable LTE as well which I really like in stationary places due to the much faster uplink compared to UMTS. In other words, I'd really like to see a 'UMTS/LTE-only' mode setting.

The DIY-CPU Project – The Clock Generator

After reading about how a simple CPU works in J. Clark Scott's book and other sources I've been toying with the thought about building a CPU myself. It's a bit of a project and it will take a while but the journey is the reward. As one has to start somewhere I decided to start with the clock as the details of how one is built is a bit vague in the book.

As the CPU is for educational purposes I want it to run at a clock cycle of around one Hertz, so one can actually see how things are working. In addition to a long clock cycle to drive an 'enable' signal to put something on the data and address bus that interconnects everything, a shorter clock cycle in the middle of the overall clock cycle is required to drive the set inputs to a number of components such as registers, the memory etc. to tell them to take over what's currently on the bus. These two signals can be generated out of a clock and a delay of itself of half a clock cycle. The book describes how to use AND and OR gates to generate the enable and set pulses ot of those signals but not how to create clock signal itself and how to derive the delayed clock from the original clock.

So I improvised a bit and used two inverters (NOT gates) with a resistor and capacitor for a 1 Hz clock generator (in the middle of the picture), a transistor, some resistors and a capacitor for the delayed but inverted signal (the right part in the picture) and another NOT gate to revert the delayed impulse back. The circuit with the AND and NOT gates described in the book to generate the two output signals are shown on the left together with two LEDs to visualize the final signals.

The result looks a bit complicated but it's actually not, because there are three distinct and independent building blocks that can work independently of each other. One thing that makes things look a bit complicated is the use of one AND of the chip on the left and three NOT gates in the chip in the middle to create a single OR gate.

Using parts of the electronic kits I got as a teenager and parts of kits I recently bought to have a more complete setup was ideal for prototyping the circuit. I'm sure there are a million ways to build this more efficiently and with fewer parts. But efficiency was not the point of the exercise. There we go, the first step towards my own CPU is done.

Anti-Noise Headset for the Mobile Traveler

I spend a lot of time commuting and traveling to far away places so I spend a lot of time in trains, cars and planes. Especially in cars and planes I usually make good use of the time by reading or writing something, such as this blog entry for example. But there's one thing usually in the way and that's the noise made by the vehicle itself, frequent (useless) announcements and other travelers as well. Up to a certain level, I can ignore it and get on with whatever I do. But at some point, especially when people close to where I am start talking my concentration is usually gone. Earplugs help somewhat but only to a certain extent. I've long wished for noise canceling headsets to go further. I had some in the past but they had limited effect and when I lost the plastic ear plugs and couldn't get replacements I never ventured into this area again. Then recently, I read a number of raving reports in several places about the new Bose QC20 in-ear noise canceling headsets. To say they were positive would be an understatement so I couldn't wait for them to become generally available (looks like the Bose PR department has done their job well).

What's definitely not an understatement is the price. 300 Euros is a tough number but for real good noise suppression I was willing to spend the money. So I got myself a QC20 and swallowed hard when swiping the credit card through the readier, ah, no actually when clicking on the "One Click To Buy" button online.

Needless to say I couldn't wait for them to arrive and give them an instant test. Amazing, when pressing the silence button the external environment in trains, train stations and office just goes away. If a person nearby speaks loudly a little extra music in addition to the noise suppression makes that sound go away, too. Incredible.

The other thing that always bothered me about in-ear headsets is that they get uncomfortable after a while. The QC20 however is not an in-ear headset, however as its not held by pressing something into the ear channel. Instead, it fixes itself to the ear with a plastic hold that fits inside the ear cups. Perfect, I've worn them for several hours over several days now and it never hurt a bit, not even after several hours of wearing them.

And finally when not suppressing the nose the headset still analyzes the sound environment and compensates for the plastic isolation over the ear. This is great as without it, just like with other in-ear headsets, the external environment sounds artificial and I get a strange and uncomfortable feeling when I speak myself as that has a strange effect on a blocked ear canal. The compensation works great and it almost feels like not having earplugs in at all when switching to "listen to the outside world" mode.

I have high hopes for my next plane trips as well. On intercontinental flights, current 'over ear' headsets were of little use to me as one can't sleep with them when trying to sleep on the side. With the QC20 in-ear, or rather on-ear headset it might just be possible now.

Despite the super high price for the headset I am still full of praise for them, traveling and working in noisy office environments has become very different. Let's see how this story develops and what I think about the headset in a couple of months.