Happy Holidays from phy5ics!

After having built the hardware in Part 1, it is fairly useless without a way to get the GPS data from the device somewhere else in order to do something useful with it.  For this project, the end result will be a visualization of the GPS data in Flash Player on a Mac.  There are myriad ways to accomplish this, however very few approaches can easily encapsulate all of these steps in a single language.  This is because both low-level system access (to read the serial data) and some sort of server (to serve the data to Flash Player) are required.  While it is definitely possible to use any number of other languages such as Java, Processing, C++, etc., performing all of these tasks with those languages would require significant amounts of code.

With that said, I opted for Python not only because I love it, but also because it is quite straightforward to use it to read from a serial port using the pyserial module and also to establish any number of different types of servers including standard HTTP and socket servers.  While there are built-in libraries for creating and managing servers, I ultimately decided on creating a socket server using Twisted.  Twisted is an enormously powerful networking framework that simplifies the creation of all sorts of servers.

Why add another framework when a standard HTTP server would suffice for serving up data to the Flash Player?  The implementation of a standard HTTP server would require Flash Player polling the service to determine if data had been updated.  So, rather than rely on that sub-par solution, Twisted makes the creation of socket servers very easy, which then allows the Flash Player to receive data in real-time via an XMLSocket connection.  Not only that, but one of the coolest aspects of Twisted is that it makes it fairly easy to write multi-user socket servers, which will be a nice addition for future enhancements

Here is what the overall system architecture ends up looking like when all of that is considered:

However, before diving into these details, the first step is to hook up the device to the Mac via a serial Bluetooth connection and verifying that everything is working so far.

Bluetooth Pairing
Obviously, the first step is to power up the board.  After that, pairing the BlueSMiRF with the Mac.  This is a very straightforward process.  From the Bluetooth preference pane in System Preferences, click the “+” icon to add a new Bluetooth device.  Advance through the dialog boxes, configuring the device that shows up as SparkFun-BT.  The passkey for BlueSMiRF module is default, so type that in when prompted.

Once that’s been done, by checking the serial interfaces in /dev, it can be verified that it is now active as a serial device.  That is done by opening a terminal window and typing ls /dev/tty.*.  That will list out all available serial interfaces.  The BlueSMiRF should show up as something like tty.SparkFun-BT-COM0-1.

Screen
Screen is a Unix application that allows one to attach a terminal session to a particular process.  To view the serial communication that is happening on the serial port that the BlueSMiRF is attached to, this is a good option.  This can be done by typing the following command into the terminal to view the serial communication on that port in realtime:

screen /dev/tty.SparkFun-BT-COM0-1 9600

Note that the 9600 at the end of that command is the baud rate.  That command should yield some cryptic messages being printed in Terminal like the following if everything else is wired up properly:

To exit screen, hit control-a, then control-\.

The strings that are seen here are NMEA strings, which are derived from a specification that standardizes the way that marine electronics communicate with each other.  For additional information on this, check out http://www.gpsinformation.org/dale/nmea.htm.  If the GPS has a location fix, then numerous lines beginning with $GPGGA will be displayed, which precedes messages that contain the location fix data.  Otherwise, there will be mostly $GPGSV, which represents data regarding the GPS satellites themselves.

OK, Now What?

Now that there is data coming in over a virtual serial port, the next step is writing the software.  The next article in this series will examine the Twisted socket server and Flash XMLSocket connection along with providing the source code for those systems.

Allow me to respond to those who took the time to comment on my little project:

To Tam, David and Snoopy:
No, I didn’t actually short out the entire board by connecting VCC+ and GND.  That is a mistake in my first attempt to draw out a schematic in Illustrator.  So to those that are copying this project word-for-word - please don’t follow the diagram exactly.  I’ll update it in the next couple of days when I have a chance.  As an aside, I’d be curious to hear from others about what they use for drawing circuit diagrams.  I just use Illustrator because that’s what I know from my days long past as a designer.

To Siftah and Arto:
What I’ve done is most definitely available as a commercial product and most likely for less than I invested in the various components.  However, I just happen to be a nerd and am quite interested in learning from products and devices that may exist for an equal or greater price.

Because I cobbled my project together from off-the-shelf components, I can continually break down and re-combine any of the components I utilized into more-and-more interesting and complicated projects.  With a consumer product, I would be beholden to whatever the particular manufacturer of that consumer product dictated the functionality of a given device to be.

Additionally, while I’m not entirely familiar with what is on the market with regards to Bluetooth GPS devices, it’s much cooler, in my opinion, to be able to do whatever I want with the IMEA codes that I ingest and store from a piece of hardware via my own drivers and software as compared with what a GPS hardware/software vendor happens to expose via a crippled API in response to what their marketing team thinks that I might be interested in doing with said data that I collected via blood, sweat and tears on the trail.  Isn’t that why we all read and love Make?

Birds have dominated the sky since the day that they evolved to become flying creatures.  However, since man has gazed upon them, we have looked to them for  inspiration and in envy, often (unsuccessfully) invoking their form in an attempt to share the currents and soar above.  So, while I could theoretically transmute into a bird (or purchase one) to create an exact replica of something that already exists, by creating a reasonable facsimile I can learn how exactly it works, improve upon it and have fun doing it.

After experimenting with some different methods, some using microprocessors and some not, I opted for the simpler route, eliminating the microprocessor. A microprocessor doesn’t add anything other than cost for the basic purpose of this project. Although stay tuned for another posting about integrating a similar configuration with the Make Controller and Arduino microprocessors.

Parts List

• 5V regulated power supply
• BlueSMiRF Bluetooth Module
• EM406A GPS Module
• Extra 6-pin interface cable
• 9V battery holder
• Headers
• Breadboard
• Solid 22-gauge wire
• Soldering iron

5v Power Supply
Select a 5V power supply to use. In this case, I’m using a switchable 3.3V/5V power supply kit that I picked up from SparkFun. I made a slight modification to it and soldered a 9V battery adaptor to it to make it a bit more flexible and truly wireless rather than using the standard 9V DC wall adaptor. This is just my preference for prototyping. When I get down to a final design, I generally switch it up in favor of a simple voltage regulator to save space and weight.

BlueSMiRF Embedded Bluetooth Serial RF Link
The BlueSMiRF module is sweet little device, providing an easy way to link any project using a serial interface to a computer (or another BlueSMiRF module). Simply connect the TX, RX to another serial device along with vcc (4.5V-5.5V) and ground and it is ready to pair.

EM406A GPS Board
This small board uses the SiRF Star III chipset, which is a nice chipset that is relatively stingy on power supply and can fix its position - known as TTFF (Time To First Fix), even in indoor environments, in a matter of 30 seconds or so. Just keep in mind that the odd peach-colored ceramic part is the antenna and should point towards the sky. Many other chipsets offer significantly less in terms of performance and most are unable to fix a position unless outside. I was sold on it since happens to be the same chipset that I have in my Garmin CS60x, a considerably more expensive device.

Besides all that, the EM406A is a perfect candidate for integration with physical computing projects because it’s output is serial. It starts outputting NMEA strings at 4800 baud once its position is fixed. NMEA 0183 is a standard with which GPS data is transmitted from a device using comma-delimited strings. For more information on NMEA, consult this resource.

The documentation for the board itself is well done. In addition to the NMEA strings that are broadcast from the board itself, the EM406A can have commands sent to it via its serial interface to get specific NMEA data back.  The only catch is be sure to get an 6-pin extra interface cable along with the board itself.  I cut the interface cable in half and then soldered the wires some headers to make prototyping easier. Otherwise it’s going to be impossible to do anything useful with it.

Schematic
Now that we have all that down, here’s a little schematic of how everything is hooked up together:

Photograph

Next Article
In the next post, I’ll be working through the software aspects of this project.

I know that you’re now agreeing that this is a tedious edge case and probably clicking the close button on your browser, but for those that haven’t yet, there’s an easy answer. Open up Disk Utility from /Applications/Utilities and select the drive that you unmounted and click “Mount” from the menu. Problem solved, render complete (hours later).

Created by Sato Masahiko and Kiriyama Takashi the piece was called Arithmetik Garden. The premise of which is a space that one enters after picking up a card with a number on it. This card also contains an embedded RFID chip. One then wanders through a series of gates that contain RFID readers and are marked with mathematic operators combined with numbers (e.g. + 3, -8, / 2, * 7, etc.). The end goal is attaining a value of 73 by walking through the various gates to perform those operations on the current number before exiting the piece.

What is especially nice about this piece is that the technology is completely transparent, as the card is on a string which is placed around one’s neck. This leaves a participant to focus on the math operations required and the freedom to enjoy the experience of walking through an interface rather than passively interacting with it. There is, however, a computer in the corner of the exhibit that will display the original number as well as all of the mathematical operations performed throughout the experience. It also displays the current number for those that are less mathematically-inclined.

Photos were not allowed in the exhibition, so here are a few that I found:

But first, before an explanation, here’s a demo of the application:

The Phidgets RFID Reader
PhidgetRFID is a EM4102 125Khz protocol reader. This means that it does not have the capability to write to RFID tags, only read from them. While this is just fine, I point it out so that you are aware of this fact if you are new to RFID. It should also be noted that RFID readers like these usually fit into a larger architecture that consists of a database of some sort. This allows RFID tag IDs to be stored along with additional metadata.

This particular reader is nice in that you can connect it directly to a computer (Mac, Windows and Linux support) via USB and simply run a web service that provide connectivity to the board. In this example, that process is abstracted away in the AS3 classes that Phidgets provides (they also have a .SWC if you prefer that), so connecting to it and reading tags from it is really quite easy.

After installing the software from Phidgets, I set up an alias in my bash profile set up to make it easy to fire up the web service: alias phidget=’/usr/bin/phidgetwebservice21′. That way, I just type phidget into a terminal window and it starts. After plugging the RFID reader into an open USB port, it’s ready to communicate. That’s really all there is to setting it up since there is no microcontroller involved.

Flex Builder 3 and AIR
I opted to build this as an AIR application because an application like this is most applicable in a kiosk scenario, rather than as a web application. Anyway, connecting to the RFID reader using Flex is quite easy and a majority of the code is devoted to setting up event handlers:

creationcomplete="onCreationComplete()">
 
<!--[CDATA[
 
import com.phidgets.*;
 
import com.phidgets.events.*;
 
private var devRFID:PhidgetRFID;
 
private function onCreationComplete():void {
 
devRFID = new PhidgetRFID();
 
devRFID.addEventListener(PhidgetEvent.DETACH, onDetach);
 
devRFID.addEventListener(PhidgetEvent.ATTACH, onAttach);
 
devRFID.addEventListener(PhidgetErrorEvent.ERROR, onError);
 
devRFID.addEventListener(PhidgetDataEvent.TAG, onTag);
 
devRFID.addEventListener(PhidgetDataEvent.TAG_LOST, onTagLoss);
 
devRFID.open("localhost", 5001, "1234");
 
}
 
private function onAttach(pdeEvent:PhidgetEvent):void{
 
trace(pdeEvent);
 
devRFID.Antenna = true;
 
devRFID.LED = true;
 
}
 
private function onDetach(pdeEvent:PhidgetEvent):void{
 
trace(pdeEvent);
 
}
 
private function onTag(pdeEvent:PhidgetDataEvent):void {
 
&nbsp;	trace(pdeEvent);
 
//This is where all of the good stuff goes...
 
}
 
private function onTagLoss(pdeEvent:PhidgetDataEvent):void {
 
trace(pdeEvent);
 
}
 
private function onError(pdeEvent:PhidgetErrorEvent):void {
 
trace(pdeEvent);
 
}
 
]]-->

If you’re interested in the rest of the code, download the source. Also, a quick disclaimer that this was just a quick proof-of-concept and is all in a single MXML file for simplicity rather than encapsulating objects and creating components.

AMFPHP Remoting
For server/Flash Player communication, I generally opt for remoting due to its ease of implementation and speed, especially if dynamic, database-driven calls are required for the application. In this case, PHP and MySQL will handle user data and authentication as well as consuming SMS services. I could write an entire article about AMFPHP and Flex 3, and probably will, but for now, I’ll just mention it and note that it in the source code.

SMS
In the demo version (I’m not releasing this portion publicly), I’ve also rigged up some PHP classes to send SMS messages. I found a service called Clickatell that provides SMS gateway services to a bunch of giant corporations like BBC, Vodafone and Oracle. However, they do actually offer services to substantially smaller entities such as myself, which is pretty cool. Not only that, but they offer a free trial of their services.

I’d recommend them if you only need to send outgoing SMS messages. If you are interested in two-way messaging, be prepared to pony up a large amount of cash for short codes (somewhere in the neighborhood of $1200/month) and message routing. The other alternative is to set up your own SMS gateway. However, keep in mind that while setting up your own gateway is easy, it is not cost effective for sending large numbers of text messages using a normal consumer account. It will end up being cheaper using a bulk service like Clickatell.

Source
Click here to download the source for the AIR source and installer, PHP code and MySQL schema.

So here are a couple use cases where I run into issues:

Attempting to set the baud rate using /serial/baud 4800 is apparently successful, until I type in /serial/baud to return the value and it is inexplicably set to 4828!? Any other number that I pick at random results in it being set correctly. I have no idea what to make of this behavior.

As an additional problem, when I type in /serial/readable I receive a value of 1048760. If I then enter /serial/block to attempt to read that data, mchelper crashes [Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000)]. If I then try /serial/block 128 (or any other int), then I get a /serial/error Bad Data response.

Note: I posted the above to the MakingThings forum last night, and Liam promptly responded that this is indeed a problem with mchelper 2.0 and its implementation of OSC blobs that are returned by /serial/block. As for the incorrect baud rate issue, he’s not quite sure, but hopefully that will be resolved soon as well. I’ll be posting some how-to articles on bidirectional serial communication and using GPS devices with the Make Controller, OSC and AS3 once those bugs get straightened out.

- mchelper 2.0
- heavy 1.2 rc4
- New AS3 classes

Step 1: Erase the Current Firmware
To do this, connect power to the board and use a jumper on the 2 pins marked “ERASE” near the JTAG connector on the board. This will erase everything on the board including the firmware. Turn off the power, remove the jumper, then reconnect the power to restart the board. This will put the board into receive mode.

Step 2: Upload heavy 1.2 rc4
There seems to be a bug in mchelper 2.0 in that the option to upload firmware to the Make Controller is always grayed-out. So you’ll need to use a previous version in order to install the new heavy 1.2 rc4 firmware. To do this, fire up mchelper 1.2 then simply select the .bin file and click upload. Restart the board after the firmware has updated.

Step 3: Connecting to Flash
Close mchelper 1.2 and open up mchelper 2.0. Send a test message to the board to make sure that everything is setup properly.

mchelper 2.0 now has an XML socket server built into it (unfortunately not a binary socket server), so rather than connecting to flosc as we did in the past, we connect to mchelper. This is straightforward enough:

var mcfConnection:McFlashConnect = new McFlashConnect();

From there, it’s just a matter of setting up a bunch of event listeners, which isn’t all that different from my previous examples:

mcfConnection.addEventListener(McEvent.ON_CONNECT, onConnect);
mcfConnection.addEventListener(McEvent.ON_CONNECT_ERROR, onConnectError);
mcfConnection.addEventListener(McEvent.ON_CLOSE, onClose);
mcfConnection.addEventListener(McEvent.ON_MESSAGE_IN, onMessageIn);
mcfConnection.addEventListener(McEvent.ON_BOARD_ARRIVED, onBoardArrived);
mcfConnection.addEventListener(McEvent.ON_BOARD_REMOVED, onBoardRemoved);
mcfConnection.connect();

One of the primary differences between the new MakingThings AS3 classes and the others that I’ve written about is the addition of some methods to not only connect to mchelper (previously flosc), but also to determine when a controller board is actually connected. This is a significant improvement, as then you can be sure that you’re actually connected to the board. Additionally, the way the new classes are written opens up the possibility of connecting multiple boards, as they can be addressed individually by IP address, USB address, name (i.e. /system/name) or serial number, which is a super cool feature.

Once the connection to mchelper is established and a board is detected, sending and receiving OSC packets is rather straightforward. Here’s an example of how to send an OSC packet:

mcfConnection.send("/system/name", []);

A really cool feature of mchelper 2.0 is that OSC packets that are being sent and received from Flash are traced out to the dialog window in mchelper, which helps tremendously with debugging. After compiling a SWF that sends an OSC packet containing /system/name you should see the following in mchelper:

XML server --- New XML Connection
XML server --- /system/name
USB --- /system/name Make Controller Kit

That’s really all there is to it. Thankfully, the new MakingThings code is much less unwieldy and ditches flosc, so kudos to them for making much-needed improvements.

Step 4: Conclusion - Let the Hacking Begin
I haven’t had a chance to look at the new AS3 classes in great detail, but there are some nice new features. However, one thing that I noticed that was a bit disappointing was that all of the XML parsing is being done using XMLDocument objects, which have been deprecated in AS3. There’s no reason why this shouldn’t be using Flash Player 9’s native E4X capabilities, so that’ll be one of the first things that I rewrite, being as how I already did that in the MakingThings AS2 classes that I ported to AS3 a while back.

Download the full sample class here

The Easy Way
While not exactly the most ideal, for a short-term hack, we copied the XML in the WSDL that was generated, copied it into a empty file, and removed the offending methods manually. This was then placed on our servers and called in place of the overloaded WSDL. While it is not terribly clean nor reliable, as any time the web services change the WSDL is not updated, it happens to work without any server-side modifications.

The Hard Way
For the longer-term solution we will be implementing a service proxy in .NET and Windows Communication Foundation (WCF) because it is necessary for future iterations of the project. A service proxy is an extra layer in an SOA architecture that essentially acts as a broker between web services. The service proxy in our case accomplishes several things:

• Consolidation of multiple web services from multiple vendors into a single public-facing SOAP endpoint that the Flex client can then consume instead of attempting to integrate with them directly

• Allows for mapping between a single SOAP call into the service proxy by the Flex client to be mapped to multiple web services to be

• Allows for web service transactions whereby SOAP calls can be rolled back depending upon results from various calls to various external services

• Gives the ability to implement MSMQ for scalability and reliability, as SOAP messages can then be stored in a queue for later in the case of external services being down or overloaded

• Best of all, it allows us to author the SOAP API and the WSDL that the Flex client will connect to and removes the issue of attempting to consume an overloaded WSDL from Flex