Design and implementation of a low-cost wireless network for remote control and monitoring applications

MICROPROCESSORSAND

MICROSYSTEMS ELSEVIER

Microprocessors and Microsystems 2I (1997) 79-88

Design and implementation of a low-cost wireless network for remote control and monitoring applications A.K. Salkintzis a'*, J.E. Plevridis a, C.S. Koukourlis a, C. Chamzas b aTelecommunications Laboratory, Department of Electrical & Computer Engineering, Democritus Universi~ of Thrace, P.O. Box 11, GR67100 Xanthi, Greece blmage Processing and Multimedia Laboratory, Department of Electrical & Computer Engineering, Democritus University c~fThrace, GR67100 Xanthi, Greece Received 21 June 1996; received in revised form 16 June 1997: accepted 17 June 1997

Abstract

This paper addresses the design and implementation of a wireless network, proposed as a cost-effective support platform for remote control and/or monitoring applications. With this network, one or more supervising stations may access remote equipment like PLCs, data acquisition systems, weather stations, etc., in a reliable, transparent fashion. A suitable infrastructure is described, capable of dealing with the peculiarities and contending system requirements. The paper specifies these requirements and indicates methods to fulfil them. Also, it provides insight into the network structure, to the configuration capabilities, to the model of operation, and focuses on the implementation approach. The hardware and software design is described together with a number of critical points related to wireless communication. Furthermore, a discussion on system expandability and performance is taking place and, finally, some observations are stated. The main conclusion is, that the proposed system can feature great performance under normal operating conditions, easy maintenance and supervision, fast exploitation, and affordable cost. © 1997 Elsevier Science B.V.

Keywords: Wireless networks; Node controllers; Remote control

1. Introduction

There are certainly many applications today that require access to several equipment placed in remote and hardaccess locations. A readily available support for these applications could be provided by common wireless terrestrial [1,2] and satellite networks but, usually, their employment violates the desired cost requirements. This violation is the main reason that drive the needs for developing specialpurpose, low-cost and robust infrastructures, capable of serving that kind of application. For this purpose, a number of diverse approaches have been proposed over the years and a variety of incompatible devices/systems exist in the marketplace. However, one may observe, that there are many insufficiencies associated with the low-cost systems. For example, they feature minima or unreliable link-layer facilities [3] and are usually limited to a radio modem unit. Additionally, they employ small signaling rate [4] (mainly 1200 bps), they support only one or two terminals and, usually, they require special * Corresponding author. Tel.: +30 541 79599; fax: +30 541 27264; e-mail: [email protected] 0141-9331/97/$17.00

© 1997 Elsevier Science B.V. All rights reserved

PH S 0 1 4 1 - 9 3 3 1( 9 7 ) 0 0 0 3 5 - 5

repeaters to extend the main coverage area. Furthermore, many of them permit only one master station to control and supervise the overall network [5] and, also, they provide no means for remote network configuration and management. All these drawbacks have been considered in our implementation, along with some other requirements that are briefly stated below. Cost constraints are always at the top of the list. Our approach to this requirement is the utilization of ordinary hardware (common integrated circuits and radio transceivers) and the provision of configuration/monitoring tools that aid maintenance and supervision. As will be shown, main network elements are cheap to manufacture and easy to control. Also, of primary significance--regarding operational cost and terminal availability--is the provision of standardized, common network interfaces to satisfy the demand for straightforward connection of control devices that already exist in the marketplace. This means that the network should offer industry standard interfaces (e.g. RS-232, IEEE-488, Centronics) as the method for fast employment and easy installation. These interfaces however, are associated with

80

A.K. Salkintzis et al./Microprocessors and Microsystems 21 (1997) 79-88

dummy (network unaware) terminals, so they demand extra infrastructure intelligence and, consequently, some design problems emerge. In our implementation we address these problems and describe how the network manipulates all the communication resources and protocols in order to provide a transparent service to the terminals. Another substantial issue, always associated with wireless communications, is data integrity. The network should ensure data integrity over the hostile communications medium by a properly designed data-link and physical layer. We have adopted the AX.25 [ 6 ] - - a derivative of X.25 [7] protocol, that is being used in wireline public data networks--as our data-link layer design framework. The main reason being its similarity to international communication standards and because it has been extensively used and tested by the amateur packet radio community over the past years. Another point of attention is system throughput. It might not be so evident but, unless someone is constrained to periodic temperature collection, there may be remote control applications that need a considerable throughput. Besides, the name remote control itself, embeds a wide application domain and thus, system throughput should not be neglected. In contrast with most low-cost systems available, our implementation focuses on high throughput in every design level; from modulation--demodulation, baseband processing, RF section, to interrupt timing and code programming. Finally, supervision and expandability issues are considered as a significant part in the design process, as long as the network nodes are unattended and located at hard-accessible areas. The described network architecture provides a means to remotely manipulate and configure the proper elements and to ease the network expandability in a time effective fashion. The rest of the paper is organized as follows. In the first section the general system description is presented. We refer to the model of operation and we extensively outline the main features and scope of the node controller, with emphasis on port configuration and switching capabilities. Also, a typical network arrangement is exhibited, along with a discussion on how remote access works. In the second section we examine the hardware and software details, and concentrate on some sensitive design issues. Finally, a general discussion, related to expandability and performance is given, and we provide several conclusions.

2. System description 2.1. Model o f operation

Network operation is based on the common client-server model. That is, communication with remote devices is achieved through connection requests, originated from

central stations (the clients) and addressed to the desired remote equipment (the servers). The subnetwork in the middle provides the connection service; it sets up the link, governs the transaction and clears down the link. We classify all network elements into three types: the active elements, the passive elements and the transport elements. Machines capable of producing access requests in order to connect with a remote device, are the active elements. Their main characteristic is that they feature processing capabilities and that they execute a special networking software for their communication needs (a common PC can easily meet these requirements). Passive devices on the other hand, are common equipment such as, data acquisition systems, weather stations, programmable logic controllers, printing machinery, etc., that simply wait to be called. All these are equipped with typical RS-232 serial ports and are completely unaware of the underlying subnet which means, that they carry out normal activity regardless of being connected to an active element or not. As will be shown later, communication aspects of passive elements are manipulated by the network side in a transparent way with the aid of PAD (packet assembly/disassembly) facility. Lastly, the network entities that govern the connections between the active and the passive elements are defined as transport elements. These elements (the node controllers, as referred to below), are capable of establishing virtual circuits between communication peers and manage the relevant transactions through a number of data-link procedures (defined in the data-link protocol). 2.2. The node controller

All the network philosophy is based around the node controller (NoC), the primary network building block. NoC is a transparent element as defined in the previous subsection. It interfaces directly with the terminal equipment, through standard (RS-232) serial ports, and with the wireless communication medium, through a wireless port and an external radio unit. To be effective and flexible (and to fulfil the aforementioned requirements) the device features a two-fold function. First it provides all the necessary data-link and physical layer facilities to enable remote access to the dummy terminal equipment. Its main function is to connect this equipment with remote active elements upon request. To manage the connections and to guarantee data integrity, it employs the AX.25 protocol [6]. The second function of the NoC is to act as a transparent digital repeater. The NoC is capable of forwarding any incoming AX.25 frame, that is not addressed to one of its ports, to an outbound interface according to a supervisor-maintained switch-table. These switching capabilities enable the device to function like a multiport packet switch, aiding the overall network versatility and expandability.

A.K. Salkintzis et al./Microprocessors and Microsystems 21 (1997) 79-88

SupervisingPC

Line Printer

Dummy Terminal KI

81

Table 1 A switch-tableexample Destination address

Inboundinterface

Outboundinterface

SNODEC-2 SNODEB-3 DEFAULT SNODEA-2

SNODE-1 SNODE-1 SNODE-2 SNODE-1

SNODE-2 SNODE-1 SNODE-1 SNODE-2

Node O:xlfrdl~

Radio

Fig. 1. Port configurationoverview.

2.2.1. Port configuration The node controller supports, so far, two types of interface ports: the synchronous wireless ports that interface with external radio transceivers, and the asynchronous serial ports (RS-232) that interface with external devices (either active or passive), e.g., supervising PC stations, PLCs, dummy terminals, etc. In its core configuration it has one wireless port and two asynchronous RS-232 serial ports but there are enough resources available to accommodate as many as eight additional ports. Each RS-232 port can be configured as either RAW or KISS ~. The main difference between these modes is that RAW ports do not employ any framing, while the KISS ports utilize a simple encapsulation scheme to transport AX.25 frames. The main rule that applies is that passive elements are connected to RAW ports and active elements to KISS ports. This difference is unavoidable since, as already mentioned, active elements execute their own AX.25 networking software and, thus, they should be treated differently to dummy equipment that lack any networking facilities. It is important to note that KISS ports carry AX.25 frames between the external active elements and the node controller. The configurable feature of the asynchronous ports cannot be applied to the synchronous wireless ports. This is because each wireless port is bound to specific hardware (modem, tx watchdog, scrambler, etc.) and, once built, it cannot be re-configured to another type. All the wireless ports carry only AX.25 frames employing synchronous transmission and a typical HDLC [9] (high level data-link control) framing. Figure 1 illustrates the various port configurations supported on a node controller. 2.2.2. Status~configuration server Another enhancement in the node controller is the status/ configuration server. This server provides the means for Keep It Simple-Stupid, see Ref. [8].

remote configuration and system debugging. A remote supervisor may login into the status/configuration server (again with a simple connect command) and observe node statistics such as, port utilization, I/O errors, status of currently active AX.25 connections, addresses that have been 'heard' from the wireless port(s), etc. He may also change the node's generic address, add or drop entries to/from the switch-table, switch on or off the external relay switches, etc. It is a vital maintenance and configuration tool that greatly increases system potentials.

2.2.3. Switching capabilities A unique feature of the node controller is its switching capabilities, that is, its ability to forward any incoming AX.25 frame to an outbound interface accordingly to a switch-table. This is quite essential, specially in a hostile communication environment, because it also enables the node controller to operate as a transparent digital repeater. Also, this makes feasible the multi-hop communication between an active and a passive element without any further means of communication. Additionally, it supports the forwarding of AX.25 frames between KISS and wireless ports. It should be stated here, that for routing purposes each port at a node controller is assigned an address that is the concatenation of a generic address (unique for each node) and the port's number separated by the minus sign. For example, if the generic address is SNODE the address of port 1 will be SNODE-1, of port 2 SNODE-2 z, etc. By definition, the status/configuration server is addressed as if it was port 15 (e.g. SNODE-15). All the addresses conform to the general AX.25 addressing format (with minor modifications). Switching procedures are involved whenever an AX.25 frame is received containing an unknown destination address in its header. In this case the NoC checks a preconfigured, supervisor-maintained switch-table kept in memory. If a suitable entry in the table is not found, the frame is discarded, otherwise it is forwarded to the outbound interface that is indicated by the switch-table. An example of a switch-table is shown in Table 1. Except for the special address DEFAULT that matches with everything, no other special wildcards are supported so far. According to Table 1, everything (destination is DEFAULT) 2SNODE-0 and SNODE are identical addresses.

82

A.K. Salkintzis et al./Microprocessors and Microsystems 21 (1997) 79-88

SNODEC-1 SNODEB-2

SNODED- 1

R.AW

SNODEB

L.

AX.25 SESSIONS

.,v

ONNECT SNODEB-2~ NNECT SNODEC-I II ONNECT SNODED-1 II

Fig. 2. Atypical network structure.

received from interface SNODE-2 is forwarded to interface SNODE-1 (entry 3). Also, frames to SNODEB-3, as indicated by the second entry, are echoed back to the same interface resulting to transparent repeating. 2.3. Network overview The general network structure, built around the node controller, is illustrated in Fig. 2. At the various areas of interest (where the remote devices should be located) one node controller is placed, making up a network node, i.e. a network point-of-presence that offers common serial ports as network interfaces. During network planning each node is assigned a unique node address which will be used to identify the client devices attached to its ports using the aforementioned name conventions. In the configuration shown in the Fig. 2, there are four network nodes. The SNODEA is connected to a supervising PC station through a KISS port, while the other three nodes (SNODEB, SNODEC, SNODED) are connected to various terminal devices through RAW ports. The PC station needs an address of its own (e.g. MASTER), as long as it originates and accepts standard AX.25 traffic. It is worth mentioning that there could be two or more supervising PC stations in the network and a distributed control scheme is feasible; which is another unique feature. The controlling PC can establish a connection with a client terminal device (e.g. a remote PLC) by simply issuing a properly addressed connect command. For example, to connect with the device attached on port 2 of node SNODEB a connect SNODEB-2 command is typed. SNODEB will accept the call as long as the target device

is not busy (i.e. already connected to another peer) and will reply with a connection accepted. This will result in the establishment of an AX.25 virtual circuit between the two communication endpoints. During the connect session lifetime, communication will be under the control of the two AX.25 peer functions present at the two ends; one implemented in the node controller itself and the other inside the PC networking software. The implemented link control procedures are similar to the standard LAPB (link access procedures balanced) procedures employed in the commercial X.25 [7] protocol and the reader may check Ref. [7] for a complete and comprehensive description. Either end may release the AX.25 connection by issuing a disconnect request command. Normally, the disconnect is initiated by the active element (i.e. the supervising PC station) when any transaction requirements have been satisfied. Occasionally, however, it may be initiated by the passive site, namely, the node controller, when the link is found redundant (no activity for a given configurable time). The latter is considered essential in order to prevent port hanging. Connecting with distant nodes, that are outside the normal radio range, is still manageable if the switching capabilities of the node controllers are exploited. Referring again to Fig. 2, let us suppose that SNODEC is a distant node which can directly communicate only with SNODED. Yet, this node can be easily accessed by the PC station if the 3Specifically,any AX.25 framecomingfrom interface SNODE(the wirless port) with destination address SNODEC-1 or MASTER, should be forwarded back to the same interface.

83

A.K. Salkintzis et al./Microprocessors and Microsystems 21 (1997) 79-88

Fig. 3. Hardware boards in physical arrangement.

switch-table in SNODED is properly configured3. This potential of the node controllers is quite essential; network service area is easily expanded with no extra repeaters or other support elements.

3. Implementation 3.1. Hardware design Hardware implementation is based on a modular approach with two boards, in an up-down physical arrangement, as illustrated in Fig. 3. The lower board, the data engine, is a general purpose 16-

bit core, featuring enough computing power and plenty of add-ons in a cost-effective combination. It supplies a physical layer platform ready to support the system's processing requirements. Its design is focused around a 16-bit MCU, Intel's 80C196, running at 16 Mhz. The MCU has a number of favorable aspects, such as DMA-like transfer modes, hardware and software timers, a special port, event processing capabilities, A/D conversion, watchdog timer and many other on-chip peripherals. Such characteristics have proved ideal for this application, where both communication power and control-specific facilities are essential. System memory totals 28 kbytes of usable RAM (0 wait states) and 24kbytes of ROM (1 wait state). Also, a small EEPROM has been added (see Fig. 4) to maintain

SI~IAI.1

i

:,

2il DATA ENGINE

Port-Specific

Port-Specific

I/O C O N T R O L L E R Fig. 4. The block diagram of the node controller.

°

~1

!',

84

A.K. Salkintzis et al./Microprocessors and Microsystems 21 (1997) 79-88 0

I

I

o

9600bps

-20

BT=0.3

[db]

-20

\

I

9600bps

BT=0.5

\

[db}

-60

I

~'~

-GO

-80

10 [KHzl

20

19200bps BT=0,3

-2o

-60 -80

0

10 {KHzl

0

0

Idbl

-80

\

I I

~

19200bps BT=0.5

-20

\

[db}

\

20

"\

-60

~r~__ 10 [KHzl

20

-80

0

10 [KHz]

Z0

Fig. 5. Measured baseband spectrums for various signaling rates and BT combinations.

non-volatile note-specific configuration variables. Finally, all the decoding logic, the wait-state machine, and other glue-logic are implemented by an EPLD device in order to decrease chip-count and cost. The board is made quite flexible by designing the wait-state machine to support a large range of peripherals, both fast and slow. The most critical part of the implementation is the second board, the I/O controller; Fig. 4 outlines its block diagram together with the data engine. The main purpose of the I/O controller is to materialize all the low-level communication primitives needed to support communications. In its core implementation, the I/O controller provides as many facilities as necessary to support two common serial ports (RS232) and one wireless port with a configurable signaling rate, ranging from 4800 to 38 400 bps. The main component in the I/O board is a multi-protocol communications controller (Intel's 8274), that offers two, independent and software-configurable serial communication ports. A number of operating modes are supported on each port, resulting in a board applications field and in enhanced flexibility. In our implementation, one port is treated as raw asynchronous (without any framing) and the other as synchronous HDLC. As shown in Fig. 4, the first, with minimum additional hardware (mainly RS-232 buffers/drivers), builds the second RS-232 port (the first is supported directly by the MCU), and the second drives a number of baseband processing stages to, finally, interface with an external FM radio unit. Special software treatment is applied in each RS-232 port to make it work in either RAW or KISS mode.

Lastly, a number of MCU I/O lines are exploited to drive some relay switches. These switches can be remotely controlled by logging into the node controller's status/configuration server and giving the appropriate commands. 3.1.1. The wireless port Extra hardware is connected to every wireless port in order to efficiently utilize the radio channel and to deal with the hostile characteristics of the wireless medium. As shown in Fig. 4, the first processing element after the serial controller in the transmit direction is a scrambler, which randomizes the transmitted data and, effectively, smooths the baseband power density distribution keeping it relatively constant. The scrambler also aids the decoding process at the receiver [10]. The polynomial used for scrambling and descrambling (adopted from previous successful implementations [11])is 1 + x - 1 2 + x -17. A NRZI (non-return to zero inverted) data encoder follows after the scrambler, which is aimed at preventing the appearance of long sequences of the same bit patterns in the transmitted signal. It has been verified via simulation that, even with the scrambler, a file transmission can present as many as 30 continues of 1 or 0 s (e.g. transmitting COMMAND.COM will present sequences of 21 continues of 0 s). NRZI encoder will map 0 s to signal level changes

4 Bit-stuffing mechanism employed by the multi-protcol communications controller is also related to this effect.

85

A.K. Salkintzis et al./Microprocessors and Microsystems 21 (1997) 79-88

tended environment, where every protection level is desired to safeguard expensive equipment.

KERNEL

3.2. Software architecture J

System

Queue

~..~erface~ Q~terface~

Fig. 6. The modular software architecture.

and 1 s to no level changes and will minimizes considerably these long sequences 4. The modem unit (integrated in a single-chip, the FX-589) provides standard low-pass Gaussian filtering to the digital data before final transmission, and recovers received data and clock [12]. Its main feature is that it readily supports data rates up to 40 kbps; a rate that is not easily found in other low-cost systems. The utilized BT factor (bandwidth/ data rate) of the Gaussian filter can be set to either 0.5 or 0.3. One must bear in mind the impact of this parameter to the overall transmission characteristics, To illustrate this, Fig. 5 shows the measured baseband spectra for various signaling rates and BT combinations. As can be observed, smaller BT looks more attractive considering the lower bandwidth requirements but, as was expected, it results in increased intersymbol interference and, thus, to increased bit error rate. So, unless enough signal power is available, a large BT should be selected. And, of course, all network wireless ports must utilize a common BT factor, if the maximum performance is to be gained. Finally, the modem supplies a digital signal (S/N), which is based on the zero-crossing statistics of the received baseband, and this signal is exploited to drive the DCD (data carrier detect) state machine. This state machine provides a clear indication to the serial controller of whether there are data or noise present at the input. It should be pointed out, that defective operation of the DCD state machine and/or the associated circuit is a major source of overall performance degradation; mainly because channel activity would not be correctly tracked down and excessive collisions and other side effects will occur. The tx watchdog timer shown in Fig. 4, provides a hardware protection of the external radio unit in case of software failure. It will constrain the maximum key-up time of the transmitter to approximately 20 s. This is quite essential, because node controllers are supposed to operate in an unat-

The operating system is basically divided into two parts that operate independently and in parallel; the kernel and the device drivers. Fig. 6 shows the software architecture model and outlines these components and their interaction. A device driver is the lowest-level service entity assigned to an interface which actually maps incoming traffic to kernel work. It controls and synchronizes the I/O functions of the interface in a hardware-dependent fashion. Drivers packetize input data streams, employing interface-specific mechanisms, and enqueue the generated packets to the system queue. So, from one point of view, all device drivers are packet sources that feed the system queue with randomlength packets at random instances. The system queue itself, acts as a deposit pool that

ii ii

~.~c~ ~

~-!~ceL (a)

KERNI

Fig. 7. (a) Device driver's structure, (b) Kernel's structure.

86

A.K. Salkintzis et al./Microprocessors and Microsystems 21 (1997) 79-88

smooths input traffic peaks and establishes a communication pipe between the low- and high-level processing elements. The server process for this queue is the kernel layer, shown at the top of Fig. 6. The kernel, which is implemented in the main program loop, continuously polls the system queue, dequeues incoming packets and processes them through the AX.25 procedures. Outgoing traffic, that is generated as response to this input packet processing, is straight forwarded to the proper device driver for transmission. Device driver internals are shown in Fig. 7(a). Note that the two parallel branches (Tx-Rx) are completely independent, with one interrupt handler assigned to each one. The Tx ring buffer is filled on every transmission request by the kernel, while the Rx ring buffer is filled directly by the associated interrupt handler upon data arrival. Every buffer filling rises an appropriate flag (RxEVENT, RXEVENT) in the interface control structure in order to indicate that the buffer has pending data and needs service. The system timer, in the middle of Fig. 7(a), is activated every 65 ms and, among other housekeeping tasks, seeks for interfaces that need to be serviced (i.e. have the appropriate flags on). If one is found, an indirect call is made to a preconfigured queue server. This leads to buffer service and I/O data processing: the Tx queue server starts actual transmis1 5.00v

~ 500'~

I 5.oov

2 5oo'~

...

• , . • .~

, ....

, ....

, ....

i ........................ FIxC = 9600Hz,

sion on the interface, while the Rx queue server processes incoming data according to the interface operating mode (RAW, KISS, HDLC). Kernel operation on the other hand, is independent of the underlying hardware. As depicted in Fig. 7(b), a despooler in the kernel space continuously polls (in the main loop) the system queue and dequeues the incoming packets. It then forwards the packets to the appropriate receiver based on the mode of the interface where they came from. Packets which came from the wireless interface are sent directly to the AX.25 receiver, while KISS and RAW receivers handle packets from KISS and RAW asynchronous ports, respectively. Note that KISS receiver actually calls AX.25 receiver because both KISS and wireless ports carry AX.25 frames. LAPB engine (see Fig. 7(b)), implements the main part of the AX.25 protocol. It receives input from either the AX.25 or the RAW receiver and outputs transmissions to the proper device driver. Note also, that the AX.25 receiver can directly call a device driver for transmission bypassing LAPB control; this case corresponds to switching.

4. Performance considerations and discussion It has been verified in practice that the most sensitive and ,~--o.oos

50.0~_..~,./

,r-o.oos

2o.o~/

T" ....

, ....

, ....

Sn9].~:l STOP

, ....

, ....

Sn91~1 STOP

T, . . . . . . . . . . . . . . . . . , . . . . . . .

1

Fig. 8. Measured eye patterns at the output of FM discriminatorfor 4800 and 9600 bps signalingrates and BT = 0.5.

A.K. Salkintzis et al./Microprocessors and Microsystems 21 (1997) 79-88

performance-critical part of the design is the one(s) related to wireless communication. Initial experiments, before numerous corrections and fine-tuning revealed that, even with high signaling rates, the communication can be very disappointing and unstable. One thing that must be carefully designed and tuned is the wireless port of the node controllers. The hardware itself, provides the means for bit error rate testing, so the tuning of any wireless port has been facilitated. A satisfactory eye pattern should be obtained for ensuring minimum retransmissions and best performance. This, however, appears not to be an easy task with common voice-graded FM transceivers, because radio's band-limiting characteristics quickly deteriorate communication as the signaling rate is increased. Fig. 8 shows the achieved eye diagrams at the output of the FM discriminator (and after some filtering) in our implementation. Obviously, one should try to gain the best eye pattern that can be achieved with the utilized radio transceivers. Another thing that can easily lead to unstable behavior is a bad multiaccess scheme. Experiments have shown that the channel access protocol must be practical and robust enough in order to minimize channel collisions and to provide fast collision recovery, especially when many supervising stations are used. Our implementation employs a variation of the slotted p-persistent CSMA protocol, initially proposed by Takagi and Kleinrock [13]. Every node controller that has pending information may initiate transmission only at a slot edge with probability p. For this scheme to be effective, all the stations that compete for channel resources should, somehow, attain synchronization so as to have common slot timing. The important thing, however, is that restrict synchronization is not so crucial in our application under usual operating conditions, because there is no severe channel contention (that is because transactions are mastered by one central station and are formed by a sequenced command-response pair). The last issue that should be mentioned is the provided means for rapid expandability. Additional ports may be easily appended to each node controller to support further client devices (see the shaded region in Fig. 4). We only need to interface more multi-protocol communication controllers with the data engine and reproduce some interface logic. Expandability is straightforward since special consideration has been paid; hardware maintains reserved address space and decoding logic in order to host new serial controllers and, additionally, enough support resources are available such as, interrupt lines, software timers, buffer space, etc. Under these conditions, hardware upgrading involves only I/O controller board reshaping and no changes to the data engine itself. Firmware upgrading will also be minimal due to the high degree of multiplexing employed. That is, new ports will share the same support functions with the old ports as long as they have an identical structure. No modifications are necessary in the kernel.

87

5. Conclusions The basic aim of this project was to evaluate the feasibility of using off-the-shelf microcontrollers and other relevant hardware (serial controllers, radio units, etc.) in providing a low-cost and robust infrastructure for remote control and monitoring applications. A common client-server architecture has been implemented under which, one or more supervising stations (mostly PCs) can be utilized to access the distributed remote terminals. Mainly the software has been proven very reliable and, once the underlying hardware operates effectively (with an acceptable bit error rate), the overall performance is excellent. From normal-usage measurements that have been taken, it becomes evident that kernel utilization is fairly low, even at high traffic instances (with two serial ports and one wireless--all at 9600 bps), so there is plenty of processing power to take advantage of. However, node controllers have not yet been pushed hard enough to find their ultimate performance and practical total capacity. This is a vital direction to move towards in order to discover their maximum, usable operating point and to guarantee network reliability. The most critical part of the design is shown to be the wireless communication, firstly, because remote equipment may have to be installed at 'difficult' locations and, secondly, because of the constraint to employ low-cost, common, voice-graded FM transceivers. With the current FM transceivers, up to 9600 bps signaling rates have been achieved with encouraging results after proper data filtering and proper frequency deviation. However, the actual rate can become as high as 40 kbps if suitable transceivers are used (this will ramp up total cost). The final note is that the resulting network does not need any special equipment. Remotely controlled terminals are directly connected to serial ports and supervising stations can be common, low-cost PCs running an applicationspecific software. Also, note controllers are low-cost communication equipment and ensure easy maintenance, efficiency, quick expandability and robustness.

Acknowledgements This project was supported by the 92SYN 121 research program funded by the General Secretariat of Research and Technology of Greece and MARAK Electronics Ltd.

References l 1] M. Mouly, M.-B. Paulet, The GSM Systemfor Mobile Communications, France. 1992. [2] MOBITEXInterfaceSpecification,RAM Mobile Data. [3] The X6200 radio modem, Warwick Industrial Electronics Ltd., the Manore Aston Flamville, Leicestershire. [4] RMI200 Radio Modem-System Overview, Radio Data technology

A.K. Salkintzis et al./Microprocessors and Microsystems 21 (1997) 79-88

88

[5]

[6] [7]

[8]

[9]

[10] [11] [12] [13]

Limited, 10 Taber Place Crittal Road, Witham, Essex CM8 3YP, England, Sept. 1992. VersaNet Radio Data Network--Protocol Information, Radio Data Technology Limited, 10 Taber Place Crittal Road, Witham, Essex CM8 3YP, England, Sept. 1992. T.L. Fox, AX.25 Amateur Packet Radio Link-Layer Protocol, available from ARRL, Newington, CT 06111, USA, 1984. ITU-T X.25 recommendation, Interface between Data Terminal Equipment (DTE) and Data Circuit-Terminating Equipment (DCE) for Terminals Operating in the Packet mode and connected to Public Data Networks by dedicated circuit, available from ITU-T, Place des Nations 1121, Geneva 20, Switzerland. M. Chepponis, P. Karn, The KISS TNC: A simple Host-to-TNC communications, ARRL Sixth Computer Networking Conference, Aug. 1987, pp. 38-43. ISO 3309 recommendation, Data communications--High-level data link control procedures--Frame structure, available from ISO, 1 rue de Varembe, CH-1211 Geneva, Switzerland. D.A. Heathertington, A 56 Kilobaud RF Modem, ARRL Sixth Computer Networking Conference, Aug. 1987, pp. 68-75. J. Miller, 9600 Baud Packet Radio Modem Design, ARRL Seventh Computer Networking Conference, Oct. 1988, pp. 135-140. FX-589 GMSK Application Notes, CML semiconductor products, Mar. 1995. H. Takagi, K. Kleinrock, Throughput Analysis for Persistent CSMA Systems. IEEE Trans. Commun., COM-33 (7) (July 1985).

.............

Apostolis K. Salkintzis was born in Heraklion, Greece, in 1967. He received an Electrical Engineering Diploma from the Democritus University of Thrace, Xanthi, Greece, in October 199. He has recently finished his Ph.D. thesis and he is currently doing his military service. Also, he works on various research projects by the Democritus University, Department of Electrical and Computer Engineering. His primary research interests are in the area of digital communication systems and networks and, specifically, in power saving protocols for wireless data networks', dynamic transmission power control, error-correction coding, adaptive channel equalization, and mobile channel modeling. He is a student member of the 1EEE and a member of the Technical Chamber of Greece. His e-mail address is: [email protected].

loannis E. Plevridis was born in Heraklion, Crete, in 1971 and received a Diploma Degree from the Department of Electrical and Computer Engineering, Democritus University of Thrace, Greece, in 1994. He is currently a Ph.D. candidate in the Department of Electrical and Computer Engineering, Democritus University of Thrace, Greece. His research interests are in digital synchronization in telecommunications systems, digital PLLs, modulators and demodulators. He is a member of the Technical Chamber of Greece (TEE). His e-mail address is: jplevri @demokritos.cc.duth, g r.

Christos S. Koukourlis was born in Kavala, Greece, on August 13, 1957. He received an Electrical Engineering Diploma in 1981 and a Ph.D. degree in Electrical Engineering in 1990 both from the Democritus University of Thrace, Xanthi, Greece. From 1981 to 1990 he was serving as a research assistant in the Democritus University of Thrace, Electrical Engineering department and from 1990 to 1993 as a lecturer in the Telecommunications Systems laboratory of the same department. From 1994 he has served as an assistant professor in the same department. He is currently working on digital modem design. His research interests also include direct digital synthesis (DDS) methods and electrical impedance tomography (E1T) and the design of space instruments such as charged particle detectors and counters. Dr. Koukourlis is a member of the IEEE and Technical Chamber of Greece. He is married, has two children and lives in Xanthi, Greece. His e-mail address is: [email protected], duth.gr.

Christodoulos Chamzas was born in Komotini, Greece. He received a Diploma Degree in Electrical and Mechanical Engineering from the National technical University of Athens, Athens, Greece, in 1974 and M.S. and Ph.D. degrees in Electrical Engineering in 1975 and 1979 from the Polytechnic Institute of New York, Farmingdale. From 1979 to 1982 Dr. Chamzas was an Assistant Professor with the Department of Electrical Engineering at Polytechnic Institute of New York. In September 1982 he joined AT&T Bell Laboratories, Holmdel, NJ, where he was a member of the Visual Communications Research Department until 1990. Since September 1990 he has been a member of the Faculty of the Electrical Engineering Department at Democritus University of Thrace, where he is a Director of the Electric Circuits Analysis Lab. He has been a major player in the definition, design and implementation of the CCITT/ISO (JBIG, JPEG, etc), standards for coding, storage and retrieval of images (color and bilevel) an area where he holds six international patents. In 1985-86, he was a visiting professor with the Department of Computer Science at the University of Crete, Heraklion, Greece. His primary interests are in digital signal processing, image coding multimedia and communications systems. He is currently interested in the implementation of multimedia image data base algorithms either with fast software or with VLSI design. Dr. Chamzas is a member of the Technical Chamber of Greece, Sigma Xi, an Editor in the 1EEE Transactions of Communications and a Senior Member of IEEE. His" e-mail address is: chamzas @ee.duth.gr.