By Don Carveth
I didnt take long after getting my robot untethered to wish I could see what was going on inside. It seldom did what I thought it would when I launched it. Get to the wall, turn right and follow the wall. Then why get to the wall then spin in circles? Trying to troubleshoot without information is tough. My robot now sings and blinks to help let me know whats going on, but nothing beats hard numbers.
So my first major diversion from straight robotics turned out to be wireless communications. Low cost RF data modules have been available for several years from a number of sources such as Lemos and Abacom. These modules use AM or FM modulation and can operate from 1200 baud on up. I was able to put together a test system pretty quickly. In my initial experiments with the modules I discovered several characteristics:
Although I could watch my data scroll by the noise made it impractical to use the data as variables in calculations or for control purposes. If the transmitter is powered down, as it must be for two way communication or multiple transmitting nodes, then the noise became extreme. I decided that I would need to filter the noise to obtain solid data that I could work with. The PC software should invisibly do this work and hand nice, clean variables to my application programs.
This article describes how to build a one way RF data link with noise filtration. It ensures that only valid data is passed on. Data packets are identified by the receiver by a unique two character start flag and a checksum ensures corrupted packets are not forwarded. At the microcontroller end data is converted into RF friendly packets for transmission and at the PC end valid packets are located and decoded. The electronics are very simple and can easily be constructed on a breadboard in one evening. It assumed that the reader knows the fundamentals of sending a serial data stream from a microcontroller for display on a PC terminal program.
The PC software provided is what is called a DDE I/O server. It does all the hard work of filtering, converting, mapping and scaling the data into computer friendly values that can be linked into any Windows program that can make DDE calls such as Excel, Visual Basic, Wonderware and hundreds of others. More on this later. The microcontroller routines are written in Imagecraft C but can be easily rewritten into other languages.
How well does it work? Well its not a wired network, however I can reliably receive 4800 baud transmissions from most locations in my house. It has good days and bad days. Some locations work better than others. On bad days it can't reach the far corner of the house (50 away). Its pretty much 100% reliable within a single room of any size. Once the routines are set up its very easy to adapt to specific applications. It has certainly enhanced my ability to troubleshoot my robot. Its also useful for general wireless data acquisition use.
Will this be a difficult project? The physical installation is very simple. The RF radio modules are straightforward. On the PC end you need to add an RS-232 level converter. Both transmitter and receiver can be built up on breadboards. Most of the work is in the software. If you can make direct use of the routines I have provided you should be able to get things up and running in a few evenings. If you have to rewrite the microcontroller routines for your setup then it will take a few more evenings. If you want an application program with a graphical display, then, well you guessed it.
Wireless vs. Wired
This adventure began after I purchased some low cost RF radio modules from Abacom. The AM transmitters sell for under $12. It was quite easy to get a transmitter transmitting a periodic message from the micro and it was quite easy to connect the receiver to the PC through an RS-232 converter chip. After that things got a little more challenging.
One discovery made soon after firing up the RF modules is, that although your data shows up, so does a lot of other stuff. This is one of several significant differences between wired networking and wireless:
These differences dictate these design features:
The above criteria narrowed the choice of transmission protocol. I have chosen an old standby that I call ASCII Hex. This is what MODBUS and several of the older standard protocols used. Each byte sent is converted to two ASCII characters representing the hex value of the Most and the Least Significant Nibbles (4 bits). Additional characters (such as ";") can be used as control characters. A value of 1 would be represented as 0x30 and 0x31, the hex codes for the ASCII characters representing 0 and 1.
The advantage of this method is that the small character set in use (0 through F plus a few control characters) can be easily mapped to 5050 characters for RF transmission. In addition, control characters are easily differentiated from data, and the data can be monitored visually using a terminal program. The disadvantage is, of course, the speed. It results in essentially half the throughput of a byte at a time 8 bit protocol. There is an additional processor overhead penalty due to all the converting and mapping thats going on. Even with these caveats, however, it's still quick enough to be very usable.
The system is based on the PC receiving unsolicited data from the microcontroller. In other words, the micro sends data when it wants and the PC receives and handles the data as an exception. The PC never "asks" for the data the way most data acquisition systems work. This method is simpler and solves the "data from robot" problem pretty well. If you want to start controlling your robot from the PC based on this data then it gets a little more complex. Maybe next article.
The packet definition I am using is "UUUUU;;NnDdDdDdDdDd .Xx" where U is a sync character (the character "U" is used as it is composed of 01010101, an ideal 5050 character), ";;" is the start detection string, N and n are the Most and Least significant nibbles of the Node Number, D and d are the bytes of data and X and x make up the checksum byte. The term "Node" could as easily have been called message. Every different message, whether it be from one microcontroller or several, is assigned a separate node number. The makeup of each node is configured in the PC software. This is how the receiving software knows the length of the incoming packet and the data content of the packet.
Sending large amounts of data at low baud rates in regular polling mode (such as ICCs printf or putchar routines) can chew up a lot of CPU time. If this becomes a concern you should look at using interrupt based transmit routines.
Major System Components
Convert raw data to ASCII Hex
Add node number
Calculate and add Checksum
Convert to 5050
Transmit Packet to RF radio 5 V signal
Radio sends packet on assigned frequency
Radio scans assigned frequency for data
Convert 5 V data to RS-232 levels and send to PC com port.
Scan com port for ";;" string (the sync characters are ignored)
Determine which node has transmitted - Node sets packet length
Receive number of characters expected
Convert from 5050
Calculate checksum and compare with that received with packet
Convert from ASCII Hex to Bytes, Integers, Longs or Strings
Scale Numbers to Engineering units
Update DDE callable variables
The Radio Modules
Low cost RF radio modules are made by Radiometrixs in England and are sold in North America by Abacom and Lemos. All three companies have good information available on the web. The modules start on the low end with AM modules rated at 1200 baud (I found they could usually do 2400) to FM modules good for up to 19200 (last time I checked). I have used both the low end AM modules and an FM module good for 4800 baud. The FM module had somewhat better reliability and range than the AM version.
The transmitter modules are compact and very simple to install and require only a short piece of wire as an antenna. They run directly from a 5V data circuit (be careful not all models do) and so can be connected directly to the microcontroller without requiring an RS-232 level converter. If your board already has one you will need to pick off the signal before it gets there. They operate at either 418 or 433 MHz. Im not sure if this is an unlicensed band in the US. The radios are built in England and this band is unlicensed there. The usable range of the modules is purported to be 200 outdoors but in a house with many walls 50 is a better number.
If you are setting up a one way single node system then tie the transmitter power directly to +5V. If you are going to have two way communication, if you have more than one node, or, if you need to save power (approx. 10ma in the configuration below), then control the transmitter power via a microcontroller output - I used the 68HC11's PA5 output. Reception is better with constant power.
The receiver is a little larger but still simple to install and requires a similar antenna. It puts out a 0 to 5 volt signal, therefore a TTL to RS-232 level converter is required (MAX 233 or equivalent) to interface to the PCs com port. The converter and receiver can be mounted on a board only 1" x 3". A separate regulated 5VDC power supply is required as the PCs RS-232 port will not supply enough current. I recommend installing a fairly long cable between the PC and the receiver board so that the receiver can be optimally located. Mine works best in the adjoining room.
Once the receiver is built, plug it in to the PC and fire up HyperTerminal. You should see a barrage of characters going by (unless you live miles from civilization). Next program your microcontroller to send out a periodic burst of data to the transmitter. Make sure all your baud rate settings are matched up. You should be able to see your data showing up on the PC along with some noise data. If you have arrived at this point youre ready to go on.
The Microcontroller Software
I have provided a test program for a 68HC11 microcontroller, written in Imagecraft C (Ver. 5), that sends out a properly formatted data packet once per second from the serial port (packgen.c, Vectors.c, StdDefs.c, packgen.s19). This test packet data consists of a character (1 byte), an integer (2 bytes) and a string (defined as 5 bytes). The character and integer variables are ramped up and down between their upper and lower limits to mimic actual changing data values. The string oscillates between "AAAAA" and "BBBBB". The routines in this test program should be all you need to format your own data packets in your own program. Incidentally, the program was completely written and debugged in Borland C++ Builder using Imagecraft C syntax. It was moved to the Imagecraft IDE for final compilation only and it worked in the microcontroller with only a couple of minor tweaks. The ability to write and debug programs outside of the micro is a great time saver. If anyone converts these routines to SBasic or assembler let me know and Ill post them on my Website at http://www.alaska.net/~carvethd/robots/robots001.htm. The provided S19 file is configured for a 68HC811E2 with program at F800, data at 0000 and stack at 00FF.
The DDE I/O Server
The concept of "I/O Server" comes from the industrial automation world. In this arena there are a multitude of PC data acquisition software providers (Wonderware, Intellution, FactoryLink to name a few) and another multitude of hardware device providers (Modicon, Allen Bradley, Sq.D, Honeywell, etc., etc.). I/O Servers are the interpreters that allow the software packages to talk to the hardware, very similar to drivers in the Windows world. DDE servers are really the least sophisticated type of server but work more than adequately. The newer I/O servers are ActiveX components and a new specification called OPC (OLE for Process Controls) gives a complete framework for the ActiveX controls to be developed in. I may try to convert my server to an ActiveX control, but not this week.
The I/O Server does all the communications hard work and presents a value in engineering units to your application program. The nice thing about DDE is that Excel, most math calculation programs, all windows programming languages and many other programs can easily be configured to link to the variables. You can also link up to Web pages. I have provided a sample Excel Spreadsheet DDETest.xls that will read the sample data that the I/O Server will transmit. The I/O Server performs all the functions listed above. It scans the com port for valid packets, determines when the packet is complete, converts the values from 5050 to ASCII Hex, checks the checksum, and, if OK, updates variables that in turn update external program links. The 5050 mapping can be turned off in the configuration menu in case you are using a wired link.
How does it know which data in the packet is associated with which variable? Well you have to tell it. A configuration window allows you set the baud rate, com port and the like. It also requires that you define the variables (or tags I have used these two terms interchangeably) being transmitted. For each variable you must define a name (not used internally for reference only), an index number (the DDE variable reference), a node number, a type (unsigned character, integer, long or string), a length (strings only, the length is fixed for other types), a min/max raw and min/max scaled value (for numbers only). Once the variables are entered the configuration program figures out what the packet looks like for each node. The transmitting nodes must, of course, send a matching packet.
The program comes up in monitor mode. In this mode, all incoming data is displayed while the successful incoming packets update both raw and scaled variable value columns. This is an excellent troubleshooting tool allowing you to watch the interaction between your microcontroller and the I/O Server. I would recommend getting a wired link operational in this mode before you insert the radios into the equation.
Another troubleshooting feature I have built into the program is a test packet generator. Two modes of operation are available. A packet can be manually entered (or cut and pasted) into the text box. The checksum can be calculated and then manually added. The packed can then be submitted to the program front end and the resulting data values monitored. In auto mode, test packets based on the current configuration are generated once per second. The values of the numbers are ramped up and down and the strings oscillate just as in the microcontroller test program. This mode allows you to set up the I/O Server to application interface without even plugging your microcontroller in.
The program was developed using Visual Basic 5.0 . The program includes a help file that should be enough to allow you to set up your own Tag Database. The database is stored in sequential ASCII format and it also includes a configuration table. The executable program and sample Tag Database is attached for download as DDEServ1.zip. The file, after all the required OCXs were included, after compression, ended up at close to 2 Mb. The software is to be considered Beta level - I have tested the main features but not all variations. Please let me know if you find any problems and I'll try and keep the version on my website up to date. The Visual Basic source code is attached as DDESource.zip.
Now that you have you robot sending data and the I/O Server receiving it, what do you do with it? Well, the simplest use is to have no application software and just use the I/O Server monitor. You could also make up an Excel spreadsheet to monitor each of your variables by inserting DDE statements in separate cells. This doesnt get you the value over time information you may want but can create real time moving graphs.
Another good option is industrial control/data acquisition software. Most makers of this software provide fully functional two hour demos. These programs have all the displays, charts, graphics and data logging features you want and are designed to be setup by non-programmers. I prefer Intellutions Fix package myself, but pretty much all of them will accept DDE links and allow you to build graphical displays and reports relatively easily. Some other names are Wonderware, FactoryLink, Allen Bradley (RS View) and Aimax. Some of these will only run under NT so watch out for that. Licenses for this software are very expensive (typically well over $1000), so you are pretty much stuck with the two hour runtime limitation.
The most flexible method is to use Visual Basic or any other Windows visual programming language. Many controls are available such as slider buttons, gauges and strip chart recorders that will allow you to graphically represent your data and, of course, you can now do whatever you want with it including updating your Web site. I have included VB code (Scroll.zip) and executable (ScrollExecutable.zip) for a simple scrolling data monitor that will give a result similar to sending formatted text directly to HyperTerminal with a few improvements.
The obvious next step is two-way communication. This would allow you to not only monitor but also control your robot. In theory this means just reversing what we're already doing but a full implementation is not a small step for a few reasons:
One difficulty I ran into was lack of robustness of the PC com port. I found the port would sometimes lock up when hit with the wild data noise streams from the RF receiver. I ended up writing a small port reset program that would reset the port without requiring a reboot. This problem was additional reason for building a microcontroller based prefilter module. One of my PCs was affected more by this than the other.
I have constructed and have operational a 68HC811E2 based device that serves as a 5050 mapper on the transmit side and serial filter and packet parser on the receive side. This solves the first problem listed above. With one of these devices on each end its almost as simple as a wired network. If there is sufficient interest Ill pull together an another article on this subject.
There is a flurry of wireless data communication activity going on out there, especially on the Ethernet side. I have been watching the various developments but I believe we are still a year or two away from having low cost ubiquitous devices that can easily connect a microcontroller to a wireless high speed PC network. I anticipate that the next step in this evolution will be an Ethernet microcontroller interface chip communicating to a wireless Ethernet network but it cant be done at this time for under several hundred bucks and some R&D. Such a link would, of course, open up a whole new world of possibilities and its certainly on my radar screen.
The two primary sources of information I used to put this system together are the RF module manufacturers data sheets and application notes and the "Serial Port Complete" by Jan Axelson.
I you have any questions or comments, please feel free to drop me an e-mail at firstname.lastname@example.org.
Microcontroller code in Imagecraft C:
Test Packet Generator program - packgen.c
Vectors file (Used by Imagecraft C) - Vectors.c
My standard definitions file - StdDefs.c
Compiled S19 file - designed for a 68HC811E2 but can be used if you can load program data at 0xF800 - packgen.s19
Test Excel Spreadsheet - DDETest.xls
Scrolling Data Monitor - Visual Basic application using DDE calls - Executable ScrollExecutable.zip Approx 1.5 Mb
Scrolling Data Monitor - Visual Basic application using DDE calls - Source code Scroll.zip
The DDE I/O Server executable and sample tag database - DDEServ1.zip Approx 2 Mb
The DDE I/O Server Source Visual Basic Source Code - DDESource.zip Note: you need MSComm (in the Professional Version only).