It’s been a week since Justin, Mike Rith and I drove down to New York for Maker Faire. Mike and Justin had both tried to explain the nature of the beast that is Maker Faire, but it was clearly something that I had to experience for myself. Note to self: driving to New York City and getting there just as Friday night rush-hour traffic is beginning is a special breed of torture I wouldn't wish upon anyone.
My first glimpse of the New York Hall of Science where Maker Faire was held, was one filled with the bright blue, red and white Maker Faire signs, lines of excited Makers and visitors alike. On my way in, I chatted with a Maker about her most recent knitting project--a 7 foot by 3 foot shawl for her daughter's upcoming wedding that was going to be held practically right next door! We brought down a variety of demos including a TouchShield Slide with the Paint Program installed, an Android DIY Starter Kit, a Dual-core Android 4 Dev Kit, and a couple of Ambers. Miguel from Long Island dropped by and brought an impressive project where he created a Mancala app using a TouchShield Slide, Lithium Backpack and an Arduino.
After a quick set up, I found myself ready for action. By 10:15, The Arduino Pavilion was teeming with people. It was great to get a chance to interact with such a wide range of people--from those who'd never heard of Arduinos to 11-year olds grilling me on the merits and processing capabilities of one microcontroller over the other. Finding a way to communicate the same concepts to a range of people with different levels understanding was both challenging and rewarding.
Mike chatted with Will from tested.com about the Amber
I had a lot of interesting, thought-provoking conversations with people from all over. I got the chance to speak with a few of developers from Germany, a couple from Washington looking to deaf-proof their house with Arduinos and TouchShields, and a whole host of people with a wide variety of interests.
It was also great to see so many kids at our booth asking questions about our products, and technology in general. For the most part, they interacted with it fearlessly--with a comfort and familiarity that makes me excited for future technological innovations.
Rith, Mike and Justin had things under control, so I snapped a couple of pictures, and snuck away to check out some neat projects
Katy Perry, The Unicorn was the first project I saw as we came in to setup, so I had to go back and get a quick shot of it. Missed out on the glitter sneezes though!
I imagine this project looked really cool by the end of the day on Sunday.
After about 17 hours of non-stop Maker Faire activity, I was ready to pack it up, and head back to Boston. I tip my hat to the Maker Faire crew for such a well-organized and special event. While my feet are still recovering, I can't wait for May 2013 to get a chance to get to do it all over again in California!
Call me strange, but I’m a big fan of planning and logistics, so I’m pumped
that everything is set for our trip to Maker Faire
NY next week!
We’re only 8 days, 20 hours, 35 minutes and 12, no 8 seconds away from Maker
Faire New York 2012. This will be my first Maker Faire, so I’m really excited to
head down and see what projects people have been working on. I’ve read through
the list of
Makers and can’t wait to sneak away to check out their projects.
I’m heading down with Mike, Justin and Rith, who have all been to several
Maker Faires in the past and had great times. We’ll be bringing down our
Digital
Rooster project and a couple of other gadgets for people to check out, so
come find us in the Arduino Pavilion!
Last week, I wrote a tutorial about how to get a 3G/4G cellular modem working on my Android/BeagleBoard setup. The next question (after everything works) is, how can I get this running automatically every time I boot up my Android device?
Boot scripts are nothing too fancy, and anyone with some basic Linux or Android experience can navigate this process pretty easily. But I always find it helpful to have the actual scripts written out. As a beginner, it’s a great way to figure out what the commands actually mean, and as an advanced developer, it’s a huge timesaver to copy and paste what’s already been done.
As a quick recap, I'm running all of this off my BeagleBoard xM, BeagleTouch, and Android Ambrosia SD card/image. I decided to use a T-Mobile 4G Rocket 3.0 USB cellular modem, but any USB cellular modem should work, with some tweaks to the vendor/product ID as well as the chat script (more on that in the previous post).
Outline the process
Looking through the original 3G/4G cellular modem integration process, I needed to do 4 things:
2) Execute usb_modeswitch using the correct usb_modeswitch.conf config file
3) Once modeswitch was successful, install usbserial.ko module to the correct vendor and product ID for the device
4) Execute chat script using pppd command Wrap up relevant components into a script
I created a file called init_cellular_pppd.sh, which contains the relevant content and commands to create the usb_modeswitch.conf file as well as the dialtest.chat script. #!/system/bin/sh #This is a wrapper script to enable cellular wireless TAG="Cellular" # # echo usb modeswitch config # echo_modeswitch_conf_zte() { echo "$TAG building modeswitch config" cat > /system/etc/usb_modeswitch.conf << EOF
You’ll find init.rc in the root folder on your Android device.
I placed the init_cellular_pppd.sh script in /system/etc/ppp, though it could technically go anywhere – as long as it’s being called in the right location, and the files it generates are going to the right places as well.
Then I just added these two lines to Android’s init.rc bootup script: service cellular_up /system/bin/logwrapper /system/xbin/busybox sh -c /system/etc/ppp/init_cellular_pppd.sh oneshot
This ensures that I execute init_cellular_pppd.sh every time I boot, which in turn generates the files I need and executes the commands required to have a fully functional 3G/4G cellular connection every time I boot up my Android device, provided I have the modem plugged in. In my last blog post, I cover which parameters you’ll want to tweak if you’re using a different modem or cellular provider, but if you have any questions or suggestions, I’d love to hear it. Email me at justin@liquidware.com or follow me on twitter @liquidware
A lot of folks have been asking me about this one, so I figured it’s about time to pull together my notes on the tutorial and get started…
In this case, I used an Android Ultimate Pro Kit, which runs Android 2.3.4 on the BeagleBoard xM/BeagleTouch/BeagleJuice, 2nd Gen. Note: There’s a much sleeker (beta) way to get cell modems running in Android with the new PPP widget from Draisberghof. I haven’t tried it out yet, and hooking up modems the old-fashioned way helped me learn a few useful tips and tricks in navigating ADB, so I’m writing it all out here. Enjoy! Hardware I used
1 BeagleBoard xM
1 BeagleTouch
1 BeagleJuice, 2nd Gen (optional – a 5V power supply works fine too)
1 Android Ambrosia SD card
1 Linux or Mac computer (cygwin for Windows could also do the job, with a little bit of toolchain setup. I used a dedicated Ubuntu EeePC)
1 T-mobile Rocket 3.0 4G laptop stick (but most will work – see below)
1 Type B-mini USB cable for connecting the computer to Amber Software I used Android SDK with Android Debug Bridge
Linux terminal (Asus Eee PC is *perfect* for this) This tutorial assumes that you already have Android SDK with Android Debug Bridge set up, and that you’re communicating to the BeagleBoard/Android device from a Terminal program. Connecting your Android device
1. Switch on your BeagleJuice, 2nd Gen to power on the Android Ultimate Pro Kit.
2. Once the BeagleBoard is booted into Android, plug in a USB cable from the Linux terminal to the BeagleBoard’s OTG type B-mini port.
3. Open up Terminal in Linux.
4. I have the Android SDK and Android Platform Tools installed, so I can access Android Debug Bridge right from the prompt. The first thing I do is make sure my device is connected by typing: adb devices
A list of connected and available Android devices should come up. Tools you’ll need on the Android device
Most USB 3G/4G cellular modems are actually several “devices” rolled into one – the most notable being some form of onboard data storage.
USB_ModeSwitch is a fantastic utility that essentially does the heavy lifting of separating all these devices, so we can talk to the modem over USB serial directly.
From your working directory, push the usb_modeswitch application to /system/xbin/ on your Android device: adb push usb_modeswitch-1.1.9-arm-static /system/xbin/usb_modeswitch
6. Download the usbserial.ko kernel module from the Liquidware site. The reason I have it set up as a separate module is so that we can install usbserial as the driver for our modem, which is necessary to communicate. Then push usbserial.ko to your Android device: adb push usbserial.ko usbserial.ko
This will put the usbserial.ko file in the root folder on your Android device, which is fine for our purposes.
We’ll create the usb_modeswitch config file you’ll need later. Find your modem identification information
7. Go into Android shell: adb shell
Now you can issue commands as if you’re in a terminal application on the Android device.
8. To see details about attached USB devices, first mount the usbfs file system. mount -t usbfs usbfs /proc/bus/usb
Now type in: cat /proc/bus/usb/devices
You should see a list of devices appear. Each USB device will have a Vendor ID and a Product ID. This detailed information also clues you in by telling you what Driver the USB device is currently using.
The one I’m looking for is the T-Mobile Rocket 4G, made by ZTE. Three relevant pieces of information:
Vendor=19d2
ProdID=2000
Driver=usb-storage
Each device has a vendor and product code identifier. The Driver is “usb-storage”, meaning that the composite modem is recognized as a USB mass storage device. Not very useful for our purposes. That’s where USB ModeSwitch comes in. You’ll tell USB ModeSwitch to send a special string of characters, which then splits the composite device into 6 independently communicating USB serial devices – one of which is our modem.
Write down your Vendor and Product ID, as well as your Manufacturer, Product, and SerialNumber info. These will all be helpful in finding the correct string that you’ll need to send to the modem via ModeSwitch.
7. In order for USB ModeSwitch to run properly, you’ll need to create USB modeswitch config file in the right format that has the correct string of characters. I started by looking on Draisberghof’s extensive list of device references. For the T-Mobile Rocket 4G 3.0 by ZTE, copy the following text into gedit on your Linux terminal, and create a file called usb_modeswitch.conf ######################################################## # ZTE devices DefaultVendor= 0x19d2 DefaultProduct= 0x2000 TargetVendor= 0x19d2 TargetProductList="0001,0002,0015,0016,0017,0031,0037,0052,0055,0063,0064,0066,0091,0108,0117,0128,0157,2002,2003" MessageContent="5553424312345678000000000000061e000000000000000000000000000000" MessageContent2="5553424312345679000000000000061b000000020000000000000000000000" MessageContent3="55534243123456702000000080000c85010101180101010101000000000000" NeedResponse=1 CheckSuccess=20
8. Push usb_modeswitch.conf down to your Android device. adb push usb_modeswitch.conf /system/xbin/usb_modeswitch.conf
9. There is one additional file you’ll need, which is known as a chat script. It secures the connection with T-Mobile. Open up gedit again and copy the following text, creating a file called dialtest.chat: TIMEOUT 10 ABORT 'BUSY' ABORT 'NO ANSWER' ABORT 'ERROR' SAY 'Starting GPRS connect script\n' ""'ATZ' SAY 'Setting APN\n' OK 'AT+CGDCONT=1,"IP","wap.voicestream.com"' ABORT 'NO CARRIER' SAY 'Dialing...\n' OK 'ATD*99***1#' CONNECT
10. Push the file down to your Android device: adb push dialtest.chat dialtest.chat
This will put dialtest.chat into your root directory. Turn on your 3G/4G cellular modem for Android
Now that all the right files are in the right places, we can execute all the commands at once.
11. Plug in your 3G/4G USB cellular modem. It should start blinking
12. Go into shell on your Android device: adb shell
13. At the Android shell prompt, enter the following: /system/xbin/usb_modeswitch -I -W -c usb_modeswitch.conf
The output will tell me whether the operation was successful, and if it was, you’ll see something like the above screenshot.
14. Notice that the “matching” vendor/product ID is 19d2:0157. We can now install the usbserial kernel directly to that device. Make sure you are in the root directory, since that’s where we put the kernel file. The vendor ID and product ID need to be written in hex. insmod usbserial.ko vendor=0x19d2 product=0x0157
15. Now check to see what devices are attached to USB at this point: cat /proc/bus/usb/devices
You should see something like the following:
Compare this to the original screenshot, where usb-storage was the only device and driver under this product.
If you’d like, you can check this under the list of serial devices by typing: ls /dev/tty*
If you see ttyUSB0-5, you’re good to go!
16. This part usually takes a little experimenting to figure out which USB device you want to call with the pppd command. This is the correct one. It will execute the dialtest.chat script that you put on the device earlier. (If you’re looking closely, I put my dialtest.chat script in a different folder, but that’s not really a big issue as long as you have the right path) pppd /dev/ttyUSB1 persist defaultroute usepeerdns -detach crtscts noauth debug connect "/system/xbin/chat -v -s -f dialtest.chat"
Be sure to leave this terminal window open to maintain the connection.
The above screen shot shows what happens on a successful initiation of the chat script. You are now ready to go online. ifconfig tells me what my network connections are. Note that ppp0 has an IP address, which means we’re connected to T-Mobile. ifconfig
And the beautiful turquoise beacon, and CNN.com confirms that I’m online!
I’m sure there are going to be questions – email me at justin@liquidware.com or find me on twitter @liquidware. Or just comment below, and I’ll get back to you immediately. Next up after the Labor Day Weekend, I’ll explain how to roll this all up into a boot script, so it can run instantly, every time you power on the Android device. A big thanks to freedune for an excellent and well-written blog post, which steered me through most of this effort!
With dual-core processors and Android 4 (Ice Cream Sandwich, at least) a mainstay of smartphones and tablets, some folks suggested it was about time for the Beagle Embedded Starter Kit and Android Hardware Development Kit to get a big brother…
After quite a few months of requests, Chris and I got Android 4 running on the PandaBoard, along with an HDMI adapter board and some drivers to get the PandaBoard a “DIY tablet kit” of its own.
Just as the name suggests, the Dual-core Android 4 Dev Kit consists of the dual-core OMAP 4430 PandaBoard, Android 4 ICS (with Android serial support), 4.3” touchscreen enabled, powered by a laptop-grade battery pack, so it can be remote mounted, portable, or just permanently charging with a backup power supply.
The popular 4.3” BeagleTouch OLED display now works with the PandaBoard’s OMAP4430 with the help of a carrier board that conveniently brings the BeagleTouch pinouts to an HDMI connector.
The other side of the PandaBoard sandwich is the BeagleJuice, 2nd Generation, providing smart, laptop-grade battery and power management capabilities to the PandaBoard’s 5V input jack.
I don’t think that a few extra wires ever frightened any readers of this blog (if anything, there probably aren’t enough random wires on these boards!), but it’s fresh off the lab, so some of these extra wires are going to be solidified as the boards ship.
Either way, I’m pretty pumped about having a portable display + battery setup that works with the PandaBoard, but also one that runs Android 4 (ICS) and takes full advantage of Texas Instrument’s dual-core OMAP4430 processor.
One of the reasons I decided to make the panel remote mount capable (connected by wires rather than headers) is that the PandaBoard has a bigger footprint than the BeagleBoard, and a remote mount would allow the board and battery to be stored or mounted separately, much like most thin clients.
Here’s a quick demo I just put together:
I think this would make a cool, totally overkill, touchscreen thermostat that I could shove in my wall, not unlike the Nest (who knew thermostats could be so sexy?), but until next time, post questions, comments and project ideas to comments, justin@liquidware.com, or tweet me @liquidware …
Thanks again @bbenchoff for the post about the DIY perpetually-powered wireless outpost on @hackaday! A lot of good discussion on natural/perpetual power sources :) I got an email from Dan earlier this week about making a fish tracking aquarium. Being that we’re right in the middle of Shark Week, I respectfully obliged…
This may or may not have implications for real-life shark tracking, but I’ll take an excuse to have my shark tweet me when he (or she, I’m no marine biologist) breaches the perimeter over to the sunny side of the tank.
Of course, I’m doing this with my toy shark-on-a-stick and only a laser level and a light sensor, but it’s possible to make this much more accurate and granular just by adding more strategically placed sensors/light sources into the mix.
Disclaimer: This project was designed purely with fun and proof-of-concept in mind, and in no way is designed to replace the $100 million airport intrusion detection system at JFK. The jet ski was too big and too fast for my 10 gallon fishtank…
I couldn’t find a picture of Tom Cruise doing this because the lasers in Mission Impossible weren’t visible…
Concept
Most laser security systems rely on infrared sensors that detect changes in heat, based on a beam of light hitting the sensor. If that beam is interrupted, it’s interpreted as a change in the thermal profile on the sensor, and an alarm goes off. Usually the beams are invisible too, so that picture above is mildly inaccurate. Here’s the basic idea of how the project went:
I took a little field trip to Petco and Toys R Us to get a fish tank simulation setup. For the laser pointer, a laser light level I had in the shop worked really nicely, but any standard laser pointer will do.
Building the light sensor/laser setup
I ended up using a real, visible laser for two reasons: first, it’s easy to line up against my light sensor, and second, because I’m shooting the beam through water and 2 glass panels (on either side of my tank), which might otherwise diffuse the beam’s heat profile. Dry museums have it so easy…
On the other side of the tank, I have an Arduino with a light sensor elegantly taped to the glass.
I cut a hole in the wallpaper – on the left side, the laser is hitting the sensor directly. On the right, I moved the laser away, so you can see it the light sensor more clearly.
Chris and I just have some basic code running on the Arduino to get analog readings out from the AMBI light sensor. (The dead simple up-and-running post from way back when, as well as the wiki here). I uploaded the code to the Arduino, checked the output from serial, it seems like I’m good to go!
Connecting the sensor setup to a web-connected Android/BeagleBoard system
I connected the Arduino + Light Sensor to the BeagleBoard/BeagleTouch/Android stack sitting in my freshly dug up Mystery Box.
For a recap on how to connect the Arduino and sensor outputs over serial to output to the BeagleBoard over Android, here’s a link to the Antipasto wiki post. (This can still be tricky even with the Android Ambrosia SD card, so email me justin@liquidware.com, or comment below if you get stuck.)
Once I was able to get readings from the light sensor/Arduino in Android, I wrote a quick little Android APK to do two things:
1) Flash a Red Alert on BeagleTouch screen
2) Trigger a tweet to be sent
Why Twitter? It’s excellent for posting event alerts in an easy to subscribe fashion, and it’s also really easy to have these alerts forwarded to SMS, email, and Facebook. And they have a pretty excellent API, which I’ll get to in the next section.
If nothing is obstructing the the light sensor, the laser drives a light value of about 700-800.
As soon as the laser is obstructed by Bruce the shark himself, that light value drops. Once it’s below 400, the Android program issues a Red Alert warning that the sensor has been tripped, and sends a tweet.
This serial app, which Chris originally wrote for the Liquidware Amber, simply takes the values being sent from the Arduino/light sensor, then funnels it through the following logic:
A ratchet digital filter that detects when the sensor has been obstructed (and resets)
if ( (sensorVal < NIGHT_TRIP_POINT) && (ratchetCounter > ratchetMin))
ratchetCounter--;
if (ratchetCounter == ratchetMin)
time = NIGHT;
if ((sensorVal > DAY_TRIP_POINT) && (ratchetCounter < ratchetMax))
ratchetCounter++;
if (ratchetCounter == ratchetMax)
time = DAY;
Then here are a few of Bruce’s tweet alerts, stored in a String array:
String [] mTweets = {
"Yum.",
"Fish are friends, not food!",
"I am a nice shark, not a mindless eating machine.",
"Anchor! Chum!",
"So, what's a couple of bites like you doing out so late?"
};
Finally, bringing these two pieces together…
if ((time == NIGHT) && (prevTime == DAY)) {
mAlertDlg.setVisibility(View.V
ISIBLE);
mTweetIndex++;
if (mTweetIndex >= mTweets.length)
mTweetIndex = 0;
Tweet tweet = new Tweet(mContext,
mTweets[mTweetIndex]);
}
I posted the full source code to the Android serial reading application on Github, if you’re interested. Big thanks to the folks who developed the twitter4j Android library!
Twitter Alerts from Bruce the Shark
Two of the world’s most famous sharks have been named Bruce (see hints below):
So I figured @BruceSharkAlert would be a fitting Twitter handle. In order to make Tweets actually happen, the code above needs to be linked to an authenticated Twitter developer account. Logging in as BruceSharkAlert on dev.twitter.com, this is what I’ve got:
I created this application…
Filled out the forms and got authentication keys…
(which I neatly chopped out :) They’re required in my Tweet.java file, which requires an authenticated account to automate tweet posts:
* The user had previously given our app permission to use Twitter
* Therefore we retrieve these credentials and fill out the Twitter4j helper
*/
privatevoid loginAuthorisedUser() {
String token = PREF_ACCESS_TOKEN;
String secret = PREF_ACCESS_TOKEN_SECRET;
// Create the twitter access token from the credentials we got previously
AccessToken at = new AccessToken(token, secret);
mTwitter.setOAuthAccessToken(at);
Log.d(TAG, "Welcome back user.");
}
/**
* Send a tweet on your timeline, with a //Toast msg for success or failure
*/
privatevoid tweetMessage(String message) {
try {
mTwitter.updateStatus(message);
Log.d(TAG, "Tweet successful!");
} catch (TwitterException e) {
e.printStackTrace();
}
}
}
Now Bruce is tweeting one of the above pre-programmed lines (borrowed from Finding Nemo)
Phone Perimeter Breach Alerts
From there, I just followed @BruceSharkAlert, and since I have Twitter via SMS already set up, all I had to do was text 40404 (my Twitter “short code”) the command ON BruceSharkAlert. Now Bruce’s Tweets show up on my phone every time he breaks the laser line:
Mike gives us a little video walkthrough here:
When my phone goes off, I like to tell people that my shark tweeted me. Anyway, that’s my tribute to Shark Week, but if I had more time, laser pointers, and light sensors, I’d probably set up a crazy grid defense system. Till next time…
What else could I use this for? Let me know in the comments, over email at justin@liquidware.com or tweet me @liquidware
At first, the customized Android Tablet, 2 deep cycle marine batteries, the Arduino, the light sensor, the temperature/ humidity sensor, the solar panels and Pelican case seemed like overkill, but once I explained our reasons for the project, a lot of makers started having their own ideas on what they'd do with something like this.
.JPG)
I couldn’t find a picture of Tom Cruise doing this 
.JPG)
