TELEMETRY AND TELECONTROL OVER TETRA NETWORK
Miha Smolnikar, Andrej Hrovat, Mihael Mohorčič, Igor Ozimek, Tine Celcer and Gorazd Kandus
Institut "Jozef Stefan", Odsek za komunikacijske sisteme, Ljubljana, Slovenija
Key words: Telemetry, Telecontrol, Data Logging, TETRA, PIC microcontroller
Abstract: Geographically distributed systems performing different functions in diverse operational conditions call for interconnection of their components and efficient and reliable remote management using telemetry and telecontrol functionalities in which data and control messages are exchanged. In this paper we present a generic architecture of telemetry and telecontrol systems consisting of a control centre and remote units. We have developed a representative test application comprising telemetry and telecontrol functionalities, making use of the TETRA (TErrestrial Trunked RAdio) network as a communication and interconnection platform. In particular the test application enables temperature at the microcontroller based remote unit to be monitored from the control centre and triggering of a remote alarm. A modular approach enables the remote unit to be connected to various types of sensors and appliances, thus satisfying the diverse needs of applications. The designed platform and the representative test application have been validated using a pilot TETRA network for remote temperature monitoring and public alarm triggering.
Daljinsko merjenje in upravljanje preko omrežja TETRA
Kjučne besede: daljinsko merjenje (telemetrija), daljinsko upravljanje, beleženje podatkov, TETRA, PIC mikrokrmilnik
Izvleček: Prostorsko porazdeljeni sistemi, ki v raznovrstnih pogojih izvajajo različne funkcije, zahtevajo medsebojno povezavo posameznih komponent ter učinkovito in zanesljivo upravljanje s pomočjo funkcionalnosti daljinskega merjenja in upravljanja za izmenjavo podatkovnih in nadzornih sporočil. V tem prispevku je predstavljena splošna arhitektura sistema za daljinsko merjenje in upravljanje, ki vsebuje nadzorni center in oddaljene enote. Prikazana je reprezentativna testna aplikacija, ki združuje funkcionalnosti daljinskega merjenja in upravljanja z omrežjem TETRA (TErrestrial Trunked Radio - prizemni snopovni radio) kot komunikacijsko platformo za medsebojno povezovanje. Testna aplikacija omogoča nadzor temperature na oddaljeni enoti iz nadzornega centra ter proženje oddaljenega alarma. Modularna zgradba oddaljene enote zagotovlja možnost povezovanja z različnimi tipi senzorjev in naprav, s čimer je omogočena uporaba v vrsti različnih aplikacij. Zasnovana platforma in reprezentativna testna aplikacija sta bili potrjeni z uporabo pilotskega omrežja TETRA za oddaljen nadzor temperature in proženje javnega alarma.
1. Introduction
Many applications in consumer and industrial sectors are becoming extensively distributed over a wide geographical region with the need to be monitored and/or controlled from a centrally located supervision point. Some examples include remote monitoring and metering in gas, electric or water billing systems; remote control in building access allowance systems, security and alarm systems, and a variety of healthcare applications. Increasingly important applications, considered in this paper, are systems used in nation-wide protection against natural and man-made disasters, crisis management and disaster relief. Such systems are geographically wide-spread and require extensive infrastructure. Traditionally, the interconnection of remote units has been established using leased lines or other dedicated communication channels, which leads to expensive solutions that are difficult if not impossible to implement in geographically isolated regions. Such systems need to withstand the consequences of various large-scale disasters such as earthquakes or floods, yet in such circumstances wired communication links can easily be broken down. Wireless solutions therefore appear to have a clear advantage for interconnecting a distributed system's components. Different wireless infrastructures have traditionally been used in this context for different services (voice and data), all aimed at assuring reliable and long-range communications. A typical example is depicted in Figure 1, with two different analog radio systems used for voice
communication, a specialised radio network used to control and supervise the public sound alarm system, and another radio network used for the paging system.
Fig. 1: Traditional wireiess infrastructure
With the introduction of Professional Mobile Radio (PMR) systems, which are wireless communication systems designed for dedicated groups of users in specific organizations (e.g. police, army, fire brigades), it has become possible to use a single communication infrastructure for a range of data and voice services. Besides some proprie-
tary solutions, there are two prevailing digital PMR systems: the ETSI standard TETRA (TErrestrial Trunked RAdio) /1/ and the APCO Project 25 /2/. They all offer unified, reliable and secure voice and data communications, simplifying communication infrastructure, its management and maintenance, thus providing a reliable and robust wireless infrastructure for telemetry and telecontrol applications required in crisis management and disaster relief situations.
In general, telemetry and telecontrol systems comprise a set of remote units connected to a control centre using wired or wireless communication links. This paper is focused on telemetry and telecontrol systems based on a wireless network, with the emphasis on their design phase. As an example we have developed a test application for measuring and monitoring temperature at a remote unit and for triggering public alarms. It consists of a purposely designed control centre application and of a microcontroller-based remote unit. The latter has been designed with the idea of developing a modular hardware system whose components could be reused in a host of telemetry and/or telecontrol applications with the minimum number of modifications to the original design, although it is in general impossible to implement a generic platform for all applications.
2. Telemetry and Telecontrol
Telemetry and telecontrol are communication processes that can be defined as follows:
-	Telemetry is a process by which automatic measurements and/or other data are collected and processed at a remote object and transmitted to a receiving station for monitoring, analysis and recording.
-	Telecontrol is the process of remotely controlling the operation of a distant object's appliances from a control station.
The use of telemetry and telecontrol functionalities has proved useful for a variety of monitoring and control applications in systems distributed over wide geographical areas. They are used to couple remote site sensors (e.g. sensing devices for temperature, pressure, humidity, sound, light intensity, current, voltage, etc.) and remote site appliances (e.g. relays, motors, valves, pumps, lights, alarms) with the equipment controlling the operation of a process. A control centre and remote units are thus the basic components of any telemetry or telecontrol system. Their interconnection can be done using wired or wireless communication links. In either case a typical telemetry or telecontrol system /3/ includes three basic procedures:
-	Remote site data acquisition - a process in a telemetry system where a data stream is sampled and the required parameters are measured, and a process in a telecontrol system where an action on a remote site appliance is executed.
-	Data transmission - deals with data packaging and transmission in a communication process between the control centre and a remote unit.
-	Control centre data analysis - deals with the analysis of data received from remote units in telemetry systems, and with the generation of control commands to be sent to remote units in telecontrol systems.
The telemetry and telecontrol concepts both assume the existence of two way communication in which the systems are trying to communicate using the shortest possible messages, with the interval between them being as long as possible. By this the power consumption of typically battery powered remote units is minimized. Data processing is typically handled by a dedicated application in the control centre, which leads to less complicated and consequently cheaper remote units.
The requirements regarding the importance and the volume of transmitted information in telemetry and telecontrol systems are opposite. In the case of telemetry messages carrying meaningful information are travelling from remote units to the control centre, while messages travelling in the opposite direction are required just for the proper operation of a communication protocol (e.g. request and confirmation messages). In the case of telecontrol, the inverse is the case, i.e. meaningful messages are sent from control centre to the remote units with acknowledgements flowing in the opposite direction. Considering these complementary requirements of telemetry and telecontrol systems it is advantageous to combine both functionalities in a complete distributed automation system, which would offer the monitoring and control capabilities of a remote unit, both from a control centre.
Regardless of wired or wireless communication infrastructure, telemetry and telecontrol systems require autonomous operating scenarios in case the communication link between a control centre and a particular remote unit is broken. This causes the remote units having to be more complex in terms of additional hardware and/or signal processing capabilities. Typically the system's autonomous operation exploits data logging techniques. Data logging is a process of gathering data values generated by a particular system for the purposes of later analysis and/or archiving. The data logger may be described as a device recording a time-sequence of events. In the case of upgrading the telemetry remote units by a data-logging capability, the operation of remote units can be extended to enable a reciprocal state restoration within a control centre, after the communication link is re-established. For the remote unit to offer data-logging functionalities it must additionally contain at least a non-volatile memory bank as a data storage device, with a real-time clock source used to time-stamp the recorded data, thus keeping the track of time and calendar date. Data loggers typically operate in one of two basic modes. The prevalent one is the time-based mode, where in which a data-logger is scheduled to obtain data readings at a given time interval. The other operating mode
is the event-driven mode, in which data-logging is triggered by an external event. Different modes combining these two basic principles are also widely used.
2.1	Applications
Considering the range of sensors that can be used in telemetry systems and the range of appliances suitable to be remotely controlled in telecontrol systems, there is a vast range of applications in which telemetry and/or telecontrol functionalities could be exploited. Currently emerging applications can be classified under consumer, industrial, environmental, and health-care areas.
Typical consumer and industrial applications include burglar alarms, door gate openers, heating, ventilation and air conditioning systems, automated meter reading systems used in consumer billing to take periodic measurements of utility meters, traffic measurement and control systems, etc. Applications of environmental care include weather and seismic monitoring, remote fire supervision, flood prevention, and irrigation control. Recently, telemetry and telecontrol systems are being introduced extensively in healthcare applications, allowing patients that require continuous monitoring to go about their daily business rather than being confined in bed. Heart related requirements, such as electrocardiograms, or blood glucose monitoring in diabetic individuals fall into this category. The limitations of a particular system usually arise from the limitations of the available telecommunication infrastructure, which determine constraints such as the amount of data transmitted per time unit, transmission delay, service interruptions, etc. /4/.
A range of telemetry and telecontrol applications also exploit the data-logging functionalities. The latter are employed in many industrial and environmental applications to enable real-time logging of critical or representative parameters (e.g. temperature, wind speed, barometric pressure). In the field of health-care, data loggers are used to monitor a patient's physiological condition which is then periodically communicated to the medical stuff.
2.2	Test Application
The representative test application described in this paper exploits both the telemetry and telecontrol capabilities with the wireless infrastructure used for the transmission of measurement and control data between a control centre and remote units equipped with external sensors. The remote units also offer an autonomous operation for periods lacking wireless network connection. In such cases a default operation scenario comes into play, with events being time-stamped and logged to a Compact Flash (CF) storage device for later transmission to the control centre. The general system architecture, consisting of control centre, TETRA wireless network and remote units, is depicted in Figure 2.
Fig. 2: The wireless telemetry and telecontrol system
The intention of the test application was to demonstrate and validate the following functionalities:
-	Transmission of temperature measurement data from a remote unit over a wireless network to the control centre where this data is analysed and stored.
-	Sending warning messages from the control centre to remote units where a public alarm system is activated or deactivated.
-	Autonomous operation of remote units when remote unit has no network connectivity; the scheduled temperature measurements are stored to a CF storage device for later restoration at the control centre, and public alarms are triggered using the default operation scenario threshold temperature values.
In our system the remote unit application has been structured into two parts, each covering one of the operating modes. The normal operating mode is used whenever the remote unit's TETRA modem is connected to the network, while the autonomous operating mode is used to assure proper operation of the remote unit's basic functions in the absence of connection and to log actions taken for subsequent restoration by the control centre application.
3. Wireless interconnection
infrastructure based on the TETRA system
In order to validate the operation of a test application in a robust networking environment suitable for disaster relief conditions, we selected a TETRA network /1, 5, 6/ for the wireless interconnection of the distributed elements. TETRA is an open ETSI standard for digital trunked mobile radio for professional use, featuring fast call setup, group calls, call priorities, direct mode operation, etc. It was developed to meet the needs of the most demanding professional radio users like police forces, fire brigades and rescue teams, army, as well as commercial organizations (power distribution systems, transport systems, etc.)
PMR systems in Europe based on the TETRA standard use RF channels 25 kHz wide, with carrier frequencies around 400 MHz. Although TETRA supports direct communication between mobile stations (as an emergency mode, when no base station is available), normal communication
runs between a base station and a mobile station. TETRA provides duplex communication using FDD (Frequency Division Duplex), with adjacent upstream and downstream transmission bands. By using TDMA (Time Division Multiple Access) with four time slots, each RF carrier provides four communication channels for secure digital voice or data transmission. One communication channel on each base station is reserved for system use as a TETRA control channel.
For data transmission, TETRA provides three different data transmission services:
-	Short Data Service (SDS)
-	Circuit Mode Data
-	Packet Mode Data
SDS provides point-to-point and point to multi-point connectivity for sending short data messages, using the TETRA control channel. Messages can be either status messages with predefined meanings, or user data messages carrying arbitrary user-defined data. They can be of four different types: types 1, 2 and 3 are 2, 4 and 8 bytes long messages respectively, while type 4 are variable-length messages up to 256 bytes long, typically used for text messages. Short Data Service - Transport Layer (SDS-TL) is an extension of SDS type 4, which ensures a reliable transport using connection-oriented communication with handshaking. SDS is suitable for various low data rate applications including telemetry and telecontrol. Its advantage is simplicity of use without the need to implement a complicated communication protocol (e.g. IP protocol).
The Circuit Mode Data service establishes a fixed dedicated data communication channel between a mobile unit and a base station, while the Packet Mode Data service constitutes a fully featured packet data service, which is normally used for IP traffic. It supports packet data transmission in either connection-oriented or connection-less modes. The data transfer rate depends on the selected level of error protection as shown in Table I.
Tablel: Data communication speed in TETRA system (one time slot)
Error protection level	Transmission speed [kb/s]
No protection	7,2
Standard protection	4,8
High protection	2,4
Taking into account the communication protocol overhead, the achievable net (application level) bit rate is about 3 kbit/ s for the standard protection level. The communication speed can be increased by combining up to four time slots.
To connect data equipment to TETRA terminal (mobile radio stations), TETRA defines a standard interface PEI (Peripheral Equipment Interface), which uses standard asynchronous serial data communication (RS-232) and AT commands.
The pilot TETRA network used in our test application consisted of a digital exchange (DXT), two base stations (TBS), and two mobile radio stations, one in the control centre and the other in remote unit (see Figure 2). The communication terminal at the remote unit served as a TETRA modem to establish a link between the TETRA network and the remote unit, as well as a GPS (Global Positioning System) receiver. Using TETRA PEI interface it was connected to a microcontroller via a serial RS-232 line. Microcontroller received commands from the control centre over the TETRA network, and transmitted measurement data from the sensor to the control centre. SDS type 4 data service, being simple to use and providing sufficient transmission capacity for our test application, was used for the transmission of control and data messages.
4. Control Centre Application
The control centre application is designed to define and control remote units operation, to collect, store and analyze measured data, and to send additional settings and requests to remote units which are dynamically allocated to the control centre active set.
The control centre is composed of a TETRA modem which is connected on one side to the TETRA wireless network and on the other via a wired RS-232 interface to a personal computer running a dedicated telemetry control centre application. As it can be seen in Figure 3, the control centre application is divided into two main parts, the Remote Unit Control and the Data Analysis part.
Fig. 3: User interface of the control centre application
When the application is started, the username and password must be entered, restricting the access to the application and consequently to the remote units' settings. Before using the application, the MS Access database of the remote units must be populated. This can be done directly via the MS Access program or using the 'Add/Remove' control in the 'Communication' menu of the control centre application.
In order to communicate with remote units the control centre computer must be connected to the TETRA network via the TETRA modem. The communication settings accessible through the 'Communication' menu must be defined according to the TETRA modem set up, and the RS-232 connection between the modem and the computer must be established. If the control centre is connected to the network (shown in the status bar) and the selected remote unit is accessible, its settings can be modified in terms of control/action type and local storage enabling. In order to check the availability of any remote unit found in the MS Access database the menu bar also provides a command 'Check unit'.
4.1	Data Analysis
The upper part of the application user interface is designed for analysing the measured data and triggered events. It enables tabular representation of the stored measured temperatures and actions with the belonging time stamps. Temperature variation of the selected sensor, stored in the table, can be also presented graphically. Charted graphs can be stored independently or they can be included in the reports designed in the same application.
The application also enables acquiring data from the remote unit which, in the absence of network connectivity, switches to autonomous operation mode. In this case the measured data are stored locally and analyzed by control centre application after establishing TETRA connectivity and restoring data from local storage on the remote unit.
4.2	Remote Unit Control
The 'Remote Unit Control' part of the application is composed of four sections. It helps the user to easily and clearly control and manage implemented test applications, namely temperature monitoring and alarm triggering.
The temperature monitoring is divided into periodic and on-demand execution. In both cases the alarm can be triggered for the predefined time if the temperature threshold defined in the 'Unit Settings' window is exceeded. In the case of periodic temperature measurements the remote units must be added to the active set. This can be done using the 'Remote units' button which opens an 'Add Remote Units' window with the list of the available units. For each selected remote unit the predefined parameters can be shown. The measured data and triggered events can be saved in a predefined text file.
On-demand temperature measurement and alarm control can be triggered using 'Send req. to^' button. It opens an additional window where the type of request is selected (alarm triggering or temperature monitoring), reachable remote units are shown, and the user selected remote units and their responses are noted. All the actions can be written to the user defined log file. The graphical control part is designed for real time graphical representation of the temperature variation on the selected sensor. To be able
to present this kind of data the periodic temperature monitoring must be started. The available sensors are members of the remote unit active set.
5. Remote Unit
The core of the remote unit is built around a microcontroller providing sufficient processing capability for the autonomous operation, as well as various communication and adapter interfaces for the connection of communication, sensor, actuator and storage peripherals.
In the design of the electronic system representing the core of each remote unit, the driving idea was to implement a generic modular hardware platform consisting of reusable components that would form the basis for the development of telemetry and/or telecontrol systems. The core has to be simple, relatively small in size, and economical in cost and energy consumption. At the same time it also has to be powerful enough to form the basis of an autonomous system, and highly flexible in terms of being able to adapt to a great variety of applications by making minimal modifications. The success of the platform is thus determined by its flexibility, capacity and overall price.
5.1 Hardware Part
For the remote unit's core to be an open system, offering reconfiguration at a software level, the electronic circuit is based on a microcontroller, with the MPIC development system /7/ being used to develop and verify the test application in our case. However, in the design of an end-market product it would make sense to implement the hardware in such a way that its final function would be defined by attaching application specific add-on modules to the core unit. Together with the proper software configuration the system as a whole would then offer adaptability to a variety of environments being monitored and/or controlled.
The hardware part of the remote unit, depicted in Figure 4, consists of the core and the test application specific hardware. The core hardware comprises only the minimum requisites forming a working system, yet undetermined for a specific application. The basic components forming the core are power supply, a basic microcontroller circuit, and a communication terminal. The power supply in our case was a standard 5 V voltage regulator built around an LM7805 chip. A Microchip PIC16F877A microcontroller /8/ has been used as the heart of the core unit. It is an 8bit RISC (Reduced Instruction Set Computer) architecture microcontroller operating at a clock input of up to 20 MHz with 8 K of 14-bit FLASH program memory, 368 bytes of RAM data memory and 256 bytes of EEPROM data memory. The package is 40-pin with three 8-bit, one 6-bit, and one 3-bit input/output (I/O) ports. The external peripherals available on these ports include: three timers (8- and 16-bit), two 16-bit capture/compare/PWM (Pulse Width Modulation) modules, 8-channel 10-bit AD (Analog-to-Dig-
ital) converter, analog comparator module, I2C (Inter-Integrated Circuit), SPI (Serial Peripheral Interface), and US-ART (Universal Synchronous Asynchronous Receiver Transmitter) communication interfaces. The large number of I/ O peripherals makes this microcontroller suitable for a great number of applications, which is especially important due to the fact that we are designing a unified core. Otherwise a more appropriate microcontroller, best fulfilling the performance/price ratio, could be selected for a specific application.
Fig. 4:
Block scheme of the implemented remote unit's hardware
A EADS THR880i /9/ communication terminal, comprising TETRA modem and GPS receiver, has been used for the purposes of test application. It communicates with the microcontroller at a speed of 9600 bps using a standard RS-232 protocol. A MAX232 chip has been used to adapt the voltage levels of the RS-232 interface to the TTL levels. The communication interface occupies only two of the microcontroller's pins, i.e. the Tx and Rx of the USART interface available through port C. In our test application a standard 8 MHz crystal oscillator was used, while a reset circuit was driven by pushing a reset key.
To this end the core hardware has been described that is invariable in all remote units. Besides being the main data processing component it is also used to exchange AT messages with the communication terminal, and to set or read basic telemetry/telecontrol remote unit signals, i.e. converting analog input signals by built-in AD converters or managing each port's TTL digital signals (0 and 5 V levels). In the case of more complex signals, an application specific circuit has to be used, with the core circuit providing the proper communication interface. In our test application, shown in Figure 5, the following circuits have been designed:
-	Temperature sensing circuit based on a Dallas DS1820 /10/ temperature sensor.
-	Alarming device to visualize triggered alarms.
-	Real-time clock (RTC) module for time-stamping measurement records.
-	Compact Flash (CF) data storage device interface.
Fig. 5: Photo of the designed remote unit test application
The temperature sensor performs periodic or on-demand temperature measurements which are either reported to the control centre or stored in a log file. Based on these measurements alarms are triggered when a defined temperature threshold value is exceeded. The temperature sensor used measures temperatures in the range from -55 °C to +125 °C, where measurements between -10 °C and +85 °C are precise to a 0.5 °C. Communication is carried out using a 1-wire protocol, thus occupying only one of the microcontroller's pins. In our case the RC0 at the port C was used.
Alarming signals were in our test application represented simply by turning on and off the LEDs on pins RC1 and RC2 of port C. The key connected to the RC5 was used to manually turn the remote unit's alarm off and reset the process to a new iteration of temperature measurement and alarm triggering.
The real-time clock module is one of two components included in the system for the purpose of autonomous operation. It is based on a Philips PCF8583 integrated circuit / 11/, which is the clock/calendar circuit that was used to time-stamp temperature measurements and alarm logs stored in a log file during the autonomous operation mode, i.e. operation in the period without TETRA network connectivity. The circuit uses a two-line bidirectional I2C bus as a communication interface and is therefore connected to the microcontroller using the pins SCL (Serial CLock) and SDA (Serial DAta), located at RC3 and RC4 of the port C. The circuit additionally comprises a local oscillator and a battery backup.
The CF storage device is the second component included for the support of the autonomous operation, used to store logs of taken activities. It is connected to the microcontroller occupying two of its ports, with the control lines connected to port B and the data lines connected to port D.
5.2 Software Part
The software for the remote unit's microcontroller is of particular importance for the overall system performance, as the microcontroller has to utilize both the computation and
Fig. 6:
Flow chart of the initialisation and normal operation mode
coordination functions efficiently /12/. Computation here refers to the code required to execute a particular command, while coordination refers to the code required for reliable communication of a remote unit with control centre, and the communication of a remote unit's core hardware with the application specific hardware.
Communication between the microcontroller and the communication terminal is based on exchanging AT command messages through the RS-232 serial port. Only a subset of the terminal AT commands defined by the manufacturer /13/ were supported in our test application, viz.
-	commands used to set the proper terminal operation (e.g. how the RS-232 communication is handled),
-	commands to check the TETRA network connectivity and signal strength,
-	commands for handling the SDS messages, and
-	commands used to manage the GPS receiver built in the terminal.
The execution flow chart of the microcontroller's program has been split into two parts, each describing one of the operating modes. They are depicted in Figures 6 and 7, for the normal and autonomous operation mode respectively. The normal operation mode flow chart also depicts the initialisation routine.
Fig. 7: Flow chart of the autonomous operation mode
The program for the initialisation and normal operation mode is executed as follows. After the reset the start-up procedure takes place, with the microcontroller, its peripherals and the associated communication protocols being initialised. The decision on the operation mode is then taken, based on the information about TETRA network connectivity. If the signal strength is appropriate, the program enters the normal operation mode, where it acts as a slave unit, executing commands received from the control centre. Alternatively, in the absence of TETRA network connectivity, the autonomous operation mode is selected.
In the normal operating mode, the remote unit receives SDS messages through the serial port, decodes them (i.e.
extracts the command information) and takes the appropriate actions. The program thus executes an infinite loop of making temperature measurements and triggering alarm signals. After each action taken (successful or unsuccessful command execution) the remote unit informs the control centre of its current status. This is done by sending back to the control centre a unified report SDS message containing the information about current measured temperature, alarm state, geographical location and time. This situation lasts as long as the TETRA modem has TETRA network connectivity.
References
The autonomous operation mode is entered when the TETRA modem loses TETRA network connectivity. In this mode the temperature is measured periodically and the alarm is triggered when the temperature exceeds the default threshold temperature. All this operating information, together with the time and current location, is in each iteration saved to the local storage device (CF card). When the remote unit regains TETRA network connectivity, all the locally stored operation information is transferred to the control centre, by which the control centre is restored and becomes ready to again take control of the remote unit, which consequently enters the normal operating mode.
Information like control centre TETRA modem number and threshold temperature value for alarm triggering in autonomous operation mode are saved in the microcontroller's EEPROM memory.
6. Conclusion
/1/ ETSI TS 100 392-2 V3.1.1, Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 2: Air Interface (AI), European Telecommunications Standards Institute (ETSI), September 2006 /2/ Project 25 Technology Interest Group, Available: http://
www.project25.org/ /3/ F. Garden, R. Jedlicka, R.Henry, Telemetry Systems Engineering, Artech House Publishers, 2002 /4/ I. Ozimek, G. Kandus, SCADA system using TETRA communication network, Recent advances in computers, computing and communications, WSEAS, 2002, pp. 164-166 /5/ Terrestial Trunked Radio, radio communication standards, tetra private digital mobile radio pmr, Available: http:// www.tetramou.com/ /6/ J. Dunlop, D. Girma, J. Irvine, Digital mobile communications
and the TETRA system, John Wiley & Sons, 1999 /7/ M. Smolnikar, J. Puhan, Splošni razvojni sistem za mikrokrmil-nike iz družine PIC, Proceedings of the Fifteenth International Electrotechnical and Computer Science Conference ERK 2006, 2006, vol. B, pp. 341-344 /8/ Microchip Technology Inc., PIC16F87XA Data Sheet
(DS39582B), Available: http://www.microchip.com/ /9/ EADS, THR880i TETRA handportable radio, Available: http:// www.eads.com/
/10/ Dallas, DS18S20 High Precision 1-Wire® Digital Thermometer, Available: http://www.maxim-ic.com/ /11/ Philips Semiconductors, PCF8583 Clock/calendar with 240 x
8-bit RAM, Available: http://www.nxp.com/ /12/ A. N. Chimaris, G. A. Papadopoulos, Implementing a generic component-based framework for telecontrol applications, Software: Practice and Experience, vol. 37, August 2007, pp. 1087 - 1132
/13/ Nokia, AT command set for Nokia TETRA products, June 2005
In this paper we presented the design and basic functionality of a telemetry and telecontrol system based on the TETRA network as a communication and interconnection platform. Test application with a dedicated control centre application and a microcontroller based remote unit was developed to demonstrate and validate the feasibility of the approach. In particular, the test application consists of remote temperature measurement and public alarming with the utilisation of Short Data Service for transmission of control commands and measurement data.
The modular design of the hardware platform provides the system with a great versatility, allowing it to be adapted to a host of telemetry and/or telecontrol applications from consumer, industrial, environmental, and health-care areas. The use of an appropriate microcontroller in a particular application would also provide the system with sufficient data processing capability and would adequately fulfil the performance/price ratio of the design.
Miha Smolnikar, univ. dipl. inž. ei. Andrej Hrovat, univ. dipl. inž. el. doc. dr. Mihael Mohorčič, doc. dr. Igor Ozimek, Tine Celcer, univ. dipl. inž. el. prof. dr. Gorazd Kandus
Institut "Jozef Stefan" Odsek za komunikacijske sisteme Jamova cesta 39, 1000 Ljubljana, Slovenija Telefon: +386 1 477 3134 Faks: +386 1 477 3111 E-mail: Miha.Smolnikar@ijs.si