Related Work top
Background/Discussion top
I decided that the use of something as versatile as the BASIC Stamp was the best way to go for a couple reasons. The cost of the module's starter kit was well within an acceptable range for the project. Though the Stamp I cost something on the order of $35 that cost would come down for any larger number of units for an actual deployed system. As we can see from the capabilities of the Basic Stamp I/II, the possibilities for expansion are pretty wide.
I decided that a protocol for data transmission was really unnecessary. The Panasonic IR receiver was pretty good at filtering out noise by itself, thus the implementation of any sort of error checking wasn't required by a protocol implementation. Any data (hex, ASCII, etc) can be transmitted through the STAMP/FireStick combination. In our case, I am transmitting a byte (id #) but this is pretty much arbitrary and up to the user's needs. My initial attempts centered around transmission of the whole name (e.g. “Henning Schulzrinne”) but this proved to be problematic in terms of error checking if the user was moving, was partially obstructed, etc. To reduce the complexity I switched to the transmission of simple ID #, which proved much more manageable on the transmitter/receiver end.
This setup requires that all users that we wish to track are entered into the SQL database beforehand, and ID#s are mapped to specific names. However, using this sort of method allows us to build a transmitter tag that could be reprogrammed in a much simpler way than setting a “name” string or something of that sort.
To implement very basic error checking, I setup the transmitter to transmit the char sequence “A_” followed by the actual ID tag. On the receiver end, the Stamp's language set allows me to wait till an “A_” is received from the IR receiver, and then grab whatever comes afterwards. This way, we are not grabbing ALL infrared transmissions, but only that information immediately proceeded by the “A_” identifier. Besides error checking, this setup allows for a possible expansion of the system to only identify people, or equipment, selectively based on their “identifier sequence.” So, for example, the receiver can be setup to only track equipment by listening for “B_” which we could program as the preceding identifier for equipment, vs. “A_” for users.
ID transmission occurs at 1200 Baud, 8 bits, 1 stop bit, No parity. This appears to be the best mode for the Basic Stamp I… and in retrospect this is where I would have chosen to implement the transmitter using the basic stamp II, which offers a wider array of Baud rates/transmission options. The receiver (a Basic Stamp II) is capable of sending/receiving data at a much higher rate. We can also use one bit for parity checks, but this feature is not implemented in the Basic Stamp I, thus I did not use it.
The use of the BASIC Stamp Super Carrier board allowed me easy access to a serial interface for the receiver. By sending RS232 serial data over pin 16, we can use the serial connection of the Super Carrier Board to communicate with the client listening on that COM port. Bi-directional communication is also possible, if we chose to communicate with the transmitter tag for example. RS232 gives us the flexibility of writing whatever client code we would want. In my case, I chose Java and the java.comm. API. Though there are most likely better choices for serial communication, Java was what I knew, and the comm. API had pretty good documentation. Serial communication packages exist for VB, C/C++, Java, QBASIC, Pascal, whatever your heart desires. The simplicity of the code makes it possible to make a client on pretty much anything that's networked and has a serial port. Although true RS232 is +/- 10V, and the output of the BS I/II is only 0-5V, it doesn't appear that there is any problem in interfacing the two together. Modern's PCs seems to be able to communicate over this “quasi” RS232 supplied by the Basic Stamp.
Because the FireStick II module pulses the IR Emitter LED directly from the 9V source, its range is rather impressive. I tested the tag in the lab, achieving reception throughout the room. The published indoor range for the FireStick is “40 to 60ft” which seems to be plenty for this type of application. No data integrity loss was observed at high ranges.
Right now the size of the tag is HUGE. The 9V battery, the Rev. D. package of the Basic Stamp, and the semi-attached FireStick module make quite a hefty “tag.” By utilizing the in-line BS I, OEM kit for the FireStick, as well as a much smaller (shorter life) battery, I think I could significantly decrease the size of the transmitter to make it a practical thing to actually clip to your shirt pocket/belt. If the project were to progress past any “developmental” stage this size decrease would be made absolutely necessary. On the receiver end, I think a home-build board could be assembled for a cheaper price than the BS Super Carrier Board. This would decrease the size and cost of the BS 2 receiver module significantly without any loss in functionality.
Architecture top
The BASIC Stamp I
I selected the Basic Stamp I as the the transmitter prototype for the "tag" aspect of the project. This choice was primarily based on cost, size, flexilibilty, and capability. For the actual prototyping I used the Basic Stamp Rev D., this version of the Stamp I comes with a convenient prototype board where I intended to implement the FireStick II module. This package of the Stamp I, along with the 9V battery, is obviously too big for any sort of actual deployment. However, using the in-line package of the Stamp I, along with a much smaller battery, we could decrease the size of the module significantly. The Rev. D. package allowed me to easily work with the package while doing the design, prototyping, and testing of the system.
Rev. D. Package | In-line Package |
The FireStick II allowed me to use the BASIC Stamp to transmit serial data by infrared. The really convenient aspect of the system is that IR communication can be accomplished with a single I/O-pin. The receiver circuit requires only an infrared detector module such as the Panasonic PNA4602M for serial data reception at baud rates up to 2400. This is the IR receiver module that I used on the receiver Basic Stamp II.
FireStick II |
Receiver Architecture:
Panasonic 38KHz Infrared Detector Module | BASIC Stamp Super Carrier Board | BASIC Stamp 2 |
The "query" client model is a PHP script which asks the Location DB SQL server where a certain person is located. In this example, the PHP populates the menu with Names it retrieves from the DB, and allows the user to select "John Anonymous" as the object of the Query. Once the user presses "Find", the query is sent to the SQL server in the form of "Where is John Anonymous". The script them retrieves the result of the query and displays the appropriate information.
"Where is 'John Anonymous' Query" |
Location Query Result |
Program/System Documentation top
Directions of Future Research top
Many possibilities exist for expanding the uses of a location DB... phone redirection would be possible by redirecting a phone call for a mobile user to the specific location of that user at a particular location. For example, I would be able to receive an Emergency phone call to me, anywhere in a location DB enabled building.
One of the possible uses of such a system would be to allow the user's state, for example the light level of a room, or a TV program on a certain channel, to follow him or her throughout a household.
Tracking equipment, overhead projectors for example, would be made possible. Thus, if a teacher needed the projector for a class, he/she would simply query the location db about where the projector was located instead of having to physically search for it throughout the building.
Bi-directional capababilities do exist in the BASIC Stamp I/II model of the location system. It would be trivial to implement a bi-directional capability in both the transmitter/receiver based on the BASIC Stamps. The addition of minor hardware (A FireStick module on the receiver, and a IR receiver module on the Stamp Transmitter) would be required. As the current setup utilizes but a fraction of the communication capabilities of the Stamps, expansion is a real possibility. One example would be to notify the user wearing the tag that a location query was executed searching for his/her location. Tag-tag communication would thus also be possible, so not only "Where is the projector?" but also "Who has the projector?" queries could be executed.
Links of Interest
Hardware Vendors
References top
Special Thanks: top
Faculty Sponsor: top