5 Reasons to Use a Custom Android Tablet

There’s two sides to every coin. In the last post, I talked about instances where I usually recommend that people use an off-the-shelf tablet or smartphone device for their custom applications. The primary principle being keeping things simple, I recommend developing portable apps wherever possible, and avoiding potentially time and cost intensive hardware turns and development. But sometimes a custom (Android) tablet is required, and it’s worth knowing when to recognize these instances, and follow the path of least resistance.

It’s why the Liquidware Amber exists. We designed it for internal use, and use in engineering projects. It saved us a ton of time having that extra level of hardware and firmware customization, without having to start from scratch each time.

1) Sensor specificity and connection interface. In many cases, the end device is driven as much by the sensor as it is by the display. For example, a tablet may serve as the human-machine interface for a medical diagnostic device, but the sensor that is attached to it could be highly complex. Or the sensor required talks over a very specific protocol, such as I2C or SPI.

2) Custom hardware feature set. In many cases, the product calls for integrating more than just sensors to tablet HMI. Kiosks, industrial control terminals, and other large scale machinery come to mind. Nevertheless, the tablet portion doesn’t need to be built from scratch, and a custom tablet like the Amber allows for tight systems integration over several different interfaces.

3) Supply chain management with high volume. Designing a product to be deployed in volume brings other considerations into play. Considering that most consumer devices are built to be sold within a 24-month lifecycle or less, since they’re designed with obsolescence and upgrade paths in mind, the supply chain of these devices can be fickle. This means that in order to incorporate an off-the-shelf device into a product design, it’s probably a good idea to consider buying all the units you think you might need. Upfront. Which can translate to a pretty significant capital investment. A custom tablet enables tight control over the hardware manufacturing, and ensures longevity of the product, to maximize the value of upfront engineering, design, and systems integration work.

4) Custom OS and firmware. If the product is going to require highly customized kernels and special firmware that allows the tablet to integrate with other components of the device, it’s not exactly efficient to root and re-load a custom ROM/kernels on each individual unit. And voiding any sort of warranty in the process.

5) Security. The other (somewhat unexpected) driver of custom hardware requirements has actually been one of security. Understanding exactly what is going into a particular device and having control over all layers of software can help make the device less transparent and less vulnerable than stock devices currently available. For instance, a custom Android tablet include any manufacturer software, and doesn’t have GPS (if you don’t want it) so you’re not inadvertently broadcasting information that you don’t want released.

There are many other considerations, such as form factor and branding, that just might tip the scales in favor of using a custom Android tablet. And as with big questions in embedded systems development, the answers aren’t always obvious.

So if you’re on the fence about which way to take your custom tablet project, feel free to comment below, or get in touch – justin dot huynh at liquidware dot com.

How to read Arduino sensors with Adobe AIR Flex on Android

Android now supports Adobe AIR / Flex apps. The main benefit to using Flex over Java is that it specifically facilitates rapid story boarding of mobile user experiences. Coding Adobe Flex is similar to the Visual Basic observer design pattern of push-based actions. Add a button, right click to edit the action.

I decided to show how one could access the serial port using the Amber Android handheld, Arduino, AMBI light sensor using Adobe Flex.

Arduino Code

Upload this simple sketch to the Arduino.

void setup() {
    Serial.begin(115200);//setup a serial port with a baud of 115200

    pinMode(18, OUTPUT);
    pinMode(19, OUTPUT);
    digitalWrite(18, HIGH);
    digitalWrite(19, LOW);
}

void loop() {
    int value = analogRead(3); //read arduino analog pin 3 and save it as an int to value
    delay(1000);//delay 1,000ms
    char out[200];//create a 200 integer array

    sprintf(out, "hi\nLight=%d\n", value);//prep the out file
    Serial.print(out);//print the out array
}

Android Java Code

Android must forward serial messages to a local network socket so Adobe flex can handle the data. This is accomplished using the amber-serial app. 

Get the amber-serial source code on github, import this into a new project in Eclipse. Upload to Amber and keep the it running in the background.

Adobe AIR Flex Code

Create a flex app in the Adobe Flex builder through the wizard. Add a button to window and use the following code to read Arduino messages from a local network socket. I used port 8888, but you can use anything you'd like, just make sure to open the port in your firewall with iptables, if used.

socket = new Socket();

socket.addEventListener(Event.CONNECT, onConnect);

socket.addEventListener(ProgressEvent.SOCKET_DATA, onSocketData);

socket.connect("127.0.0.1", 8888);

private function onConnect(e:Event):void {

textarea1.text = textarea1.text + "Connected to server";

}

private function onSocketData(event:ProgressEvent):void

{

textarea1.text = textarea1.text + "[" + event.type + "] " + socket.readUTF();

}

App design tools have come a long way, now you can rapid prototype low-level sensors all the way up to the UI design.

Intro to Liquidware Amber, Part 2

First off, thanks to the wonderful folks over at Adafruit and Engadget for checking out the Amber! It’s been great hearing all the thoughts, feedback, and questions so far. While Mike and I get some of the projects and walkthroughs all documented, I’ll be posting them over the next week. In the meantime, some behind-the-scenes action, and a preview of what’s on deck…

Many of the questions about Liquidware Amber revolve around a couple common themes, which I’ll do my best to explain here:

What exactly is this “Amber” again?

It’s an easily customizable Android tablet. It originated as a tool that a few of us here used in a variety of projects to get things going a little quicker. I think of it as an “80% finished” device…which means that it works for a variety of different applications that make up the last 20% percent of the project, such as peripheral sensors, wireless connectivity, and the finished form factor.

I don’t understand why I shouldn’t just go get an iPad.

I actually did buy a tablet, for tablet purposes – the Acer Iconia A500. I liked that it was Android, that it had accessible, removable, upgradable microSD storage, and that it had a USB host port.

As much as I’d like to say I would, I don’t use Liquidware Amber to read ebooks and PDFs in bed, or to sit in the park and watch Hulu. I don’t need to customize a tablet for that. Any number of mass market consumer tablets would fit the bill way better, and cost a lot less (unfortunately, I’m not building millions of Ambers, and I don’t own massive overseas factories to do everything for me fast and ridiculously cheap!).

However, if I needed a 7” touchscreen enabled interface for something like my own a special ATM that dispensed only Monopoly cash (that I’m only building 100 units of), the Amber would save me a ton of time. I have a customizable Android tablet ready, dual USB hosts and other GPIO that allows me to focus on integrating functional parts, rather than trying to build everything from scratch.

It’s a little bit of an experiment in rapid prototyping, but more on that next time…

Okay…where can I see the Amber in action?

I’m in the process of putting up more Amber projects and tutorials, but a couple things I have handy along with my Amber are my Linux laptop, a good USB Type B-mini cable, and Android Debug Bridge (adb).

This pretty much allows me to test out peripherals with the Amber, write my own drivers, test out my own apk’s and compile custom kernels. I’m starting to compile a lot of the very basic adventures in Android applications on the Amber over on the new Antipasto HW wiki page.

I’ll also be writing up a better tutorial on getting the toolchain going. I’ve learned the hard way how important that is…and how much I’d rather not sit around installing packages when I should be busy integrating my prototype!

Also, here’s a sneak peek at some of the projects that I’ll be uploading as I get to them this week:

Build my own DIY ATM (for Monopoly money)
Design a custom retina scanner and display for entry to my room
Install a 3G/4G cellular modem on Amber
Physical computing with Arduino and Amber
Cloud computing and kernel hacking on Amber

And a couple recaps on basic network/Android debugging stuff that I found helpful when I started:

Setting up Eclipse and Android SDK
Writing my own Android Skeleton App
ADB tips and tricks
Port forwarding for remote access

That’s it for now, but I’ll be getting back to more questions over the weekend.  Feel free to suggest more in the comments, or just email me at justin at liquidware dot com…

Introducing Liquidware Amber

One of the most common questions I get is, “Can I build my own Android tablet for [my project]?”

That’s also something that I spend a disproportionate amount of time working on. Now, rather than starting from scratch, I’m starting from the level of say, ripping the case off my tablet and rooting it. It’s not as violent as it sounds. The point is, I need something about 80% of the way to a tablet.



Conversely, I could build my way back up from something like a BeagleBoard, but in many cases, it’s much more of a prototype than I really need.

After a while, we had an “80%-finished”, 7” Android tablet that came in very handy as a starting point for custom tablet-related projects. I like to think of it as a “foundational technology”, but since that’s quite a mouthful, we decided to call it the Amber. This is the part where it looks like a tablet…

…And this is the part where it looks very…80%-finished.

The whole idea being that I want a starting point far enough along, so I don’t need to build everything from scratch, but not so far along that it’s a pain to customize.

The Amber is a 7” projected capacitive tablet driven by a 1 GHz, ARM Cortex-A9 OMAP3730 from Texas Instruments. We’ve customized a version of Android Gingerbread 2.3.4 to run on the Amber, and its 2 USB host ports offer high-speed USB and serial communications to a pretty wide range of devices. WiFi, Ethernet, cellular, and battery configurations are available as part of the Enhanced or Pro versions of the Amber.



I’ll be uploading more shots and tutorials of cool (and hopefully useful) things I’ve worked on with the Amber and Android development. Meanwhile, here’s a couple videos of the Amber in action: