circuitcellar.com
Magazine Support   Digital Library   Products & Services   Suppliers Directory 
 
 

 

December 2005, Issue 185

Browser-Based Telemetry System

POOR MAN’S SYSTEM

In the early days, I thought connectivity issues would be the crux of this project, but I was wrong. We had numerous discussions about using wave-guided (Wi-Fi) or radio modems and repeaters, but neither was a viable option given the raw wilderness settings in which the system would be operating. As the years went by, however, I saw big improvements in cellular technology. It eventually became a matter of simply getting in touch with Bell Canada to get a sponsored cellular modem. The rest was straightforward. I loaded up the rig with sensors and cameras.

We wrote the entire system in Java, from the low-level job of polling sensors all the way up to generating reports and posting them on a hosted web site. The separation of concerns isn’t only a good idea, it’s mandatory for any multi-agent system.

Java was the practical choice for this project. I wanted to keep things simple and portable. Figure 1 shows the data flow from the cliff face to the web browser. Refer to the “Framework” sidebar for more information.

(Click here to enlarge)

 Figure 1—1-Wire networks are advantageous because of the parasite power and daisy chaining that simplify the cabling. But you’ll need an RJ11 crimp kit to make cables.

The embedded device on the climbing rig collects sensor data, wraps it in XML, and sends it to the home server in a UDP packet. The home server then parses the XML and generates a report as an image to be sent via FTP to a host server. Finally, the administrator requires only a computer with Telnet, FTP, and a web browser to keep the system up and running.

I used two servers (home and hosted) because most hosting companies charge for running servlets and they won’t open just any old port for your XML data. However, there is no extra charge for simply sending the reports as images via FTP. (This eats into my monthly transfer limit because images have a higher byte count than XML data, but I’ve never gone over.) In addition, the home server, which is on an asymmetric digital subscriber line (ADSL), has a low outgoing bandwidth and would never be able to support numerous concurrent users. (More and more cable and DSL providers are blocking common ports like 21 and 80, so read your agreement carefully.) My system makes the best of these restrictions at the expense of increased latency. These protocols are standards and easy to reconfigure if lower latency is required.

Framework

Java does far more than just wipe away memory management issues. The Micro Edition of the Java 2 platform (J2ME) has only the core functionality of the Java 2 platform enterprise edition (J2EE). I needed to develop a framework so that all my tools would run on Mac, PC, and embedded platforms.

My framework builds on the lowest common libraries of the Micro Edition to simplify the networking and to provide basic XML parsing and command dispatching using best-practice design patterns. To jumpstart a new project, all you need to do is hook into this JAR supply properties file and specify UDP, TCP, or multicast protocol and addresses.

Now I can use XML to talk to an Internet application, diagnostic tool, or the embedded devices (see Photo 1). Multicast addressing enables the system to be highly redundant and distributed. Using UDP sockets also enables services to stop and restart without having to reestablish connections (as TCP would require). Packets are rarely (if ever) lost on a LAN. I tried several stress tests and never lost a single packet.

A code snippet posted on the Circuit Cellar FTP site shows you how a project hooks into the framework JAR. You’re only required to instantiate a sensor or device (e.g., an LCD screen or motor controller) and register it with an API. This keeps the project space tight. You must deal only with your chosen XML syntax and the device’s public methods. The API is a two-method interface the developer must implement:

- execute(Command command)

- filterEvent(Object o).

This framework is meant to be as simple as possible. There are richer features in projects like Jgroups, which is a toolkit for multicast communication (www.jgroups.org). Code portability and reuse should be the goal of all large software projects. Java is by no means perfect, but it’s free and used in many open-source projects.

(Click here to enlarge)

 

 Photo 1—The swing-based chat tool enables you to see the XML commands and feedback. The TStik (DS1820) has a 0.5° resolution. The AAG device is much better suited to measure air temperature.

Standards and the communities of programmers continue to make Java popular. Why pay for development tools? Even though I cut my teeth on C/C++, Java showed me what object-oriented programming was really about. Oh, and don’t tell me, “Yeah, but Java is slow.” That hasn’t been true for years. It’s been the topic of many online discussions. Remember that Java can be cross-compiled as well (http://gcc.gnu.org/java/).
   
PREVIOUS • NEXT

 
Contact Us | Webmaster