Thursday, September 24, 2015

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.

Thursday, September 10, 2015

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...

Tuesday, September 8, 2015

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.

Friday, July 31, 2015

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!

Monday, May 18, 2015

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.

Monday, May 11, 2015

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.

Sunday, May 3, 2015

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.