Lollipop, Lollipop, Oh Lolli, Lolli, Lolli

As I saw today Android 5.0 (Lollipop) factory images, I got a twitch going on. Yes, I could wait OTA a week or so or I could install the newest Android OS on my phone immediately at the cost of data. It took me a whole second to know the answer.

First step was to install Java. I took latest x64 Java Development Kit and got that pest (temporarily) on my machine. Next step was to get Android SDK Tools. I opted to get it as a standalone install.

Upon starting Android SDK Tools, I just installed all packages offered by default. Nitpickers might say that you only need Platform Tools and Google USB Driver but I find it much easier to click Next, Next, Next until cows come home or all needed gets installed.

Last part of puzzle was actual factory image for Nexus 4. All files from it I unpacked in the same directory where fastboot.exe was installed. Since I took all defaults this was at %USERPROFILE%\AppData\Local\Android\android-sdk\platform-tools.

Now I powered off my mobile phone and powered it back on while holding Volume down button. This brought me into the FastBoot mode and I connected my USB cable only to have device not be recognized. Therefore I had to go to the Device Manager and right-click Android device with a yellow question mark. Selecting Update Driver Software and then pointing dialog to the SDK directory (%USERPROFILE%\AppData\Local\Android\android-sdk in my case) allowed installation of Google’s USB Driver.

Now I could start cmd.exe and unlock my phone:

cd %USERPROFILE%\AppData\Local\Android\android-sdk\platform-tools
fastboot oem unlock

This gave me a warning prompt on my mobile phone. To select Yes I had to use volume keys for the movement and power key for the confirmation. First step done.

Next step was to actually flash the phone. Fortunately Google provided nice script for that so I just started it (still in the %USERPROFILE%\AppData\Local\Android\android-sdk\platform-tools directory):

flash-all.bat
 sending 'bootloader' (2264 KB)...
 OKAY [  0.076s]
 writing 'bootloader'...
 OKAY [  0.294s]
 finished. total time: 0.374s
 rebooting into bootloader...
 OKAY [  0.004s]
 finished. total time: 0.006s
 …
 sending 'cache' (10984 KB)...
 OKAY [  0.375s]
 writing 'cache'...
 OKAY [  0.602s]
 rebooting...
 finished. total time: 87.058s
 Press any key to exit...

After two minutes your phone was be rebooting with a brand new OS. First reboot took quite some time (eight minutes on my device) so have some patience was needed.

After setting everything up I rebooted the phone once more into the FastBoot mode (power off; VolumeDown+Power). Then I started cmd.exe one last time and brought the lock back:

cd %USERPROFILE%\AppData\Local\Android\android-sdk\platform-tools
fastboot oem lock
fastboot reboot

And with that installation of Lollipop was over.

PS: Interesting tidbit: during initial Lollipop setup I could only see 2.4 GHz wireless networks. As soon as I was connected, 5 GHz networks became visible too.

Rectangular NFC Antenna Calculator

For a project I had to calculate parameters needed to make nice rectangular PCB inductor for a NFC antenna. Since my search didn’t bear desired results, I decided to make my own.

Enjoy.

Calculation is done per NXP’s AN1445.

Livin' La Vida Https

I had SSL enabled on my site for a while now. My hosting provider had it available as an option and I hated having my password travel unencrypted. However, as Google pushed for https, I started playing with the idea to use https exclusively. As you can (hopefully) see, migration was successful.

First order of business was to sort out redirects. I wanted regular http domain 301-redirected to the https one. As my server was using Apache, following directives were added to .htaccess file:

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

In order to be compliant with HTTP Strict Transport Security, I also added new header just above conditions in the same file:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

My Suffusion WordPress theme kept using http to fetch ads and that caused browsers to omit them all together (you cannot load http scripts on https site). Therefore I also had to make a slight modification to it. In file ./suffusion/functions/shortcodes.php I had to change suffusion_sc_ad function to use https by removing protocol name from the URL:

function suffusion_sc_ad($attr) {
        $params = array('client', 'slot', 'width', 'height');
        $provider = 'google';
        $provider_type = 'syndication';
        $service = 'ad';
        $service_type = 'page';
        $ret = "<div id='".$service."sense'>\n<script type='text/javascript'><!--\n";
        foreach ($params as $var) {
                $ret .= "\t".$provider."_".$service."_$var = '".$attr[$var]."';\n";
        }
        $ret .= "//-->\n</script>\n";
        $service_url = "!!http:!!//".$service_type.$service."2.$provider$provider_type.com/$service_type$service/show_{$service}s.js";
        $ret .= "<script type='text/javascript' src='$service_url'></script>\n";
        $ret .= "</div>\n";
        return $ret;
}

Result of these three changes is that my site is now https-only without any functionality loss.

PS: Those checking the certificate will notice that I use CloudFlare and their Universal SSL. Do notice that using such service is actually one big man-in-the-middle attack since CloudFlare decrypts all traffic before encrypting it again when it contacts your site. It is not because they are evil but because they cannot provide you with their CDN services (and more) any other way. For any website traffic, I see no problem with such approach. However, for administration tasks, I would recommend having a separate https subdomain that leads directly to your server.

FTDI - Best to Avoid?

Serial port ruled the hobby market when connecting custom electronics to a computer was needed. As USB became prevalent, instead of serial interface we got USB-to-UART chips. Most common ones were manufactured by Prolific and FTDI and they became defacto standard. I personally chose FTDI’s FT232RL for huge majority of my designs. Partly it was due to driver availability for almost any platform and partly due to my bad experience with Prolific’s PL-2303.

Mid October FTDI pushed new WHQL certified driver via Windows Update. For quite a few customers that meant death of their serial devices. And it wasn’t just a compatibility issue. Once some devices saw new driver they became unusable on other operating systems (yes, including Linux). For more information, there is a huge thread at EEVblog forum along with some other sources.

Story started when the FTDI engineering found a way to detect some (if not all) non-genuine chips reprogramming them in process. For all practical purposes any device containing fake, cloned or compatible chip became dead. You could boot into Linux and previously working device would refuse to cooperate. You could even move it to another computer (without driver update) and it still wouldn’t work. While change is reversible by the expert user, normal user would just assume device is dead.

Were they in the right to detect fake devices and not work with them? For fakes chips answer is most definitive yes. It is a bit of a gray area when it comes to the compatible chips that have no FTDI markings. But actually killing the end-user devices is taking “pirate” fight a step too far. I am not necessarily talking about legality of “bricking” devices; I am sure that we will see at least legal analysis if not a legal action due to this.

As it works currently, in hobby market, you almost never contact manufacturer directly. You typically go via third-party. Whether you get legitimate or counterfeited chips is mostly a function of price. But you can get a real chip for cheap (e.g. somebody selling unused stock) and you can get a fake for a full price. Yes, you are more likely to get a original if you deal with a big/official suppliers (e.g. DigiKey, RS, Farnell/Newark/Element 14/whatever-is-their-name-now) but they are pain to deal if you are from in “unsupported” country. And a dollar difference here or there might make a difference to a hobby user.

As you sell a few devices with everything looking peachy they all suddenly stop working. Devices start coming back and you need to issue refunds or give a new device with a genuine chip. In an ideal world, you would sue your supplier and recover your damages. In reality you just swallow the loss because having a day in court would cost much more (in both time and money) than what you can hope to win. Only thing you can do is to avoid troublesome chip in the future. Once burned twice shy.

Similar problem exists if you bought a hardware device with the purest intentions. Price was right, not too high, not too low, functionality was just right and device used a FTDI chip internally (e.g. quite a few Arduinos, some BusPirate versions, humble chip breakout, or even some boards I made). But device manufacturer either used fake part knowingly or they just got screwed. In former case device was happily working until suddenly unrelated driver update killed it. If device is new you might get a refund. But chances are that you’ll get nothing.

If you are doing more than a few devices chances are you’re probably outsourcing assembly to somebody else. Dealing with assembly is handful on the best of days and now suddenly you might have on your hands a bunch of devices that pass all possible tests on the assembly bench only to be bricked by the end-user’s computer. To anybody other than the biggest manufacturers this is a scenario from hell. You will need to replace quite a few devices with assembler claiming devices work on their end and that it is not their issue. Court may be your friend but money/time equation usually does not work out.

And it is not as this fixes issue of fake devices. Those making fakes will just adjust their firmware to behave as a real FTDI chip for this case and Whac-A-Mole starts anew. I personally see a much higher chance that some later driver update will accidentally kill some genuine chips rather than preventing cloning. Recognizing that problem, FTDI CEO did say “sorry” but with a side dish of “we’ll do something else less drastic next time”.

I will personally vote with my wallet until I see what next few months will bring in this FTDI saga.

PS: If you want to get away from the FTDI but you don’t want to rework your board, there is a Cypress CY7C65213-28PVXI. It is pretty much exact pinout (albeit without possibility of an external oscillator), supporting anything from Windows 98 onward, and at a lower cost.

PPS: Those prepared to change board can look at MCP2221.

PPPS: Yes, I am aware my actions are purely cosmetic since I only buy 20ish FTDI chips a year.

[2016-02-05: They’re at it again. This time not bricking, just messing with data output.]

J a Bit

These days it is almost a common knowledge that J standing alone has a meaning of a smile. What you see as a J on the desktop suddenly becomes a letter J when viewed on (Android) phone. But why is that?

Answer lies in the dark times before the Unicode when only possibility to introduce new symbols was to actually swap some characters for them. It was quite a common practice to make fonts that consisted purely of symbols.

One of such fonts were Wingdings family. These fonts were then used in anything from Word to many custom programs. If your platform doesn’t support fonts or contains no Wingdings font (as Android), you would see symbols substituted for the letter characters.

Probably most commonly used in the emails are smiley symbols: J (J), K (K), and L (L). As Unicode became standard in communication, only smiley and frowny face survived. Other Wingdings characters remained just a curiosity and something you would get from Outlook users.

But maybe they will be coming back into fashion soon as Unicode 7.0 will contain most of them. Who knows, maybe even somebody makes an effort and J-weirdness becomes a history.