Establishing a data collection network with web publishing

Abstract

Major development issues included the development of an algorithm that can perform many data conversions without losing the stored information, as well as incorporating sufficient error checking of the received data. We also develop a prime number algorithm to control transmission time and minimize collisions, thus enhancing scalability.

Introduction

We propose the design and construction of a remote data collection network, capable of communicating wirelessly with a personal computer or workstation, and publishing the collected data to the Web to make it globally available anywhere in the world. Specifically, our design involves a scalable network of temperature sensors, scattered throughout a local area limited only by the transmission range of the wireless transceivers. By automating both data collection and data archiving, we greatly simplify the entire process, as the system is designed to run continuously and independently, with no human interaction required.

In theory, the sensor can be any data collection device that the user desires. However, for our demonstration, we selected a temperature sensor, both for its availability, and easily verifiable output. The sensor can output its data in either analog or digital format, since the microcontroller has the ability to take both as input, and convert to digital output if necessary.

The microcontroller needs to be capable of reading in data from the sensor. It also needs to frame the data, both at the beginning and end of each packet, to ensure that data is not lost or corrupted in transit. Packet framing offers us a straightforward method of error checking. Because each sensor is a part of a much larger network, it is important to designate which sensor a given packet has originated from. To accomplish this, each microcontroller also adds its own identification number to the packet before transmission. Thus, a packet transmitted from sensor 18 would have, in addition to the actual data, a start frame, a stop frame, and a byte designating that packet as “from host 18”.

To avoid spamming the network with redundant data, each microcontroller needs some internal mechanism to determine when to transmit. Also, because we want to reduce the noise over our network frequency, we want each transmitter to be off as much as possible. Thus, our algorithm for the microcontroller turns the transmitter on and off as needed.

It is much easier to design complexity and robustness in software instead of hardware. Thus, we sought to keep the wireless transmission link of our network as simple as possible. This increases reliability and durability. Accordingly, the requirements for our transmitters are fairly simple. They are only turned on when there is sufficient data in the buffer to transmit. Once they have finished transmitting, they are turned off. Since our system has a one-way data path, the transmitter is not capable of receiving any type of acknowledgement from the base station, nor does it look for one.

With this simplicity in mind, we also designed the base station receiver to do as little as possible. It merely reads in all information received, and passes it on to more intelligent devices. It does no error checking and makes no guarantees of successful delivery.

The MAX-232 chip receives data from the receiver, and converts it to the standard RS-232 data format [1] that can be read in by a serial port on a personal computer or workstation. Once the data is sent to the serial port, we read it to a file using low-level writes to the COM1 port. Our software is also responsible for parsing the data packets to ensure good transmission, error-checking to make sure that the received data is accurate, and writing the data to a file. Software also timestamps the data, and writes the most recent data received to a website for publication. We assume that the user has his own web server, such as Apache, running.

Design decisions

The sensor that was settled on was the Motorola MTS102, which can be obtained from On Semiconductor. This device is easy to use, since the output is an analog voltage. The unit is more economical, with a base price of fifty cents, and was available in the parts shop. Also it would be easy to replace with other analog devices and only require a change in the software as the hardware would function in much the same way. Unfortunately, the downside is that the device is no longer manufactured, so it would have to be produced from existing stores. Also, it only offers 2°C of accuracy and requires a current source for it to work correctly [3]. In spite of these drawbacks, we felt that the MTS102 was the best choice for our temperature sensor.

On of the downsides to using the MTS102 was its need for a constant currant source. This required more decisions to be made by the design team. The first solution was to construct a current source out of NMOS transistors [4]. The other solution was to use a current source part in the design. The team found it possible to build the current source by first simulating the circuit on PSPICE. The circuit, although simulated correctly, did not function correctly when built. This could be due to faulty NMOS transistors, or to variations between the transistors used in the simulation and the actual transistors we used to build the circuit. Due to time constraints, the team chose to replace their circuit with a LM334 adjustable current source [5]. This design is adjustable enough to be used with a wide variety of devices, as well as being economical at $0.50 and available in the part shop. The team felt there was no downside to using this device in the design.

2.2 Microcontroller design

The microcontroller provides the logic for making the remote sensor work. It is responsible for receiving the analog values of the sensor, creating the data packet, and operating the transmitter. It also must be capable of serial and parallel communication, and be able to operate at a mid-level bit rate. We considered both the Parallax Basic Stamp II, and the Motorola MC68HC912BC32, both of which were available from the parts shop. The Basic Stamp was rejected first because it was not fast enough to interface with the original digital sensor. When the sensor selection changed it was reconsidered for the design. The device did not have a strong analog to digital interface, the serial port was configured for RS-232 communication only, and the programming language was BASIC [6]. In contrast, the Motorola microcontroller was designed with built-in A/D conversion, could output data in both the RS-232 format and a standard TTL serial format, and was only slightly more expensive. The A/D allows for up to eight analog devices to be hooked up to it at one time allowing multiple devices at one location [7]. The Motorola microcontroller had its own unique instruction assembly language, but this allowed for more precise control of timing and actions taken by the microcontroller than the Basic Stamp. For these reasons the Motorola device was chosen.

The Motorola chip has a surprisingly complex serial port with two different types of interfaces: the Serial Communication Interface (SCI) and the Serial Peripheral Interface (SPI) [7]. The SCI has a transmit line and a receive line, while the SPI has bi-directional communication on a single pin. The SCI is better suited to our application because we can control and use the transmission line relatively easily.

2.3 Transmitter/ Receiver design

Although the transmitter and receiver were parts of different subprojects, the choice in the design process was made for these components at the same time. This is because the transmitter and receiver need to communicate with each other and so needed to come from the same manufacturer. Through research, the choices came down to two different systems: the Xemics XE1201 and the LINX TXM/RXM-315-LC. The Xemics XE1201 operates at a frequency range of 300-500 MHz and can operate as either a transmitter or receiver. It has a high data rate of 64 kbits/s, and an effective range of almost three miles [8]. The cost is around $7.50 for the unit, so it is very affordable. The difficulty came in dealing with the company: the data provided were not very specific about what other devices would be needed in order for the chip to operate correctly. This lack of communication caused us to look for another solution.

The LINX chip has much more modest functionality. The maximum range was only 300 feet and the maximum data rate was listed at 5 kbps [9]. The LINX chip operates at a set frequency of 315 MHz. The transmitter and receiver are separate components, which allowed for multiple transmitters at a cheaper unit cost and a less expensive total cost then the Xemics module. The limited range hampers the deployment of a full-scale network, but did work well for demonstrating the feasibility of the design. The choice of the LINX also removes the possibility of full duplex error checking. The hardware is never aware of whether it is performing correctly, and it is now left up to the software to determine if everything is working, based on the communication it receives from the sensors. This is because the LINX only allows for transmission at the sensors. Placing receivers at each of the transmitters was rejected because of cost.

2.4 Data processing with the MAX-232

The LINX receiver outputs its data in standard 5V TTL Format. This format is not compatible with the serial port, and so the data needs to be converted into the RS-232 standard. The first solution we came up with was to use a Xilinx Spartan II FPGA [10], [11]. The FPGA is programmable and so capable of a wider range of functions, including error checking. However, it is not designed for the type of interface we are designing. Also, the decision was made to do as much data processing in software as possible. This eliminates the need for programmability, as its primary function is just signal conversion. Fortunately, the MAX-232 from Maxim is specifically designed for changing TTL into the RS-232 standard. The only additional hardware it needs are capacitors to help generate the 10 volts needed for the serial port [12]. This solution is economical as well, at only $2.00 for the chip. These considerations made the MAX-232 the proper solution for the data conversion portion of the receiver module.

2.5 Software and web publishing design

The software portion of the project was responsible for three specific tasks: error checking, temperature conversion, and web publishing. The decision was made to do all error checking in the software because it is easier to manipulate and has a lower cost then implementing the functions in the hardware through the use of the FPGA. The temperature conversion came about through the choice of using the MTS102 and was based upon the specifics of that chip, and the way the A/D converter recorded the temperature. The web publishing requirements were carried out through the use of HTML markup tags, as opposed to a Java-based scheme. We chose this implementation to make our data as widely accessible as possible. Since we are conveying information easily conveyed with text, there is no reason to limit its accessibility to users with a graphical, Java-enabled browser. We also personally despise bloated and inefficient web pages, and did not want to create another one.

DESIGN DETAILS

The sensor hardware has three major responsibilities it needs to consistently perform. It needs to capture the temperature from the sensor, package the data, and transmit the data to the receiver. The first element we look at will be the capturing of the temperature.

The MTS102 was the temperature sensor chosen to be used in this project because it provides decent accuracy at low cost and can be a modular piece with other analog devices. In order for this to work, the MTS102 requires a constant current of 100 mA. This is provided by the LM334 adjustable current source. To provide the 100 mA current the source required a 680 W. The resistor value was determined by following the following equation [5]:

I_set = V_R/R_set * 1.059

This gave the sensor its necessary current. The characteristics of the MTS102 give it a base voltage of 595 mV. This means that the temperature can be determined from the following equation.

This temperature value is sent into the microcontroller via pin AD3. The microcontroller has 8 different ports that can receive Analog values and be converted by the A/D converter in the microcontroller. The microcontroller is configured to do the conversion of the temperature and assign it a value based upon two voltages. These reference voltages are:

V_H = 820 mV

V_L = 314 mV

These values were obtained by designing the voltage dividers in Figure 4, and were connected to pins 49 and 50. During verification it was found that the A/D converter did not live up to its specified of 8 bits of accuracy, but only had 5 bits of accuracy. This was solved by computing the average of 64 conversions and using this value instead. This calculation gave 8 significant bits with ±2 LSB in a ten bit conversion. 32 conversions was originally attempted and the accuracy only improved to ±3 LSB. The total time for these conversions was computed using the following equation:

((ATD Conversion Time * 64) + Division Calculation)/ MC Clock = Total Time

The total time is 200 ms, which is negligble when compared with the operating time of the program. This does not include the 32 clock cycles it takes for the A/D converter to make the conversion because this occurs concurrently with the rest of the code.

After the conversion of the temperature the microcontroller is required to create a data packet and send it. This requires use of the serial port. The baud rate of the serial port is the limiting factor as far as time to send the data packet. The baud rate is 9600 and the data packet is 40 bits long so it takes almost 4 ms to transmit the entire message. The packet consist of the following format:

The X’s signify that they are dependent upon some algorithm within the microcontroller to be set and can change. This packet is sent out on the serial port to the transmitter.

The third job of the microcontroller is to control the transmitter. During the testing it was found that more than one transmitter on at the same time can cause signal cancellation and thus cause false bits to arrive at the receiver. The solution is to have the microcontroller turn on the transmitter before it is to send and turn it off after it is done. The transmitter needs a period of time in order to stabilize before it is ready to transmit. This settling time was found in the specifications and was set at 10 ms in the code. This gives a total transmission time of 15 ms.

Once the data packet is sent the remaining portion of the microcontroller code is the delay code. This stops the microcontroller in order to allow other sensors to send their data packets into the receiver. This code is based upon the simple equation:

18*Iterations/8 MHZ = Time

The number of iterations that this loop will complete will determine the time in between transmissions. In order to minimize collisions, we would like the number of cycles between transmissions to be related by prime numbers. Using prime numbers will ensure that any two sensors in the network do not have transmission times which are multiples of one another. Thus, we cannot get a situation where one sensor is constantly preventing the transmission of another packet. Even if two transmitters send at the same time (which will inevitably happen), the delay code running independently at each site will cause them to misalign themselves on the next transmission cycle.

3.2 Receiver module

The receiver module is responsible for receiving transmissions from every sensor and forwarding them to the PC. This is accomplished by having the receiver powered up at all times and having the data output of the receiver converted by the MAX232 chip. This chip changes the data into a format that can be used by the Serial Port. The schematic for this is demonstrated below [13]:

3.3 Data handling in software

After the data has reached the serial port, it becomes the job of our software to turn this information into something that is correctly formatted and easily accessible and readable.

The first step is to transfer the data on the serial line to memory. To do this, we access the virtual memory address of the COM1 port directly, using the outp() and inp() commands found in conio.h. We also include dos.h to make use of its register addressing capability. We map the COM1 registers to 0x03f8 – 0x03fe, which allows us to access each port register as necessary [14]-[15].

In order to begin reading from the serial port, we need to configure it for our use. To do this, we disable interrupt generation, since we want to poll the Line Status Register (LSR1) instead. We then set active the Divisor Latch Address Byte (DLAB) by writing to the Line Control Register (LCR1). Once the DLAB is active, we can set the speed at which the serial port should look for data to be received. We want to communicate at a baud rate of 9600, which for our purposes can be considered to be 9600 bps. We then turn the DLAB off, and write LCR1 to tell the port that we are using 8-bit transfers with no parity and 1 stop bit. Finally, we set the FIFO control register by writing to IIR1.

After configuring the serial port, we are ready to begin polling for incoming data. In our code, we do this by entering an infinite loop in which we fill a memory buffer with data from the serial port, and then use that buffer to check our data integrity. To poll from the serial port, we check the least significant bit of LSR1. When data is in the FIFO buffer, this bit will be active. If this is the case, we simply read data in from COM1. Otherwise, we wait for data to arrive. Note that we can do this because the rest of our code only needs to execute if there is new data to process. This allows us to poll instead of generating and servicing interrupts.

One other item of note is the size of the memory buffer. We found that a buffer size of 50 was effective for a demonstration network of two sensors. However, for a full-scale network, the buffer should be significantly larger to ensure that we catch the largest number of received packets. In a noisy environment, if the network frequency is not always free, it is also desirable to increase the buffer size. This is due to the fact that random white noise on the frequency will occasionally passed to the serial port as data (since the receiver doesn’t know any better), causing the buffer to fill up more quickly. It causes no degradation in the quality of the information received, however.

Once the buffer is full, we want to check the validity of the data we received. To do this, we scan from the beginning of the buffer to the end, looking for our start frame (0xAA). If we find one, we check the next memory location for a valid sensor identification (<MAXNUMSENSORS), and we check the 4^th subsequent memory location for a stop frame (0x55). If all three of these conditions are met, we can be fairly certain that we have received a good packet. This means that the 2^nd and 3^rd bytes of the packet contain the 10-bit value that resulted from the A/D conversion in the remote microcontroller.

The 10-bit value simply represents the relative voltage of the pin, plotted linearly between the low-voltage reference (which corresponds to 0x000) and the high-voltage reference (which corresponds to 0x3ff). Our first step is to change this 10-bit value to an actual voltage with respect to the ground of the sensor. To do this, we make use of the simple linear relation [3]:

V_actual = V_relative * (V_h – V_l) / 0x3ff + V_l

We now know the voltage level output by the sensor. But this isn’t really what we want. We want to know the temperature. The MTS102 sensor is designed to output a voltage of 595 mV at a room temperature of 25°C. From the data sheet, we also know how the voltage changes with temperature. Thus we have the relation [3]:

T_ambient (°C) = 25 + [(V_actual - 595)] / [-2.265 + 0.0033(V_actual – 595)]

where V_actual must be calculated in millivolts. At this stage we have the actual ambient temperature at the sensor. We add yet another accuracy check to the process by requiring that this number be within a normal range of reasonable temperature. Note that this range is arbitrary, and can be adjusted according to the environment in which the network will be operating. We made sure that the temperature is between 10°C and 40°C.

At this point, we open our .html file, temp.html, and write our updated temperatures, as well as the markup tags. We then close the file, and begin polling the buffer for information again.

DESIGN VERIFICATION

It is necessary to test every design before one can claim that it is complete. We need to make sure that the design is able to function over its entire range of operation. In our case, this meant that we had to test and ensure the functionality of each individual component, as well as testing the functionality of the completed whole.

4.1 Sensor verification

The test on the sensor needed to accomplish one thing verify that the sensor is operating correctly. In order to do this the V_B was found and the temperature was converted to check for accuracy. The V_B is the base voltage when the MTS is first turned on this was measured five times and every time came up 595 mV on the two sensors we used. Sensors that did not accomplish this were not used. Then we compared the measured temperature of the lab to the thermostat reading of the lab. If the two were not within ±2 °C then the sensor was not used. These test allowed us to be confident in the accuracy of the temperature measurements of the sensor.

4.2 Microcontroller verification

Since the A/D conversion was so important to our design, we needed to make sure that it was working exactly as intended. As mentioned before, we averaged the result over 64 conversions to make sure that the value was accurate. By doing this we managed to achieve 8 bits of accuracy on the conversion (which means we can achieve a reading accurate to within 4 mV). When we look at only one conversion, we only get 5 bits of accuracy (which corresponds to a voltage uncertainty of 32 mV)

As one can see from Fig. 5, the average value, which results from averaging 64 conversions, is almost precisely the theoretical value over the entire range. The single run value, on the other hand, is noticeably inaccurate, and cannot be trusted to provide good data.

4.3 LINX verification

The LINX transmitters and receivers were tested using a square wave at different frequencies. According to the data sheet on the device the maximum transmission speed is 5000 bps. The rate we desired to send at is 9600 bps so we needed to be sure of the reliability of transmission at rates higher than what the specs on the device allow for.

The test to guarantee transmission was conducted by transmitting a 1 KHz square wave from the function generator and comparing the wave forms on the oscilloscope. This test was repeated with 5 KHz, 10 KHz, and 30 KHz square waves. All of the test found that the receiver was able to accurately receive the data that was being sent. This meant that the datapath would be robust operating at 9600 bps.

4.4 MAX-232 verification

In order to test the MAX-232 chip, we connected its input line directly to the serial output of the microcontroller, instead of the LINX receiver module. We then connected its output directly to the serial port of a computer. By using the serial display window provided by the assembler program, we were able to easily verify that the MAX-232 was passing data correctly formatted to the RS-232 specification.

4.5 Software verification

We also performed debugging and verification on the software running at the host computer. Our code can be divided into two well-distinct subsections. The first deals with the communication protocols necessary to talk with the serial port. The second deals with parsing, error checking and file manipulation. We wrote the code for these two parts separately, to make the task of debugging easier. We tested the design and the algorithms by inputting a wide variety of values to ensure correct processing, and then by running the system for a long period of time to verify that it was in fact working correctly. Fortunately, this was the case.

COST ANALYSIS

The project cost includes the parts that were used as well as parts that were purchased or attempted to be used but rejected in favor of other parts. This cost only reflects the development cost to the university. Parts that were considered but not purchased or used are not included in the cost analysis.

6 CONCLUSIONS

We feel that we have developed and demonstrated a feasible and relatively useful design. The system in its current implementation works as intended and provides accurate information. We have shown that our wireless datapath is robust enough to maintain solid communication even through large amounts of interference. We have also shown that our algorithms can, through repeated sampling, reduce the error inherent both in the MTS102 sensor and in the A/D conversion on the microcontroller. Consistently, our readings were within 1°C of the actual temperature, even though the sensor only provides for an accuracy of ±2°C.

We also want to note that our design, while it can be considered complete, still offers opportunities for extensibility. For instance, because of cost constraints, our current setup uses the fairly weak LINX transceiver module. We could, with no added complexity, use a chip with a longer range. This would extend the area over which a network could function, and would greatly enhance the effectiveness of the design. We could also replace our traditional power supply with a solar-powered voltaic cell. Because the remote device consumes relatively little power, this would be an effective way to increase the flexibility of the design.

In conclusion, we feel that this project was a success because it enabled us to realize an interesting, useful and functional design. It was also a success because it was fun.

WORKS CITED

[2] Dallas Semiconductor, “DS1821 programmable digital thermostat,” 20 November 1999.

[3] Motorola, “Device data sheet for MTS102,” 5 April 2000.

[4] “CMOS op-amp current source,” laboratory notes for ECE 343, Department of Electrical and Computer Engineering, University of Illinois at Urbana-Champaign, Spring 2000. http://www2.ece.uiuc.edu/~ece343/asgn4cs.html

[5] National Semiconductor, “LM134/LM234/LM334 3-terminal adjustable current sources,” DS005697, March 2000.

[6] Parallax, Inc., “BASIC Stamp programming manual 1.9,” April 2000.

[7] Motorola, “HC12 CPU12 reference manual,” rev. 1.0, April 2000.

[8] Xemics, “Low-power UHF transceiver XE1201 300-500 MHz,” February 2000.

[9] Linx Technologies, “LC series receiver module data guide,” 28 September 1999.

[10] Xilinx, “Spartan-II 2.5V family Field Programmable Gate Arrays,” DS001 (v.0.8), 14 January 2000.

[11] Xilinx, “Spartan-II FPGA family architecture,” 2000.

[12] Texas Instruments, “MAX232, MAX232I dual EIA-232 driver/receiver,” SLLS047G, August 1998.

[13] Rumsey, Lee, “How to use the LC series LINX modules,” April 2000, http://www.ece.uiuc.edu/ece345/linx.htm

[14] Blum, Christian, Serial port FAQ, 22 February 1995, http://www.ece.uiuc.edu/ece291/class-resources/serial.html

[15] Peacock, Craig, ”Interfacing the RS-232/serial port,” 28 February 2000, http://www.beyondlogic.org/serial/serial.htm