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.