How to build a DIY perpetually-powered wireless outpost

Earlier this week, I had a mystery box of electronics and was looking for something to do with it. Thanks to Bryan from New Zealand, who asked about creating a wireless farm monitoring outpost…

The idea of a perpetual power supply comes up now and again, mostly in the context of a remote outpost. Naturally, the idea of creating mesh networks in the wild and digital dead drops appeal to my inner Bourne, but that’s a story for a different day.

This project is really broken out into two parts: the perpetual powering, and then doing something useful with the perpetual power.

Perpetual (Self-Replenishing) Power

I found a couple of Mike’s old boat motor batteries, along with some 12V solar panels we had here in the lab. Since the batteries were 24V, I put the solar panels in series. Some back of the envelope math, along with my handy voltmeter, suggested that the solar panels could charge the batteries at about 200 mAH outside in the sun.

For the month of August, here in the Boston area, I get about 13.5 hours of sunlight. That means, each day, I’m storing about +2700 mA per day.

Testing the system that I have in the mystery box (which I’ll get to in a second), I’m burning a low of -75 mAH and a high of –150 mAH. It averages out to be about –100 mAH, or –2400 mA per day, for a net of +300 mA per day.

The massive batteries ensure that things will keep going for a while, even if I’m wrong about how much sun is getting through, and if there happens to be an unexpected volcanic cloud over Boston that day.

The Mystery Box (a.k.a. awesome Pelican case o’ stuff)

I put the batteries in the box, along with a BeagleBoard xM, BeagleJuice 2nd Gen, and BeagleTouch, as well as a couple Arduinos to run sensors.

The Pelican case itself is designed to be waterproof, although I hacked the neoprene o-ring in the front to run wires out of a single location. For testing purposes, I have a light sensor hooked up to the Arduino, and I have an AT&T 3G setup running from the BeagleBoard, which is sharing that Internet connection over WiFi to create a wireless hotspot. (If you look carefully at the top, I stuffed a wireless router in there as well)

There are three key links here, which each deserve a separate blog post complete with code:

Light Sensor to Arduino
Arduino with Sensor to BeagleBoard
BeagleBoard to 3G (I’ll write a blog about how to do this as well, but Dune made an excellent post, which got me started)

Towards the bottom, I also included a couple USB-powered speakers…  (Oh the possibilities! :-)

Matt helped me dig a hole in the ground to bury the case, and then we ran some of the wires through a PVC contraption we made to mount the solar panels and WiFi antenna. It’s not the neatest thing in the world, but it works.

I’ve built a (mostly) perpetually-powered outpost, using a Pelican case, solar panels, some boat batteries, and an Android-powered BeagleBoard setup that converts a 3G cellular connection into a WiFi hotspot, all while logging and uploading sensor data. Now all I need is a coffee maker, and I’ll basically have Starbucks!

Naturally Mike had a brilliant idea for a light sensor and speakers…after all, what farm outpost would be complete without a rooster’s cockadoodledoo every morning. So I present to you, Mike’s Digital Cock app :-)

Next week, I’ll break out each piece of the project into distinct tutorials, especially the 3G cellular modem + BeagleBoard + Android component, which quite a few folks have been asking about.

What would you do with a remote, perpetually-powered wireless outpost? I’m planning to save this one for Halloween to have a robotic, motion-detecting scarecrow…

Post your thoughts to comments, or get a hold of me on twitter @liquidware, or over email at justin.huynh@liquidware.com

Powering my Raspberry Pi with the BeagleJuice, 2nd Gen Battery

My Raspberry Pi finally showed up today! Naturally, an unboxing event was in order…

I haven’t gotten around to setting up my SD card yet, but I just wanted to see if it would power on with the BeagleJuice sitting on my desk. In theory, it should work, since the BeagleJuice outputs 5V from each of the 2-pin molex connectors.

I took the micro USB cable that I spliced last week and plugged it into the Raspberry Pi…

…then I connected the other end to the BeagleJuice.

And voila! The Raspberry Pi powers on, as indicated by the red power LED next to the audio jack. Just for kicks, I plugged in the BeagleBone to the BeagleJuice as well (with a 5V barrel jack) to make sure they both run simultaneously, and they do :-)

What project should I do today?

Chris and I were kicking around a few ideas on excuses to get out of the office and work on some interesting projects while we’re at it. I’ve personally gotten quite a few emails for some cool projects, so we decided to kill two birds with one stone.

As a huge fan of The Ben Heck Show, as well as Ladyada’s Ask an Engineer, I thought some kind of interactive weekly Youtube show might be a fun experiment that could also get some local Boston makers involved as well. It also solves the $1,000,000,000 question (that I wake up to most mornings):

What project should I do today?

The first idea I had is something like an Iron Chef but for electronics and hacking. There’s some set of secret “ingredients” inside a mystery box, and the challenge is to come up with some kind of project we can do with what’s inside.

A twist on this would be to pull a random project suggestion from the virtual mailbag, and then try to make things work with what’s inside. So if there’s a project you’ve been stuck on, just wanted to see built, or you just think would make a good tutorial, post to comments, twitter me @liquidware, or send me an email at justin@liquidware.com

Now it’s time to think of a good title for this show…

How to build a high-tech prototype faster than it takes to build a 30-story hotel

I stumbled across a video recently that I thought was pretty amazing. It’s a time-lapse video of a 30-story hotel that was built in 15 days.

Mind you, this wasn’t a shoddy structure. It’s designed to withstand a 9.0 earthquake, along cutting-edge energy efficiency features. How’d they do it? (The longer story from Businessweek is here)

We make 93 percent of the building in our factory. The basic block, a “main board,” is 3.9 meters by 15.6 meters (12.8 feet by 51.2 feet) and includes everything from water pipes and ventilation shafts down to floor tiles, lights, even toilets and the kitchen sink.

Building blocks. The principles of “prefabrication”, or prefab, for short, have been around for a while now, especially in the realm of architecture and construction. This project just took it to a whole new level. Everything in the building was modularized, trucked out, and assembled. These blocks were strategically unfinished, designed to be connected to other blocks to form the completed structure.

What can hardware and embedded systems design learn from this?

The modular hardware ecosystem has continued to grown, becoming more accessible to an ever-expanding base of developers. With the Arduino, Raspberry Pi, BeagleBone, BeagleBoard, and others, there’s an incredible amount of processing capability out there, in an easy to integrate, easy to program, modular form factor.

Prefabbed building blocks exist for the Arduino in the form of shields, BeagleBone in the form of capes, and the BeagleBoard in the form of modules. These all make the integration process extremely low overhead – with hot-swappable operating systems bootable from removable media.

David Blaza, Vice President of UBM Electronics (the wonderful folks who bring us the Embedded Systems Conference and EETimes) recapped this growing trend in development. Interestingly, it doesn’t even have to happen in this particular order anymore…and just about anyone can do it:

1) Outline the concept (5-10 hours). A lot of startups, entrepreneurs, hobbyists, and engineers already have this part nailed down really well. Napkin sketches or Visio flowcharts, the concept is something that comes naturally to inventive minds. It’s just useful to whittle down features and ideas to focus the very first prototype.

2) Raise financing – or not (2-3 hours to craft and setup a campaign). This is an optional step these days, but crowdfunding sites Kickstarter and Indiegogo, or peer-to-peer financing sites like Prosper provide an easy, accessible way for individuals to raise money and publicize their projects on the cheap.

3) Pick a hardware platform (3 hours). For me, it’s typically come down to a couple main hardware drivers. If I need analog sensors, I’m probably going to involve an Arduino along the way. Then it’s a question of what screen size (4.3-inch or 7-inch are common) I’ll need, CPU speed, and connectivity. If I know it’s going to be fairly integrated (as all the folks asking for a custom tablet are aware), I’ve usually selected something like the Liquidware Amber.

4) Pick a software platform (3 hours). Linux or Android? Being more open than other operating systems, it’s a little easier to get a stack going and piggyback off code, kernels and drivers that are out there.

5) Buy it (1-3 days). First I usually buy the mainboard (like a BeagleBoard or Pandaboard), along with any complementary modules I’ll need for that platform. It’s worth doing a little planning ahead to buy some spare cables, too, since there’s nothing more frustrating than sitting around with hardware, and not having that USB or HDMI micro cable to test things out.

6) Build it (5 days). Hardware “assembly” should be fairly straightforward, with clear, standardized pinouts (as attested to by the Arduino pin-spacing hullabahoo of late 2009). I find that USB is pretty versatile and ideal for easy connectivity, but that’s the subject of a different post.

If all goes well, assembling the hardware should be a 1-2 hour activity – max! Getting the OS running the way you want it to shouldn’t take too long, but it depends on how customized your kernel has to be.

Then it’s time to develop the app. Bringing out data over serial is a favorite activity (Android Ambrosia tutorial here), as is building a GUI. Adobe AIR is also excellent for simulating application mockups for a presentation.

7) Tell the world (4 hours). Ready for the big screen? Like Step 1, this final step comes naturally to most entrepreneurs – between blogging, emailing well-connected folks, posting to Twitter and Facebook, the evangelizing is usually everyone’s favorite part.

Building a complex prototype has never been easier or more accessible. What’s your experience with modular development? Post thoughts and questions to comments, or just email me at justin dot huynh at liquidware dot com

3 Useful Things to Know about the BeagleJuice, 2nd Gen

I got a few very good questions about the BeagleJuice, 2nd Gen from earlier this week, so I thought I’d answer them in post form.

What are the specs on the I2C pins on the BeagleJuice?

The I2C pins (GND, Vext, SDA, and SCL) are exposed for custom headers or wiring. After bugging Chris several times, he decided to just draw me a schematic instead. The range of operation is 1.8V to 3.3V. Currently, there are drivers coded for Android/Linux and OMAP, but it could be hacked to anything that talks I2C.

What else can I power with the BeagleJuice?

The BeagleJuice comes standard with the 2.1mm barrel plug, which works just fine with the 5V barrel jacks on the Arduino, BeagleBoard C5 and xM, PandaBoard, as well as the BeagleBone.

That said, it is in fact just a 2-pin molex connector at the end, so Matt spliced up his own USB micro cable, put some heat-shrink on the tip, and voila! The BeagleJuice now charges anything that takes 5V – my phone, or even the Raspberry Pi (when mine finally arrives!).

What’s with the strips of LEDs?

Aside from the fact that LEDs are always fun, they actually serve a purpose.

The ones on the left are battery charge status indicators, which were inspired by Chris’ Macbook Pro battery meter. (Sorry the picture is a little blurry – I tried to catch it as the lights were moving up!)

There are a couple more “easter eggs” on the BeagleJuice, 2nd Gen – mostly holdovers from things Chris, Mike and I were working on here at the lab. Post your thoughts or guesses to the comments, or just send me a note – justin dot huynh at liquidware dot com

Introducing the BeagleJuice, 2nd Generation: Laptop-Grade Power Management for the BeagleBoard

Last week, I took a trip through some of the battery boards and power management systems we created for the Arduino, BeagleBoard and Amber. The development of the 2nd generation BeagleJuice was inspired mostly by requests for a “standalone Amber backpack”.

Sort of…I took a little artistic license with the picture above! The Liquidware Amber power supply and BeagleJuice, 2nd Gen were both built with advanced power management principles in mind.

(Edit: I got a few questions about this - the BeagleJuice, 2nd Gen comes with the standard 5V barrel jack cable to charge any 5V device that fits the jack, like the BeagleBone or PandaBoard. For the adventurous, it's not a huge stretch to wire your own cable to the 2-pin Molex connector...)

The 2nd Generation BeagleJuice is a modern, laptop-grade power supply that implements smart charging technology to manage multiple cells in series to deliver higher charge capacity, as well as high-power output. It’s optimized for 2-cell, 3-cell, and 6-cell configurations to deliver 2800, 4200, or 8400 mAh of capacity.

Onboard LEDs provide multiple status readouts as well as charge information. Advanced features can be accessed over I2C pins directly, or via a Zero Insertion Force (ZIF) ribbon connector. Here at the lab, I’ve used the 2nd Gen BeagleJuice as a primary power supply for several BeagleBoard units concurrently – which centralizes the power management system for remote installation clusters. The high-capacity BeagleJuice provides quad 5V outputs via discrete 2-pin Molex connectors.

I’ll cover some details on charging cycles in the next blog, but in addition to smart charging and power input management, the heavy-duty power supplies that the BeagleJuice is modeled after also focus on being fault tolerant and providing an added measure of battery preservation. This “safety” logic protects the battery from:

• over current charge/discharge
• over temperature charge/discharge
• over voltage charge/discharge
• cell charge/discharge imbalances

While no system is perfect, taking these issues into consideration is a big step closer to advanced power management and portable power supplies, useful for hobbyist and embedded prototyping projects with the BeagleBoard alike. Since the BeagleJuice, 2nd Gen comes with 2 5V barrel jacks connectors, it can actually power the PandaBoard and Arduino, as well as my phone with a custom-spliced USB connector. Here’s a quick shot of the new BeagleJuice in action:
This is Part 2 of 3 on portable power management for prototyping embedded systems. The next post will walk through some of the charging algorithms and explain some of the complexity around charge management ICs - justin dot huynh at liquidware dot com

3 Portable Power Management Systems For Development and Prototyping

This post came about when we  asked Keith about the difference between the battery setups we had, and whether it was possible to pull the Amber battery pack off, and use it for other things. [Cue flashback music…]
Lithium Backpack for Arduino
About 4 years ago, we started with the basics of power management: the Lithium Backpack. For that, it was mostly around form factor and simplicity, which was great since the Arduino has both analog and digital capabilities. If it let me take my Arduino project around, I was happy. A single-cell system, it had 4 pins - +5V, +3v3, GND, and Status. Really, the only two that mattered was my positive and my ground. Simple.

BeagleJuice for BeagleBoard
So when we started working with the BeagleBoard, we started with the same concept: a “shield” type battery for the BeagleBoard platform. Just a little more heavy-duty, since the BeagleBoard is an embedded computer in its own right, and much like my smartphone, will run out of juice pretty quickly.

Nevertheless, the BeagleJuice idea was simple – single-cell battery, charging, mounting standoffs, USB-mini trickle charge capability, and an on-off switch. That was 2 years ago.
Laptop Power Management and the Liquidware Amber
In the meantime, a few projects came along where we really had to wrap our heads around portable power supplies, power management for mobile devices, and the like. Thinking about products with lifecycles of 5 years or more also means that we had to consider things like battery longevity and smart charging cycles.
This was a whole new ball game for us, so we started by taking a look at how consumer laptop batteries are put together. Chris’ old Sony laptop became the sacrificial lamb:


No big surprise – a PCB controller was attached to 6 rechargeable Lithium-ion battery cells. The real fun was in understanding the power management ICs on board, how they communicated with the computer, and what other information was being provided, since the battery pack had quite a few more pins than our original lithium backpack did!
One of the big takeaways was that we needed to use some more complex power management units in order to provide the complex battery systems people were used to using with laptops and robust embedded systems. So for the Liquidware Amber, we incorporated laptop power management circuitry, which enabled multiple cells in series to provide higher charge capacity as well as high-power output (the Liquidware Amber battery pack delivers 5V at up to 4A for an extended period of time). What does this mean for functionality? A lot of charge and discharge management algorithms that go on behind the scenes, but also the ability to read out current, temperature, and voltage status to the display – something we take for granted on most modern devices, but actually involves quite a bit more complexity than strapping some rechargeable batteries to a board!
This is the first post in a three-part series on portable power management. In the next one, I’ll discuss the specific features and algorithms we considered in building a laptop power management system, and answer Keith’s original question about a standalone Amber battery. Questions, thoughts or projects – email me directly: justin dot huynh at liquidware dot com.

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.

5 Reasons to Customize an iPad (or Samsung Galaxy, or any off-the-shelf Android tablet)

Since the Liquidware Amber officially launched back in May, I’ve gotten a few more questions about tablets, that usually go along the lines of:

“I’m building a special application for [my company]…can I just use an iPad/Galaxy/off-the-shelf tablet? Or should I use the Amber?”

As much as I could be self-serving in answering that question (mwahahaha!), the real answer is that it depends. The more targeted question to ask is:

“If I just build an Android or iOS app, without hardware accessories, does it get the job done?”

There’s a bit of a gray area, and a lot of instances where you really could go one way or the other. But my take boils down to the fact that, if you can avoid building custom hardware, I’d recommend that. But if there’s no way around it, it’s usually worth putting in some effort to make the path as quick and painless as possible.

Embedded development can typically be broken down into three levels:

Application Level. The front-end. Anything that can be downloaded on Apple’s App Store, or Google Play. This is anything that the end-user will interact with, and also constitutes permissions and access to resources within the OS and hardware.

Operating System Level. This involves kernels and ROMs that provide access to functionality on a piece of hardware. With Android on consumer devices, this usually includes rooting the device, then adding functionality or removing OEM restrictions on the hardware.

Hardware Level. On one end of the spectrum, this entails something as “simple” as an accessory device, like Square’s credit card reader:

That said, not all accessories are made equal, and when added functionality, higher bandwidth, and larger amounts of data are required, the accessories become increasingly complex. (A common theme is the analog-sensor-to-Android-device project, which gets the Arduino and Amber/Android involved…subject of an upcoming blog post!) The more complex the accessory, the more likely it is to require OS level tweaks as well.

When to use an off-the-shelf tablet:

When it comes to custom applications, I typically recommend Android because of the simplicity in pushing down your own custom .apk file. The off-the-shelf tablet is ideal when…

1) Stock permissions are adequate. If the front-end app can be built without running into OS-level obstacles, that’s a great first sign that maybe going with a portable app that can be run on any consumer device is the way to go.

2) Low-complexity hardware accessories. Similarly, if power and data transfer to the device is simple, it may be easiest to use an existing interface – in most cases, Apple’s 30-pin (soon to be 19-pin?) docking connector, or the micro USB OTG on Android devices. As soon as higher data rates are needed, level shifters come into play and you want to start transmitting across SPI, I2C, and have a million uses for various GPIO…it’s not a bad idea to think about a custom device.

3) Low volume/high speed deployment. If an extremely quick turn is required (say, a weekend-ish) for a prototype solution, and the deployment is pretty limited, supply chain and manufacturing concerns are just going to get in the way. Get an unlocked device and make modifications. There’s no time to burn sifting through custom specifications on potential hardware options. A device in the field is worth a hundred on paper, even if it’s not quite perfect. (One of my personal heroes, Guy Kawasaki, is big on this.)

4) Minor OS Tweaking. In many cases, it’ll be necessary to root a device, and flash a custom Android ROM or kernel. For a few units, it’s not too big a deal, especially if you have some strong Android coders to navigate the low level, or maybe some skilled developers have already taken care of the heavy lifting. Even better if you can get the devices “pre-rooted” or loaded with your custom version of Android.

5) Low-cost Networking/Battery. This weighs in quite heavily for mobile applications that meet all of the above. Aside from the CPU and display, WiFi/Bluetooth/3G/4G and good power management systems drive significant cost in any embedded device, especially in a compact package. Customizing an off-the-shelf device for these purposes takes advantage of the economies of scale of consumer products, and in some cases, subsidies from from cellular providers.

Bonus: Branding. This one has typically been a dealbreaker for many companies based on preference. Sometimes it doesn’t matter if the user knows that this is an off the shelf device, or that it’s running an OS behind the app, but this factor alone has driven teams to search for a fully customizable device.

Stay tuned for Part II on when a custom Android tablet might just fit the bill. In the meantime, if you’re not sure about your project, or want to share your experience, feel free to comment below or email me: 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: