ijk

In this project report the "alternative Lotte" airship flight control system project and its results for August 2000 – July 2006 are described. In summer 2006 the project was cancelled.

The alternative Lotte project aimed to improve the flight control system of the solar airship "Lotte" of University of Stuttgart.

	The user interface is the link between the user and the alternative – LOTTE, a measurement vehicle for solar radiation and wind power. Its purpose is allowing the user to control the alternative – LOTTE from the base station, so by using the User Interface, the user can set data to the alternative – LOTTE (new position, new velocity ...) and get data from the alternative – LOTTE (acceleration, angular velocity, azimuth, temperature, wind vector, Solar radiation ...).
The airship can be controlled from the ground or fly automatically to specified coordinates.

1 Introduction

1.1 The LOTTE project and the “alternative Lotte”

Airships are becoming more and more important within the last years. At the “Institut für Statik und Dynamik der Luft- und Raumfahrtkonstruktion” at the University of Stuttgart a solar airship was built. In February 1992 the project “Solarluftboot” was initiated. The purpose of this project was to find new materials, new construction methods and a new concept for controlling and navigating an airship run by a solar energy engine.

The “alternative Lotte” – a cooperation project between the universities of Karlsruhe and Stuttgart and the Fachhochschule Karlsruhe - is planned to be an experimental airship which can be controlled directly from the ground (first step of implementation) or (second step of implementation) fly automatically to specified coordinates. The energy supply is going to be conventional batteries in the first step but it is planned to switch to solar energy later. With “alternative Lotte” environmental data are collected during the flight via different sensors which can be mounted on the airship. In the first step the speed of the wind, the temperature and the solar radiation are measured. Apart from that flight data such as acceleration, angular velocity and azimuth angle are measured for navigation purposes.

For the above mentioned Solarluftschiff an alternative flight control system (flight control system - FCS) is developed, which takes into account modern information technology methods.

The "alternative LOTTE" project is lead by the association VaEF e.V. As cooperation main cooperation partners act the Universities of Karlsruhe and Stuttgart. The "alternative LOTTE" project intends to use an airship for taking wind measurement data.

2 Project Management

2.1 Costs

Personal costs: About 3 man years

Material costs: 6000 EUR

Renting rooms, computers etc. 10 000 EUR

The project was undergone through student research works (mostly master thesises).

3 Flight Control System of an airship [1]

This Flight Control System is based on the IFR Control System of the Lotte airship of the University of Stuttgart / Germany

3.1 Block diagram of the Control Loops

4 Optimization of the Flight Control System architecture

4.1 The architecture of the Flight Control System and its simulation on the middleware OSA+ running on the operating system Windows

Based on:

Samir Mourad, Diplomarbeit (Master Thesis)„Anbindung des Echtzeitbetriebssystems VxWorks an die Middleware OSA+ und Integration dessen in eine dienstorientierte Test-Echtzeitsystem-Umgebung"

Institut für Mikrorechner und Automation, Univ. Karlsruhe, Supervisor: Prof. Dr. U. Brinkschulte“, Institut für Prozessrechnentechnik und Robotik, Faculty of Computer Science, Universität Karlsruhe (TH), December 2000

Überblick

1. Einleitung

Allgemeingehaltene Einführung in den Aufbau von Echtzeitsystemen. Anforderungen an heutige Echtzeitsysteme: Rechtzeitigkeit der Verarbeitung, wiederverwendbarer Aufbau des Gesamtsystems. Mögliche Lösung: dienstorientierter Aufbau (modular, einfache Erweiterbarkeit des Echtzeitsystems, gibt natürlich den funktionalen Ablauf bei einem Echtzeitsystem wieder) mit Middleware (Trennung von Anwendungssoftware und Betriebssystem bzw. Hardware)

2. Aufgabenstellung und Lösungsansatz

2.1 Aufgabe

Erstellung eines dienstorientierten Test-Echtzeitsystem mit zwei Rechnern, die mit Funk-Ethernet verbunden sind. Der zweite Rechner hat einen CAN-Bus, an dem Sensoren und Aktoren hängen. Über Funkethernet gibt der erste Rechner dem zweiten Rechner Anweisungen bezüglich der Bedienung der Sensoren und Aktoren. In die andere Richtung werden Meßdaten übertragen und auf einer Oberfläche des ersten Rechners dargestellt.

2.2 Vorstellung einiger vorhandener Systeme

2.2 Lösungsansatz

dienstorientierter Systemaufbau (siehe entsprechende Abbildung in Lottefcs_vom_Leptop.doc)

Begründung für die Auswahl von VxWorks: relativ einfache Handhabbarkeit wegen umfangreicher Entwicklungsumgebung, in der Praxis erprobtes Standard-RTOS.

3. OSA+

Beschreibung von Prozeßdienst, Ereignisdienst (SA von Sven), Kommunikationsdienst und Datenhaltungsdienst (Zusammenfassung aus Institutsbericht)

4. VxWorks

Vorstellung des Basic OS, des I/O System, des lokalen Filesystems und des Kommunikationssystems (Zusammenfassung aus Programmer's Guide)

5. Anpassung von VxWorks an OSA+

5.1 Prozeßdienst

5.2 Ereignisdienst (SA von Sven)

5.3 Kommunikationsdienst

6. Integration ins Gesamtsystem

Beschreibung der Dienste, der Treiber, der HW und des Zusammenspiels des Gesamtsystem

6.1 Oberfläche des 1. Rechners und zugehörige Dienste

6.2 Kommunikationsdienst zwischen 1. und 2. Rechner

6.3 Meßdienste und Stelldienste auf 2. Rechner

6.4 Treiber für VxWorks bzgl. CAN-Bus (DA von M. Subhan)

(6.5 Sensoren/Aktoren auf dem CAN-Bus)

7. Ausblick

Variierungsmöglickeiten: Ersetzung der Sensoren/Aktoren, Austausch des VxWorks durch ein anderes RTOS bzw. direkte Anbindung an die HW, Ersetzung des Funkethernet durch ein anderes Protokoll.

4.2 Results

Entwicklung einer verteilten

Experimentalumgebung fuer die Middleware OSA+

(ESfOSA+)

Diplomarbeit von Samir Mourad

(Inhaltsverzeichnis)

1. Aufgabenstellung

Thema der Arbeit ist die Entwicklung eines Experimentalsystems fuer die OSA+-Anbindung an Windows NT und die die darauffolgende Durchfuehrung und Dokumentation von Test mit diesem Experimentalsystem.

Das Experimentalsystem wird im folgenden mit EsfOSA+ (Experimentalsystem fuer OSA+) bezeichnet.

EsfOSA+ soll eine Simaulation eines embedded system werden, wobei die Hardwarekomponenten wie Aktoren und Sensoren als digitale Uebertragungsglieder simuliert werden.

]Der Kern von EsfOSA+ ist komplexer Regelkreis, der eine zu automatisierende Anlage regelt.

Ausgangspunkt war ein der vorliegenden Arbeit ist ein analoger Regelkreis, welcher digitaliert wurde und in dienstorientierter Struktur realisiert wurde. Die Dienste sollen auf der Middleware OSA+ ablaufen.

Es soll getestet warden, ob es Bedingungen gibt, unter denen eine solche Regelkreisimplementierung unter OSA+/Windows NT echtzeitfaehig ablaufen kann.

2. Digitalisierung des analogen Regelkreises

Bild 1: Der analoge Regelkreis

Bild 2: Der digitale Regelkreis

3. Konstruktion der dienstorientierten Systemstruktur fuer EsfOSA+

Die Dienste-Architektur des EsfOSA+

Anforderungen an "ideale" Dienste:

* Plattformunabhaengigkeit (-> Portierbarkeit)

*Skalierbar und Konfigurierbar (-> Anpassung an die Anwendung, Erweiterbarkeit)

* Austauschbar (einfacher Wechsel von Komponenten)

* Kompatibel (->Datenaustausch)

* Testbar (->Fehlehrsuche, Wartung)

* Echtzeitfaehig (Wenn erforderlich)

EsfOSA+ soll den in Bild 2.1.1 dargestellten Kaskadierten Regelkreis implementieren.

4. Die OSA+ Architektur

OSA+ ist eine skalierbare echtzeitfaehige Middleware. Sie erlaubt es, verteilte Anwendungen zu entwickeln, die echtzeitfaehig ablaufen und innerhalb eines heterogenen Netzwerks existieren. Die zugrundeliegende Hardware sowie die Betriebssysteme warden dazu optimal ausgenutzt.

Der OSA+-Ereignisdienst

Der Ereignisdienst dient dazu, Jobs zu vorgegebenen Zeiten innerhalb eines festgelegten Intervalls ausfuehren zu lassen. Er besteht aus 2 Teilen: dem eigentlichen Ereignisdienst und den Funktionen fuer die Uhrzeit.

5. Experimentelle Ergebnisse

5.1 Die Simulationshardware

Die Simulation life auf einem PC mit einem Intel Pentium Prozessor mit 133 MHz und 32 MB RAM ab.

Sensorik und Aktorik wurden softwaremaessig simuliert. Es war keinerlei reale Sensorik oder Aktorik angeschlossen.

5.2 Die Testreihe

Bei den Tests wurden verschiedene Dienste eingesteckt und das Zusammenspiel getestet. Dabei wurde so vorgegangen, dass zunaechst nur die Dienste der inneren Regelschleifen mit den zugehoerigen Messdiensten und natuerlich der Streckensimulation und des Stelldienstes eingesteckt wurden. Spaeter wird sukzessive der ganze kaskadierte Regelkreis von innen nach aussen aufgebaut.

Einstecken von PS, S1_M, S2_M, S, R_In1, R_In2

Test 2.1

Festlegung der max. Antwortzeiten der einzelnen Dienste (durch den Ereignesdienst)

PS 10ms

R_In1 20ms

R_In2 100ms

Wie schon im vorigen Test warden einige Groessen ueber der Zeit aufgezeichnet (Graphen von links nach rechts):

y_4, x_1, x_5, x_12, x_8, y_1,, (d.h. der 1. Graph v. l. zeigt y_4, der 2. Graph v. l. zeigt x_1 usw.)

Im Bild R_In2_KnappeAntwortzeit_1.bmp ist zu sehen, dass die Dienste nicht vollstaendig ausgefuehrt warden konnten. Im naechsten Versuch (siehe R_In2_KnappeAntwortzeit_2.bmp) wird daher die Antwortzeit fuer R_In1 erhoeht.

R_In2_KnappeAntwortzeit_1.bmp

Test 2.2

Einstellungen wie bei Test 2.1, nur ist die Antwortzeit fuer R_In1 diesmals 30 ms.

R_In2_KnappeAntwortzeit_2.bmp

Einstecken von PS, S1_M, S2_M, S, R_In1, R_In2, MV,_2, R_M, MV_2, R_A (vollstaendiger Regelkreis)

Test 4.1

Festlegung der max. Antwortzeiten der einzelnen Dienste (durch den Ereignisdienst)

PS 10 ms

R_In1 30 ms

R_In2 100 ms

MV_1 100 ms

R_M 200 ms

R_A 300 ms

Testdauer: 30 Sekunden

Auf der folgenden Seite ist R_A_KnappeAntwortzeit_1.bmp zu sehen.

(v.l.n.r.: x_12, y_MV1, x_8, y_1, y_4, x_1, x_3, x_5)

6. Bewertung der experimentellen Ergebnisse und Ausblick

Die Experimente ergaben folgende Erkenntnis: Wird im Ereignisdienst die Rueckgabezeit eines Dienstes zu klein eingestellt, dann wird nicht mehr richtig gereglt. Es ergeben sich Bilder wie "R_In1_zuKleineAntwortzeit.bmp". Dies bedeutet: kommt man bei einer OSA+-Anpassung an WindowsNT mit den geforderten Antwortzeiten in den Bereich von ca. 20 ms, ist auch praktisch gesehen kein rechtzeitiges Antwortverhalten garantiert. Dass die zugrundeliegende Simulationshardware keinen grossen Einfluss hat, wird dadurch bestaetigt, dass nahezu die gleichen Tests auf einem AMD Duron 900 MHz Prozessor mit 256 MB gemacht wurden, und dort fast die gleichen Ergebnisse herauskamen.

Es waere interessant, OSA+ auf ein Echtzeitbetriebssystem anzupassen, und dort aehnliche Tests ablaufen zu lassen.

4.2.1.1 System Architecture of Airship Flight Control System

4.2.1.2 Simulation Code (in programming language C)

4.2.1.3 Simulation results

5 Development of the Ereignisdienstes for the middleware OSA+

Based on Entwicklung des Ereignisdienstes für die Middleware OSA+, Studienarbeit von Sven Forstmann, 2001

Studienarbeit (Bachelor Thesis)

Sven Forstmann

27 Sep 2001

Institute for Prozeßrechentechnik and automation, Univ. Karlsruhe

Supervisors:

Samir Mourad

Dipl. -Inform. Jens Riemschneider

Prof. Dr. Uwe Brinkschulte

1 Abridged Version. 4

2 The nature of the task. 4

3 The OSA+ architecture. 4

3.1 Introduction. 5

3.2 The components of OSA+. 6

3.2.1... The Platform.. 6

3.2.2... Generic Services. 7

4 Components of the OSA Eventing service. 8

4.1 The time functions. 8

4.1.1... The handling of the time. 8

4.1.2... Initialization. 9

4.1.3... Functions for time management 10

4.1.3.1 Time Continued. 10

4.1.3.2 Reading Time. 11

4.1.3.3 Move Time. 11

4.1.3.4 Spend time in a string. 11

4.2 The event service. 12

4.2.1... General Information. 12

4.2.2... The initialization of the Ereignisdienstes. 14

4.2.3... Features of the Ereignisdienstes. 14

4.2.3.1 Add an Event 14

4.2.3.2 Remove a Events. 15

4.2.3.3 Reading a result/error codes. 15

5 Short Overview.. 16

5.1 Time functions/variables. 16

5.2 Features of the Ereignisdienstes. 16

6 Configuration. 16

7 Theory of Operation. 17

7.1 Osagettime() 17

7.2 Osasettime(int,int) 17

7.3 Osaaddtime(int,int) 18

7.4 Char * osaPrintTime( int, int ) 18

7.5 Osainitevents() 18

7.6 Int osaAddEvent(uint,uint, uint, uint,uint, uint,uint, uint, function) 18

7.7 Int osaDelEvent(uint,uint,uint,UINT) 20

7.8 OSA_Error osaGetEventResult(uint,UINT) 20

7.9 Internal functions of the Ereignisdienstes. 21

8 Programming examples. 21

8.1 For example: Changing the Time. 21

8.2 Example: Add an Event 22

8.2.1... Start a function at a specified time. 22

8.2.2... Repeated start a function. 23

8.3 Queries of results. 23

8.4 Delete a Events. 24

9 Test Runs. 25

9.1 Deliver-Test 26

9.2 Test run of a cyclical events with open. 27

9.3 Test the maximum temporal resolution on different systems. 28

9.3.1... System 1. 28

9.3.2... System 2. 30

9.3.3... System 3. 32

9.4 Stability tests. 34

9.4.1... Exceeding the maximum acceptable number of Events. 34

9.4.2... Exceeding the maximum acceptable number of events per unit time. 34

9.4.3... Overrun of the events per unit time through Zeituberschneidung. 35

10 Results and Outlook. 37

11 ANNEX.. 38

11.1 List of all Windowsspezifischen Functions. 38

12 Literature. 38

Declaration

I hereby declare, Sven Forstmann, that I have carried out this work independently.

Thanksgiving

First of all, I wish to thank Prof. Brinkschulte for the nice assistance and cooperation and also thank Jens Riemschneider for assistance during the incorporation in OSA+. Samir Mourad was for the friendly help thanked in advance of the thesis.

5.1 Abridged Version

Middleware systems support the development of real-time systems especially in heterogeneous environments, in the present work is the event service with all the details, as well as the Implementationsbeschreibung presented.

The event service extends the existing OSA+ to services for the timed start jobs or functions, as well as to several functions to manage the time.

What is important is that the Ereignisdienstes the OSA+ now one step closer in the direction of the real-time capability brings, this is achieved by, inter alia, that when you start a job / a function also can be specified, in which interval This is to be started, however, the extent to which this real-time capability achieved will depend on the respective operating system, and is also by the handling of the time functions of the same limited.

5.2 The nature of the task

In the framework of a joint project with several industrial partners, the Institute for Prozeßrechentechnik and Automation the open, scalable, and real-time middleware platform OSA+ (Open System Architecture Platform for universal services) developed, today's real-time systems usually operate in environments with many asynchronous events, and the processing of these events is often complex and may, by the introduction of a own service established for this purpose will be much easier. The aim of this thesis is the design of the service, a prototypical implementation and integration into the OSA+ overall architecture.

5.3 The OSA+ architecture

The content of this chapter is [Brinks et al, 00] taken from the description of the individual OSA+ -functions from [Brinks et al, 00] are not listed, it can be read there.

5.3.1 Introduction

OSA+ is a scalable real-time middleware that allows to develop distributed applications, the real timable expire and exist within a heterogeneous network. The underlying hardware, as well as the operating systems to be used optimally.

The architecture of OSA+ is divided by a application in services that communicate with each other on jobs, this communication is achieved by means of a platform, in which services in the platform "Plugged in", in this way can inserted into all services with one another using the Platform communicate.

The platform itself specifically used excellent services, to increase its capabilities, including generic services, which ensure that the platform independent of the operating system and the underlying hardware, it is, as well as Erweiterungsdienste, the specific tasks for the platform provide the platform is, however, also run without these services.

The following is the detailed architecture described by the OSA+.

1: OSA+ architecture

2: Communication of services using job and outcome ( =job)

First, it is described as the "naked" platform looks like and what functionality it provides, so that you will be the base and Erweiterungsdienste explains and the associated additional possibilities, thus acquires the the platform, and concludes the interfaces of the platform and the basic and Erweiterungdienste described.

5.3.2 The components of OSA+

5.3.2.1 The Platform

The platform is the component to the user by the OSA+ is visible, it offers a interface, with whose assistance services in the platform can be inserted and allowed the grant of orders, which is divided the platform in three basic parts:

· A Service Management: she knows all inserted services and completed the install and uninstall services, as well as locate of services;

· A job management: Allows the give and expect of orders and the report of results of this and expect orders;

· A user interface: Is there a clear struktierte the user interface to these two bodies.

5.3.2.2 Generic Services

The platform uses the generic services, to an encapsulation of the operating system functions, which you can use for your tasks are not generic services installed in the platform, so must the platform without these features and can only get to make, what as a recognized standard of the underlying implementation language is recognized, based on the ANSI-Richtlilien for C and C++ or the JDK 1.0 . Beyond functionality of the generic services must be available in each are this:

· Prozeßdienst: it allows the platform lightweight and/or heavyweight to take advantage of services, he provides a unified interface to process administration of the operating system, and the OSA+ -Prozeßdienst allows it, split the control flow of the customer, so that the contractor and the customer (quasi) in parallel, each with their Arbeitfortfahren can. This is possible, that of the Prozeßdienst the platform allowed, with a service to connect a Control Flow, heavyweight Kontrollflusse are situated in their own space and are in need of a Miniplattform, on the A Kmmunikationsdienst (IPC-service) is installed.

· Echtzeitspeicherdienst: it allows the realtime access to memory (in particular the allocation and release), not real-time memory is in the above language specifications standardized (e.g. malloc in C or new in C++ or Java). The service is not installed, so the time conditions are checked only a job, but not guaranteed.

· Communications services: serve the platform to the shipping of orders over any communication media, it is also the Interprocess Communication as a means of communication.

· Eventing service: is the platform for the monitoring and control of temporal processes. He provides specific Auftragspezielle jobs to the platform, so this on certain events can be informed.

5.4 Components of the OSA Eventing service

The event service is divided into the services for the management of the time, as well as in the of the actual Ereignisdienstes. a separation of these two is not impossible, but awkward, as the event service on the functions of the time is dependent on time, to all the processes to start.

5.4.1 The time functions

5.4.1.1 The handling of the time

In the event service is managed the time in the UNIX FORMAT, as this is the easiest to handle, and at the same time the implementation on UNIX/LINUX - systems much easier.

In this format, the seconds since 1.1.1970 12:00:00 in a 32 ( soon, perhaps even 64 ) bit - value paid, which means that extra for Sekunde/Minute/Stunde/ ... not a variable is needed, and also that the invoices are carried out with the time, are now almost easily.

In the OSA-event Service is the time but now not only in a 32-bit value, since there often also in real-time applications to a higher accuracy is essential, therefore it is in addition to the 32-bit variables for the seconds a further variable used for the milliseconds. This makes it difficult and slows down while the calculation of time differences, but it is for the time-exactly timed execution of the job is essential.

It could also have been upgrading the CMOS-clock for all of the operations of the time, as well as to use of the Ereignisdienstes - this had caused some complications, however, first of all it is not accurate enough, because you only on the time the tenth stores, since the event service is to be real timable and there you have a accuracy is promoted in the millisecond range, this is enough and not from, a further difficulty is that when the time change this change affects the entire system and be influenced by other programs, then what in these can create incorrect results.

3: Structure of the time

4: Integration of time management, and in the system of the Ereignisdienstes

5.4.1.2 Initialization

Before the time functions that can be called the initialization must be performed first, which for the time periods required calculated variables.

This calculation is necessary, because the time with the help of two different functions is calculated.

With the A is initially read out the time of the system and stored in the time variable, since the system time but only on the second exactly is returned, only to a Sekundenwechsel must be serviced to ensure the Millisekundenanteil can be initialized with zero.

Now, the difference to the value of the other function are calculated, which returns the system time in Millisekundenformat. In this is the number of milliseconds since the start of the system, since you can get with this 32-bit value but only 2 ^32 milliseconds can be used to specify, which corresponds to 49.71 days, you can use this function only to do this, read the time already with the help of this function to update, and is now an offset is calculated at the beginning of the system time and always corresponds to the difference of Millisekundenanteil indicating to system time.

In addition, the initialization of the time and also the Ereignisdienstes starting values for the set, in order to save another function call.

5: PAP of the time initialization

5.4.1.3 Functions for time management

Time Continued

When you set the time, the global time variable updated for seconds, and milliseconds. This also takes into account whether Millisekundenanteile have been specified, the Not in the range 0 to 999. In this case, a carryover for the seconds portion of is calculated, and the Millisekundenanteil corrected accordingly.

But it is only the time of the OSA+ internally changed - the general CMOS clock of the computer remains untouched.

The time periods necessary to offset the difference between milliseconds of the system and the real time, must also be newly set so that it does not come to the wrong calculations.

Reading Time

When reading the time, the global variable for seconds and milliseconds updated. For this purpose, the difference in milliseconds since the last time the query with the help of the system time calculated and added to the current time.

Since the system time to calculate is used, it should in fact not later than 49 days all the time query be invoked once, but now that the event service is associated with the time, it can be ausgegeangen that this due to its timer is called more often, in order to start the events correctly, it must also of course at each time, in the course of which he is called from the timer, the time queries, which is now the reason for this, that the time of an application program does not necessarily have to be called regularly.

6: PAP of the time

Move Time

This function adds to the current time a specified time difference in addition to this, in principle, this function does not have been necessary, since one with the two above functions exactly the same thing can reach had - but so is now saved time, and this may be to match the time on the network can be of use, and the user will work when calculating the carryover disconnected.

Spend time in a string

This function creates a string in which the current date and time is included with milliseconds. ( This is especially handy in debug output ). This is done by first with the help of the ctime from the current time, in the 32-bit value is stored, generated a string, the date and time already contains, the only thing missing now is the Millisekundenanteil, which simply by various Stringkopieraktionen is inserted.

5.4.2 The event service

5.4.2.1 General Information

The event service is responsible for ensuring that jobs at a specified time with a pre-specified accuracy can be started. He is to guarantee the real-time capability of the OSA, which but limited by the underlying operating system is, for jobs be started via the network, must, however, only the clocks of the two systems are synchronized, this is by a long-term observation of the Pingzeiten possible; as a result of the time offset can then be calculated by which the current time has to be postponed, an alternative would be the average of the Pingzeiten to calculate the last few minutes, and with this to synchronize the clocks.

The event service is from Geschwindigkeitsgunden directly in OSA have been implemented, it is therefore not directly to a LW/HW-service, but rather a supplement to the OSA+ features available.

Figure 7: Architecture of the Event Service (Ereignisdienst)

5.4.2.2 The initialization of the Event Service

The initialization of the Ereignisdienstes is automatically after the initialization of the time. This is the first to be the necessary variables for the Eventing service set, the next step is the timer function of the Ereignisdienstes started, what must be called upon regularly in order to make it in time to start the jobs, in which intervals this is to be called, depends on the desired accuracy of the Ereignisdienstes as well as the speed of the underlying system, try showed that, for example on a Duron 900 even an interval of one millisecond is possible.

On a Pentium 100 products, on the other hand, only 5-10 ms intervals possible. ( but more about that later in the test runs.

It would also be conceivable, the performance of the Ereignisdienstes to increase that zeitkirtische functions through the implementation of assembly code are replaced.

5.4.2.3 Features of the Ereignisdienstes

Add an Event

When you add new events there are several possibilities: The job can be either at a specific time, or with a relative delay be called, and you can also be used to specify whether the job repeatedly in a certain time interval is to be started (for example, is for the regular queries of sensors helpful), and whether the result of the delivers to the later check is to be saved, and also can be a optional to call a function if it particularly in the short responses to local applications. When you add it can, however, to get any error messages if the job was already over, the list is full, or too many jobs at the same time are to be started, and this number in the same time interval the job to be started is adjustable and should be to the respective system be adapted to maintain speed and in addition must still be given a timeout, the constrains the time window in which the job is to be started.

The job is only called after leaving the window, so is he skipped ( this happens but only if it to failures or malfunctions in the system, the calling of the timer function prevent ). If it is a repetitive job, it will be the next time but started again, and can still be set, if he is as closely as possible to the Zeitgitter oriented, or the delay as precisely as possible is to be met.

The Add/delete a job may be to delay a few milliseconds, since, as long as the interrupt routine is active, no operations on the list of job to be started are allowed, this of course also applies vice versa for the interrupt routine, if you an insert/delete operation interrupts, this call is ignored, which may of course have the consequence that a(IGE) Event(s) to a few milliseconds late be started - what but only at very slow computers into the weight cases is expected.

The job that you want to be the Ereignisdienstes in a circular list managed fixed-size, you can, after you have been added to this list, also again be removed - if you have not yet been started.

In order to results of the query again later delivers to, is not yet an additional list managed, in the opened up for each event to an entry exists (the key is the ID of the job), but for reasons of space is only for each EventID keep the latest result.

If the size of the lists is to be changed, is that in the source code simply by changing the #defines in the beginning to reach the files.

In addition, it can not - real-time operating systems that have come to the timer not in time will be called; the result may be that the events do not correctly can be started and is currently are then to be started up to the point that started events at a time, i.e. as long as the timeout of the respective jobs is not exceeded.

Another difficulty arises if a cyclic job has been called for, the back is to be added to the list and an error occurs: a time already past, crowded or list the already too many events to the desired time be called, in order to solve this problem, is, at the moment a part installed, the attempts to the event to matureness, later to start dates.

This will be calculated by either, that either the next possible start times will be taken, or but in the set for the job by increments is attempted, add the job again, the number of retries can be adjusted - but should not be set too high, otherwise if there are too many errors the time interval of the timer not longer sufficient, and the next will be affected, if the rescue but is unsuccessful, the job will no longer be called.

Remove a Events

Back to an event from the table of the job to be started to remove, first waited until requests on the table are allowed and then occupied the semaphore.

The next step will be for the complete table, and skipped the event you want to delete, and the remaining are automatically when.

Reading a result/error codes

Now here is the error code returned, which when you start a job is created, it can here, however, from being purged the last result which emerged only be queried, and internally to a list of all mitzuloggenden Events kept, in the then at the start of the event the result will be entered, if there are more events will be logged, as the list is large, after the FI Fo-Prinzip approach.

5.5 Short Overview

5.5.1 Time functions/variables

UINT osatime: Are Using Unixtime in seconds

UINT osamtime: related Millisekundenbruchteil ( <1,000 )

Osagettime: time reading

Osasettime: Time Set

Osaaddtime: Time-add offset

Osaprinttime: Spend time

5.5.2 Features of the Event Service (Ereignisdienst)

Osainitevents: Initialize event service and Time

Osadelevent: Delete Job

Osaaddevent: Add Job

Osageteventresult: Result of a running job reading

5.6 Configuration

The configuration of the Ereignisdienstes within the source code can be made, and by modifying the various definitions ( #define) at the beginning of the source code:

( Alternatively, these parameters from the source code be relocated in the Makefile.

Variable instantaneous value propositions

Precision 1: determines the accuracy with which the event service is supposed to work

EVENTSPERTIME 5 : determines the number of bootable events at the same time

TABLENGTH 255: Indicates the size of the Event-Tabelle (must be a 2 ^n-1 number)

ERRORBUFFER 7 : Specifies the size of the Result-Tabelle (must be a 2 ^n-1 number )

RETRYCOUNT 4 : specifies how often should be attempted, a recurring event in the

List should be entered, if errors occur

OSA_DEBUG: If defined, debug messages are issued, the

All of the important actions of the Ereignisdienstes describe

To the size of the event, and the table was a 2-he potency as a large selected to the to accelerate for offset calculation for Tabellenzugriffe. ( then can namely an and instead of a Modulo-Verkupfung be used - this difference is particularly noticeable on older systems.

5.7 Theory of Operation

5.7.1 Osagettime()

Parameters: None

Input integer:NONE

Reads the current time from and updates the global time variable ( osatime and osamtime ).

Implementation:

The time is almost to the millisecond, and is calculated from a combination of the internal clock and the system time, the clock will be at the beginning needed to fix the start time in seconds, but not the accuracy is sufficient for OSA as a timer, in that, it not the time to the millisecond that shows exactly, now here comes the system time in the game, the milliseconds since the start of Windows in a 32-bit value, and if you now waits until the clock the seconds count up to 1, then you can use it to calculate a differential value to system time, and with the help of the value they get the missing milliseconds for the time.

If so now osaGetTime() is invoked, the milliseconds updated, and at a value greater than 1,000 according to also the seconds, and the difference between this and the system time.

5.7.2 Osasettime(int,int)

Parameters:Seconds,Milliseconds

Input integer:NONE

Sets the time seconds is the time in the Unixformat and milliseconds are the associated thousandth.

However, this change also directly to the events that are already in the list are entered, and are to be started; i.e. it quickly in case of major changes can lead to errors.

Implementation:

Here are the global variables are updated; Millisekundenanteile greater than 999 will be automatically converted in seconds.

5.7.3 Osaaddtime(int,int)

Parameters:Seconds,Milliseconds

Input integer:NONE

Added to the current time in addition to the time difference of the call-up parameters milliseconds greater than 999 will be converted to the seconds.

( Here are also negative values registered )

Implementation:

This function first reads the time from, and then added the desired time difference, taking into account a Millisekundenuberlaufs, added.

5.7.4 Char * osaPrintTime( int, int )

Parameters:Seconds and milliseconds of output time

Input integer:String with the date and time.

This function returns a pointer to a string, the current date and time includes, in debug output is very helpful, since also thousandths of a second to be issued.

Implementation:

The function will access the Function ctime back, which from a 32-bit value (Epoch) a string with the date and time calculated. This string will then be modified, so that even milliseconds with be returned.

5.7.5 Osainitevents()

Parameters: None

Input integer:NONE

Initializes the table in which the jobs be entered later and sets the time.

Implementation:

All of the entries will be first in the list of events deleted, and the difference between the internal clock and the system time for osaGetTime determined. The next step is now set the timer, later also the starts the job, which is the Multimediatimer of Windows, the a function with a definable accuracy can repeatedly. (image 5)

5.7.6 Int osaAddEvent(uint,uint, uint, uint,uint, uint,uint, uint, function)

Parameters:assigned id1,NUMCOUNT ID 2,Type,start,MSTART, repeat,mRepeat, timeout, FUNCTION

Input integer:0 =OK, 1 =list already full, 2 =too many events to the same Zeit,3 =time is already over

Assigned ID1,NUMCOUNT ID 2:ID's of the job that you want to (ID1 is the normal ID of a job, ID2 is

For the future of applications planned)

Type:Bit 0 =0:Start at the specified time ( Start,MSTART )

Bit 0 =1:Start in Start.MSTART Seconds

Bit 1 =0:start only once

Bit 1 =1:repeatedly at intervals of repeat.Start mRepeat

Bit 2 =0:return value of not logging osajbscdDeliver

Bit 2 =1:return value of osajbscdDeliver log for later queries (costs a little more time.

Bit 3 =0:start times will be respected as precisely as possible

Bit 3 =1:time differences are maintained as closely as possible

Bit 4 =0:When Retries try,the job to start at the soonest Time

Bit 4 =1:In retries the job in time intervals of repeat.Try to start mRepeat

Start,MSTART:Start at/in Start.MSTART Seconds

Repeat,mRepeat:If in type is specified, the event in repeat.mRepeat seconds called again

TimeoutGibt the size of the time window, in milliseconds, in which the job is to be launched

FunctionWenn not zero, the specified function ( void function() ) called - osajbscdDeliver is not running in the case

Adds a job to be launched to the Event List in addition to this, the function can be specified the optional, but it is only intended for local use, if short response times are of importance, this feature is this, that you will be called directly, with the same priority as the timer function of the Ereignisdienstes started ( on Windows, this is the the highest ). You should therefore not be longer than 1-5 ms to use it, as the subsequent jobs this can be affected in some circumstances, since a while(1); in this function, e.g. the system leads to Unbedienbarkeit, this option should go directly to a function can only be used with extreme caution.

Implementation:

In order to prevent the paste that in between the timer function on the Event List is accessing it, is a simple system with semaphores implemented. This checks at the beginning of the paste operation, whether the timer function is currently active and waiting if this is the case, everything is free, the semaphore is occupied, and it can now be checked whether it is possible to add the event, the list is already full, an error will be immediately returned.

If not, now is the time for a relative time into an absolute time converted so that can be compared quickly as possible, whether the job is still is to run, or the time has already passed, the last thing now to check, is the number of jobs, the at this time are to be started.

Now, if everything is in order, the job is in the Time sorted list is inserted; this prevents that when starting from the correct position must be sought.

5.7.7 Int osaDelEvent(uint,uint,uint,UINT)

Parameters:assigned id1,NUMCOUNT ID 2,start,MSTART

Input integer:number of the deleted events

Deletes one or more events from the list, or if one of the parameters is 0 (up to the Millisekundenanteil), it is not compared; i.e. , osaDelEvent(0,0,0,0 ) Deletes the entire list, or if the time (start.MSTART) is specified, it is always the absolute time compared ( even if the call the relative is specified.

Implementation:

This function runs through the list of events from the front to the rear, and not to delete the copied together events to be deleted with the be skipped, and here again is the system used with semaphores, to avoid conflicts.

5.7.8 OSA_Error osaGetEventResult(uint,UINT)

Parameters:assigned id1, ID2

Input integer:result of the last Delivers

There is the latest result back, at the start of the event with the assigned id1, ID2 has been created.

If OSA_ERR_SERVICE_NOT_FOUND is returned, the job was either not started yet, or the result of change is already have been overwritten.

Implementation:

The list is after the first event with the two ID's being sought, and the returned result of the job in question, and when the event is not found, the function returns OSA_ERR_SERVICE_NOT_FOUND back.

5.7.9 Internal functions of the Ereignisdienstes

Void callback TimerProc( UINT,UINT,DWORD,DWORD,DWORD )

This is the central function of the Ereignisdienstes, which with the Multimediatimer from the desired accuracy of the Ereignisdienstes regularly is called ( default are here 2ms ). It is responsible for ensuring that the jobs to be started and repetitive jobs again be entered in the list.

Implementation:

At the beginning of the function, it first checks whether the semaphore is busy, and if so, this time interval is skipped; otherwise is now checked, whether the first job needs to be started.

If yes, the next step is still being examined, whether the timeout has not been exceeded and whether a function is to be called, or the job is to be delivered (in the last case, optional, the result will be a list saved).

It is a job to be repeated, again this is in the list, taking into account the different operating modes, it is registered.

5.8 Programming examples

5.8.1 For example: Changing the Time

There are several ways to do this, but one of the simplest is to set the time with the help of the function osaSetTime ( seconds, milliseconds ).

For example, is specified

Osasettime( 986604168, 50 )

So the clock will be on

Friday the 06.April 2001, 4:42:48 PM set and 50 milliseconds.

However, since this is not too comfortable, and most of the time almost is set correctly, it is often better if the clock is not set to a new, but before or is adjusted, the function is osaAddTime ( seconds, milliseconds ) provided.

So causes for example

Osaaddtime ( -3600 , 0 )

That the clock one hour is reset.

But you need have no concerns that the time of the system of such actions could be affected - the time is purely OSAintern.

Yet now, in order to check that the Daylight Saving Time was successful, then the time you can also still with the function osaPrintTime( seconds, milliseconds ) output:

Printf(" Date/Time: %s\n", osaPrintTime( osatime , osamtime ));

5.8.2 Example: Add an Event

5.8.2.1 Start a function at a specified time

Now here is the first variant customizationsavailable presented:

A unique feature is intended to be with a delay of 5 seconds will be called, is only required once the function that should be called; this has, however, fixed call, and with, here's a little example:

OSA_Error test (void)

{

Printf( "Test OK\n" );

Return OSA_ERR_OK;

}

Now, the Eventing service still be communicated, where he finds the function, and

When he is to call you, and this is done with

Osaaddevent ( 1, 0 , // assigned id1, ID2

1 , // type ( bit 1 = 1, so start time = delay.

5 , 0 , // start in 5 seconds

0 , 0 ,// time difference when repeats (if set)

1,000 , // 1 second timeout

&Test // Function

);

As the start time is here now a delay of 5 seconds ( + 0 milliseconds ) as well as a timeout of a second is specified at the end of the call must now only the pointer to the function to be called be specified.

A timeout of 1 second means that the function call to a maximum of 1 second may be delayed - for larger delays he will no longer run.

Are Normal delays of 0-10 milliseconds; on fast systems (0-1 milliseconds.

The whole sample program could then may then look like the following:

#Include "osa.h" // necessary include - Files

#Include "osa_ereignisdienst.h"

OSA_Error test (void)// function that the event Service is Started

{

Printf( "Test OK\n" ); // as soon as this issue is, the test was successful

Return OSA_ERR_OK;// everything OK

}

Main( )// Main Function

{

// Initialize the Ereignisdienstes

Osainitevents( );

// Test-Event entries

Osaaddevent ( 1.0 , 1, 5.0 , 0.0 , 1000, &test );

// ... And to the start of the wait dfor

While(1)sleep(1000);

}

5.8.2.2 Repeated start a function

The next example shows how to do a job programd, the will be called repeatedly, which is to the test - function the first time after 5.050 seconds, and then repeatedly at intervals of 1,005 seconds be called, the function is to be called repeatedly, the Eventing service by setting the the 2, Bits communicated in the display type box. The timeout is as well as in the previous example 1 second, and in the display type box the bit 3 is not set, attempts of the Eventing service here, the function exactly as possible to enter the vorherberechneten time - in the present example : Start Time + 5.05 s + X * 1.005 p.

( If the bit would have been set, he had tried, the delays exactly as possible.

The description for the function here is to be called, you can see from the example above, for example, here is the actual function call to the event Service:

Osaaddevent ( 1, 0 , // assigned id1, ID2

1+2 , // type ( delayed start [Bit 1] + repetition [Bit 2] )

5 , 50, // Start in 5.050 seconds

1 , 5 ,// repeated Start in 1.005

1,000 , // Timeout = 1,000 milliseconds

&Test // Function

);

5.8.3 Queries of results

If a job is started, there is the possibility and subsequently the result query, which is of the type OSA_Error. It plays no role, whether it is a deliver or a direct function call has traded.

Osaaddevent (1.0 , 1+8 VDC , F2.0: , 0.0 ,50 , &test); // event in the list entries

Sleep(1000);

Printf( "Eventresult of ID 1 : %d\n", osaGetEventResult(1.0 / * ID of the event * / ) );

Sleep(2000);

Printf( "Eventresult of ID 1 : %d\n", osaGetEventResult(1.0 / * ID of the event * / ) );

In this example is now the result once before, and the second time after the start of the event read, and if everything is working properly, it is the first time OSA_ERR_SERVICE_NOT_FOUND returned, since the results are not yet available, and the second time then OSA_ERR_OK, what the return value of the test-function corresponds to.

5.8.4 Delete a Events

In the next example will be added first three events, each of which every two seconds will be called once. After 5 seconds, then two of the three will be removed again. The associated program code could appear as follows:

Osaaddevent ( 1.0 , 1+2 ), "2, 0, 2.0 ,50, &test1 ) ;// Add the 1 events.

Osaaddevent ( 1.0 , 1+2 ,2,500, 2.0 ,50, &test2 ) ;// Add the 2 events.

Osaaddevent ( 2.0 , 1+2 , 3, 0, 2.0 ,50, &test3 ) ;// Add the 3 events.

Sleep(5000); // wait for 5 seconds ...

Osadelevent ( 1.0 ,// and all with ID 1, * Delete,

0.0 ) ;// without the start times to be taken into account

When the program starts, all three events will be initially launched sequentially. After 5 seconds are then the first two of the three events removed from the list, as in the clearing instructions as the ID 1.0 was specified, what exactly the ID's of the events corresponds to the start times were not taken into account when you delete, since all passed with 0 fields cannot be compared.

5.9 Test Runs

Test Environments

System 1:

Hardware:

CPU:AMD Duron 800

Memory:256 MB

Hard Drive:10GB

Graphics:Nvidia Geforce 2

Operating system:

Windows 2000

System 2:

Hardware:

CPU:Cyrix 6x86

Memory:24MB RAM

Hard Drive:0.5GB

Graphics card: Tseng ET6000

Operating system:

Windows 98

System 3:

Hardware:

CPU:Intel Celeron 450

Memory:256 MB

Hard Drive:100GB

Graphics:3dfx Voodoo 3000

Operating system:

Windows 2000

Configuration of the Ereignisdienstes (if not otherwise specified):

Precision:2// The Event-Timer is called every 2 milliseconds

EVENTSPERTIME:5// it must not more than 5 events started at the same time

// i.e. there will be maximum 5 events within the 2 ms started

TABLENGTH:255// Number of entries in the Event-Tabelle (2 ^n-1 must be)

ERRORBUFFER:7// number of jobs, the results keep at the same time

// Should Be (must also be 2 ^n-1)

RETRYCOUNT:4// Number of retrys if repetitive Job does not immediately return

// CAN BE ADDED

5.9.1 Deliver-Test

In this test was done with the built-in local modified Serverfunktionstest. The function this is not more testsrvFunc immediately, but only with the delay of 1 second will be called, by using the following changes in the File testsrv.c were made:

If (OSA_ERR_OK= =osajbscdDeliver(jobId))

{

... // Wait for confirmation and result Queries

}

Has Been Replaced by the following section

Osaaddevent(/ * ID * / jobId,0,

/ * Type * / 1,

/ * Delay * / 1.0 ,

/ * Repeat * / 0.0 ,

/ * Timeout * /1,000 to

/ * Feature * /NULL);

If(1)

{

... // Wait for confirmation and result Queries

}

Now is the result: (with debug mode enabled, to represent the timing of the procedure)

+ +> Added ID: 8524656 delay: 1,000 Start: Sun Apr 08 9:48 PM:41,917

--> Started Event 8524656 with error: 1ms at Sun Apr 08 9:48 PM:41,918

Calculated 1+1

I received a 2!

+ +> Added ID: 8524656 delay: 1,000 Start: Sun Apr 08 9:48 PM:42,920

--> Started Event 8524656 with error: 0ms at Sun Apr 08 9:48 PM:42,920

Calculated 2+1

I received a 3!

+ +> Added ID: 8524656 delay: 1,000 Start: Sun Apr 08 9:48 PM:43,920

--> Started Event 8524656 with error: 0ms at Sun Apr 08 9:48 PM:43,920

Calculated 3+1

I received a 4!

As you can see, the test was successful, and also the temporal error that start when you are born, were within the tolerance: at a set of 2 Accuracy of the Ereignisdienstes milliseconds is a error of 1ms are allowed or not to be excluded.

5.9.2 Test run of a cyclical events with open

In this test is the response of the Ereignisdienstes on longer breaks in the System tested, and the duration of the interruption is in this test here in about 10 seconds, is checked, whether cyclic jobs after this interruption continue to be started correctly. In addition, there will be a demonstration of how the set/do not set of the 3, affects bits to the time difference.

First Test: Bit 3 = 0

Here is the associated function call:

Osaaddevent(/ * ID * / 1.0 ,

/ * Type * / 1+2,

/ * Delay * / 2.0 ,

/ * Repeat * / 0.10 ,

/ * Timeout * /10,

/ * Feature * / &test );

And the result after the start:

+ +> Added id: 1 delay: 9 Start: Sun Apr 22 12:50 PM:28,290 2001

--> Started Event 1 with error: 1ms at Sun Apr 22 12:50 PM:28,291 2001

Test OK

+ +> Added id: 1 delay: 9 Start: Sun Apr 22 12:50 PM:28,300 2001

--> Started Event 1 with error: 1ms at Sun Apr 22 12:50 PM:28,301 2001

Test OK

+ +> Added id: 1 delay: 9 Start: Sun Apr 22 12:50 PM:28,310 2001

--> Started Event 1 with error: 9804ms at Sun Apr 22 12:50 PM:38,114

-> Skipped due to timeout

+ +> Added id: 1 delay: 6 Start: Sun Apr 22 12:50 PM:38,120 2001

--> Started Event 1 with error: 0ms at Sun Apr 22 12:50 PM:38,120 2001

Test OK

+ +> Added id: 1 delay: 10 Start: Sun Apr 22 12:50 PM:38,130 2001

--> Started Event 1 with error: 0ms at Sun Apr 22 12:50 PM:38,130 2001

Test OK

+ +> Added id: 1 delay: 10 Start: Sun Apr 22 12:50 PM:38,140 2001

--> Started Event 1 with error: 0ms at Sun Apr 22 12:50 PM:38,140 2001

Test OK

Here you can see now that lasted 10 seconds after the interruption of the job is no longer started, because of the timeout has been exceeded, the time for the next start is now calculated so that the 10ms - Zeitgitter is respected.

Second Test: Bit 3 = 1

Here is the associated function call:

Osaaddevent(/ * ID * / 1.0 ,

/ * Type * / 1 +2+8,

/ * Delay * / 2.0 ,

/ * Repeat * / 0.10 ,

/ * Timeout * /10,

/ * Feature * / &test );

And the Test Results

+ +> Added id: 1 delay: 10 Start: Sun Apr 22 9:36 PM:26,359 2001

--> Started Event 1 with error: 0ms at Sun Apr 22 9:36 PM:26,359 2001

Test OK

+ +> Added id: 1 delay: 10 Start: Sun Apr 22 9:36 PM:26,369 2001

--> Started Event 1 with error: 1ms at Sun Apr 22 9:36 PM:26,370 2001

Test OK

+ +> Added id: 1 delay: 10 Start: Sun Apr 22 9:36 PM:26,380 2001

--> Started Event 1 with error:. with EN 10204ms at Sun Apr 22 9:36 PM:36,584 2001

-> Skipped due to timeout

+ +> Added id: 1 delay: 10 Start: Sun Apr 22 9:36 PM:36,594 2001

--> Started Event 1 with error: 0ms at Sun Apr 22 9:36 PM:36,594 2001

Test OK

+ +> Added id: 1 delay: 10 Start: Sun Apr 22 9:36 PM:36,604 2001

--> Started Event 1 with error: 1ms at Sun Apr 22 9:36 PM:36,605 2001

Test OK

+ +> Added id: 1 delay: 10 Start: Sun Apr 22 9:36 PM:36,615 2001

--> Started Event 1 with error: 0ms at Sun Apr 22 9:36 PM:36,615 2001

Test OK

In this test is now to see that no Zeitgitter more is present, and after the delay of 10 seconds no correction is applied, deleted a part of the calculation, so that this variant a little less processor time.

( However, is expected only on very slow systems make itself felt.

5.9.3 Test the maximum temporal resolution on different systems

5.9.3.1 System 1

Now here is tested in multiple passes, how high the maximum frequency of the calls on this system may be set, without that it comes to errors or problems.

The set of precision timer Ereignisdienstes: 1 millisecond.

Precision:1// The Event-Timer every millisecond is called

Cycle 1:

Set precision of the Ereignisdienstes :1 millisecond (precision= 1)

Set time difference of the Test-Events :1 millisecond.

Associated function call:

Osaaddevent( / * ID * / 1.0 ,

/ * Type * / 1+2,

/ * Delay * / 2.0 ,

/ * Repeat * / 0.1 ,

/ * Timeout * /10,

/ * Feature * / &test );

And the result of the test:

...

+ +> Added id: 1 delay: 1 Start: Mon Apr 23 12:28 PM:36,643 2001

--> Started Event 1 with error: 1ms at Mon Apr 23 12:28 PM:36,644 2001

Test OK

XX> Event 1 emergency added - Time Over

+ +> Added id: 1 delay: 2 Start: Mon Apr 23 12:28 PM:36,646 2001

--> Started Event 1 with error: 0ms at Mon Apr 23 12:28 PM:36,646 2001

Test OK

+ +> Added id: 1 delay: 1 Start: Mon Apr 23 12:28 PM:36,647 2001

--> Started Event 1 with error: 0ms at Mon Apr 23 12:28 PM:36,647 2001

Test OK

...

+ +> Added id: 1 delay: 1 Start: Mon Apr 23 12:28 PM:36,652 2001

--> Started Event 1 with error: 1ms at Mon Apr 23 12:28 PM:36,653 2001

Test OK

XX> Event 1 emergency added - Time Over

+ +> Added id: 1 delay: 2 Start: Mon Apr 23 12:28 PM:36,655 2001

--> Started Event 1 with error: 0ms at Mon Apr 23 12:28 PM:36,655 2001

Test OK

+ +> Added id: 1 delay: 1 Start: Mon Apr 23 12:28 PM:36,656 2001

--> Started Event 1 with error: 0ms at Mon Apr 23 12:28 PM:36,656 2001

Test OK

...

As you can see, does the start mostly, but it is out and back to errors, to now is the result of such a high request to improve the accuracy, would be the first consideration, to configure the job in such a way as to that of the Eventing service always the interval of one millisecond complies with with these settings, the test was not, however, the desired result, but there were still the same error.

The real problem here is that the performance was not sufficient, to all text output to be carried out within a millisecond after the text output were omitted in part, the test was almost flawless. There were still error on, but not more in 10ms increments, but only every few seconds; also the misconduct has improved: were it to the top 2 more failures per error, it is the case in the following test run only has one:

...

--> Started Event 1 with error: 0ms at Mon Apr 23 3:54 PM:29,198 2001

--> Started Event 1 with error: 0ms at Mon Apr 23 3:54 PM:29,199 2001

--> Started Event 1 with error: 0ms at Mon Apr 23 3:54 PM:29,200 2001

--> Started Event 1 with error: 0ms at Mon Apr 23 3:54 PM:29,201 2001

--> Started Event 1 with error: 0ms at Mon Apr 23 3:54 PM:29,202 2001

--> Started Event 1 with error: 0ms at Mon Apr 23 3:54 PM:29,203 2001

--> Started Event 1 with error: 1ms at Mon Apr 23 3:54 PM:29,205 2001

XX> Event 1 emergency added - Time Over

--> Started Event 1 with error: 0ms at Mon Apr 23 3:54 PM:29,207 2001

...

Cycle 2:

Set precision of the Ereignisdienstes :1 millisecond (precision= 1)

Set time difference of the Test-Events :2 millisecond.

Associated function call:

Osaaddevent( / * ID * / 1.0 ,

/ * Type * / 1+2,

/ * Delay * / 2.0 ,

/ * Repeat * / 0.2 ,

/ * Timeout * /10,

/ * Feature * / &test );

And the test results:

...

--> Started Event 1 with error: 0ms at Thu Apr 26 12:12:42,310 2001

+ +> Added id: 1 delay: 2 Start: Thu Apr 26 12:12:42,312 2001

--> Started Event 1 with error: 0ms at Thu Apr 26 12:12:42,312 2001

+ +> Added id: 1 delay: 2 Start: Thu Apr 26 12:12:42,314 2001

--> Started Event 1 with error: 0ms at Thu Apr 26 12:12:42,314 2001

+ +> Added id: 1 delay: 2 Start: Thu Apr 26 12:12:42,316 2001

--> Started Event 1 with error: 0ms at Thu Apr 26 12:12:42,316 2001

...

The test was properly here, without that it came to any errors, i.e. , when working with text files, at least on this system should be a time difference of 2 ms be between 2 Jobs

5.9.3.2 System 2

Here is to be tested, as the replacement of the operating system from Windows 2000 to Windows 98 is noticeable.

Cycle 1:

Set the precision Ereignisdienstes :10 milliseconds (precision= 10)

Set time difference of the Test-Events :100 milliseconds

Function call:

Osaaddevent( / * ID * / 1.0 ,

/ * Type * / 1+2,

/ * Delay * / 2.0 ,

/ * Repeat * / 0.100 ,// cyclic call every 100 ms

/ * Timeout * /10,

/ * Feature * / &test );

Test run:

In this test Sorry, no results could be collected, as the operating system is either refused the Test ( The Multimediatimer has not been activated ), or, if this time succeeded in, worked behind the exit and save the logs not, because the system remained at once.

Cycle 2:

Set of precision timer of the Ereignisdienstes: 100 milliseconds

Function call:

Osaaddevent( / * ID * / 1.0 ,

/ * Type * / 1+2,

/ * Delay * / 2.0 ,

/ * Repeat * / 1.0 ,

/ * Timeout * /10,

/ * Feature * / &test );

Test run:

...

+ +> Added id: 1 delay: involving 994 Start: Mon Apr 24 11:54 PM:07,000 1995

--> Started Event 1 with error: 6ms at Mon Apr 24 11:54 PM:07,006 1995

+ +> Added id: 1 delay: involving 994 Start: Mon Apr 24 11:54 PM:08,000 1995

--> Started Event 1 with error: Note No. 4465ms at Mon Apr 24 11:54 PM:12,465 1995// done manually delay

-> Skipped due to timeout

+ +> Added id: 1 delay: experienced 535 recorded Start: Mon Apr 24 11:54 PM:13,000 1995

--> Started Event 1 with error: 6ms at Mon Apr 24 11:54 PM:13,006 1995

+ +> Added id: 1 delay: involving 994 Start: Mon Apr 24 11:54 PM:than 14,000 1995

Started Event 1 with error: 1ms at Mon Apr 24 11:54 PM

...

The result shows that it is still possible, on a Windows 98 machine with the OSA to run event service, but may not be a high claims be made to the accuracy!

5.9.3.3 System 3

As there is a on Windows NT-based operating system present, can already at the beginning with a higher accuracy than in 9.3.2   be started.

Cycle 1:

Set precision of the Ereignisdienstes :1 millisecond (precision= 1)

Set time difference of the Test-Events :1 millisecond.

Function call:

Osaaddevent( / * ID * / 1.0 ,

/ * Type * / 1+2,

/ * Delay * / 2.0 ,

/ * Repeat * / 0.100 ,// cyclic call every 100 ms

/ * Timeout * /10,

/ * Feature * / &test );

Test run:

...

--> Started Event 1 with error: 1ms at Wed May 11 11:28:43,584 2001

-> Skipped due to timeout

XX> Event 1 emergency added - Time Over

+ +> Added id: 1 delay: 1 Start: Wed May 11 11:28:43,585 2001

--> Started Event 1 with error: 1ms at Wed May 11 11:28:43,586 2001

-> Skipped due to timeout

XX> Event 1 emergency added - Time Over

+ +> Added id: 1 delay: 1 Start: Wed May 11 11:28:43,587 2001

--> Started Event 1 with error: 1ms at Wed May 11 11:28:43,588 2001

-> Skipped due to timeout

XX> Event 1 emergency added - Time Over

+ +> Added id: 1 delay: 1 Start: Wed May 11 11:28:43,589 2001

--> Started Event 1 with error: 2ms at Wed May 11 11:28:43,591 2001

...

For this test it is clear that here, in this system even more errors have occurred, as in the same test on the first system. In a further test run however, again, as in 9.3.1 NFS Server Configuration file , that mainly blame the text output is to the late call, the same test with only a text per call will be as follows:

...

--> Started Event 1 with error: 0ms at Wed May 23 15:18:28,271 2001

--> Started Event 1 with error: 0ms at Wed May 23 15:18:28,272 2001

--> Started Event 1 with error: 0ms at Wed May 23 15:18:28,273 2001

--> Started Event 1 with error: 0ms at Wed May 23 15:18:28,274 2001

--> Started Event 1 with error: 0ms at Wed May 23 15:18:28,275 2001

...

So a much better result ( Timeouts came even before, however very much less than previously ). This is also the reason why should also sub-programs, the of of the timer function in so called short intervals are not too to take a lot of time.

Cycle 2:

In the following test was now the Aufruffrequenz halved, to test whether this time the attempt without Timeouts runs; the test environment is as follows:

Set precision of the Ereignisdienstes :1 millisecond (precision= 1)

Set time difference of the Test-Events :2 milliseconds

Function call:

Osaaddevent( / * ID * / 1.0 ,

/ * Type * / 1+2,

/ * Delay * / 2.0 ,

/ * Repeat * / 0.100 ,// cyclic call every 100 ms

/ * Timeout * /10,

/ * Feature * / &test );

Test run:

--> Started Event 1 with error: 0ms at Wed May 23 3:47 PM:34,566 2001

--> Started Event 1 with error: 0ms at Wed May 23 3:47 PM:34,568 2001

--> Started Event 1 with error: 1ms at Wed May 23 3:47 PM:34,571 2001

--> Started Event 1 with error: 0ms at Wed May 23 3:47 PM:34,572 2001

--> Started Event 1 with error: 0ms at Wed May 23 3:47 PM:34,574 2001

Here the test was now easily, although there were also late calls, but this had to literally be sought with the magnifying glass, in the absence of such an then time occurred, it wasn't too bad, because this delay is not Timerout led immediately to a.

5.9.4 Stability tests

5.9.4.1 Exceeding the maximum acceptable number of Events

For this test was the maximum allowable number of 255 entries now intentionally exceeded, to test the risk of errors:

Function call:

For(i= 0 ;i< 500 ;i++)

Osaaddevent( / * ID * / i .0,

/ * Type * / 1 + 2,

/ * Delay * / i + 2.0 ,

/ * Repeat * / 256.0 ,

/ * Timeout * /100,

/ * Feature * / &test );

Test run:

+ +> Added id: 0 delay: 2000 Start: Wed May 16 14:30:59,050 2001

+ +> Added id: 1 delay: 3,000 Start: Wed May 16 2:31 PM:00,050 2001

+ +> Added id: 2 delay: 4,000 Start: Wed May 16 2:31 PM:01,050 2001

...

+ +> Added ID: 252 delay: 254000 Start: Wed May 16 2:35 PM:11,050

+ +> Added ID: 253 delay: EUR 255000 per year Start: Wed May 16 2:35 PM:12,050

+ +> Added ID: 254 delay: The value 256000 Start: Wed May 16 2:35 PM:13,050

XX> Event 255 not added - table full

XX> Event 256 not added - table full

...

XX> Event 498m not added - table full

XX> Event 499 or fewer not added - table full

--> Started Event 0 with error: 0ms at Wed May 16 14:30:59,050 2001

+ +> Added id: 0 delay: The value 256000 Start: Wed May 16 2:35 PM:15,050 2001

--> Started Event 1 with error: 0ms at Wed May 16 2:31 PM:00,050 2001

+ +> Added id: 1 delay: The value 256000 Start: Wed May 16 2:35 PM:16,050 2001

--> Started Event 2 with error: 0ms at Wed May 16 2:31 PM:01,050 200

...

As you can see, the test run was successful, and there was no further difficulties

5.9.4.2 Exceeding the maximum acceptable number of events per unit time

It was here that the set from the beginning, the maximum number of 5 Events / Unit time maintained. An attempt is now to exceed this limit, a small difficulty with this attempt is that the add of the 10 events no longer than a millisecond should be allowed to take. This was the reason for this and the next attempt the test system 1 is selected.

Function call:

For(i= 0 ;i< 10 ;i++)

Osaaddevent( / * ID * / i .0,

/ * Type * / 1 ,

/ * Delay * / 1.0 ,

/ * Repeat * / 0.0 ,

/ * Timeout * /100,

/ * Feature * / &test );

Test run: ( System ( 1 )

+ +> Added id: 0 delay: 1,000 Start: Wed May 15 3:22 PM:08,072 2001

+ +> Added id: 1 delay: 1,000 Start: Wed May 15 3:22 PM:08,072 2001

+ +> Added id: 2 delay: 1,000 Start: Wed May 15 3:22 PM:08,072 2001

+ +> Added id: 3 delay: 1,000 Start: Wed May 15 3:22 PM:08,072 2001

+ +> Added id: 4 delay: 1,000 Start: Wed May 15 3:22 PM:08,072 2001

XX> Event 5 not added - too many events per Time

XX> Event 6 not added - too many events per Time

XX> Event 7 not added - too many events per Time

XX> Event 8 not added - too many events per Time

XX> Event 9 not added - too many events per Time

--> Started Event 0 with error: 0ms at Wed May 15 3:22 PM:08,072 2001

--> Started Event 1 with error: 0ms at Wed May 15 3:22 PM:08,072 2001

--> Started Event 2 with error: 0ms at Wed May 15 3:22 PM:08,072 2001

--> Started Event 3 with error: 0ms at Wed May 15 3:22 PM:08,072 2001

--> Started Event 4 with error: 0ms at Wed May 15 3:22 PM:08,072 2001

5.9.4.3 Overrun of the events per unit time through Zeituberschneidung

This test is similar in principle to attempt from 9.4.2 . above, however, the event service the overlap of the events do not immediately realize. The events are added so that you are all the events until a later date to a time overlap. Here is the behavior of the Ereignisdienstes tested to this situation and will be demonstrated, this is, of course, also the set / do not set of the 4, bits in the Typenfeldes depending on, here is the setting so that, if an error arises during the adding, then simply the closest possible time is selected as a start time (bit 4 is not set). In this example, the minimum delay between the various earliest starts 1 millisecond.

Since the test this time a bit longer, it was the result of the test for the better understanding still comments.

Function call:

For(i= 0 ;i< 10 ;i++)

Osaaddevent( / * ID * / i .0,

/ * Type * / 1+2,

/ * Delay * / 1+ i,0,

/ * Repeat * / 10- i,0,

/ * Timeout * /100,

/ * Feature * / &test );

Test run: ( on System 1.

1 Step: Add the 10 Events

+ +> Added id: 0 delay: 1,000 Start: Tue May 22 11:48 am:42,200 2001

+ +> Added id: 1 delay: 2000 Start: Tue May 22 11:48 am:43,200 2001

...

+ +> Added id: 8 delay: 9,000 Start: Tue May 22 11:48 am:50,200 2001

+ +> Added id: 9 delay: 10,000 Start: Tue May 22 11:48 am:51,200 2001

2 Step:because it is cyclic events, you will be

Re-added

--> Started Event 0 with error: 0ms at Tue May 22 11:48 am:42,200 2001

+ +> Added id: 0 delay: 10,000 Start: Tue May 22 11:48 am:52,200 2001

--> Started Event 1 with error: 0ms at Tue May 22 11:48 am:43,200 2001

+ +> Added id: 1 delay: 9,000 Start: Tue May 22 11:48 am:52,200 2001

--> Started Event 2 with error: 0ms at Tue May 22 11:48 am:44,200 2001

+ +> Added id: 2 delay: 8,000 Start: Tue May 22 11:48 am:52,200 2001

--> Started Event 3 with error: 0ms at Tue May 22 11:48 am:45,200 2001

+ +> Added id: 3 delay: 7,000 Start: Tue May 22 11:48 am:52,200 2001

--> Started Event 4 with error: 0ms at Tue May 22 11:48 am:46,200 2001

+ +> Added id: 4 delay: 6,000 Start: Tue May 22 11:48 am:52,200 2001

But since only 5 events/unit ( here 1 millisecond ) may be called, the remaining 5 to be launched later.

--> Started Event 5 with error: 0ms at Tue May 22 11:48 am:47,200 2001

XX> Event 5 not added - too many events per Time

+ +> Added id: 5 delay: 5,001 Start: Tue May 22 11:48 am:52,201 2001

--> Started Event 6 with error: 0ms at Tue May 22 11:48 am:48,200 2001

XX> Event 6 not added - too many events per Time

+ +> Added id: 6 delay: 4001 Start: Tue May 22 11:48 am:52,201 2001

--> Started Event 7 with error: 0ms at Tue May 22 11:48 am:49,200 2001

XX> Event 7 not added - too many events per Time

+ +> Added id: 7 delay: 3001 Focal point Start: Tue May 22 11:48 am:52,201 2001

--> Started Event 8 with error: 0ms at Tue May 22 11:48 am:50,200 2001

XX> Event 8 not added - too many events per Time

+ +> Added id: 8 delay: 2001 Start: Tue May 22 11:48 am:52,201 2001

--> Started Event 9 with error: 0ms at Tue May 22 11:48 am:51,200 2001

XX> Event 9 not added - too many events per Time

+ +> Added id: 9 delay: 1001 Start: Tue May 22 11:48 am:52,201 2001

3. Step:Here you just added the starts of the events, only to have a better overview the rows have been shown, in which the events are started.

--> Started Event 0 with error: 0ms at Tue May 22 11:48 am:52,200 2001

--> Started Event 1 with error: 0ms at Tue May 22 11:48 am:52,200 2001

--> Started Event 2 with error: 0ms at Tue May 22 11:48 am:52,200 2001

--> Started Event 3 with error: 0ms at Tue May 22 11:48 am:52,200 2001

--> Started Event 4 with error: 0ms at Tue May 22 11:48 am:52,200 2001

--> Started Event 5 with error: 0ms at Tue May 22 11:48 am:52,201 2001

--> Started Event 6 with error: 0ms at Tue May 22 11:48 am:52,201 2001

--> Started Event 7 with error: 0ms at Tue May 22 11:48 am:52,201 2001

--> Started Event 8 with error: 0ms at Tue May 22 11:48 am:52,201 2001

--> Started Event 9 with error: 0ms at Tue May 22 11:48 am:52,201 2001

5.10 Results and Outlook

By the enlargement to the event service is now the OSA+ a further major step in the direction toward real-time capability.

This makes it possible that now jobs or functions in an adjustable time in an adjustable time window can be started.

The maximum achievable accuracy is, however, limited by the underlying operating system on Windows 95 testing e.g. in the best case only 50 milliseconds, while under Windows 2000/NT even accuracies of up to 1-2 milliseconds were possible.

If necessary, you can also the jobs started in the same intervals be repeated.

This relatively high accuracy in Windows2000/NT is achieved by the fact that the event service functions to read/set that provides the time, which only during the initialisation of the C use the Standardzeitfunktion. Later, the time, then determined with the help of the system time, which is much more accurate.

This OSA - internal time is also necessary, since there may be times on the network need to be synchronized, and not the CMOS - clock of the system is to be affected.

If you have higher levels of accuracy should be needed, it is recommended that you the porting of the OSA+ on a Echtzeitplatform such as VxWorks or RT-Linux.

Then there are up to the factor of 10 higher accuracy possible and 100% guaranteed real-time capability.

5.11 ANNEX

5.11.1 List of all Windows specific functions

Here is a list of the Windows 95 / 98 / ME/NT/2000 specific functions in the porting to a different platform need to be replaced:

Timegettime()

Reads the current system time from ( milliseconds since startup ) and there is this as a 32-bit integer value back. ( due to the 32-bit, the value is 49.71 days all resettiert )

Timesetevent( PRECISION,1, TimerProc , 0, TIME_PERIODIC );

This function is responsible for ensuring that the Mutimediatimer of the Windows is initialized and then in definable intervals ( here:precision ) the timer function ( TimerProc ) invokes the timer function has on the basis of the fixed parameters therefore look like the following:

Void callback TimerProc(UINT uid, UINT uMsg, DWORD dwUser, DWORD DW1, DWORD DW2 ) ;

The Windowsspezifischen variables are passed but not evaluated further.

( What the implementation should facilitate to other platforms.

5.12 Literature

[Brinks et al, 00]Brinkschulte, Krakowski, Riemschneider, "The OSA+ architecture", Internal Report, Institute for microcomputer and automation, Uni-Karlsruhe , 28 March 2000)

6 Inertial Measurement Unit

Based on Mohammad Subhan, "Building a inertial measurement system for an experimental environment", Diploma Thesis, 2001/2002, Karlsruhe University of Applied Sciences

University of Technology

Table of Contents i

List of figures: iii

List of Tables iv

1 Introduction 1

1.1 Task 2

1.2 Overview................................................................................................... 2

2 Basics 3

2.1 Coordinate System.................................................................................... 4

2.2 Calculation of the current position.......................................................... 6

2.3 Compass.................................................................................................... 7

3 Architecture design of the IMU 8

3.1 Meßdatenaufnahme.................................................................................. 8

3.2 Meßdatenaufbereitung.............................................................................. 8

4 Development environment 10

4.1 Hardware-Entwicklungsumgebung...................................................... 10

4.2 Software Development Environment.................................................... 11

5 Realization of the IMU 12

5.1 Meßdatenaufnahme................................................................................ 12

5.1.1 Circuit Design for the Meßdatenaufnahme................................. 12

5.1.1.1 Acceleration Sensors................................................................... 13

5.1.1.1.1 Rather than focusing solely on the accelerometer 14

5.1.1.1.2 Laying down the bandwidth of the accelerometer 15

5.1.1.1.3 Definition of the period duration of the accelerometer 15

5.1.1.2 The roundabout and the filtering their output signals............. 16

5.1.1.2.1 Calculation of the order Butterworth 17

5.1.1.3 The Kompaßsensoren and filtering their output signals........... 18

5.1.1.4 Reference Voltage....................................................................... 20

5.1.2 Board layout design for the Meßdatenaufnahme........................ 21

5.2 Meßdatenaufbereitung............................................................................ 23

5.2.1 Circuit Design for the Meßdatenaufbereitung............................. 24

5.2.1.1 Supply Voltage............................................................................ 24

5.2.1.2 Reference Voltage....................................................................... 24

5.2.1.3 Memory....................................................................................... 24

5.2.1.4 Jumper Settings........................................................................... 26

5.2.2 Board layout design for the Meßdatenaufbereitung................... 27

5.2.3 The software for the Meßdatenaufbereitung............................... 29

5.2.3.1 States and state transitions of the program............................... 30

5.2.3.2 Analysis and Design with SA (Structured Analysis) / SD (Structured Design) 31

5.2.3.3 User Interface.............................................................................. 32

5.2.3.4 Collection of data of the acceleration sensors........................... 34

5.2.3.4.1 Decoding of the outputs of the acceleration sensors 34

5.2.3.4.2 Calculation of the acceleration with high accuracy 35

6 Test Results 37

6.1 Hardware-Test........................................................................................ 37

6.2 Test of the overall system with the microcontroller (C167).................. 38

6.2.1 Gesamtsystem-Test 1..................................................................... 38

6.2.2 Gesamtsystem-Test 2..................................................................... 40

6.2.3 Gesamtsystem-Test 3..................................................................... 40

7 Summary and outlook 42

List of figures:

Fig 1: translational and rotational motion parameters. 3

Fig 2: Euler-Winkel 4

Fig 3: Spatial Representation. 6

Fig 4: Earth's magnetic field. 7

Fig 5: The architecture of the IMU the "Alternate Lotte". 8

Fig 6: Development Environment for the hardware development; EAGLE Layout Editor. 10

Fig 7: Development Environment for the software development; µVision2 Text Editor. 11

Figure 8: Block diagram of the Meßdatenaufnahme. 12

Figure 9: Block diagram of the Beschleunigungsaufnahme. 13

Fig 10: Embedding an accelerometer. 14

Fig 11: Block diagram of the Winkelgeschwindigkeitsaufnahme. 16

Fig 12: circuit for the Winkelgeschwindigkeitsaufnahme. 17

Fig 13: Butterworth. 18

Fig 14: Block diagram of the heading indicator. 19

Fig 15: on-chip component of the Kompaßsensors. 19

Fig 16: Set/reset circuit for the Kompaßsensor. 20

Fig 17: Reference Voltage. 21

Fig 18: Komponentenbesetzung on the circuit board 1 and 2. 22

Fig 19: Platinenansicht of IMU-overall system.. 23

Fig 20: Block diagram of the Meßdatenaufbereitung (Sensordatenaufbereitung) 23

Fig 21: circuit for the Eingangsspannungsuberwachung. 25

Fig 22: serial interface will be started. 26

Fig 23: component side of the Mikrocontrollerboards. 28

Fig 24: solder side of the Mikrocontrollerboards. 28

Fig 25: Environment of the microcontroller. 29

Figure 26: state diagram for the Meßdatenaufbereitungs-Software. 30

Fig 27: User Interface of the IMU for testing purposes. 33

Fig 28: Sensor Output of ADXL210. 34

Fig 29: the accelerometer, in X-direction. 38

Fig 30: the accelerometer, in Y-direction. 39

Fig 31: the accelerometer, in Z-direction. 39

Fig 32: the accelerometer, in X-direction. 40

Fig 33: the accelerometer, in Y-direction. 41

Fig 34: the accelerometer, in Z-direction. 41

List of Tables

Table 1: Bandwidth. 15

Table 2: Resistance values for the setting of the period. 16

Table 3: jumper settings on the microcontroller board. 27

Table 4: Results of the gyros. 37

6.5 Realization of the IMU

In this chapter will be the implementation of the Advanced Inertial Measurement System explains. After the block diagram of the Meßdatenaufnahme Meßdatenaufnahme is the shifting of the presented, the individual parts of the circuit are described in detail, on the same principle will be the implementation of the described Meßdatenaufbereitung and, in the case of the Meßdatenaufbereitung even the description of the developed software on the Microcontroller is added.

6.5.1 Meßdatenaufnahme

The task of the Meßdatenaufnahme consists in, and the movement of the airship and the earth's magnetic field to capture the Meßdatenaufnahme is composed of three acceleration sensors, three roundabouts and three magnet sensors together.

Figure 8: Block diagram of the Meßdatenaufnahme

For the adaptation of the Sensorensignale Meßdatenaufbereitung to the additional Signalanpassungsschaltungen be required.

6.5.1.1 Circuit Design for the Meßdatenaufnahme

The whole circuit for the Meßdatenaufnahme is shown in Annex A, the following are the individual areas of the circuit described in more detail.

Acceleration Sensors

Accelerometers measure, as the name already says, the rate of change of velocity, by creating electronic signals, the measured or to control a process can be used, and traditional applications include the activation mechanisms of safety belts and air bags, in which the sudden deceleration of the accelerometer which is responsible for the security techniques in gear sets.

The above sensors use a mechanism, the with of the elongation of a spring can be compared, the force, by the acceleration due to is, extends the spring, with a higher acceleration is even more stretched the spring. The measurement of the Deformationslangen and the acceleration can be determined.

Figure 9: Block diagram of the Beschleunigungsaufnahme

The ADXL210 is a "low cost" 2Achs-Beschleunigungssensor with low power consumption, and the measurement is between - 10g and +10G. The special on the ADXL210 are the digital outputs on the two axles, the outputs are digital signals, whose length (ratio of the pulse width to the period) proportional to the acceleration in two axles are. These outputs can directly be measured with a Mikrocontroller-Zahler. There is no ad-converter needs. The Arbeitszyklusmodulator (DCM) has a resolution of 14 bits, based on this special properties, the acceleration with a simple schema record. After Fig. 9 , the digital outputs of the sensor to the microcontroller directly connect the circuit for the embedding of such an accelerometer is in the figure 10 shown.

The ADXL210 is to configure the following: the length of the period and the bandwidth of the signal output (e.g. , elimination of high-frequency vibrations). These settings are described below.

Description: accel

Fig 10: Embedding an accelerometer

The error behaviour of the acceleration sensor

The sensor failure da of the ADXL210 is in general from a scale factor error k, a bias B and a stochastic noise process w , so that the error can be described as follows:

There is a possibility, before each experiment to determine the bias, so can the error with a much lower bias be assessed, as without this information.

Laying down the bandwidth of the accelerometer

The ADXL210 from Analog Device is set to 100 Hz bandwidth. This setting is By Cx and Cy (here C10 and C11 connector, see 10), determines, two capacities are to pin 11 (Yfilt) and 12 (Xfilt) connected, and the calculation of the capacity is as follows:

( 51‑ )

( 52‑ )

Bandwidth	Capacity
10 Hz	0.47 mF
50 Hz	0.10 mF
100 Hz	0.05 mF
200 Hz	0.027 mF
500 Hz	0.01 mF
5 Khz	0.001 mF

Table 1: Bandwidth

Definition of the period duration of the accelerometer

The length of the period at the sensor output is determined by a resistance Rset (in the image R23+R24+R25), is connected with the GND, the equation is then:

( 53‑ )

T2	Rset
1 MS	125 KW
2 MS	250 KW
5 MS	625 KW
10 MS	1.25 MW

Table 2: Resistance values for the setting of the period

The gyro and the filtering their output signals

The angular velocity with a roundabout you can be record. This recording is in the Fig. 11 shown to adapt it to the microcontroller a Butterworth filter be added and an amplifier.

Fig 11: Block diagram of the Winkelgeschwindigkeitsaufnahme

The "heart" of the gyroscope is a Keramikstab, which, in its longitudinal axis is brought to vibrate, the rod is in two places with Metallgabeln welded to the "nodal point" of the rod are, and when the rod to rotate is placed on the vertical plane to a vibration appears through influence, the with the angular velocity is the same, the on the rod mounted piezo-electric plates are both a way to swing the rod longitudinal to bring, as well as the vibration generated by the appears through influence on the vertical plane should be repealed, and the voltage, the repealing of the vibrations on the vertical level is necessary, there is information on how fast the rod (and therefore, the gyroscope) is turning. The gyroscope in this way creates an output voltage that is proportional to the angular velocity is.

Description: kreisel_1

Fig 12: circuit for the Winkelgeschwindigkeitsaufnahme

The output of the Kreisel-Sensors is an analog voltage to Noise-Reduzierung and the antialiasing is the sensor a Butterworth filter 2. Ok downstream and the resulting signal is output through a 1.2 -fold at the amplifier AD-converter led of the microcontroller, you used to strengthen a IC of analog device of the type OP491.

The Butterworth filter is used only resistors and capacitors with fault tolerance of 1 %. This is necessary, because of the filter must be exactly in the calculation of the resistors and capacitors are C1 with 22 nF and C2 with 100nF commanded. Based on these values can then the values of the other resistors be determined.

Calculation of the order Butterworth

( 54‑ )

( 55‑ )

( 56)‑

The following constants are specified:

A0 = 1; a1 = 1.4142 ; b1 = 1

Description: butterworth

Fig 13: Butterworth

As a fixed values has been C1 with 22 nF and C2 set with 100 nF. It follows after the forming of equation ( 56):‑

( 57‑ )

As a last then you can R3 calculate

( 58‑ )

The Compass sensors and filtering their output signals

The current direction of the airship can be seen, in which you have a sensor that the magnetic field on the surface of the earth measures, uses, this compass is in the figure 14 briefly presented. With a instrumentation amplifier is the output signal from the sensor connected to the microcontroller.

Fig 14: Block diagram of the heading indicator

Magnetoresistic sensors from Honeywell are simple bridge connections (Figure 15), the only an input voltage need to to measure magnetic fields, and if a voltage from 0 to 10 volts to Vbridge is connected, begins to the sensor, a magnetic fields to measure in the environment. In addition, the sensor two "on chip straps", the offset and the Enter reset switch.

Description: bridge_hmc

Fig 15: on-chip component of the Kompaßsensors

The offset-bridge can be different operating modes, if a DC by the offset-bridge flows. An unwanted, but known magnetic field can be subtracted out.

Description: set_hmc

Fig 16: Set/reset circuit for the Kompaßsensor

The Set/reset (S/R) can be a high current pulses, which are then very useful, if the sensor in a highly sensitive work mode can be, and most magnetic sensors, measure the low field strengths, are influenced by larger magnetic fields (> 4 - 20 gauss), the can lead to a Ausgangssignalverminderung. In order to to reduce this effect, and to the signal at the output to maximize, can a magnetic circuitry (Fig 16) on the S/R will be applied, the eliminated the effect, with the help of IRF7105 brings top is at the exit of the Set/reset circuit with a power output of approximately 3A present, the purpose of Set/reset (S/R) is more sensitive to the sensor back to make small field strengths. This is accomplished, by a large current through the S/R pulsates.

6.5.1.2 Reference Voltage

The analog output signals of the sensors require a reference voltage, this reference voltage is the building block by UM780 AD generated, as both Referenzspannungerzeuger, as well as use Temperaturanderungssensor. By AD780 is a Ultrahochprazision "Bandgap" generated reference voltage, the 2.5 V or 3.0 V provides. The required input voltage can be between 4-36 volts.

Description: ref_spannung

Fig 17: Reference Voltage

In addition to the reference voltage generated of the AD780 is still a further output voltage, the correlated with the temperature difference (in fig 17This is the output (A3), A3 provides a voltage, is dependent on the linear of temperature fluctuations, it is intended to help the non-linearity of the sensors to correct with the help of the data sheets and data collected.

A room temperature of 25 C is the outlet temperature voltage of 560 mV (according to the data sheet) with a "temperature sensitivity" of 1.9 mV/°C, since the reference voltage of 2.5 volts and AD-converter of the microcontroller a resolution of 10 Bit has, the system has a resolution of:

To the capture of signals to simplify, was elected an amplifier of 2.47 (see Figure 17), that are each temperature changes ensures that you can be covered, a + 1 C temperature change then caused a change in voltage at the output of + 4.7 mV. during the room temperature is the output voltage: 1.48 V.

6.5.2 Board layout design for the Meßdatenaufnahme (Measurement data collection)

The three a wide array (acceleration sensors - Drehwinkelmessung and telemetry, magneticfield measurement, etc.) each have three components (each for the measurement in the x-, Y-and z-direction). In all three Sensorpaketen the sensors must be (responsible for the Meßdatenaufnahme) also in the direction of the corresponding spatial axs (X, Y, and z-axis) be aligned, i.e. , that a package two sensors (e.g. , for the Meßdatenaufnahme in x and y-direction) in a plane, and the third sensor ( e.g. for the Meßdatenaufnahme in Z-direction) in a vertical plane.

This can be realized by two sensors each of the three a wide array on a circuit board and the third sensor placed all three a wide array on a second board, perpendicular to the first circuit board is mounted.

Fig 18: Komponentenbesetzung on the circuit board 1 and 2

Fig 19: Platinenansicht of IMU-overall system

6.5.3 Meßdatenaufbereitung

Fig 20: Block diagram of the Meßdatenaufbereitung (Sensordatenaufbereitung)

6.5.3.1 Circuit Design for the Meßdatenaufbereitung

The Meßdatenaufbereitung is with a microcontroller (with additional memory and peripheral components) are realized.

The shift, the the microcontroller with the additionally required memory and peripheral components connects, is listed in Appendix B, the following are the individual sections of the circuit described in more detail.

Supply Voltage

Supply voltage is used as a component of the type 78M05. In the component is an input voltage between 7.5 volts and 12 volts input. As a output voltage is 5 volts, all components work with 5 volts of power. The pins of the inputs are via the jumpers JP2 and JP6 (see Figure 23). A LED can the jumper JP7 to be connected, the lit LED indicates that the supply voltage is working properly.

Reference Voltage

For the reference voltage there are two possibilities: either the supply voltage of 5 Volt be used as a reference voltage, or it can be connected a separate reference voltage, which can be selected by jumper settings (see JP10 in JP11 in the table 3). If you feed a own reference voltage, which will not exceed 5 volts, there is no 22 Pin of connector SV2 is available (see table 9 ).

Memory

The microcontroller is to 256 KByte ROM (2 blocks per 128 Kbytes) and 256 KByte RAM equipped. The used Rome is of the type 681000, the RAM of the type 29F010 of the Philips company, with the power supply of RAM was a second supply voltage available to potential losses to avoid the memory, and the building block MAX690 machines only (by Maxim) takes on this task (see Figure 21). The output Vout of the module MAX690 machines only there is a constant output voltage from. As soon as VCC is less than 5 volts, the building block to battery power, this will allow the data from the RAM, a data loss by shutdown or weakening of the input voltage is avoided, however.

Description: max690

Fig 21: circuit for the Eingangsspannungsuberwachung

For a connection with other computers or for the programming of the flash RAM, a serial interface and a CAN-bus to the board appropriate. Instead of a port a CAN-bus the connection can also used as a second serial interface be. The first interface X1 (see Figure 22) is the first serial port interface X2 can be either as a CAN-interface or as a second serial interface operated. The switchover is by JP3 and JP4.

Description: serial

Fig 22: serial interface will be started

Jumper Settings

The microcontroller board can be configured with different jumper settings, and there is still an additional switch to the RAM or the Rome to configure.

The jumper settings have the following functions:

	Default Setting		Alternative setting
JP1	(1 +2)	CAN-VCC generated by Supplay	(2 +3)	CAN-VCC generated by CAN-network via DB9-X2
JP8 JP9	(2 +3)	DB9-X2 works as CAN	(1 +2)	DB9-X2 works as a second serial specific
JP10	(1 +2)	VAREF generated by VCC	(2 +3)	VAREF generated by external Suplay on SV2
JP11	(1 +2)	RGND generated by DGND	(2 +3)	RGND generated by external earth via SV2

Table 3: jumper settings on the microcontroller board

6.5.4 Board layout design for the Meßdatenaufbereitung

As for the components of the Meßdatenaufbereitung no special spatial directions (as in the Meßdatenaufnahme) are required, the entire Meßdatenaufbereitung on a sufficiently large board will be realized.

It shows that the whole circuit for the Meßdatenaufbereitung on a four-layered EURO-board is to realize.

The first of the four layers is the Bestuckunsseite, an interlayer is the ground, a second intermediate layer is connected to the supply voltage, and the fourth layer is used as a solder.

Description: uc_board

Fig 23: component side of the Mikrocontrollerboards

Description: uc_board_bottom

Fig 24: solder side of the Mikrocontrollerboards

6.5.4.1 The software for the Meßdatenaufbereitung

The actual Meßdatenaufbereitung is realized by a software on the microcontroller (C167) expires.

Signals from sensors are recorded and edited, depending on the switch settings will be different operating modes, and forwarded to multiple LEDs (i.e. , the LEDs show the current mode). The edited data is then given to the serial interface.

Fig 25: Environment of the microcontroller

States and state transitions of the program

Figure 26: state diagram for the Meßdatenaufbereitungs-Software

CALIBRATION

In this condition, the initialized and/or calibrated sensors. In the acceleration sensors is the period on the DCM-output measured. The IMU must once again to the x-, Y-, and z-axis will be rotated, this will determine the force of gravity, the later in the Gravitationskompensation is used.

The system can be moved in the Calibration-Zustand, by the START_ Calibration-Befehl there is, after turn of the IMU can then this state with a stop Calibration-Befehl be terminated after calibration, the system in the READY_MEASURE-condition.

READY_MEASURE

This condition is considered a transition state, it will be no data from the sensors detects. This operating mode is used only for the preparation of the next status. With the command START_MEASURE the system goes to the next state.

The condition READY_MEASURE can only be achieved if the system has already been calibrated, which means that the condition is never reached, if the system has not yet been calibrated, which makes it the faulty measurement of the sensors prevent another transition in the calibration state calibration is possible, however, in the man the Start_calibratoin-command is there.

Measure

In this condition in certain periodic cycles, is the data collected by the sensors, after error correction, and calculations (Meßdatenaufbereitung) are the data obtained on the serial interface given. This you get the current measured data on the serial interface.

Analysis and Design with SA (Structured Analysis) / SD (Structured Design)

The program processes the data from the sensors and then you are to the serial interface, the user can use serial interface defined commands to the microcontroller to the program of a condition to put in the other (see Fig 26).

You can also reach a transition of the program, in which various switch, the with pins of the microcontroller are connected, actuated. Whether the command over the serial interface or the of a switch has a higher priority, can be set a separate switch, should be in the General commands via the serial interface have priority.

The processes of the system are in the following SA-graph (circles mean functions or processes, arrows mean data flows):

6.5.4.2 User Interface

The user interface is used for the test case for this purpose, to communicate with the microcontroller, so between the different modes can be switched.

Description: user_int

Fig 27: User Interface of the IMU for testing purposes.

The user has the option, the system with five different commands to affect:

Show

The formula s= 1/2 a t² the user receives in the primitive test case the current position in relation to a starting position, in which the Board at the start of the program was. This command can only be executed when the system is already calibrated and has been started.

Clear

Sets all readings back to zero, so a new measurement can be started, if you have already been calibrated.

Start calib.

The system is brought into the calibration mode, the sensors must now by hand to the rotary axs (X-, Y-, and Z-axis) be rotated once.

Stop calib.

Let the program go to a condition when loaded and ready to launch.

Start

Starts the Measurements

Collection of data of the acceleration sensors

In the collection of the accelerometer data a special procedure is necessary.

Roundabout, Kompaßsensoren and temperature and/or reference voltage are on to the AD-converter of microcontroller connected, and the data that will be without a special routine converted into a digital form.

Decoding of the outputs of the acceleration sensors

The outputs of the acceleration sensors are in the form of digital signals before. This is used for decoding a special routine necessary.

Description: adxl_signal

Fig 28: Sensor Output of ADXL210

To the two components of a accelerometer to determine, you need to have the Signallangen of T1 and T2 of the two outputs of the sensor (see Figure 28). A counter will be with the rising edge of the x-output (Ta = 0) started. The count on the signal covered (TB) is stored during running timer, the contents of Timer is on the following rising edge of the x-output (TC) is stored and, at the same time stopped, a process which will then for the Y-output repeatedly (TD, TE and Tf).

T1 and T2 are then easily calculated with the following formulas.

( 59‑ )

( 510‑ )

In normal use, if no high accuracy is required, you can the acceleration with the following simple Naherungs-Formel calculate (see [ 4] ):

( 511‑ )

Calculation of the acceleration with high accuracy

With the given "low cost" sensors can be a high level of accuracy only achieved by a suitable software will be in accordance with the data sheet of ADXL210 is to achieve a higher level of accuracy, the following routine to use in the process (see [ 4] ):

At the beginning the system should be placed in the Kalibrier-Zustand, and then with each component of the Beschleunigungs-Sensors be made the following:

The Komponenten-Richtung lies horizontally, then slowly to the sensor is full 360o rotated, and in such a way that the Komponenten-Richtung the zenith (direction that is perpendicular to the top) cuts. If the Komponenten-Richtung in the Zenit shows, should measure the accelerometer -1g, according to +1g, if the Komponenten-Richtung vertically downwards.

Meaning of the variables in the following formulas:

T2cal		The value of T2 during the calibration.
Zcal		The 0 g of T1 during the calibration.
Bit scale factor		Bitnormierungsfaktor
K		Scale Factor

( 512‑ )

( 513‑ )

The current acceleration can be calculated as follows:

( 514‑ )

Where:

( 515‑ )

7.5 Realization of the ACU

In this chapter is the realization of the actuator control Unit (ACU) explains the five blocks of the ACU (see Figure 14) is as follows: First, it presented the block diagram, for the blocks "Voltage regulation", " Basisbetriebszustands-Einstellung " and " Notsteuerungs-Baugruppe " is the respective circuit presented, and the individual parts of the circuit described in detail in blocks " Betriebsspannungs-Überwachung " and " Steuersignal-Erzeugung " is only described the Software on the microcontroller expires because the Board for the latter 3 blocks off-the-shelf was concerned, and only the programming of the microcontroller to an established part of the present work was.

7.5.1 Versorgungsspannungs-Stabilisierung

Fig 17: Block diagram for the " Versorgungsspannungs-Stabilisierung "

Figure 17 shows the assembly " Versorgungsspannungs-Stabilisierung ", which the remaining blocks of the ACU with a constant voltage of +5V supply, as well as provides this assembly to ensure that the power supply for a certain time is maintained, after the Normal-Betriebsspannungsversorgung not more is fully functional, and this is done in that the " Versorgungsspannungs-Stabilisierung " in this case, the remaining elements of the ACU to the Notbetriebsspannungsquelle connects.

7.5.1.1 Circuit Design for the Versorgungsspannungs-Stabilisierung

Fig 18: circuit " Versorgungsspannungs-Stabilisierung "

The circuit for the Versorgungsspannungs-Stabilisierung consists of six areas (see figure above, the ranging numbers are there circled):

1. Connection to the supply voltage for the ACU (Normal and Notbetriebsspannungsversorgung)

2. Stabilization of the supply voltage for the Blocks " Betriebsspannungs-Überwachung " and " Steuersignal-Erzeugung " (i.e. , for the microcontrollers, since these two blocks to the Microcontroller are implemented)

3. Stabilization of the supply voltage for the Blocks " Versorgungsspannungs-Stabilisierung ", " Basisbetriebszustands-Einstellung " and " Notsteuerungs-Baugruppe " (i.e. , for those blocks, the hardware are implemented, and while on a common board)

4. Connection to the remaining blocks of the ACU (left series: Connections to the microcontroller, i.e. , to " Betriebsspannungs-Überwachung " and " Steuersignal-Erzeugung "; rights series: Connections to the blocks "voltage stabilization", " Basisbetriebszustands-Einstellung " and " Notsteuerungs-Baugruppe " ), to the stabilised voltage with this to supply.

5. Connection to the supply voltage for the actuators (Normal and Notbetriebsspannungsversorgung)

6. Toggle switch from normal operation to Notbetriebsspannungsversorgung

Circuit Description The Schaltungsbereiches for the supply of the Mikrokontrollers (Schaltungsbereiche 1-4, upper half of the pattern thus activating):

Relay K1 switches battery 1 (soldering tag LSP1 +Pol, and LSP2 -pol) and the battery 2 (soldering tag LSP3 +Pol, and LSP4 -pol) using Digitalport P2.7 to ( ' 1' = Battery 2 enabled). The charge level of the battery voltage Vc is by the voltage divider R1 + R2 on the analog port P5.0 measured (VIN 1/3 VC), with the voltage divider R4 + R5 can be an internal voltage activated, the supply of the Capcom is carried out by the +5V voltage regulator IC1 which are Umschaltspitzen with the capacitor C1 smoothed, the supply of the internal logic is made with the regulator IC2, the in addition to the highly-capacitive Pufferkondensator HICAP1 in total voltage drop is supplied to the servos in a defined location, see figure 18.

Circuit Description The Schaltungsbereiches for the supply of the actuators (servos and engine) (Schaltungsbereiche 5, left, the lower quarter of the pattern thus activating):

Relay K7 switches battery 3 (soldering tag LSP5 +Pol, and LSP6 -pol) and battery 4 (soldering tag LSP7 +Pol, and LSP8 -pol) using Digitalport P2.6 or higher ( ' 1' = Battery 4 enabled). The battery charge the battery voltage vs is by the voltage divider R6 + R7 at the analog port P5.1 measured (Vin Ca Aprx 1/3 Vs). The LSP9 ( +pol) and LSP10 ( -pol) is connected the supply of the governor.

7.5.2 Betriebsspannungsuberwachung

The "Betriebsspannungsuberwachung" monitors, whether and when the required operating voltage falls below a particular level, at the the blocks of the ACU not more properly can be supplied.

Fig 19: Block diagram for the Betriebsspannunguberwachung

The Betriebsspanunnungsuberwachung software is purely realized with a program, which expires on the microcontroller, the Microcontroller uses up to a A/D-converter, which is also on the PHYTEC-test board is located, to current, analog voltage level in a digital number to convert, then finally the with the help of a Mikrocontroller-Programms is compared with a threshold value, the digitized current voltage level is less than the threshold, a signal is generated on the output of the microcontroller, which is by the Block " Versorgungsspannungs-Stabilisierung " is directed, and there causes that on "Notversorgungsspannung" is switched.

Fig 20: for the Betriebsspanunnungsuberwachung Programmablaufplan on the µC

Figure 20 shows the µC-program for the Betriebsspannungsuberwachung. The same program is used for both the Betriebsspannungsuberwachung the Aktorik-Spannungsversorgung , as well as for the Betriebsspannungsuberwachung the ACU-power supply used. The two analog Meßeingange for the two power supplies are available at two different channels of the ADCs and will be gradually converted by the ADC and the ADDAT in-register of the microcontrollers written (Single conversion mode of the ADC, see Ch. 2).

The microcontroller still works at a supply there must be a pause of. That is why the 4.76 V. Microcontroller are used to a voltage fell below below the 5V-border to detect and respond to it.

7.5.3 Basisbetriebszustands-Einstellung

Using a switch, the on a separate channel (channel 5) of the remote control is pressed, the distributor of the " Basisbetriebszustands-Einstellung " with either normal operation (contains normal operation and normal operation (A B) or with Luftschiff-Startphasen -operation be initialized when Luftschiff-Startphasen operation, the PWM signals from Fernsteuerungsempfanger switched directly to the actuation system (to override of the microcontroller of the block " Steuersignal-Erzeugung " ), during the flight can Fernsteuerungskanal 5 between Luftschiff-Startphasen -operation and normal operation be switched in both directions, if neither control signals (PWM signals) at the output of the block "Steuersignalerzeugung", nor on the channel5-output of the Fernsteuerempfangers concerns, the finite state machine of the " Basisbetriebszustands-Einstellung " the system, in the Condition " Notsteuersignal-Erzeugung - level 2" (i.e. , hardware production of Notsteuersignalen) move to (state transition Notsteuersignal-Erzeugung normal operation after - level 2).

Fig 21: Block Diagram " Basisbetriebszustands-Einstellung " with Environment

Figure 22 shows the state diagram for the distribution of the " Basisbetriebszustands-Einstellung ":

Figure 22: state diagram for the manifold of the " Basisbetriebszustands-Einstellung " (see fig 13 in section 3.6 below).

7.5.3.1 Circuit Design for the Basisbetriebszustands-Einstellung

Figure 23: Part 1 of the switch between Luftschiff-Startphasen -operation and normal operation (LSB/NB-switch, part1)

Description: Umsch.E-A

Fig 24: Part 2 of the switch between Luftschiff-Startphasen -operation and normal operation (LSB/NB-switch, part2)

Transition from startup, after LSB or NB and between LSB and NB (see Figure 23):

The PWM-signal of Fernsteuerungskanal 5 is from the output P2.5 of the Fernsteuerungsempfangers on the entrance to the LSB/NB-switch (in Figure 24 with P2.5 refers). In the LSB/NB-switch is depending on the length of the PWM-signal greater than 1.5 ms: LSB; smaller than 1.5 ms: NB) of the output 12 (C/_Ext) of his flip-flop module IC7B on high or low (see Figure 23) is set, this line of the flip-flops, with the gate input is insulated (C/_Ext) of the Fett-Kondensators Q7 (see 24) connected. The FET controls the relay K2 and K4, and K2 can be either a interconnection of the Fernsteuerkanale 1 and 2 (P2.1 and P2.2) to the rudder and the engine or but the connection of the rudder and the engine to the outputs P8.2, P7.0, P8.3 and P7.1 of the microcontroller, K4 has the same effect as K2, but not for the rudder and the engine, but for the two Hohenruderhalften (elevators 1 And 2).mm

Transition from NB or LSB Notsteuersignal-Erzeugung - level 2 (see Figure 23):

If neither PWM signals at the output of the ACU concerns, nor PWM signals over Fernsteuerungskanal 5, interrupt the relay K3 and K5 the connections to the relay K2 and K4 and connect the actuators with the Block " Notsteuersignal-Erzeugung - level 2 ".

Table 3: summarizes the inputs and outputs of the LSB/NB-switch together:

7.5.4 Steuersignal-Erzeugung

In Abschn.3.3 was the architecture of the " Steuersignal-Erzeugung raised before the description of the off-the-job training Shelf-Hardware and the design of the software components of the " Steuersignal-Erzeugung " is moved, here is to again on the architecture of the " Steuersignal-Erzeugung " be received, and also some of the things added:

The Block "Steuersignalerzeugung" generated depending on the operating status on various way control signals (PWM signals), the directly the actuators (engine, servos) response:

· In normal operation A gets the "Steuersignalerzeugung" commands from manifold of the " Basisbetriebszustands-Einstellung " and generates control signals (i.e. , PWM signals)

· In normal operation B are control signals (i.e. , PWM signals) from Fernsteuerungsempfanger (by the microcontroller through) activated and forwarded to the actuators, the Microcontroller is used here as Signal-Begrenzer and observers.

· At the system startup to the normal operation B is initialized, if on channel 5 "Normal mode" is set, and the further operation may, at any time from normal operation B switch to normal operation a be and vice versa, and this is done by setting from the N/R-machine from the N/R-computer receives this information on his communication system from the ground (not from the remote control).

· If in normal operation A or normal operation B due to the failure or failure of the N/R-computer and/or of the Fernsteuerungsempfangers no more signals the microcontroller on the input port of the microcontroller, will be moved to the State " Notsteuersignal-Erzeugung - level 1 ", in which the microcontroller of the "Steuersignalerzeugung" autonomously PWM signals to the actuators generated and there is, so can the time of the failure of normal operation and normal operation B with a defined PWM signals are bridged.

Fig 25: Block diagram of the " Steuersignal-Erzeugung "

Fig 26: finite state machine for the " Steuersignal-Erzeugung ". (See Figure 13 in section 3.6 ).

7.5.4.1 The hardware of the Steuersignal-Erzeugung

The Steuersignal-Erzeugung is realized by a software on the microcontroller 80C167CR-LM is running, and the microcontroller is located on a Testbord, the company was purchased PHYTEC. All the required peripherals are also located on the plate.

7.5.4.2 The monitoring and the forwarding of the PWM-signals from the remote control (normal operation (B)

The monitoring of the pulse width is particularly important for the proper function of the circuit, because of these data have the dynamic and the stationary behavior of the airship (alternative Lotte) abhanget, faults can also indirectly in the Aktorenbereich pulse produced by the be discovered.

The 4 channels of the receiver are connected to the lower 4 pins of the Port 2 connected. In Figure 27 is the program for the 4 inputs of the µc. The pulse lengths are programd with the help of the Capcom1 unit measured

Fig 27: for the Aktorik-Ansteuerungsprogramm Programmablaufplan on the µC

Table 4: shows the channel no.., and the corresponding connections and Capture-Register

The subunit CAPCOM1 consists, as previously mentioned in chapter 2 was, from the two timers T0 and T1, the program was only one timer necessary and 4 registers (see Table 4) .

Be the 4 tabs in the Mode Capture (used to recover) is used, which means that the register at each rising or falling edge on these inputs corresponding the the recovered CCxx meter readings of the Timer T0 Record. Your Operating Mode (Mode) in a 4-bit-long field in a of the Betriebsartregisters CCM0.

The control register CCMx set the operating mode of each of four Captur/ compare channels each firmly.

Selection of the operating mode CCMODx

001 : Capture on the rising edge at the terminal CCxIO

010 : Capture the trailing edge at Port CCxIO

011 : Capture on both flanks at Port CCxIO

ACCx assignment the timer: 0 = T0 or "T7 ", 1 = T1 or T8

The CCM0 register is in the main function under void main (void) with CCM0 = 0x1111 set, and so is with each rising edge on these inputs a corresponding interrupt (CCxIC) is triggered, and for processing led to the first interrupt routine.

First interrupt routine:

In the first interrupt routine is the Timer T0 and its 3,000 Nachladeregistern the value given to the same period of 25 ms to reach the measured signals, then with T0R = 1 started, before the control register should T01CON = 0x0000 in the main function will be programd, the CCM0-Register is here with 0x2222 programd to the falling edges to capture.

And so with the falling edge on the inputs a corresponding interrupt (CCxIC) triggered and the current counter of the timer T0 to the corresponding Capture-Register CCxx saved (see Figure 28). The triggered Interrupt leads to the processing of the second interrupt routine.

Fig 28: Capture Mode

Second Interruptroutinen:

In the second interrupt routine , the value of the Timer T0 in the moment in the Capture-Register saved and then to the global variable copied CC_Nx. The CCM0-Register will be programd to rising edge, and the pulse length is measured not only easy, but it must also be made in a statement, and this is why the CC_Nx values with two constant T1x_MIN and T1x_MAX compared (see program and Figure 29). The two constants are used to limit the pulse signals between 1.2 ms and 1.8 ms, and that makes it possible to get the Hohenruderausschlag limited by the software.

If (CC_N > T1_min )

{

CC18 = T1_min;

P82 = !P21;

}

Else if (CC_N < T1_max)

{

CC18 = T1_max;

}

Else

}

P82 = P21;

}

Fig 29: T0 and CC1 in capture mode

Third interrupt routine:

In this interrupt routine, the contents Compare-Register , of the same value of 1.8 ms is, with the Timer T1 within second interrupt routine compared. In conformity is a Interrupt CCX * IC is triggered and this will of the appropriate output port (P8X= 0) set to zero, thus the PWM-limited pulses.

At 1.2 ms, with the smaller T1_min the Compare-Registers/1.8 ms and when is with the larger value of T1_max the Compare-Registers compared.

CC18_isr void (void) interrupt 0x32

{

P82 = 0;

CC21 = T1_max;

}

Fourth interrupt routine:

For the monitoring of the input signals is the fourth interrupt routine with the Timer T2 initialized . The initialization of the interrupts is done after the setting of the mode of the timer T2CON = 0x0003 ( period = 210 ms ) and with T2R = 1, the timer is started and with a 0 the interrupt processing given freely, and the timer T2 is in the second Interruptroutinen every time on the T2 = 500 reset, which means that the third interrupt routine is not triggered, only if no rising or falling edge within the period of the timer is important, in the T2 interrupt routine, constant

PWM signals generated by the PWM unit.

Test routines

For the tests, which are described in chapter 2, test programs have been created.

Test 1 is used

For the measurement and evaluation of the Mikrocontroller-Eingangssignale (PWM signals) on board, the come from the recipient and

To test the of the PWM-unit of the microcontroller produced PWM signals.

Test 2 will test the constancy of the supply voltage of the µC, and the other components of the Aktorik-Ansteuerungsbaugruppe .

The full code is included in Annex B listed.

7.5.4.3 Level 1 Notsteuersignal-Erzeugung

With this unit in the event of an emergency are constant PWM signals generated (30), if the recipient for some reason no sending them signals to the outputs, this unit has 4 channels, each of the 4 channels contains its own Timer PTX, the from the CPU-measure or a divider on the counts receives(Table 4). The period of the signal results from a comparison of the current counter with the Periodenregister PX, the Low-Zeit from a comparison with the Pulsweitenregister PWX (see C program and 30).

Table 5: shows the DCLS Einheit-Ausgange and their corresponding Timer

T2_isr void (void) interrupt 0x22

{

P7X = 0; // P7.x is output

PX = 7800; // Max Period

PWX = 7372) and strong support ; // Initial value (high flank)

PWMCON0 = 0x0044; // Timer and CPU-to-measure : Age 64 (210 ms)

PWMCON1 = 0x0004; // outputs with mode 0 Free

}

Fig 30: PWM-production in the Mode PMX 0

7.5.5 Notsteuerungsbaugruppe

Fig 31: for the Blockdiagram Notsteuerungsbaugruppe

7.5.5.1 Circuit Design for the monitoring of the control signals on the output of the ACU and the channel5-output of the Fernsteuerempfangers

Fig 32: Monitoring of the control signals (PWM signals) at the output (CAKTIV) of the ACU and the channel5-output of the Fernsteuerempfangers (P2.5)m

If to P2.5) and mCAKTIV no signals are present, the OR-link to output 3 set to "Low" and flip-flops to input 12 of the IC5B of the " Basisbetriebszustands-Einstellung " (see Figure 23). The output 9 of the IC5B is to input 11 of IC9B (see Figure 29) has been set and now led the production of Notsteuerungssignalen - level 2.

7.5.5.2 Circuit Design for the Notsteuerungsbaugruppe

Description: Intern_Baug.

Fig 33: Notsteuerungsignal-Erzeugung - level 2

As already mentioned above, output 9 of the IC5B of the " Basisbetriebszustands-Einstellung " (see Figure 23) with input 11 of IC9B (see Figure 33) now connected and led the production of Notsteuerungssignalen - level 2, and this is done as follows:

Output 9 of the IC9B triggers each of the input A of the three flip-flops IC8B, IC8A and IC9A. The output of the latter three flip-flops is each with the gate of a FET, the gate signal of the reinforced forwards to the respective actuator, PWM signals are caused by the combination with the clock of the two flip-flops expands (IC9B and IC8B, IC9B and IC8A, IC9B and IC9A).

Figure 34: One of the three generated PWM signals, which is generated by the combination of the clocks of the two flip-flops expands is created (see text)

The PWM of the three generated PWM signals (in the picture as an example T2-T1 for one of the three generated PWM-signals) can before each use of the airship by the potentiometer P15 P16 and P17 be set (Figure 34). This can the Notsteuersignal-Erzeugung - level 2 of the conditions of the respective mission be adapted.

7.5.5.3 Circuit Design for the forwarding of the PWM-signals from Fernsteuerungsempfanger ( Luftschiff-Startphasen -operation)

The condition " Luftschiff-Startphasen -operation" are the channels 1-4 (in Figure 24 are you with P2.1-P2.4 and higher) of the Fernsteuerempfangers placed directly to the actuators, and this is done, if K2, K3, K4 and K5 are activated accordingly (see left and right lower half of the 24), i.e. , P2.1 is directly with SEITSERV1 and SEITSERV2 connected, P2.2 is directly with RPMSERV (engine) connected, P2.3 is connected directly with HÖHSERV1 and P2.4 and higher HÖHSERV2 is directly connected with.

i.e. here is not a new circuit necessary.

7.5.6 Layout design of board 1 ( "Voltage regulation", " Basisbetriebszustands-Einstellung " and " Notsteuerungs-Baugruppe ")

The blocks "Voltage regulation", " Basisbetriebszustands-Einstellung " and " Notsteuerungs-Baugruppe " are realized on the circuit board 1 (see section 3.6 ), Figure 35 shows the layout design of Board 1.

Description: ifr-gamal2002-top

Fig 35: the layout design of board 1

7.5.7 The circuit boards of the ACU

The both circuit boards of the ACU

Fig 36: the two boards (1 and 2) to the ACU

Figure 37: the receiver and the actuators (engine,servos) are connected to circuit board 1.

7.6 Experimental results

7.6.1 Structure of the Testplatzes

Figure 38: Testplatzaufbau

Fig 38 shows the in the experiments and the development of the program used for the ACU devices. The PC is the ACU via a serial interface (RS232) connected to the PWM signals to make visible, an oscilloscope is used.

The ACU is particularly sensitive to static electricity, which is why it is important, this assembly to a suitable place to be during the experiments, in the housing for the embedded system is a Versorgungsspannungserzeugungseinheit (right-hand side of the figure) is installed, in order to able to forego on batteries.

7.6.2 Experiments and test sequence

The output values (counter values the Compare-Einheit/swap is performed on the ACU-microcontroller for the rising and falling edges of visualized on the oscilloscope signals) over a serial interface sent to the PC, it is calculated and the pulse width on the PC-screen made visible, the three following signals are made visible at the same time on the oscilloscope.

· The ACU-input signal to channel 5,

· A selectable output signal of the ACU and

· A selectable input signal of the ACU.

On the PC-screen pulse width can be permanently on the oscilloscope with the pulse width of the respective signal shown by the user are compared, so you can while the program runs directly determine whether the program expires without fault, this data are of great help in the detection of the error with unstable program.

The two most important experimental data are visualized on the oscilloscope and the length of the period of the distance between the rising and the falling edge of the the PWM-signal.

7.6.3 The series of tests

At the time of the implementation of the tests was the ACU Mikrokontroller-Platine so faulty that input only P2.4 and higher (channel 4), exit 4 (control of elevator clattering 1) and channel 5 did, so no signals from other A and/or outputs (control of the rudder, of the engine, ... ) will be tested, but are on the other a and/or outputs to the expected signals similar to those of each input 4 and Output 4.

In the following tests the signals to Input 4 and Output 4 in various operating conditions as measured. The current operational status is also measured by the signal set to channel 5, the 2 possible modes of channel 5 (1, by the recipient pulse width less than 1.5 ms: normal operation; 2, pulse width from the receiver greater than 1.5 ms: Luftschiff-Startphasen -operation) are by a switch on Fernsteuerungssender (on the ground) set by hand.

The following are the different conditions under which the different tests ran:

Test 1: pulse width of channel 5 of the receiver less than 1.5 ms: -> normal. The ACU is under the condition when you turn on "normal" to the normal mode B initialized. Under this condition runs test 1.

Test 2: pulse width of channel 5 of the recipient greater than 1.5 ms: Luftschiff-Startphasen -operation.

Test 3: there is no signal from the receiver: -> It is a signal to output generated by the microcontroller 4 ( Notsteuersignal-Erzeugung - level 1)

Test 4: ACU Mikrocontroller-Platine is removed from the system: -> Notsteuersignal-Erzeugung - level 2 is activated, a signal generated by the Notsteuerungsbaugruppe is to output 4 to.

Test 5-1, Test 5-2: operation B, i.e. the microcontroller directs the PWM-signal from the remote control next (input 4 on the outcome 4)and, in addition, the pulse width of the signal limited, i.e. , the signal on output 4 (channel 4) is in contrast to the signal at the input (up or down to) Limited, unlike the limit test 1 is indeed in the visible, because the input signals outside the limits.

Test 6: between normal operation and normal operation A B is changed by the corresponding information from the N/R-machine to the microcontroller of the ACU is given, the N/R-computer receives this information via the communication system from the ground, in test 6 this will be simulated by two different keys on the lab computer, the serial interface is connected to the ACU, and of the the N/R-simulated by computer, will be activated, if the A button is pressed, the system is intended to go to the normal mode A, in the other key is to control the system to normal operation B go. The correct transfer of information from N/R-machine to the microcontroller and the correct response is with the help of appropriate LEDs on the Mikrocontroller-Platine (board 2) simulates. These lights depending on the currently valid condition.

In the Test-Abbildungen are from top to bottom to see the following signals:

1. CH 1: channel 5 at the entrance of the ACU

2. CH 2: channel 4 at the entrance of the ACU

3. CH 3: Channel 4 on the output of the µC

4. CH 4: Channel 4 on the output of the ACU

7.6.3.1 Test 1

The channel 5- switch of the remote control on the ground, is to "pulse width less than 1.5 ms" provided.

It is the normal case B (control signals from Fernsteuerrungs-Empf . will be give to the microcontroller, the passes on this to its output) tested, with the Fernsteuerungsknuppel is a certain deflection of the commanded Hohenruders. This specification is on channel 4 sent.

Description: PIC1

Fig 39: Test 1 CH1 = channel 5; CH2 = input signal from channel 4; CH3 = output from the microcontroller; CH4 = output channel 4 of the ACU

Figure 39 shows that the pulse width of the channel 5 less than 1.5 ms (1.2 ms) is, this is normal operation B is set, and the PWM of the PWM signals at the input and output of the channel 4 are identical (1.5 ms), and so has the µC the PWM signals without modification of the output of the ACU redirected. The results came out as expected.

7.6.3.2 Test 2

The channel 5- switch of the remote control on the ground, is to "pulse width greater than 1.5 ms" position, this will the Luftschiff-Startphasen -operation (the PWM signals are Fernsteuerungsempfanger directly to the ACU-outputs passed on) set, otherwise runs Test 2 as the above test 1.

Description: PIC5

Fig 40: Test 2 CH1 = channel 5; CH2 = input signal from channel 4; CH3 = output from the microcontroller; CH4 = output channel 4 of the ACU

In Figure 40 is the PWM-signal to channel 5 (CH 1) 2 ms long, and as expected, this Luftschiff-Startphase -operation set by the µC, the PWM on the lower limit of 1.2 ms limited, and because the input signal (CH2) only 1.0 ms long and thus smaller than 1.2 ms, it is to 1.2 ms at the µC output extended (see Ch 3). The Luftschiff-Startphasen -operation however the signals directly forwarded and unlimited on the ACU-output (CH4) is set, and the results in the figure are consistent with what you would expect.

7.6.3.3 TEST3.

The PWM signals from Fernsteuerungsempfanger (channel 1, channel 5) will not be more to the ACU-inputs connected (this is CH2 dead, i.e. , in the Fig is not a rash to see), thus a failure of the remote control will be simulated, and no data coming from the R/N-machine.

Thus, the level 1 Notsteuersignal-Erzeugung enabled.

Description: PIC4

Figure 41: Test 3 CH1 = channel 5; CH2 = input signal from channel 4; CH3 = output from the microcontroller; CH4 = output channel 4 of the ACU

As expected, the µC with the help of his internal PWM unit PWM signals with fixed pulsewidth created (CH3), the on the output of the ACU (Ch 4) concern.

7.6.3.4 Test 4

In this test, the " Notsteuersignal-Erzeugung - level 2" is activated, by the circuit board with the microcontroller (Plate 2) from the ACU is mechanically separated, this will simulate a failure of the microcontroller, in Fig. 42 one sees that neither an input signal (CH2) is present, even at the output of the microcontroller (CH3) a signal is present, even is the channel5-input signal from Fernsteuerungsempfanger (CH1) to.

The successful production of a PWM signal with the " Notsteuersignal-Erzeugung Level 2" is shown by ch 4.

Description: PIC6

Fig 42: Test 4, CH1 = channel 5; CH2 = input signal from channel 4; CH3 = output from the microcontroller; CH4 = output channel 4 of the ACU

7.6.3.5 Test 5

The Pulsweiten-Begrenzung the PWM signals in normal operation B at the output of the channel 4 tested.

By the Fernsteuerungsknuppel, the maximum pulse (2.0 ms) (Test 5-1) and minimum pulse width (1.0 ms) (Test 5-2.) The PWM-signal commanded. This is on ch 2 in the two illustrations 43 and 44 to see.

In Figure 43 is the limitation of the PWM-signal to the upper limit of the pulse width clearly shown: CH 2 (2.0 ms) is the unlimited signal, CH 4 (1.8 ms) is the limited signal.

In Figure 44 is the limitation of the PWM-signal to the lower border of the pulse width clearly shown: CH 2 (1.0 ms) is the unlimited signal, CH 4 (1.2 ms) is the limited signal.

Description: PIC3

Figure 43: Test 5-1, CH1 = channel 5; CH2 = input signal from channel 4; CH3 = output from the microcontroller; CH4 = output channel 4 of the ACU

Description: PIC2

Figure 44: Test 5-2, CH1 = channel 5; CH2 = input signal from channel 4; CH3 = output from the microcontroller; CH4 = output channel 4 of the ACU

7.7 Summary and outlook

In this work , a part-functioning Aktorik-Ansteuerungs -unit (Actuator Control Unit (ACU) for the airship "alternative Lotte" was completed, and the ACU Fernsteuerungsempfanger get input signals of a or of a regulatory and the navigation computer (R/N-computer) on board, depending on the operating mode are in different ways by the ACU Anteuerungssignale for the actuators (Helm, engine) is created, the ACU has a multi-level security system to R/N-the airship crash or Kommunikationsverbindungsausfall defined for a time as possible to control and, where necessary to bring safely to the ground.

At the time of submission of the thesis is the data stream between R/N-machine and ACU has not yet been tested on correctness, the there is a connection, but is has been verified and the data stream between R/N-machine and ACU is to be tested during the integration phase, i.e. when the ACU together with the other components of the Flugkontrollsystems (Flight Control System (FCS) are joined together.

Literature

[ 1] (C167) underlying hedged transaction Users Manual, Infineon AG, Munich, 3.1 edition; March 2000.

[ 2] Schmitt G, "micro-computers with the Controller C167 ", Oldenbourg Verlag, 2000.

[ 3] Martin H. , "lecture notes for microcontroller C167 ", Institute of Computing Technology, Technical University of Vienna, 2000.[5]

[ 4] Bernd B. / Peter G. , "The Big C167-microcontroller Operation", Gerber Verlag,

2001

Appendix A

Circuit Design for the Versorgungsspannungs-Stabilisierung

Description: Servo_3

Figure 0-1: circuit design for the Versorgungsspannungs-Stabilisierung

Circuit for switch between Luftschiff-Startphasen -operation and normal operation (LSB/NB switch, part2)

Description: gh

Figure 0-2: shift to switch between Luftschiff-Startphasen -operation and normal operation (LSB/NB switch, part2)

Circuit Design for the Basisbetriebszustands-Einstellung and the Basisbetriebszustands-Einstellung

Description: jh

Figure 0-3: circuit design for the Basisbetriebszustands-Einstellung and the Basisbetriebszustands-Einstellung

ANNEX B

Test program 1

/ * Measure of the length of time between successive flanks the entrance P2.3 * /

#Include <REG167.h>

#Include <intrins.h>

#Include <stdio.h>

SFR Pam Picon = 0xf1c4;

/ * ----------------------------------------------------------------------------------------

** The direction of the ports in and out for those needing

* /

SBIT DP84) = DP8 ^ 4;

SBIT P84) = P8 ^ 4;

SBIT DP72 = DP7 ^ 2;

SBIT P72 = P7 ^ 2;

SBIT DP23 = DP2 ^ 3;

SBIT P23 = P2 ^ 3;

Unsigned int CC_N;

Unsigned int flankennr = 0; / * distinguishes between 1ter and 2nd flank * /

Unsigned int T_E= 0;

Const int T1_min = 6000; / * constant to the decision on whether the timer should be stopped * /

Const int T1_max = 7500; / * constant to the decision on whether the timer should be stopped * /

/ * ----------------------------------------------------------------------------------------------

** Global variables for the serial interface

* /

Unsigned int t0_inhalt_start = 0;

Unsigned int t0_inhalt_stop = 0;

Unsigned int steur_reg = 0;

Unsigned int steur_zaehler = 0;

/ * ----------------------------------------------------------------------------------------------

** Production of the PWM-signals from derPWM-unit

* /

Void t2_isr (void) interrupt 0x22

{

P72 = 0;

PP2 = 7800;

PW2 = 7372) and strong support ;

PWMCON0 = 0x00ff;

PWMCON1 = 0x000F;

}

/ * --------------------------------------------------------------------------------------------

** Limitation of the pulsewidth of the PWM signals

* /

Void cc20ISR (void) interrupt 0x34

{

P84) = 0;

CC20 = T1_max;

}

/ * --------------------------------------------------------------------------------------------

** Programming the PWM signals at the entrance

* /

Void p23 (void) interrupt 0x13

{

Charbuff_tmp [ 40];

Int I;

PP2 = 0;

PW2 = 0;

P72 = 1;

P84) = P23;

If (flankennr= = 0) / * First edge * /

{

T2 = 500;

T0rel = 3000;

T0 = 3000;

T0R = 1; / * starts timer T0 * /

T0_inhalt_start = T0;

T7rel = 2950;

T7 = 2950;

T7R = 1;

CCM0= CCM0 & 0x0FFF;

CCM0= CCM0| 0x2000;

Flankennr= 1; / * YES -> There are still two more sides expected * /

}

Else if (flankennr= = 1) / * Second flank * /

{

CC_N = CC3;

T0_inhalt_stop = T0;

CCM5 = 0x0005;

CCM0= CCM0 & 0x0FFF;

CCM0= CCM0| 0x1000;

Flankennr = 0;

If (CC_N < T1_min )

{

CC20 = T1_min;

P84) = !P23;

}

Else if (CC_N > T1_max)

{

CC20 = T1_max;

}

Else

{

P84) = P23;

}

/ * ------------------------------------------------------------------------------------------

** The serial interface

* /

If (( + +steur_reg) == 100)

{

For (i= 0; i< 100; i++)

{

sprintf(buff_tmp, "T0start: %u;Tstop: %u;imp: %u\n",

T0_inhalt_start,t0_inhalt_stop,CC_N , steur_reg);

Printf (buff_tmp);

}

Void main (void)

{

Flankennr = 0; / * 0.. there is still no flank occurred * /

DP72 = 1; / * DP7.2 central as output * /

DP23 = 0; / * sets the direction of DP2.3 to input * /

DP84) = 1; / * sets the direction of DP8.4 on output. * /

Pam Picon = Pam Picon | 0x3;

CCM0 = 0x1000;

CCM1 = 0x0001;

T01CON = 0x0000; / * Timer 1 has been with period (26 ms) initialized * /

CC3IC = 0x0047;

CC4IC = 0x0046;

CC21IC = 0x0045;

CC20IC = 0x0048;

T2CON = 0x0003;

T2IC = 0x0044;

T78CON = 0x0000;/ 0 1 00 0 000 0 1 00 0 000 26 ms * /

T2R = 1;

IEN = 1;

While(1) {

_idle_( );

}

Test program 2

#Include <reg167.h>/ * Register Diffinitionen of the C167) * /

#Include <intrins.h>/ * bausteinspezifische functions * /

#Include <stdio.h>

/ * ---------------------------------------------------------------------------------

** Initialization of the inputs and outputs

* /

SBIT DP26 =DP2 ^ 6;

SBIT P26 =P2 ^ 6;

SBIT DP27 =DP2 ^ 7;

SBIT P27 =P2 ^ 7;

SFR P5DIDIS = 0xFFA4;

Unsigned int adc_kanal0[200];/ * buffer for the Wandlungeergebnisse * /

Unsigned int adc_kanal1[200];/ * buffer for the Wandlungeergebnisse * /

Static unsigned int steur_reg = 0;

Static unsigned int steur_kanal0 = 0;

Static unsigned int steur_kanal1 = 0;

Static unsigned int pxt= 0;

/ * In the AD-converter interrupt service routine, the Wandlungsergebnisse

Read and in the field adc_werte copied and if the value in adc_werte 16

Less than 496 (4.76 p. p. p. n V) is, is therefore in this moment by high edge to P2.6 or higher a

HRLY RATE be switched * /

Void adcisr (void) interrupt 0x28

{

Int I;

Unsigned int test_1;

Unsigned int test_0;

Char buff_tmp[ 40];

If (ADDAT & 0x1000)

{

TEST_0 = ADDAT & 0x03ff;

Adc_kanal steur_kanal0+0 [ +] = ADDAT & 0x03ff; / * result of a/d process * /

If( test_0 < 800)/ * voltage small e.g. 4 V * /

{

P26 = 1; / * is available on the P7.8 1 (rising edge) * /

}

Else

{

P26 = 0;

}

Else

{

TEST_1 = ADDAT & 0x03ff;

Adc_kanal steur_kanal1+1 [ +] = ADDAT & 0x03ff; / * result of a/d process * /

If(test_1 < 600)/ * voltage small e.g. 4 V * /

{

P27=0;/ * is available on the P7.8 1 (rising edge) * /

}

Else

{

P27 = 1;

}

/ * --------------------------------------------

From the µC ** data sent back to the screen

* /

If ((steur_reg) < 100)

{

+ +Steur_reg;

}

Else if ((steur_reg) == 100)

{

For (i= 0; i< 50; i++)

{

sprintf(buff_tmp, "Channel1: %u, Kanal0: %u\n",

Adc_kanal1 [i], adc_kanal0 [i] );

Printf (buff_tmp);

}

+ +Steur_reg;

}

/ * --------------------------------------------------------------------

** With GPT1 is the conversion each time after time start bestemmte

* /

Void gpt1T3 (void) interrupt 0x23

{

ADST = 1; / * Conversion start * /

}

Void main (void) {

DP27 = 1;

P27 = 1;

DP26 = 1;

P26 = 1;

P5DIDIS |= 0x0001;

Adcon= 0xf221;

T3CON = 0x0002;

T3 = 0x0BDC;

T3IC = 0x006B;

T2CON = 0x0020;

T2 = 0x0BDC;

ADCIC = 0x004C;

IEN= 1;

T3R = 1;

While(1){

_idle_( );

}

8 Communication and User Interface

Based on the bachelor thesis of Rabih al-Farkh, "Development of a communication interface for a measurement system", June 2002, Lebanese University – Tripoli/Lebanon, Faculty of Engineering

Abstract

A communication system which includes a graphical user interface has been developed to control a mobile sensor platform, and to receive measurement data from this mobile sensor platform. The measurement system is used to measure alternative energy resource values like solar power and wind vector at different points.

Keywords: graphical user interface, airship, transceiver, wireless communication, V-model, structured analysis, structured design, software engineering.

8.1 Introduction

8.1.1 The LOTTE project and the “alternative Lotte”

8.1.2 Development method

The software is developed using structured analysis / structured design (SA / SD). This method is very common in industrial development processes as well. The complete communication system is tested in a laboratory using two PCs and the transceivers. The whole development process basically follows the known V-model.

8.1.3 Working task and realization approach

The task is to develop a communication interface which is software running on a PC which is connected with the transceiver on the ground. Apart from that a program which is running on the board computer has to be developed. The purpose of this program is to establish the communication between the sensors and the transceiver on the “alternative Lotte” sensor platform.

So the diploma thesis can be divided into several tasks:

· Specification document, SA diagram (Structured Analysis) and SD diagram (Structured Design) for the User Interface.

· Programming of the User Interface using Visual Basic 6.0.

· Specification document, SA/SD for the communication protocol.

· Programming of the communication protocol with programming language C.

· Programming of the protocol for sending and receiving with an off-the-shelf transceiver cards.

· Testing the communication system with the User Interface.

8.1.4 Overview

After a short introduction some basic knowledge about the used development method SA / SD, the V-model and some general information about transceivers is provided.

In the third chapter a detailed description of the user interface and the transceiver is given. Then the system architecture of the whole system is presented.

Chapter 5 contains the SA, SD of the alternative Lotte communication system and a brief description of the software implementation. After that the development environment is explained.

The last chapter is about the tests that have been done to verify the functionality of the communication system.

Detailed figures of the hardware and the code of the software can be found in the annex.

8.2 Basics

8.2.1 The V-Model

The V-Model is an extensive collection of knowledge about the best practices of software development. This knowledge can be described as a process: In addition to the planned products and activities, the V-Model also contains information about the course the project will take. To this end, the process standard includes which output products are to be created by an activity and which successor activities need this product as input. This internal product flow allows you to derive a chronological order for the activities.

The V model is a logical product model. It describes the contents of the products which have to be created during a software project and their relationships on a very high level. However, in a real project the physical structure of these products might (and in most cases will) be quite different [1].

Figure 2.1: The V–Model

The left side of the V shows the products resulting from development activities: problem description, user requirements, developer requirements, system design, component design and component code. The products are not further described here.

The right side of the V documents the construction of the final system starting with individual components. The products on this side of the V are called executable components, executable system, usable system and used system.

Besides development and constructional activities the V model also contains some analytical activities: verification and validation.

Verification takes place after each development activity. The output of the activity is verified against the input in order to check if both actually match.

Validation happens after each construction step to assure that the so far constructed system behaves as it should. It is therefore tested against the corresponding product on the other side of the V model.

It should be emphasized that the V model is no physical product model nor any kind of process or life cycle model. However, due to its very general description, products used in a life cycle model can always be matched with the products contained in the V model. Therefore, it can be seen as a generic product model.

The V-Model is a Lifecycle Process Model, originally developed to regulate the software development process within the Federal Administration of the Federal Republic of Germany.

The V-Model is composed of four submodels: software development, quality assurance, configuration management, and project management.

The submodels are closely interconnected and mutually influence one another by exchange of products and results. The software development submodel develops the system or software. The quality assurance submodel submits requirements to the other submodels and test cases and criteria to assure the products and the compliance of standards. The configuration management submodel administers the generated products. The project management model plans, monitors, and informs the other submodels. Each can be further decomposed. For instance, the software development submodel can be broken down as follows (see [2]):

System requirements analysis and design.
Data processing requirements analysis and design.
Software requirements analysis.
Preliminary design.
Detailed design.
Implementation.
Software integration.
Data processing integration.
System integration.

8.2.2 Structured Analysis (SA) / Structured Design (SD)

In the seventies and eighties of the 20^th century Structured Analysis (SA) was described by Yourdon, Constantine, and DeMarco. These practices became very popular, and by the early eighties had a profound effect upon the definition of analysis. SA was a technique in which the requirements of the customer were broken down into a hierarchy of functions. This breakdown was known as functional decomposition . Datasets were specified in abstract (Bacchus-Naur) terms, and their manipulation were depicted through functionally decomposed data flow diagrams.

SA was coupled to another practice known as Structured Design (SD). Indeed, the two were often mentioned in the same breath as SA/SD. SA described the data sets and data transformations implied by the requirements. As such, SA described what the system would do, albeit in very technical terms. On the other hand SD described the partitioning of the software into modules, and the flow of data between those modules. Therefore an SD was, more or less, a description of how a system would be structured to meet the requirements. SA/SD contained a practice known as The Transform Analysis , which was used to convert the diagrams representing a Structured Analysis into the diagrams the represented a Structured Design. This practice, and indeed much of the documentation of the period, established the notion that the design was directly derivable from the analysis by applying some simple transformation rules. This meant that the analysis was really a preliminary description of the design, requiring only a mapping operation to complete. The view of SA/SD was a remarkable change from the systems analysis of the sixties. In the sixties no such mapping from analysis to design was implied. The analysis simply described data sets

and their transformations without implying anything about software structure. SA/SD also implied a temporal constraint between analysis and design that was not practiced by the Systems Analysis of the sixties. In SA/SD it was necessary to finish the analysis before the Transform Analysis could be applied to translate the analysis into a design. Thus, SA/SD strongly reinforced the waterfall model of development [3].

Figure 2.2: SA/SD (see [4])

8.2.3 Transceivers

There are three wireless RF modules: transmitter, receiver and transceiver. These RF modules are designed to serve as a tool for electronics design engineers, developers and students to perform wireless experiments.

The transmitter is used to transmit data and the receiver is used to receive data, so they are used in application of one-way communication. The transceiver is used to transmit and receive data, so it is used in application of two-way communication. All of the RF modules which are used in this project have 9,600 bps serial interfaces at maximum. The used modules can communicate over range up to 250 feet. Generally the range depends on the power and the frequency of the RF module.

Radio frequency (RF) refers to electromagnetic waves that have a wavelength suited for use in radio communication. Radio waves are classified by their frequencies, which are expressed in kilohertz, megahertz, or gigahertz [5].

The RF transceiver controls and modulates the radio frequencies that the antenna transmits and receives.

8.3 Requirements Specification

8.3.1 The Graphical User Interface (GUI)

The user interface is the link between the user and the alternative – LOTTE, a measurement vehicle for solar radiation and wind power. Its purpose is allowing the user to control the alternative – LOTTE from the base station, so by using the User Interface, the user can set data to the alternative – LOTTE (new position, new velocity ...) and get data from the alternative – LOTTE (acceleration, angular velocity, azimuth, temperature, wind vector, Solar radiation ...).

Figure 3.1: User Interface

8.3.1.1 Software Requirements Specification

Ø The user interface contains a frame (Receive_Data_Frame) inside which, we find several
text boxes or labels.

Figure 3.2: Receive Data Frame

Ø These several text boxes or labels are used to display the data that the base station received from the alternative - LOTTE. These data are the data sensors (acceleration in X, Y and Z, angular velocity in X, Y and Z, azimuth, temperature, solar “Solar Radiation” and wind vector). As to the azimuth parameter, it can not be seen by the user. It is used by the user interface to display the direction of the alternative – LOTTE in a picture box. These sensor data will be sent from the alternative - LOTTE to the base station. The user interface uses these data to calculate the velocity of the alternative - LOTTE in X, Y and Z and to calculate the position of the alternative - LOTTE in X, Y and Z.

Ø

The user interface contains command button shown below, this command button is used whenever the user wants to send data (commands) to the alternative – LOTTE. When the user presses this command button, a Send_Data_Frame will be displayed, (Sending_Data_Frame). The commands that the user can send to the alternative – LOTTE are the new position in X, Y and Z, and the new velocity in X, Y and Z.

Figure 3.3: Sending Data Button

Ø The user interface contains Sending_Data_Frame, in this command frame, we find several text boxes that are used by the user to put the data (commands) that he will send to the alternative – LOTTE. These data (commands) are the new position in X, Y and Z, and the new velocity in X, Y and Z.

Figure 3.4: Sending_Data_Frame

Ø

The user interface contains picture box that is used to display the position of the alternative – LOTTE on a map (two dimensions x, y). In this picture box the user will be able to see the position of the alternative – LOTTE during its flight.

Figure 3.5: PictureMap

Ø The user interface contains another command button. The function of this command button is to test if the connection between the base station and the alternative – LOTTE is OK. The result is displayed in the Connection_Frame. In fact, the connection is always put to the test whenever the user receives data from the alternative – LOTTE (which means that the connection is OK). If the user wants to make sure about the connection at any time all he has to do is to press the Test – Connection Button.

Figure 3.6: Test-Connection Button

Ø The user interface contains a Connection_Frame that is used to tell the user that the connection is OK while the alternative - LOTTE is in the air. In case there is a problem in the connection between the base station and the alternative - LOTTE, it is displayed in this frame, and the user would be able to see that there is a problem.

Figure 3.7: Connection Frame

Ø

The user interface contains a picture box that is used to display the direction of the alternative - LOTTE while it is in the air. The user interface will get the azimuth from the alternative – LOTTE and use this parameter to display the direction of the alternative – LOTTE.

Figure 3.8: PictureDirection

Ø The user interface contains a weather frame that is used to tell the user the status of the weather while the alternative – LOTTE is in the air. In this frame, the user can observe the temperature, the wind vector, and the solar radiation (solar radiation in X, Y and Z). The user interface get these data from the sensors data.

Figure 3.9: Weather Frame

Ø

The user interface contains a third command button. The function of this command button is to display the solar radiation in front of the user in three dimensions. When the user press this button, he will see the position of the alternative – LOTTE in three dimensions with the value of the solar radiation in each position.

Figure 3.10: Solar Radiation Button

Ø When the user presses the Solar Radiation button, the figure shown below shall be displayed :

Figure 3.11: Solar Radiation show

In this figure, the position of the alternative – LOTTE is displayed with the power of the solar radiation, the color at the position shows the intensity of the solar power at this point.

8.3.2 Specifications for the transceiver

The goal of this transceiver is send and receive data between the Base station and the alternative – LOTTE. There are two transceivers, one is connected to the base station and the other is connected to alternative – LOTTE.

8.3.3 Communication Protocol for User Data

In each frame, the transceiver processes the data internally and input/output user data. User data can be specific by user. In general, data is send and receive as “packet”.

Ø
The form of the telegram that the base station receives from the alternative – LOTTE is :

Figure 3.12: User Data Protocol _ Receive Message

¨ The Begin flag is the beginning of the telegram (message) and the length of this command is 1 byte (8 bits). It is a special byte that the user uses to tell the alternative – LOTTE and the base station that it is the beginning of the telegram (message).

¨ The information length of the telegram is on 2 bytes, and it contains an information about the length of the telegram (message) that the base station receives from the alternative – LOTTE, or sends to the alternative – LOTTE.

¨ The sensors data contains information about the acceleration in X, acceleration in Y, acceleration in Z, angular velocity in X, angular velocity in Y, angular velocity in Z, the azimuth, wind vector in X, wind vector in Y, wind vector in Z, solar in X, solar in Y, solar in Z and the temperature. Each information is in 4 bytes and the type of this data is float.

¨ The End flag is the end of the telegram and the length of this command is 1 byte. It is a special byte. So when the base station or the alternative – LOTTE receives this byte, it knows that this is the End of the telegram and it waits for another telegram from the alternative – LOTTE.

The form of the telegram (message) that the base station sends to the alternative – LOTTE is :

Figure 3.13: User Data Protocol _ Send Message

The sent and the received telegram have the same protocol (Begin_Flag , Length of the Telegram, Data or Commands (information) and then the End_Flag). We can send the begin flag at first, then the length of message (commands), then the commands (which gives the new position and the new velocity), and finally the end flag to tell the alternative – LOTTE that the telegram is finished.

8.3.4 Handshaking

Handshaking refers to the internal communications protocol by which data is transferred from the hardware port to the receive buffer. When a character of data arrives at the serial port, the communications device has to move it into the receive buffer. A handshaking protocol ensures that data is not lost due to a buffer overrun, where data arrives at the port too quickly for the communications device to move the data into the receiver buffer.

8.4 Architecture Design

The purpose of the user interface is to control the alternative – LOTTE from the base station and the purpose of the transceiver is to send and receive data between the base station and the alternative – LOTTE. The connection between the user interface, the transceiver and the whole system is shown in the figure below :

Figure 4.1: System Connection

This figure shown above describes the connection between the PC in the base station which contains the user interface program and the transceiver, and the connection between the embedded system in the alternative – LOTTE and the other transceiver. This connection is done through the serial port.

Apart the connection between the embedded system in the alternative – LOTTE, the transceiver card and the sensors card is shown in the figure above. In fact the sensors card is connected to the microcontroller which is connected to the embedded system through the serial port. The purpose of the microcontroller is to transfer the sensors data from the sensors card to the embedded system. The embedded system gets these sensors data from the serial port which the microcontroller is connected to and sends these data to the serial port to which the transceiver card is connected.

The transceiver gets these sensors data from the embedded system through the RS232C connector, then the data are stored in internal buffer. After the transceiver checks that the carrier frequency to be set is not used on air, these data will be sent to the base station using one of the channels frequencies between the 433.200 – 434.775 MHz. The same thing is done when the transceiver gets data from the base station and will sent to the alternative – LOTTE

The modulation used is the FSK modulation (Frequency Shift Keying), this type of modulation enables transmission at a maximum of 9,600bps. Also when multiple channel are to be used simultaneous or if high communication standards are required, the MSK modulation enables transmission at a maximum of 2,400bps.

Figure 4.2: The “alternative Lotte” Communication System

8.5 Development Environments

The development has been done on a PC with AMD – k5 tm processor, AT / AT compatible, 64 MB RAM and a PC with a PENTIUM – S processor 100 MHz, 96 MB RAM.

The following software tools have been used for the development:

· MS Windows 98, MS Windows 2000, MS Office 97 and MS Office 2000.

· Windows 2000 server for workflow Management, Linux.

· MS Visual Basic 6.0 language and C language. (program C is done under VxWorks).

· Visual Basic 6.0 compiler for Visual Basic program.

· "Gcc" compiler for C program under UNIX.

· Tornado 2.0 environments for C program.

· VxWorks 5.4 compiler for C program.

· Optional : MS Visio 2000 for the graphical visualization of processes, Structured Analysis (SA) / Structured Design (SD).

8.6 Design and Implementation

8.6.1 SA / SD and Implementation for the base station program

8.6.1.1 SA (Structured Analysis)

Figure 6.1: Context Diagram

Ø The DISPLAY is the screen of a PC in the base station that can be used to observe the received sensors data. These sensors data are received from the alternative – LOTTE using the serial port of the PC.

Ø The KEYBOARD is used by the user to write the commands that he wants to send to the alternative – LOTTE. These commands are sent to the alternative - LOTTE using the serial port. In fact, whenever the user wants to send commands to the alternative – LOTTE, the user interface will send them to the serial port.

Ø The SERIAL PORT is the peripheral between the user interface and the alternative – LOTTE. So by using the user interface, we can say that the user will get data (from the alternative – LOTTE) and set data or commands (to the alternative – LOTTE).

Figure 6.2: data flow diagram (DFD) of the process “User interface”

In this second diagram, we can see all the functions that the user interface can perform .

Ø Some remarks for structured analysis (SA) convention:

The symbol means that we have a process and this symbol

means that we have a storage.

Ø In the second increment a security layer is added to the communication protocol. The commands that the base station sends to alternative –LOTTE will be acknowledged. If the acknowledgement fails the commands are resent.

ID	Features	Increments
01	Ø Send commands to the alternative – LOTTE Ø Receive data from the alternative – LOTTE	1
02	Ø Save Commands that the user sent to the alternative – LOTTE. Ø Waiting for an answer from the alternative – LOTTE about what it has Received. Ø Compare this answer with the Telegram (message) that the user sent.	2
03	Ø Send commands with saving it to compare with the answer from the alternative – LOTTE. Ø Receive data from the alternative – LOTTE.	All

8.6.1.2 SD (Structured Design)

Some remarks for structured Design (SD) convention:

The symbol means that we have a function, and in this symbol we can find the same name of the function used in program.

this relation means that the function1 calls function 2.

The symbol describes the return value of the function

The symbol describes the input parameters of the function.

Figure 6.3: Structured Design (SD) diagram for the user interface

Description of the functions

MSCOMM

This is an OCX (Microsoft Comm Control 6.0) which contains all functions that the programmer can use when he wants to program the serial port. Using this OCX, we can manage the serial port from Visual Basic which means that we can open the port, put the settings of the port, read from serial port and write to serial port ... .

UserInterface Load

This function runs automatically when the user runs the Program. The purpose of this function is to give the MSCOMM the number of serial port that the user will open and the settings and the InputMode. It will also enable the TimerRun_R and testing the status of the serial port.

Timer_Run_R

This function contains the interval which the user interface uses to read data from serial port if this serial port was not busy. The serial port being busy means that it is not used at the moment. For example, if we define the interval time like one second, so every one second the program will read data from serial port. Of course these data are the sensors data, and it contains information about the acceleration of the alternative – LOTTE and the angular velocity, the azimuth, the solar, the wind vector, and the temperature.

Read_Data

The purpose of this function is to read sensors data from serial port and to use these data to calculate the velocity of the alternative – LOTTE and its position. After that it sends these data to the Receive_Data_Frame which is then displayed in front of the user. Of course the user can not change these data, he can only see it. (Of course this requires that the serial port is not busy doing any other function like sending commands to the alternative – LOTTE, or testing the connection between the base station and the alternative – LOTTE).

Write_Commands

The purpose of this functions is that the user will be able to send commands from the base station to the alternative – LOTTE, using the serial port. The user can write commands after disabling the TimerRun_R. but if the TimerRun_R is enabled, this means that the serial port is used only to Read_Data.

C_Send_Commands

The purpose of this function is to enable the Sending_Data_Frame that it used by the user to write the sending commands (new position in X, Y and Z, and new velocity in X, Y and Z) that he wants to send to the alternative – LOTTE.

Send_OK

This function will confirm that the user wants to send the commands that he writes in the Sending_Data_Frame to the alternative – LOTTE after testing the status of the serial port. This is because the serial port maybe busy doing another function at that time like receiving data from the alternative – LOTTE ... .

Send_Cancel

This function is used by the user if he clicks the Sending Data Button and then he changes his mind and does not want to send commands to the alternative – LOTTE. So this function will disable the Sending_Data_Frame, and enable the TimerRun_R ( which means that the serial port is not busy sending commands right now, but rather the program is enable to read sensors data ).

C_Connection

The purpose of this function is to test the connection between the base station and the alternative – LOTTE. It refreshes the Connection_Frame and gets the status connection from the Read_Data Function. It also displayed the status of the connection on the Connection_Frame.

PictureBox_Position

The purpose of this function is getting data from the Read_Data function (position in X, position in Y) and displaying the position of the alternative – LOTTE on the map.

PictureBox_Direction

The purpose of this function is getting data from the Read_Data function (Azimuth) and displaying the direction of the alternative – LOTTE in the PictureBox.

Calculate_Velocity

The purpose of this function is to get the Acceleration from the Read_Data function and calculate the velocity of the alternative – LOTTE in X, Y and Z and gives this information to the Receive_Data_Frame that it displays.

Calculate_Position

The purpose of this function is to get the velocity from the Calculate_Velocity and calculate the position of the alternative – LOTTE in X, Y and Z and gives this information to the Receive_Data_Frame that it displays.

TxtCodeHex2Dec

The purpose of this function is to get the sensors data from the Read_Data function and to convert this data from the hexadecimal format to the decimal format.

TxtCodeDec2Hex

The purpose of this function is to get commands from the Write_Commands function and to convert this commands from the decimal format to the hexadecimal format.

FormPosition

This function run when the user press on the PicturePosition if he wants to see a large view. It contains a large picture box that inside it the user can show how the alternative – LOTTE change its position.

FormDirection

This function run when the user press on the PictureDirection if he wants to see a large view. It contains a large picture box that inside it the user can show how the alternative – LOTTE change its direction.

Solar_Radiation

This function run when the alternative – LOTTE finishes its travel. It takes the position in X, Y and Z and the Solar Radiation in X, Y and Z from the Read_Data function and uses these parameters to put the position of the alternative – LOTTE in the three dimensions with the value of the solar radiation in each position. The color of the position (point of position) changes with the value of the solar radiation.

Jet

This function run when the user press the solar radiation button. It takes the parameters (position in X, Y and Z and the solar radiation) and puts it in a three dimensional figure.

8.6.1.3 Implementation

The whole VB program code is in Annex E.

In this paragraph, the important things done in the software part will be described. At first, when the user interface program is used, the user has to care about these commands :

Ø MSComm1.CommPort = 3 (line of code: 132)

this command is used to open the serial port number 3. Changing the number of the port is allowed. [6]

After that the initialization of the baud rate of the serial interface, the parity status, the data length and the stop bit will be done as below :

Ø MSComm1.Settings = "9600,E,8,2" (line of code: 133)

Then the initialization of the handshaking protocol is done by this command :

Ø MSComm1.Handshaking = comRTSXOnXOff (line of code: 134)

When the handshaking is set to the value shown above, the RTSEnable property will be set to TRUE as shown below :

Ø MSComm1.RTSEnable = True (line of code: 135)

The input mode used is input text mode, this mode is set by the command shown below :

Ø MSComm1.InputMode = comInputModeText (line of code: 136)

Setting the InputLen property to a number causes the communications control to read this number of bytes from the receive buffer.

Ø MSComm1.InputLen = 116 (line of code: 137)

So by using all the commands shown above, the initialization of the serial port is completed and the serial port can be opened by this command :

Ø MSComm1.PortOpen = True (line of code: 138)

An important parameter used is the interval of the timer. The value putted in this parameter is used by the program to read the data from the receive buffer of the serial port.

Ø TimerRun_R.Interval = 500 (line of code: 155)

The value used is 500 msec, so each 500 msec reading data from the receive buffer is done.

Three files are used by the user interface program. The "Receive_file.rcv" is used to save the telegram that the base station received from the alternative – LOTTE. In this file, only the correct telegram will be putted. The "Send_file.snd" is used to save the telegram that the base station sent to the alternative – LOTTE. The "Solar_file.rad" is used to save the position of the alternative – LOTTE in X, Y and Z and the solar radiation value. When the Solar Radiation button is pressed, this file will be opened to get the data from it and use these data to put the position of the alternative – LOTTE in a 3D figure with the value of the solar radiation. The command used to open a file from the visual basic is shown below :

Ø Open "C:\User Interface\Data\Send_file.snd" For Binary Access Write As

#2 (line of code: 104)

So before the user interface program putted in use, it is very important to put the correct path of the three files described above.

One program is used with the user interface. The purpose of this program is to showing the position of the alternative – LOTTE in a 3D figure with the value of the solar radiation during its flight. The command used to run this program from the user interface program is shown below :

Ø Shell "C:\3D\Jet.exe", vbNormalFocus (line of code: 85)

So it is very important to put the correct path of this program.

This program used with the user interface is called "Jet". This is an visual basic program. In this program, the "Solar_file.rad" is opened to get the data from it and used it to put the position of the alternative – LOTTE and the value of the solar radiation in a 3D figure as we said above. So it is very important to be care about the path of the "Solar_file.rad" file before using this program.

In the "Jet" program, the value of the solar radiation is always putted to the test whenever a value is received from the alternative – LOTTE. The purpose of this test is to changed the color of the position of the alternative – LOTTE, because the color of the point will give the user an idea about the power of the solar radiation at this point.

For the graphical show, a file is used (CURSOR20.ICO) when the user selects a region in the figure map for doing a zoom. This file must be in the same directory with the user interface program, or the path of this file should be specified.

Ø PictureMap.MouseIcon = LoadPicture("cursor20.ico") (line of code: 198)

Another program is developed using visual basic. The purpose of this program is just to build of a test environment with connected one of PC to the transceiver and connected the other PC to the other transceiver. By using this program, only sending and receiving data is allowed. This program uses a Send_Data function to send telegrams.

Note : If all the files and the programs used with the user interface program is putted in the same directory with it, so the path file will not be important, only the name of the file or of the program should be written.

8.6.2 Communication part on the board system on the airship

8.6.2.1 The tranceiver

The transceiver to be used is MB-STD-RS232. It is a bi-directional semi-duplex radio modem having RS232 serial interface. It uses CIRCUIT DESIGN 's standard 434 MHz FM Narrow Band transceiver module STD-402 transceiver for RF part. This transceiver was selected because of its frequency of 434 MHz. For this frequency in Germany there is no extra permission necessary. Another reason is that this transceiver is a cheap one.

The STD-402 transceiver is an UHF Narrow Band Multi channel Transceiver.

The UHF FM-Narrow Band semi-duplex radio data module STD-402 equipped PLL controller in its robust metal housing. Unlike other transceivers, the STD-402 is ready to transmit RF data without complicated controller board. The compact size and low power consumption of the STD-402 make it ideal for battery operated applications where its interference rejection and practical distance range are much better than similar RF modules based on Wide Band SAW – resonator frequency devices.

Most of RF setting are done by internal microcomputer, which allows the user to manipulate the module without professional knowledge of RF circuit.

Special for MB-STD-RS232

Figure 6.4: MB-STD-RS232 – CIRCUIT DESIGN

The RF part complies with the European radio, EMC and safety requirements and has been notified in major European countries under the R & TTE directive. The MB-STD-RS232 provides long range data link at low/medium data rate for various industrial telemetry and data transfer applications.

Also this board can be used as a test board of the STD-402 TR.

Features

· CE compliance STD-402 434 MHz RF module on the board.

· RS232 interface with D-sub 9pins connector or Modular 6pin jack.

· Fixed frequency / Auto frequency setting selectable.

· Cross / Straight cable selection SW.

Applications

· Serial data transmission (RS232C communication)

· Telemeter (FA line, Sensor information)

· Wireless connection between PC and peripheral RS232 equipment

General Description

MB-STD-RS232 is designed to make it possible for the user to connect between RS232 equipments with the radio. STD-402 434 MHz narrow band radio module that complies with EN300220 is equipped on the board. 64 channels are pre-programmed in the module.

There are two frequency setting are available. In fixed (manual) setting, RF channel can be set on board switches. In auto setting, RF channel is set to vacant channel automatically.

Operation mode and communication set up (Ack, parity, data rate) can be selected by on board dip-switch. The operation mode 1 is designed for two-way communication and the operation mode 2 is designed for one-way communication (TX -> RX).

1:N communication is possible by using unique module ID number that designated to each RF module.

Specification

RF parameter

Communication mode Half-Duplex

Frequency range 433.200 to 434.775 MHz

CH step 25 kHz

Number of CH 64 CH

CH setting Fix / Auto (8Gr*8ch)

Modulation data speed 9600bps

Modulation 2FSK

Emission class F1D

Transmission power 10 mW

Serial Interface

Interface RS-232C

Data format Asynchronous communication (UART) Data speed of RS 1200/2400/4800/9600 bps

Flow control RS / CS hardware control

Buffer Transmission 2kB, Reception 2KB

Interface connector D-Sub 9P / Modular 6P

Other

Switches Power, Frequency, Operation

Mode, Cable (Cross/Straight)

LED indication TX, RX, RSSI, LD, LE

Dimension 85*53*15mm

Supply Voltage 4.0 to 9V DC.

Figure 6.5: MB-STD-RS232 – CIRCUIT DESIGN

For more details about this board, refer to Annex A.

Special for STD-402 (Transceiver)

Figure 6.6: STD-402 Transceiver – CIRCUIT DESIGN

The STD-402 transceiver is an UHF Narrow Band Multi channel Transceiver.

The UHF FM-Narrow Band semi-duplex radio data module STD-402 equipped PLL controller in its robust metal housing. Unlike other transceiver, the STD-402 is ready to transmit RF data without complicated controller board. The compact size and low power consumption of the STD-402 make it ideal for battery operated applications where its interference rejection and practical distance range are much better than similar RF modules based on Wide Band SAW – resonator frequency devices.

Most of RF setting are done by internal microcomputer, which allows the user to manipulate the module without professional knowledge of RF circuit.

Features

· European EN300 200 standard compliance.

· High technology into compact module for easy operation.

· Low voltage operation from 3.6 V DC.

· Low current consumption, ideal for battery operated applications.

· 9600bps data rate.

· Carrier sense output for Multi-Channel access operation.

Application

· Remote control system.

· Security systems.

· Bi-directional communication systems.

· Telemetry systems

· Handy terminal.

STD-402 characteristics

v Common

Communication form Semi-duplex

Frequency range 433.200 MHz to 433.775 MHz.

Channel step 25 kHz.

Baud rate 9600bps max.

Supply voltage 3.6 – 12 V DC (Direct Mode).

Dimensions 53 ´ 35 ´ 12 mm.

v Transmitter

RF output power 9 mW ± 1mW.

Data input level 3.6 – 12V (Direct Mode).

Input signal Digital

Spurious emission < -60 dBm (< 1 GHz).

Supply current 36 mA.

v Receiver

Receiver type Double superheterodyne PLL synthesizer.

Selectivity ± 4 kHz at –6dB point.

Data output Digital.

The STD-402 transceiver has 3 mode operation guide :

1) Direct Mode Operation Guide (For more details about this mode, refer to Annex B)

2) Auto Mode Operation Guide. (For more details about this mode, refer to Annex C)

3) Auto Mode Operation Guide for CPU interface. (For more details about this mode, refer to Annex D)

Or the MB-STD-RS232 equips STD-402 transceiver module and performs packet communication using CPU interface mode of the transceiver.

8.6.2.2 The communication software on the embedded board computer

The code for this program is written in C. The program runs under the Real Time Operation System (RTOS) VxWorks on the embedded system in the alternative – LOTTE. The purpose of this program is to get the sensors data from one serial port and put it on another serial port which is connected to the transceiver.

The whole C program code is in Annex H.

The important thing in this program is the initialization of the serial interface communication, the following lines contain a description about this initialization :

Ø id_com_dev = open (c_device, O_RDWR ,0); (line of code: 17)

This command is used to open the serial port. When the serial port is not opened, this function returns –1.

Ø if (-1 == ioctl (id_com_dev,FIOBAUDRATE,speed)) (line of code: 24)

Ø SerialControl = (CLOCAL|CREAD); (line of code: 28)

Ø Parity = PARENB ; (line of code: 29)

Ø CharacterSize = CS8; (line of code: 30)

Ø if (-1 == ioctl (id_com_dev,SIO_HW_OPTS_SET,SerialControl | Parity | CharacterSize)) (line of code: 31)

Ø ioctlvalue = ioctl (id_com_dev,FIOSETOPTIONS,OPT_TANDEM &~

OPT_MON_TRAP); (line of code: 36)

These commands initialize the parity, the stop bit, the data length and the handshaking mode.

8.7 Component Tests

8.7.1 Transceiver test

The MB-STD-RS232 board which equips the STD-402 transceiver module has stored unique module identification number in the radio module. When one unit is set up for master and other unit is for slave, slave modem unit operate with same ID as master unit.

The test of the transceiver is shown in following lines :

1. Connect the serial cable to the D-SUB 9pin connector.

2. Set "Cable SW" (Cross / Straight) according to the cable.

3. Connect the supply voltage of the transceiver to 6V DC.

4. Select unit to be master and set SW1 to "9" and SW2 to "1". Select unit to be slave and set

SW1 to "9" and SW2 to "0".

5. Power ON the units.

6. When power of the master is turned on, TX, RX and LE LED turn ON and LD blinks.

Radio communication start and continue for about 10sec.

7. When power of slave unit is turned on, TX, RX LED turn ON and RSSI turn on when

signal from master is received. LD blink when group setting is completed.

8. After slave unit receives unique module identification code stored in master units, radio

communication can be performed with this code.

9. Power of the units.

10. Setting the mode and the property of the communication by the SW switch.

1 : ON à Transmitter 1 : OFF à Receiver

2 : OFF à Mode 1 (Two way communication)

3 : ON à Setting prohibited.

4 : ON à Setting prohibited.

5 : ON à ACK response (Yes).

6 : ON à Parity Yes (Even).

7 : ON à Communication speed.

8 : ON à Communication speed. (9600bps).

11. MB-STD-RS232 has 64 pre-programmed frequency channels. These frequencies are

divided to 8 groups. Each group contains 10 frequencies. The group can be selected by

SW2, and the value inside the group is selected by SW1. The frequency used to built the

test is 433.975 MHz. To select this frequency, set the SW1 switch to 3 and the SW2

switch to 1. The master and the slave unit should be selected to the same frequency.

12. Power on the units.

13. MB-STD-RS232 is in RX mode at wait time (stand by), which means RX is turned ON at wait time. When the unit receives radio data from the other unit, the RSSI LED turn ON

and the unit will start outputting the data to RS232 port.

14. When the unit get data from PC through RS232C connector, the data is stored in internal buffer and then will be sent after the MB-STD-RS232 check that the carrier

frequency to be set is not used in air. The TX LED turned ON when the unit will transmit the data. The unit returns to RX mode when all data is gone.

8.7.2 User interface laboratory test with two PCs

As described in the implementation in chapter 6, the important things before testing the user interface program is to take care about the path of the files that the user interface used, the program run with the user interface, the initialization of the serial port (number of port, baud rate, parity, data length, stop bit, handshaking mode, input mode ...), the interval of the timer used to read data from the receive buffer. If all these commands are done in the correct way, an EXE file can be made and used.

Connect one of the transceiver to a PC that contains the user interface program and the other transceiver to an other PC that contains the program used to send data (UserInterface_SendData). Then run the two programs and click the Sending_Data button and the data will be displayed in the user interface program each 500 msec as below :

Figure 7.1: position & direction of the alternative – LOTTE

Figure 7.2: parameters of the alternative – LOTTE

Figure 7.3: Status of the alternative – LOTTE

Figure 7.4: Weather parameters

As we see in the pictures above that the user interface test with the transceiver test work very well, and the data are received correctly and putted in their place.

8.7.3 Test of the user interface on the target system

To test the C program on the embedded system, run the TORNADO 2.0 then the following figure will be shown :

To open the connection between the TORNADO and the VxWorks machine, open the tools options, then select "Target server", then "PepVMP", then go to the list box to select the IP, after that the TORNADO inform you if the connection is done between it and the VxWorks machine.

So if the connection is ok, the user will be able to compile the C file, then open a shell to send commands to the VxWorks machine. Before running the C file on the VxWorks machine, you should download the C file on it, this thing can be done by select the project, right click on it and press Download "name of the project".

If all thing is done in the right way, the user will be able to type the name of the C program in the shell (In our project, the name of the C program is "maincom"), and the data is sent to the serial port of the VxWorks machine.

The whole code of the C test program used is shown in Annex G.

8.8 Annex A

Some trouble shooting

Phenomena	Cause of trouble
TX-LED blink	SW1, 2 setting error. Please check setting of SW1, 2.
RX_LED blink	Low voltage. Please check supply voltage
TX and RX LED blink by turns	Internal EEPROM is something wrong. Please contact us.
Both RX and RX LED turn ON And no transmission.	There would be interference at set frequency. Please change the frequency. Noise from PC might be the cause of the problem. Please try to leave the board from PCs and check it.

Frequency CH setting

There are two frequency settings are available.

· Fix setting (manual):

Frequency is set by switches (SW1 & SW2) on the board manually. RSSI-LED indication helps to set vacant channel.

· Auto setting:

MB-STD-RS232 search radio carrier to find vacant channel before starting radio communication and set to vacant channel automatically. For more details about the frequency table, refer to the data sheet (page 6,7)

Initial Setting (Master / Slave)

SW1	SW2	Function
9	0	STD-402 initial setting / set to Slave
9	1	STD-402 initial setting / set to Master
9	9	Setting mode (Lf, Ack, Character strings, etc..) and TEST

Operation Mode Setting SW

NO	Description		SW3 setting
			ON				OFF
1	Operation Mode		Transmitter				Receiver
2			Mode 2 (One-way communication)				Mode 1 (Two-way communication)
3	(Reserve)		Setting Prohibited				Off
4	(Reserve)		Setting Prohibited				Off
5	U A R T	ACK response	Yes				No
6		Parity	Yes (Even)				No
7		Communication Speed (bps)	ON	9600	OFF	4800	ON	2400	OFF	1200
8			ON		ON		OFF		OFF

Stop bit at UART Communication

Normally, Stop bit is selected one of 1 / 1.5 / 2 bit when COM port of PC equipment is set-up. When continuous data are outputted, data comes after stop bit. However there is a case that there is more time space than specified stop bit length because of asynchronous communication.

The MB-STD-RS232 receives the data from PC correctly if stop bit is 1 bit or more. Stop bit of data from the MB-STD-RS232 to PC is fixed to 2 bit therefore communication with PC can be made regardless of stop bit (1, 1.5, 2 bit).

Jumper Setting

There are 6 jumper settings on the board. Changing J4 and J5 can change LED-working condition to reduce the consumption current.

J1, J2, J3 : Module set up STD-402 434 MHz setting must be Short, Open, Open.

J4: LED operation of TX, RX, RSSI LED Use: Short Non Use (off): Open

J5: LED operation of LD, LE Use: Short Non Use(off): Open

J6: CPU reset signal: this must be short

Communication Interface

The board equips D-SUB 9pin and Modular 6pin as communication interface [8].

Figure A.1: Serial Connector

Signal	I/O	Modular 6P	D-Sub 9p (*)		Remark
RD (RX)	I	1	2	3	Input terminal / from PC
RS (RTS)	O	2	7	8	Hi when the equipment become data reception possible. Lo when internal Buffer is full
SD (TX)	I	3	3	2	Data output terminal / from PC
CS (CTS)	O	4	8	7	Hi when SD terminal send data Lo when SD terminal do not send data
GND (SG) DC (+)		5	5		GND
GND (SG) DC (+)		6	-		Supply power (DC 4 to 9V) is possible From Modular 6pin.

Communication Cable

Cross cable which mainly connect between PCs and straight cable which connect PCs and peripheral RS 232 equipment are available as RS 232 standard cable. Please set “Cable SW” (Cross / Straight) according to the cable. For more details ,refer to the Data Sheet (page 11,12).

Operation Mode

MB-STD-RS232 has two operation modes as below :

· Operation Mode 1: Two-way (Semi-duplex) communication

· Operation Mode 2: One-way communication

Ø Operation Mode 1: Two-way (Semi-duplex) communication

This mode is useful for an application of two-way communication with the Ack/Nck

Response between PC and RS232 equipment, and an application that returns the data from RS232 equipment to PC according to the command from PC MB-STD-RS232 is in RX at wait time (stand by). When the unit receives radio data from the other unit, the unit will start outputting the data to RS232 port. When MB-STD-RS232 get the data from PC through RS232C connector, the data is stored in internal buffer and then will be sent after the MB-STD-RS232 check that the carrier frequency to be set is not used on air. The unit returns to RX when all data in buffer is gone.

1:N communication is possible by implementing the group setting. In this case, the application software have to be programmed to consider that identification number of RS232 equipment have to be included in transmission command, and only the equipment which has requested ID number returns the data when its command is received. In this operation mode, Only Fix CH setting can be used.

Figure A.2: Two-way, Semi-Duplex Communication

Ø Operation Mode 2: One-way communication

This mode is useful for an application of one-way communication from PC to measurement equipment. TX (transmitter) / RX (receiver) setting can be done with dip switch on the MB-STD-RS232. TX unit transmit the signal at selected channel regardless that data is in buffer or not. RX unit outputs the data to RS232 port when radio signal is received. (RX unit does not transmit even data is imputed to RS232 port).

1:N communication is possible by implementing the group setting. 1 * TX unit to N * RX units communication is possible.

In this operation mode, Either Fix channel setting or Auto channel setting is used.

In Auto setting, TX unit perform automatic RF channel search and transmit the data in the vacant RF channel. RX unit perform channel scan to detect transmission signal and set to the RF channel.

Figure A.3: One-way Communication

Restriction on data communication

The MB-STD-RS232 equips STD-402 transceiver module and performs packet communication using CPU interface mode (data length 63bit) of the transceiver.

Serial data or command stream from PC or other equipment connected to the MB-STD-RS232 is pocketed and sent to a receiver. When these data are outputted from the unit, the time space appear as shown below. The time space (delay) is 300msec or more when operation mode 2 (One-way communication) is used.

Figure A.4: Data Communication

ACK Auto Response Function

Depending on RS232 equipment, but some equipment stop or become error and repeat transmitting same data if Ack/Nck command is not returned as response signal within several 10msec.

This is not problem in wired communication because PC can return Ack/Nck command immediately after receiving data from RS232 equipment. Wireless communication with the MB-STD-RS232 have a few second time-lag for the response. This function is given to avoid error caused by such situation. It is realized to return Ack (or specific response string) response return.

MB-STD-RS232 operates as that the data from RS232 equipment is suppose to carry delimiter symbol (Etx, Lf etc…) at end.

When Ack/Nck character is contained in output from RS232 equipment, MB-STD-RS232 judges that the Ack/Nck character is the response from PC and when it is not contained the output is recognized as data stream (i.e. measurement data) for request

data command from PC. The MB-STD-RS232 sends Ack response only if this data

stream (without Ack/Nck) is recognized.

(If there is data in TX buffer, the Ack will be sent after that).

Delimiter, Ack/Nck and character string to recognize these operation can be changed by user.

Example

Delimiter “Lf” (0AH)

Response detect code 1 “Ack” (06H)

2 “Nck” (15H)

Auto response character string “Ack CR Lf” (06 0D 0AH) Max. 16 characters

Figure A.5: ACK Auto Response

Group Setting

The MB-STD-RS232 has stored unique module identification number in the radio module. When one unit is set up for master and other unit(s) is for slave, slave modem unit operate with same ID as master unit.

If this setting (group setting) have not finished, radio communication between the MB-STD-RS232 is not possible even with same frequency.

Ø Setting Procedure

Select unit to be master and set SW1 to “9” and SW2 to “1”. Select unit(s) to be slave and set SW1 to “9” and SW2 to “0”. Power on the units.
When power of the master unit is turned on, TX, RX and LE LED turn ON and LD LED blinks. Radio transmission start and continue for about 10sec.
When power of slave unit(s) is turned on, TX, RX LED turn ON and RSSI turn ON when signal from master is received. LD blink when group setting is completed.

After slave unit receives unique module identification code stored in master units, radio communication can be performed with this code.

Note: This setting is to set identification code for radio communication. Original unique module identification code of slave unit itself remains unchanged. When the unit was used for slave is set to

master and perform communication, identification number is different from former communication. Therefore interface does not occur.

Figure A.6: Master & Slave Units

Ack Auto Response Setting

Delimiter, Ack/Nck code and auto response character string (max. 16 characters) for recognition of Ack auto response can be changed from RS232 port using software like Windows Hyper Terminal.

Ø Procedure

1. Connect MB-STD-RS232 and PC with RS232 cable. Set SW1 and SW2 on the MB-STD-RS232 to “9”, “9”, then power ON.

2. Start up the Hyper Terminal and set communication condition as below.

4800bps, Bit = 7, Parity = Odd, Stop Bit = 1, Flow control = Hard ware.

3. At first, type “/A CrLf” and return. Check if the MB-STD-RS232 modern return the product name and program version.

4. Set up with reference to the following table.

Command

Transmission format

Correct Response

Data (example)

Description

“/A”

“/A CrLf”

“/A MB-STD-RS232,

001.000 CrLf”

Product name, Program ver.

“/I”

“/I 06, 0D, 0A CrLf”

“Ok CrLf”

Set and check of Ack response character sting (HEX)

Max. 12 character (prohibit to include ASCII code “00”)

“/I CrLf”

“/I 06, 0D, 0A CrLf”

“/K”

“/K 06 CrLf”

“OK CrLf”

Set and check of Ack response detect code 1 (HEX).

Example : 06H = Ack

“/K CrLf”

“/K 06 CrLf”

“/L”

“/L 15 CrLf”

“/L OK CrLf”

Set and check of Ack response detect code 2 (HEX).

Example : 15H = Nck

“/L CrLf”

“/L 15 CrLf”

“/M”

“/M 0A CrLf”

“OK CrLf”

Set and check of delimiter (HEX)

Example : 0AH = Lf

“/M CrLf”

“/M 0A CrLf”

Circuit diagram for the MB-STD-RS232

8.9 Annex B

¨ STD-402 [Direct Mode Operation Guide]

General Description

The STD-402 is a short range device stipulated by CEPT/ERC recommendation 70-03 and is a radio module complying with ETSI standard EN300-220-1 with a transceiver built into its compact case.

The built-in PLL synthesizer circuit enables both transmission and receipt through 64 pre-set channel frequencies between the 433 to 434 MHz bands.

The transmit mode / receive mode settings and the frequency channel settings can be made easily with dip switches or jumpers without the use of an external microcomputer.

As the system operates on low voltage and low current consumption in consideration of mobile communications, battery operation is also possible.

The FSK modulation enables transmission at a maximum of 9,600bps. Also, when multiple channels are to be used simultaneous or if high communication standards are required, the

MSK modulation enables transmission at a maximum of 2,400bps. However, it is necessary to install an MSK modem IC externally for this purpose.

The radio module has been designed with high levels of reliability cultivated through long-term results, and this provides excellent levels of selectivity receiving sensitivity and radio interference capabilities.

Features

· Comply with EN 300 220

· Compact size (53mm * 35mm * 12mm) with built-in transceiving functions (STD-402)

· Baud rate of maximum 9,600bps

· Simple channel setting with switches

· Continual “0” or “1” data transmission for a maximum of 20msec.

· High-level endurance capabilities against the effects of antenna reflection and surrounding equipment

· Low-voltage operations : 3.6 V to 12 V

· Low-current consumption : 36mA (transmit mode), 26mA (receive mode)

Applications

v Telecommand and Telecontrol

v Telemetry

v Alarms

v Data terminals

Pin description

Number	Pin Name	I/O	Description	Equivalent circuit
1	CAR (STATUS)	O	Carrier sense output of the receiver. The RSSI signal (receiving level) Will become “H” when the signal exceed the threshold.
2	RSS	O	The receiving level output of the receiver. The strength of the RF level is converted to the direct current voltage.
3	AF	O	The AF output of the receiving section.
4	DO	O	The data output for the receiving section. The port uses FET buffer output, the “H” level is Vcc.
5	T/R	I	TX(transmit mode) / RX (receive mode) setting. The port is pulled up with resistor. TX mode: L (GND) RX mode: H (Open)
6	DI	I	Data input for the transmission section. The port uses transistor input, the digital “H” level is Vcc and the digital “L” is GND.
7	VCC	-	The power supply terminal. Operates on 3.5V to 12V, but the same Vcc level as the surrounding circuits must be used.
8	GND	-	The ground. Extend the pattern over the widest area possible on the printed circuit board.
9	LD	O	· The LOAD signal output for External parallel -> serial register · The RESET signal is output with The receive mode. · The port uses FET buffer output, the “H” level is Vcc.
10	LE	I/O	· The LATCH ENABLE signal output for external serial -> Parallel register. · Setting mode switch input.
11	RDY (CLK)	O	The READY signal output. RDY is Active when at “L”. The following Conditions apply when RDY is “H”. (1) Initial status. (2) CAR is “H” Call name being transmitted.
12 13 14 15 16 17	CH5 CH4 CH3 CH2 CH1 CH0	I	· Set the various conditions when in the setting mode. · Sets the ID address with normal operations. 63 address types between 1 and 63 are available. · Pulls up each port.

Electrical characteristics

· Common characteristics

Item	Rating	Conditions/remarks
Communication form	Semi-duplex
Modulation	F1D	FSK
Oscillation system	PLL controlled VCO
Frequency range	433.200 – 434.775 MHz
Channel step	25 kHz
Number of RF channel	64 channels
Baud rate	4800, 9600bps	FSK
Modulation polarity	Positive
Demodulation polarity	Positive
Antenna impedance	50 Ohm
1st IF	21.7 MHz
2^nd IF	450 kHz
Range	200m or more	F1D 9600bps
Operation temperature	-10 to 55°C
Operation power voltage	3.6 – 5V
Supply current	36mA	TX mode
Supply current	26mA	RX mode
Dimensions	533512mm
Weight	34g

· Transmission section characteristics

Item	Rating	Conditions
Transmitter type	PLL synthesizer
RF output power	9.0mW ± 1.0mW	10mW
Frequency stability	± 4ppm	-10 to + 55°C
Spurious emission	< -60dBm	< 1GHz
Spurious emission	< -50dBm	> 1GHz
Deviation	±1.9 to 2.1 kHz	*1
S/N ratio	> 25dB	*1
Adjacent channel power	> 40dB	Spectrum analyzer act. *1
Carrier sense level	-107 dBm	Fixed
Transmitter start-up time	< 30msec	PLL data setting
Channel switching time	< 15msec	25KHz
Channel switching time	< 30msec	100KHz

*1: 9,600bps, 511 bit (Pseudo Noise)

· Receiving section characteristics

Item	Rating	Conditions
Receiver mode	Double super heterodyne
Sensitivity	< -117 dBm	25°C, *2
Spurious response	> 45dB	*3
Selectivity	> 45dB	*3
Local frequency stability	± 4ppm	-10 to +55°C
Radiation from local oscillator	< -65 dBm	< 1GHz
Radiation from local oscillator	< -60 dBm	> 1GHz
Output level	350m Vp-p	100Kohms terminate *4
Carrier sense level	-113 dBm	Fixed
Carrier sense response time	< 30msec	PLL data setting
Channel switching time	< 15msec	25KHz
Channel switching time	< 25msec	100KHz
Bit error rate	1 ´ 10^-2	Less than –110dBm
Bit error rate	1 ´ 10^-4	Less than –107dBm

*2: AF = 1KHz, fmod = 2KHz, CCITT filter ON

*3: Jamming waves AF = 400Hz, fmod = 40%

*4: Dev:= 2Khz, AF = 1KHz

*5: 256bit / 4800bps

Modes

The STD-402 can be controlled manually with a simple set of external switches and jumpers, or with microcomputer controller.

Figure B.1: Models & Modes

Modulation mode

· The maximum baud rate is 9,600bps with FSK. The data format may be decided by the user.

· The MSK modulation is recommended when stable operations are required during the use of multiple channels within the same area. However, the MSK mode requires an external MSK modem IC (MSM6882 manufactured by OKI or an equivalent model). Restrictions in the performance of this IC mean that the maximum baud rate is 2,400bps.

Figure B.2: Modulation Mode

For more details about the channel table and the Manual Mode, refer to Data Sheet (page 2...18).

Transceiver mode with microcomputer

· Connection method

Ø More complex settings are made available when the STD-402

modes and channels are controlled by microcomputer.

Ø By developing microcomputer software that monitors the STD-402 READY ports, it is possible to avoid channels already occupied by

other radios in the same way as MCA (Multi-Channel Access) and

automatically set up empty channels.

Figure B.3: Connection Method

Timing for transmit mode setting

· The flow chart and timing chart for transmit mode setting when under microcomputer control are provided below.

Figure B.4: Timing for transmit mode setting

Timing for receiving mode setting

· The flow chart and timing chart for receive mode setting when under microcomputer control are provided below.

Figure B.5: Timing for receiving Mode

MSK Modulation mode

· Modem IC

Ø The MSM6882 MSK modem IC manufactured by OKI is recommended for the MSK (Minimum Shift Keying) modulation mode.

Ø Modulation MSK waves are emitted by loading transmission data into

the encoder.

Ø The decoder converts MSK waves into receiving data.

Ø Examples for the application of the MSM6882 terminal function, the

transmission mode and the receiving mode are provided in the Data

Sheet. For more details, refer to STD-402 Direct Mode Operation Guide (page 21, 22, 23)

Cautions

· Power supply

Ø The operating voltage range for the STD-402 is between 3.6V and 12.0V.

A voltage exceeding the maximum of 12.0V will result in damage to the

device.

Ø Ensure that an open drain or open collector port is connected when the

TX/RX, CH0 to CH5 and external circuits are connected together.

Figure B.6: Power Supply

· Reverse connection protection circuit

v When using low-voltage with battery operations

Figure B.7: Protection Circuit

· As the maximum battery supply current will flow into the diode

when the battery is connected in the reverse position, much

consideration must be given to the PC (heat loss) in the diode.

· Although this method is the simplest, long-term heat emission

may result in the outbreak of fire. Take extreme caution when

handling this.

v When using high-voltage mains power for stable operations

Figure B.8: High Power

· Although this method will not result in the buildup of heat in the

diode, it will result in a lowering of the forward voltage in the

diode and the efficiency rate of the mains power will be lower

with batteries and other low voltages.

· The forward voltage will differ depending on the type of the

diode, but the general rectification is approximately 0.6 to 0.7V.

Antenna

v Antenna and radial

· the STD-402 antenna is approximately 17cm with a one quarter wavelength in the 434MHz band. The unit¢s metal case not only acts as the ground but is also known as the radial to radiate the electronic radio waves from the antenna and radial. The phase is in inverted with the redial and antenna.

· Increase the module¢s ground pattern as much as possible. The electronic wave radiating power is strongest at the tip of the antenna, and when brought close to the unit¢s case, or radial, will work to cancel each other out, causing dramatic effect to the arrival distance.

Figure B.9: Antenna

v Incorporating into equipment

· A direct line is ideal for the antenna, but it should be separated from the case as much as possible when space for incorporating it into the equipment is limited.

Measured data

8.9.1 Block diagram of the STD-402 transceiver in Direct Mode

8.10 Annex C

¨ STD-402TR [Auto Mode Operation Guide]

8.10.1 General

The STD-402 auto mode is a operation mode that is equipped with automatic link function and an encoding/decoding function. Automatic link searches vacant channels in order to use forty six channel frequencies without hindrance or interference. The encoding/decoding function establishes an interface between the data I/O circuit and radio assembly and executes the necessary communication protocols.

The transmitter¢s input circuit and the receiver¢s output circuit can easily be connected together with a general-purpose IC.

Note: The STD-402 auto mode supports only one-way communication (uni-directional) transmissions (transmitter -> receiver) but support for simplex communications (bi-directional) is planned for the future.

8.10.2 Features

· The automatic link function automatically connects to channels that do not cause interference.

· Simple I/O circuits with the built-in encoder/decoder.

· The I/O connections can be expanded to a maximum of 63 bytes

· The built-in micro-computer greatly reduces the cost of new development.

· Perfect for combining with other equipment.

8.10.3 Application Examples

Ø One-way system

v Tele-control

· For controlling cranes, concrete pump vehicles, golf carts, remote opening/closing for various purposes, traffic lights for road works, etc...

Support for the following applications is planned for the future.

Ø Simplex systems

v Data transmission

· Handy terminals, bar-code readers

v Security

· Transmission of anti-theft alarms, immobilizes for cash delivery trucks, notification of customers entering retail shops, etc.....

v Telemeter

· Water level monitoring for canals and dams, etc..., monitoring of various alarms, etc... .

8.10.4 Configuration

· The auto mode automates numerous functions with the use of the built-in micro-computer.

Figure C.1: Configuration

· The features of both modes are shown in the table below

Figure C.2: Mode

Explanation for internal processes (1) [Automatic channel search]

· the automatic channel search is a system that detects the carrier level of the channel in use to search for vacant channels in order to avoid interference with other radios. This is controlled automatically by the built-in micro-computer.

· The channel search is executed by the module from the pre-determined starting channel.

· For example, if the channel search was executed from [0ch], the procedure would be as follows :

1. The STD-402 is set in the receiving mode.

2. Set as channel 0 (433.200MHz)

3. The carrier level is detect and compared with the standard level

4. If the channel is occupied, the frequency is increased by two channels (50KHz).

5. If the channel is vacant, the system is switched across to the transmission mode.

6. The vacant channel is set.

7. Transmission is started.

Figure C.3: Automatic Channel Search

Explanation for internal processes (2) [Automatic link]

· This is controlled automatically by the built-in micro-computer in the same way as the automatic channel search.

· All modules are started from [0ch] in the case of the automatic link.

· The channel search is executed by the module from the pre-determined starting channel.

· For example, if the channel search was executed from [0ch], the procedure would be as follows :

1. The transmitter set for the vacant channel commences transmission.

2. The receiver is set at channel 0 (433.200MHz).

3. The carrier level is detected and compared with the reference level.

* the reference level is different for the transmitter and receiver.

4. If it is below the standard level, the frequency is increased by one channel (25KHz).

* Increased by two channels for transmitter, but only one channel for the receiver.

5. The ID data is received and compared with the ID register.

6. Increased by one channel (25KHz) if the ID number matches.

7. Switched across to the communication mode if the ID number matches.

Figure C.4: Automatic Link

Explanation for internal processes (3) [ID number registration]

· It is necessary to register an ID number for the transmitter and receiver in order to enable the STD-402 to establish an automatic link between two devices.

· If the transmission is performed on the same frequency from another radio or an STD-402 with a different ID number, the receiver will continue to search the channels until it finds an ID number that matches its own.

Ø Registration of ID

· The serial number is unique number set in the factory at the time of shipment and can only be read.

· The ID register is a register for storing the ID number.

Figure C.5: ID Number Registration

· As shown above, the number registered in the ID register remains the same even when switching between the transmitter and receiver, so it is not necessary to register a new ID number.

Explanation for internal processes (4) [Encoder]

Ø Connection method

· The illustration below shows the basic circuit when the STD-402 is used in the TX mode (transmitter).

· The 74HC165 is a general-purpose 8-bit parallel input -> serial output converter.

· The STD-402 detects disconnection, so ensure that a DO is connected to the SI.

Figure C.6: Encoder

Ø Timing chart

· The timing for the STD-402 TX mode is shown below.

· The micro-computer built into the STD-402 is equipped with an encoding function and communication protocols to convert the automatic link ID numbers, the various control data and the transmitted data into FSK data.

· The entire data is called as a ¢frame¢, and the transmission data is inserted once into a single frame. The data is transmitted continually until the power supply is switched off.

· The length of the control data is fixed, but the transmission data can be changed between 1 byte to a maximum of 63 bytes in accordance with the application.

Figure C.7: Timing chart for STD-402 TX mode

(1) The parallel data is latched onto the clock asynchronously when the LD signal is “L”

(2) Serial data is shifted at the RDY (clock) rises when the LD signals is “H”.

Explanation for internal processes (5) [Decoder]

Ø Connection method

· The illustration below shows the basic circuit when the STD-402 is used in the RX mode (receiver).

· The 74HC595 is a general-purpose serial input -> 8-bit parallel output converter.

· The STD-402 detects disconnection, so ensure that a QH is connected to the DI.

· The 74HC595 latch data is cleared when LD is ²L²

Figure C.8: Decoder

Ø Timing chart

· The timing for the STD-402 RX mode is shown below.

· The micro-computer built into the STD-402 is equipped with a decoding function and communication protocols to convert the received FSK data into control data and the transmitted data (serial data).

· The transmission data is output once into a single frame. The data is received continually until the power supply is switched off.

Figure C.9: Timing chart for STD-402 RX mode

(1) The serial data is shifted when the RDY (clock) rises.

(2) The parallel data is latched onto the clock asynchronously when the LE signal rises.

Explanation for internal processes (6) [Data format]

Ø Communication data format

· The STD-402 control data is of fixed length and comes in a unique format that includes the ID code for radio links and special codes.

· The user data (transmission data, receiving data) is between 1 byte and 63 bytes depending on the number of I/O connections, and the transmission time will be extended in accordance with the length of the transmission data.

· The communication data format is shown below.

Figure C.10: Data Format

Ø Transmitting data between Transmitter and receiver

· The communication data is transmitted continually during transmission. However, the transmission data will not actually travel continuously at 4,800bps owing to the fact that the control data is transmitted by frame by the encoder.

· Using 1 byte of data as an example, the data volume (number of bytes) transmitted within a one-second period is as follows.

D = 1000msec ¸ {20msec + (1.67msec ´ 1)} » 46 bytes.

Figure C.11: Transmitting Data between TX and RX

For more details about the Encoder/Decoder and the setting mode, refer to Data Sheet (page 13...19)

Communication mode

· the communication mode enters normal operation when the power supply is switched on after all transceiver settings have been made in the setting mode.

· First of all with the communications mode, a link is established with the transmitter and receiver with the same ID number in accordance with the procedure explained for the automatic link, and data transmission is then started.

· Once a link has been established, communication will be carried out on the same channel unless the power supply is switched off.

Local ID numbers

· It is possible to transmit the data from one transmitter to a maximum of 63 different receivers with the STD-402 auto mode.

· Local ID numbers must be set for each of the receivers for identification purposes. The ID numbers are set with the CH0 to CH5 ports.

· The (LD = L) reset signal is output and the data is cleared under normal conditions when the ID number of the transmitter and receiver do not match. [LD] is invalidated and the receiving data is output if the ID numbers do match. However, if the ID number for the data and clock matches, it is output regardless of the local ID.

· If the ID number for the transmitter is [0 (ALL)], the receiver will output the data regardless the ID number.

Figure C.12: Local ID Numbers

Figure C.13: Communication 1:N

Figure C.14: Communication 1:1

To see the ID address table, refer to Data Sheet (page 22).

8.10.5 diagram of the STD-402 transceiver in Auto Mode

9 Annex D

¨ STD-402 [Auto Mode Operation Guide for CPU Interface]

Or the board used to equips the STD-402 is the MB-STD-RS232, so the this mode (Auto Mode Operation Guide for CPU Interface) is used like mode of the STD-402 transceiver.

Auto mode : CPU interface conceptual illustration

Ø Wired Communication

Figure D.1: Wired Communication

Above image shows basic construction of data communication with SIO (Synchronous Serial Input Output)

Ø Radio Communication through STD-402 Auto mode

Figure D.2: Radio Communication

Above figure shows the communication that replaces the wire with the radio module (STD-402). Radio communication is not stable as wired communication.

In addition, the procedure in the beginning of radio communication link (connection between transmitter and receiver), TX/RX switching and the disconnection of radio communication are unique for radio communication therefore specific protocol is required for radio communication.

STD-402 auto mode provides such specific protocol as the function of radio link, frequency channel selection and encode/decode.

Transmission concept

Figure D.3: Transmission Concept

Data from SO (Serial Output) of CPU, which is shifted on the raising edge of clock signal is imputed to DI (Data Input) of STD-402. User data can be set with any data size in byte from 1-63 byte. STD-402 internal CPU adds identification code, error correction code and other internal process code and then transmit them as modulation data in frame.

Reception concept

Figure D.4: Reception Concept

When the receiver receives data of which ID code, error correction and code and other internal process code are matched, only user data is outputted from DO by byte in synchronism on the rising edge of clock. If no signal is received or any of ID code, error correction or other process code is not matched, CLK and data signal does not appear.

Connection between STD-402 and CPU

Figure D.5: Connection between STD-402 & CPU

STD-402 Terminal Description

Terminal	Description
DI	Transmission data input terminal Connect to SO (Serial Output) of CPU
DO	Receive data terminal Connect to SI (Serial Input) of CPU
RDY (CLK)	Shift clock output for SO and SI serial data
T/R	Transmitter/Receiver function select terminal L: TX, H: RX
CAR	Status signal for transmission/receive and multiplex switching signal for CH0-5. The port shows L when TX and H when RX. Multiplex switching signal comes at end of frame. It can be used for frame status signal.
CH0 – 5	Input ports for Mode & data rate, frequency channel selection mode (Auto/Fix) and data length (1 – 63 byte) for initial setting. Input port for local ID (0 – 63) and frequency channel (0 – 64 channel) during normal operation.

Communication Protocol

9.1 9.2 STD-402 Data Format

Figure D.6: Communication Protocol

STD-402 communication data format is shown as above. STD-402 internal CPU will make above data automatically except User data. Data connection is possible by feeding user data (1 – 63 bytes) to 3 wire SIO ports of CPU in synchronism with CLK.

In each frame, STD-402 process the data internally and Input/Output user data. In general, data is sent and received as “packet”.

Initial Setting

Initial setting configures STD-402 internal setting.

1. MODE

Ø Direct mode

Ø Auto mode: (Logic interface)

Ø Auto mode: CPU interface

2. FREQUENCY CH (channel)

Ø Auto channel mode STD-402 automatically search vacant channel and make radio link.

Ø Fixed channel mode – Set frequency channel to 0 – 63 channel.

3. DATA LENGTH

Ø User data length per frame (1 to 63 byte)

Setting to transmitter (master) and receiver (slave) is different. MODE is set to both transmitter (master) / receiver (slave). FREQUENCY CH and DATA LENGTH are firstly set to transmitter (master) then these data are transmitted to receiver (slave) and then the receiver (slave) memorizes the data.

Above three setting data (MODE, FREQUENCY CH and DATA LENGTH) are inputted to CH0 – 5. MODE and FREQUENCY CH data are inputted to the ports in multiplex process, and DATA LENGTH data are inputted from the port for Mode in sequence.

Initial setting process will start with LE port “L” at power ON and complete with LE port “H”. In normal operation, power supply of the module must turn ON with LE port “H”.

It is recommended to use regulator with controller terminal for STD-402 power supply control.

Completion of initial setting can be confirmed with LD port output.

For more details about setting parameter, refer to Data Sheet (page 9)

9.2.1 Transmitter : Initial setting flow chart

Figure D.7: TX Initial Setting Flow chart

Receiver : Initial setting flow chart

Figure D.8: RX Initial Setting Flow chart

Normal Operation

Local ID and Frequency CH can be set at CH0 – 5 in Normal operation.

Local ID

Set Local ID (0 to 63)

Frequency CH

Fixed channel mode (0 to 63 CH)

Ø In normal operation, CLK will be outputted when STD-402 internal set-up is completed and data communication is ready after power ON, TX/RX switch and frequency CH change. CPU needs to check interruption.

Ø Set up and communication link between TX and RX. Approximately 10msec of frequency setting time is needed because STD-402 uses a synthesizer system. Also, demodulation circuit in the receiver work in AC

operation, DC drift occurs specially when power is supplied. Thus, RF

communication is not stabilized during approx. First 100msec. It is therefore recommended to send dummy data (example 00H) few times before sending actual data.

Ø Carrier Sense

STD-402 performs carrier sense function to check the set channel is busy or vacant. When module is set fixed channel mode and the set channel is occupied, a clock is not outputted from STD-402. In this case, please wait for interruption or change the other frequency channel.

Transmitter: Timing at power ON

Ø Following shows transmitter timing chart at the time of STD-402 power supply ON. Set to T/R port to “L” (transmit).

Ø Transmission cycle of data is defined as frame. Following timing figure shows one byte transmission. It can be set any byte from 1 to 63 bytes. Time of 1 frame is (20 + the number of byte * 1.7) msec.

Ø Data transmission is not possible during module setting time (240msec). It is recommended to send 1 to 5 frame dummy data (example 00H) at the beginning of transmission to help initial radio communication link.

Ø T/R port, frequency CH and local ID data will be read at the end of frame.

Figure D.9: TX, Timing at power ON

Transmitter: Flow chart at power ON

Figure D.10: TX, Flow chart at power ON

Receiver: Timing at power ON

Following shows Receiver timing chart at the time of STD-402 power supply ON. Set T/R port to “H” (Receiver).

Ø Receiving cycle of data is defined as frame. Following timing figure shows one byte transmission. It can be set any byte from 1 to 63 bytes. Time of 1 frame is (20 + the number of byte * 1.7) msec.

Ø Data can not be received during module setting (approx. 165 msec).

Ø T/R port, Frequency CH, and Local ID data will be read at the end of frame.

Ø Following shows timing that receiver turns ON when radio signal from transmitter has been transmitted.

Figure D.11: RX, Timing at Power ON

9.2.2 Receiver: Flow chart at power ON

Figure D.12: RX, Flow chart at Power ON

Transmitter: Frequency channel change timing

Following shows timing chart at time when the transmitter frequency channel is changed from 7 to 39 channel.

Ø Channel data will be read at the end of frame and the data will be set at next frame. If channel data is changed at 1 msec or later after final clock (CLK), the data will be read at next frame.

Ø The figure shows the example that data size is one byte. Data will be read by 22 msec span.

Ø Data transmission is not possible during channel switching and setting period (approx. 210 msec.). The channel switching time is same at any channel set.

Ø Transmission will stop and CLK will not be outputted during channel switching and setting period.

Ø Frequency channel change must be done at the same time for both TX and RX.

Figure D.13: TX, Frequency CH change timing

Transmitter: Frequency CH change flow chart

Figure D.14: TX, Frequency CH change Flow chart

Ø Frequency CH data is read at the end of data frame. See timing chart for detail.

Ø After frequency CH is switched, transmission become possible when CLK is outputted.

Receiver: Frequency channel change timing

Ø Following shows timing chart at time when the receiver frequency channel is changed from 15 to 32 channel.

Ø Channel data will be read at the end of frame and the data will be set at next frame. If channel data is changed at 1 msec or later after final clock (CLK), the data will be read at next frame.

Ø The figure shows the example that data size is one byte. Data will be read by 22 msec span.

Ø Data reception is not possible during channel switching period (approx. 210 msec.). The channel switching time is same at any channel set.

Ø Reception will stop and CLK will not be outputted during channel switching.

Ø Frequency channel change must be done at the same time for both TX and RX.

Figure D.15: RX, Frequency CH change timing

Receiver: Frequency CH change flow chart

Figure D.16: RX, Frequency CH change Flow chart

Ø Frequency CH data is read at the end of data frame. See timing chart for detail.

Ø After frequency CH is switched, reception become possible when CLK is outputted.

Timing at Transmitter -> Receiver switching

Ø Following shows timing chart at time when the module switches from transmitter to receiver.

Ø T/R port will be read at the end of frame and the data will be set at next frame. If T/R port is changed at 1 msec or later after final clock (CLK), the data will be read at next frame.

Ø The figure shows the example with one byte data size and 4800bps data rate.

Ø Data reception is not possible during the receiver setting period (approx. 365 msec.).

Ø Reception become possible when CLK is outputted.

Figure D.17: Timing at TX –> RX switching

Timing at Receiver -> Transmitter switching

Ø Following shows timing chart at time when the module switches from receiver to transmitter.

Ø T/R port will be read at the end of frame and the data will be set at next frame. If T/R port is changed at 1 msec or later after final clock (CLK), the data will be read at next frame.

Ø The figure shows the example with one byte data size and 4800bps data rate.

Ø Data transmission is not possible during the receiver setting period (approx. 200 msec.).

Ø Transmission become possible when CLK is outputted.

Ø As described in timing at power ON, send dummy data “00H” for 1 – 5 frame at beginning of transmission to make radio link with receiver.

Figure D.18: Timing at RX -> TX switching

Transmitter <-> Receiver switching flow chart

Figure D.19: TX <-> RX switching Flow chart

Ø TX -> RX or RX -> TX change data will be read at end of frame.

Ø After switching TX/RX, transmission and reception is possible when CLK is outputted.

9.3 Annex E: Visual Basic code for the user interface program

1 ' Parameters using to do a Zoom on the PictureMap

2 Dim r1 As Integer, X1 As Integer, X2 As Integer, Y1 As Integer, Y2 As Integer

3 Dim ULeftX As Integer, ULeftY As Integer, Target As PictureBox

4 Private Sub C_Close_Click()

5 'Close the Serial Port

6 MSComm1.PortOpen = False

7 'Close the Receive_File

8 Close #1

9 'Close the Send_file

10 Close #2

11 'Close the Solar_file

12 Close #3

13 'Close the User Interface Program

14 'Close the FormMap Program

15 'Close the FormDirection Program

16 Unload FormMap

17 Unload FormDirection

18 Unload Me

19 End

20 End Sub

21 Private Sub C_Connection_Click()

22 'Wait for Data (Sensors Data) to come to the Serial Port

23 ' 116 is the length of the Receive_Message

24 Do

25 DoEvents

26 Loop Until MSComm1.InBufferCount >= 116

28 ' Call the function used to Read Data from Serial Port ( Read_Data)

29 ' and in this function, we will test the Begin and the End Flag

30 Read_Data

31 End Sub

32 Private Sub C_Send_Cancel_Click()

33 'Enable the timer used for Receive Data form serial Port

34 TimerRun_R.Enabled = True

35 'Disable the SDF ( Sending Data Frame)

36 SDF.Visible = False

37 'clear the TextBoxes from the data

38 T_newPos_inX.Text = ""

39 T_newPos_inY.Text = ""

40 T_newPos_inZ.Text = ""

41 T_newVel_inX.Text = ""

42 T_newVel_inY.Text = ""

43 T_newVel_inZ.Text = ""

44 End Sub

45 Private Sub C_Send_Commands_Click()

46 'Enable le SDF (Send_Data_Frame)

47 SDF.Visible = True

48 'Clear the Transmit Buffer

49 MSComm1.OutBufferCount = 0

50 'Clear the TextBoxes from Data

51 T_newPos_inX.Text = ""

52 T_newPos_inY.Text = ""

53 T_newPos_inZ.Text = ""

54 T_newVel_inX.Text = ""

55 T_newVel_inY.Text = ""

56 T_newVel_inZ.Text = ""

57 'Set the Cursor in the first TextBox (new_Position inX)

58 T_newPos_inX.SetFocus

59 End Sub

60 Private Sub C_Send_OK_Click()

61 'Testing the status of the new information (TextBoxes)

62 If (UserInterface.T_newPos_inX.Text = "" Or UserInterface.T_newPos_inY.Text = "" Or 63 UserInterface.T_newPos_inZ.Text = "" _

64 Or UserInterface.T_newVel_inX.Text = "" Or UserInterface.T_newVel_inY.Text = "" Or 65 UserInterface.T_newVel_inZ = "") Then

66 MsgBox (" SORRY, but you should put a number in these TEXTBOXES !!!!!")

67 T_newPos_inX.SetFocus

68 Else

69 'Disable the Timer using for Read_Data

70 TimerRun_R.Enabled = False

71 'call the function used for writing Commands in the Transmit Buffer

72 Write_Commands

73 'Disable the SDF (Send_Data_Frame)

74 SDF.Visible = False

75 'Enable the Timer used for Reading Data

76 TimerRun_R.Enabled = True

77 End If

78 End Sub

79 Private Sub C_Solar_Radiation_Click()

80 'Close the Solar_file.rad

81 Close #3

82 'Execute the Program used to draw the Position of the

83 'ALTERNATIVE-Lotte in the 3D (three Dimensions) with

84 ' the value of the Solar Radiation

85 Shell "C:\3D\Jet.exe", vbNormalFocus

86 End Sub

87 Private Sub Form_Load()

88 'Initialisation the form of the User Interface

89 UserInterface.Width = Screen.Width

90 UserInterface.Height = Screen.Height

91 'Initialisation of the position of the ALTERNATIVE-Lotte on the MAP

92 CenterX0 = 3

93 CenterY0 = PictureMap.Height - 1702

94 'Initialisation of the Counter used for drawing

95 ' the Wind Vector and the Solar

96 CountW = 1

98 'Initialisation of the Value used to display

99 'the position and the direction in the large view

100 CLK_M = False

101 CLK_D = False

102 'Open the file (Send_file) that the user used it to put the Telegram (Message) that he will 103 send to the ALTERNATIVE-Lotte

104 Open "C:\User Interface\Data\Send_file.snd" For Binary Access Write As #2

105 SI = 0

106 ' Open the file (Receive_file) that the user used it to put the Telegram (Message) that he 107 will recevie from the ALTERNATIVE-Lotte

108 Open "C:\User Interface\Data\Receive_file.rcv" For Binary Access Write As #1

109 RI = 0

110 'Open the file (Solar_File) that the user used it to put the value of the Solar Radiation

111 Open "C:\User Interface\Data\Solar_file.rad" For Binary Access Write As #3

112 SRI = 0

113 'Set the drive an path for the JPG or BMP image and the Mouse icon

114 ChDrive Left$(App.Path, 2)

115 ChDir App.Path

116 'The shape control for the ZoomBox or frame is loaded dynamically

117 'at runtime

118 Controls.Add "vb.shape", "shpZoomBox", PictureMap

119 Set Target = FormMap.PictureMap_Z

120 Target.Width = FormMap.PictureMap_Z.Width

121 Target.Height = FormMap.PictureMap_Z.Height

122 'Disable the SDF (Send_Data_Frame)

123 SDF.Visible = False

124 'Disable the Solar Radiation Command

125 C_Solar_Radiation.Enabled = False

126 'Test the Status of the serial Port

127 If (Status_Port(MSComm1, 3) = False) Then

128 MsgBox "SORRY!!!, This port is not Available (used by another application)"

129 End

130 Else

131 ' Initialisation of the serial port

132 MSComm1.CommPort = 3

133 MSComm1.Settings = "9600,E,8,2"

134 MSComm1.Handshaking = comRTSXOnXOff

135 MSComm1.RTSEnable = True

136 MSComm1.InputMode = comInputModeText

137 MSComm1.InputLen = 116

138 MSComm1.PortOpen = True

139 'Initialisation of the value of the Recevie_Message

140 RMessage.DataIn_AX = "0"

141 RMessage.DataIn_AY = "0"

142 RMessage.DataIn_AZ = "0"

143 RMessage.DataIn_AVX = "0"

144 RMessage.DataIn_AVY = "0"

145 RMessage.DataIn_AVZ = "0"

146 RMessage.DataIn_Azt = "0"

147 RMessage.DataIn_WX = "0"

148 RMessage.DataIn_WY = "0"

149 RMessage.DataIn_WZ = "0"

150 RMessage.DataIn_SX = "0"

151 RMessage.DataIn_SY = "0"

152 RMessage.DataIn_SZ = "0"

153 RMessage.DataIn_Temp = "0"

154 'Set the Interval of the timer

155 TimerRun_R.Interval = 500

156 'Enable the Timer used for Reading Data

157 TimerRun_R.Enabled = True

158 End If

159 End Sub

160 Private Sub PictureDir_Click()

161 'Enable the From_Direction

162 FormDirection.Visible = True

163 'Disable the SDF (Sending_Data_Frame)

164 SDF.Visible = False

165 FormDirection.SetFocus

166 'Close the FormMap

167 Unload FormMap

168 CLK_D = True

169 If (Azimuts < 0) Then

170 YD_Z = 1900 - (1650 * Cos((Azimuts * PI) / 180))

171 XD_Z = 2450 + (1650 * Sin((Azimuts * PI) / 180))

172 FormDirection.PictureDir_Z.Line (2450, 1900)-(XD_Z, YD_Z), RGB(255, 0, 0)

173 Else

174 YD_Z = 1900 - (1650 * Cos((Azimuts * PI) / 180))

175 XD_Z = 2480 + (1650 * Sin((Azimuts * PI) / 180))

176 FormDirection.PictureDir_Z.Line (2480, 1900)-(XD_Z, YD_Z), RGB(255, 0, 0)

177 End If

178 End Sub

Private Sub PictureMap_MouseDown(Button As Integer, Shift As Integer, X As

Single, Y As Single)

180 'Get the Position of the Mouse_Down

181 X1 = X

182 Y1 = Y

183 'Get the position of the MouseDown.It is mean get

184 'the X and Y when the User press the MouseDown

185 Controls("shpZoomBox").Left = X1

186 Controls("shpZoomBox").Top = Y1

187 Controls("shpZoomBox").Width = 0

188 Controls("shpZoomBox").Height = 0

189 Controls("shpZoomBox").BorderStyle = 3

190 Controls("shpZoomBox").Visible = True

191 End Sub

Private Sub PictureMap_MouseMove(Button As Integer, Shift As Integer, X As

Single, Y As Single)

193 'Call the function used to do a Zoom

194 ZoomBoxArea X1, X, Y1, Y

195 If Controls("shpZoomBox").Visible = True Then

196 'Change the Mouse Icon

197 PictureMap.MousePointer = vbCustom

198 PictureMap.MouseIcon = LoadPicture("cursor20.ico")

199 Controls("shpZoomBox").Width = minX(X1, X)

200 Controls("shpZoomBox").Height = minY(Y1, Y)

201 End If

202 End Sub

Private Sub PictureMap_MouseUp(Button As Integer, Shift As Integer, X As Single,

Y As Single)

204 'Enable the FormMap

205 FormMap.Visible = True

206 FormMap.SetFocus

207 'Close the FormDirection

208 Unload FormDirection

209 FormMap.C_ZoomMap.Visible = True

210 CLK_M = True

211 Controls("shpZoomBox").Visible = False

212 PictureMap.MousePointer = vbArrow

213 'Get the position of the Mouse_Up

214 X2 = X

215 Y2 = Y

216 ZoomBoxArea X1, X2, Y1, Y2

217 'The StretchBlt API function copies a bitmap from a source

218 'rectangle into a destination rectangle.

219 r1 = StretchBlt(Target.hdc, 0, 0, Target.Width, Target.Height, PictureMap.hdc, ULeftX, 220 ULeftY, minX(X1, X2), minY(Y1, Y2), SRCCOPY)

221 ' show the updated image

222 Target.Refresh ' show the updated image

223 'Disable the SDF (Sending_Data_Frame)

224 SDF.Visible = False

225 End Sub

226 Private Sub T_newvel_inX_KeyPress(KeyAscii As Integer)

227 'Testing the status of the TextBoxes, so if it is not clear, jump to the other

228 If (T_newVel_inX.Text <> "" And KeyAscii = 13) Then

229 T_newVel_inY.SetFocus

230 ElseIf (KeyAscii = 27) Then

231 T_newPos_inZ.SetFocus

232 T_newVel_inX.Text = ""

233 ElseIf (T_newVel_inX.Text = "") Then

234 T_newVel_inX.SetFocus

235 End If

236 End Sub

237 Private Sub T_newvel_inY_KeyPress(KeyAscii As Integer)

238 'Testing the status of the TextBoxes, so if it is not clear, jump to the other

239 If (T_newVel_inY.Text <> "" And KeyAscii = 13) Then

240 T_newVel_inZ.SetFocus

241 ElseIf (KeyAscii = 27) Then

242 T_newVel_inX.SetFocus

243 T_newVel_inY.Text = ""

244 ElseIf (T_newVel_inY.Text = "") Then

245 T_newVel_inY.SetFocus

246 End If

247 End Sub

248 Private Sub T_newvel_inZ_KeyPress(KeyAscii As Integer)

249 'Testing the status of the TextBoxes, so if it is not clear, jump to the other

250 If (T_newVel_inZ.Text <> "" And KeyAscii = 13) Then

251 C_Send_OK.SetFocus

252 ElseIf (KeyAscii = 27) Then

253 T_newVel_inY.SetFocus

254 T_newVel_inZ.Text = ""

255 ElseIf (T_newVel_inZ.Text = "") Then

256 T_newVel_inZ.SetFocus

257 End If

258 End Sub

259 Private Sub T_newPos_inX_KeyPress(KeyAscii As Integer)

260 'Testing the status of the TextBoxes, so if it is not clear, jump to the other

261 If (T_newPos_inX.Text <> "" And KeyAscii = 13) Then

262 T_newPos_inY.SetFocus

263 ElseIf (T_newPos_inX = "") Then

264 T_newPos_inX.SetFocus

265 End If

266 End Sub

267 Private Sub T_newPos_inY_KeyPress(KeyAscii As Integer)

268 'Testing the status of the TextBoxes, so if it is not clear, jump to the other

269 If (T_newPos_inY.Text <> "" And KeyAscii = 13) Then

270 T_newPos_inZ.SetFocus

271 ElseIf (KeyAscii = 27) Then

272 T_newPos_inX.SetFocus

273 T_newPos_inY.Text = ""

274 ElseIf (T_newPos_inY.Text = "") Then

275 T_newPos_inY.SetFocus

276 End If

277 End Sub

278 Private Sub T_newPos_inZ_KeyPress(KeyAscii As Integer)

279 'Testing the status of the TextBoxes, so if it is not clear, jump to the other

280 If (T_newPos_inZ.Text <> "" And KeyAscii = 13) Then

281 T_newVel_inX.SetFocus

282 ElseIf (KeyAscii = 27) Then

283 T_newPos_inY.SetFocus

284 T_newPos_inZ.Text = ""

285 ElseIf (T_newPos_inZ.Text = "") Then

286 T_newPos_inZ.SetFocus

287 End If

288 End Sub

289 Private Sub TimerRun_R_Timer()

290 'Wait for Data (Sensors Data) to come to the Serial Port

291 '116 is the length of the Receive_Message

292 Do

293 DoEvents

294 'Enable The Solar Radiation Command

295 'because when the program stop here

296 'It is mean that the travel of the

297 'ALTERNATIVE-Lotte is finished

298 C_Solar_Radiation.Enabled = True

299 Loop Until MSComm1.InBufferCount >= 116

300 'Disable the Solar Radiation Command

301 'because when the program continue

302 'It is mean that the ALTERNATIVE-Lotte

303 'continue its tavel

304 C_Solar_Radiation.Enabled = False

305 'Call the function used to Read Data

306 Read_Data

307 End Sub

308 'these 3 functions minX, minY and ZoomBoxArea are used

309 'to do a Zoom on the position of the ALTERNATIVE - Lotte

310 Public Function minX(X1, X2)

311 If X1 < X2 Then

312 minX = X2 - X1

313 Controls("shpZoomBox").Left = X1

314 Else

315 minX = X1 - X2

316 Controls("shpZoomBox").Left = X1 - minX

317 End If

318 End Function

319 Public Function minY(Y1, Y2)

320 If Y1 < Y2 Then

321 minY = Y2 - Y1

322 Controls("shpZoomBox").Top = Y1

323 Else

324 minY = Y1 - Y2

325 Controls("shpZoomBox").Top = Y1 - minY

326 End If

327 End Function

328 Public Sub ZoomBoxArea(X1, X2, Y1, Y2)

329 If X1 < X2 And Y1 > Y2 Then

330 ULeftX = X1

331 ULeftY = Y2

332 ElseIf X1 > X2 And Y1 > Y2 Then

333 ULeftX = X2

334 ULeftY = Y2

335 ElseIf X1 > X2 And Y1 < Y2 Then

336 ULeftX = X2

337 ULeftY = Y1

338 Else

339 ULeftX = X1

340 ULeftY = Y1

341 End If

342 End Sub

Visual Basic code for the library (Library_RW) used in the user interface program

343 Public Const PI = 3.141592

344 'Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)

345 'these two functions are used to do a Zoom for a picture

346 Public Declare Function BitBlt Lib "gdi32" (ByVal hDestDC As Long, ByVal X As

347 Long, ByVal Y As Long, ByVal nWidth As Long, ByVal nHeight As Long, ByVal

hSrcDC As Long, ByVal xSrc As Long, ByVal ySrc As Long, ByVal dwRop As

349 Long) As Long

350 Public Declare Function StretchBlt Lib "gdi32" (ByVal hdc As Long, ByVal X As Long, 351 ByVal Y As Long, ByVal nWidth As Long, ByVal nHeight As Long, ByVal hSrcDC As 352 Long, ByVal xSrc As Long, ByVal ySrc As Long, ByVal nSrcWidth As Long, ByVal 353 nSrcHeight As Long, ByVal dwRop As Long) As Long

354 Public Const SRCAND = &H8800C6 ' (DWORD) dest = source AND dest

355 Public Const SRCCOPY = &HCC0020 ' (DWORD) dest = source

355 Public Const SRCERASE = &H440328 ' (DWORD) dest = source AND (NOT dest)

356 Public Const SRCINVERT = &H660046 ' (DWORD) dest = source XOR dest

357 Public Const SRCPAINT = &HEE0086 ' (DWORD) dest = source OR dest

358 'Structure of the Receive_Message

359 Public Type Struct_RMessage

360 Begin_RFlag As String ' The really type is Byte

361 Length_RMessage As String ' The really type is Interger

362 DataIn_AX As String ' The really type is Single

363 DataIn_AY As String ' The really type is Single

364 DataIn_AZ As String ' The really type is Single

365 DataIn_AVX As String ' The really type is Single

366 DataIn_AVY As String ' The really type is Single

367 DataIn_AVZ As String ' The really type is Single

368 DataIn_Azt As String ' The really type is Single

369 DataIn_WX As String ' The really type is Single

370 DataIn_WY As String ' The really type is Single

371 DataIn_WZ As String ' The really type is Single

372 DataIn_SX As String ' The really type is Single

373 DataIn_SY As String ' The really type is Single

374 DataIn_SZ As String ' The really type is Single

375 DataIn_Temp As String ' The really type is Single

376 End_RFlag As String ' The really type is Byte

377 End Type

378 Public RMessage As Struct_RMessage

379 'String (Variable) used for Read Data from Serial Port

380 Public Receive_Message As String

381 'Structure of the Send_Message

382 Public Type Struct_SMessage

383 Begin_SFlag As String ' The really type is Byte

384 Length_SMessage As String ' The really type is Interger

385 DataOut_PX As String ' The really type is Single

386 DataOut_PY As String ' The really type is Single

387 DataOut_PZ As String ' The really type is Single

388 DataOut_VelX As String ' The really type is Single

389 DataOut_VelY As String ' The really type is Single

390 DataOut_VelZ As String ' The really type is Single

391 End_SFlag As String ' The really type is Byte

392 End Type

393 Public SMessage As Struct_SMessage

394 'String (Variable) used for Send Data to Serial Port

395 Public Send_Message As String

396 'Parameters used to save the Old Data

397 Public Acc_inX As Single

398 Public Acc_inY As Single

399 Public Acc_inZ As Single

400 Public Ang_vel_inX As Single

401 Public Ang_vel_inY As Single

402 Public Ang_vel_inZ As Single

403 Public Azimuts As Single

404 Public Wind_inX As Single

405 Public Wind_inY As Single

406 Public Wind_inZ As Single

407 Public Solar_inX As Single

408 Public Solar_inY As Single

409 Public Solar_inZ As Single

410 Public Temp As Single

411 'Parameters used to get the Velocity and the Position

412 Public Vel_inX As Single

413 Public Vel_inY As Single

414 Public Vel_inZ As Single

415 Public Pos_inX As Single

416 Public Pos_inY As Single

417 Public Pos_inZ As Single

418 ' Parameters used for drawing the Position

419 ' of the ALTERNATIVE-Lotte on the MAP

420 Public CenterX As Single

421 Public CenterY As Single

422 Public CenterX0 As Single

423 Public CenterY0 As Single

424 Public CLK_M As Boolean

425 ' Parameters used for drawing the Direction

426 ' of the ALTERNATIVE-Lotte

427 Public XD As Single

428 Public YD As Single

429 Public XD_Z As Single

430 Public YD_Z As Single

431 Public CLK_D As Boolean

432 'Parameters used to put the Wind Vector

432 Public RW As Single 'Wind Power

433 Public CountW As Integer

434 'Parameters used to put the Solar Radiation

435 Public RS As Single 'Solar Radiation

436 'Paramters used to put the Telegram in the file

437 Public RI As Integer

438 Public SI As Integer

439 Public SRI As Integer

440 Public Function Read_Data() As Boolean

441 ' Read the Contain of the Receive Buffer

442 Receive_Message = UserInterface.MSComm1.Input

443 If (Read_Data) Then

444 'Save the old position

445 Acc_inX = Val(RMessage.DataIn_AX)

446 Acc_inY = Val(RMessage.DataIn_AY)

447 Acc_inZ = Val(RMessage.DataIn_AZ)

448 Ang_vel_inX = Val(RMessage.DataIn_AVX)

449 Ang_vel_inY = Val(RMessage.DataIn_AVY)

450 Ang_vel_inZ = Val(RMessage.DataIn_AVZ)

451 Azimuts = Val(RMessage.DataIn_Azt)

452 Wind_inX = Val(RMessage.DataIn_WX)

453 Wind_inY = Val(RMessage.DataIn_WY)

454 Wind_inZ = Val(RMessage.DataIn_WZ)

455 Solar_inX = Val(RMessage.DataIn_SX)

456 Solar_inY = Val(RMessage.DataIn_SY)

457 Solar_inZ = Val(RMessage.DataIn_SZ)

458 Temp = Val(RMessage.DataIn_Temp)

459 End If

460 ' Call the function used to convert from Hex Format to Decimal Format

461 UserInterface.SC1.Reset

462 UserInterface.SC1.AddCode UserInterface.txtCodeHex2Dec.Text

463 RMessage.Begin_RFlag = Val("&H" & Left(Receive_Message, 1))

464 RMessage.Length_RMessage = Val("&H" & Mid(Receive_Message, 2, 2))

465 RMessage.DataIn_AX = UserInterface.SC1.Run("compute", Mid(Receive_Message, 4, 8))

466 RMessage.DataIn_AY = UserInterface.SC1.Run("compute", Mid(Receive_Message, 12, 8))

467 RMessage.DataIn_AZ = UserInterface.SC1.Run("compute", Mid(Receive_Message, 20, 8))

468 RMessage.DataIn_AVX = UserInterface.SC1.Run("compute", Mid(Receive_Message, 28, 8))

469 RMessage.DataIn_AVY = UserInterface.SC1.Run("compute", Mid(Receive_Message, 36, 8))

470 RMessage.DataIn_AVZ = UserInterface.SC1.Run("compute", Mid(Receive_Message, 44, 8))

471 RMessage.DataIn_Azt = UserInterface.SC1.Run("compute", Mid(Receive_Message, 52, 8))

472 RMessage.DataIn_WX = UserInterface.SC1.Run("compute", Mid(Receive_Message, 60, 8))

473 RMessage.DataIn_WY = UserInterface.SC1.Run("compute", Mid(Receive_Message, 68, 8))

474 RMessage.DataIn_WZ = UserInterface.SC1.Run("compute", Mid(Receive_Message, 76, 8))

475 RMessage.DataIn_SX = UserInterface.SC1.Run("compute", Mid(Receive_Message, 84, 8))

476 RMessage.DataIn_SY = UserInterface.SC1.Run("compute", Mid(Receive_Message, 92, 8))

477 RMessage.DataIn_SZ = UserInterface.SC1.Run("compute", Mid(Receive_Message, 100, 8))

478 RMessage.DataIn_Temp = UserInterface.SC1.Run("compute", Mid(Receive_Message, 108, 8))

479 RMessage.End_RFlag = Val("&H" & Right(Receive_Message, 1))

480 ' Testing the Begin_Flag and the End_Flag for each Receive_Message

481 If (RMessage.Begin_RFlag <> 2 Or RMessage.End_RFlag <> 3) Then

482 ' In this section the Begin_Flag or the End_Flag is NOT Correct

483 Read_Data = False

484 ' Display the Old Data

485 UserInterface.L_Acc_inX.Caption = Acc_inX

486 UserInterface.L_Acc_inY.Caption = Acc_inY

487 UserInterface.L_Acc_inZ.Caption = Acc_inZ

489 UserInterface.L_Ang_inX.Caption = Ang_vel_inX

490 UserInterface.L_Ang_inY.Caption = Ang_vel_inY

491 UserInterface.L_Ang_inZ.Caption = Ang_vel_inZ

492 UserInterface.L_Wind_inX.Caption = Wind_inX

493 UserInterface.L_Wind_inY.Caption = Wind_inY

494 UserInterface.L_Wind_inZ.Caption = Wind_inZ

495 UserInterface.L_Solar_inX.Caption = Solar_inX

496 UserInterface.L_Solar_inY.Caption = Solar_inY

497 UserInterface.L_Solar_inZ.Caption = Solar_inZ

498 UserInterface.L_Temp.Caption = Temp

499 UserInterface.L_Vel_inX.Caption = Vel_inX

500 UserInterface.L_Vel_inY.Caption = Vel_inY

501 UserInterface.L_Vel_inZ.Caption = Vel_inZ

501 UserInterface.L_Pos_inX.Caption = Pos_inX

502 UserInterface.L_Pos_inY.Caption = Pos_inY

503 UserInterface.L_Pos_inZ.Caption = Pos_inZ

503 'display the status of the connection to the user

504 UserInterface.L_Connection.Caption = " TAKE CARE !!!! , there is NO connection 505 between the Base Station and the ALTERNATIVE-Lotte"

506 UserInterface.Pic_statusOK.Visible = True

507 UserInterface.Pic_statusNO.Visible = False

508 Else

509 ' In this Section the Begin_Flag and the End_Flag are Correct

510 Read_Data = True

511 UserInterface.Text1.Text = Val(UserInterface.Text1.Text) + 1

512 ' Display the sensors data in the RDF (Receive_Data_Frame)

513 UserInterface.L_Acc_inX.Caption = Left(RMessage.DataIn_AX, 8)

514 UserInterface.L_Acc_inY.Caption = Left(RMessage.DataIn_AY, 8)

515 UserInterface.L_Acc_inZ.Caption = Left(RMessage.DataIn_AZ, 8)

516 UserInterface.L_Ang_inX.Caption = Left(RMessage.DataIn_AVX, 8)

517 UserInterface.L_Ang_inY.Caption = Left(RMessage.DataIn_AVY, 8)

518 UserInterface.L_Ang_inZ.Caption = Left(RMessage.DataIn_AVZ, 8)

519 UserInterface.L_Wind_inX.Caption = Left(RMessage.DataIn_WX, 8)

520 UserInterface.L_Wind_inY.Caption = Left(RMessage.DataIn_WY, 8)

521 UserInterface.L_Wind_inZ.Caption = Left(RMessage.DataIn_WZ, 8)

522 UserInterface.L_Solar_inX.Caption = Left(RMessage.DataIn_SX, 8)

523 UserInterface.L_Solar_inY.Caption = Left(RMessage.DataIn_SY, 8)

524 UserInterface.L_Solar_inZ.Caption = Left(RMessage.DataIn_SZ, 8)

525 UserInterface.L_Temp.Caption = Left(RMessage.DataIn_Temp, 8)

526 'Save the Data

527 Acc_inX = Left(RMessage.DataIn_AX, 8)

528 Acc_inY = Left(RMessage.DataIn_AY, 8)

529 Acc_inZ = Left(RMessage.DataIn_AZ, 8)

530 Ang_vel_inX = Left(RMessage.DataIn_AVX, 8)

531 Ang_vel_inY = Left(RMessage.DataIn_AVY, 8)

532 Ang_vel_inZ = Left(RMessage.DataIn_AVZ, 8)

533 Azimuts = Left(RMessage.DataIn_Azt, 8)

534 Wind_inX = Left(RMessage.DataIn_WX, 8)

535 Wind_inY = Left(RMessage.DataIn_WY, 8)

536 Wind_inZ = Left(RMessage.DataIn_WZ, 8)

537 Solar_inX = Left(RMessage.DataIn_SX, 8)

538 Solar_inY = Left(RMessage.DataIn_SY, 8)

539 Solar_inZ = Left(RMessage.DataIn_SZ, 8)

540 Temp = Left(RMessage.DataIn_Temp, 8)

541 'Put the Sensors_Data in the Recevie_File

542 'Put #1, (1 + 60 * RI), Begin_RFlag

543 'Put #1, (2 + 60 * RI), Length_RMessage

544 Put #1, (4 + 60 * RI), Acc_inX

545 Put #1, (8 + 60 * RI), Acc_inY

546 Put #1, (12 + 60 * RI), Acc_inZ

547 Put #1, (16 + 60 * RI), Ang_vel_inX

548 Put #1, (20 + 60 * RI), Ang_vel_inY

549 Put #1, (24 + 60 * RI), Ang_vel_inZ

550 Put #1, (28 + 60 * RI), Azimuts

551 Put #1, (32 + 60 * RI), Wind_inX

552 Put #1, (36 + 60 * RI), Wind_inY

553 Put #1, (40 + 60 * RI), Wind_inZ

554 Put #1, (44 + 60 * RI), Solar_inX

555 Put #1, (48 + 60 * RI), Solar_inY

556 Put #1, (52 + 60 * RI), Solar_inZ

557 Put #1, (56 + 60 * RI), Temp

558 'Put #1, (60 + 60 * RI), End_RFlag

559 RI = RI + 1

560 'Call the function used to Calculate the Velocity of the ALTERNATIVE-Lotte

Calculate_Velocity

561 'Call the function used to Calculate the Position of the ALTERNATIVE-Lotte

Calculate_Position

562 'Get the position of the Center of the Circle

563 'used to put the position of the ALTERNATIVE-Lotte

564 CenterX = CenterX0 + CSng(UserInterface.L_Pos_inX.Caption)

565 CenterY = CenterY0 - CSng(UserInterface.L_Pos_inY.Caption)

566 'Put the Position on the MAP

567 UserInterface.PictureMap.PSet (CenterX, CenterY), RGB(255, 0, 0)

568 'Clear he old direction of the ALTERNATIVE-Lotte

569 UserInterface.PictureDir.Cls

570 FormDirection.PictureDir_Z.Cls

571 'Put the Direction in the PictureDir

572 If (Azimuts < 0) Then

573 YD = 850 - (700 * Cos((Azimuts * PI) / 180))

574 XD = 920 + (700 * Sin((Azimuts * PI) / 180))

575 UserInterface.PictureDir.Line (920, 850)-(XD, YD), RGB(255, 0, 0)

576 Else

577 YD = 850 - (700 * Cos((Azimuts * PI) / 180))

578 XD = 960 + (700 * Sin((Azimuts * PI) / 180))

579 UserInterface.PictureDir.Line (960, 850)-(XD, YD), RGB(255, 0, 0)

580 End If

581 'Testing if the user click in the pictureDirection (ZOOM)

582 If (CLK_D) Then

583 'Put the Direction on the PictureDirection in large View (ZOOM)

584 If (Azimuts < 0) Then

585 YD_Z = 1900 - (1650 * Cos((Azimuts * PI) / 180))

586 XD_Z = 2450 + (1650 * Sin((Azimuts * PI) / 180))

587 FormDirection.PictureDir_Z.Line (2450, 1900)-(XD_Z, YD_Z), RGB(255, 0, 0)

588 Else

589 YD_Z = 1900 - (1650 * Cos((Azimuts * PI) / 180))

590 XD_Z = 2480 + (1650 * Sin((Azimuts * PI) / 180))

591 FormDirection.PictureDir_Z.Line (2480, 1900)-(XD_Z, YD_Z), RGB(255, 0, 0)

592 End If

593 End If

594 'Put the Wind Vector (Wind Power) in the PictureWind

RW = (Val(UserInterface.L_Wind_inX.Caption) ^ 2 +

Val(UserInterface.L_Wind_inY.Caption) ^ 2 +

Val(UserInterface.L_Wind_inZ.Caption) ^ 2) ^ (1 / 2)

UserInterface.PictureWind.PSet (CountW, UserInterface.PictureWind.Height - 1365

– (RW / 13)), RGB(255, 0, 0)

597 'Put the Solar Vector (Solar Radiation) in the PictureSolar

RS = (Val(UserInterface.L_Solar_inX.Caption) ^ 2 +

Val(UserInterface.L_Solar_inY.Caption) ^ 2 +

Val(UserInterface.L_Solar_inZ.Caption) ^ 2) ^ (1 / 2)

UserInterface.PictureSolar.PSet (CountW, UserInterface.PictureSolar.Height - 1365

– (RS / 13)), RGB(255, 0, 0)

599 CountW = CountW + 2

600 'Put the Solar Radiation Data in the Solar_file

601 Put #3, (1 + 17 * SRI), Pos_inX

602 Put #3, (5 + 17 * SRI), Pos_inY

603 Put #3, (9 + 17 * SRI), Pos_inZ

604 Put #3, (13 + 17 * SRI), RS

605 SRI = SRI + 1

606 'Display the Status of the Connection to the User

607 UserInterface.L_Connection.Caption = "There is a connection between the Base Station 608 and the ALTERNATIVE-Lotte"

609 UserInterface.Pic_statusNO.Visible = True

610 UserInterface.Pic_statusOK.Visible = False

611 End If

612 'After reading the receive message, we clean the receive buffer

613 UserInterface.MSComm1.InBufferCount = 0

614 End Function

615 Public Function Write_Commands() As Boolean

616 ' Call the function used to convert from Decimal format to Hex format

617 UserInterface.SC1.Reset

618 UserInterface.SC1.AddCode UserInterface.txtCodeDec2Hex.Text

619 'configure the Send Message

620 SMessage.Begin_SFlag = Hex$(2)

621 SMessage.Length_SMessage = Hex$(28)

622 If (Val(UserInterface.T_newPos_inX.Text) =

CInt(Val(UserInterface.T_newPos_inX.Text))) Then

623 UserInterface.T_newPos_inX.Text = (UserInterface.T_newPos_inX.Text & ".000001")

SMessage.DataOut_PX = UserInterface.SC1.Run("compute", UserInterface.T_newPos_inX.Text)

625 Else

626 SMessage.DataOut_PX = UserInterface.SC1.Run("compute",

UserInterface.T_newPos_inX.Text)

627 End If

628 If (Val(UserInterface.T_newPos_inY.Text) =

CInt(Val(UserInterface.T_newPos_inY.Text))) Then

628 UserInterface.T_newPos_inY.Text = UserInterface.T_newPos_inY.Text & ".000001"

SMessage.DataOut_PY = UserInterface.SC1.Run("compute",

(UserInterface.T_newPos_inY.Text))

630 Else

631 SMessage.DataOut_PY = UserInterface.SC1.Run("compute",

(UserInterface.T_newPos_inY.Text))

632 End If

633 If (Val(UserInterface.T_newPos_inZ.Text) =

CInt(Val(UserInterface.T_newPos_inZ.Text))) Then

634 UserInterface.T_newPos_inZ.Text = UserInterface.T_newPos_inZ & ".000001"

SMessage.DataOut_PZ = UserInterface.SC1.Run("compute",

(UserInterface.T_newPos_inZ.Text))

637 Else

SMessage.DataOut_PZ = UserInterface.SC1.Run("compute",

(UserInterface.T_newPos_inZ.Text))

639 End If

640 If (Val(UserInterface.T_newVel_inX.Text) =

CInt(Val(UserInterface.T_newVel_inX.Text))) Then

641 UserInterface.T_newVel_inX.Text = UserInterface.T_newVel_inX.Text & ".000001"

SMessage.DataOut_VelX = UserInterface.SC1.Run("compute",

(UserInterface.T_newVel_inX.Text))

643 Else

644 SMessage.DataOut_VelX = UserInterface.SC1.Run("compute",

(UserInterface.T_newVel_inX.Text))

645 End If

645 If (Val(UserInterface.T_newVel_inY.Text) =

CInt(Val(UserInterface.T_newVel_inY.Text))) Then

646 UserInterface.T_newVel_inY.Text = UserInterface.T_newVel_inY.Text & ".000001"

SMessage.DataOut_VelY = UserInterface.SC1.Run("compute",

(UserInterface.T_newVel_inY.Text))

648 Else

649 SMessage.DataOut_VelY = UserInterface.SC1.Run("compute",

(UserInterface.T_newVel_inY.Text))

650 End If

If (Val(UserInterface.T_newVel_inZ.Text) =

CInt(Val(UserInterface.T_newVel_inZ.Text))) Then

652 UserInterface.T_newVel_inZ.Text = UserInterface.T_newVel_inZ.Text & ".000001"

653 SMessage.DataOut_VelZ = UserInterface.SC1.Run("compute",

(UserInterface.T_newVel_inZ.Text))

654 Else

SMessage.DataOut_VelZ = UserInterface.SC1.Run("compute",

(UserInterface.T_newVel_inZ.Text))

656 End If

657 SMessage.End_SFlag = Hex$(3)

658 'Put the Data (Commands) in the Send_Message

659 Send_Message = SMessage.Begin_SFlag & SMessage.Length_SMessage & _

SMessage.DataOut_PX & SMessage.DataOut_PY & _

SMessage.DataOut_PZ & SMessage.DataOut_VelX & _

SMessage.DataOut_VelY & SMessage.DataOut_VelZ & _

SMessage.End_SFlag

660 'Put the Telegram (Send_Message) in the Send_File

661 Put #2, (1 + 60 * SI), Send_Message

662 SI = SI + 1

663 'send the Message to the Transmit Buffer

664 UserInterface.MSComm1.Output = Send_Message

665 'Set the Status of the Write_Commands function

665 Write_Commands = True

666 End Function

667 ' the Goal of this function is to calculate the Velocity

668 ' of the ALTERNATIVE - Lotte in X, Y and Z

‘ The Velocity is the Integration of the Acceleration

670 Public Function Calculate_Velocity() As Boolean

671 Vel_inX = (RMessage.DataIn_AX) * (UserInterface.TimerRun_R.Interval / 1000)

672 Vel_inY = (RMessage.DataIn_AY) * (UserInterface.TimerRun_R.Interval / 1000)

673 Vel_inZ = (RMessage.DataIn_AZ) * (UserInterface.TimerRun_R.Interval / 1000)

674 UserInterface.L_Vel_inX.Caption = Vel_inX

675 UserInterface.L_Vel_inY.Caption = Vel_inY

676 UserInterface.L_Vel_inZ.Caption = Vel_inZ

677 Calculate_Velocity = True

678 End Function

679 ' the Goal of this function is to calculate the Positon

680 ' of the ALTERNATIVE - Lotte in X, Y and Z

681 ' The Position is the Integration of the Velocity

682 Public Function Calculate_Position() As Boolean

683 Pos_inX = Vel_inX * (UserInterface.TimerRun_R.Interval / 1000)

684 Pos_inY = Vel_inY * (UserInterface.TimerRun_R.Interval / 1000)

685 Pos_inZ = Vel_inZ * (UserInterface.TimerRun_R.Interval / 1000)

686 UserInterface.L_Pos_inX.Caption = Pos_inX

687 UserInterface.L_Pos_inY.Caption = Pos_inY

688 UserInterface.L_Pos_inZ.Caption = Pos_inZ

689 Calculate_Position = True

690 End Function

691 Public Function Status_Port(cComm As MSComm, lPort As Long) As Boolean

692 'This function Test the Status of the Serial Port

693 'NOTE : Do not try to send/receive data while executing this function...!

694 Dim oldState As Boolean

695 Dim oldPort As Long

696 ' Get current MSComm Info

697 oldState = cComm.PortOpen

698 oldPort = cComm.CommPort

699 ' Change Info

700 On Error Resume Next

701 cComm.PortOpen = False

702 cComm.CommPort = lPort

703 ' See if Port is Available

704 Err.Clear

705 cComm.PortOpen = True

706 If Err Then

707 Status_Port = False

708 Debug.Print Err.Description

709 Else

710 Status_Port = True

711 End If

712 cComm.PortOpen = False

713 ' Set Info Back To Old Data

714 cComm.CommPort = oldPort

715 cComm.PortOpen = oldState

716 On Error GoTo 0

717 End Function

9.4 Annex F: C program code

/****************************************************************************************************

** Project : Diploma Thesis

** The goal of this program is to initialise the serial port

** and read from one serial port and write to another.......

*****************************************************************************************************/

/*-- Include files ----------------------------------------------------------*/

1 #include <stdio.h> /* Standard input/output definitions */

2 #include <string.h> /* String function definitions */

3 #include <unistd.h> /* UNIX standard function definitions */

4 #include <fcntl.h> /* File Control definition */

5 #include <errno.h> /* Error number definitions */

6 #include "vxWorks.h"

7 #include "ioLib.h"

8 #include <sioLib.h>

/******************************************************************************

** COMM_init

** initialize COM-device

**---- Parameters -------------------------------------------------------------

**---- Returnvalue ------------------------------------------------------------

** int : 0 if success

** int : -1 if error

******************************************************************************/

9 int COMM_init(char *c_device, int *fd)

10 {

11 int id_com_dev; /* filename descriptor for the COM */

12 int speed = 9600; /* speed for COM */

13 int SerialControl;

14 int Parity;

15 int CharacterSize;

16 int ioctlvalue;

/*--------------------------------------------------------------------

** Open the COM-Device

17 id_com_dev = open (c_device, O_RDWR ,0);

18 if ( id_com_dev == ERROR )

19 {

20 perror ("Open_Port : Unable to open /dev/ ---");

21 return(-1);

* Could not open the port

22 }

23 *fd = id_com_dev;

/*------------------------------------------------------------

** setting the BAUD-rate to 9600 ............

24 if (-1 == ioctl (id_com_dev,FIOBAUDRATE , speed))

25 {

26 return(-1);

27 }

/*------------------------------------------------------------

** Setting the Parity, the Stop bit ................

28 SerialControl = (CLOCAL | CREAD);

29 Parity = PARENB ;

30 CharacterSize = CS8;

if (-1 == ioctl (id_com_dev,SIO_HW_OPTS_SET,SerialControl | Parity |

CharacterSize))

32 {

33 return(-1);

34 }

/*------------------------------------------------------------

** Setting the new options of the serial port

** with setting the handshaking protocol

35 ioctlvalue = ioctl (id_com_dev, FIOFLUSH, 0);

ioctlvalue = ioctl (id_com_dev,FIOSETOPTIONS,OPT_TANDEM &~

OPT_MON_TRAP);

38 }

/******************************************************************************

** Main

** main program of RWCOM

**---- Returnvalue ------------------------------------------------------------

** 0

******************************************************************************/

39 int maincomRW(int argc, char *argv[])

40 {

41 char pathserial0[] = "/tyCo/0"; /* Path of the port 2....*/

42 char pathserial1[] = "/tyCo/1"; /* Path of the port 3....*/

43 int ui_byte; /* Number of bytes readed */

44 int uo_byte; /* Number of bytes writed */

45 char *ur_buff; /* Buffer used to get the bytes from the serial port */

46 char *uw_buff; /* Buffer used to set the bytes to the serial port */

47 int fd1; /* file descriptor for the first port */

48 int fd2; /* file descriptor for the second port */

49 int len_mess; /* Length of message */

50 COMM_init(pathserial0, &fd1);

51 COMM_init(pathserial1, &fd2);

52 len_mess = 116;

53 ui_byte = 0;

54 ur_buff = (char*)malloc(116);

55 uw_buff = (char*)malloc(116);

56 while(1)

57 {

58 /* Wait until the all message arrive -------------------*/

59 while (ui_byte < len_mess)

60 {

/*------------------------------------------------------------

** read from the COM-Device

61 ui_byte = read (fd1, ur_buff,len_mess);

62 }

/*---------------------------------------------------------

** Copy the read buffer to the write buffer

63 strcpy(uw_buff,ur_buff);

/*------------------------------------------------------------

** send to the COM-Device

64 uo_byte = write (fd2, uw_buff,len_mess);

65 }

66 close (fd1);

67 close (fd2);

68 return (0);

69 }

9.5 Annex G

/****************************************************************************************************

** Project : Diploma Thesis

** The goal of this program is to initialise the serial port

** and read from one serial port and write to another.......

*****************************************************************************************************/

/*-- Include files ----------------------------------------------------------*/

#include <stdio.h> /* Standard input/output definitions */

#include <string.h> /* String function definitions */

#include <unistd.h> /* UNIX standard function definitions */

#include <fcntl.h> /* File Control definition */

#include <errno.h> /* Error number definitions */

#include "vxWorks.h"

#include "ioLib.h"

#include <sioLib.h>

/******************************************************************************

** COMM_init

** initialize COM-device

**---- Parameters -------------------------------------------------------------

**---- Returnvalue ------------------------------------------------------------

** int : 0 if success

** int : -1 if error

******************************************************************************/

int COMM_init(char *c_device, int *fd)

{

int id_com_dev; /* filename descriptor for the COM */

int speed = 9600; /* speed for COM */

int SerialControl;

int Parity;

int CharacterSize;

int ioctlvalue;

/*--------------------------------------------------------------------

** Open the COM-Device

id_com_dev = open ("/tyCo/1", O_RDWR ,0);

if ( id_com_dev == ERROR )

{

perror ("Open_Port : Unable to open /dev/ ---");

return(-1);

* Could not open the port

}

*fd = id_com_dev;

/*------------------------------------------------------------

** setting the BAUD-rate to 9600 ............

if (-1 == ioctl (id_com_dev,FIOBAUDRATE , speed))

{

return(-1);

}

/*------------------------------------------------------------

** Setting the Parity, the Stop bit ................

SerialControl = (CLOCAL | CREAD);

Parity = PARENB ;

CharacterSize = CS8;

if (-1 == ioctl (id_com_dev,SIO_HW_OPTS_SET,SerialControl | Parity | CharacterSize))

{

return(-1);

}

/*------------------------------------------------------------

** Setting the new options of the serial port

** with setting the handshaking protocol

ioctlvalue = ioctl (id_com_dev, FIOFLUSH, 0);

ioctlvalue = ioctl (id_com_dev,FIOSETOPTIONS,OPT_TANDEM &~

OPT_MON_TRAP);

}

/***************************************************************************

** Main

** main program of RWCOM

**---- Returnvalue ------------------------------------------------------------

** 0

******************************************************************************/

int maincom(int argc, char *argv[])

{

char pathserial0[] = "/tyCo/1"; /* Path of the port 2....*/

int us_byte; /* Number of bytes writed */

int ui_byte; /* Number of bytes read */

char *us_buff0; /* Buffer used to set the bytes to the serial port */

char *us_buff1; /* Buffer used to set the bytes to the serial port */

char *us_buff2; /* Buffer used to set the bytes to the serial port */

char *us_buff3; /* Buffer used to set the bytes to the serial port */

char *us_buff4; /* Buffer used to set the bytes to the serial port */

char *us_buff5; /* Buffer used to set the bytes to the serial port */

char *us_buff6; /* Buffer used to set the bytes to the serial port */

char *us_buff7; /* Buffer used to set the bytes to the serial port */

char *us_buff8; /* Buffer used to set the bytes to the serial port */

char *us_buff9; /* Buffer used to set the bytes to the serial port */

char *ur_buff; /* Buffer used to get the bytes from the serial port */

int fd1; /* file descriptor for the serial port 2 */

int len_mess; /* Length of the send message */

int i;

COMM_init(pathserial0, &fd1);

len_mess = 116;

us_byte = 0;

ur_buff = (char*)malloc(52);

us_buff0 = (char*)malloc(116);

us_buff1 = (char*)malloc(116);

us_buff2 = (char*)malloc(116);

us_buff3 = (char*)malloc(116);

us_buff4 = (char*)malloc(116);

us_buff5 = (char*)malloc(116);

us_buff6 = (char*)malloc(116);

us_buff7 = (char*)malloc(116);

us_buff8 = (char*)malloc(116);

us_buff9 = (char*)malloc(116);

/*-------------------------------------------------------------------

** send to the COM-Device

us_buff0="21C40C6D0E540C3EF9D40C3EF9D416418934282A5E341752F1A414420C4415251EB4179EF9D4189B4394143DB224161C28F4173687241A1B4393";

us_buff1="21C411251EB41126E97411224DD41CA978D4278FDF3427D09374189ED91417522D0418A9BA5419A0C494161A1CA418299994189AE1441CA978D3";

us_buff2="21C4143B22D4143374B4143DB2241C28F5C41819BA542940FDF4200CDD2418A916841999BA541AA68724181B645419268724199ED9141F99BA53";

us_buff3="21C41740000417445A141741062422547AE427547AE41C270A342115D2F41991EB841A9B43941BC20C44194FDF341A2BA5E41A83F7C422168723";

us_buff4="21C4192624D4192687241924BC641A845A142780A3D41C000004234000041AA916841B9ED910000000041A1126E41B41A9F41BB4BC6423548B43";

us_buff5="21C41AA937441AB020C41AABC6A41C5000042AAA5E34282A5E34279418941B8E35341C8000041D9B43941B0D2F141C0EB8541CA978D48B43";

us_buff6="21C41C3020C41C3374B41C32F1A423548B44282A5E342513439425948B441CA687241DBE35341E8168741C2916841D19BA541D9D9164280A3D73";

us_buff7="21C41DB49BA41DBB85141DB3D7041D9B64541EA916841F1B8514286A45A41DA916841E99BA541F1B85141D453F741E1AE1441EA68724288A45A3";

us_buff8="21C41F39FBE41F3EF9D41F39DB2424148B44296A6E942BEA5E342A8764541E9F5C241F9A3D74204DC2841E1A3D741F0F5C241FA126E428CA6663";

us_buff9="21C4205F4BC420615814205F6C842614BC6425948B4424C178D42B4000041F9A3D742068312420E916841F2020C4200FBE742051374429007AE3";

/* Wait until the all message arrive -------------------*/

if (ui_byte < len_mess)

{

/*------------------------------------------------------------

** read from the COM-Device

ui_byte = read (fd1, ur_buff,len_mess);

}

us_byte = write (fd1, us_buff0,len_mess);

delayedEval(500);

us_byte = write (fd1, us_buff1,len_mess);

delayedEval(500);

us_byte = write (fd1, us_buff2,len_mess);

delayedEval(500);

us_byte = write (fd1, us_buff3,len_mess);

delayedEval(500);

us_byte = write (fd1, us_buff4,len_mess);

delayedEval(500);

us_byte = write (fd1, us_buff5,len_mess);

delayedEval(500);

us_byte = write (fd1, us_buff6,len_mess);

delayedEval(500);

us_byte = write (fd1, us_buff7,len_mess);

delayedEval(500);

us_byte = write (fd1, us_buff8,len_mess);

delayedEval(500);

us_byte = write (fd1, us_buff9,len_mess);

delayedEval(500);

close (fd1);

return (0);

}

10 Some repairs on the sensor card and first step integration

11 Integration

Based on Mohammed Yassir Mikou, "Integration und Test eines Board-Computers für ein alternatives Luftschiff", Master Thesis (Diplomarbeit)

Supervisors:

Samir Mourad, Verein für alternative Energieforschung

Prof. Dr. –Ing. Habil Albrecht Zur, Fachhochschule Kiel - University of Applied Sciences, Fachbereich Informatik und Elektrotechnik

11.1 Abstract

This work deals with the development of software for controlling an airship, the weather data (solar radiation, temperature and wind) to determine. The aim of this thesis is to integrate control cards, ie To allow communication between the Sensors, Actuators and transceiver card. The integration should be carried out as part of a Linux platform. It has gained acceptance because of the embedded system and the specific processor type, the RedHat distribution.

TABLE OF CONTENTS

List of Figures ........................................................................ 2

LIST OF TABLES .............................................................. 2

1. Introduction to the airship project ..................................... 4

1.1 . The Lotte-project and the "Alternative LOTTE" ............................... 4

1.2 . Development method ............................................................................ 4

1.3 . Activity and REALISIERUNGSANNaeHERUNG ...... 5

1.4 Overview ................................................................................................ 5

2. Basics of Work ........................................................... 6

2.1 The V-model ............................................................................ 6

2.2 . Structured Analysis (SA) /structured design (SD) ............. 8

3. Development environment ..... 10

4. Architectural design, and implementation ..................... 11

4.1 . The implementation of the BASISSTATIONSPROGRAMMS ...................... 14

4.2 . The implementation of the LUFTSCHIFFPROGRAMMS ............................ 15

Section 4.2.1 , the sensors ........................................................................................ 16

4.2.2 . The actuators ........................................................................................... 17

Point 4.2.3 .. The Transceiver ................................................................................................. 18

Point 4.2.4 .. The Board Computer ........................................................................ 20

5. Operating System Installation .............................................. 22

5.1 . Problem ............................................................................... 22

5.2 . ..................................................... 22 implementation of the installation

5.2.1 . . configuration of the core .................................................................. 23

5.2.2 . . Modules creating and installing ......................................................... 38

5.3 . .................................................................. 39 development environment

5.4 . ................................................................................................. 41 Real

5.4.1 . . latency and fluctuation ........................................................................ 42

Item 5.4.2 above . hard and soft real-time conditions .............................................. 43

5.4.3 . . embedded applications ...... 46

5.4.4 . . Installation of Linux-Echtzeit ................................................................ 47

6. Description of PORTZUGRIFFSARTEN .......................... 49

6.1 . Direct Access ............................................................................... 49

6.1.1 , ............................................................................. rights awarded 49

6.1.2 . . Einlesen/Ausgeben ............................................................................... 51

6.2 . ACCESS about GERaeTEDATEIEN ............................................................ 54

6.2.1 ), . Ports Opened and closed .................................................................. 54

Item 6.2.2 , . canonical and non-canonical Input/Output ......................... 56

6.2.3 . . synchronous and asynchronous transfer ............................................ 67

6.3 . THREADPROGRAMMIERBEISPIEL ............................................................ 72

7. ............................................................................... 75 LITERATURREFERENZ

[2] Technical data sheets of Analog Device of http://products.analog.com/products/info.asp?product=ADXL202

[5] The script is available for free on the Internet under http://mc.ict.tuwien.ac.at

Test Description	Result	Large
Roundabout No1	2.4	Volts
Roundabout No2	2.4	Volts
Roundabout No3	2.3	Volts

	Application	Latency/ turnover
Standard BS.	No real time	10 μs – 100 ms
Standard Linux	Soft real time	1 μs
IEEE 1003.1d	Hard real time	10 – 100 μs
Linux Microkernel	Hard real time	1 – 10 μs
RTOS-Kernels	Hard real time	1 – 10 μs

component	description
c_iflag	input flag
BRKINT	Generate SIGINT at break
IGNBRK / IGNPAR	Ignoring break / parity errors
INPCK	Parity check allow
IGNCR	Ignorieren von Carriage Return
ICRNL	Converting CR to NL on input
INLCR	Switching on the parity check when entering
IXON / IXOFF	Flow control, enable software-
PARMARK	Mark parity errors
c_oflag	issuance flag
OPOST	Provide an implementation-defined output type. If this option is disabled, then all other Ignores options in c_oflag.
ONLCR	NL to CR-NL Paare abbilden.
c_cflag	control flag
B0-B115200	Terminal baud rate set.
CLOCAL	Ignore the modem status symbol or terminal only operate locally.
CREAD	Character can be received.
CRTSCTS	Enable hardware flow control
CSIZE	Number of bits per character: CS5-8 for 5 to 8 bits per byte
CSTOP	Use two stop bits. By default, one stop bit.
PARENB	Parity generation for output and Enable parity checking for input.
PARODD	Odd parity enable, otherwise just default.
c_lflag	Local flags
ECHO	Each character you spend on the terminal.
ICANON	The canonical (row-oriented) mode switch.
ISIG	Generate a corresponding signal, whenTerminal control characters are entered (arrived).

Function	descrition
tcgetattr tcsetattr	Check the terminal attributes Set the terminal attributes
cfgetispeed cfgetospeed cfsetispeed cfsetospeed	Call the input speed Check the output speed Set the input speed Set the output rate
tcflush	Empty the input and / or output buffer

y		Azimut, heading, heading (also yaw angle); Axis LPH
Q		Longitudinal Tilt, pitch angle (also pitching); axis K2
F		Hangewinkel, bank angle (also roll angle, slope); Axis XF

5.4.2.2 The initialization of the Event Service

5.5.2 Features of the Event Service (Ereignisdienst)

6.3.1 Measurement Data Collection (Meßdatenaufnahme)

6.3.2 Measurement Data Processing (Meßdatenaufbereitung)

The error behaviour of the acceleration sensor

Definition of the period duration of the accelerometer

6.5.2 Board layout design for the Meßdatenaufnahme (Measurement data collection)

6.7 Test of the overall system with the microcontroller (C167)

7.3 Architecture design of the Aktorik-Ansteuerungseinheit (engl, Actuator Control Unit (ACU)