Low Power Voltage Sampling

The car computer project has taken a big detour for the last few months in lieu of my gaining more experience with microcontrollers and electronics. Carputer 2015 was mostly a system integration design to be achieved by plugging together existing modules. Carputer 2016 is about integrating complex pre-existing modules with customized sensing, communication, and control. Alas, this probably makes the project even less accessible for those wanting their own carputer. On the plus side, most of the people who hit my blog are finding it via web search. I hope electronics hobbyists can find something of use here.

I've lately been exploring very low power microcontroller applications. There are so many situations that fit the form:

1. Take a sensor reading.
2. Process, store, and/or respond to the sensor value.
3. Sleep until interrupt, then repeat.

Such systems are often deployed with their own, limited power source. My specific application is normally powered via micro-USB with a 5.5V supercapacitor backup. I'd like the controller to monitor both its USB and capacitor voltage to be able to indicate charging, discharging, and out of spec power.

Simply powering a resistive voltage divider could take on the order of 100 microamps. That's actually significant compared to the sleep current of an ATmega328P controller. The typical solution is to switch the high side of the voltage divider with a P-channel MOSFET. The divider (or resistive sensor) can then be powered only for the duration needed to get a stable sample. See the following:

• » Zero-power measurement – part 2 » JeeLabs
• Jeenode Wireless Sensors - Arduino

My application is constrained by the number of available connector and controller pins. What I really want is to pulse an analog pin and then read my sample on that same pin. I do this by adding an N-channel FET to momentarily discharge the 0.1µF cap on the P-channel's gate.

FETs with a low gate-source threshold voltage allow this circuit to function down to the 2.7V brown-out of my microcontroller. If you don't need low voltage operation, there are probably cheaper FETs that will work. I'm using a ZVP4424A and a ZVN2106A. As you can see, the sense output is connected to the gate on the N-channel FET. By dividing the output low enough, the gate will stay low/off. A timed low pulse on A0 should further guarantee a reset.

Reading from a µCurrent GOLD show single digit nanoamps when the divider is off and 1+ milliamps (I badly need a scope!) when on and charging the gate cap back up. Mission accomplished!

Carputer 2015 - September Status

Time rolls on and the car computer has yet to roll. I've been having way too much fun interfacing and developing for Arduino. Still, everything else is ready to go, so expect the rolling demo video and blog post sometime next week. Here's a quick summary of what the system looks like.

Frontend

• Hardkernel Odroid XU-4
  ARM-based Android computing frontend
• Software to use network GPSd (TBD)
• Wired Ethernet link to backend
• Chalkboard Electronics 7" IPS TFT display w/ touch
• Blue Microphones Tiki
  USB noise-canceling mic
• DC switching power converter for Odroid

Backend

• Raspberry Pi 2
  ARM-based Linux backend and network router
• Nexus 5 Android smartphone
  USB tethered to Pi for wireless data access
• Async serial GPS module
  Provides location data to GPSd on Pi
• Febon100 UVC video capture
  Provides MJPEG over USB video into Pi
• 12V powered USB hub
  Can feed 5V to Pi and additional power to N5

Management

• Freaduino Mega2560 (modified Arduino Mega clone)
  System management controller
• Resistors and analog ICs for voltage and current measurement
• Adafruit 2675 OLED display module
  For system diagnostics and power monitoring
• PowerStream 12V DC UPS module

I imagine the Arduino as something of a lights-out management controller for the entire system. The initial use is power monitoring and control. The Cosa software platform has been a wonderful help when developing for 'duino, as an event-driven approach is important to me. Check out my demo of voltage monitoring and text display.

Getting Intermediate with Arduino

There's a wealth of information out there on getting started with the Arduino microcontroller, development environment, and basic electronics. So you've interfaced with LEDs, sensors, and modules. You've written sketches to do digital input and output, analog input, and maybe a bit with async serial, SPI, and I2C interfacing. Now you're ready for the next step. Maybe you have a project in mind that needs to make that transition from prototype to something that can survive real world conditions.

Now's the time to roll up your sleeves and yank that AVR controller IC, design a custom board, and start developing directly with the avr-gcc toolchain. Wait... what?

This is a fundamental problem with the beginning hobbyist and rapid prototyping nature of Arduino. There are obvious transition paths when you simply need more hardware resources. The Mega 2560, with its abundant I/O, RAM, and flash is clearly more capable than an Uno. The Arduino Due is fast, but may not be worth the loss of compatibility and ubiquity. Once you start exploring the world of custom and specialized 'duinos it's easy to become overwhelmed by the choices. There's no obvious path from beginning experimenter to serious project builder.

Hardware Selection

As I've progressed with Arduino, I've learned which boards to buy by making wrong choices and wasting money. Maybe you won't have to. Here are some general recommendations:

• Avoid prototyping boards with custom I/O.
  That 'duino with built in Bluetooth or Ethernet may be tempting, but adding I/O modules to standard boards is more flexible and provides useful experience.
• Choose modules over shields.
  Using multiple shields will eventually lead to pin conflicts. Shields are also constrained by the Uno form factor. Modules can be more easily moved between different types and sizes of controller.
• Build out your own proto shields or boards.
  Perma-proto shields can be useful to consolidate modules, connectors, and small circuits as you progress from prototyping toward deployment. At some point you'll need to get that tangled mess of prototyping wires, modules, and components into a more compact, organized, and ruggedized form factor. Perma-proto shields are a decent way to customize interfacing for your project.
• Plan your prototyping and deployment requirements.
  Determine early your physical requirements and controller specifications for both prototyping and deployment. That Uno or Mega might be great for prototyping, but not quite cut it for deployment in tight spaces or harsh conditions.
• Select boards in pairs.
  To progress from prototyping to deployment you're better off with two (or more) controller boards. I'm currently liking the compatibility of prototyping on the Uno and deploying on the Adafruit Pro Trinket. You can build your own little shields to stack on the Trinkets.

A sampling of prototyping boards.

Software Development

The Arduino development app is great for beginners. For actual software development it's extremely limited. Yet again the intermediate developers are left to fend for themselves. All the thirdparty libraries and examples are written to be used from the standard IDE and runtime that are borderline unusable for production software.

I probably don't need to explain what's wrong with the Arduino IDE. It's simply extremely limited when compared to environments like Eclipse. That said, it's not unbearable to continue using the Arduino IDE for your .ino projects and use a better editor or complete IDE to organize most of your functionality into libraries.

The real problem with Arduino development is that the libraries and runtime are awful. The AVR microcontroller underlying most 'duinos doesn't typically run an operating system with processes and threads as you would find on a single board computer like the Raspberry Pi. Your Arduino project and supporting runtime library are your operating system!

The standard runtime works if you're only trying to do a very limited number of things and don't require fast real-time response. The fundamental problem is the linear nature of the standard runtime and libraries and the acceptance of millisecond level delays. It's simply unacceptable that library routines block the execution of other code for many thousands of instructions. What is needed is an asynchronous programming approach with asynchronous I/O, events/callbacks, and timers. This approach can prevent missed I/O events, allow events to happen at predictable times, and still allow the controller's processor to sleep when it's not needed.

The frustrating nature of standard Arduino development almost caused this experienced software developer to abandon Arduino entirely. Fortunately someone else who had experienced these same problems made the effort to do something about the situation. Enter Cosa, "An Object Oriented Platform for Arduino Programming."

Getting into Cosa takes a bit of time, but I strongly recommend taken the plunge as early as possible. Dive in there and start converting libraries to fit the framework of Cosa helper classes. Arduino was screaming out for asynchronous OO development and Cosa is what exists and works.

Furure Directions

So where does the intermediate developer with a couple projects under the belt go next? I can only speak from my own experience. With the availability of tiny 'duino boards, I don't feel a strong impulse to design custom controller PCBs when I can stack or socket existing boards. With Cosa I don't currently feel the need to develop directly with the avr-gcc toolchain. I've found an environment where I can get things done.

Would I step up to the ARM-based Arduino Due for more demanding projects? Probably not as things currently sit. Either arduino.cc, arduino.org, or Adafruit would do well to negotiate with Mikael Patel to embrace and enhance the Cosa environment while extending it to the Due board. Without a solid software ecosystem that can work for beginning, intermediate, and advanced developers, Arduino seems destined to become yet another legacy embedded platform. Tick, tock, Arduino. The TI LaunchPad is looking really tempting right now...

DC Power Conversion

With so much interest in mobile electronics these days, Makers are tossing aside their long despised AC adapters and turning to DC power. Unfortunately, DC sources tend to fluctuate or be comprised of cells that produce voltages not directly usable by most electronics. It's relatively easy to reduce voltage by converting electrical energy to heat, but it's hard to find applications where efficiency isn't a factor. Efficient switched power conversion is gradually replacing inefficient linear voltage regulation.

Terminology

It's useful to know a few terms to understand the type of voltage conversion performed by devices.

• Linear voltage regulation / conversion. A continuously regulating voltage divider (inefficiently) down-regulates voltage.
• Switching voltage conversion. Current is rapidly switched to step voltage up or down.
• Buck converter. This is a switching converter that reduces voltage to a desired level. In some converters the output voltage may be configurable but it will always be less than the input by some margin.
• Boost converter. This is a switching converter that raises voltage to a desired level. A common use would be running 5V electronics from a 3.7V Li-Ion or Li-Po battery.
• Buck-boost converter. This flexible switching converter can either raise or lower voltage to match the desired output.

A sampling of fixed and variable voltage converters.

Real World Examples

So let's say we want to power a tiny computer like the Raspberry Pi or a microcontroller board like Arduino from a 12V source.

Raspberry Pi

The Pi requires regulated 5V input through its Micro USB power connector. This allows the use of ubiquitous AC to Micro USB charging adapters and eliminates the need for a 5V regulator on the Pi. In hindsight, these were very questionable choices. Many existing chargers could not supply sufficient current for the Pi, and no onboard 5V regulation makes the Pi harder to run directly from a DC source. This has all been a big enough problem that there are now quite a few DC to 5V power boards designed to meet the specific requirements of the Raspberry Pi.

With the USB connector unplugged there seems to be no problem supplying regulated 5V power directly through the Pi's 5V header pin.

This Pi 2 works great off a tiny buck converter.

I'm happily running my Pi 2 using the tiny Adafruit "UBEC" buck converter pictured above. It's almost like the connector was specifically intended to provide power directly to the 5V rail of the Pi. (It almost certainly was.)

Arduino

Most Arduinos and clones are pleasantly flexible regarding DC input. The USB connector can be used to supply regulated 5V. The 2.1mm barrel jack is specified to accept 7-12V which is passed through a linear regulator to provide 5V. Considering what we know about linear regulators, it's better to stick toward the lower side of that range. A small number of 'duinos, like the Freaduino Mega2560 pictured below, feature an onboard switching regulator that can handle more than 20V. Finally, a regulated 5V supply may be tied to the internal 5V rail via the header pin.

Exotic "Freaduino" with onboard switching regulator.

I specifically sought out and bought my Freaduino so I could pass 12V (automotive) power into the barrel jack with minimal losses. Given a more typical 'duino, a variable buck converter set to ~7V and passed into the barrel jack would be a fine approach.

Odroid

Although not as popular as the Pi and 'duinos, the Odroid is a very capable yet inexpensive tiny computing platform. Please refer to my writeup on the new ODROID-XU4. This Odroid specifies power requirements as a beefy 4A of current at 5V. A fixed 5V 5A buck converter did not result in a stable system. The AC adapter output measures 5.15V with no load. The fixed 5V converter either droops enough under load or 5V isn't quite enough to stably run the Odroid. Fortunately I had a DROK 5A adjustable buck converter that worked flawlessly when set to 5.2V. I may actually write a review of this converter, as it has some interesting features. These include limited rate battery charging and voltage and current monitoring over an asynchronous serial interface.

Carputer 2015 - ODROID-XU4 SBC

The carputer project is still ongoing, just vanished down a rabbit hole for a few weeks. As it turns out, the Android OS environment is simply more compatible, stable, and easier to manage on ARM platforms than x86 PC platforms. Duh, right?

The Carputer is Dead, Long Live The Carputer!

The Carputer 2015 frontend is now powered by a US$74.00 ODROID-XU4. This capable little board contains, at its heart, the same Exynos 5422 SoC as the international variant of the Samsung Galaxy S5 smartphone. This places it a notch below 2015's flagship devices, but in a completely different class than low-cost boards like the Raspberry Pi 2 and BeagleBone Black.

Hardkernel ODROID-XU4 ARM SBC

Ordering the Odroid and accessories from ameriDroid went flawlessly. The order arrived quickly, well-packaged, and complete. There was even a little handwritten "thank you" note. Other Asian manufacturers would do well to emulate Hardkernel's American distribution channel.

What's on (the) Board?

It should be evident from the picture that there's a lot of I/O on this little board. So here's what we have:

• Samsung Exynos 5422 SoC, 8 cores, 2 GB, graphics
  AnandTech provides some quick analysis and comparison.
• Heat sink and fan
  The PWM-controlled fan kicks in as needed. I have yet to see it move.
• Power switch
  Pulls the board out of sleep state. The board powers on automatically.
• 2x USB 3.0 host ports
  These share an internal 2 port hub.
• 1x GigE Ethernet port
  A wonderful and rare feature for ARM SBCs! Internally, this runs off a dedicated USB 3.0 channel.
• 1x USB 2.0 host port
  Is this connected via an internal hub? Directly connected, no hub.
• Full-size HDMI connector
  Nicely enough, this supports digital audio output and CEC.
• DC power jack
  Input is specified as 5V at up to 4A. 4 amps is a lot for a small board.
• Standard microSD card slot
• Connector for eMMC module (underside of board)
  This supports fast 5.0 modules!
• Boot selector switch (microSD or eMMC)
• Serial console connector (requires cable)
• Connector for RTC battery
  Nicely done to leave the battery off the board but easy to add!
• Headers for digital, analog, and bus I/O

Hardkernel did a great job with the design of this board. Pretty much everything is there, and in a form that doesn't require adapters. It does bear mentioning the few features that are missing:

• No analog audio in/out
  Digital audio is supported via HDMI, USB, and I2S headers.
• No wireless anything
  You'll need to add WiFi, Bluetooth, GPS, etc. if you want them.
• No USB client port
• No power monitoring or battery management
  Some other models of Odroid have power monitoring.

Again, it was a logical choice to leave out noisy radios and audio conversion.

What about Android?

Hardkernel sells eMMC modules and microSD cards preloaded with Android or Linux. Currently shipped versions appear to be Android 4.4 KitKat and Ubuntu 15.04. Disclaimer: I have not yet tried Linux on Odroid. Android images appear to be customized versions of CyanogenMod. After playing around a bit with 4.4, I soon upgraded to the community supported 5.1 and installed the Google Apps.

The carputer plan is to use HDMI audio output and a USB microphone. Digital audio was one of those things that just didn't want to work on Android-x86. I have a Blue Tiki USB microphone that is quite good at filtering noise from voice input. This mic also provides a (semi-useless?) output channel that confuses the Android audio subsystem. This results in USB audio in or HDMI audio out, pick one. Thankfully this has a quick solution under Android 5.x. Editing the audio_policy.conf file to comment out the USB audio output section gave the desired result. Multiple audio device support remains problematic in Android.

The long-promised in-car demo shouldn't have to wait much longer!

Carputer 2015 - Workbench Demo

Carputer 2015 - Sourcing Parts

When I began this car computer project, I imagined that the current popularity of hobbyist embedded computing and custom A/V projects would make it easy to obtain components. Not so much. Internet searches and scouring forums can lead toward the specific products that will work best for a project, but many of these products will not be available from a domestic distributor.

Be prepared to work directly with distributors in Asia. Some of these distributors may have a web site for ordering, some work through eBay, and some just have an email address. It helps to respect that English is not the first language and to keep communication simple and clear. Payment is generally accepted through PayPal and timely shipping may cost a bit. I have so far dealt with four different Asian distributors and have received correct and functioning components each time.

Expect a lot of parcels like this one.

The apparent cheapest solutions to problems may not actually be the cheapest. One of my initial project guidelines was to start with inexpensive components and be able to justify price increases. Having done this, I can now offer advice to others who may be considering a similar project.

1. Don't buy an EasyCAP / EzCAP for composite video capture from Linux. You could spend a fortune in money, time, and frustration to get a combination of device and kernel that actually works. Spend the money and get a UVC capture device from +Andy FEBON.
2. Don't settle for a cheap TN display panel or resistive touchscreen overlay. An IPS panel with capacitive touchscreen gives the true "tablet experience" that most people expect. I finally found what I was looking for at Chalkboard Electronics.

Left good (FEBON100 UVC), right bad (EasyCAP).

The US$56 TN panel and resistive touchscreen setup below is pretty much only useful for prototyping. I certainly wouldn't want to have to use it.

Cheap TN panel and resistive touchscreen.

Below is the 7" IPS panel that I will install in my car. The pictures don't do it justice. The display controller is small and affixed to the back of the panel. Entire unit can be powered over USB! Full information here.

IPS panel in direct lighting.

IPS panel in indirect lighting.

I'm now just waiting on a powered USB3 hub and some cables before being able to demo this system in my car. A number of commenters have mentioned that it's hard to grasp what I'm trying to achieve with this project. My next posting should contain a demo video that makes things much more clear.

Carputer 2015 - System Design

The carputer design is coming together. I've collected a decent set of system components, cabling, connectors, and tools that will be useful for prototyping. System design has been a bit up in the air as I'm coming to understand the limited selection of components and their constraints. In particular, finding acceptable display panels and controllers has been a problem.

The following is my current iteration on the overall design.

Car outline clip art image by Cliparts.co. Diagram produced using Inkscape.

1. Vehicle battery.
   Note the new cable run through the engine firewall to the rear of the vehicle. This will allow maintenance of a low-power sleep mode to quickly bring the master carputer online when the vehicle is turned on or a remote network query is made.
2. Vehicle system bus and accessory power distribution module.
   This represents a magical (to me) black box that provides 12V accessory power and vehicle systems signaling.
3. Vehicle A/V control unit.This module processes input and output for non-essential vehicle systems, such as climate control and audio. This is designed to interface with a display unit that will be entirely replaced by new components for this project.
4. Flat panel touchscreen display and controller module.
   The existing LCD panel is 8 years old and the backlight is weak. Readily available panels in the 7" size seem to go from 800x480 to 1280x800. For this application, panel visibility in a variety of lighting conditions is much more important than resolution.
5. Legacy display signal conversion and digital capture module.
   The A/V control unit generates what appears to be a 15kHz RGBs video output (like an old arcade game). This will be converted to composite video and then digitally captured with a USB dongle. The master carputer needs to be able to process and display these video frames.
6. Legacy wiring interface microcontroller.
   This is a controller like an Arduino that interfaces signals from the A/V wiring harness to USB. The master carputer will then be able to determine things like vehicle speed and reverse state.
7. Powered USB hub.
   This supplies the power and data bus for components in the front and center consoles of the vehicle. The uplink is wired to the master carputer host at the rear of the vehicle.
8. Switchable DC to DC power conversion module.
   The master carputer requires a stable DC power supply, possibly with multiple voltages and possibly with battery backup support.
9. Master carputer.
   This is the main computer that handles all USB I/O devices and generates audio/video output to the front display over HDMI. The carputer setup is as yet unspecified. This could be a repurposed coreboot plus Linux Chromebook, an embedded PC, or a Raspberry Pi. Potentially the frontend (audio/video) and backend (input processing and control) could be separate computers.
10. Rear-view camera module.
    This vehicle did not originally come with a backup camera. A camera will be added to provide rear-facing video to the master carputer for display or recording.

Notice that the long cable runs between the front and rear of the vehicle use digital signaling. I had originally planned to run composite video from the rear camera and analog audio from the master carputer to the front of the vehicle. The flatscreen display module I'm most strongly considering now only has HDMI input and breaks out HDMI audio to a D/A converter. Display controllers often have a board with switches to select between inputs and configure the display like a computer monitor. In the carputer case, fewer switches might be a good thing. I also like the idea of using only digital signals over distance. Solving glitchy or noisy analog audio/video problems is no fun at all.

Carputer 2015 - Motivation and Goals

Background

I've long wanted to do an in-car computer system but the timing was never right. Recently I decided that my midlife crisis car will be the car I already have: a 2007 Infiniti G35x sedan. Being willing to invest time and money into this car means I can finally have the carputer I want. Interestingly the carputer I want now bears only a passing resemblance to the carputer I wanted 5 years ago.

Mobile Device Integration

In-dash navigation used to be a really big deal. The factory Navigation Package including a 7" LCD touchscreen and Sirius XM Radio was a $2,100 option for my car. Needless to say I'm happy I declined. Now that mobile touchscreen devices are so ubiquitous, why would anyone want to be locked into an in-dash system that works differently and more awkwardly than one's own smartphone or tablet? The industry has clearly figured this out with integration platforms like Android Auto.

Starting Points

This is my car and its sorry 7" non-touch LCD screen. Status display is 15 kHz RGB video, just like old '80s arcade games! I still need access to status information but this washed-out and washed-up LCD needs to go.

The original Bose audio system is still good enough to my aging ears. I'm planning to integrate with the existing audio instead of replace it.

Philosophy and Goals

Having a software and systems background, I like to go into new projects with a set of guidelines. Here's what I've come up with for this carputer:

• Incrementally add and augment features such that at no point are existing features lost.
  e.g. Kickass visualizations aren't as fun if there's no way to know cabin thermostat settings.
• Integrate rather than re-create. Follow the mobile device integration philosophy.
• Carefully plan the physical installation.
  Do I really want to open up the dash and interior panels more than, say, twice?
• Be mindful of how and when components need to be powered.
• Run multiplexed buses over distance rather than individual signals.
• Be mindful of component placement and possibilities for modularity.
• Maintain a professional look when the vehicle is turned off. Hide wires and dongles.
• Start cheap and be able to justify increases to the BOM.
• Prototype outside of the vehicle until a minimally acceptable feature set can be achieved.
  Yeah, this probably isn't as fun when it comes to posting progress pictures.

The following is my set of non-negotiable requirements:

• The main computer shall run a Linux kernel. I understand this environment.
• There must be a highly visible touchscreen within usable distance from the driver.
• As a new feature, backup camera functionality must be integrated.

Continuation

I'm in the process of ordering parts for initial prototyping. I've tested a few system components to make sure they work and will satisfy requirements. I intend to continue posting status updates here on my blog and on Google+. It would be great if this becomes something of an open project with a degree of collaboration. You let me know what does/doesn't work and I'll let you know. Please let me know when I'm being stupid; I can take it. I'll attempt not to dwell on deep specifics of my vehicle so as to be useful to other carputer enthusiasts. Any generally useful software I develop will be made available, although I can't yet guarantee it will be open source or free.

Taking Control of Your Wi-Fi

Ubiquiti UniFi APs and Controller Software on Linux

Background

For years, I bought Wi-Fi routers and access points from the likes of Linksys, Netgear, D-Link, and Asus. Warranties would immediately be voided as I loaded alternative, Linux-based firmwares onto these devices. I started with DD-WRT before moving on to Tomato-based firmwares and OpenWrt. Tomato by Shibby is my choice for Broadcom chipset devices. OpenWrt supports a wide variety of hardware and has DIY geek appeal.

Gradually, I came to expand my network of Wi-Fi APs to cover the entire house, immediate yard, outbuildings, etc. If you're in an apartment or crowded suburbia, absolutely get yourself a quality device that supports 5GHz, like the higher end models from Asus. It's really crowded out there on 2.4GHz, so only use that as a fallback. Locate your single 5GHz device somewhere central and (hopefully) enjoy the speed and lack of hiccups.

On the other hand, some of us want to expand our coverage to several acres. No dead spots in certain corners of the house. Decent Wi-Fi coverage while out in the garden or mowing the lawn. Minimum lot size in my town is two acres, and it's not unreasonable to want that (or more) covered. This desire for increased coverage and easy management of multiple APs led me to try the UniFi products by Ubiquiti.

Dumb APs, Smart Control

Ubiquiti addresses the management and cost concerns of multiple APs by dumbing down the AP. The UniFi APs are simple, don't directly support web-based management, and don't really have the resources to run (comparatively heavyweight) Linux firmwares. What these APs do support is Java-based management software in the form of the UniFi Controller. The cross-platform nature of Java allows this software to run on Windows PCs, Macs, Linux boxes, and so on. You can fire up the software once to get things configured, and then not really worry about it. Alternatively, you can run the controller 24/7 to provide monitoring and captive portal functionality.

Now that I have a decently low-power yet powerful box on which to run this, in the form of a coreboot Chromebox, it's time to make the UniFi Controller run as a service on Linux. Ubiquiti somewhat supports this, but it still takes effort and research to make it right. For the benefit of myself and others, I'm going to document everything in one place.

Minimum System Requirements

Resource requirements are not especially light, considering you'll be running Java and MongoDB.

• 2GiB RAM
• 10GB storage
• Single 64-bit x86 processor core

In theory, other architectures should work, but don't expect somebody to have created packages or compiled binaries. Given RAM and CPU requirements, I don't recommend planning to deploy on an embedded ARM platform like the Raspberry Pi or BeagleBone Black. If you do manage to get this running on an alternative platform like ARM or MIPS, please let me know!

Selecting a Linux Distro

Ubiquiti appears to support Ubuntu and Debian best, providing repositories from which to obtain packages. The software itself is also available in a ZIP archive, for those who are pledged to another distro and willing to put in some work. I'll be documenting the procedure for Debian 7 (wheezy) here. Debian a good, solid choice for this. If you're able run this all in a virtual machine, I highly recommend it.

Installing and Configuring the Software

We start with a relatively stock Debian 7 install. I accepted most of the defaults, deselecting the desktop and selecting ssh and standard utilities package sets. Configure networking as you'd like it once the install has completed.

We'll add the apt repositories for Ubiquiti and MongoDB.

apt-key adv --keyserver keyserver.ubuntu.com --recv C0A52C50
echo "deb http://www.ubnt.com/downloads/unifi/distros/deb/wheezy wheezy ubiquiti" >/etc/apt/sources.list.d/ubiquiti.list
apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10
echo "deb http://downloads-distro.mongodb.org/repo/debian-sysvinit dist 10gen" >/etc/apt/sources.list.d/mongodb.list
aptitude update

Let's disable startup of the default MongoDB instance in advance. It's going to want to pre-allocate multiple GB of journal files, so best to avoid that.

echo "ENABLE_MONGODB=no" >>/etc/default/mongodb

Now we'll install all the packages, watching the UniFi controller fail to start. This is due to the unifi init script setting an outdated JAVA_HOME path. We can fix that in the init script or create a symlink. I'm going to recommend the symlink so we can safely upgrade the unmodified package init script in the future.

aptitude install unifi
ln -sf java-6-openjdk-amd64 /usr/lib/jvm/java-6-openjdk

Just to be safe, we can make sure services are stopped and database journal files are removed.

service unifi stop
service mongodb stop
rm -Rf /var/lib/mongodb/journal
rm -Rf /var/lib/unifi/db/journal

Now we'll edit UniFi controller properties to disable DB journaling, then start the service.

echo "unifi.db.nojournal=true" >>/var/lib/unifi/system.properties
service unifi restart

Now point your browser at http://<ip-address>:8080/ and accept the certificate to access the software interface. I hope you found this useful. Please let me know if you have problems or improvements.

Last Year's Phones: Nexus 5 and Moto X

The Lay of the Android Land

These phone comparisons have been done to death, so I'm going to come at this from a different angle. The touchscreen smartphone market has matured. In the Android space, the new Samsung Galaxy S5 and HTC One M8 are both rather incremental improvements over their predecessors. With unlocked prices well above USD $600 for these new flagships, one might reasonably consider paying half that amount for one of last year's finest.

Personally, I'm a stickler for a near-stock Android experience. Samsung provides a hodgepodge of their own multiple UI efforts along with the mandated Google pieces. Other vendors provide their own enhanced experience. All of this equates to lock-in. After many years of Apple's iDevice, iTunes, App Store lock-in, I refuse to go back. Thankfully, we have our Google Nexus branded devices, Google Play Edition devices, and soon Android Silver. Google's acquisition of Motorola Mobility aided the demise of the Motoblur UI in favor of a value-added, near-stock Android experience. Let's hope Lenovo, as the new owner of Motorola, stays the course.

Anyway, enough background. As an early adopter of the LG-made Nexus 5, I'm now transitioning to the slightly older and lower-spec Moto X. My home's metal siding and roof make for very poor indoor signal. Republic Wireless provides a clever solution, and their customization requires a Moto X or G. Thankfully, prices on the Moto X have dropped significantly since its introduction. Both the Moto X and Nexus 5 are in the $300-400 range without contract. Now, on to the phones.

Aesthetics and Philosophy of Use

Nexus 5 (left) and Moto X (right)

With its 4.95-inch display, the Nexus 5 is a somewhat larger device than the 4.7-inch Moto X. Some have critiqued the N5's "lack of style." To this, I must respectfully disagree. The Nexus 5 is a debadged, dechromed, monochromatic slab of a device. This in itself is a style statement. This is a device that exudes power without ostentation, making some competitors look like they're overcompensating. The only other distinguishing features are the the circular ear hole speaker and the unfortunate bezel "chin" extending below the display. The slightly rubberized back are sides are nicely grippy, if a little bit wide and angular in the hand.

The Moto X, on the other hand, has an understated class... and sexy curves. Its slightly rubberized back has a simulated carbon fiber look. The curvature not only feels perfect in the hand but is practical as well, encasing a stacked battery. The front glass extends to the sides, making them somewhat more slick than the N5. My only complaint would be the slightly too obvious microphone hole in the lower left of the front glass. If the N5 is a muscle car, the X is a sleek luxury coupe.

Upon use, the relatively minor size difference between these two devices appears to magnify. The ~5-inch display and full HD resolution bring the N5 into borderline phablet territory. Phone apps can feel like they're underutilizing the display. As an example, the Amazon store app feels limiting in a way that it just doesn't on the Moto X. The N5 is crying out for the ability to choose between phone and tablet apps. Thus, in the current state of the Android ecosystem, the Moto X is great as a phone and the Nexus 5 is a near-phablet that can't run tablet apps. Here's hoping that Google figures this out. This issue may not be obvious to users until they've had their phone for a while.

Display Comparison

Aside from the 0.25-inch size difference, display resolution and technology contribute to the perceived differences mentioned above. The N5's 1080p IPS LCD display makes small text and detail highly visible. Extended periods of reading are not a problem. The front glass is a perhaps a little more reflective than ideal, and the backlight can only get so dim for nighttime use, a typical issue with LCDs.

The Moto X sports a 720p AMOLED display. Text is less clear than on the N5, partly owing to the lower resolution and partly to obvious color fringing around object edges. It's not clear to me whether this is more an artifact of intentional anti-aliasing or the nature of the AMOLED subpixel matrix itself. The AnandTech review of the Moto X is informative.

Thus, the Moto X is definitely no e-reader. That all said, AMOLED has some benefits that are put to good advantage by Motorola. Blacks are black (no backlight), and display power draw is proportional to the number of subpixels lit. This sets the stage for Motorola's exclusive Active Display feature. With the display off, motion sensing and software are able to detect when the user has picked up or unpocketed the phone. The display then kicks in to show the current time and notification updates in white on an otherwise dark background. Just pick up or nudge the device and you'll get status without touching a single button or tapping the display. This is both useful and seriously cool.

Voice Controls: Ok Google (Now?)

Both the Nexus 5 and Moto X allow voice control of a number of phone and search operations. With the N5 switched on, unlocked, and at the home screen, the Google Now Launcher will respond to a spoken command of "Ok Google" followed by a directive or query. This experience is awkward to say the least. Once one has pressed the button to wake the phone and exited the current app by touching the home icon, is it really helpful to speak to the phone instead of just use it?

Once again, Motorola adds a feature that addresses real world use cases. The Moto X contains a subprocessor that is always listening for the phrase "Ok Google Now." It's necessary to train it, and perhaps the additional "now" was added to further prevent this feature from triggering accidentally. Still, this turns voice control from a novelty into a truly useful feature. I'm even finding myself saying "Ok Google Now, launch app-name" as I reach to pick the phone up from the desk, saving precious seconds. Can you tell I like this feature yet? I'm hoping this works decently with background noise in the car.

Miscellany and Conclusion

Cameras on both phones are passable, not great. It's a pity that so many OEMs are cutting costs and corners on sensor elements, optics, and imaging software/firmware. There are many reviews and comparisons out there with images taken from these and competitive phones.

Processing performance on both the N5 and Moto X seems entirely acceptable. They are subjectively faster than the 2013 Nexus 7. Benchmark results are available out there. The Moto X loses the spec war by having only two general purpose processing cores versus the more common four (or eight) in today's flagship devices. I can attest that browsing with Chrome, an activity that benefits from parallelism, does appear faster on the four core N5. For other activities it's kind of a wash. Looking purely at specs yields little practical information, as mobile processing is severely limited by power and cooling constraints.

Battery performance is somewhat low on both of these devices. The Moto X should do slightly better than the N5, but I don't have enough data yet to draw any conclusions. I'd generally accept a little more thickness and weight on all fixed battery devices to reduce mid/late-day charging hassle.

To draw some final conclusions, the Moto X is a great last-gen phone with some very unique features. Discounts have allowed this device to stay appealing despite it's age. The LG-made Nexus 5 is a very capable near-phablet with great potential. One hopes that future firmware updates will permit the N5 to come closer to realizing the potential of its hardware.

BeagleBone Black Exploration

The BeagleBone Black is an inexpensive ($45 US), ARM processor based hobbyist/developer board that runs Linux. This board is similar to the better known Raspberry Pi, enough so that's it's hard not to compare them. The BBB employs the embedded control oriented Texas Instruments AM3359 Sitara SoC, while the RPi employs the video oriented Broadcom BCM2835. I have both boards, so I'll definitely be comparing them.

I ordered the full BeagleBone Black (Rev A5C) starter kit from Adafruit including the 5V power adapter, prototyping breadboard and backplate and jumper wires, and "cape" PCB. I also recommend a microSD card to boot/install alternative Linux OS distros and a microHDMI cable/adapter and USB keyboard for debugging networking configuration.

BeagleBone Black and ChronoDot RTC on Prototyping Breadboard

The BBB comes standard with Ångström Linux on its onboard 2GB eMMC flash storage. Nod to the BBB over the RPi here. The Raspberry Pi requires a prepared SD flash card to get started.

For my purposes, I immediately loaded Arch Linux ARM onto a microSD card, booted from SD, and installed Arch onto the eMMC. I have to give a lot of credit to the developer(s) who produced the Arch image: it's nicely pre-configured to bring up wired Ethernet and SSH using DHCP. Arch thus allows a completely headless install and configuration. Alas, I messed up static IP configuration and had to attach a display and keyboard to work through it.

During the installation process, I felt motivated to benchmark both the eMMC and my microSD card (ADATA 32GB UHS-I).

Device	Read MB/s	Write MB/s
2GB eMMC	21.2	3.9
32GB μSD (BBB)	4.3	1.7
32GB μSD (PC USB2)	19.6	19.2

The SD interface is incredibly slow. The same card performs tremendously better on my PC monitor's USB2 adapter. I wouldn't want to run the OS from SD anyway, as reliability is always questionable. The microSD interface is clearly intended primarily as a means to load alternative distros onto the eMMC. Even using an SD card for a data/media filesystem takes a bit of effort.

Once running from the eMMC, the BeagleBone Black feels subjectively quick, certainly quicker than the Raspberry Pi. This is no surprise. The TI Sitara contains a more recent, higher-clocked, superscalar processor core with DDR3 RAM support.

My intended use for the BBB is as an internal network services (DHCP, DNS, NTP) and home automation controller. Like the RPi, the BBB doesn't have a battery backed real-time clock (RTC). I easily added one via the ChronoDot RTC and Lemoneer's excellent guide. The BBB has no lack of I/O and should be awesome for monitoring and control. There are even two dedicated PRU cores for true real-time control. I haven't explored this yet, but the PRUs may eliminate much of the need to attach Arduino microcontrollers a la the Raspberry Pi.

For my purposes, the BBB looks to be solidly better than the RPi. That said, the RPi still has some key advantages. There is a huge Raspberry Pi installed base and community. The RPi camera module is appealing. The RPi is decidedly superior for graphics and especially video tasks like XBMC. At these prices, there's something to be said for having one (or more) of each.

A Night and a Day on Backup Power

Power Management for Home Computing and Networking

In this installment, I discuss strategies by which computing enthusiasts may reduce power and retain or improve availability of home network services.

TL;DR TBD ;-)

Low Power Computing

There's never been a better time for low power computing. A lot of us are optimizing electricity use, not just because power is expensive, but because we've become mindful of waste. Smartphones, tablets, and ultrabooks use a lot less power than desktop PC setups. Mobile devices train us to be aware of power use. We can't always plug in, and it's inconvenient to plug in, so we optimize and prioritize around battery life. For those of us geeks who run home servers, more networking than a single WiFi router, whole house DVR backends, and home automation, it may be time to apply our power management skills to the home. I have some additional motivation: disruptive power outages that take my home off-grid, ranging from momentarily to minutes, hours, or several days.

On-Demand Battery Backup

I've owned a number of small UPSes from APC and CyberPower. These are a great help for those whose power is less than reliable. For many, this is all the power protection they need. Check out the recent "line-interactive" models with "active PFC". These are typically the best match for modern electronic devices where UPS cost is an issue.

If your equipment is mission-critical, especially sensitive, or you need to run on dirty power (as from a generator), you should be considering a "double conversion on-line" UPS. These units rectify current to charge batteries and feed an inverter that produces stable AC output. On-line UPSes are more expensive and less efficient than their line-interactive counterparts, but they serve their niche.

Generating Electric Power

If you live in remote or disaster-prone area, you may be considering the ability to generate your own power. You may be considering a photovoltaic solar installation even if you live in a center of civilization. Make no mistake, generating reliable AC power is a challenge. Some small or remote installations may be better off sticking to DC power and equipment. I won't write more about DC here, but may blog about in the future if I get around to implementing my dream DC system.

Typically, generating your own power means getting a generator setup that runs on fossil or bio-fuel. Good generators are expensive. Around here, some people spring for whole-house standby generators with automatic control systems and transfer switches. These setups usually run on natural gas or propane and cost $10K USD or more. Many more people have smaller "portable" generators that they backfeed into house power, a manual transfer switch, or just replug equipment into the generator itself. If backfeeding, it's critical to turn main line power off at or before the breaker/fuse box.

My generator is a 6500W (max) tri-fuel (gasoline, natural gas, or propane) unit that cost about $2.5K. It's got electric start, but I need to manually engage the key switch, flip switches in the basement, etc. to bring it on line. The generated AC power isn't very clean. I've seen frequency range from 60-64Hz and voltage from 115-130V. If I had an oscilloscope, I could see the ugliness of the "simulated sine wave" output. AC motors will sometimes vibrate on generator, lights flicker, A/V equipment exhibit audio noise, and cheap UPSes beep and refuse to charge their batteries or pass generator power through.

Real UPSes That Work

I can deal with most of the downsides to dirty, generated power. It's temporary; most things work, just not optimally. UPSes that discharge during the initial outage then refuse to charge or pass generator power are a huge annoyance. You'd have to shutdown, unplug, and replug each piece of equipment on each UPS to switch to generator power, then repeat the process to switch back to the UPS! This somewhat defeats the purpose of having a UPS in the first place. It took me a few years to take the hint and solve the problem.

My solution was to purchase a double conversion UPS with extended runtime battery pack. My critical equipment plugs into this UPS and will continue to run on generator power. Non-critical equipment that would suffer from unexpected outages goes on cheap, line-interactive UPSes. This non-critical equipment either survives short outages or stays off until line power returns.

• SU1500RTXL2UA Double Conversion UPS
• BP48V24-2U External Battery Pack

I went with Tripp Lite instead of APC because the equivalent (SURTA series) APC UPS was literally $400+ more.

Data for a Case Study

So now that you've heard the rambling details of why and how I addressed my problem, here are the specifics from recent testing. This takes us to the title of this lengthy post. I spent the night with the UPS unplugged to see how long it would run my critical equipment. Much of the next day was then spent on generator to 1) ensure batteries would charge and equipment run, and 2) determine how long it would take batteries to charge from 10% to 100%.

Equipment consists of:

• Comcast Business Class network gateway
• D-Link DIR-825 running as dedicated firewall/router
• Asus RT-N66U running as WiFi access point and network switch
• Raspberry Pi running critical network services and monitoring
• Thin Mini-ITX Intel "Ivy Bridge" PC running as DVR backend
• HDHomeRun network-attached dual digital TV tuner

I don't have exact power consumption figures all devices individually or all devices together. The UPS won't guess loads under 100W, so I know this is less than that. My back-of-envelope guesstimate is an average draw of ~60W. The runtime figures bear this out.

The equipment ran for just over 12 hours on battery. I was hoping for closer to 16 hours, but there are optimizations left to try. The UPS batteries charged well from generator while equipment continued to run. During the just over 5 hours it took the batteries to charge from 10% to 100%, there was one 19 second interval where input power went out of spec. The generator kicked up to 64Hz and 130V during this time and engine RPM and generator whine were obviously increased. I have no idea why. Anyway, I'm happy enough with these results.

Power Optimization Tips and Tricks

So, how to get from 12 hours to my goal of ~16 hours on battery? Tripp Lite has a nice calculator. Basically, I need to stay closer to 40W than 60W. To PC gamers that probably sounds impossibly low. Well, good thing I'm not gaming on batteries!

Most obviously, functions can sometimes be consolidated onto a single device. For instance, I'm running a separate firewall/router and WiFi access point. Most home users don't do that. Ah, but there's a method to my madness! During some extended power outages cable internet will go out; not always at first, but eventually power backup goes out at the cable headend too. In these situations I want to be able to "shed" the load of my Comcast gateway and firewall/router. And sometimes I just want to be able to power cycle them without taking down my internal network.

So separating and assigning related services that fail together into power/availability groups is sometimes useful. I have an "internet connectivity" group and a "home networking" group. Now, how to lower overall power use?

My PC-based DVR backend and TV tuners pull a decent amount of power. Yet when it comes down to it, DVRs only need to be powered up when they're being used.

Wake-on-LAN/Timer to the Rescue

Some PC-based equipment simply doesn't need to be fully powered up at all times. Modern PCs can generally be put to sleep (suspended to RAM for reduced power draw and quick resume) or hibernated (suspended to disk for no power draw and slower resume). Failing that, systems can be shutdown and booted back up when needed. This is all possible because modern PCs can keep a trickle of power going to a clock and system/network controllers while the PC is still plugged in.

Think of this like your TV. When the TV is off, it's really in "standby". A sensor and controller are powered and waiting to detect your press of the "on" button on the TV remote.

Let's go back to my PC-based DVR example. If this system drew a lot of power, it might make sense to keep it powered off until it's needed to record or stream content. Since my particular system only pulls 15-45W, it's more convenient to keep it on and immediately available. That equation changes when I'm running from battery. This calls for a little automation:

1. When line power is available, power on, stay on, and run normally. Done.
2. When running from battery and the system is idle, set the wakeup timer to just before the next scheduled event. Go to sleep or hibernate.
3. When the pre-set timer goes off, wake up if sleeping or hibernating.
4. When receiving a magic network packet, wake up if sleeping or hibernating.

The "magic packet" allows another computer or device to wake or boot an otherwise unavailable system from a standby state on demand. There are a number of utilities available to send magic packets through a manual UI or scripted interface. Some systems also support the ability to wake on keyboard/mouse activity or selective USB activity. These are very cool and underutilized features outside the world of portable PCs.

Power Control Hacks

I also mentioned that I'm running a network-attached digital TV tuner. Logically, this is part of a "DVR" power/availability group. The tuner box only needs to be powered when the DVR backend is recording or streaming live TV. Unfortunately, the tuner box doesn't support power management. It's either plugged in and on, or unplugged and off. Some devices are like this.

A little research shows that the HDHomeRun tuner runs on 5V and under 2A. My PC-based DVR already contains cables that can supply the proper voltage and current! Let's say that I hacked a SATA power cable to provide 5V at 2A to a barrel connector that could be plugged into the tuner. Now (in theory) I have a tuner that can power off and on as the PC sleeps and wakes.

Software/Firmware Power Tuning

Intel, AMD, and the various ARM vendors have gotten pretty good at making the hardware and firmware recognize demand and selectively power up/down functional units and communications buses. This used to be done with software (if at all). Still, there are sometimes power saving drivers to install or driver options to tweak to save a little juice. A blunter approach is to disable (in the BIOS/firmware) or remove devices that aren't needed. Underclocking and/or undervolting CPUs, GPUs, or RAM is also an option.

Consolidation and Virtualization

As I stated before, sometimes combining and consolidation is detrimental to sensible grouping and availability of services. Oftentimes, consolidation is brilliantly appropriate. System and container virtualization can make consolidation even more applicable. Let's say I want to add a software PBX like Asterisk to my mix of services. I could easily install this on the DVR system, preferably under virtualization to isolate it from the DVR system image. The PBX would go up and down as the DVR system wakes and sleeps during outages. That said, my voice-over-IP (VoIP) provider already forwards calls to my cell phone when my PBX is down. This makes the PBX a useful but not critical service. And there are potentially ways to proxy voice service and wake the PBX system on incoming calls.

Roll Credits

If you made it this far, I admire your fortitude. Believe me, I wasn't planning to write such a voluminous tome. As always, questions and comments are welcome via Google+.

Repurposing the HTPC

Several month ago, I built a slim form factor Windows 8 PC to act as a media streaming frontend. Notes here:
http://travesh.blogspot.com/2013/03/super-slim-intel-htpc-build.html
http://travesh.blogspot.com/2013/03/super-slim-htpc-followup.html

Total overkill as an HTPC for everything but games, yet I hadn't found a better solution to stream MythTV recordings, Netflix, Amazon Instant Video, etc. to single frontend. Android solutions were flakey or slow. Netflix uses Microsoft Silverlight, so good luck getting that on Linux. After a while, I added Aereo and Plex to my streaming requirements. Windows 8 on a small PC can do all of this, but it can't do it like an appliance with a unified UI. I bought a Roku 3 and the PC sat for a bit.

Having torn down my big MythTV backend when the summer TV doldrums went into effect, I'd been starting to feel the pressure to put MythTV recording back into service. Aereo's cloud DVR has mostly worked for me, but not 100%. Fundamentally, their service is a legal and technological hack; I'll enjoy it for now, but can't totally trust it.

So the now unused PC frontend has become the new DVR backend. The SDD got replaced with a 500GB 2.5" 7200rpm drive for video storage and Windows 8 got wiped in favor of Mythbuntu. My goal this time around is low power recording. When I lose electric service (as I often do), I want my DVR to keep recording on UPS and/or generator. There's also just the cool factor of the low power x86 and ARM trend. Everyone is starting to care at least a little about heat and power.

All said and done, the new DVR backend idles at 16W. That's insanely good! And this is Ivy Bridge, so who needs Haswell? And especially, who needs Atom? My old Atom 330 always idled at about 35W. The later Mini-ITX Atom boards were better, but never great. ARM isn't quite there as a DVR backend; disks over USB, 10/100 Ethernet on most boards, weak transcoding speed and support. I was planning this elaborate sleep/wake configuration for the Myth backend, but I might not bother. Always-on is just easier.

I'm planning my next blog post about separating the DVR recording backend from transcoding, archival storage, and streaming. The slim form factor Mini-ITX Sandy, Ivy, and Haswell get a huge thumbs up from me as a near ideal solution for DVR recording. And at 16W idle, you may want to run some other always-on services from this system as well. Power tuning is still in progress. How low can we go?

Developments in Home Streaming

After 10+ years of building and running home theater PC boxes (HTPCs), cheap streaming appliance frontends may finally be good enough to present a variety of local and Internet content on 1080p displays. This blog post provides a brief summary of the hardware and software solutions I've recently abandoned, and some suggestions and hints toward what might approach video Shrangri-La.

In mid-2012 I discontinued use of my TiVo HD in favor of a MythTV setup with HDHomeRun network attached tuners. For nearly a decade, I'd run TiVo series 1 and 3 (HD) boxes for my cable recording and living room display needs. The old TiVo was a life-changer. The original TiVo team built a brilliantly usable interface to fundamentally complex functionality. Unfortunately, TiVo has become something like the Palm Computing of DVRs. The current devices aren't that much more advanced than the original devices in terms of actual interface and practicality. It's like TiVo laid off a brilliant team of engineers and failed to foster partnerships in the industry. When my local cable provider switched to digital-only, I ditched the TiVo rather than fighting with CableCARD and re-committing to TiVo. I will not support the cable industry's lockdown of content by turning every DVR or cable box into an additional source of revenue for the cable monopoly. This is now the age of Ethernet and Internet streaming. I refuse to acknowledge my cable provider as anything but an Internet pipe and source of local broadcast programming. I realize that many get the extended or premium cable TV packages. I'm done with that. I'll get my HBO and Showtime series over DVDs or streaming services long after the programs initially air. Considering most network's proclivities to cancel new programs, I'm willing to wait a couple years for those programs that pass the gauntlet, and receive them at a time-discounted price.

I've run local streaming server and client HTPCs for years. PCs, especially Linux and open source PCs, have offered the freedom to store and stream personally owned/managed content for years. Just as the TiVo was my DVR, my HTPCs happily served up my personal AV archive and DVDs to any display in the house.

This year, I've experimented with devices like the MiniX Neo X5 (Chinese, Android-based TV box) to act as cheap clients to attach to HDMI displays. I also built a new Windows 8 HTPC to access XBMC, MythTV, and streamed Netflix and Amazon content: http://travesh.blogspot.com/2013/03/super-slim-intel-htpc-build.html. In the end, neither Android nor Windows boxes are what I want attached to my displays. I want set-top boxes that work like appliances and have custom hardware and Linux underneath. I don't want to futz with custom Android firmwares and the intricacies of hardware accelerated playback, nor the complexities of a full Windows box with an awkward combination of Metro apps and some (annoyingly) browser accessed content. What I want, and what I suspect many want, is something akin to the old TiVo appliance that can seamlessly access both local media and current Internet streaming services. Nothing else will do. This past week, I repurposed my long-serving AMV/Nvidia (MythTV) HTPC to be a network firewall/router and bastion host. I expect to repurpose my new Windows 8 HTPC as a network server this coming week. PCs are finally becoming overkill for driving 1080p displays; they're still too much like PCs and not enough like appliances.

My current preference for driving displays is the Roku 3. The works like an appliance for the sources I use: Netflix, Amazon, Aereo, and Plex. My Synology box now acts as a very adequate Plex server for my own content, and can be integrated to work with my MythTV backend. Netflix, Amazon, and Aereo can stream at 720p or 1080i/p. The Roku has a great appliance interface and a great remote control. I love being able to attach headphones to the Wi-Fi remote control itself for quiet late-night viewing.

In the end, here are my recommendations: A Roku 3 for each dumb display, a MythTV backend for cable-based content, a Plex server for your personal media archive, and portable devices to shore up any other areas. Aereo may be here for the long haul, or may be a flash in the pan. MythTV and ClearQAM or CableCARD also have an uncertain future. Transcode or pop your archive and TV content onto a Plex server to stand the test of time. The world of broadcast and streamed video is changing rapidly. I generally trust the Roku (version 3) and Plex to stand the test of time. This may change. ;-/. I'll be right there to inform as changes occur. As always, I'd love to hear on G+ what's currently working for everyone else or what direction you're heading. Cable and Internet video is always a moving target. This will presumably settle down at some point, but we're in a period of disruption and business and legal change. I simply hope you AV enthusiasts out there are navigating a path that works for your and your family! I'd love to hear your chosen path(s). Thanks for listening during these unsettled times!

Old New England Homes

[Veering off my normal technical-only discussion today due to impending hot weather forecast for my part of the world later this week.]

My home in New Hampshire was built around 1850 to replace the run-down old garrison just to the north. The story is that some salvaged materials (bricks, timbers, boards?) from the old garrison were used in the construction of the "new" farmhouse. The garrisons were fortified to repel Indian attacks and abductions in the area into the mid-1700s. My family roots in this area run deep, and numerous ancestors were killed or abducted, especially around the time of the Dover, NH Massacre of 1689. Abductees were typically taken north to Quebec and held for ransom. One of my ancestors was a "heroine" of the Dover Massacre; another declined to return to her abusive husband after abduction to Quebec. There's a lot of history here. Of course, documented historical roots don't run as deep here in the New World as in Eurasia. I recall staying at an old, old inn in Wales in 2006 where one corner of the room was obviously several inches higher than the other.

Like many old New England homes, my home has a borning room. This is a small room just off the kitchen/hearth where mothers would give birth, infants would be tended, and the sick and elderly would be provided solace. The hearth was the living center of the old New England homestead. This makes special sense given the history of the Little Ice Age in North America. My home, although not especially large for the time, has a vaulted brick arch in the basement to support the dutch oven and fireplaces on the first floor. My paternal grandparents acquired this home in a somewhat run-down and unimproved state (no electricity, plumbing) in the early 1940s. My 3rd great grandfather had lived in this same home when it was relatively new. Homes "in town" during the same period would have had better amenities, higher ceilings, grander staircases, etc. compared to rural farmhouses. On the plus side, I have almost 500 acres of conservation land in my back yard.

For the past couple years I've been sleeping in the small borning room off the long, farm-style kitchen. This room has space for a small bed against three walls, a nightstand and dresser. It also happens to be cold in the winter and hot in the summer due to a southeast location and little insulation. Many new homes aren't built to last, but at least they're using a sensible layout and insulation. Surviving old homes were built with quality materials, yet impose compromises for modern living. With a warm weather forecast for later this week, I've decided to change to the upstairs bedroom. I've ordered a small window air conditioner to hopefully arrive and be installed before hot weather strikes on Thursday.

When my grandparents acquired the house, the upstairs was largely unfinished. My grandmother had most of the upstairs built out as a separate apartment some years after my grandfather passed away. The current tenant has been there for almost 30 years. I retain one bedroom at the top of the (steep) front stairs with no upstairs bathroom access. This certainly isn't the house as I want it to be. That said, I have a great tenant and will be gradually making practical improvements. For now, I need to figure what should be moved to the upstairs bedroom to make it habitable. I have a bed, lamp, and nice closet but desperately need a bedside stand and dresser. Longer term, I'd love to figure out either a fix to the steepness of the stairs or a separate upstairs bathroom situation. It's all possible, but starts to run into real money. At some point, I run the cost-benefit analysis as to whether it's better to buy/build the home I want and force renters to deal with the quirks of the old farmhouse.

Cutting the Cable?

In this installment, I'll discuss the gradual progression that's been driving my brand of AV enthusiast away from the cable TV monopolies and onto the Internet. I'll also focus on Aereo's local broadcast DVR service in both a mini-review and in the larger landscape.

The more you tighten your grip, the more star systems will slip through your fingers.

- Princess Leia

This quote often springs to my (admittedly twisted) mind when discussing the lengths to which media distributors and cable monopolies such as Comcast, Time Warner, etc. will go to maintain control in a world of cheap recordable media and broadband Internet service. On the Internet, everything is just (potentially encrypted, unrecognizable) data. The media genie has long escaped the bottle. Somehow the RIAA and music distributors (MB/song) got the message, but the MPAA and cable companies (GB/video) are still refusing to give ground. I recall being young and poor and not wanting to pay for intellectual property I couldn't afford anyway; this is still the third world argument for rampant IP piracy. It's not a terrible argument. If duplication/distribution costs are negligible and legal distributors won't operate in your region, why should distributors be able to restrict your access to information and entertainment? Is infotainment for the producers or the audience? It takes both!

I now have the money to legally access the media I desire and the value system to resent overly restrictive controls and obsolete business models propped up by bad laws. Here is my manifesto.

1. I will pay for the content I want if the terms are at all reasonable. I have bought (sometimes rebought) much of my digital music on iTunes and Amazon. I pay for Netflix and Amazon streaming.
2. I am reluctant to pay a one-time fee to "own" or stream a piece of DRM restricted content.
3. If the content owner will not sell into a region, I do not believe piracy in that region is wrong. Information wants to be free.
4. I will not pay dozens of monthly fees to get the content I want. There is absolutely a place for content aggregators and streaming services.
5. Whenever one distributor/studio "takes their toys and goes home" by establishing a separate service for their content, I will boycott that distributor. You chose to be difficult; there are other fish in the sea.
6. I will not step back from the functionality of a TiVo to skip commercials or replay content. I will not pay money for locked-down content.

Wouldn't it be great if the industry could just work out a reasonable plan for both DRM-free video downloads and cross-platform video streaming? Kudos to Apple for absolutely forcing this on the music distributors back in the day and actually saving their revenue streams in a changing world.

Then there's the broadcast networks and cable companies still trying to eek out an existence from advertising, cable transmission fees, and monopolies and legal bullying. Since there's apparently no reasoning with all the broadcast networks at once unless you're a cable monopoly, we now have companies like Aereo. In case you haven't followed the drama, Aereo is trying to work within the law to provide each subscriber with their own tiny TV antenna and DVR streaming service in their local broadcast area. Cloud-based DVR streaming already has legal precedent behind it. Aereo's service is especially useful for those viewers on the outskirts of the metro broadcast area (like me) or with physical obstacles in the signal path (like me) or with intractable landlords. Aereo is specifically not for people who wish to receive extended or pay cable channels; it's for cable cutters for whom a physical antenna is difficult or impossible. You're paying Aereo a monthly fee to host your antenna and DVR. There's some interesting technology behind this, but the legality seems fairly straightforward. The lawsuits are flying and Aereo has generally been prevailing. Fox and CBS have threatened to pull their broadcast stations if Aereo ultimately prevails.

If Aereo is able to grow quickly enough to establish a significant subscriber base, they may be able to negotiate with the networks just as the cable monopolies do now. This is certainly my hope. This would also allow Aereo to reduce their resource requirements by storing a single (replicated for redundancy and performance) stream for each provider with whom they have an agreement. It's almost a given that broadcast TV will go away in the next decade, freeing up the spectrum for other uses. The FCC will need to change the regulatory landscape to provide some degree of free access to public news and alerts on TVoIP.

If I haven't mentioned much about the Aereo service itself, it's because it pretty much works as advertised. I'm on the $12/mo plan that provides two simultaneous channels and 60GB of DVR space. I'd love to know more of the technical details behind how they make their system work. There's apparently some serious transcoding going on at recording/viewing time. They're almost certainly not doing data deduplication for video storage; this would add a legal gray area, and they're absolutely trying to stay legal. I've tried viewing both on a laptop screen and across a room on a TV. Close viewing shows very obvious macroblocking artifacts, visible interlacing on some content, and horizontal line artifacts where 1080i content is being naively downscaled to 720p. At TV viewing distances, most issues become "good enough" for this non-videophile. Lack of macroblock dithering/blending for large areas of a similar colors are still visible. It may be possible to eliminate much of this by properly calibrating display brightness levels. I have not observed frame skipping or lengthy buffering problems.

Aereo is presenting a somewhat specialized solution. If you're tied to cable Internet, bundled basic cable may be a better deal. If you want cable/satellite-only channels, you'll need cable or satellite. I'm no longer willing to put a locked-down, slow, and awful cable box on each of my displays. The cable company has tightened their grip with encrypted digital content and threatened removal of unencrypted broadcast content (ClearQAM) formerly mandated by the FCC. The cable companies are trying to drag us back to the bad old days of the phone company ("Ma Bell") when everyone had to lease each and every phone from the monopoly provider. Grasping behavior like that has me slipping through their fingers.