Stranger Android Things

As far back as 2011 I was talking up using Android as a Linux-based embedded operating system. In those days I was running it on a BeagleBoard. I liked that idea then and I still like it now.



Android has a rich set of features, many of which would be really useful in an embedded product at the higher end. It is architected to make use of multiple network devices - for example, WiFi and a cellular modem - which is becoming common in the kinds of things I work on. Android has a mature tool chain and development infrastructure that includes stuff like a graphical IDE and a debugger. It is a well understood platform on which to deploy third-party applications, which at least one of my clients is eyeing as a business model for one of their products. And best of all, Android has enormous market forces incentivizing other folks to do a lot of the work for you.

I never got any traction on that idea. But maybe now that Google is promoting Android Things - as in Android for the Internet of Things - that will change. Android Things (formerly the platform known as "brillo") is a stripped down version of Android that can be run headless. It has the usual Android Run Time (ART) Java Virtual Machine (JVM) plus support for native C and C++ code, so you can port your legacy drivers and libraries, but do your new application development in an object oriented language that has first-class built-in support for threading, synchronization, and lots of other useful stuff.

Or will. Currently Android Things is just a pre-built developer preview that you can load on a selection of inexpensive development boards like the Raspberry Pi 3. It includes drivers and Java APIs for common embedded hardware interfaces like an Inter-Integrated Circuit (I²C) bus, a Serial Peripheral Interface (SPI) bus, Pulse-Width Modulation (PWM) output, and General Purpose Input/Output (GPIO) pins.

Third-party developers have in turn written higher level drivers and Java APIs on top of these for a selection of peripherals on commercially available expansion boards. For the Pi, that would be the Pimoroni Rainbow Hat. The Rainbow Hat has an APA102 LED strip (SPI), a BMX280 temperature and pressure sensor (I²C), two two-character HT16K33 alphanumeric segments (also I²C), a piezoelectric buzzer (PWM), and some discrete LEDs and buttons (GPIO). Below is a photograph of a Rainbow Hat on a Pi running my single threaded RainbowHatDemo application.



The source for Android Things hasn't been released yet, so porting any of my C or C++ libraries will have to wait. But the developer preview, with a Raspberry Pi and the Rainbow Hat, is a great way to see where this is all going. I wrote some toy applications using Android Studio just to try to remember how to use Java, which I haven't done anything serious with in a decade. You can find the repository, code-named Deringer, with all my source code as Android Studio projects, on GitHub. Below is a little code snippet from my multi-threaded RainbowHatThing application that reads the temperature and pressure sensor and logs the results.

    public void run() {
        Log.i(getClass().getSimpleName(), "begin");
        while (!lifecycleDone()) {
            try {
                float[] readings = sensor.readTemperatureAndPressure();
                float centigrade = readings[0];
                float fahrenheit = (centigrade * 9.0f / 5.0f) + 32.0f;
                float hectopascals = readings[1];
                float inches = hectopascals * 0.02953f;
                Log.i(getClass().getSimpleName(), centigrade + "C " + fahrenheit + "F " + hectopascals + "hPa " + inches + "in");
                pause(1000);
            } catch (IOException e) {
                // Do nothing.
            }
        }
        Log.i(getClass().getSimpleName(), "end");
    }

Here is a little video (with audio) of the RainbowHatThing application running many threads concurrently on my tiny test system.



Will Android Things take off as a platform for the more capable IoT targets? No clue. But for sure there are many economic reasons to take this very seriously.

The Cost of Doing Business

My software development career over the past forty-plus years has been all over the map: supercomputers, eight-bit micro controllers, vast distributed telecommunications systems, multi-core microprocessors. The one thing they all have in common - at least at the level I work at near bare metal - is that the skill sets are all basically the same. But one thing that isn't the same is the cost of the tools to debug, functionally test, and validate my work.

Perhaps twenty years ago, I was writing firmware in C and C++ for optical networking products based on ATM and SONET. One night I found myself working late in a lab trying to debug some recalcitrant real-time code. I was surrounded by an H-P broadband analyzer, two H-P ATM protocol analyzers, and a tangle of multimode optical fiber. I realized I had maybe US$300,000 worth of test equipment dedicated to this one task, never mind my high-end workstation and the room-filling racks of telecommunications equipment. I paused for a moment to realize that an organization smaller than Bell Labs might have had a tough time tackling this product development effort, the investment in infrastructure was so significant.



Moore's Law hasn't really changed things that much, because as the tools got cheaper, the systems we develop and debug have gotten larger and more powerful right along with them. Just the other day I was working on my stratum-0 atomic clock project and I realized that my little hobbyist oscilloscope - one of the most useful tools I have ever purchased - was completely inadequate for doing any kind of jitter analysis on the output of the device. After some reflection, I decided I probably didn't know anyone that had an oscilloscope that could measure the jitter of my chip-scale atomic clock. Any jitter that might be detected would surely be in the oscillator used by the measurement instrument itself.



See, our measurement of time is a funny thing. It is a completely synthetic artifact, a singularly human invention. Thanks to natural variation in the Earth's rotation and in its orbit, time isn't even tied to the movement of the Sun any longer. It's defined, in the International System of Units, to the beat of an oscillator based on the cesium-133 time standard. And the thing I was trying to measure was itself an oscillator based on the cesium-133 time standard. The only way we can measure the precision and accuracy of a clock is by using a more precise and more accurate clock. I'm not likely to ever have one of those.

The larger lesson here is this: before you decide to tackle a project, make sure you can get the tools you need for the entire life-cycle of the product. You may find out that the economics of developing a product are substantially different from the economics of debugging, testing, validating, and supporting that product.

Engines of Time

In My Stratum-1 Desk Clock and My Stratum-0 Atomic Clock I described the two clocks that I built: O-1 a.k.a. "Hourglass", and O-2 a.k.a. "Astrolabe". Both act as stratum-1 NTP servers on my home network, along with two commercial units, "Waterclock" and "Sundial", that I have previously described. I mounted both clocks on inexpensive acrylic fixtures from office supply stores that just happened to be about the right size and shape to serve as stands to display my handiwork.

Hourglass is my desk clock sitting on a shelf in my home office. It is a Raspberry Pi 3 using Raspbian and runs the GPS daemon and the NTP daemon. It connects to my home network wirelessly, although the wirefull port works as well. It uses the NMEA output and 1PPS strobe from a Uputronics GPS board to discipline its system clock. It has a real-time clock board that with the push of a button can save the time to a battery-backed clock to preserve its state should it need to be powered off. Thanks to the standard Linux kernel and GNU software, it automatically adjusts to Daylight Saving Time, and GPS itself automatically adjusts to the occasional leap second. As long as it can receive GPS signals from an amplified antenna sitting in my office window, it will be within milliseconds (at least) of Universal Coordinated Time.

Astrolabe sits on a small table in the living room. It is virtually identical to Hourglass in both hardware and software, but replaces the Uputronics GPS board with a Jackson Labs Technologies CSAC GPSDO, a board that has a Microsemi Chip-Scale Atomic Clock that it phase locks to GPS time. Astrolabe receives NMEA output from the GPS chip on the GPSDO board, but gets its 1PPS strobe from the CSAC cesium-133 oscillator. Once the CSAC is initially disciplined to the GPS 1PPS, and the Pi's system clock is disciplined to both GPS and 1PPS, even if it subsequently cannot receive GPS signals from the matchbook-sized amplified antenna sitting in the living room window, it will still be within milliseconds or even microseconds of UTC. Astrolabe also includes a couple of test points: a BNC connector to the 10 MHz output of the CSAC, and an RS-232 serial port to the command interface of the GPSDO.

This is the most accurate and precise timepiece I will ever own, perhaps could ever own, my own stratum-0 atomic clock. Far far better clocks exist, but I am unlikely to ever own them, much less have them in my living room. Its time is traceable to the atomic clocks in the U.S. NAVSTAR GPS satellite constellation in orbit, which are traceable to the U.S. Air Force Master Control Station clock in Colorado Springs Colorado, which is traceable to the Washington Master Clock at the U.S. Naval Observatory in Washington D.C., which is traceable to the NIST-F2 clock at NIST in Boulder Colorado, which is synchronized with atomic clocks all over the world coordinated by the International Bureau of Weights and Measures in Paris.

I have been fascinated by time, time measurement, and time keeping, for decades. Having spent the past forty-plus years working on real-time systems close to bare metal, this was perhaps inevitable. The ability for information to cross the boundary between the real world and the digital world fundamentally depends on the quality of our frequency sources. And our interpretation of reality rests on the accuracy and precision of our clocks.