nollsen.de
 
  
 

Stefan Noll

Daily Activity Monitor

Abschlussbericht für das Karl Steinbuch Stipendium

 

 

Stefan Noll

06.05.2009

 

 


 

Inhalt

Einleitung. 3

Motivation. 3

Konzeptionierung Messverfahren. 4

Beschleunigung. 4

Temperatur. 6

Luftfeuchtigkeit. 6

Pulsoxymetrie. 6

Hardware. 8

USB Schnittstelle. 9

Speicher. 9

Sensor. 10

Stromversorgung. 10

Softwareframework. 10

Firmware. 10

Timer. 13

USB Implementierung. 13

Messprozess. 13

Batteriemessung. 14

Speicherformat. 15

Analysesoftware. 17

Oberfläche. 17

Genereller Programmaufbau. 18

Algorithmen. 19

Verworfene Annahmen. 27

Wizzard Offset Korrektur. 29

Ergebnis. 32

Abbildungsverzeichnis. 33

Quellen. 33

 


 

 

Einleitung

Motivation

Abbildung 1: Konzeptabbildung Daily Activity Monitor

Seit wenigen Jahren gibt es sehr kleine und genaue Beschleunigungssensoren, die immer mehr Anwendungsbereiche finden. Die Spielekonsole Wii ist ein sehr populäres Beispiel, in dem Beschleunigungssensoren Anwendung finden.

In dem Projekt "Daily Activity Monitor" soll gezeigt werden, wie Beschleunigungssensoren auch im medizinischen Bereich sinnvoll eingesetzt werden können. Der Daily Activity Monitor ist ein medizinisches Aufzeichnungsgerät in der Größe einer Zigarettenschachtel. Drei unabhängige Beschleunigungssensoren und ein Temperatur/Feuchtigkeitssensor zeichnen 24h am Tag Messwerte auf und speichern diese in einem Flash Speicher ab. Die Datenübertragung zu einem Host PC erfolgt über eine USB Schnittstelle. Eine Zigbee Schnittstelle soll auch eine drahtlose Übermittlung der Daten ermöglichen.

 

Abbildung 2: Gesamtaufbau Daily Activity Monitor

Konzeptionierung Messverfahren

Beschleunigung

Bevor mit der eigentlichen Entwicklung begonnen wurde, sind einige Vorversuche durchgeführt worden. Da der Hauptbestandteil der Aktivitätsmessung ein Beschleunigungssensor sein soll, wurden zunächst einige Experimente mit Beschleunigungssensoren durchgeführt. 

Zunächst wurden erste Experimente mit einem 2D Beschleunigungssensor durchgeführt. Um erste Beschleunigungen aufzuzeichnen, wurde eine kleine Testschaltung erstellt, die einen 2D Beschleunigungssensorchip ansteuert. Zusätzlich enthielt diese Testplatine eine MMC Karte, um die Daten abzuspeichern, sowie um herauszufinden, wie weit sich eine SD/MMC Karte für das Abspeichernd der Daten eignet. Als Beschleunigungssensor wurde von Analog Devices das Bauteil ADXL322JCP verwendet. Dies ist ein einfacher 2D Beschleunigungssensor mit analogem Ausgang. Es werden Beschleunigungen zwischen -2G und +2G erfasst. Die Analogwerte werden zunächst mit einem Tiefpass gefiltert, um keine Aliasing Effekte zu bekommen. Das Analogsignal wurde dann in einem Mikrocontroller A/D gewandelt und auf einer MMC Karte abgespeichert.

Die Graphik Abbildung 3 zeigt den Aufbau der Schaltung. Das Platinenlayout ist in Abbildung 4 gezeigt

Abbildung 3: Testaufbau zur ersten Beschleunigungsmessung

Abbildung 4: Platinenlayout der ersten Beschleunigungsmessung

Mit dieser Schaltung wurden hilfreiche Erfahrungen gesammelt, wie Beschleunigungsdaten aufgezeichnet werden können. So zeigte sich bei den Messungen, dass die Erdbeschleunigung einen Hauptteil der Beschleunigung ausmacht. Daraus kann man ableiten, dass 2 Achsen für eine sinnvolle Aktivitäts- und Lagebestimmung nicht ausreichen. Um den 1G Erdbeschleunigungsoffset immer korrekt messen zu können, ist ein 3D Beschleunigungssensor notwendig. Zudem hat sich gezeigt, dass der interne AD Wandler des Mikrocontrollers nicht genau genug ist, richtige Messungen durchzuführen. Die Ansteuerung der MMC/SD Karte hat sich als sehr problematisch erwiesen. Der 8 Bit Mikrocontroller ist nicht in der Lage ein Dateisystem richtig zu interpretieren.

Temperatur

Die Temperatur ist messtechnisch eine relativ einfache Größe. Über eine Temperaturmessung könnte später ermittelt werden, in welcher Umgebung sich das Erfassungsgerät befunden hat oder wo es getragen wurde. Darum soll der Daily Activity Monitor eine Temperaturmessung enthalten.

Um die Temperatur zu messen, gibt es verschiedene Möglichkeiten. So kann diese beispielsweise über eine Temperaturdiode wie in Abbildung 5 gezeigt gemessen werden.

Abbildung 5: Temperaturmessung mit einer Temperaturdiode

Eine Temperaturdiode hat eine Sperrspannung, die sich linear zur Temperatur verhält. Dieser Wert kann über einen A/D Wandler direkt gemessen werden.

In der Praxis hat sich gezeigt, dass sich diese Spannungsmessung jedoch nur bedingt für ein batteriebetriebenes Gerät eignet. Der Strom, der immer durch die Diode fließen muss, um eine stabile Spannung aufrecht zu erhalten, ist zu groß für eine Batterie. Daher wurde auf einen digitalen Temperatursensor gewechselt, der gleichzeitig auch die Luftfeuchtigkeit messen kann.

Luftfeuchtigkeit

Ebenso wie bei der Temperatur könnte die Luftfeuchtigkeit Aufschluss darüber geben, wo sich das Aufzeichnungsgerät befunden hat. Falls der Luftfeuchtigkeitssensor nahe der Haut platziert wird, dann kann über diesen Sensor auch die Aktivität validiert werden.

Die Luftfeuchtigkeit kann man messtechnisch über vielerlei Arten erfassen. Am Ende wurde bei dem Projekt der Temperatur- und Feuchtigkeitssensor SHT11 (Abbildung 6) der Firma Sensirion gewählt. Er misst die Feuchtigkeit über einen integrierten kapazitiven Feuchtigkeitssensor. Das Ausgabesignal ist Digital.

sht11cols2.jpg

Abbildung 6: Foto des SHT11

Pulsoxymetrie

Die Pulsoxymetrie ist ein Verfahren, um optisch den Puls und die Sauerstoffsättigung im Blut zu messen. Dieses Messverfahren basiert darauf, dass sauerstoffreiches Blut mehr Licht absorbiert als sauerstoffarmes Blut. Um dies zu messen, kann man das Blut mit einem Infrarotstrahl bestrahlen und anhand der Reflexion ermitteln, welchen Sauerstoffgehalt das Blut hat. Da sich bei jeden Herzschlag die Arterien etwas weiten, erhält man zudem den Herzschlag.

In einem Vorexperiment wurde dann getestet, ob die Reflexionen am Handgelenk ausreichen würden, um den Puls zu bestimmen. Dazu wurde zunächst eine Schaltung für ein Pulsoxymeter aufgebaut. Die Abbildung 7 zeigt den Schaltplan einer solchen Schaltung. Das Platinenlayout dieser Schaltung ist in Abbildung 8 zu sehen. Das Gewebe wird mit unterschiedlichen Wellenlängen bestrahlt, um Umgebungslichteffekte heraus rechnen zu können sowie um die Absorption auf die reine Absorption des Blutes und nicht des Gewebes zurückführen zu können. Im Schaltplan übernimmt diese Aufgabe die LED1 und LED2. Die Messung des Lichtes erfolgt in einer Fotodiode, die abhängig von dem einfallenden Licht einen bestimmten Strom erzeugt. Auf der Platine ist die Fotodiode LED3 zwischen den beiden Leuchtdioden LED1 und LED angebracht. Der Strom der Fotodiode ist allerdings sehr schwach und muss daher verstärkt sowie zu einer Spannung gewandelt werden. Dies übernimmt ein Transimpendanzwandler. Ein Transimpendanzwandler kann beispielsweise durch einen Operationsverstärker realisiert werden. In der Schaltung übernimmt der IC1A des Operationsverstärker IDs LM324D diese Aufgabe. Der eingehende Strom der von der Fotodiode kommt wird durch einen Strom durch den Widerstand R3 neutralisiert. Die Ausgangsspannung ergibt sich aus der Formel . Da das einfallende Licht proportional zum Strom der Photodiode ist, ist Ausgabesignal dann eine Spannung die dem einfallenden Licht entspricht.

 

Die Abbildung 9 zeigt die Ausgabe beim Messen des Signals an einem Finger auf einem Oszilloskop. Jeder horizontale Strich entspricht einer Sekunde, jeder vertikale Strich 500mV. Der Pulsschlag ist ziemlich eindeutig zu erkennen. Leider hat sich bei den Experimenten gezeigt, dass am Handgelenk zu wenig blutdurchströmtes Gewebe vorhanden ist. Zudem war abhängig von der Lage immer ein anderer Offset zu Messen, was schon bei kleinen Bewegungen sehr starte Artefakte verursacht hat. Daher wurde in diesem Projekt darauf verzichtet, den Herzschlag mit einem Pulsoxymeter zu messen.

Abbildung 7: Schaltplan für Pulsoxymeter

 

Abbildung 8: Platinenlayout einfaches Pulsoxymeter

Abbildung 9: Herzschlag auf dem Oszilloskop

 

Hardware

Die vorherigen Experimente haben gezeigt, welche Sensoren verwendet werden können und welche sich nicht so sehr dafür eignen. Die Abbildung 10 zeigt die Zusammenfassung aller geplanten Komponenten.    

Abbildung 10: Aufbau Daily Activity Monitor

Beim Bau der der Versuchsplatinen hat sich gezeigt, dass viele Überlegungen in die Konnektivität und das Handling gemacht werden müssen. Für die Datenübermittlung müssen entsprechend einfache Schnittstellen zum PC existieren. Auf den Stromverbrauch muss besonders geachtet werden, damit die Batterie lange hält.

USB Schnittstelle

Die Kommunikation zu dem Host PC und der Analysesoftware erfolgt über den USB Bus. Der USB Bus hat den Vorteil, dass er an praktisch jedem PC inzwischen vorhanden ist und universell einsetzbar ist. Die verwendete Mikrocontrollerserie AVR hat spezielle USB AVR Typen, die einen USB Treiber direkt schon enthalten. Der USB Bus hat zusätzlich den Vorteil, dass auch Energie mit übertragen wird und somit die Batterie geladen werden kann. Für das Laden der Batterie wurde ein standardisierter Laderegler verwendet, der vollautomatisch aus der USB Spannung eine Li Ionen Batterie lädt.

Als Protokoll auf USB wurde eine serielle Schnittstelle gewählt. Die USB Spezifikation hat viele verschiedene Standardklassen definiert, aber auch benutzerdefinierte Klassen können erstellt werden. Für diese Anwendung eignet sich eine serielle Schnittstelle aufgrund ihrer Einfachheit sowie der Tatsache, dass kein extra Treiber erforderlich ist.

Wird der Mikrocontroller mit einem PC verbunden, wird zunächst die Initialisierungsroutine durchgeführt. Die Treiber für die serielle Schnittstelle werden geladen und initialisiert. Öffnet nun ein Programm eine serielle Verbindung, wird auf dem Mikrocontroller eine Konsole geladen. Das Steuerungsprogramm kann nun Befehle an den Mikrocontroller senden, die dort ausgeführt werden und das Resultat wird zurückgegeben.

Speicher

Zunächst war vorgesehen, bei dem Projekt eine SD HC Karte zu verwenden. Preislich sind diese Karten sehr günstig und haben auch eine entsprechende Speichergröße.

Die Ansteuerung von SD Karten erfolgt seriell über den SPI Bus. In [1] wird ein Projekt vorgestellt, wie man mit dem verwendeten Mikrocontroller auf eine SD Karte schreiben kann. Bei der ersten Version hat sich allerdings gezeigt, dass dieser Speichertyp nicht so ideal ist. Das Lesen und Beschreiben des Speichers kann nur Blockweise erfolgen. Ein Block umfasst 512 Bytes. Das Problem dabei ist, dass die Mikrocontroller nicht genügend Speicher haben, um mehrere Blöcke im Speicher  zu analysieren. Ein FAT Dateisystem, welches auf den meisten Karten vorhanden ist, ist ebenso ziemlich ungeeignet für solch eine Sensorapplikation. Für einen einfachen Schreibzyklus muss der Dateisystemtreiber mehrere Blöcke im Speicher bereithalten, um die richtigen Speicherpositionen herauszufinden. Der verwendete 8 Bit Mikrocontroller hat nicht den Speicher und die Rechenleistungen, um dies in einer annehmbaren Zeit mit einem annehmbaren Aufwand zu realisieren. Aus diesem Grund wurde in der neuen Revision ein integrierter Flash Speicher mit SPI Schnittstelle verwendet.

Sensor

In der neuen Revision wurde kein analoger, sondern ein digitaler Beschleunigungssensor verwendet. Die Wahl fiel auf den MMA7456 von Freescale. Dieser lässt sich über ein I2C oder ein SPI Interface digital ansteuern. Zudem hat er schon integrierte Verarbeitungsmöglichkeiten sowie Interruptfunktionalitäten. Für diesen Chip ist auch eine Demonstrationsapplikation vorhanden, so dass auch mit der Softwareentwicklung begonnen werden konnte obwohl noch keine Hardware verfügbar war.                              

Stromversorgung

Die Schaltung sollte ein einheitliches Konzept für eine Stromversorgung haben. Dazu wurde eine LiIonen Batterie mit einer Kapazität von 450mAh ausgewählt. Um diese Batterie zu laden, wurde ein entsprechender Lade Chip für den USB Bus auf die Platine integriert. Dieser wandelt die 5V des USB Busses in einen konstanten Ladestrom für die Li Ionen Batterie.

Die Platine selbst arbeitet mit 3,0V. Es wurde hierzu ein Low Drop Wandler mit 0,3V max. Drop Spannung verwendet. Somit kann die Spannung der Batterie bis auf 3,3V absinken. Würde die Platine mit einer höheren Spannung wie 3,3V arbeiten, dann könnte die Batterie nur bis auf 3,6V entladen werden und es würde mehr ungenutzte Restenergie in der Batterie verbleiben

Um den Ladezustand der Batterie zu messen, wird die Batteriespannung mit einem Spannungsteiler halbiert. Dadurch liegt sie im Messbereich des AD Wandlers des Mikrocontrollers, der die Spannung dann messen kann. Somit hat der Mikrocontroller immer die Kontrolle, ob noch genug Akkuleistung vorhanden ist.

Softwareframework

Die Software besteht aus zwei Teilen. Zum einen besteht diese aus einer Firmware, die auf dem Mikrocontroller läuft. Der zweite Teil ist eine Analysesoftware, die auf einem  PC arbeitet.

Firmware

Die Platine enthält einen Mikrocontroller, der mit einer Firmware programmiert werden muss. Die Firmware hat die Aufgabe, den Datenfluss zwischen Sensor und Speicher zu verwalten sowie dann das Auslesen durch den PC zu ermöglichen.

Bei der Programmierung der Firmware musste darauf geachtet werden, dass das Programm in keinen Wartezuständen hängen bleibt. Wenn ein Programmteil beispielsweise auf eine Aktion des Speichers warten würde, dann könnte der Messprozess nicht rechtzeitig ausgeführt werden.

Die gesamte Architektur basiert daher auf Zustandsmaschinen.

Der Mikrokontroller ist zudem ein single thread prozessor, bei dem es nicht möglich ist mehrere Threads laufen zu lassen. Da allerdings mehrere Anwendungen gleichzeitig auf dem Prozessor laufen müssen, werden alle Prozesse nacheinander abgearbeitet. Jeder Prozess darf nicht zu lange in einem Zustand verharren, da ansonsten die Zeitsynchronität verloren gehen würde.

Es gibt vier Prozesse, die gleichzeitig abgearbeitet werden. Die ersten beiden Prozesse kümmern sich um die USB Kommunikation mit dem PC, falls dieser angeschlossen ist. Der zweite Prozess ist der eigentliche Messprozess, der Messungen startet, die Daten ausliest und in dem Speicher ablegt. Der letzte Prozess wird aufgerufen, nachdem alle anderen Prozesse abgearbeitet wurden. Er prüft, ob noch weitere Aktionen vorliegen, und bringt falls möglich den Prozessor in einen stromsparenden Stand By Modus. Aus diesem Stand By Modus kann der Prozessor wiederum durch ein Timersignal geweckt werden oder durch ein externes USB Signal.

Die Abbildung 11 zeigt den prinzipiellen Ablauf aller Tasks.

Abbildung 11: Zustandsmaschine der Firmware

Timer

Die gesammelten Daten sind ohne eine gemeinsame  Zeitbasis nicht so viel Wert. Daher muss das System eine Echtzeituhr haben, um die Daten mit einer Zeitbasis aufzeichnen zu können. Da das Messsystem keinen Ein/Ausschalter besitzt, läuft der Mikrocontroller die ganze Zeit. Somit reicht es, wenn der Mikrocontroller immer beim Verbinden mit dem PC synchronisiert wird. 

An den Mikrocontroller ist ein 32.768Hz Uhrenquarz angeschlossen. Dieser Takt wird intern durch den Faktor 16 geteilt und dann an einen Interrupt angeschlossen. Somit wird also jede  ein Interrupt ausgelöst. Das Auslösen des Interrupts hat zur Folge, dass der Stand By Modus verlassen wird und alle Messaufgaben abgehandelt werden. Zudem wird eine Echtzeituhr hochgezählt. Um die Echtzeituhr relativ einfach zu halten, erfolgt die genaue Resynchronisierung des Messdaten auf dem Host PC. Die Echtzeituhr speichert nur die Zahl der Sekunden seit dem letzten Reset in drei Variablen:

dCounter

sCounter

uTicksCounter

Anzahl von 65536 Sekunden Einheiten seit dem letzten Start, entspricht etwa 18,2h

0.. 65536 Sekunden

Anzahl der  Einheiten seit dem letzten Start

 

Zusätzlich feuert der Timer auch Events ab. Dies erfolgt durch das Setzen eines Flags in einer globalen Variable. Ist das Event vom Hauptprozess ausgeführt worden, wird das Flag wieder gelöscht. Alle 16 Sekunden sowie alle 256 Sekunden wird ein solches Event ausgelöst und an den Messprozess geschickt.

 

USB Implementierung

Über die USB Schnittstelle werden die Messdaten ausgetauscht sowie Kommandos von der Host Applikation übertragen. Als USB Klasse wird eine virtuelle serielle Schnittstelle verwendet. Dieses benötigt auf dem Host PC keine extra Treiber, sondern kann betriebssysteminterne Treiber verwenden.

Die Kommunikation selbst findet über Endpunkte statt. Der Messchip hat einen Eingabe und einen Ausgabeendpunkt für serielle Daten. Wird das Messsytem mit dem Host PC verbunden, wird eine Konsole auf dem  Mikrocontroller gestartet. Die Host Applikation kann sich mit der Schnittstelle verbinden, und dann Text zu dem Mikrocontroller senden. Diese Befehle werden dann vom Mikrocontroller beantwortet.

 

Messprozess

Der Messprozess steuert den gesamten Messablauf und initiiert die Einzelmessungen. In Abbildung 12 ist der Prozess als Zustandsmaschine visualisiert. Durch den Timer ist garantiert, dass dieser Prozess alle mindestens 1x durchgeführt wird.

Abbildung 12: Zustandsmaschine des Hauptmessprozesses

Zunächst wird geprüft, ob der Messmodus überhaupt aktiv ist. Dann werden die Events überprüft, und gegeben falls entsprechende Startaktionen gestartet. So wird bei einem 16S impuls die Batteriemessung sowie die Temperaturmessung angestoßen. Nach dem anstoßen arbeiten die Sensoren komplett eigenständig und erfassen die Werte. In späteren Zyklen wird abgefragt ob die Werte schon komplett erfasst wurden und dann entsprechend abgespeichert.

Der Beschleunigungssensor hat die höchste Datenrate aller Sensoren. Das Statusregister wird daher bei jedem Durchlauf abgefragt. Falls neue Sensordaten verfügbar sind, werden diese dann in den Speicher geschrieben.

Batteriemessung

Alle 16 Sekunden wird die Batteriemessung angestoßen. Das Messen der Batteriespannung erfolgt im internen AD Wandler. Es werden zur Batteriemessung zwei Prozesse verwendet. Der erste Prozess wird beim Starten der Batteriemessung durchgeführt. Der AD Wandler wird aus dem Power Down Modus geholt und initialisiert. Dann wird die Messung gestartet, und der AD Wandler führt eigenständig die Messung durch. Ist die Messung zu Ende, dann wird dies durch einen Interrupt signalisiert. Der Interrupt liest den Wert aus und konvertiert ihn zu einem 8 Bit Wert. Dann wird der AD Wandler wieder deaktiviert. Die Abbildung 13zeigt die beiden Prozesse.

Abbildung 13: Messung der Batteriespannung

Die Spannungsreferenz des AD Wandlers liegt auf 2,56V. Es wird zunächst mit einer Genauigkeit von 10 Bit gewandelt. Da die Batteriespannung höher als die 2,56V ist, wird sie mit einem Spannungsteiler auf die Hälfte reduziert. Es ergibt sich also in der Summe folgender Ausgangswert:

Da sich die Spannung der Li Ionen Batterie nur im Bereich zwischen 3,2V und 4,2V befindet, wird der ADC Wert auf 8 Bit heruntergesetzt. Hierzu wird der Wert 650 abzogen. Falls der Wert aus dem 8 Bit Wertebereich herausfallen würde, wird der Wert auf die entsprechende Grenze gesetzt. Eine Messung hat folgende Tabelle ergeben:

 

Wert

4,2 V

207

4,1 V

187

4,0 V

166

3,9 V

146

3,8 V

125

3,7 V

105

3,6 V

84

3,5 V

64

3,4 V

45

3,3 V

24

 

Speicherformat

Als Speicher wurde ein Flash Speicher im SO8 Gehäuse gewählt. Im Gegensatz zu der Möglichkeit, eine SD Karte zu verwenden, hat dieser Speicher den Vorteil dass die Ansteuerung viel einfacher zu handhaben ist. Allerdings sind in diesen Bauformen noch nicht so große Flash Speicher verfügbar, so dass bei dem Projekt ein 32 MBit Speicher = 4 MByte Speicher für die Daten ausreichen muss. Die Daten werden daher vor dem Abspeichern mit einer Lauflängenkodierung komprimiert. Der Speicher ist Blockorientiert, d.h. es stehen 8192 Blöcke a 512 Bytes zu Verfügung. Der Mikrocontroller speichert die Daten entsprechend dann auch immer blockorientiert. Im EEProm des Mikrocontrollers wird festgehalten, welcher Block gerade beschrieben wird, und welcher zuletzt ausgelesen wurde. Wenn die Schreibposition die Ausleseposition erreicht, dann ist der Speicher voll.

Die Abbildung 14 zeigt den Aufbau des Speichers, wenn eine bestimmte Menge Daten bereits aufgezeichnet wurden.

Abbildung 14: Funktionsweise Ringpuffer

Jeder Block beginnt mit allgemeinen Headerinformationen:

Feld

Länge

Funktion

uTicksCounter

1 Byte

Diese drei Felder enthalten zunächst die Datumsinformationen, wann dieser Block aufgezeichnet wurde. Die Zeitinformationen geben die Zeit an, die seit dem Start des Mikrocontrollers vergangen sind. uTicksCounter gibt dabei die Länge in 1/256 Sekunden an, sCounter die Zahl der Sekunden. Der dCounter enthält wie viele 18,2h Einheiten seit dem Start vergangen sind. Diese Zeitinformationen reichen damit in der Summe aus, die Zeiten für bis zu 14 Tage anzugeben.

sCounter

2 Byte

dCounter

1 Byte

BatteryState

1 Byte

Dieses Feld enthält den Status der Batterie, als dieses Paket aufgezeichnet wurde

RevisionCounter

1 Byte

Der Mikrocontroller enthält im EEProm einen Startup Counter. Dieser zählt bei jedem Start des Mikrocontrollers um den Wert 1 hoch. Beim Anlegen eines neuen Paketes wird dieser Revisionscounter mit abgespeichert. Falls also während einer Messung der Mikrocontroller neu gestartet wurde, so kann durch diesen Wert später festgestellt werden ob Daten verloren gingen oder ob Daten mit falschen Zeitinformationen abgespeichert wurden.

               

Die restlichen Bytes des Blockes enthalten dann die Sensordaten zu den Beschleunigungssensoren sowie Temperatur/Feuchtigkeitsmesswerte. Die Werte sind, um Speicher zu sparen, mit unterschiedlichen Längen aufgezeichnet. Folgende Bedeutung kann ein gelesenes Byte haben:

Byte (Binär)

Bedeutung

0b0000 0000

Ende des Blockes

0b0001 xxyy 0byyyy yyyy

Dieser Abschnitt enthält nicht lauflängenkodierte Messdaten. Die Bits xx geben an, auf welcher Achse ein Wert gemessen wurde. Die Bits y enthalten dann den Wert.

0b0010 xxyy 0byyyy yyyy 0bzzzz zzzz

Dieser Abschnitt enthält lauflängenkodierte Beschleunigungsmessdaten. Die Bits xx geben an, für welche Achse dieser Wert gemessen wurde. Der Wert selbst ist in den Bits mit dem y abgelegt. Die z Bits enthalten die Länge, wie oft dieser Beschleunigungswert gemessen wurde

0b1000 tttt 0bxxxx xxxx 0bxxxx xxxx

Dies ist ein Abschnitt, mit einem 16 Bit Messwert, wie er vom Temperatur- oder Feuchtigkeitssensor geliefert wird. Die Bits unter t  geben an, um welchen Sensor es sich handelt. Die Bits x sind ein 16 Bit Integerwert mit dem eigentlichen Messwert.

 

Analysesoftware

In dem Projekt wurde eine universelle Softwareplattform für Analysen geschaffen. Sie sollte möglichst einfach für den Benutzer zu bedienen sein, aber trotzdem auch die Möglichkeit enthalten direkt Algorithmen auf der Plattforum zu entwerfen und zu testen. Das System soll aus mehreren möglichen Eingabequellen die Daten herauslesen, mit verschiedenen Bearbeitungsmodulen die Daten analysieren und dann auf dem Monitor dem Benutzer interaktiv darstellen. Die Softwarestruktur soll modular gehalten werden, um neue Algorithmen möglichst einfach einbetten zu können. Nach Möglichkeit sollten neue Analysemodule durch Plugins hinzugefügt werden können.

Oberfläche

Die Oberfläche soll einen einfachen Zugriff auf alle Berechnungsvariablen geben, um eine Entwicklung von Algorithmen in dem Programm zu ermöglichen. Gleichzeitig sollen alle Komponenten in einer Endanwendung für den Endkunden auch verwendbar sein. In Abbildung 15 ist ein Screenshot der Anwendung gezeigt.

Hautbestandteil der Oberfläche ist ein graphisches Ausgabefeld in dem Kurven und Darstellungen geladen werden können. Darunter ist ein Feld für Ausgaben von Textanalysen. Die Ausgaben werden von entsprechenden Visualisierungsmodulen erzeugt, die in der Toolbar ausgewählt werden können.

Alle Berechnungsmodule und Visualisierungsmodule haben Optionen, die ein einer Tabelle aufgelistet sind und direkt geändert werden können.

Für Analysen für Endanwender kann das Parameterfeld entfernt werden, und nur noch die entsprechenden Visualisierungsmodule können ausgewählt werden.

Abbildung 15: Hauptoberfläche der Analysesoftware

Für komplexere Analysen gibt es ein Wizard System. Module können als Wizard implementiert werden und aus dem Menü aufgerufen werden. Sie führen den Benutzer in Dialogfeldern durch eine Analyse und geben eine entsprechende Zusammenfassung aus oder verändern Parameter der Gesamtanalyse. Ein Anwendungsfall für solch einen Wizard ist beispielsweise die Offsetkorrektur.

Für die graphische Darstellung wird das Steuerelement OsziControl verwendet, das vom Autor schon vor einiger Zeit entwickelt wurde. Dieses Steuerelement dient zur Darstellung von Oszilloskop Kurven. Im Gegensatz zu den üblichen Darstellungsprogrammen für Oszilloskop Kurven hat dieses Steuerelement das Ziel, die Bedienung möglichst dem Windows Standard anzupassen.

Genereller Programmaufbau

Als Programmierumgebung wurde eine C#/.NET Laufzeitumgebung gewählt. Diese hat den Vorteil, dass schon relativ viele Komponenten verfügbar sind. Durch die objektorientierte Natur der .NET Umgebung ist es auch einfach, neue Algorithmen oder Module zu implementieren.

Die Berechnungsstruktur des Programmes ist in drei Ebenen aufgeteilt (siehe Abbildung 16). In der ersten Ebene erfolgt der Datenimport. Entsprechende Module können Daten aus Eingabedateien oder auch aus einer Live Quelle beziehen. Die Daten werden dann über verschiedene Verarbeitungsmodule weitergereicht. Am Ende stehen Visualisierungsmodule, die die Daten graphisch aufbereiten und dann an das Ausgabedialogfeld liefern. Alle Objekte können Konfigurationsobjekte enthalten, die die jeweiligen Analysen steuern.

Abbildung 16: Datenfluss der Analysesoftware

 

Um die Parameter anzupassen, können Wizard Objekte auf die gesamte Berechnungsstruktur zugreifen. Mit ihnen soll der Benutzer die Möglichkeit haben, einfach die Parameter zu ändern und zu optimieren.

 

Algorithmen 

Die Abbildung 17 zeigt den Aufbau der Berechnungsklassen. Jedes Berechnungsobjekt kann von dem Hauptpaket eine bestimmte Analyse anfordern. Das Diagramm zeigt, welche Pakete die vorhanden Klassen jeweils anfordern und was sie berechnen.

Abbildung 17: Berechnungsbaum der Analysesoftware

Vorverarbeitung

Zunächst müssen die Daten vorverarbeitet werden. Dies erfolgt in dem Berechnungsmodul DAMRawProcessor. Hier können die Daten um einen bestimmten Offset verschoben werden. Danach besteht die Möglichkeit, die Daten zu skalieren und zu drehen. Es stehen also folgende Parameter zur Verfügung:

·         Offset (

·         Skalierung:

·         Drehung:

Sind die Parameter gegeben, wird zunächst eine Umformungsmatrix gebildet. Die Umformungsmatrix ist das Produkt von vier Matritzen. Aus den Parametern der Skalierung wird die Matrix  erzeugt, aus den Drehungswinkeln die Matritzen  gebildet:

  

Die Umformungsmatrix ist dann das Produkt aller 4 Matrizen.

Jeder Beschleunigungsvektor wird dann mit der Matrix multipliziert, um einen korrigierten Vektor zu erhalten:

Diese Operation wird mit allen Beschleunigungswerten durchgeführt.

Gesamtbeschleunigung

Aus den Werten der Vorverarbeitung lässt sich die Gesamtbeschleunigung berechnen, mit der der Sensor bewegt wurde. Sie wird mit der folgenden Formel berechnet

Zusätzlich zur Gesamtbeschleunigung wird die Gesamtbeschleunigung ohne Erdbeschleunigung ermittelt. Da die Erdbeschleunigung konstant mit 1G auf den Sensor wirkt, kann diese direkt abgezogen werden.

FIR Filtergenerator

Das Programm enthält ein abstraktes Berechnungsmodul, das einen FIR Filter nachbaut. Dieses Modul kann überladen werden, wenn ein spezieller FIR Filter benutzt werden soll. Das überladene Modul muss dann nur noch eine Berechnungsmethode für die Filterkoeffizienten enthalten, die Filterung wird von dem FIR Modul übernommen.

Ein FIR Filter ist ein allgemeiner Signalverarbeitungsfilter. Er entstammt aus der Z Transformation.

Gegeben sei zunächst eine allgemeine zeitdiskrete Übertragungsfunktion:

Die Übertragungsfunktion ist gleichzeitig das Ausgangssignal durch das Eingangssignal

Ineinander eingesetzt ergibt sich folgende Gleichung

Dividiert man nun durch die höchste z – Potenz, erhält man folgende Gleichung

Diese Gleichung lässt sich nach Y(z) auflösen:





Mithilfe der Z Transformation lässt sich diese Gleichung in den Zeitbereich Transformieren


Aus den gegebenen Koeffizienten lässt sich somit mit dieser Formel die gefilterte Reihe  aus den Eingangsdaten  berechnen.

Das Programm enthält einen Wizard (Abbildung 18), mit dem die verwendeten FIR Filter im Programm angezeigt und Analysiert werden können. Der Wizard stellt Frequenzgang, Phasengang, sowie eine Ortskurve mit Pol/Nullstellendiagramm zu Verfügung.

 

Abbildung 18: Screenshot des FIR Filtergenerators

Hoch/Tief/Bandpassfilter

Um nicht direkt die FIR Parameter eingeben zu müssen, enthält das Programm ein von dem FIR Filtermodul abgeleitetes Berechnungsobjekt, das die FIR Parameter für Hoch, Tief und Bandpass berechnen kann.

Das Modul errechnet dann zu der eingegebenen Knickfrequenz und der Samplingrate der Quelle einen Filter 1. Ordnung

Es werden folgende Filterfunktionen verwendet:

Tiefpassfilter:



Hochpassfilter:


Bandpassfilter:




 

Bei diesem Frequenzfilter handelt es sich ebenso um ein abstraktes Modul. Es kann überladen werden um einen bestimmten Filter zu erzeugen.

Lagefilter

Der Lagefilter ist ein Tiefpassfilter. Bei den Beschleunigungen kann davon ausgegangen werden, dass die hochfrequenten Beschleunigungen Bewegungen sind, die niederfrequenten Beschleunigungen sind das Resultat der Erdbeschleunigung. Für alle Lageoperationen wird daher das Signal mit einem Tiefpassfilter gefiltert und den anderen Modulen zur Analyse überlassen.

Lageberechnung

Das tiefpassgefilterte Lagesignal hat praktisch immer die Länge 1G. Der Beschleunigungsvektor zeigt somit praktisch immer auf einen Punkt auf einer Kugel um den Ursprung mit dem Radius 1. Für eine Klassifizierung der Lage eignen sich daher Gebiete auf dieser Kugel, auf die der Beschleunigungsvektor zeigen kann. Die Abbildung 19 zeigt die geglättete Beschleunigungskurve in einem 3D Diagramm. Die Begrenzungslinien zeigen einen Würfel mit der Kantenlänge 2. Es ist deutlich zu erkennen, wie die Lage sich nur auf einer Kugel befindet.

Abbildung 19: 3D Visualisierung der Beschleunigungswerte

Für eine Klassifizierung eignet sich eine 2D Darstellung allerdings besser als eine 3D Darstellung. In der 3D Darstellung. Darum erfolgt eine Transformation der Kugeloberfläche auf eine 2D Darstellung.

Von jedem Beschleunigungsvektor wird praktisch der Längen und Breitengrad des Punktes ermittelt, der beim Durchstoßen der Einheitskugel getroffen wird.

Formelmäßig wird dieser Punkt so berechnet:


Zusätzlich wird der Neigungswinkel zur X,Y und Z Achse berechnet.



 

Klassifikation

Die Klassifikation der Lage erfolgt im Modul DAMLatLonClassifier. Es wird eine einfache Bereichsklassifikation durchgeführt. Über Parameter können rechteckförmige Gebiete mit dem Längen und Breitengrad definiert werden. Der Klassifizierer sucht dann für jede Lage die entsprechende Klasse heraus und weißt diese Klasse zu. In Abbildung 20 sind die einzelnen Positionen für einen am Bein getragenen Sensor abgebildet. Dadurch, dass für die Klassifikation das bereits Tiefpass gefilterte Signal verwendet wird, ist eine weitere Glättung der Klassen nicht notwendig.

Abbildung 20: Einteilung der Beschleunigungen in Klassifikationen

               

Frequenzbasierte Analysen

Um frequenzbasierte Analysen durchzuführen, wird eine FFT der Daten durchgeführt. Die FFT besteht aus zwei Modulen. Das erste Modul ist ein Fenstermodul, das immer ein Teil der Daten aus dem kompletten Datenstrom herausnimmt und mit einer Fensterfunktion multipliziert. Das zweite Modul ist die eigentliche FFT.

Fenstermodul

Das Programm enthält ein Fenstermodul, das das zeitliche Beschleunigungssignal in Pakete aufteilt. Die Pakete können eine variable Länge haben. Für die Berechnung der FFT ist allerdings später erforderlich, dass die Länge eine Zweierpotenz ( ist. Die Fenster können sich um einen bestimmten Faktor überlappen. Sind die Pakete herausgezogen, werden sie nochmals mit einer Fensterfunktion multipliziert. Die Fensterfunktionen dienen dazu, asdfa sdf asdf Effekte zu verhindern. Es stehen verschiedene Fensterfunktionen wie eine Barlett funktion, BlackmanFilter oder einfach ein Rechteckfilter zur Verfügung.

FFT Modul

Die gefensterten Daten werden nun über eine FFT in den Frequenzbereich konvertiert. Hierzu wird zunächst eine ganz normale FFT Funktion durchgeführt. Eine FFT arbeitet mit komplexen Zahlen. Das Ergebnis eines reellen Signales ist immer komplex. Jeder Ergebniswert zeigt die Energie eines bestimmten Signales im Absolutbetrag, sowie die Phase des jeweiligen Frequenzanteils die Phasenlage des Signals an.  Für die weiteren Berechnungen wird nur noch der Absolutbetrag gespeichert, da die Phasenlage für Analysen nicht sehr interessant erscheint.

Abbildung 21: Gesamtbeschleunigung beim Laufen

Abbildung 22: Fourieranalyse der Gesamtbeschleunigung

Aktivität

Hauptbestandteil des Projektes ist eine Aktivitätsmessung über die Zeit. Energieaufwändige Aktivitäten sind in der Regel langsame, periodische Bewegungen. Das Ergebnis der FFT Transformation ist eine Kurve, die die Signalenergien für einzelne Frequenzen aufzeigt. Für die Berechnung der Aktivität werden dann dazu die Signalenergien für einen Frequenzbereich zusammenaddiert. Rechnerisch entspricht der Aktivität

Da die Sensoren ein natürliches Rauschen haben, wird ein Korrekturoffset abgezogen.

Die Aktivität wird für jedes vom dem Fenstermodul erzeugten Fensteres berechnet. Die Aktivität gilt dann für den gesamten Zeitraum, den dieser Auszug überdeckt.

Die Aktivität kann momentan und kumuliert Dargestellt werden. Bei der momentanen Darstellung wird für jede Zeit die Aktivität aufgezeigt. Bei der kumulierten Darstellung wird der aktuelle Wert zur Vergangenheit hinzuaddiert. Somit kann am Ende des Tages festgestellt werden, welches Aktivitätsniveau an diesem Tag vorhanden ist.

Verworfene Annahmen

Vertikalgeschwindigkeit

Aus Beschleunigungen lässt sich theoretisch durch zweimaliges Integrieren der Ort herausfinden.


In der Praxis treten allerdings Fehler auf. So ist immer bei den Messungen ein Offset überlagert.

Durch das zweimalige Integrieren verfälscht der Offset die Ausgangsposition mit quadratischer Ordnung.

Dieser Fehler könnte theoretisch durch eine gute Offsetkorrektur behoben werden. Ein weitaus größeres Problem ist allerdings, dass die Lage des Sensors unbekannt ist. Dadurch wirkt die Erdbeschleunigung mit 1G immer auf den Sensor. Ohne einen weiteren Sensor ist es nicht möglich, die Drehungen des Sensors heraus zurechnen. Das folgende Beispiel zeigt einen Anwendungsfall, wie der Sensor auf zwei Arten bewegt werden könnte, und was das gleiche Messresultat hervorbringen würde:

Abbildung 23: Sensor fällt

Wenn der Sensor nach unten fällt, misst der Beschleunigungssensor während des gesamten Falls die Beschleunigung 0. Der Sensor kann sich nun in jede beliebige Position drehen, ohne dass sich die Messwerte ändern.

Wenn jetzt der Sensor in eine bestimmte Richtung beschleunigt wird, aber der Sensor entsprechend vorher gedreht wurde, resultiert dies in immer der gleichen Messwerte.

Abbildung 24: Sensorbewegungen und resultierende Vektoren

 

Dies stellt eine systematische Grenze dar, weshalb eine Integration nicht möglich ist solange sich der Sensor frei drehen kann. Da bei diesem Sensor nicht klar ist, wo er genau am Körper getragen wird und wie sich der Körper bewegt, ist es nicht möglich dies heraus zurechnen.

Wizzard Offset Korrektur

Beschleunigungssensoren weißen von ihrer Bauart aus einen sehr hohen Offset auf. Unter normalen Bedingungen kann dieser Offset +- 0,2G betragen. Die Abbildung 25 zeigt die um die Erdbeschleunigung 1g korrigierte Gesamtbeschleunigung auf einen gedrehten Sensors. Eigentlich sollte die ganze Kurve nur minimal um den Wert 0 abweichen. Durch unterschiedliche Offsetwerte der drei Achsen sind jedoch Offsets vorhanden. Dieser Offset hat zur Folgen, dass sich die Richtung der Beschleunigungen nur ungenau feststellen lässt. Daher muss dieser korrigiert werden.

Abbildung 25: Durchschnittswerte der tiefpassgefilterten Beschleunigungswerte

Der Hersteller des Beschleunigungssensor Chips stellt in [2] Methoden vor, wie eine Kalibrierung erfolgen kann. Bei einer herkömmlichen Kalibrierung führt man eine 0G oder eine 0X0Y1Z Kalibrierung durch. D.h. man legt an den Sensor eine bestimmte Beschleunigung an und errechnet dann den Offset. In der Praxis ist es allerdings bei einem am Körper getragenen Beschleunigungssensors schwierig, eine definierte Lage als Kalibrierungslage zu verwenden. Darum wird hier eine alternative Kalibrierungsmethode vorgestellt, mit der der Offset ohne Referenzlage bestimmt werden kann.

Um aus den 3 Achsen die Gesamtbeschleunigung zu errechnen, wird der Betrag des Vektors gebildet.

Wenn der Beschleunigungssensor nicht beschleunigt wird, dann wirkt nur die Erdbeschleunigung mit 1G auf den Sensor. Daher gilt für die Ruhelage immer:

Wie die obige Graphik zeigt ist dieser Wert allerdings um 1 verschieden.

Korrigiert man nun den X,Y und Z Wert um einen Offset Wert , dann wird die Formel zu folgender:

Um einen eventuellen Faktor noch mit zu berücksichtigen, wurde die Formel um weitere Faktoren ergänzt:

Es gibt also 6 Variablen (, die aus gegebenen Punkten bestimmt werden könnten.

Da allerdings die Lösung nicht exakt sein wird, da immer ein Zufallsrauschen mit in den Messdaten sein wird, wurde ein genetischer Algorithmus entwickelt.

Gegeben seien  Stützstellen auf der Messkurve, bei denen der Sensor in Ruhe war. .

Gesucht seien die 6 Korrekturvariablen

Zunächst berechnet der Algorithmus den Fehler, der bei Verwendung von bestimmten Korrekturwerten entsteht:

Der Algorithmus beginnt mit den Startwerten. Dies wäre der optimale Fall bei dem keine Korrektur notwendig wäre.
Nun probiert der Algorithmus zufällig aus, diese 6 Variablen zu verändern. Wenn der neue Fehler geringer ist als der vorherige, dann wird die neue Lösung verwendet. Wird der Fehler größer, wird die neue Lösung verworfen. Am Anfang dieses Zyklus sind die Variationen recht stark, mit jedem neuen Versuch wird allerdings die Variationsbreite etwas verringert.

Abbildung 26: Annäherung des Fehlers

Die Abbildung 26 zeigt die zeitliche Annäherung des Fehlers an das Optimum. Die rote Linie fängt etwa bei 1,8 an und verringert sich schon nach wenigen Permutationen auf einen Wert um 0,6. Der Fehler nähert sich dann an einen Wert um 0,3 an. Wie das Optimum der Kompensation wäre kann durch dieses Verfahren nicht bestimmt werden. Die grüne Kurve zeigt die Variationsbreite der Versuche. Zu erkennen ist, dass am Anfang die Variationsbreite sehr stark schwankt und dann linear abfällt. In diesem Bereich probiert der Algorithmus dann die zufälligen Datenwerte aus und verwendet jeweils immer das beste Ergebnis.


 

Ergebnis

In dem Projekt Daily Activity Monitor wurde zunächst eine Evaulierung über verschiedene Hardwarerealisierungen durchgeführt. Daraufhin wurde eine entsprechende Hardware entwickelt und in die Fertigung gegeben. Leider sind aufgrund von Fehlern in der Fertigung die entwickelten Geräte für eine Praxiserprobung noch nicht geeignet. Die Entwicklung einer Firmware war jedoch möglich. Bei einer erneuten Fertigung wird die Praxistauglichkeit gegeben sein.

Für die Beschleunigungswerte wurde eine umfangreiche Analysesoftware erstellt. Die Analysesoftware hat viele Einstellmöglichkeiten und kann unterschiedliche Analysen durchführen. Die Software arbeitet auch mit dem Funkempfänger des Freescale Demonstrationskits zusammen und kann damit Analysen durchführen. In Abbildung 27 ist beispielsweise das Ergebnis einer nächtlichen Aufzeichnung gezeigt.

Abbildung 27: Bewegungsprotokol über eine Nacht


 

 

Abbildungsverzeichnis

Abbildung 1: Konzeptabbildung Daily Activity Monitor. 3

Abbildung 2: Gesamtaufbau Daily Activity Monitor. 4

Abbildung 3: Testaufbau zur ersten Beschleunigungsmessung. 5

Abbildung 4: Platinenlayout der ersten Beschleunigungsmessung. 5

Abbildung 5: Temperaturmessung mit einer Temperaturdiode. 6

Abbildung 6: Foto des SHT11. 6

Abbildung 7: Schaltplan für Pulsoxymeter. 7

Abbildung 8: Platinenlayout einfaches Pulsoxymeter. 8

Abbildung 9: Herzschlag auf dem Oszilloskop. 8

Abbildung 10: Aufbau Daily Activity Monitor. 9

Abbildung 11: Zustandsmaschine der Firmware. 12

Abbildung 12: Zustandsmaschine des Hauptmessprozesses. 14

Abbildung 13: Messung der Batteriespannung. 15

Abbildung 14: Funktionsweise Ringpuffer. 16

Abbildung 15: Hauptoberfläche der Analysesoftware. 18

Abbildung 16: Datenfluss der Analysesoftware. 19

Abbildung 17: Berechnungsbaum der Analysesoftware. 20

Abbildung 18: Screenshot des FIR Filtergenerators. 22

Abbildung 19: 3D Visualisierung der Beschleunigungswerte. 24

Abbildung 20: Einteilung der Beschleunigungen in Klassifikationen. 25

Abbildung 21: Gesamtbeschleunigung beim Laufen. 26

Abbildung 22: Fourieranalyse der Gesamtbeschleunigung. 27

Abbildung 23: Sensor fällt. 28

Abbildung 24: Sensorbewegungen und resultierende Vektoren. 28

Abbildung 25: Durchschnittswerte der tiefpassgefilterten Beschleunigungswerte. 29

Abbildung 26: Annäherung des Fehlers. 31

Abbildung 27: Bewegungsprotokol über eine Nacht. 32

 

Quellen

[1]    “Ulrich Radig, mikrocontroller and more :: MMC-SD,” MMC-SD.

[2]   Kimberly Tuck, “AN3447.pdf (application/pdf-Objekt),” Implementing Auto-Zero Calibration Technique for Accelerometers, Rev  , 03. 2007.

[3]   R. Barbieri u. a., “A low-power motion capture system with integrated accelerometers [gesture recognition applications],” in Consumer Communications and Networking Conference, 2004. CCNC 2004. First IEEE, 2004, 418-423.

[4]   “BlackmanHarrisWindow.cs - trunk/src/app/MathNet.Neodym/Library/Windowing - Codesuche,” http://www.google.com/codesearch/p?hl=de#NDSnon73r-Q/trunk/src/app/MathNet.Neodym/Library/Windowing/BlackmanHarrisWindow.cs&q=0.53836%20Hamming.

[5]   “Fourier-Transformation – Wikipedia,” http://de.wikipedia.org/wiki/Fourier-Transformation.

[6]   Thomas Schlömer u. a., “Gesture Recognition with a Wii Controller” (University of Oldenburg), http://wiigee.sourceforge.net/download_files/gesture_recognition_with_a_wii_controller-schloemer_poppinga_henze_boll.pdf.  

[7]   Shekhar R. Gaddam, Vir V. Phoha, und Kiran S. Balagani, “K-Means+ID3: A Novel Method for Supervised Anomaly Detection by Cascading K-Means Clustering and ID3 Decision Tree Learning Methods,” Knowledge and Data Engineering, IEEE Transactions on 19, no. 3 (2007): 345-354, doi:10.1109/TKDE.2007.44.  

[8]   Michael Dippold, “Personal Dead Reckoning with Accelerometers,” 2006.  

[9]   Michael Dippold, “Persönliche Positionsbestimmung mit Beschleunigungssensoren” (Fachbereich Informatik/Mathematik - Universität Bremen, 2006), http://auriga.wearlab.de/~midi/leica/Diplom_MiDi.pdf.  

[10]                      Paul Lukowicz u. a., “Recognizing Workshop Activity Using Body Worn Microphones and Accelerometers,” Pervasive Computing, 2004, http://www.springerlink.com/content/bdkmbgv8d57dhbl4.

[11]                      “Schlafstadienanalyse mit HMM,” http://www.rawvision.de/schlafanalyse/#eeg-dia.

[12]                      http://ftp.fmed.uc.pt/pub/OpenBSD/distfiles/sox-12.15.tar.gz

[13]                      http://www.driesen-kern.de/images/sht11cols2.jpg

[14]                      http://de.wikipedia.org/wiki/Drehmatrix