D I P L O M A R B E I T

Akustische Kommunikation in einem

Schwarm von ad hoc Netzwerkknotenbasierend auf der Arduino Prototyping Plattform

vonSascha Friedrich

eingereicht am 30.09.2013 beimInstitut für Angewandte Informatik

und Formale Beschreibungsverfahrendes Karlsruher Instituts für Technologie

Referent: PD Dr. -Ing. Sanaz Mostaghim

Heimatanschrift: Studienanschrift:Brüderstraße 14 Brüderstraße 1475210 Keltern 75210 Keltern

Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig verfasst undkeine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.

Karlsruhe, den 30. September 2013

Inhaltsverzeichnis

1. Einleitung 11.1. Zielsetzung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . 41.2. Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Grundlagen 72.1. Akustik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1. Wellentheorie . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.2. Theorie und Einheiten der Akustik . . . . . . . . . . . . 11

2.2. Unterwassernetzwerke . . . . . . . . . . . . . . . . . . . . . . . . 142.2.1. Multiple Access Protocols . . . . . . . . . . . . . . . . . . 162.2.2. Medium Access Control (MAC) . . . . . . . . . . . . . . 18

2.3. Verwandte Arbeiten und Herangehensweise . . . . . . . . . . . 21

3. Hardware 273.1. Mikroprozessor-Architekturen . . . . . . . . . . . . . . . . . . . 28

3.1.1. ARM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.1.2. x86 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2. Mikrocontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.1. AVR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3. Physical-Computing-Plattformen . . . . . . . . . . . . . . . . . . 323.3.1. Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.2. Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . 373.3.3. Beaglebone (Black) . . . . . . . . . . . . . . . . . . . . . . 42

3.4. Peripherie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4. Realisierung eines akustischen Modems 594.1. Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.1.1. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . 624.1.2. Existierende Lösungsansätze . . . . . . . . . . . . . . . . 634.1.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . 67

4.2. Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.2.1. Alternative Ansätze . . . . . . . . . . . . . . . . . . . . . 744.2.2. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . 75

vi Inhaltsverzeichnis

4.3. Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.3.1. Einrichtung der Softwareumgebung . . . . . . . . . . . . 764.3.2. Hardwareaufbau und Steuerung . . . . . . . . . . . . . . 784.3.3. Softwareimplementierung . . . . . . . . . . . . . . . . . . 814.3.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . 81

4.4. Evaluierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.4.1. Evaluation des akustischen Modem mit Pausen-Verzögerten

Ablauf für die Abtastintervall-Erzeugung . . . . . . . . . 834.4.2. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . 89

5. Anpassung des akustischen Modems für eine bidirektionale Da-tenübertragung im Schwarm 915.1. Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.1.1. Existierende Lösungsansätze . . . . . . . . . . . . . . . . 925.1.2. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . 93

5.2. Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945.2.1. Synchronisierungsalgorithmus . . . . . . . . . . . . . . . 945.2.2. Synchronisierungsimpuls . . . . . . . . . . . . . . . . . . 965.2.3. Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 985.2.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . 100

5.3. Evaluierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.3.1. Synchronisierungs-Algorithmus . . . . . . . . . . . . . . 1015.3.2. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . 104

6. Zusammenfassung und Ausblick 107

A. Anhang 111A.1. Quellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Literaturverzeichnis 143

1. Einleitung

Die heutige Zeit ist gekennzeichnet durch eine stark zunehmende Anzahl vonembedded Geräten in unserem Alltag, die in verschiedenster Art und Weisemiteinander teils lose (ad hoc) oder fest strukturiert vernetzt sind. So ent-stehen mittlerweile Netzwerke, an Orten, an denen vor einigen Jahrzehntenniemand damit gerechnet oder als realisierbar erachtet hätte.

Einen beachtlichen Einfluss auf diese Gegebenheit hat natürlich zum einenMoore’s Law und den sich daraus ergebenden drei Faktoren: Miniaturisie-rung, Kapazitäts-/Leistungssteigerung und Kostensenkung. Vor allem diekostengünstige Produktion von größeren Chargen von Netzwerkteilnehmern,die für den Aufbau von ganzen Schwärmen notwendig sind, trägt ihren Teilzu dieser Entwicklung bei. Da gerade die Anzahl an Teilnehmern eines Sen-sornetzwerkes einen Einfluss auf die zu erledigende Aufgabe hat, ist dies vonVorteil. Zudem werden auch die notwendigen Kommunikationsmodule im-mer günstiger und energiesparender, wodurch der mobile ad hoc Einsatz ver-stärkt in den Vordergrund tritt. Und gerade bei diesem lassen sich feste Netz-werkstrukturen nicht mehr realisieren, sondern man muss ein sich ständigveränderndes, quasi ein lebendiges Netzwerk, handhaben.

Eine Entwicklung, die wohl jedoch erst in den kommenden Jahren verstärktzu tragen kommen wird, ist die Möglichkeit durch gezielte Auslagerung vonSpeicher- und Rechenkapazitäten in eine Cloud, Projekte zu realisieren, diemit recht rudimentären Clients auskommen können. Diese kostengünstigenund somit massenproduktionstauglichen Thin-Clients sind jedoch durch dieNutzung der Cloud sehr leistungsfähig und erzeugen in der Masse gewis-sermaßen einen empathischen Schwarm. Dieser kann durch eine ergänzendezusätzlich zentrale Stelle bei Bedarf ferngesteuert oder um zusätzliche Infor-mationen ergänzt werden.

2 1. Einleitung

Cloud Robotics1 wäre hierfür ein in jüngster Zeit immer öfters angewandterVersuch Roboterplattformen, wie bei einem Software as a Service (SaaS) An-satz, eine Skalierung der Rechen- und Speicherleistung möglich zu machen.Dies kann natürlich nicht nur für ein einzelnes Individuum, sondern auch imMaßstab eines Schwarms genutzt werden.Naturgemäß können Echtzeitentscheidungen durch die sich resultierendenNetzwerklatenzen nicht ausgelagert werden. Hier vermögen jedoch die Thin-Clients, und hier insbesondere diejenigen, die mit einem Mikrocontroller aus-gestattet sind, ihre volle Stärke als reflex-basierte (für sehr schnelle und schwer-wiegende Entscheidungen) oder einfache Echtzeit-Entscheider auszuspielen.Diese Dynamik basiert auf dem schnellen Auslesen von Sensorwerten und derRegulation von Aktoren. Offline-Learning-Anwendungen wiederum sind da-für prädestiniert in die Cloud verschoben zu werden, da sie nicht zeitkritischzu handhaben sind und rechen- und speicherintensiv gestaltet sein können.

Ein weiterer Trend, der zu einem verstärkten Netzwerkausbau in den ver-schiedensten Bereichen führt, ist das Phänomen der Physical-Computing-Plattformen, welche einerseits einen schnellen Prototypen-Aufbau gewährleis-ten, andererseits durch ihre leichte Handhabung und Erweiterbarkeit eineVielzahl von Mashup-Lösungen ermöglichen. Neben anerkannten Institutio-nen wie die NASA, dem MIT, et cetera nutzen auch Hobbyisten, Start-Upsund Unternehmen die vielfältigen Möglichkeiten dieser Plattformen. Zudembieten diese einfache und schnelle Baukasten-Lösungen, die vergleichbar mitdenen von Lego NXT und dergleichen sind. Auch im Rahmen dieser Diplom-arbeit nutzen wir eine kostengünstige und flexible Systemlösung.

Jedoch was ist zwingend notwendig für einen Schwarm? Das wäre die Kom-munikation bzw. die Abstimmung mit anderen Teilnehmern, die zum jetzi-gen Zeitpunkt hauptsächlich über elektromagnetische Funk- oder Infrarot-Transceiver gewährleistet wird. Eine Ausnahme hierzu bilden Räumlichkei-ten, die wie ein Faraday-Käfig aufgebaut sind, das wären zum Beispiel Kup-ferrohrleitungen, die eine elektromagnetische Abschirmung verursachen oderder Einsatz unter Wasser, der durch die starken Dipol-Kräfte der Wassermo-leküle, die durch einen zu hohen Dämpfungsfaktor, die elektromagnetischeÜbertragung ineffizient machen.Des weiteren, wie schon in den Absätzen zuvor erwähnt, nimmt die Anzahlder netzwerkfähigen Endgeräte immer stärker zu, und verursacht dadurcheine immer höhere Client-Dichte, welche zur Folge hat, dass dieser Übertra-gungskanal immer mehr Störungen unterliegt und an seine Grenzen stoßenkann. Somit ist ein alternativer Einsatz über akustische Signale erwägenswert,davon abgesehen, dass gerade akustische Übertragung in den eben genanntenUmgebungen wie Faraday-Käfige und Unterwasser ohne größere Problemeeinsetzbar wäre.

1Interessante Informationen hierzu findet man in [QuMD11]

3

Aus den vorherigen Passagen sollten sich folgende wichtigen Punkte heraus-kristallisiert haben:

• Homogene und heterogene Schwärme werden immer einfacher, un-komplizierter und kostengünstiger zu realisieren, beziehungsweise tre-ten durch die inzwischen allgegenwärtige Vernetzung von Endgerätenautomatisch auf und können für Schwarmalgorithmen genutzt werden.

• Eine Skalierung der Speicher- und Rechenleistung durch die Nutzungeiner Cloud und Thin/Rich-Clients fördert das Auftreten von Schwär-men und erweitert deren Einsatzbereich.

• Gerade Physical-Computing-Plattformen ermöglichen einen schnellenund kostengünstigen Aufbau eines mobilen ad hoc Netzwerkes, der fle-xibel erweiterbar ist. Zudem können schon vorhandene Offline-Gerätedurch Physical-Computing-Plattformen unproblematisch in ein beste-hendes oder neu aufzubauendes Netzwerk integriert werden.

• Die anzutreffenden Netzwerke werden immer mobiler und besitzen meisteinen ad hoc multihop Charakter.

• Eine terrestrische Umgebung unterliegt einer immer höheren Client-Dichte an elektromagnetisch orientierten Akteuren, die sich ein Über-tragungsmedium (Luft) teilen müssen. Dies macht alternative Übertra-gungskanäle immer interessanter, auf die bei Engpässen oder Störungenausgewichen werden kann.

• Es gibt Umgebungen, bei denen von vornherein eine elektromagnetischeÜbertragung auszuschließen ist.

All diese Punkte tragen zu der Motivation bei, ein ad hoc Netzwerk in Schwarm-größe zu konzipieren, dass durch eine Physical-Computing-Plattform reali-siert werden soll. Dadurch soll es auch möglich sein, bestehende Projekteum Schwarminteraktion erweitern zu können und unkompliziert und schnellneue ad hoc Netzwerke mit Physical-Computing-Plattform-Eigenschaften zuermöglichen.Um hierbei alternative Wege zu bestreiten, wird statt Funk, die akustischeÜbertragung gewählt, die für bestimmte Umgebungen, wie elektrisch leiten-de Rohrleitungen oder Unterwasser, ohnehin zu präferieren ist. Des weiterensollte nicht außer Acht gelassen werden, dass zum Zeitpunkt der Erstellungdieser Diplomarbeit der Großteil der vorhandenen Roboter zwar über akusti-sche Transceiver, meist in Form von Ultraschall-Abstandsmessern, verfügen,jedoch ein Funkmodul nicht zwangsläufig integriert sein muss. Somit kannein bereits existierender Roboter, der mit einer Ultraschall-Messeinheit (einTyp, wie er in dieser Diplomarbeit verwendet wird) ausgestattet ist, ohneweitere Kosten oder Hardwareaufwand, um ein Kommunikationsmodul er-weitert werden.

4 1. Einleitung

1.1. Zielsetzung der Arbeit

Das Ziel dieser Arbeit ist die Ausarbeitung eines akustischen Schwarmnetz-werkes, wobei hier die Implementation eines physischen akustischen Modemsfür eine uni-direktionale Datenübertragung zwischen zwei Netzwerkknotenerstellt werden soll. Für auf dieser Diplomarbeit aufbauenden Arbeiten, sollzudem ein Konzept für die Implementation eines MAC-Protokolls für einenbidirektionale Datenübertragung in einem ad hoc Schwarmnetzwerk konzi-piert werden. Dieser Schwarm aus Netzwerkknoten soll, wie auch das Mo-dem, zudem durch die Arduino Physical-Computing-Plattform realisiert wer-den. Dieses Schwarmnetzwerk soll auf Basis von akustischen Transceivern ei-ne Alternative zu bereits vorhandenen elektromagnetischen Netzwerken dar-stellen und für den Einsatz in Faraday-Käfig ähnlichen Umgebungen, sowiedurch Impedanzanpassung des Transceiver-Moduls, den Unterwassereinsatzermöglichen.

Hierbei soll vor allem durch die Verwendung einer Physical-Computing-Plattform sicher gestellt werden, dass in kürzester Zeit ein Schwarmnetzwerkaufgebaut werden kann und zukünftige Updates und Upgrades sich leichtbewerkstelligen lassen.

Das zu entwickelnde ad hoc Schwarmnetzwerk ist von den sonst üblichen Da-tennetzwerken insoweit abzugrenzen, dass Schwarm-Algorithmen innerhalbdes Netzwerkes zum Tragen kommen sollen und daher keine direkte globa-le Adressierung von einzelnen Individuen im Schwarm vorgesehen ist2. DieKommunikation findet somit auf Basis von lokalen Broadcasts und mittelslokal direkt adressierten Übertragungen mit den unmittelbar benachbartenEinheiten statt.

Des weiteren sind pure Sensordatenübertragungen zu einer zentralen odermultiplen Stellen vorgesehen, die wiederum ihrerseits Synchronisierungssi-gnale an den kompletten Schwarm wiedergeben können. Wir bedienen unshier dem Beispiel aus der Natur, dass in Schwarm-Kolonien, zum Beispiel beiAmeisen, es verschiedene Gruppen mit unterschiedlichen Fähigkeiten und Be-fugnissen gibt. So gibt es bei den Ameisen nicht nur Sammler und Arbeiter,sondern auch Wächter und eine Brutmutter. Auch in unserem Schwarm sindverschiedene Gruppen mit unterschiedlichen Fähigkeiten und Aufgaben vor-gesehen. So soll es Synchronisierungs-Knoten geben, die beispielsweise miteinem GPS-Modul ausgestattet sind, das eine genaue Zeitwiedergabe ermög-licht. Diese Knoten dienen dem Schwarm als Taktgebern für eine synchroneZeitsteuerung der einzelnen Knoten. Außerdem sollen diese Knoten als Emp-

2Damit ist gemeint, dass die Adresse und die Existenz von Knoten, die nicht in unmittelbarerNachbarschaft vorhanden sind, dem Sender unbekannt sind und somit nicht von diesemdirekt angesprochen werden können.

1.2. Gliederung der Arbeit 5

fangsstationen, wie in der Unterwasserakustik weit verbreitet, als Funksendermit höheren Reichweiten zur Basisstation an Land, eingesetzt werden.

Als Ziele für diese Diplomarbeit sind folgende Punkte vorgesehen:

1. Als erstes zu verwirklichendes Ziel ist die Erstellung eines Akustik-Modems, um das Transceiver-Modul der Netzwerkknoten, als auch dieakustische Übertragung als solches zu testen und zu untersuchen.

2. Als zweites Ziel ist die theoretische Betrachtung eines Netzwerkes vonmehr als zwei Teilnehmern vorgesehen, die sich ein Übertragungsme-dium teilen müssen. Hierzu muss ein Multi-Access-Protokoll aus derUnterwasserakustik dem terrestrischen Umfeld entsprechend angepasstund konzipiert werden, um in darauf aufbauenden Arbeiten die Soft-ware der Netzwerkknoten den neuen Nebenbedingungen (Interferen-zen durch gleichzeitige Übertragung von mehreren Netzwerkknoten imgleichen Empfangs- und Senderadius) anzupassen.

Hierdurch kann, auf dieser Diplomarbeit aufbauend, ein akustisches ad hocNetzwerk auf Basis der Arduino Physical-Computing-Plattform implemen-tiert werden. Dieser Prototyp eines physischen Schwarms kann darauf fol-gend für weitere Untersuchungen verwendet werden.

1.2. Gliederung der ArbeitWir werden in Kapitel 2 die Grundlagen, die für den Aufbau dieser Arbeitbenötigt werden, abhandeln.Im ersten Unterkapitel 2.1, das sich zuerst mit den physikalischen Grundlagender Akustik auseinandersetzt, wird eine kurze Auffrischung bzw. eine grobeZusammenfassung, der für diese Arbeit wichtigen physikalischen Begeben-heiten, die im späteren Projektverlauf eine Rolle spielen, geboten.Ein Haupteinsatzgebiet akustischer Netzwerke und somit eine Quelle vie-ler schon vorhanden Lösungsansätze, Herangehensweisen, Konzeptionen undAnalysen reiht sich mit Unterkapitel 2.2 Unterwassernetzwerke in die Folgeein. Hier wird näher auf den grundsätzlichen Aufbau, den Problemen undLösungsansätzen der akustischen Netzwerke eingegangen und dient diesemProjekt als Hauptangelpunkt.Hierbei stellen die verschiedenen Netzwerkprotokolle eine entscheidende Rol-le dar und sind daher in den Unterkapiteln 2.2.1 und 2.2.2 detailliert beschrie-ben.

Hierbei nutzen wir die Erfahrungswerte aus der Unterwasser-Akustik undgehen näher auf schon bestehende Lösungsvarianten in Unterkapitel 2.3 ein.

Zum Abschluss der Grundlagen wird in Unterkapitel 3 das notwendige Fach-wissen für die spätere Auswahl und der Arbeit mit den verwendeten Hard-warekomponenten und möglichen Alternativen beleuchtet.

6 1. Einleitung

Nachdem die Grundlagen im vorherigen Kapitel abgehandelt wurden, wid-met sich Kapitel 4 der Erstellung eines akustischen Modems.Die Gliederung des Kapitels ist der wissenschaftlichen Arbeitsweise ange-passt und besteht aus den folgenden Unterkapiteln: 4.1 Analyse, 4.2 Entwurf,4.3 Implementierung und 4.4 Evaluierung.

Nach erfolgreicher Erstellung eines akustischen Transceiver-Moduls, beschreibtKapitel 5 die notwendigen Schritte für die Entwicklung eines komplettenakustischen Schwarmnetzwerkes, dass vor allem durch das verwendete Multi-Access-Protokoll gekennzeichnet ist. Auch hier spiegeln die Unterkapitel, wiein Kapitel 4 die methodisch klar strukturierte wissenschaftliche Arbeitsweisewider.

Zum Abschluss wird in Kapitel 6 das Resümee der vorgestellten Arbeit undein Ausblick für den Einsatz, den Erweiterungsmöglichkeiten und ein Anstoßfür mögliche weiteren Untersuchungen gegeben.

2. Grundlagen

In diesem Kapitel werden wir den grundlegenden theoretischen Hintergrundfür den Aufbau eines akustischen Schwarms erläutern. Hierbei werden wirin Kapitel 2.1 die für uns verfügbare Frequenzspektrum für die Nutzung ineinem akustischen Schwarmnetzwerkes und den jeweiligen Charakteristikader jeweiligen Frequenzbereiche näher beschreiben. Darauf erläutern wir inKapitel 2.1.2 die wichtigsten wellentheroetischen Grundlagen, sowie Begriff-lichkeiten und sehen in Kapitel 2.1.2 anschließend noch gezielter auf die füruns wichtigen Schallwellenparameter ein.

Nachdem die Grundlagen der Akustik beschrieben wurden, können wir inKapitel 2.2 uns der für uns wichtigen Unterwassernetzwerken widmen unduns näher damit auseinandersetzen warum gerade in dem Medium Wasserdiese Art von Netzwerk eine so entscheidende Rolle für die Forschung undfür praktische Anwendungen spielt. Diese haben auf unsere Diplomarbeit in-sofern einen wichtigen Einfluss, da wir sie als Grundlage für unseren terrestri-schen akustischen Schwarm zu einem erheblichen teil als Vorlage heranziehenwerden. Hier werden wir vor allem auf die zur Verfügung stehenden Protokol-le für den Mehrfachzugriff in Kapitel Unterkapitel 2.2.1 und in Unterkapitel2.2.2 der Medienzugriffssteuerung (MAC) und der möglichen Verwendung ineinem akustischen Netzwerk beschreiben.

Als letztes Protokoll in dieser Analyse in 2.2.2 werden wir uns sehr genau dasFAMA-Protokoll anschauen, das wir in in letzten Unterkapitel 2.3, das sichmit den herangezogenen Arbeiten unserer Diplomarbeit und dem generellenVorgehen unserer Verwirklichung eines akustischen Schwarms erläutern wer-den, um eine Synchronisation-Variante, dem Slotted-FAMA erweitern. Die-ses Protokoll bildet die Grundlage für die Kommunikation von abschließendmehreren Knoten in einem akustischen Netzwerkes.

8 2. Grundlagen

2.1. AkustikDa wir für unser Projekt eine alternative Übertragungsform, die Akustik,wählen, werden wir in den folgenden Unterkapiteln grob die wichtigstenInformationen aufbereiten, die für den Aufbau eines akustischen Schwarm-Netzwerkes von Bedeutung sind.Das wären im Einzelnen die generellen wellentherotischen Begrifflichkeitenbezüglich der Form und Ausbreitung einer Druckwelle in Unterkapitel 2.1.1und deren energetischen Eigenschaften in 2.1.2. Zuvor werden wir noch dasSchallspektrum mit seinen unterschiedlichen Frequenzbändern erläutern.

Die Frequenzbänder in der Akustik werden hauptsächlich in drei Abschnit-te untergliedert. Wie aus Abbildung 2.1 ersichtlich wird, sind das im Bereichunter 20 Hz der Infraschall, den Menschen nicht wahrnehmen können, sowieim Intervall zwischen 20Hz und 20kHz der hörbare Bereich, den wir Menschenwahrnehmen und somit für Datenübertragungszwecke unbedingt zu vermei-den ist. Hierauf folgt mit über 20kHz der Ultraschallbereich, der außerhalbder menschlichen Wahrnehmungsschwelle liegt und für unsere Zwecke ge-nutzt werden kann.

In Kapitel 3.4 werden wir bei der Beschreibung des von uns genutzten Ul-traschallsensors weiter auf die dadurch bedingte Richtungscharakteristik undweiteren Eigenschaften näher eingehen. Wir werden nun jedoch kurz die be-reits erwähnten Frequenzbereiche charakterisieren, um auf die damit verbun-denen Störquellen und Besonderheiten für unser Projekt einzugehen.

Abbildung 2.1.: Akustische Frequenzbereiche [Wiki13g]

Infraschall: Infraschall wird von vielen Tieren wahrgenommen, da viele zer-störerische Ereignisse, wie beispielsweise Gewitter, Vulkanausbrüchen undErdbeben damit verbunden sind. Somit stellt die Wahrnehmung dieser Früh-signale evolutionsbiologisch einen Vorteil dar. Beispielsweise können Brieftau-ben und Elefanten diese niederfrequenten Schallwellen wahrnehmen, und imFall von den Dickhäutern sogar initiiert werden. In Bezug auf Brieftaubenwerden diese niederfrequenten Wellen, durch Wasserwellen tief im Ozeanerzeugt und über weite Distanzen bis in die Atmosphäre übertragen. DieseUltraschalltöne werden als akustischer Marker eingesetzt und zur Navigati-on herangezogen1. Durch die geringe Absorption dieses Frequenzspektrums,

1Nähere Informationen findet man in [KrQu79]

2.1. Akustik 9

ähnlich wie bei elektromagnetischen Radiowellen, können diese erstaunlicheDistanzen zurücklegen. Eine Reichweitenerhöhung kann zudem durch Schall-kanäle erreicht werden, wenn kühlere Luftschichten mit weniger Turbulenzen,eine bis zu dreifache Erweiterung ermöglichen2. Zudem weißt dieses Fre-quenzband, wie wir in Kapitel 3.4 näher beschreiben werden, eine wenigerrichtungsabhängige Ausbreitung auf.Da der Infraschall von Tieren wahrgenommen werden kann, muss im Einzel-fall geprüft werden, inwieweit diese Frequenzen für eine Datenübertragungausscheiden. Der Mensch kann hier als Faktor ausgeschlossen werden.

Hörbarer Bereich: Hier wird eine Richtungscharakteristik mit steigender Frequ–enz immer ausgeprägter, welche immer noch deutlich geringer ist als im Ul-traschallbereich. Da hier der Mensch mit in die Betrachtung für die Daten-übertragung einbezogen werden muss, scheidet dieser Bereich für unser akus-tisches Schwarmnetzwerk aus, es sei denn man will dem Menschen Informa-tionen in Form von Warntönen oder besonderen Zuständen des Schwarmszukommen lassen.

Ultraschallbereich: Ultraschall wird von einigen Tieren, wie beispielsweiseDelphinen, Hunden und vor allem nachtaktiven Tieren wie Fledermäuse wahr-genommen. Hier müssen die Einsatzbereiche und Frequenzen der jeweiligenSituation angepasst werden. Diese sind in Bezug auf den Menschen jedochaußerhalb der Wahrnehmungsschwelle und somit für das Projekt nutzbar.Durch die hohen Frequenzen wird allerdings eine deutliche Richtungscharak-teristik sichtbar und zudem die Reichweite durch erhöhte frequenzabhängigeDämpfung gemindert.Wiederum bedeuten hohe Frequenzen für unseren akustischen Schwarm ho-he Bitraten, was in einem Schwarm von essentieller Bedeutung ist, bei dembeträchtlicher Overhead durch die vielen Einheiten verursacht wird, und so-mit für eine gute Funktionsweise erforderlich ist.

Daher ist abschließend zu sagen, dass ein gewisser Tradeoff zwischen Bitrateund Richtungscharakteristik bei der von uns für die akustische Kommunika-tion ausgewählten Frequenz eingegangen werden muss. Umgangen werdenkann die Richtungsabhängigkeit durch die Anbringung mehrerer Schallwand-ler, die jeweils außerhalb des Interferenzbereiches der Anderen liegen. 3 Eineandere Möglichkeit wäre durch zeitlich seriell geschaltete Schallwandler dieszu bewerkstelligen. Daraus resultieren allerdings auch ein höherer Komplexi-tätsgrad für die Kommunikation, ein damit verbundener höherer Energiever-brauch sowie eine größere Fehleranfälligkeit.

2Weitere Informationen hierzu können in der, von der National Geographic gefördertenForschung, in dem Paper [GLRL95] entnommen werden.

3In Kapitel 3.4 beschreiben wir dies anhand des Halbwertswinkels.

10 2. Grundlagen

2.1.1. Wellentheorie

Die folgende Abbildung 2.2 zeigt eine typische Sinuswelle mit ihren Eigen-schaften. Auf Basis dessen, werden wir die in diesem Abschnitt die für unsessentiellen Variablen/Parameter für die Diplomarbeit erläutern.

Abbildung 2.2.: Sinus-Welle

Die folgenden Definitionen sind aus [Frie08] entnommen:

• Amplitude (A): ’Die Amplitude ist das Mass für die Starke der Schwin-gung. In der Hörwelt klingen starke Schwingungen gleicher Frequenzlauter als schwache. Die Amplitude hat keinen Einfluss auf die Fre-quenz.’

• Phase (φ): ’Der dritte Parameter einer Schwingung ist die Phasenlage.Sie ist interessant im Zusammenhang mit anderen Schwingungen undgibt an, um welchen Grad die Schwingungen gegeneinander verscho-ben sind. Zwei Schwingungen sind in Phase, wenn der Kurvenverlaufübereinstimmt, also die Maxima und die Nulldurchgänge zum selbenZeitpunkt stattfinden. Gegenphasige Signale haben zur selben Zeit Null-durchgänge, wahrend am Scheitelpunkt die eine Schwingung ihren po-sitiven Maximalwert, die andere ihren negativen erreicht. Angegebenwird die Phasenlage in Grad. 0◦ bedeutet gleichphasige, 180◦ gegenpha-sige Signale. Eine Phasenverschiebung von 90◦ weist auf unkorrelierte- das heißt voneinander unabhängige - Signale hin. Die Phasenlage istentscheidend, wenn es um Überlagerungen von Schallwellen, die soge-nannten Interferenzen geht.’

• Wellenlänge (λ): ’ Die Wellenlänge ist der Weg, den der Schall wahrendeiner Periodendauer zurücklegt. In der Luft liegen die Wellenlängen der

2.1. Akustik 11

hörbaren Frequenzen zwischen 17 m und 17 mm.’

• Periode (T): ’Die Form einer solchen idealen Schwingung ist sinusfor-mig. Visualisieren lasst sich so etwas durch ein Masse-Feder-Pendel, dasauf und ab schwingt. Befestigt man einen Stift an der Unterseite, der diemomentane Auslenkung auf ein Blatt Papier zeichnet, das mit konstan-ter Geschwindigkeit vorbeiläuft, ergibt sich die Sinuskurve. Der Schwin-gungsverlauf wiederholt sich periodisch, solange die Schwingung nichtgebremst wird. Die Zeit, in der eine solche Schwingungsperiode durch-laufen wird, nennt man Periodendauer.’

• Frequenz (f): Die Anzahl Schwingungen pro ’Sekunde ist die Frequenz.Die Einheit der Frequenz ist das Hertz (Hz),[...]’

• Geschwindigkeit (v):’Je nach Medium breitet sich der Schall unterschiedlich schnell aus. DieSchallgeschwindigkeit c in Luft liegt für normale Temperaturen bei et-wa 343 m/s. Aus der Schallgeschwindigkeit lasst sich die Wellenlänge λ(sprich lambda) ableiten.’

• Wellenzahl (k): Die Wellenzahl ist der Quotient aus 2π und λ.

Diese Variablen stehen in folgenden Beziehungen zueinander:

f =1T

(2.1)

λ = v · T (2.2)

k =2π

λ(2.3)

2.1.2. Theorie und Einheiten der Akustik

Eine für uns wichtige Größe für die akustische Datenübertragung ist die mög-liche maximale Reichweite, die wir erzielen können und der Einfluss von Ma-terialien auf die Wellenausbreitung. Da Schallwellen keine Materie übertra-gen, nachdem die Partikel nur um die Gleichgewichtslage schwingen, wirdEnergie durch Schwingungsanregung jeweils benachbarter Moleküle erzeugt.Je nach Kopplung dieser Moleküle kommt es zu einer schnelleren oder lang-sameren Ausbreitung in einem Material. Die Wellen werden als Longitudina-le Wellen bezeichnet und sind gekennzeichnet durch Dichte-Schwankungen

12 2. Grundlagen

entgegen und mit der Ausbreitungsrichtung im Medium. Dagegen abzugren-zen wären Transversale Wellen, die beispielsweise bei Wasser-Oberflächen-wellen vorkommen. Im Gegensatz zu Longitudinalen Wellen, werden hier dieMoleküle rechtwinklig zur Ausbreitungsrichtung zur Schwingung angeregt.Für uns sind in diesem Zusammenhang im Wesentlichen diese Werte von Be-deutung: Schalldruck, Schallschnelle, Relativer Schalldruckpegel, Schall-leistung, Schallleistungspegel, Kugelwelle, Schallintensität und Nahfeld/-Fernfeld.

Die folgenden Definitionen sind [Frie08] entnommen:

Schalldruck (p): ’Er tragt das Formelzeichen p von pressure und wird in Pas-cal (Pa) angegeben.[...] Der Schalldruck ist ortsabhängig. Je weiter man sichvon der Schallquelle entfernt, desto geringer ist der Schalldruck. Er halbiertsich mit jeder Verdopplung der Entfernung. Der Schalldruck ist durch dieSchwingung nicht konstant. Deshalb wird auch nicht sein Spitzenwert ver-wendet, sondern der Effektivwert. Der Effektivwert entspricht dem Wert, denein unveränderliches Signal mit denselben Eigenschaften - in diesem Fall den-selben Druck - hatte. Bei Sinusschwingungen berechnet man den Effektivwert,indem man den Spitzenwert durch

√2 dividiert. Das Verhältnis von Spitzen

zu Effektivwert nennt man auch den Crest-Faktor.’

Schallschnelle (v): ’Die mittlere Geschwindigkeit, mit der sich die Luftmole-küle um ihren Ruhepol bewegen ist die Schallschnelle v. Sie hat nichts mit derSchallgeschwindigkeit zu tun sondern liegt bei unter einem Millimeter proSekunde. Sie steigt mit zunehmender Lautstärke an.’

Relativer Schalldruckpegel (Lp): ’Der große Wertebereich der hörbaren Schall-drücke ist für die tägliche Arbeit zu unübersichtlich. Außerdem wird siedem Gehör nicht gerecht. Das Weber-Fechnersche Gesetz besagt, dass dieWahrnehmungsorgane eine Reizverstärkung nicht linear, sondern nur loga-rithmisch übertragen[...]. Daher bietet sich ein logarithmisches Verhältnismaßan, um Schalldruckdifferenzen auszudrücken. Das ist der Schalldruckpegel.Um zwei Schalldrücke miteinander in Beziehung zu setzen, kann anstelle derHörschwelle auch jeder andere Schalldruck als Referenzwert p0 verwendetwerden. Die Einheit dieses relativen Schalldruckpegels ist das Dezibel (dB).6dB entsprechen einer Verdopplung oder Halbierung des Schalldrucks, 20dB dem Zehnfachen. Durch die Ortsabhängigkeit des Schalldrucks sinkt derSchalldruckpegel um 6 dB mit jeder Verdopplung der Entfernung.’

Schallleistung (Pak): ’Im Gegensatz zum Schalldruck ist die Schallleistungortsunabhängig. Sie beschreibt eine Eigenschaft der Schallquelle, nämlich dieMenge an Schallenergie, die pro Zeiteinheit abgestrahlt wird. Diese akustischeLeistung Pak hat die Einheit Watt (W).’

2.1. Akustik 13

Schallleistungspegel (LW): ’Der Schallleistungspegel ist ein logarithmischesMaß zur Beurteilung von Schallleistungen im Verhältnis zur Referenz von P0= 10−12W. Seine Einheit ist das Dezibel. Er wird wie folgt berechnet:

LW = 10 lgPP0

(2.4)

’

Kugelwelle: ’Man unterscheidet Kugelwellen von ebenen Wellen. Kugelwel-len werden von Punktschallquellen erzeugt, ebene Wellen von Flächenstrah-lern, die aber in der realen Welt kaum und wenn dann nur für hohe Fre-quenzen vorkommen. Statt dessen nähert sich eine Kugelwelle mit steigenderEntfernung einer ebenen Welle an. Nahe der Schallquelle ist die Krümmungder Kugelwelle noch sehr stark, mit steigendem Durchmesser wird sie aberimmer schwächer, so dass man in einiger Entfernung von einer ebenen Wel-lenfront sprechen kann.’

Dieser Approximation werden wir uns in 3.4 für die Herleitung der Impedanzbedienen.

Schallintensität (I): Die Schallintensität ist die Schallleistung dividiert durchden Flächeninhalt. Diese Größe ist somit im Gegensatz zur Schallleistung ent-fernungsabhängig und ist im Fall einer Kugelwelle durch eine veränderteOberfläche abhängig vom jeweiligen Radius. Bei einer ebenen Welle ist daswiederum nicht der Fall, da hier die Fläche konstant bleibt.

Für eine Punktschallquelle (Kugelwelle) gilt:

I =PakA

=Pak

4πr2 =⇒ I ∼ 1r2 (2.5)

Diese Abnahme der Energie/Flächeneinheit führt, wie die Absorption, zureiner Amplitudenminderung und beschränkt damit die effektive Reichweitefür unsere Datenübertragung.

Nahfeld/Fernfeld: ’Das Nahfeld bezeichnet einen Abstand zur Schallquellebis etwa zur halben Wellenlänge. Darüberhinaus gelten Fernfeldbedingungen.Im Fernfeld sind Schalldruck und Schallschnelle gleichphasig.’

Abbildung 2.3 zeigt den Nahbereich und den sich langsam annähernden Fern-bereich, mit einer gemeinsamen Wellenfront. Wie aus dieser Abbildung er-sichtlich wird, ist mit Interferenzen im Nahbereich zu rechnen. Im Fernbereichwiederum können durch die Verwendung mehrerer Schallquellen ebene Wel-len angenommen werden. Phasenunterschiede im Nahfeld wirken sich hierauf die Schallschnelle aus, indem sie zu einer ∝ 1

r2 Berechnung, anstatt einer∝ 1

r dieser führen. Dadurch sinkt auch die Schallschnelle im Nahbereich mit1r2 und im Fernbereich nur noch um 1

r für eine Kugelwelle.

14 2. Grundlagen

Nach [Frie08] erfolgt die ’[...]Schallausbreitung [...] in der Realität immer ge-richtet. Die Punktschallquelle und ihre kugelförmige Schallabstrahlung ist einidealisiertes, theoretisches Modell.’

Dies hat auf unsere Arbeit insofern Einfluss, da wir keine kreisförmige Si-gnalübermittlung mit nur einem Sender bewerkstelligen können. Wir müssendaher mehrere Transceiver-Module nutzen, oder uns die Richtungscharakte-ristik zu Nutze machen.

Abbildung 2.3.: Hier sind, sich langsam bildende, ebene Wellenfronten amrechten Rand zu sehen. Die ganze Abbildung zeigt den Nah-bereich, da für die zusätzliche Darstellung des Fernbereichs,eine sonst viermal so breite Abbildung gezeichnet werdenmüsste. [Wiki13d]

2.2. UnterwassernetzwerkeLaut [SoSP00a] ist ein Unterwassernetzwerk wie folgt gekennzeichnet: ’Un-derwater acoustic networks (UAN) are generally formed by acoustically connec-ted ocean-bottom sensors, autonomous underwater vehicles, and a surfacestation, which provides a link to an on-shore control center.’ Ein Unterwas-sernetzwerk hat den Throughput zu maximieren, ebenso zuverlässig zu funk-tionieren und den Energieverbrauch zu minimieren, da ein Austausch oderein Wiederaufladen der vorhandenen Energiespeicher Unterwasser mit hohenBergungskosten auf See verbunden ist. In den frühen Jahren der Unterwasser-forschung wurden Sensoren am Meeresboden und in verschiedenen Schichtendes Meeres verankert. Diese Sensoren konnten ihre gesammelten Daten nurspeichern und nicht an die Oberfläche übermitteln, so war man daran ge-bunden, dass die Sensoren absolut zuverlässig funktionsfähig waren. Da diesnaturgemäß nicht immer gewährleistet werden kann, kam es des öfteren zuunbrauchbaren Daten, die zudem erst nach Wochen oder Monaten entdecktwurden. Um dies zu umgehen, musste nach einer Lösung für dieses Problemgesucht werden. Da im Wasser, jedoch wegen den wirkenden Dipolkräften der

2.2. Unterwassernetzwerke 15

Wassermoleküle, die Absorptionsrate, wie in Abbildung 2.4 ersichtlich ist, imBereich bis 100MHz einen viel zu großen Wert für eine energieeffiziente Da-tenübertragung darstellt musste man eine andere Übertragungsform suchen.Diese ist die akustische Schallübermittlung. In Abbildung 2.4 sieht man dendeutlich geringeren Absorptionskoeffizienten für Schallwellen im Vergleichzu elektromagnetischen Wellen.

Abbildung 2.4.: Vergleich der Dämpfungswerte für EM und Schallwellen[LeSW09]

Die Topologie eines typischen UAN kennzeichnet sich durch einen ad hocmulti-hop-Charakter. Diese Netzwerke haben einen hierarchischen Aufbau,da als zentraler Hub ein Oberflächensender, der neben eines akustischen Mo-dems auch einen Funksender für die Datenübertragung ans und vom Festlandintegriert hat, eingebunden ist. Ein Nachteil dieses Aufbaus ist die geringereRobustheit bei Ausfall des Hubs, was jedoch durch redundante Hubs kom-pensiert werden könnte. Die Reichweite der verwendeten akustischen Mo-dems wird auf ein Minimum angesetzt, damit möglich wenige Interferenzendurch Überlagerung mehrerer Signale entstehen können. Zudem wäre einedirekte Kommunikation aller Knoten miteinander energetisch wenig sinnvollund wird daher durch eine multi-hop-Verbindung realisiert. Zudem würdeder Versand zu einem sehr weit entfernten Knoten die Datenübertragungvon anderen Knoten in der Nachbarschaft blocken und zu einem geringerenThroughput führen. Dieses Problem wird als Nah-Fern-Problem bezeichnet.Der große Nachteil eines multi-hop-Ansatzes ist andererseits eine vergrößerteLatenz, die bei der Akustik durch die deutlich niedrigeren Geschwindigkeitenals bei elektromagnetischen Wellen ohnehin sich schon nachteilig auswirkt.Da in UAN jedoch der Energieverbrauch eine höhere Gewichtung, als die La-tenz einnimmt, wird der multi-hop Charakter präferiert.

16 2. Grundlagen

Abbildung 2.5.: Network topology of an UAN [SoSP00a]

2.2.1. Multiple Access Protocols

In vielen Netzwerken ist der Datenverkehr durch stoßweisen Versand von Da-tenpaketen gekennzeichnet, wobei die meiste Zeit das System als solches sichin Ruhezustand befindet. Da die Bandbreite bei UAN ein wertvolles Gut dar-stellt und das Übertragungsmedium für alle Knoten zugänglich ist, muss dieverfügbare Zeit und die nutzbaren Frequenzen effizient für die Datenübertra-gung eingeteilt werden. Da wir uns, wie Unterwasser im terrestrischen miteinem Mehrfachzugriff-Medium auseinandersetzen müssen, werden wir inden folgenden Abschritten auf die drei wichtigsten Multiple Access Protocolsnäher eingehen. Dies wären der Reihenfolge nach Frequency Division MultipleAccess (FDMA), Time Division Multiple Access (TDMA) und Code Division Mul-tiple Access (CDMA).

Frequency Division Multiple Access (FDMA): bei diesem Protokoll für denMehrfachzugriff auf ein Medium wird die verfügbare Bandbreite in mehre-re Teilbänder untergliedert. Ein spezifischer Kanal, mit einer verbundenenFrequenz ist hier ausschließlich für einen Netzwerkknoten zu einer bestimm-ten Zeit nutzbar, bis dessen Übertragung beendet wurde. Bei diesem Proto-koll müssen leistungsstarke Filter genutzt werden um die unterschiedlichenFrequenzen voneinander abgrenzen zu können. Dafür gibt es hier nicht dasNah-Fern Problem, wie wir es in Kapitel 2.1.2 angesprochen haben und zu-dem muss keine aufwendige Synchronisierung wie bei TDMA implementiertwerden. Hier ist jedoch die vorhandene Bandbreite, die man für die verschie-

2.2. Unterwassernetzwerke 17

denen Kanälen nutzen kann von entscheidender Bedeutung. Da die Frequenzwährend der Übertragung nicht verändert werden kann, ist man auf einenstörungsfreien Kanal angewiesen.

Time Division multiple access (TDMA): Hier wird im Gegensatz zu FDMAnicht die Bandbreite in Subkanäle untergliedert, sondern ein vorgegebenesZeitfenster (Frame) in mehrere Zeitintervalle (Slots) eingeteilt. Jeder Slot wirdeinem Knoten zugewiesen. So können quasi simultan Daten von mehrerenKnoten verschickt werden ohne das Interferenzen entstehen. Um Kollisionenvon benachbarten Slots zu vermeiden werden Wartezeiten zwischen ihnen an-gewandt. Diese Wartezeiten müssen proportional zur Laufzeitverzögerung imKanal angesetzt werden. Da wir bei UAN jedoch mit hohen Laufzeitverzöge-rungen zu kämpfen haben, ist dies hier weniger praktikabel. Da bei TDMAerst die Daten gepuffert werden müssen, bis ein zugeteilter Slot turnusgemäßnoch einmal aufgerufen wird und nun die Daten versendet werden können,erfolgt hier ein sehr stoßweiser Netzwerkverkehr. Hier benötigen wir jedochhöhere Bitraten als bei FDMA. Während keine Datenübertragung erfolgt, kön-nen zudem die Knoten zur Energieeinsparung in einen Ruhemodus versetztwerden. Ein schwerwiegender Nachteil von TDMA ist die benötigte Zeitsyn-chronisierung der knoten, damit die Slots im richtigen Moment auch auf demdafür bestimmten Knoten genutzt werden können. Dies ist in UAN schwierig,kann durch ein regelmäßiges gesendet Synchronisierungssignal mit einmali-ger (bei statischen Netzwerken) oder periodischer (mobiles Netzwerk) Latenz-berechnung erreicht werden. Wie werden in Kapitel 2.2.2 zwar kein MultipleAccess Protocol, sondern ein Medium Access Control Protocol mit der Be-zeichnung Slotted-FAMA mit genau dieser synchronen Eigenschaft widmen.Somit wäre eine die Einführung von diesem Mehrfachzugriff-Protokoll nacheinigen Anpassungen realisierbar.

Code Division Multiple Access (CDMA): bei CDMA können alle Knotendie komplett verfügbare Frequenzbandbreite simultan benutzen. Dies wirddurch eine Codierung eines Signals mit Pseudo-Rauschen ermöglicht. Durchdieses Rauschen unterscheiden sich die Signale von unterschiedlichen Knotenund können beim Empfänger dementsprechend decodiert werden. Im Gegen-satz zu FDMA und TDMA kann hier das Nah-Fern-Problem jedoch auftre-ten, wenn ein starkes Signal ein schwächeres Signal überlagern sollte. Dieskann man zwar durch Mehrfachbenutzer-Detektion mildern indem man dieSignalstärke auf ein Minimum beschränkt um den Empfänger zu erreichenund dabei möglichst wenig andere Signale um ein vielfaches zu überlagern,erfordert jedoch einen erhöhten Aufwand. Wiederum senkt dies ebenso denEnergieverbrauch und sollte daher hier deswegen bei UAN angewandt wer-den.

18 2. Grundlagen

2.2.2. Medium Access Control (MAC)Die raren Ressourcen in einem limitierten Unterwasserkanal sollten in einermöglichst effizienten Art und Weise genutzt werden. Hierfür ist das MediaAccess Protokoll verantwortlich, mit dessen verschiedenen Varianten wir inden folgenden Abschnitten uns näher befassen.

Das originale ALOHA Protokoll besteht aus einem Zufallszugriff für die ein-zelnen Knoten. Wenn ein Knoten Informationen für einen Datenversand hat,so werden diese auch unmittelbar versendet. Wenn die Datenübertragung er-folgreich von einem Sender an einen Empfänger zu Stande kommt, was be-deutet das keine Paketkollisionen auftraten, sendet der Empfänger eine Be-stätigung in Form von einem (ACK)4, andernfalls wird nach einer zufälliggewählten Wartezeit eine erneute Datenübertragung versucht. Durch den Zu-fallscharakter ist eine weitere Kollision recht unwahrscheinlich, kann jedochdennoch auftreten. Dieses Protokoll erfordert allerdings sehr geringe Latenzenund führt zu einem relativ hohen Energieverbrauch, den man sich bei UANjedoch nicht leisten kann. Der maximale Throughput liegt laut [SoSP00a] beicirca 15%.

Das weiterentwickelte Extended-ALOHA Protokoll erweitert das ALOHA Pro-tokoll und synchronisiert die Uhren der Netzwerkknoten und erlaubt nurDatenübertragungs-Anfragen zu Beginn eines designierten Sendezeitraumes.Da die Wahrscheinlichkeit für Kollisionen zu diskreten Zeitpunkten herab-setzt, erhält man hier einen Throughput von 36%. In stoß weise erfolgendenDatenübertragungsnetzwerken, erfolgen trotz alledem zu viele Kollisionen fürein UAN und resultieren daher in einem viel zu hohen Energieverbrauch.

Das Carrier Sense Media Access (CSMA) tastet den Übertragungskanal nachTrägerwellen ab, um präventiv Kollisionen zu vermeiden. Hierfür ist natür-lich eine möglichst geringe Latenzen notwendig, damit möglichst schnell eineTrägerwelle erkannt werden kann, bevor selbst Anfragen ausgesendet oderDaten übertragen werden. Nur wenn ein Knoten einen freien Kanal annimmt,versucht er sein Paket zu senden. Hierbei gibt es zwei problematische Sze-narios bei denen trotz alledem Kollisionen auftreten können. Diese Szenarienwerden das Versteckte Knoten (hidden node) Szenario und das Freiligende Kno-ten (exposed node) Szenario genannt. Auf Basis von Abbildung 2.6 werden wirnachfolgend diese zwei Szenarien erläutern.

Versteckte Knoten Szenario: Wenn Knoten A ein Paket an Knoten B sendet, soerkennt C nicht die Trägerwelle und sendet sein eigenes Paket, was zu einerKollision mit dem Paket von B führt. Da der Knoten A für C versteckt war,wird dieses Szenario Verstecktes Knoten Szenario genannt.

Freilegender Knoten Szenario: Wenn das Ziel von einem Paket von C nicht Bwäre, so sollte B keine Kollision feststellen, falls dieser Knoten Interferen-

4ACK=Acknowledgment

2.2. Unterwassernetzwerke 19

Abbildung 2.6.: Knotentopologie für unser Beispiels UAN [SoSP00a]

zen, durch die gleichzeitig eintreffenden Pakete verursacht werden handha-ben kann. Auf der anderen Seite, wenn B eine Nachricht an A sendet, so ist Cblockiert, selbst, wenn es nicht das ziel für das Paket von B darstellen sollte.Das sorgt für einen unnötig niedrigen Datendurchsatz.

Das CSMA Protokoll kann diese zwei Szenario durch Schutzzeiten, welcheproportional zur maximalen Übertragungszeitverzögerung im Netzwerk an-gewendet werden. Da jedoch der akustische Informationsaustausch im Wassermit hohen Laufzeitverzögerungen, durch die niedrige Schallgeschwindigkeit,verbunden ist, resultiert CSMA in hohen Leerzeiten und somit in einen ge-ringeren Datendurchsatz. Als Konsequenz ist CSMA nicht praktikabel für einUAN und daher noch weniger für terrestrische akustische Netzwerke, mitnoch geringerer Schallgeschwindigkeit in der Luft, wie wir eines erstellenwollen.

Das Multiple Access with Collision Avoidance (MACA) nutzt zwei Signal-pakete um den Datenverkehr zu regeln. Das sind im Einzelnen: request-to-send(RTS) und clear-to-send (CTS). Sobald ein Knoten A seine Daten verschickenwill, sendet es ein RTS an den Empfangsknoten mit den Metainformationender Länge des beabsichtigten Datenpakets, das verschickt werden soll. WennB das RTS empfängt und in der Warteschlange Zeit für diese Nachfrage hat, sosendet Knoten B ein CTS. Nun kann die richtige Datenübertragung nach die-sem Handshake erfolgen. Dies löst sowohl das Versteckte Knoten Szenario alsauch das Freilegende Knoten Szenario. Eine Automatische Leistungssteue-rung kann durch das Erlernen der minimalen Schallamplitude beim RTS-CTS-Handshake zudem erlernt. Das Freilegende Knoten Szenario kann daherdurch die Verringerung der Signalstärke für den Versandt an nah gelegenenKnoten erzielt werden. So verblasst das Signal bevor es einen weit entferntenKnoten erreicht und wird nicht mehr registriert. Dadurch werden Leerlaufzei-ten reduziert und in Folge dessen der Datendurchsatz erhöht. Zudem werdendurch die minimale Reichweitenanpassung undder vermeidung von Kollisio-nen der Energieverbrauch gesenkt. Als Nachteil wird gerade durch diesenHandshake zusätzlicher Overhead erzeugt. Aber die geringeren Leerlaufzei-

20 2. Grundlagen

ten kompensieren diesen Faktor und führen , wie eben schon erwähnt zueinem höheren Datendurchsatz.

Abbildung 2.7.: Handshake zwischen Knoten A und B [MoSt06]

Abbildung 2.8.: RTS von Knoten C kollidiert hier mit einem Datenpaket vonKnoten A [MoSt06]

Eine modifizierte Version von MACA ist MACAW. MACAW nutzt wie MA-CA die RTS-CTS-DATA-Sequenz für den Datenaustausch. Wie man anhandAbbildung 2.9 erkennt, sind keinerlei Bestätigungspakete ACK oder NACKin den Ablauf involviert. Diese Aufgabe übernehmen übergeordnete Schich-ten, was jedoch sehr zuverlässige Verbindungen erfordert. Diese können beider UAN wiederum schwer gewährleistet werden und daher ist dieses Proto-koll für die akustische Datenübertragung nicht zu präferieren.

Floor Acquisition Multiple Access (FAMA)Das FAMA Protokoll nützt eine Trägerwellenerkennung zur Kollisionsvermei-dung, wie auch CSMA und erweitert dies noch mit dem von MACA genutztenHandshake, um die zuvor erwähnten Szenarios zu vermeiden und zudem diehohe Latenz auszugleichen die in akustischen Netzwerken auftreten. HoheLaufzeitverzögerung verhindern jedoch eine effektive Anwendung dieses Pro-tokolls für unsere Zwecke, da hierdurch die nötigen Pufferzeiten, damit alleNachbarknoten nach der längst möglichen auftretenden Verzögerung, viel zuhohe Werte annehmen würden und somit der Datendurchsatz und auch die

2.3. Verwandte Arbeiten und Herangehensweise 21

Abbildung 2.9.: Zeitüberschreitung eines RTS-Pakets und fehlerhafte RTS-Übermittlung [PrSo01]

Latenz schlechte Werte einnehmen würden. Diese Pufferzeiten werden durchdie Festlegung der Länge eine RTS auf mindestens der Laufzeitverzögerungim Netzwerk und einem CTS, dass länger als die doppelte Laufzeitverzöge-rung im Netzwerk addiert um die Zeitdauer der Signalverarbeitung in einemKnoten ist. Da jedoch viel zu große Metapakete gesendet werden müssen, umeine aktive Trägerwelle konstant im Übertragungskanal zur Kollisionsvermei-dung bei einer beabsichtigen Datenübertragung zu etablieren ist dieses nochnicht angepasste Protokoll für akustische Netzwerke nicht zu empfehlen. zu-dem erhöht es wie eben beschrieben die schon vorhandene Latenz durch dielangen Metapakete zusätzlich!

2.3. Verwandte Arbeiten und HerangehensweiseBei der Konzeption eines akustischen Schwarmnetzwerkes haben wir uns zualler erst mit der Akustik als solches auseinander setzten müssen und habendaher vor allem durch die Opencourseware-Vorlesung ’Physics III: Vibrati-ons and Waves’ [MIT13] , die von Prof. Walter Lewin gehalten wurde, dieGrundlagen für die weitere Arbeit erarbeitet.Für die technische Konzeption wurde in der Planungsphase sodann [LeSW09]zu Rate gezogen.

Nachdem die Grundlagen erlernt werden konnten, stellte sich die Frage, wound in welchen Gebieten die Akustik schon zur Datenübertragung herange-zogen wurde. Für den terrestrischen Anwendungsbereich suchten wir fastvergebens, mit Ausnahme von Akustikkopplern, die während der Monopol-zeit von Bell in den USA als Workaround ihre Verwendung fanden, Infosoundvon Yamaha und kleineren Hobby-Projekten im DIY-Bereich, nach schon er-folgreich implementierten Projekt, die wir für unseren akustischen Schwarmhätten heranziehen können.

22 2. Grundlagen

Hierbei stellte sich natürlich die Frage, warum so wenige Arbeiten für dieterrestrische akustische Datenübertragung bisher zu Stande kamen. Einemögliche Erklärung könnten die folgenden Punkte bieten:

1. Elektromagnetische Wellen sind mit clight = 299.792.458m/s5 im Gegen-satz zu csound = 343, 2m/s einfach deutlich schneller und ermöglichensomit geringere Latenzen.Zudem sind wir Menschen für Akustik im Bereich zwischen Infra- undUltraschall, somit zwischen 16 Hz und 20 kHz empfänglich, wodurchdieses Frequenzband für technische Anwendungen im Bereich der Da-tenübertragung ausscheidet und unsere nutzbare Bandbreite neben derdurch Absorption, Richtungscharakteristik und Wellengröße eingeschränk-ten Bereich noch weiter verkleinert.

2. Bis zur Entwicklung von Piezo-Elementen war der Wirkungsgrad beider Energieumwandlung von elektrische in Schall-Energie bei wenigerals 1% bis maximal 50%6 im Gegensatz zu 80-95% die bei Piezo Schall-wandlern üblich sein können.

3. Der momentane Übertragungsstandard ist nun einmal auf elektroma-gnetische Wellen ausgelegt. Hierfür besteht auch schon eine geeigneteInfrastruktur und Übertragungsmodule zur Verfügung.

Somit sind wir darauf angewiesen andere Einsatzgebiete, als das von unsausgewählte für weitere Untersuchungen heranzuziehen. Wir mussten daherdas Hauptverbreitungsgebiet der akustischen Datenübertragung, dem EinsatzUnterwasser, als Ausgangspunkt für bereits vorhandene Forschungsergebnis-se zu rate ziehen. Hier fanden wir insbesondere in [SLMR05],[Stoj95],[Stoj96]und [StPr09] Informationen die für unseren Projektaufbau einfließen konn-ten.Die Ansätze der akustischen Unterwasser-Netzwerke haben jedoch die füruns entscheidende Unterschiede, dass sie mit dem Übertragungsmedium Was-ser mit höherer Dichte als Luft, csound = 1.482m/s und einer nicht mit Men-schen bevölkerten Umgebung arbeiten. Die noch geringere geringere Geschwin-digkeit von Schallwellen an Land erhöht nochmal die Problematik der La-tenzen und sorgt im Endeffekt für insgesamt geringere Datenraten. Zudemschließt das Vorhandensein von anderen Lebewesen mit anderen Hörschwel-len, wie Unterwasser andere Frequenzbänder für die Nutzung aus.Ansonsten sind der terrestrische und der Unterwassereinsatz miteinander ver-gleichbar und es können Lösungen und Erkenntnisse aus den UAN ange-wandt werden.

Da wir eine Physical-Computing-Plattform für unseren Schwarm, wegen denschon in Kapitel 1 und Unterkapitel 3.3 erwähnten Vorteilen, verwenden woll-

5Geschwindigkeit für elektromagnetische Wellen im Medium Luft und nicht im Vakuum.6mit Schallbündelung durch Trichter und Druckkammern. Siehe hierzu [LeSW09] S.424 und

S.669

2.3. Verwandte Arbeiten und Herangehensweise 23

ten, stand zu aller Erst die geeignete Auswahl einer Plattform zu Disposition.Nach sorgfältiger Analyse, entschieden uns für die Arduino-Plattform, waswir in Unterkapitel 4.1 noch genauer erläutern werden.Hierdurch hatten wir nun unsere Rechen- und Steuereinrichtung für unserProjekt und mussten dieses noch um ein Kommunikationsmodul erweitern.

Nach Betrachtung der üblichen Konstruktionen von akustischen Modems,entschlossen wir uns aus Zeit- und Vereinfachungsgründen ein fertiges Piezo-Transceiver-Bauteil für unser Modem zu nutzen, um uns den Aufbau folgen-der sonst notwendiger Module zu ersparen und nicht unseren Zeitrahmen zusprengen:

• Vorverstärker

• Verstärker

• Filter (Bandpassfilter)

• Signalformerzeugung

• Kalibrierung des Transceiver-Moduls auf die Resonanzfrequenz des Pie-zos

• Saubere Signalformerzeugung

Zudem entschlossen wir, uns auf eine einzige Frequenz, durch die Nutzungdes SRF02 ist das bei uns 40kHz, für die Datenübertragung zu beschränken.Natürlich macht das unser System anfällig durch Störeinflüsse, da wir auf kei-ne alternative Frequenz wechseln können. So stellen Schallquellen wie zumBeispiel fahrende Eisenbahnen (Abrolltöne) oder Tastaturen(Klicken) , solltenbei unserer beabsichtigten Nutzung der Schwärme vernachlässigbar sein.Einen großen Vorteil den wir durch die Nutzung des SRF02 erhalten, ist daswir ein optimiertes Transceiver-Modul erhalten, das man zusätzlich zur Ab-standsmessung heranziehen kann. Dies ohne zusätzliches Modul und damitzusätzlich verbundenen Kosten und Energieverbrauch. Zudem kann man da-durch schon vorhandene Projekte, die gerade diesen Ultraschallsensor ver-wenden nachträglich mit einem Modem versehen und drahtlos Daten über-tragen.Folgende Nachteile handeln sind uns durch den SRF02 ein:

• proprietäres Bauteil

• Signalstärke und Frequenz sind fix

• Von Hersteller vorgesehenes Zeitintervall für eine Abstandsmessung von65ms, was ohne einen von uns genutzten Tweak7, zu einer Datenrate vonnur um die 15 Bits führen würde.

7Um es schon vorweg zu nehmen: Wir haben uns der Eigenschaft des SRF02 bedient, dernach erfolgreicher Messung, die umgerechnet laut Datenblatt minimal 0,4ms betragen

24 2. Grundlagen

Somit ist festzuhalten, dass wir eine recht unorthodoxe Vorgehensweise ge-wählt haben, indem wir uns für ein schon fertiges Transceiver-Moduls für einan sich anderes Einsatzgebiet entschieden haben. Dafür erhalten wir durchdas Umfunktionieren ein 2 in 1 Modul, dass wir für unsere Zwecke nut-zen und anpassen können. Des weiteren steht uns dadurch ein kostengünsti-ger und sehr schneller Aufbau für einen Schwarm in Kombination mit einerPhysical-Computing-Plattform zur Verfügung.

Nach der Auswahl der Plattform und des Transceiver-moduls mussten diesesnatürlich über eine geeignete Schnittstelle verbunden werden. Hier musstenwir uns zwischen I2C und RS232(TTL) entscheiden und diese Schnittstelle im-plementieren. Zudem mussten sämtliche Hardwarekomponenten per Steck-brett (Breadboard) für einen schnellen Prototypenaufbau verkabelt werden.

Neben der hiermit nun kombinierten Hardware war die Erstellung von geeig-neten Sourcecode für die Steuerung des Mikrocontrollers und des Transceiver-moduls notwendig. Hierfür schrieben wir ein vereinfachtes Übertragungspro-tokoll für eine unidirektionales akustisches Modem in den Programmierspra-chen C8 und C++.

Da die physische Schicht natürlich von einem Protokoll für den Mehrfach-zugriff innerhalb eines Mediums für den erfolgreichen Einsatz einer bidi-rektionalen Datenübertragung erweitert werden muss, entschlossen wir unshier das in [MoSt07] beschriebene Slotted-FAMA-Protokoll anzuwenden. DieGründe hierfür waren vornehmlich das dieses Protokoll für den akustischenEinsatz angepasst wurde, es sehr energiesparend, durch die Vermeidung vonKollisionen von Datenpaketen und für multi-hop ad hoc Netzwerke, wie esunser Schwarm ist, ausgelegt ist, scheint es prädestiniert für unsere Zweckezu sein.In diesem Zusammenhang wollen wir das Protokoll nicht für Broadcasts nut-zen, sondern für die gezielte Datenweitergabe an einzelne Knoten in der di-rekten Nachbarschaft. Das kann für die Weitergabe von Sensordaten an einenHauptsender mit elektromagnetischen Funkmodul oder für die Implementie-rung eines Synchronisierungsalgorithmus, der uns Timestamp-Funktionalitätvon Ereignissen und ein synchrones Arbeiten des Schwarms ermöglicht. Fürreine Broadcast wäre das Slotted-FAMA mit seinem Handshake durch RTS >CTS > DATA9 ein viel zu großer Overhead für die geringen Bitraten in un-serem Netzwerk. Für Broadcasts sollten CS-Protokolle ohne Handshake zumEinsatz kommen. Das erhöht natürlich die Wahrscheinlichkeit für Kollisionen,macht jedoch für diese Art von Datenübertragungen mehr Sinn.

darf, weitere Messungen ermöglicht. So nutzen wir diesen Fakt indem wir nach jedem Bitein Trigger-High-Bit für den Sensor mit schicken, der einen erfolgreichen Messvorgangjeweils beendet.

8Die von uns verwendete Wire-Bibliothek der Arduino-Community, die für die Steuerungder I2C-Schnittstelle notwendig ist, wurde in C implementiert.

9RTS: Request to send; CTS: Clear to send; DATA: Daten.

2.3. Verwandte Arbeiten und Herangehensweise 25

Das Slotted-FAMA-Protokoll (Floor Acquisition Multiple Access):In Unterkapitel 2.2.1 zeigten wir schon die Entwicklung von CSMA überMACA/MACAW zu FAMA auf und beschrieben ausführlich das FAMA-Protokoll und dessen Handshake-Mechanismus von RTS > CTS > DATA. DieAnpassung des FAMA-Protokolls an die akustische Datenübertragung kenn-zeichnet nun den Aufbau von Slotted-FAMA. Da das reine FAMA bei denhohen Latenzen die wir durch die Verwendung von akustischen Modem er-halten zu viel zu großen Paketen für RTS und CTS führen würde, was sichwiederum auf einen höheren Energieverbrauch der Knoten auswirken wür-de, erstellt das Protokoll Zeitintervalle, an deren Beginn nur gesendet werdendarf. Hierdurch kann man die Paketgröße von RTS und CTS, die als Carri-er für den CS-Teil des Protokolls fungieren, auf ein Minimum heruntersetzenund erhält trotzdem eine kollisionsfreie Datenübertragung im Netzwerk. Ab-bildung 2.10 zeigt einen erfolgreichen Handshake des Slotted-FAMA. In die-ser Abbildung sieht man die einzelnen Slots, zu deren Beginn nur gesendetwerden darf.

Abbildung 2.10.: Erfolgreicher Handshake zwischen Knoten A und B, trotzfür A verstecktem Knoten C [MoSt07]

Die Größe der Slots berechnet sich wie folgt:

tSlot = max(tLaufzeitverzögerung) + tÜbertragungszeit eines CTS (2.6)

Vorteile des Slotted-FAMA-Protokolls sind:

1. Es ist den Bedingungen der akustischen Datenübertragung mit hohenLatenzen und geringer Bitrate angepasst.

2. Es vermeidet Paketkollisionen und senkt somit den Energieverbrauchder Knoten.

26 2. Grundlagen

Nachteile des Slotted-FAMA-Protokolls sind:

1. Synchronisierung ist notwendig, was aufwendig ist.

2. Durch das Handshake vor Beginn einer Datenübertragung entsteht einnicht zu verachtender Overhead.

Da Slotted-FAMA synchrone Knoten für seine Ausführung benötigt, warenwir gezwungen unser Netzwerk um eine solche Komponente zu erweitern.Dies führten wir durch die Konzeption eines Synchronisierungs-Algorithmusund der Hinzunahme von Sender-Knoten mit genaues zeitliches Takten überzusätzliche Module, wie GPS.Zur Evaluation unseres eigens für dieses Projekt entwickelten Algorithmus,entwickelten wir zusätzlich mit Python und dem Framework Pyside eine gra-fische Simulationsumgebung um diesen zu testen. In Unterkapitel 5 werdenwir genauer auf den Algorithmus und die Simulationsumgebung eingehen.

Mit der Implementierung des Slotted-FAMA-Protokolls in unsere zuvor er-stellten akustischen Modems steht nun eine kollisionsfreie Datenübertragungfür unseren Schwarm zur Verfügung.

3. Hardware

In diesem Kapitel widmen wir uns der Hardware, mit der ein Aufbau ei-nes akustisch kommunizierenden Schwarms von Netzwerkknoten realisierbarwäre. Darunter gehören für jeden Knoten zum einen eine geeignete Rechen-und Steuereinheit, welche die eingehenden Daten verarbeiten und die ange-schlossenen Sensoren und Aktoren koordinieren kann, und zum anderen, dieeben erwähnten Sensoren und Aktoren.

Abbildung 3.1.: Darstellung eines Netzwerkknoten und dessen gestaffeltenAufbau.

Zuerst befassen wir uns mit der Unterscheidung und Eingrenzung von Mi-krocontrollern und Mikroprozessoren. Im Anschluss gehen wir näher auf dieverschiedenen Chip-Designs und deren Vor- und Nachteile ein und beleuch-ten im Detail die jeweils verwendeten Befehlssätze der Chips.

28 3. Hardware

Um einen schnellen und kostengünstigen Prototypenbau zu realisieren, wol-len wir jedoch nicht den puren Mikrocontroller, sondern eine geeignete Physical-Computing-Plattform zum Aufbau heranziehen. Daher wird in Unterkapitel3.3 auf die momentan am weitesten verbreiteten Plattformen eingegangen.Hier werden vor allem, zur Einschätzung von Alternativen zu der Arduino-Plattform, die in diesem Projekt verwendet wurde, das Beaglebone (Black)und das Raspberry Pi ausführlich beschrieben. Jede Plattform hat seine Vor-züge und Nachteile, somit sollte bei jedem Projekt, zuvor analysiert werden,ob ein einzelner Mikrocontroller oder eine bestimmte Plattform den Anforde-rungen eher gerecht wird, beziehungsweise besser dafür geeignet sein sollte.

Im Unterkapitel 3.4 widmen wir uns abschließend der noch zusätzlich not-wendigen Peripheriekomponenten, die nicht ohnehin schon durch eine Platt-form oder einem Mikrocontroller integriert sind. Dies gestaltet sich bei unse-rem Projekt recht überschaubar und besteht nur aus einer Komponente: demUltraschallsensor, der uns als akustisches Transceiver-Modul dienen wird.

’Ein Mikroprozessor ist ein Prozessor in sehr kleinem Maßstab, bei dem alleBausteine des Prozessors auf einem Mikrochip (integrierter Schaltkreis, IC)vereinigt sind.’ [Wiki13c]

3.1. Mikroprozessor-ArchitekturenIn Embedded Geräten, die mit einem Mikrocontroller (MCU) ausgestattetsind, findet man momentan vorherrschend die Prozessorarchitekuren ARM,AVR, wohingegen bei Desktop-PCs vor allem die Architektur x86 bevorzugtwird. Dies liegt zum einen an der unterschiedlichen Leistungsaufnahme derzwei Architekturen, als auch an der unterschiedlich notwendigen Flexibilitätder Programmierung der jeweiligen Einsatzgebiete der Geräte. Ein Trocknermuss nun mal die immer gleichen Aufgaben erledigen, im Vergleich zu einemDesktop-PC der sowohl E-Mail-Versand, Bildbearbeitung, Surfen etc. ermög-lichen sollte.

Neben den generellen Aufbauunterschieden von ARM, AVR und x86, unter-scheiden sich die Gruppe, bestehend aus ARM, AVR von der Gruppe der x86Prozessoren insoweit, dass sie einen einfachen Befehlssatz RISC im Gegensatzzu x86, der bei den heute geläufigen Modellen einen Hybriden CISC/RISCbeherbergt, nutzen.

Dieser Unterschied macht sich vor allem in der Leistungsaufnahme bemerk-bar, wodurch sie vor allem in eingebetteten Systemen Verwendung finden.

3.1.1. ARM

ARM steht für Advanced RISC Machines, was somit auch gleich den Befehls-satz dieser momentanen 32-Bit-Chiparchitektur erläutert. In naher Zukunft

3.1. Mikroprozessor-Architekturen 29

Abbildung 3.2.:

(voraussichtlich 2014) soll das ARM Design noch um eine stärkere 64-Bit Va-riante ergänzt werden.

Chips mit ARM-Architektur zeichnen sich, wie schon in Kapitel 3.1 erwähnt,durch eine geringe Leistungsaufnahme aus.

Im Gegensatz zu den Atmel AVR können sich jedoch mal eine Von-Neumann-Architektur oder eine Harvard-Architektur beinhalten.

3.1.2. x86

Für dieses Projekt nicht wirklich als Option zu erwägen, der vollständig hal-ber erwähnt, ist die x86 Prozessorarchitektur, die in vielen Desktop-PCs ihreHeimat findet.

Sie arbeitet momentan hauptsächlich mit 64-Bit-Registern und höheren Tak-tungsraten im GHz-Bereich und einer größeren Anzahl an Kernen, im Ver-gleich zu den ARM, geschweige denn den AVR Mikrocontroller-Prozessoren.

Früher wurden hauptsächlich pure CISC Prozessoren hergestellt, heutzutagesind die Hybridmodelle mit CISC/RISC geläufiger. Diese Prozessoren habeneinen RISC-Kern mit einer CISC-Emulationsschicht.

Da die x86er Serien jedoch weit mehr Leistung aufnehmen und zudem deut-lich teurer als die ARM und AVR Prozessoren sind, werden wir diese Archi-tekturfamilie für die Verwendung in unserem Schwarm außer Betracht lassen,auch wenn x86 natürlich leicht zu programmieren, eine große Programmier-Bibliothekssammlung, eine große Community und flexiblere Eigenschaftenbereitstellen.

Erweitert man den Chip, auf dem der Mikroprozessor untergebracht ist, umweitere Peripherie, spricht man von einem Mikrocontroller. Hier sind meist

30 3. Hardware

RAM, Flash-Speicher, Bussysteme, ADC und vieles mehr untergebracht. Diesermöglicht einen vielseitigen Einsatz des Mikrocontrollers als Miniaturrech-ner.

3.2. MikrocontrollerZu beachten sei jedoch, dass ein Mikroprozessor für jede zu wählende Physical-Computing-Plattform notwendig ist, ein Mikrocontroller dagegen eine optio-nale Komponente darstellen kann.Ob der Mikroprozessor somit direkt, fest-gelötet beziehungsweise bestückt,oder indirekt über einen Mikrocontroller in einem Einplatinen-Rechner inte-griert ist, das ist von der jeweiligen Plattform abhängig.

Abbildung 3.3.: Layeraufbau

Wenn man jedoch statt der einfachen Erweiterbarkeit einer Physical-Computing-Plattform, die Kosten minimal halten will, sollte man zuerst analysieren, obein Mikrocontroller einer bestimmten Mikrocontroller-Familie, mit geeigneterintegrierter Peripherie, ausreichend wäre.

Die heute gängigen Mikrocontroller sind mit 4-, 8- 16- und 32-Bit-Prozessorenausgestattet. Will man eine geringere Leistungsaufnahme erreichen, sollte maneine niedrigere Bit-Rate bevorzugen. Da sich jedoch 8- und 16-Bit-Prozessorenfertigungstechnisch kaum von den 32-Bit Varianten unterscheiden und daherfast gleichpreisig gefertigt werden können, werden momentan die 4-,8- und16-Bit Varianten von den 32-Bit MCUs, mit ihrer höheren Rechenleistung, ver-drängt.

3.2. Mikrocontroller 31

3.2.1. AVR

’Atmel AVR ist eine 8-Bit-Mikrocontroller-Familie des US-amerikanischen Her-stellers Atmel. Die Controller dieser Familie sind wegen ihres einfachen Auf-baus und ihrer leichten Programmierbarkeit auch bei Hobby-Anwendern weitverbreitet.’ [Wiki13b]

Besonderheit der gängigen Atmel AVR (alle außer der 32-Bit Variante, dieeine Harvard-Architektur mit Koppelfeld beinhaltet) ist das Schaltungskon-zept der Harvard-Architektur. Bei der Harvard-Architektur gibt es eine strik-te Trennung zwischen Daten- und Programm-Speicher, da beide über jeweilseigene voneinander getrennten Bussen erreichbar sind. Das hat den Vorteil,dass auf Daten und Programmcode gleichzeitig zugegriffen werden kannund nicht auf nacheinander folgenden Buszyklen verlegt werden muss. Diephysikalische Trennung der beiden Speicherbereiche vereinfacht zudem dasProgrammcode schreibgeschützt genutzt werden kann, indem der separierteSpeicherbereich als Flash-ROM ausgelegt wird. Bei den Atmel AVR sind derProgrammcode und der Bootloader im Flash-ROM und die Laufzeitvariablenetc. getrennt im RAM untergebracht.

Des weiteren ist die AVR Familie für höhere Programmiersprachen, wie Causgelegt. Somit kann mit einem C-Compiler effizienter Code erzeugt werdenund man ist nicht zwingend daran gebunden, selbst auf Assemblerebene zuprogrammieren.

Da ein Atmel AVR jedoch den binären Programmcode direkt aus dem inte-grierten Flashspeicher bezieht, sind geringere Taktraten von Nöten, als wennder Code in einem SRAM-Speicher vorliegen würde.

Die neueren Atmel-32-Bit Mikrocontroller ähneln schon eher der ARM-Ar-chitektur und ergänzen die geringe Leistungsaufnahme mit einem höherenDatendurchsatz als bei den früheren Varianten.

Um späteren Namensverwechslungen vorzubeugen, sei darauf hingewiesen,dass die Firma Atmel MCUs mit AVR eigener Prozessor-Architektur, als auchARM-Prozessor Architekturen vertreibt. Durch den Namen Atmel auf einemMCU, kann somit nicht direkt auf die Atmel AVR Baureihe geschlossen wer-den.

In der Peripherie sind: AD-Wandler mit 10 bit, 8- und 16-Bit-Timer mit Puls-weitenmodulation (PWM), SPI, I2C (TWI), UART, Analog-Komparator, Wat-chdog untergebracht. Wie schon in Kapitel 3.2 erwähnt, macht gerade die In-tegration von Peripheriestrukturen auf dem Mikrochip einen Mikrocontrolleraus.

Angeschlossen an eine 1,8 - 5,5 V Spannungsquelle und versehen mit einemexternen Taktgeber ist der AVR Mikrocontroller schon out of the box betriebs-bereit.

32 3. Hardware

3.3. Physical-Computing-PlattformenDa wir einen in seiner Funktion leicht erweiterbaren Prototypen-Schwarmerstellen und funktionstüchtig betreiben wollen, spielt die Auswahl einer ge-eigneten Physical-Computing-Plattform1 eine entscheidende Rolle.Optimierungen und der Austausch von Hardware und Softwarekomponentenkönnen nach erfolgreicher Erstellung des Prototypen-Netzwerkes noch heran-gezogen werden.

Abbildung 3.4.:

Die folgenden Zielsetzungen begleiten die Auswahl einer geeigneten Platt-form:

1. Die vorgesehenen Algorithmen müssen mit dem zur Verfügung stehen-den Speicher und der Rechenleistung erzielbar sein.

2. Kostengünstig, da ein ganzer Schwarm in Planung ist und Funktiona-lität über Schwarmintelligenz erreicht werden soll und nicht über hoheIndividualleistungen.

3. Geringer Energieverbrauch (da ein mobiler Einsatz vorgesehen ist).

4. Eine Erweiterung und Verbesserung der Funktionalität der erstelltenNetzwerkknoten sollte möglichst leicht von statten gehen.

5. Die Dimensionierung der Hardware in möglichst geringer Größe.

Dabei ist zu beachten, dass je nach verwendeter Prozessorarchitektur un-terschiedliche Speicherbereiche zur Verfügung stehen. So ist bei der Von-Neumann-Architektur, die schon in 3.2.1 erwähnt wurde, ein gemeinsamerSpeicher für die Unterbringung des auszuführenden Programms, sowie für

1Für weitere Informationen siehe [SLMR05].

3.3. Physical-Computing-Plattformen 33

die zu speichernden statischen Variablen, dem Stack und Heap vorhanden.Somit muss dementsprechend die Größe des gemeinsamen Speichers ausge-wählt werden.

Bei der Harvard-Architektur wiederum liegt der auszuführende Binärcodein einem separaten ROM-Bereich und statische Variablen, Stack und Heap imRAM. Hier muss auf zwei Speicherbereiche bei der Dimensionierung geachtetwerden.

Egal ob Harvard- oder ’Princeton-Architektur’2 gewählt wurde, ist zudemein EEPROM vorhanden, können statische Variablen, hier vor allem String-Konstanten, in den Langzeitspeicher ausgelagert werden und schaffen somitPlatz für Stack und Heap. Somit hat auch der EEPROM Einfluss auf das Spei-chervermögen für bestimmte Programm-Variablen und kann als Erweiterungdes RAM angesehen werden und sollte daher mit beachtet werden.

Zudem kann abschließend gesagt werden, dass durch den Erfolg der in denfolgenden Unterkapiteln beschriebenen Physical-Computing-Plattformen, aufOpen Source Basis (sei es unter GPL und/oder LGPL)3, und einer wachsendenDIY-Mentalität4, in immer kürzeren Zeitintervallen ähnliche oder adaptiertePlattformen entstehen. Diese schaffen es meist bis hin zur Massenproduk-tion, durch Crowdfounding-Webseiten, wie Kickstarter oder Indiegogo. Dahersollte in regelmäßigen Abständen bzw. nach Fertigstellung des Prototypen-Schwarms überprüft werden, ob nicht eine neue und bessere Möglichkeit fürdie Realisierung eines ad hoc Netzwerk-Schwarms möglich wäre.

Abbildung 3.5 zeigt die verschiedenen Plattformen, inklusiver einer weiterenVariante, dem Arduino-Due, bei der Arduino-Plattform. Wie ersichtlich wirdsind die Größenverhältnisse nicht allzu unterschiedlich, jedoch die Ausstat-tung mit Pins und unterschiedlicher Peripherie fällt einem sofort auf.

3.3.1. Arduino

Was ist ein Arduino? Die Definition ist sogar dem Team um das Projekt mitder Zeit immer schwerer gefallen, als dieses stets populärer wurde und sichdurch das Open Source Prinzip bei der Hard- und Software zunehmend Kloneund Arduino-Derivate entwickelten. So beschlossen sie das Logo und denNamen rechtlich zu schützen.

In ihrem Internetblog 5 geben sie die folgenden Punkte für die Eingrenzungeines offiziellen Arduino an:

• es wird direkt von der offiziellen Arduino IDE unterstützt2Als Randnotiz: Von Neumann war Professor in Princeton.3Eine schöne Übersicht über die verschiedenen Lizenzen erhält man durch [BuDH13]4Siehe hierzu [KuPa10].5Den genauen Blogeintrag findet man in: [Banz13]

34 3. Hardware

Abbildung 3.5.: Vergleich von Größe und Layout von: Raspberry Pi Model-B(links oben), Arduino Uno Rev 3.0 (rechts oben), BeagleboneBlack (links unten) und Arduino Due (rechts unten)

Abbildung 3.6.: Hier ist das Arduino Uno Rev 3.0 zu sehen.

3.3. Physical-Computing-Plattformen 35

• es folgt dem standardisierten Arduino Layout6

• es ist geeignet auf ihrer Webseite dokumentiert

• es trägt den Namen ’Arduino’ und das Logo

• es wird durch autorisierte Hersteller produziert

Wir erwähnen diesen Sachverhalt, da für die Konzeption und Implementie-rung eines eigenen Arduino-Plattform-Derivats, je nach gewählter Funktiona-lität und Komfortverhalten, nur wenige Komponenten erforderlich sein müs-sen.

Somit gehört zu einer Arduino-Plattform ein unterstützter Mikrocontroller.Dieser hat an sich einen eigenen Arduino-Bootloader für die schnelle und un-komplizierte Übertragung von Binärcode, mittels serieller Schnittstelle inte-griert. Um Speicherplatz zu sparen und/oder den Startvorgang des Mikro-controllers zu beschleunigen, kann dieser jedoch weggelassen und der Binär-code per externen ISP jedes Mal frisch aufgespielt werden.Das wahre Herz, neben dem jeweiligen genutzten Mikroprozessor der Platt-form, ist die Bibliothekensammlung, die von der Arduino-Community be-reit gestellt wird. Dadurch können schnell und unkompliziert viele Funktio-nen, ohne eigene Assemblerprogrammierung, somit unter Verwendung einerHochsprache, eingebettet und programmiert werden. Daher empfiehlt es sichbeim Aufbau eines eigenen Arduinos diese zu verwenden, jedoch auch diesesind nicht zwingend notwendig.Legt man nun nicht besonderen Wert auf eine genaue Taktung7 könnte mansogar einen externen Taktgeber beim eigenen Aufbau außen vor lassen undmuss sich nur noch um eine geregelte Stromversorgung mittels Spannungs-regler, um für eine konstante Versorgungsspannung zu sorgen.Für komfortables Arbeiten mit dem Mikrocontroller empfiehlt es sich nocheine Status-LED und einen RESET-Schalter zu integrieren. Auch diese sindoptional.Nun hätte man im Grunde genommen seine eigene Arduino-Plattform.

Eine andere Möglichkeit wäre, die freien Leiterplatten- und Schaltkreis-Layouts, welche die Arduino-Community in Form von Eagle8-Dateien zurVerfügung stellt, für eine eigene Ätzung der Leiterbahnen und zur Bestückungzu verwenden.

Da man jedoch mehr Peripherie, leichte Upgrade-Möglichkeit durch das Ardu-

6Momentan ist das die Revision 3.07So haben die AVR-Familie z.B. einen internen Taktgeber. Dieser ist nicht besonders genau,

ist in manchen Fällen jedoch ausreichend.8CAD-Software für das Leiterplatten-Design

36 3. Hardware

ino-Shield-Layout und vieles mehr haben möchte, empfiehlt sich für den ge-nerellen Aufbau eines flexiblen Projektes schon fertige Arduino-Boards her-anzuziehen. So ist beispielsweise ein USB-to-Serial-Konverter, mit dem manbequemen den Flash-ROMs Programmieren kann, in der Arduino-Plattformvorhanden und erspart uns einen zusätzlichen anzuschließenden ISP9.

Tabelle 3.1 zeigt eine aktuelle Übersicht über die zur Verfügung stehendenVarianten der Physical-Computing-Plattform Arduino.

Das standardisierte Platinendesign der Arduino-Plattform, ermöglicht eineschnelle und platzsparende Erweiterungsmöglichkeit mit verschiedensten zu-sätzlichen Modulen.So sorgen aufsteckbare Platinen, den sogenannten Shields, die entweder fürden Formfaktor des Arduino-Mega oder des kleineren Arduino-Uno ange-passt sind, für eine schnelle und einfache Funktionserweiterung der jeweiligenPlattform-Variante. Hierbei ist zu beachten, dass die I/O-Pins des Arduino-Due nur für Shields mit 3,3V, im Gegensatz zu den anderen Boards, die für3,3V und 5V konzipiert sind.10

Neben der einfachen Variante mittels Stecksystem die Plattform zu erweitern,bietet das System zudem die Möglichkeit auf die folgenden Schnittstellen undBussysteme: USB, SPI, ICSP und I2C11 zuzugreifen und hierdurch nachzu-rüsten.Auf die eben erwähnten Schnittstellen und Bussysteme werden wir in Kapitel3.4 näher eingehen.Auch wir haben von der Möglichkeit Gebrauch gemacht, unsere Schwarm-knoten durch die Verwendung des I2C-Bussystemes für den Anschluss ei-nes Ultraschall-Transceiver-Moduls mit zusätzlichen kleinen Mikrocontroller-Board, zu erweitern.Ein weiteres Beispiel für eine Funktionserweiterung, wäre die Möglichkeitunser System, mit dem gerade bei Kickstarter angelaufenen optischen Erken-nungssensor mit den bereitgestellten Schnittstellen: UART, SPI, I2C; der Car-negie Mellon University, einzubinden.12

Zusätzliche Funktionalitäten können auch per Software, durch Nutzung vonder Arduino-Communiy erzeugten Programmierbibliotheken, die es inzwi-schen in großer Menge gibt, in ein Projekt integriert werden. So erhält manzum Beispiel durch die Timer1-Bibliothek, ohne in die Registerprogrammierungund hier vor allem den Counter/Timer-Registern und den jeweilig nötigen In-terrupts und Prescaler einzutauchen, die Möglichkeit sehr genaue zeit-basierte

9Ein ISP ist eine Hardware für das Programmieren eines Mikrocontrollers10Die komplette Übersicht über allen momentan verfügbaren Shields erhält man durch: http:

//shieldlist.org/11Das Arduino-Mega hat zudem noch UART und das Arduino-Ethernet TWI zur Verfügung.12Kickster-Projektseite für Pixy: http://www.kickstarter.com/projects/254449872/

pixy-cmucam5-a-fast-easy-to-use-vision-sensor

3.3. Physical-Computing-Plattformen 37

Aktionen auszulösen. Dies wird durch den Zugriff auf einen der drei verfüg-baren internen Timern beim Arduino-Uno bewerkstelligt.

Arduino MCU Be-triebs-

span-nung

FlashKiB

EEPROMKiB

SRAMKiB

Dig.I/OPins

. . .mit

PWM

Anal.Ein-gän-ge

Interfaces Abmessungenin mm

Nano ATmega328(8-bit)

5V 32 1 2 14 6 8 Mini-B, USB,I2C, SPI

43 × 18

Diecimila ATmega168(8-bit)

5V 16 0.5 1 14 6 6 USB 68,6 × 53,3

Duemilanove ATmega168(8-bit)

5V 16 0,5 1 14 6 6 USB,SPI, ICSP,I2C

68,6 × 53,3

Uno ATmega328(8-bit)

5V 32 1 2 14 6 6 USB, SPI, ICSP,I2C

68,6 × 53,3

Ethernet ATmega328(8-bit)

5V 32 1 2 14 4 6 Ethernet, SDcard, SPI,TWI

68,6 × 53,3

Mega ATmega1280(8-bit)

5V 128 4 8 54 14 16 USB, SPI, ICSP,I2C, UART

101,6 × 53,3

Mega2560 ATmega2560(8-bit)

5V 256 4 8 54 14 16 USB, SPI, ICSP,I2C, 4 UART

101,6 × 53,3

Mega ADK ATmega2560(8-bit)

5V 256 4 8 54 14 16 USB, SPI, ICSP,I2C, 4 UART

101,6 × 53,3

LilyPad ATmega168Voder

ATmega328V(8-bit)

2,7 -5,5V

16 0.5 1 14 6 6 USB (FTDIBasic Breakout

requ. )

ø 50

BT(Bluetooth)

ATmega328(8-bit)

5V 32 1 2 14 4 6 Bluegiga WT11Bluetooth,

TWI, I2C, SPI

81,2 × 53,3

Leonardo ATmega32U4(8-bit)

5V 32 1 2.5 20 7 12 USB, ICSP,TWI, I2C, 1

UART

68,6 × 53,3

Micro ATmega32U4(8-bit)

5V 32 1 2.5 20 7 12 USB, ICSP,TWI, I2C, 1

UART

48,3 × 17,8

Esplora ATmega32U4(8-bit)

5V 32 1 2.5 - - - Micro USB,ICSP, TinkerkitKonnektoren,

TFT-Konnektor(LCD-

Display)Due AT91SAM3X8E

(32-bit)3,3V 512 - 96 54 12 12 USB, CAN,

ICSP, 2 TWI, 2I2C, 4 UART, 2

DAC

101,6 × 53,3

Tabelle 3.1.: Übersicht der Arduino Modelle [Wiki13a]

3.3.2. Raspberry Pi

Im Gegensatz zu der zuvor vorgestellten Physical-Computing-Plattform Ar-duino, die mit einem Mikrocontroller ausgestattet ist, bedient sich das Raspberry-Pi eines 700 MHz ARM-Prozessors mit ausgelagerten RAM in der Größe von256MB/512MB und mehreren GB an Programmspeicher durch Einbinden ei-ner Speicherkarte. Die integrierte Peripherie und weitere Spezifikationen kön-nen der Tabelle 3.2 entnommen werden.Vergleicht man schon alleine die Größe des Arbeitsspeichers und der Rechen-leistung der CPU des Raspberry Pi, mit deren der momentan verfügbaren

38 3. Hardware

Arduino-Varianten, fällt das Raspberry Pi mit seinen deutlich höheren Wertenauf. Das muss jedoch nicht zwangsläufig bedeuten, dass diese Plattform diegeeignetere Wahl für I/O-Anwendungen darstellt, da hier im Vergleich zu ei-nem Mikrocontroller noch ein Betriebssystem im Hintergrund seine Routinenund Prozesse ablaufen lässt und die Ausführung dementsprechend verlang-samt. Gerade bei Echtzeitanwendungen stößt man hier an die Grenzen desRaspberry Pi. Durch Echtzeit-Betriebssysteme wie beispielsweise RISC OS13,kann die Plattform zwar in die Richtung eines Mikrocontrollers verschobenwerden, ein Arduino ist trotz alledem noch optimierter für diese Art von An-wendungen.

Abbildung 3.7.: Raspberry Pi Model-B

Diesen Sachverhalt bringen Matt Richardson und Shawn Wallace in [RiWa12]schön auf den Punkt:

When you have a problem that requires exact control in realtime, such as a controller for a 3D printer. [...] Raspbian is nota Real Time operating system, and programs can’t necessarilydepend on the same “instruction per clock cycles” rigor of amicrocontroller

Zudem arbeiten die Pins des Raspberry Pi mit 3,3V und tolerieren keine 5V,was einige Peripheriekomponenten jedoch benötigen.Dafür hat man im Gegensatz zu der Arduino-Plattform ein Betriebssystem sei-ner Wahl, das auf der verwendeten ARM-Architektur aufbaut, zur Verfügung

13Hier wird ein Echtzeitkernel innerhalb eines OS-Kernels ausgeführt und sorgt für die zeit-lich genauere Ausführung und Steuerung.

3.3. Physical-Computing-Plattformen 39

und hat zudem deutlich höhere Speicherwerte und eine höhere Rechenleis-tung.So lange man keine Echtzeit Anwendungen verwenden will, kann man dieGPIO-Pins problemlos zum Steuern von LEDs und dergleichen gebrauchen.Außerdem können über die zusätzlichen Schnittstellen: SPI, I2C und UARTviele Module integriert werden. In unserem Fall wäre das der SRF02-Ultraschall-Abstandmesser, der durch I2C mit der Plattform verbunden wurde.Im Unterschied zur Arduino-Plattform ist das Raspberry Pi daher eher alsMiniatur-PC anzusehen. So ermöglichen Audio- und Grafikausgänge (HDMIund Video-OUT), sowie USB-Eingänge für Tastatur und Maus einen Einsatzim Desktop-PC-Bereich.

Nimmt man zudem das Modell B, so erhält man zusätzlich einen integrier-ten Ethernet-Controller, wodurch man diese Plattform in ein kabelgebunde-nes LAN einbinden kann. So wird über LAN oder WLAN (per WLAN Sticküber USB) das Raspberry Pi zu einem Teil des ’Internet of things’14. DieseNetzwerk-Funktionalitäten besitzt das Arduino, abgesehen von dem Arduino-Ethernet und Arduino-YÚN nicht out of the box, diese können jedoch inzwi-schen leicht auf Basis von Arduino eigens gefertigten Shields erreicht wer-den15.Zudem kann, wie auch die Arduino-Plattform, das Raspberry Pi, den für Sen-sornetzwerke oft genutzten ZIGBEE-Stack 16, verwenden. Dafür ist die Platt-form mit einer Zusatzplatine mit dem Namen RaspBee, welche bei ArduinoXbee genannt wird, zu ergänzen.

Im Gegensatz zu den Shields der Arduino Plattform haben die aufsteckbarenModule auf den verfügbaren Pins hier keinen speziellen Namen, sondern wer-den einfach als Erweiterungsplatinen bezeichnet. Hier gibt es momentan nochkeine allzu große Auswahl, wenn man im Gegensatz die Arduino-Plattformheranzieht. An dieser Stelle weisen wir besonders auf zwei Module hin: DasGertboard und die Arduino Shield Bridge.

Gertboard: Das Gertboard ist eine I/O-Erweiterungsplatine, die das Raspber-ry Pi um einen ATmega Mikrocontroller bereichert und somit Echtzeitanwen-dungen durchführbar macht.

Arduino Shield Bridge: Die Arduino Shield Bridge ist ein Adapter, mittelsdessen man Arduino Shields direkt auf dem Raspberry Pi nutzen kann. Desweiteren kann über die Bibliothek arduPi ursprünglich nativer Arduino Codefür das Raspberry Pi kompiliert werden.

Als OS laufen die verschiedensten Linux-Distributionen, die in Tabelle 3.2 nä-her betrachtet werden können. Die am gängigsten genutzte Distribution ist14Die Bezeichnung für embedded Geräte mit Internetanschluss15Das wären insbesondere:Arduino WiFi Shield,Arduino Wireless SD Shield,Arduino WiFi

Shield,Arduino Ethernet Shield und Arduino GSM Shield.16Standardisierter Protokollstapel nach IEEE 802.15.4

40 3. Hardware

Abbildung 3.8.: XBee-Shield aufgesteckt auf einer Arduino Shield Bridge, diewiederum auf einem Raspberry Pi aufgesteckt ist. Schön zuerkennen, ist die unkomplizierte und kompakte Integrationder Module. [chac13]

hierfür Raspedian, ein Debian-Derivat. Durch die Verwendung von GNU/Li-nux stehen somit natürlich auch die Repositories der jeweiligen Distributionenzur Verfügung und können je nach Belieben die Funktionalität der Plattformerweitern. Ein schnelles sudo apt-get install <Paket> in Raspedian zum Beispiel,ermöglicht auf schnelle und unkomplizierte Art und Weise Bibliotheken, An-wendungen inklusive benötigter Abhängigkeiten zu installieren.

Betrachtet man die Leistungsaufnahme, so wird aus Tabelle 3.2 ersichtlich,dass wir im Gegensatz zum Arduino17 eine vielfach höhere Leistungsauf-nahme der puren Leiterplatte ohne zusätzlicher angesteckter Peripherie zubeachten haben.

Beim Thema Lizenzen und verfügbaren Platinenlayouts sieht es bei dieserPlattform ein wenig anders als bei Arduino, mit seinem puren Open SourceCharakter, aus. Für das Raspberry Pi sind nur insoweit quelloffene Informa-tionen bekannt, so dass Erweiterungsmodule dadurch erstellt werden könnenund man einen Überblick über dessen Aufbau erhält. Hier wurde nicht be-absichtigt, dass man die Platine selbst erstellen kann, um damit Klone undVarianten fertigen zu können.

Vergleicht man zudem die Preise der zwei Plattformen miteinander, so liegtmomentan das Raspberry Pi bei ca. 39 EUR18 und das Arduino Uno bei ca.23,80 EUR und ist somit fast doppelt so teuer. Dafür bekommt man jedochauch einen kleinen Miniaturrechner. Reichen dagegen die Spezifikationen fürdas Arduino Uno, sollte man sich die Frage stellen, warum man eine dop-pelt so teure und mit einer höheren Leistungsaufnahme versehene Plattformauswählen möchte.

So kann abschließend als Fazit gesagt werden, dass das Raspberry Pi ein ande-res Anwendungsspektrum, im Vergleich zum Arduino abdeckt. Das Raspber-ry Pi ist nun einmal eher ein Miniaturrechner, als ein Mikrocontroller. Beide

17Arduino Uno: Leistungsaufnahme bei 7-12V liegt bei unter <1 Watt für das reine Board.18inklusive Mehrwertsteuer

3.3. Physical-Computing-Plattformen 41

verfügen sie jedoch über Schnittstellen wie I2C und können somit mit anderenModulen oder direkt über ihre Pins mit anderer Peripherie und der Umweltagieren und zeichnen sich somit als Physical-Computing-Plattformen aus.

Modell A Modell BPreis (inkl. MwSt): 27 EUR 34 EUR

Größe: Kreditkartengröße85,60 mm × 53,98 mm

× 17 mm

Kreditkartengröße85,60 mm × 53,98 mm

× 17 mmSoC Broadcom BCM2835 Broadcom BCM2835

CPU: VIA ARM1176JZF-S(700 MHz)

VIA ARM1176JZF-S(700 MHz)

GPU: Broadcom VideoCoreIV

Broadcom VideoCoreIV

Arbeitsspeicher(SDRAM):

256 MB 512 MB (bis Oktober2012 256 MB)

USB 2.0 Anschlüsse: 1 2 (über integriertenHub)

Videoausgabe: FBAS, HDMI FBAS, HDMITonausgabe: 3,5 mm-Klinkenstecker

(analog), HDMI(digital)

3,5 mm-Klinkenstecker(analog), HDMI

(digital)Nicht-flüchtiger

Speicher:SD (SDHC und

SDXC)/MMC/SDIO-Kartenleser

SD (SDHC undSDXC)/MMC/SDIO-

KartenleserNetzwerk: – 10/100 MBit

Ethernet-Controller(LAN9512 des

Herstellers Han Run)Schnittstellen: Bis zu 16 GPIO-Pins,

SPI, I2C,UARTBis zu 16 GPIO-Pins,

SPI, I2C,UARTEchtzeituhr: – –

Leistungsaufnahme: 5 V, 500 mA (2,5 Watt) 5 V, 700 mA (3,5 Watt)Stromversorgung: 5 V

Micro-USB-Anschluss(Micro-B), alternativ 4× AA-Batterien

5 VMicro-USB-Anschluss(Micro-B), alternativ 4× AA-Batterien

Betriebssysteme: Arch Linux ARM,Debian GNU/Linux,

Fedora, FreeBSD,NetBSD, Plan 9,

Raspbian OS, RISC OS,Slackware Linux

Arch Linux ARM,Debian GNU/Linux,

Fedora, FreeBSD,NetBSD, Plan 9,

Raspbian OS, RISC OS,Slackware Linux

Tabelle 3.2.: Modellübersicht Raspberry Pi [Wiki13e][Wiki13f]

42 3. Hardware

3.3.3. Beaglebone (Black)

Das Beaglebone Black ist ein Einplatinencomputer der Firma Texas Instru-ments mit Open Source Hardwarekomponenten19. Somit kann das Platinen-layout frei eingesehen werden. Es liegt in den Varianten Beaglebone und Beag-lebone Black vor. Die Variante Beaglebone wird jedoch nicht mehr produziert.

Abbildung 3.9.: Beaglebone Black

Bei dieser Plattform ist besonders hervorzuheben, dass keinerlei Lizenzenexistieren.Das Beaglebone (Black) stellt im Vergleich zu dem größeren zuvor erschie-nenen Einplatinencomputer BeagleBoard eine größere Erweiterbarkeit undMikrocontroller-Funktionalitäten bereit.

Wenn man Abbildung 3.9 betrachtet, fällt einem dabei sofort auf, dass diePlattform über eine Fülle von Pins verfügt und RAM und CPU separat vor-liegen. Es ist quasi eine Kombination von Arduino und Raspberry Pi. So sindauf der Platine ein AM335x 720MHz ARM Cortex-A8 beziehungsweise einAM335x 1GHz ARM Cortex-A8 verbaut, was für viel Rechenleistung sorgt.Der Arbeitsspeicher ist mit 256MB DDR2 / 512 MB DDR3L auch für vieleAnwendungen im Vergleich zur Arduino-Plattform sehr hoch dimensioniert.

Die Plattform ist mit zwei programmierbaren Echtzeit-Einheiten (PRU) ver-sehen, die im Vergleich zum Raspberry Pi neue Anwendungsgebiete erschließt.Durch diese 2x PRU 32-bit RISC CPUs / 2x PRU 32-bit Mikrocontroller, wirdaus dem Miniaturrechner ein System mit Echtzeitfunktionalität, wie bei ei-nem Arduino. Diese zwei programmierbaren Echtzeit-Einheiten machen da-

19Bis auf die PowerVR-GPU.

3.3. Physical-Computing-Plattformen 43

mit Projekte realisierbar, an denen ein Raspberry Pi bei zeitkritischen Anwen-dungen scheitern würde. Interessant hierbei ist, dass die zwei PRUs auf einengemeinsamen Bus zusammen mit einem Interrupt-Controller zugreifen. So istes möglich, dass die zwei PRUs komplett unabhängig voneinander oder auchgemeinsam agieren. Durch den zusätzlichen Interrupt-Controller wird außer-dem eine Kommunikation auf Geräteebene in beide Richtungen ermöglicht.So kann die Host-CPU mit in den jeweiligen Programmablauf und umgekehrtintegriert werden.

Abbildung 3.10.: Aufbau des PRU-Subsystems[Inst13]

Die Plattform stellt neben weiteren, die für uns interessanten Schnittstellen:69 GPIO-Pins, McASP, CAN0, SPI1, I2C, UART0 und TTL bereit. Somit istauch hier eine Erweiterbarkeit mit weiteren Modulen möglich.

Auch ein Client und ein Host Port sind für die Kommunikation mit weitererPeripherie vorhanden, was das System wie das Raspberry Pi, flexibler macht.

Um es in das ’Internet of Things’ integrieren zu können, gibt es die Mög-lichkeit über WLAN-Stick oder direkt über den integrierten Ethernet-Port mitdem jeweiligen Netzwerk zu interagieren.

Die Leistungsaufnahme ohne zusätzliche Komponenten liegt bei max. 2,4Watt / 2,5 Watt, was wiederum um ein vielfaches über dem Arduino Unoliegt.

Der Preis für ein Beaglebone Black liegt momentan bei circa 47 EUR, und istsomit nicht wesentlich teurer als ein Raspberry Pi. Entscheidend hier bei derAuswahl ist der genaue Verwendungszweck und die benötigten Ein- und Aus-gänge, wie USB, Video-Out, ecetara, sowie die vorhandenen Erweiterungspla-tinen und Bibliotheken.

Da wir es hier mit einem Einplatinen-Computer mit PRUs zu tun haben undnicht mit einem reinen Mikrocontroller, verwendet das Hauptsystem ein Be-triebssystem. Davon abgekoppelt oder eingebunden arbeiten die PRUs ihrenProgrammcode ab. Das OS kann je nach Version auf einer Micro-SD Karte

44 3. Hardware

oder beim Beaglebone Black auch auf dem internen 2GB Flash Speicher aus-geführt werden.Folgende Linux20 OS werden unterstützt: So wird neben Angström Linux, daszu Beaglebone (Black) kompatibel ist, auch Android und Ubuntu unterstützt.

In dem folgenden Absatz, werden wir uns nun noch detaillierter das neuereBeaglebone Black anschauen.

Das Beaglebone Black ist ein Upgrade des Beaglebones. Es besitzt einen zu-sätzlichen internen 2GB 8-Bit eMMC Flash Speicher und einen NEON Floating-Point Accelerator. Gerade durch verbesserte Handhabung von Fließkomma-zahlen, können hier interessante Anwendungen geschrieben werden, die trotzalledem noch schnell ausführbar sein sollten.Für unser Projekt jetzt weniger interessant, jedoch dennoch vorhanden, isteine Micro-HDMI-Schnittstelle für die Bildausgabe.

Weitere Spezifikationen dieser Physical-Computing-Plattform können der Ta-belle 3.3 entnommen werden.

Erweiterungsmodule - Capes:Beim Beaglebone (Black) werden die Erweiterungsplatinen als Capes21 be-zeichnet. Wie bei Arduino kann so im Baukastenstecksystem schnell und ein-fach mehr Funktionalität hinzugefügt werden. So stellt beispielsweise das Be-agleBone TiWi-5E-Cape 2.4 and 5 GHz IEEE 802.11 a/b/g/n und Bluetooth 4.0für diese Plattform bereit. In Abbildung 3.11 sieht man exemplarisches diesesCape.

Abbildung 3.11.: Cape: BeagleBone TiWi-5E [http13a]

20Wir haben hier mit Absicht nicht GNU/Linux geschrieben, da Android recht wenig mitGNU im Gegensatz zu zum Beispiel Ubuntu zu tun hat.

21In [http13a] kann eine Übersicht über die momentan verfügbaren Erweiterungsmodulegefunden werden.

3.3. Physical-Computing-Plattformen 45

Tabelle 3.3.: Spezifikation des Beagleboard Black [http13b]

46 3. Hardware

Abschließend kann diese Physical-Computing-Plattform wie folgt charak-terisiert werden:Das Beaglebone (Black) ist für die Entwicklung und für das Prototyping ei-ne optimale Plattform. Sie hat viele Schnittstellen in vielfachen Variationen,besitzt mit 700MHz / 1GB und 256 MB / 512 MB viel Raum für aufwendi-ge Programme und ist durch die zwei integrierten PRUs in der Lage Echt-zeitfunktionalität bereitstellt. Nur wenn man den Energieverbrauch mit demeines Arduino vergleicht, fallen die für bestimmte Projekte unnötigen inte-grierten Peripheriekomponenten, mit ihrer zusätzlichen Leistungsaufnahme,ins Gewicht. Diese erschweren den mobilen Einsatz mittels Batterie bezie-hungsweise Akkumulatoren.

3.4. PeripherieDie Liste der Peripheriemodule, die wir für unseren akustisches Schwarm-netzwerk benötigen, hält sich mit einem einzigen Modul, einem Ultraschall-Sensor, in Grenzen.

Abbildung 3.12.:

Nachdem wir uns festgelegt haben, einen Ultraschall-Transceiver als fertigesModul zu beschaffen, um zeitaufwendige Kalibrierungen zu vermeiden undzudem einen akustischen Schwarm in möglichst geringer Zeit aufbauen zukönnen, entschieden wir uns für den Ultraschallsensor SRF02 der Firma De-vantech, mit integriertem Transceiver. In Kapitel 4 gehen wir genauer auf dieBeweggründe hierfür ein.

Wir werden nun in Folge detaillierter auf die SRF-Reihe von Ultraschallsenso-ren eingehen, um anhand derer den Begriff der Richtungscharakteristik zuerläutern, die nötigen Grundlagen der Ultraschalltechnik und die Spezifika-tionen für den späteren Umgang mit dem SRF02 kennenzulernen.

3.4. Peripherie 47

Die Namensgebung Ultraschallsensor ist an sich irreführend, da ein Ultra-schallsensor kein reiner Empfänger, sondern auch einen Sender darstellt undsomit auch in die Gruppe der Aktuatoren einzuordnen ist. Kernstück diesesUltraschallsensors ist der Piezo-Schallwandler, ein Piezo22-Keramik-Plättchen,mit an die Richtungscharakteristik und Frequenz angepassten Maßen.

Abbildung 3.13.: Halbstreuwinkel zwischen zwei -6 dB Punkten eines Ultra-schallwandlers [Olym06]

Die Richtungscharakteristik kann, laut [Olym06] wie folgt für den Halbstreu-winkel zwischen zwei -6 dB Punkten, der in Abbildung 3.13 veranschaulichtwird, berechnet werden:

f = Frequenz [Hz]α2 = Halbstreuwinkel zwischen zwei -6 dB Punkten [◦]D = Durchmesser des Piezoplättchens [m]c = Schallgeschwindigkeit[m/s]

sin(α

2) = 0, 515c

0, 514cf D

(3.1)

Somit ist der Öffnungswinkel des Haupt-Strahls reziprok proportional zu fund/oder D. Dementsprechend kann die Richtungscharakteristik für einengrößeren Winkelbereich durch Senkung der Frequenz und/oder Reduzierungdes Durchmessers erreicht werden. Für λ ≥ D tendiert die Form zur Kreisbil-dung.Dies kann auch sehr schön in Abbildung 3.14 in Kombination mit Tabelle

22Auf S.110 in [WiHW11] wird der Piezo-Effekt wie folgt beschrieben: ’Der 1880 von Jacquesund Pierre Curie entdeckte piezoelektrische Effekt besteht aus einer linearen elektrome-chanischen Wechselwirkung zwischen den mechanischen und den elektrischen Zustän-den in einem Kristall. Eine mechanische Deformation des Kristalls erzeugt eine zu dieserDeformation proportionale elektrische Ladung, die als elektrische Spannung abgegriffenwerden kann (direkter piezo-elektrischer Effekt). Umgekehrt kann durch Anlegen einerelektrischen Spannung an den Kristall in diesem eine mechanische Deformation erzeugtwerden (reziproker oder inverser piezoelektrischer Effekt). ’

48 3. Hardware

3.4 eingesehen werden. Vergleicht man in Abbildung 3.14 zum Beispiel dieRichtungscharakteristik und den Halbwertwinkel von den Ultraschallsenso-ren SRF235 und SRF10 so sieht man bei dem SRF235, der mit 235 kHz im Ge-gensatz zu 40kHz betrieben wird, eine deutlich gerichtetere Ausbreitung derSchallwellen. Die Abweichung der Richtungscharakteristik zwischen SRF04und SRF10 ist topologisch bedingt, da hier Sender und Empfänger separatvorliegen und dementsprechend einen anderen Abstand einnehmen können.

Die Reichweite der Ultraschallsensoren ist zudem abhängig von der Größedes Piezo-Plättchens, um elektrische Energie in Schallenergie umzuwandelnund zudem von den Absorptionseigenschaften der Luft. Hier ist hervorzuhe-ben, dass der Absorptionsgrad mit der Frequenz positiv korreliert. Das siehtman auch gut in Formel 3.2.Als Annäherung laut [LeSW09], kann für die praktische Anwendung, die Nä-herungsformel für den totalen Dämpfungskoeffizienten von H.O. Kneser füreine ebene Welle, die im Temperaturbereich von 0◦C bis 20◦C und bei Nor-maldruck(1atm = 101,325 kPa), angewandt werden:

α =12(11, 7 + 0, 1υ)10−12 f 2 +

π10−5(0, 81 + 0, 022υ)τ f 2

1 + 4π2τ2 f 2 (3.2)

Temperatur(υ) in ◦C; Frequenz(f) in Hz; totaler Dämpfungskoeffizienten(α) inm−1; Relaxionszeit(τ) in s.

Dafür notwendig ist die empirisch bestimmte Relaxionszeit, die laut [LeSW09]in der nachfolgenden Formel, abhängig vom Wasserdampfpartialdruck(h) be-stimmt wird:

1τ= 1, 92 · 105h1,30s−1 (3.3)

Für die Schallausbreitung von ebenen Schallwellen im Freien gibt [LeSW09],das in der Praxis häufig genutzte Maß

D = 8, 686αx (3.4)

für den Schalldruckpegel

Lp = 20 log10(pp0) = 20 lg(

pp0)[dB] (3.5)

Normaldruck(p0); Druck(p) an.

Die Schallabsorption kann somit als linear steigend mit der Frequenz be-trachtet werden. Zur Erhöhung der Amplitude wird dieses Piezo-Plättchenauf eine metallische Unterlage geklebt, da im Vergleich zu Festkörper- undWasser-Schall mehr Energie benötigt wird, als eine reine Deformation desPiezo-Plättchens alleine bewerkstelligen könnte.

3.4. Peripherie 49

Abbildung 3.14.: Auszug aus den FAQ von Denvantech Ltd: Reflektionscha-rakteristiken der verschiedenen SRF-Modellen [Ltd13]

50 3. Hardware

Sensor Communication MinimumRange

MaximumRange

Angle∗ Echoes∗∗ Ranging Time Notes

SRF01 Serial 0 cm 6 m 45◦ One 70 ms ASRF02 I2C / Serial 15 cm 6 m 45◦ One 70 ms ASRF04 Digital 3 cm 3 m 45◦ One 100 µs - 36 msSRF05 Digital 3 cm 4 m 45◦ One 100 µs - 36 msSRF06 Analog 2 cm 5 m 55◦ One 70ms - 100 msSRF08 I2C 3 cm 6 m 45◦ 17 65 ms B CSRF10 I2C 3 cm 6 m 60◦ One 65 ms A B

SRF235 I2C 10 cm 1 m 15◦ One 10 ms A DSRF485 RS485 Serial 30 cm 5 m 45◦ One 70 ms A

SRF485WPR RS485 Serial 60 cm 5 m 30◦ One 70 ms A∗: Approximate angle of the sensor cone at 1/2 sensor range (see diagram above).∗∗: The number of echoes recorded by the sensor.These are the recorded echoes from the most recent reading, and are overwritten with each new ranging.A: These sensors are smaller than the typical (SRF 04 / 05 / 08) size.B: Range time can be adjusted down by adjusting the gain.C: This sensor also includes a photocell on the front for light detection.D: Operates at a higher 235kHz frequency.See the SRF235 Technical Specifications page for how this affects sensor performance.

Tabelle 3.4.: Übersicht der verfügbaren Ultraschallsensoren von Devantech[Robo13a]

Der Vorteil von diesem Aufbau sind laut [WiHW11]:

• ’Die schädliche Schallabstrahlung ins Sensorinnere wird sofort absor-biert;’

• ’Robustheit gegenüber externen Belägen auf der Membran (z.B. durchSchmutz oder Feuchtigkeit) und frequenzverändernden Temperatur- /Alterungseinflüssen wird erhöht.’

Neben des Piezo-Plättchens sind natürlich noch weitere Bestandteile in einemUltraschallsensor notwendig, um damit eine Messung oder wie in unserenFall eine Datenübertragung per Schall, zu bewerkstelligen.

Betrachten wir hierzu Abbildung 3.15 genauer. So ist zum einen ein Vorver-stärker, der im Fall, wenn der Transceiver als Receiver fungiert, notwendig umdas abgeschwächte Signal, dass man empfangen möchte auf ein vernünftigesNiveau für die Weiterverarbeitung zu transformieren. Daneben gibt es wie imFall des SRF02, der zur Abstandsmessung ausgelegt ist, einen zeitabhängi-gen Verstärker (Time-Gain-Compensation Amplifier - TGC), der je nach Lauf-zeit des zuvor abgesonderten Signals eine Verstärkung vornimmt. So werdenEchos die eine längere Laufzeit hatten und somit einer höheren Absorptionunterlagen mit einem höheren Wert verstärkt. Dies senkt die Leistungsauf-nahme bei der Abstandsmessung.

Zu erwähnen ist noch, dass das Piezo-Plättchen, eine Eigenfrequenz aufweist,die der jeweiligen zur Nutzung beabsichtigten Frequenz angepasst ist. So istdas beim SRF02 40, 0± 1.0 kHz, in diesem Bereich erreichen wir die höchsteelastische Verformung und somit durch Veränderung der Kristallstruktur, die

3.4. Peripherie 51

Abbildung 3.15.: Aufbau eines Ultraschallsensors [Corp13]

Abbildung 3.16.: Sensitivität und Schalldruckerzeugung des SRF02 im Bereichvon 40kHz ist die Resonanzfrequenz als maximal ersichtlich[Air13]

52 3. Hardware

höchsten Sensitivität, beziehungsweise den höchsten Schalldruckpegel. Dieswird an Hand Abbildung 3.16 veranschaulicht. Dabei stellt 400ST160 einenSender und 400SR160 ein Empfangsmodul dar. Nach erfolgreichem Empfangeines Signals, im Falle des SRF02 ist dies ein Stoß von 8 Impulsen mit der gän-gigen Frequenz von 40kHz für Ultraschallsensoren, wird ein Bandpassfilter23

genutzt, um nur den eigens für den Sensor vorgegebenen Frequenzbereich,für die Weiterverarbeitung ohne Reduktion der Amplitude zuzulassen. Dabereits durch die Eigenfrequenz des Piezo eine Filterung stattgefunden hat,ist dies zur weiteren Verbesserung zur Fehlerkorrektur zu betrachten.

Nachgeschaltet ist oft meist ein Komparator, der die Eingangsspannung misstund mit einer Referenzspannung vergleicht und in Folge dessen selbst einedigitale 0/1 zur weiteren Verarbeitung übermittelt. Durch dieses Bauteil istes möglich, die durch Resonanzfrequenz und den Bandpassfilter zuvor amwenigsten abgeschwächten Spannungsamplituden (analoges Signal) inklusiveden zwei Verstärkungen der vorgeschalteten Module zu einem digitalen Wertüberzuführen.

Der im Anschluss verbundene Mikrocontroller stellt die Funktionen zur Zeit-bzw. Längenmessung durch Programmierung, über die diversen Schnittstel-len des Ultraschallsensors anderen Mikrocontrollern oder Rechnern zur Ver-fügung. Diese wären beim SRF02: I2C und RS232 (TTL).

Im Gegensätzlichen Fall, wenn somit der Ultraschallsensor als Sender fun-giert, wird ausgehend von einem MCU, ein Zähler und das Signal für einenStoßimpuls gestartet, der das Zeitintervall bis zum Erreichen des Echos misstund berechnet.

Darauf folgt ein Pulsgenerator, der entweder direkt oder indirekt über einenSchwingkreis oder Taktgeber erzeugt wird.

Als letztes vor dem Piezo steht ein Impedanz-angepasster Schaltkreis füreinen maximalen Energietransfer bereit.

Abbildung 3.17 zeigt einen puren Transceiver ohne MCU, der in einem Ultra-schallsensor verbaut wird und hier als Schallwandler fungiert. Bei dem SRF02,den wir benutzen, handelt es sich um die Variante ganz links in der Abbil-dung mit dem Kunststoffzylinder. Tabelle 3.5 zeigt weitere Spezifikationen fürden im SRF02 verbauten Schallwandler.

Nachdem inzwischen sämtliche Grundlagen des Ultraschallsensors mit inte-griertem Transceiver-Modul erläutert wurden, wollen wir näher auf den ver-wendeten SRF02 und dessen Besonderheiten eingehen. Hierzu betrachten wir23Ein Bandpassfilter ist die Kombination eines Tief- und Hochpassfilters und wird über die

Kombination von Widerständen und/oder Kondensatoren und/oder Spulen über einenSchwingkreis erzeugt.

3.4. Peripherie 53

Abbildung 3.17.: [Air13]

Tabelle 3.5.: Aufbau eines Ultraschallsensors [Air13]

54 3. Hardware

zu aller erst Abbildung 3.18. Hier sieht man auf der Oberseite den zylindri-schen Schallwandler24 auf einer Leiterplatte befestigt. Auf dessen Unterseitedieser Leiterplatte befinden sich ein MCU (links) und ein ?(rechts), sowie di-verse Widerstände und eine rote LED. Die LED wird bei jedem Sende- undEmpfangsvorgang aktiviert und dient als Kontrollleuchte für die erstellte IDfür ein I2C-Bussystem. Bei den Anschlüssen sehen wir eine +5V Spannungs-versorgung, eine Erdung sowie eine Modus-Schnittstelle, die für das Einstel-len als I2C oder TTL zuständig ist. Für I2C ist zudem die benötigte Signal undTaktleitung noch vorhanden. Bei TTL sind dies dementsprechend Tx und Rx25.

Abbildung 3.18.: Auszug aus dem Datenblatt des SRF02: Anschlüsse und Be-maßung [robo13c].

Da wir bereits zuvor festgestellt haben, dass wir mit einem einzigen Ultra-schallsensor eine gerichtete Wellenausbreitung bekommen, ist die Möglichkeitweitere Ultraschallsensoren, zur Anpassung der Gesamt- Richtungscharakte-ristik unseres Knotens zu integrieren unter Umständen nötig. Dies ermög-licht der SRF02, da wir hier mit I2C oder TTL bis zu 16 weitere Sensoreneinbinden können. Diese Beschränkung auf maximal 16 hängt nicht durchden möglichen Adressraum von I2C oder TTL zusammen, sondern von demID-Register, das mit 4 bits maximal 16 verschiedene IDs ermöglicht. Dafürmuss jedoch die ID zuvor für jeden Ultraschallsensor mit einen neuen, nochnicht verwendeten Wert, beschrieben werden. Abbildung 3.19 zeigt eine mög-liche Positionierung, wobei festzuhalten ist, dass bei dem Projekt Flying Robot

24Im Datenblatt wurde ein anderer Zylinder verwendet, was jedoch für die weiteren Erläute-rungen nicht von Bedeutung ist.

25Tx = lesen Rx = schreiben

3.4. Peripherie 55

der pure Schallwandler mit weiteren Komponenten als Transceiver-Modul ge-nutzt wurde und nicht der Ultraschallsensor SRF02, Verwendung fand.

In den nachfolgenden Absätzen werden wir uns näher mit den Registern desSRF02 befassen, die ein wichtiger Bestandteil für die Steuerung und Daten-übertragung darstellen. Es sind sechs Register vorhanden, von denen Re-gister 1 ungenutzt ist. Register 0 dient als Befehlsregister mit dem wir denUltraschallsensor von außen steuern können. Bei dem Auslesen dieses Re-gisters, was für uns später eine entscheidende Rolle in Bezug auf die Syn-chronisierung der Datenübertragung spielen wird, wird die momentan in-stallierte Firmwareversion als Rückgabewert zurückgegeben. Register 2 und3 dienen uns als Leseregister für die Rückgabe der Messwertes nach einemMessvorgang. Hierbei stellt Register 2 das High Byte und Register 3 das LowByte Register dar. Die letzten zwei Register, 4 und 5 geben den minimalenAutotuning-Wert als High und Low Byte zurück. Der Autotuningwert ist dieminimale Entfernung, die nach Ablauf des internen Algorithmus und derautomatischen Kalibrierung eingestellt, momentan verwendet wird. Da derSchallwandler nach dem Senden noch etwas nach schwingt, ist in dieser Zeitkein Empfang möglich. Hier stellt der interne Algorithmus des SRF02 sicher,dass die minimale Zeitdauer für eine nicht verwendete Eingangsmessung ge-nutzt wird. In unserem Fall spielt dieser Wert keine Rolle, da wir nicht gleich-zeitig Senden und Empfangen wollen, da wir nur mit einer einzigen Frequenzarbeiten. Bei einer Abstandsmessung hätte dies wiederum den Einfluss, dasszu nahe Gegenstände nicht erfasst werden könnten, da die Laufzeit des Echosin die noch vorhandene Schwingung des SRF02 einfließen würde.

Tabelle 3.6.: Übersicht der vorhandenen Register des SRF02. [robo13c]

56 3. Hardware

Kommen wir nun zu den möglichen Befehlen, die uns der Ultraschallsensorzur Verfügung stellt. Hier werden wir auf die verfügbaren I2C-Befehle nähereingehen, da wir diese für unser Projekt implementiert haben. Die vollstän-dige Übersicht kann man in Tabelle 3.7 einsehen. Wir gehen hier auf die ver-schiedenen Abschnitte ein.

Die erste Reihe an Befehlen 0x50, 0x51 und 0x52 initiieren einen Messvor-gang, das heißt es wird in diesem Fall ein Burst an 40 kHz Impulsen gesendetund auf das Echo gewartet. Unterschiedlich sind die drei Befehle einzig indem Rückgabewert, der als Längenmessung in Zentimeter oder Inches undals Zeitmessung in µs ausgegeben wird. Diese Mess-Modi sind für uns nichtinteressant, da wir keine eignen Echos empfangen wollen, sondern Signalevon anderen Knoten. Dieser Modus ist der Standard bei den meisten Ultra-schallsensoren, was wiederum bedeutet, dass ein Upgrade zu einem Akustik-Modem nicht bei jedem Ultraschallsensor ohne weiteres möglich ist.

Der nächste Abschnitt in Tabelle 3.7 sind die Befehle für den puren Mess-vorgang mit Zeit- oder Längenmessung. Er wird hier als synchroner Mess-vorgang im Datenblatt bezeichnet, da er dafür vorgesehen ist mehrere SRF02gleichzeitig zur Abstandsmessung heranziehen zu können. So kann ein Burstausgesendet werden und von mehreren versetzt montierten Empfangs-SRF02registriert werden, um unterschiedliche Reflexionswinkel des Echos zu kom-pensieren oder als Linear Array eine parallele Schallausbreitung zu gewähr-leisten. Für uns ist hier vor allem 0x58 von Interesse, da wir feststellen wollen,ob in einem bestimmten Zeitintervall, dass durch die synchrone Taktung beiden Knoten vorgegeben ist, empfangen wurde und als logische 1 interpretiertwerden kann.

Tabelle 3.7.: Befehlsübersicht für die verschiedenen Register des SRF02.[robo13c]

3.4. Peripherie 57

Von weiterer wichtiger Bedeutung für uns ist der Befehl 0x60 der einen 8 zy-klischen 40kHz Burst sendet. Dies machen wir uns für die Ausstrahlung einerlogischen 1 zu Nutze. Leider wird nicht angegeben, wie lange die Wartezeitzwischen zwei 0x60 Befehlen liegen muss. Daher schätzen wir den absolutmöglichen Minimalwert ohne Mikroprozessor-Aktion wie folgt:

t =8

40000= 0, 2µs (3.6)

Dabei fehlt natürlich noch die durch die Taktung des Mikroprozessors desSRF02 und dessen Programmablauf weiter verzögernd wirkenden Faktoren.Jedoch wird hier schon ersichtlich, dass wir mit dem SRF02 eine geringereBitrate in Kauf nehmen müssen, als wenn wir ein Transceiver-Modul mit eige-nem Schwingkreis betreiben würden. Dafür erhalten wir natürlich auch einesehr robuste logische 1 bei der Übertragung, da sie quasi mit sieben Backupsversehen ist.

Befehl 0x60 ist für unser Projekt weniger von Bedeutung, da wir in erster Liniekeine Abstandsmessung durchführen wollen. Der Befehl 0x60 startet nebender sowieso schon beim Einschalten stattfindenden Kalibrierung des Ultra-schallsensors, um das Nachschwingen des Piezo festzustellen, eine weitereKalibrierung des SRF02, um die minimal möglichen Messwerte festzustellen.

Der letzte Abschnitt ist die Kette der Befehle zur Änderung der ID des Sen-sors. Dieser Abschnitt wird erst bei Verwendung von mehr als einem SRF02oder bei mehreren Teilnehmern neben unserer Arduino-Plattform interessant.Hier müsste sichergestellt werden, dass jedem Teilnehmer eine einzigartigeID zugeteilt wird.

Bei der Reichweite laut Datenblatt wird von 15cm bis 6m gesprochen, wassich jedoch auf eine Abstandmessung bezieht. Somit können wir die maxi-male Reichweite mit mindestens 12m (2x6) veranschlagen. Da das ausgesen-dete Signal natürlich auch Absorption und Transmission bei Auftreffen aufein Hindernis ausgesetzt ist. Dies erweitert bei uns, da wir bei einer reinenDatenübertragung, die Entfernung um die zuvor erwähnten Faktoren, die beiuns nicht auftreten, da wir nicht mit Echos arbeiten.

Als Besonderheit des SRF02 sei noch erwähnt, dass eine automatisch zeitlichbedingte Verstärkung des Signals erfolgt. Somit ist hier ein TGC implemen-tiert. Das hat für uns insbesondere den Nachteil, dass Signale die anfangseines Messintervalls eintreten nur gering zusätzlich verstärkt werden. Dersonst übliche Befehl bei Ultraschallsensoren zum Einstellen der Verstärkung,der normalerweise zur Begrenzung der Reichweite eingesetzt wird, fehlt hierleider.

Ein für uns noch sehr wichtiger Punkt in Bezug auf den Messvorgang stelltdie maximale Messdauer dar. Sie beträgt circa 65ms und gibt entweder diesen

58 3. Hardware

maximalen Wert zurück oder je nach Eintreffen eines Echos, beziehungsweiseSignals einen geringeren Wert.

Während der Messung ist der Ultraschallsensor jedoch nicht ansprechbar unddas Register 0, dass die Firmwareversion beinhaltet, liefert nicht dessen Wertzurück. Dies kann genutzt werden, um zu evaluieren, ob ein Messvorgangschon abgeschlossen wurde. Wurde eine Messung abgeschlossen, so wirdbeim Auslesen von Register 0 die Firmwareversion zurückgeliefert und an-dernfalls der Wert 255, was bedeutet das der Sensor nicht per I2C ansprech-bar war. Wir werden in Kapitel ... darauf noch näher eingehen, da wir diesenTweak für unsere Zwecke ausnützen werden, um eine sofortige Synchronisie-rung des Empfangs eines Daten- oder Metapakets zu realisieren.

Der Energieverbrauch liegt bei dem SRF02 bei 4mA · 5V = 0, 02Watt. DieKosten liegen momentan bei circa 13,89 EUR inklusive Mehrwertsteuer. DieKosten für den den im SRF02 verbauten Schallwandlers 00PT160 liegt zudempreislich bei circa 6 EUR26.

Abbildung 3.19.: Richtungscharakteristik eines Ultraschallwandlers [EcGD11]

26Ohne Versandkosten aus der UK.

4. Realisierung eines akustischenModems

Wir befassen uns in diesem Kapitel mit der Erstellung eines akustischen Mo-dems. Dabei implementieren wir zunächst eine unidirektionale Datenüber-tragung zwischen zwei Netzwerkknoten, so das wir momentan nicht auf dieImplementation eines MAC-Protokolls anwiesen sind.

Das Kapitel untergliedert sich in die Unterkapitel 4.1, das sich mit der Analy-se, den schon vorhandenen Lösungsansätzen und den zu erfüllenden Anfor-derungen und Randbedingungen widmet.

Das folgende Unterkapitel 5.2 stellt die Konzeption für unser erstelltes akus-tisches Modem vor und wird in Unterkapitel 4.3 für den realen Einsatz in derterrestrischen Umgebung in Verbindung mit der Zusammengesetzten Hard-ware erläutert.

Abgeschlossen wird dieses Kapitel mit der Evaluation des erstellten akus-tischen Modems und dessen Implementationen zum einen mit künstlichenPausen(Delays) und über Interrupts und der Verwendung von STOPBITS.

60 4. Realisierung eines akustischen Modems

4.1. AnalyseUnsere Diplomarbeit hat als Ziel die Erstellung eines akustischen ad hocSchwarm-Netzwerkes zu ermöglichen. Hierfür muss zum einen das Kom-munikationsmodul, das akustische Modem, konzipiert und nach erfolgrei-cher Implementation um die notwendige Medienzugriffssteuerung (MAC)erweitert werden. Hierdurch soll eine energiesparende und kollisionsfreie Da-tenübertragung gewährleistet werden.

Die Randbedingungen, welche die vorgegebenen Bedingungen sind, auf diewir selbst keinen Einfluss haben, werden wir nun anhand folgender Informa-tionsquellen: [SoSP00b], [PSRS01] und [Stoj96]. Diese können in einem großenUmfang mittels geringer Anpassungen in das terrestrische Umfeld übertra-gen werden. So werden in [StPr09] die Randbedingungen wie folgt dekla-riert:’attenuation that increases with signal frequency, time-varying multi-path propagation, and low speed of sound (1500 m/s).’ Um die Herausfor-derungen mit denen eines WLAN-Netzwerkes zu vergleichen, zitieren wir andieser Stelle aus der selbigen Quelle:’Underwater acoustic channels are ge-nerally recognized as one of the most difficult communication media in usetoday.’. Da wir uns bei der akustischen terrestrischen Kommunikation mitnoch geringerer Schallgeschwindigkeit, aufgrund der geringeren molekula-ren Masse, auseinandersetzen müssen, gilt dies für den terrestrischen Bereichnoch mehr. Hier fallen zwar die Oberflächenreflektionen, durch den massi-ven Brechungsparameter beim Medienübergang von Wasser zu Luft, die inder Unterwasserakustik berücksichtigt werden müssen, weg diese spielen je-doch auch hauptsächlich bei der Flachwasserakustik eine Rolle. So beinhaltetdie terrestrische akustische Datenübertragung laut Milica Stojanovic die ver-gleichsweise ungünstigsten Eigenschaften eines Radio-Kanals, die zum einendurch eine schlechte Verbindungsqualität, wie bei einem mobilen Radio-Kanalund eine hohe Latenz, wie bei einem Satelliten-Kanal gekennzeichnet sind.

Des weiteren sind für unsere Diplomarbeit die selbst auferlegten Randbe-dingungen: ein limitiertes Budget, die Verwendung von Modulen und denschnellen Aufbau eines Schwarms, durch Verwendung einer Physical- Compu-ting-Plattform einzuhalten. Hierbei ist die Auswahl der benötigten Moduleund einer Variante der gegenwärtig vorhandenen Physical-Computing- Platt-formen für uns beeinflussbar.

Für den Aufbau eines Schwarms, sollte zuerst der generelle Aufbau einessolchen analysiert und charakterisiert werden.

Schwarmkonzeption:Hierbei fällt bei näherer Betrachtung eines Schwarms auf, dass simple Agen-ten, denen teilweise spezialisierte Funktionen zugeteilt sind, in einer redun-danten Anzahl vorliegen und zusammen teilweise durch emergente Ausprä-gungen, Aufgaben bewältigen können, die ansonsten eine einzelne Einheit

4.1. Analyse 61

nicht lösen könnte. Die Steuerung folgt dezentral und somit autonom für je-de Einheit. Die Einheiten sind aufgrund ihrer zugeteilten Funktionen in ihrerKomplexität überschaubar gehalten und jederzeit gegeneinander austausch-bar. Daher werden wir in der Diplomarbeit versuchen, durch möglichst ge-ringe Kosten für eine einzelne Einheit, einen möglichst großen Schwarm zuerstellen.

Da der mögliche Einsatzbereich und die Funktionalitäten eines Agenten nochnicht spezifiziert sind und zudem offen gehalten werden sollen, ist eine er-weiterbare Plattform mit austauschbaren Komponenten, Update- und Upgra-demöglichkeiten zu bevorzugen. Hier stellte sich nun die Frage, welche vonden in Kapitel 3.3 vorgestellten Physical-Computing-Plattformen, die für unsgeeignetste darstellt. Hierauf werden wir in Unterkapitel 4.2 näher eingehen.

Neben der großen Anzahl an Agenten eines Schwarms ist jedoch auch dieRolle der Kommunikation zwischen diesen Einheiten von essenzieller Be-deutung. Hier ist vor allem ein begrenzter Kommunikationsradius für dieeinzelnen Einheiten vorgesehen. Große Kommunikationsradien würden nurverstärkte Interferenzen verursachen und einen unnötig hohen Energiever-brauch für eine autonome Einheit darstellen. Daher werden Informationenmeist über kurze Entfernungen mit benachbarten Einheiten ausgetauscht undInformationen lokal im Nachbarschaftsradius weitergegeben, um mit voran-schreitender Ausbreitungsgeschwindigkeit der ausgesendeten Nachricht die-se an den ganzen Schwarm zu übermitteln.

Da wir einen mobilen, beziehungsweise einen Einsatz ohne externe Strom-versorgung gewährleisten wollen, stellt hier die Leistungsaufnahme jedesKnotens einen entscheidenden Faktor für uns dar. Somit muss bei der Kom-ponentenauswahl insbesondere auch auf dessen Energieverbrauch geachtetwerden und Implementationen diesen positiv unterstützen, sei es durch dieverwendeten Kommunikationsprotokolle oder dem generellen Programmab-lauf von jedem Knoten.

Da wir nicht elektromagnetisch, sondern über Schallwellen innerhalb desSchwarms verbreiten wollen, ist auf Grund dessen die akustische Kommu-nikation zu analysieren.

Akustische Kommunikation:Als mögliches Kommunikationsmodul kommt nur ein Schallwandler in Fra-ge. Somit ist zu klären, welche Bauart und welche Materialien hier für unserenEinsatz verwendet werden sollen. Hier spielen insbesondere der Wirkungs-grad für eine mobile, beziehungsweise ohne externe Stromversorgung mögli-che, Anwendung eine für uns wichtige Rolle. Zudem wirken sich, die für unsausgewählten Frequenzbereiche auf die Hardwareauswahl aus und beein-flussen die möglichen Richtungscharakteristiken unserer Netzwerkknoten.

62 4. Realisierung eines akustischen Modems

Da wir nur Frequenzen verwenden wollen, die außerhalb der menschlichenWahrnehmung liegen, stehen für uns nur zwei Frequenzbereiche zur Verfü-gung. Das wären zum einen der Infraschall- (<20Hz) und zum Anderen derUltraschallbereich (>20kHz).

Wählen wir den Infraschallbereich, so erhalten wir eine geringere Richtungs-charakteristik, jedoch auch maximal eine Datenrate von 20 Bits/Sekunde oh-ne Verwendung eines Kodierverfahrens oder der Nutzung mehrerer Frequenz-kanäle. Wählen wir statt dessen den Ultraschallbereich, so erhalten wir deut-lich höhere Datenraten, jedoch dafür auch eine deutlich gerichtetere Schall-ausbreitung. Diese Richtungscharakteristik kann man jedoch durch die Ver-wendung weiterer Schallwandler, die an einem Knoten so angebracht sind,dass keine Interferenzen erzeugt werden, kompensieren.

4.1.1. AnforderungenWie wir soeben charakterisiert haben, muss der akustische Schwarm folgendeAnforderungen erfüllen:

• Die Netzwerkknoten sollten in möglichst hoher Quantität herstellbarsein, um Emergenz und Redundanz zu ermöglichen.

• Daraus folgt die Bedingung, dass die Kosten für einen einzelnen Netz-werkknoten möglichst gering gehalten werden müssen.

• Da der genaue Verwendungszweck des Schwarms noch nicht bestimmtwurde und auch offen gehalten werden soll, ist eine erweiterbare Hard-wareumgebung zu präferieren.

• Die Komplexität und somit auch die Rechenleistung und der Speicher-platz eines einzelnen Knotens kann möglichst gering bemessen werden,da der Schwarm als Ganzes zur Problemlösung herangezogen werdensoll, beziehungsweise nur einfache Funktionalitäten, wie zum Beispielin einem Sensornetzwerk benötigt werden.

Für das zu erstellende akustische Modem sind des weiteren folgende Anfor-derungen zu erfüllen:

• Die nötigen Datenraten müssen erbracht werden können, um ein funk-tionsfähigen Datenaustausch im Schwarm zu gewährleisten. Da wir beiSchallwellen in der Luft, mit geringen Geschwindigkeiten und einer dar-aus resultierenden hohen Latenz im Netzwerk uns auseinander setzenmüssen, sollte man hier mit möglichst hohen Datenraten entgegenwir-ken.

• Die Ausbreitung der Schallwellen sollte optimaler weise kreisförmigverlaufen, um die komplette Nachbarschaft für einen Informationsaus-tausch erreichen zu können. Dieser und der zuvor genannte Punkt wi-dersprechen sich natürlich aufgrund der Richtungscharakteristik, die

4.1. Analyse 63

sich aus der Verwendung höherer Frequenzen ergibt. Somit muss hierein Kompromiss gefunden werden.

• Der Energieverbrauch sollte minimal sein, damit ein mobiler, beziehungs-weise ein Einsatz ohne externe Stromversorgung, möglich ist.

• Hier sollten ebenfalls die Kosten möglichst gering gehalten werden, umden Gesamtpreis für einen Netzwerkknoten minimal zu halten, um so-mit eine möglichst hohe Anzahl an Knoten für unseren Schwarm, beibeschränktem Budget, zu ermöglichen.

• Das Modem muss mit einer Medienzugriffssteuerung ausgestattet sein,damit allen Knoten das gemeinsam genutzte Medium Luft, ohne Inter-ferenzen zum Informationsaustausch zur Verfügung steht.

4.1.2. Existierende Lösungsansätze

Für den Aufbau eines akustischen Modems ziehen wir folgende schon existie-rende Lösungsansätze zu Rate: An Ultrasonic Sensor Based Low-Power AcousticModem for Underwater Communication in Underwater Wireless Sensor Networks[NaAn07], AquaNodes: An Underwater Sensor Network [VaDR07], The WHOIMicro-Modem: An Acoustic Communications and Navigation System for MultiplePlatforms Modem for Underwater Communication in Underwater Wireless SensorNetworks [FGSP+05], A low cost and high efficient acoustic modem for underwatersensor networks [SBYS11] und Low-Power Acoustic Modem for Dense UnderwaterSensor Network [WiYH06].

The WHOI Micro-Modem: An Acoustic Communications and Navigation System forMultiple Platforms Modem for Underwater Communication in Underwater WirelessSensor Networks [FGSP+05] beschäftigt sich mit der Erstellung eines akusti-schen Modems mit geringer Leistungsaufnahme. Aus dem Auszug des Ab-stract: ’It has the capability to perform low-rate frequency-hopping frequency-shift keying (FH-FSK), variable rate phase-coherent keying (PSK), and twodifferent types of long base line navigation, narrow-band and broadband. Thesystem can be conigured to transmit in four different bands from 3 to 30 kHz,with a larger board required for the lowest frequency’ können wir entnehmen,dass hier als Modulation der Trägerwelle eine Frequenzumtastung (FrequencyShift Keying - FSK) herangezogen wurde, um die einzelnen Bits zu übertra-gen. Die Hauptplatine besteht hier aus einem Texas Instruments DSP1 der biszu 160 MIPS2 ausführen kann, zudem besitzt er einen Low Pass Anti-AliasingFilter mit einem 12-bit A/D-Wandler (Converter) mit einer 80kHz Abtastra-te, der für die korrekte Signalrekonstruktion nach zuvor erfolgter Abtastungdes Original-Signals beim Empfänger-Modul zum Einsatz kommt. Für dasSendemodul des Transceivers wird ein linearer 12-bit D/A Wandler und ein

1DSP = Digital Signal Processor2MIPS = Million Instructions Per Second - Millionen Instruktionen pro Sekunde

64 4. Realisierung eines akustischen Modems

Tiefpass-Rekonstruktionsfilter eingesetzt. Für Energieeinsparungen wird zu-dem eine Echtzeituhr (Real Time Clock - RTC) verwendet, um das Modem inregelmäßigen Abständen in einen Energiesparmodus, mit einer Leistungsauf-nahme von nur 80mW setzen zu können, statt sonst circa 180mW im Normal-betrieb.

In AquaNodes: An Underwater Sensor Network [VaDR07] wird der Aufbau einesakustischen Modems für ein Unterwasser-Sensornetzwerk beschrieben. Hierliegt die Punkt zu Punkt Datenübertragungsreichweite bei mehreren hundertMetern bei einer Bitrate von 330kbits/Sekunde und bei 300 Bits/Sekunde fürBroadcasts. Die Hardware für die Netzwerkknoten besteht hier aus einemATmega128 Mikrocontroller mit 128kByte Flash-Programmspeicher, 4kByteRAM. Zusätzlich werden 512kByte externer Flash-Speicher für das Abspei-chern von Daten-Logs genutzt. Der Netzwerkknoten enthält zudem einenDruck- und Temperatursensor. Das reine akustische Modem besteht aus ei-nem Blackin BF533 DSP mit 600MHz, der für die Signalverarbeitung zu-ständig ist und separate aufwendige Filter überflüssig macht. Für die Da-tenübertragung wird eine Pulsweitenmodulation (PWM) verwendet, um eineTrägerwelle auszusenden, die nach der Initialisierung noch durch einen Ver-stärker zu einer Welle mit einer noch höheren Amplitude transformiert wird.Das Signal wird durch einen selbst entwickelten zylindrischen Piezokeramik-Schallwandler anschließend auf das Trägermedium übertragen.

Für den Empfang wird ein Bandpassfilter eingesetzt und anschließend einVerstärker für die Amplitudenerhöhung verwendet. Ein nachgeschalteter 12bitA/D-Wandler tastet danach das Signal bei 250k Samples/Sekunde ab, um dieeinzelnen Bits zu de-modulieren. Als Modulationsverfahren wird hier FSK fürdie Trägerwelle von 30kHz genutzt. Die Symbolgröße liegt bei 3ms, wobei 2msdavon als Pause und nur 1ms als eigentliche Datenübertragung dienen. DieDatenpakete, als solche bestehen aus einem Synchronisierungs-Impuls gefolgtvon 16 Bytes an Daten. Hier wird zudem ein Mehrfachzugriff durch TDMAermöglicht, was natürlich eine Synchronisierung benötigt.

In A low cost and high efficient acoustic modem for underwater sensor networks[SBYS11] wird ein MCU verwendet, der zusammen mit einem piezoelektri-schen Schallwandler, der in diesem Fall ein kommerzielles Echolot darstellt,einem Verstärker, einigen Filtern, ein paar zusätzlichen Sensoren, wie einemTemperatursensor et cetera betrieben wird. Des weiteren wurde eine RTC in-tegriert. Die Modulation des Signals erfolgt per FSK und die Trägerwelle isthier mit 85 kHz angegeben. Die maximale Reichweite beträgt 100m. Bei 5Vbeträgt hier die Leistungsaufnahme 16mW, bei einer Reichweite von 20m.

In Low-Power Acoustic Modem for Dense Underwater Sensor Network [WiYH06]wurde als Trägerfrequenz 18kHz ausgewählt und für die FSK-Modulationwurde hier ein kommerzieller FM-Chip von Phillips, der SA604A genutzt.Auch hier wurden Verstärker für die Signalübertragung und den Signalemp-

4.1. Analyse 65

fang angewandt. Für die Erzeugung der Trägerwellenfrequenz wird ein linea-rer Oszillator mit der Bezeichnung LTC6900 eingesetzt. Das Modem wird miteinem Atmega128L Mikrocontroller mit einer Taktung von 7,3 MHz betrie-ben, der nur 25mW verbraucht, wenn er vollständig aktiv ist. So beträgt diegesamte Leistungsaufnahme bei der Datenübertragung 2 Watt.

Abbildung 4.1.: Aufbau des zweiteiligen Transceiver-Moduls in An ultrasonicsensor based low-power acoustic modem for underwater communi-cation in underwater wireless sensor networks [NaAn07]

Das letzte Paper, An ultrasonic sensor based low-power acoustic modem for under-water communication in underwater wireless sensor networks [? ], das wir abschlie-ßend hier beschreiben wollen, nutzt im Gegensatz zu den zuvor vorgestell-ten Papern einen Ultraschallsensor für die Datenübertragung. Auch hier wirdein Mikrocontroller, in diesem Fall eine 8bit MCU, dem ATmega128L für dieSteuerung und Signalverarbeitung genutzt. Die Trägerwelle ist hier durch denquasi Standard für Ultraschallsensoren von 40kHz vorgegeben. Für die Mo-dulation der Trägerwelle wird die Amplitudenumtastung (Amplitude-ShiftKeying - ASK) in Form von On-Off Keying (OOK) eingesetzt. Das 40kHzSignal, des Ultraschallsensors, wird bei OOK einfach ein- und ausgeschaltet.Somit gibt es zwei Stadien, in denen der Schallwandler sich befinden kann.Das wäre für eine logische 1, in einer Schwingung mit 40kHz und für eine lo-gische 0 im ausgeschalteten Zustand. Auch hier werden natürlich die Signaleüber einen Verstärker mit einer höheren Amplitude versehen. Nach diesemVorgang wird in diesem Transceiver das Signal durch einen Komparator1 vonstörendem Rauschen so weit wie möglich befreit und anschließend anhand ei-nes Hüllkurvendetektor (Envelope-Detectors) das ursprüngliche Signal ermit-telt. Dieses analoge Signal wird im letzten Schritt zu einem digitalen Signaldurch den Komparator2 transformiert und an die zu verarbeitende Einheitweitergesendet.

Die generierten analogen und digitalen Signale können in Abbildung 4.2 und4.3 näher betrachtet werden.

66 4. Realisierung eines akustischen Modems

Abbildung 4.2.: Signale im Verstärker [NaAn07]

Abbildung 4.3.: Software Sampling [NaAn07]

4.1. Analyse 67

Die resultierende Bitrate des akustischen Modems beträgt 100 bps. Die Reich-weite konnte nur bis 3m getestet werden, da die verwendete Umgebung dieEvaluation beschränkt hatte.

Abbildung 4.4.: Paket-Implementation [NaAn07]

Das angewandte MAC-Protokoll kann man in Abbildung 4.4 genauer betrach-ten. Wir werden auf dieses Paketformat in Kapitel 4.2 näher eingehen, da wirin abgewandelter Form unsere Paketimplementation bewerkstelligt haben.

4.1.3. Zusammenfassung

Zusammenfassend kann festgehalten werden, dass die Analyse eines akusti-schen Modems, durch die von uns ausgewählten Paper, vor allem durch denHauptfaktor, der niedrigen Schallgeschwindigkeit und der damit einherge-henden hohen Latenz verbunden ist. Daher sollten hohe Bitraten bevorzugtwerden, auch wenn dadurch sich Richtungscharakteristiken ergeben, die sichstark von einer kreisförmigen Ausbreitung unterscheiden. Diese kann jedochdurch die Positionierung mehrerer Schallwandler, mit sich nicht überschnei-denden Richtungskegeln, damit sich keine Interferenzen ergeben, approxi-miert werden. Bei der Auswahl eines Schallwandlers sind eindeutig Piezo-Module mit ihrem hohen Wirkungsgrad, wie wir ihn schon in Kapitel 3.4charakterisiert haben, zu bevorzugen, um eine möglichst geringe Leistungs-aufnahme zu gewährleisten. Des weiteren ist der Aufbau eines Transceiver-Moduls, abgesehen von den verwendeten Modulation-Varianten, in allen vonuns analysierten akustischen Modems sehr ähnlich. So werden stets ein biszwei Verstärker für die Amplitudenerhöhung einer Trägerwelle zur weiterenVerarbeitung oder zum Versand herangezogen. Diese Trägerwelle wird wie-derum durch PWM mit einem Mikrocontroller oder einem DSP erzeugt. Beider verwendeten Modulation wird entweder FSK oder ASK in Form von OOKeingesetzt, wobei für FSK weitere Module notwendig sind, um die Trägerwellezu transformieren. Für den Empfang der Trägerwelle und für eine Reduktiondes Rauschens muss ein Bandpassfilter angewandt werden, um ausschließlichdas zu empfangene Signal weiterverarbeiten zu können. Für den Aufbau einesSchwarms an akustischen Knoten muss ebenso auf niedrige Kosten geachtet,

68 4. Realisierung eines akustischen Modems

wie auch die Leistungsaufnahme und die Erweiterbarkeit der Funktionalitätberücksichtigt werden, da hier vor allem die Anzahl an Einheiten von Bedeu-tung ist.

4.2. Entwurf 69

4.2. EntwurfWie wir in Kapitel 4.1 analysiert haben, werden wir für eine möglichst geringeLeistungsaufnahme unseres akustischen Modems einen Piezo-Schallwandlerverwenden. Da sich die sonst nötigen Komponenten, wie bei allen akusti-schen Modems abgesehen von der Modulationstechnik sehr ähneln, werdenwir einen Ultraschallsensor als schon fertiges Transceiver-Modul für unserModem bevorzugen, um die aufwendige und zeitintensive Kalibrierung undder internen Abstimmung der nötigen Komponenten, wie Bandpassfilter, Ver-stärker, Trägerwellen-Erzeuger(PWM, Schwinkreis,...) zu vermeiden. Hierfürnutzen wir den in Kapitel 3.4 beschriebenen SRF02-Ultraschallsensor, der ei-ne Trägerwelle von 40kHz zur Abstandsmessung erzeugt. Unter den verfüg-baren SRF-Modellen hat der SRF02 zwei für uns essentielle Vorteile: Er kanneinen Messvorgang auch ohne Erzeugung eines eigens erzeugten Burst vor-nehmen, welches wiederum bei den anderen Modellen nicht möglich ist. Zu-dem ist er ein sehr preisgünstiger Ultraschallsensor. Da diese Frequenz wie inKapitel 2.1 erläutert, im Ultraschallbereich und somit außerhalb der mensch-lichen Wahrnehmungsschwelle liegt, können wir die Datenübertragung ohneBeeinträchtigung von Menschen bewerkstelligen. Nachteilig wirkt sich hiernatürlich die durch die hohe Frequenz bedingte Richtungscharakteristik aus.Diese kann allerdings in weiteren Aufbauschritten durch zusätzliche Ultra-schallsensoren kompensiert werden. Als Modulationsverfahren nutzen wirASK in Form von OOK, da wir auf die Frequenzerzeugung bei diesem pro-prietären Bauteil keinen Einfluss haben. Zudem erscheint uns dieses Modu-lationsverfahren hier am sinnvollsten, da bei dem SRF02 acht Schallimpulsepro Messvorgang erzeugt werden. Diese redundanten Impulse senken zwardie Datenrate, machen diese jedoch dafür auch robuster gegenüber Störquel-len.

Für die logische Signalverarbeitung und die Steuerung des SRF02 werden wir,wie auch der Großteil der akustischen Modems, in den von uns zuvor ana-lysierten Quellen, einen Mikrocontroller verwenden. Da wir jedoch weiterePeripherie einfach und schnell hinzufügen und auswechseln wollen, verwen-den wir eine Physical-Computing-Plattform. Bei der Auswahl zwischen den inKapitel 3.3 vorgestellten drei Plattformen: Arduino, Raspberry Pi und Beagle-bone Black entscheiden wir uns für die Arduino-Plattform und hier insbeson-dere der Variante Arduino Uno Rev. 3.0, da hier im Gegensatz zum RaspberryPi ein Mikrocontroller als Hauptkomponente integriert ist. Dieser ermöglichstEchtzeitanwendungen, wie wir sie gerade bei der Signalverarbeitung benö-tigen, mit seinen hohen Bitraten und der damit verbundenen zeitkritischenKomponenten. Dies kann ebenso das Beaglebone(Black) für uns bewerkstelli-gen, dennoch ist dessen erhöhte Leistungsaufnahme und der Preis zum aktu-ellen Zeitpunkt, so lange die notwendigen Anforderungen mit dem Arduinoerfüllt werden können, noch keine Option. Werden jedoch erhöhte Ansprüchean die Rechenleistung und der Speicherkapazität gestellt, stellt diese Platt-

70 4. Realisierung eines akustischen Modems

form für uns eine ernstzunehmende Alternative zu der Arduino-Plattformdar. Vergleicht man in Tabelle 4.1 die verschiedenen Physical-Computing-Plattformen, so erkennt man, dass das Arduino Uno Rev 3.0 sowohl beimPreis- als auch beim Energieverbrauchsvergleich jeweils am besten abschnei-det sowie das Beaglebone Black Echtzeitfunktionalitäten besitzt. Bei der Re-chenleistung und der Speicherkapazität ist jedoch eine erhebliche Diskrepanzzu den anderen zwei Alternativen vorhanden. Da wir uns jedoch erst miterhöhten Speicher- und Rechenleistungswerten auseinander setzen müssten,wenn die Anforderungen höhere Werte aufweisen würden, können wir mo-mentan mit dem Arduino Uno Rev 3.0 eine für unsere Zwecke gute Physical-Computing-Plattform für den Aufbau unseres akustischen Schwarms heran-ziehen.

Plattform Leistungsaufnahme Preis RAM CPU Echtzeit-funktionalität

Arduino UnoRev 3.0

< 1 Watt 23,80 EUR 2 KB 16 MHz Mikrocontroller

Raspberry PiA / B

2,5 / 3,5 Watt 27 EUR / 34EUR

256 / 512 MB 700 MHz über Echtzeit-betriebssystemansatzw. mgl.

BeagleboneBlack

max. 2,5 Watt 47 EUR 512 MB 1 GHz 2 PRU

Tabelle 4.1.: Vergleich der verschiedenen Physical-Computing-Plattformen

Im ersten Schritt der Erstellung eines akustischen Modems kombinieren wirdaher die Physical-Computing-Plattform Arduino Uno mit dem SRF02 Ultra-schallsensor.

Hier stellt sich die Frage, der zu verwendenden Datenschnittstelle, zu dieserPeripheriekomponente. Zur Verfügung stehen die asynchrone serielle Schnitt-stelle RS-232(TTL) und die synchrone serielle Schnittstelle I2C. Der Vorteil ei-nes synchronen Datenbusses ist, das man zuvor nicht für jede Komponentedie Baudrate auf den gleichen Wert einstellen muss, sondern einzig der Mas-ter die Bustaktung durch eine eigene Taktungsleitung vorgibt. Hier werdenwir den von Philips©entwickelten seriellen synchronen Zweidraht-Bus I2Cauf Grund seiner weiten Verbreitung in Controller- und Robotikschaltungen,den möglichen Baudraten von 100 kHz im Standard Modus und 3,4 MHz imHigh Speed Modus, benutzen.

Da wir nur einen Slave an unseren I2C anschließen werden, den SRF02, müs-sen keine externen Pullup-Widerstände3 für die Daten- und Taktungsleitungverwendet werden, da hierfür die integrierten Widerstände des Arduino UnoRev 3.0, der zwei verwendeten Pins ausreichend dimensioniert sind.

3Für einen I2C-Bus sind Pullup-Widerstände notwendig. Durch diese Pullup-Widerstände,wird die Busleitung auf einen High gezogen, um Störungen durch temporäre Unter- undÜberschreitung eines zwischen High- und Low-Wertes zu vermeiden.

4.2. Entwurf 71

Abbildung 4.5.: Schaltplan [Ardu13]

Abbildung 4.6.: Schaltungsaufbau laut Arduino-Community-Webseite[Ardu13]

72 4. Realisierung eines akustischen Modems

Zum Glätten der Stromzufuhr, werden wir, wie auf Seite 189 in der Quelle Ar-duino Robotics [Banz13] und auf der Arduino-Community-Webseite [Ardu13] ge-raten wird, einen 100µF Kondensator verwenden, um temporäre Spannungs-abfälle des SRF02 auszugleichen. Den genauen Schaltungsaufbau kann manin Abbildung 4.5 und 4.6 betrachten.

So werden wir mit Steckplatinen (Breadboards) unseren ersten Knoten erstel-len. Hierdurch ist ein schnelles und einfaches Prototyping möglich.

Abbildung 4.7.: Datenübertragungsprotokoll-Paketkonzeption

Bei der Konzeption der Meta- und Datenpakete orientieren wir uns teilweisean Abbildung 4.4. Auch wir werden die Größe unserer Nutzlast eines Daten-paketes im Header angeben. Auf den genauen Aufbau werden wir nun imfolgenden Absatz näher eingehen.

Bei der Art der Pakete, die wir übertragen wollen, differenzieren wir zwi-schen den reinen Metadatenpaketen: RTS, CTS und den Datenpaketen: DATA.Bei unseren ersten Tests und der Implementation unseres akustischen Mo-dems werden wir zudem nur das Senden und Empfangen dieser Pakete rea-lisieren und evaluieren. Im Anschluss werden wir in Kapitel 5 die weiterenTeile des Medium Access Control(MAC) Protokolls konzipieren.

Zum einen ist ein Paket durch ein Startbit gekennzeichnet, um die nachfol-genden Bits synchron mit der zuvor für alle Knoten gleichen Datenrate abzu-tasten. Dies erreichen wir durch eine Dauerschleife von Messvorgängen undder Abfrage innerhalb dieser Schleife von Register0, welches entweder dieFirmwareversion zurückgibt oder falls ein Messvorgang noch aktiv sein sollteüber I2C keine Verbindung zum SRF02 und somit 255 zurückgegeben wird.So brechen wir sobald das Startbit angekommen ist sehr zeitnah aus der End-losschleife und starten das erste Abtastintervall.

Zur Differenzierung von Daten und reinen Metapaketen, wie zum BeispielRTS, CTS, führen wir im nächsten Schritt den MSG-TYPE ein. Reine RTS,CTS haben den optionalen rechten Teil, der in Abbildung 4.4 farblich grün

4.2. Entwurf 73

markiert ist, nicht zusätzlich angehängt, um den Overhead im Netzwerk mög-lichst gering zu halten. Andererseits besitzen Datenpakete noch die Metada-ten DATA-SIZE, die für die Bestimmung des Paketendes eingesetzt werden.Wir veranschlagen im ersten Schritt die Anzahl an Bits auf 4, was 24 = 16mögliche Nachrichtentypen zulässt. Dies sollte inklusive späterer ACK oderNACK ausreichend dimensioniert sein.

Nachfolgend wird über die Metadaten MAC-TO und MAC-FROM eine Adres-sierung realisiert. Mit einem Byte, somit 28 = 256 möglichen IDs ist unserSchwarm zunächst auf maximal 256 Knoten beschränkt.

Es sei an dieser Stelle noch einmal darauf hingewiesen, dass rein der farb-lich orangene Teil der Abbildung immer gesendet werden muss. Der grüneTeil des Pakets ist optional, außer für den MSG-TYPE DATA, hier sind die-se Felder Pflicht. Mit 28 = 256 möglichen Byte-Werten, können wir zudemausreichend große und flexible Datenpakete versenden.

Wir haben uns für die zuvor erläuterte Struktur des Paketprotokolls als ers-te Version entschieden, damit durch MAC-TO und MAC-FROM eine direkteAdressierung möglich ist. Zudem kann für Broadcasts hier das gleiche Verfah-ren wie in einem LAN angewandt werden, demnach über Carrier Sense undin Kauf zu nehmende Kollisionen eine Broadcast-Adresse implementiert wer-den. Somit können Pakete an die komplette Nachbarschaft die sich in der ma-ximal möglichen Kommunikationsreichweite befinde, als Broadcast gesendetwerden. Da hier jedoch ein Handshake mit allen möglichen Nachbarknotengegenüber einem einfachen Kollisionsansatz wie CSMA einen viel zu hohenOverhead verursachen würde, müssen wir für diese Art von AdressierungKollisionen in Kauf nehmen. Dies ist jedoch verständlicherweise immer nocheffizienter, als sich erst über einen Handshake mit jedem Nachbarknoten ab-zustimmen, wenn man von einem Schwarm mit einer großen Anzahl an Kno-ten und einer dementsprechenden Dichte an Knoten ausgeht.

Wir wollen daher im ersten Schritt unseren Schwarm als Sensornetzwerkgestalten und die gesammelten Informationen von Sensoren oder Nachbar-schaftsbeziehungen an eine oder mehrere zentrale und speziell dafür gestal-tete Knoten weitergeben. Diese(r) Knoten soll(en) mit weitergehender Peri-pherie ausgestattet sein, die die anderen Knoten nicht benötigen und bei-spielsweise zum Versand per Funkmodul an einen PC oder einem embeddedGerät, als Sammelstelle und Laufbote für die akkumulierten Informationenfungieren.

74 4. Realisierung eines akustischen Modems

4.2.1. Alternative AnsätzeIn Bezug auf die verwendete Hardware, wäre es möglich gewesen die Kom-ponenten, die in dem SRF02 vorhanden sind und wie wir sie in Kapitel 3.4ausführlich beschrieben haben, selbst zu erstellen. Dieses eigene Transceiver-Modul hätte für uns die Möglichkeiten eröffnet, die Frequenz für unsere Trä-gerwelle zum einen selbst bestimmen zu können und zudem auch mehrereFrequenzen für beispielsweise FSK zu nutzen. Da ein Piezo-Schallwandler al-lerdings eine bestimmte Resonanzfrequenz aufweist, ist eine größere Abwei-chung von dieser mit einem geminderten Wirkungsgrad für die Energietrans-formation für die Signalübertragung verbunden. Auch hätte man hierdurcheine höhere Bitrate, da man nicht auf einen Ausstoß wie beim SRF02 von 8Impulsen angewiesen ist, sondern pro Bit einen Impuls aussendet.

Bei der Auswahl des Ultraschallsensors wären auch andere Modelle möglichgewesen, die als Transceiver mit einem einzigen Schallwandler versehen sind.Da solche Modelle allerdings nicht unbedingt den Standard bei dieser Art vonSensoren darstellen, zumindest nicht im präferierten Preissegment, blieb dieAuswahl recht bescheiden. Man hätte jedoch ebenso höhere oder geringereFrequenzen und damit eine angepasstere Richtungscharakteristik heranzie-hen können.

Bei der Steuerung des Transceiver-Moduls, wäre statt einer Physical-Computing-Plattform eine Alternative in Form von der Verwendung eines einfachen Mi-krocontrollers vorhanden gewesen. Da wir dadurch zusätzlichen Aufwand fürdie Programmierung des Mikrocontrollers ohne ISP und zudem keine ein-fache Erweiterung durch Shields hätten, scheidet diese Lösung für die Di-plomarbeit aus. Zur Optimierung des Energieverbrauchs und zur Senkungder Kosten, wenn man die Entwicklungskosten ad acta legt, kann dies natür-lich eine sinnvolle Alternative darstellen.

Bei der Auswahl der Plattform ist als große Alternative das Beaglebone Blackanzusehen. Durch diese Plattform wäre eine um ein Vielfaches erhöhte Re-chenleistung und Speicherkapazität inklusive eines OS möglich gewesen. Diesermöglicht natürlich ganz andere Optionen für jeden einzelnen Knoten, diesesind jedoch in unserem Schwarm, den wir vorerst als Sensornetzwerk aufbau-en wollen, momentan nicht notwendig. Außer es sei denn, wir transformierendie Knoten zu mobilen Robotern und erhöhen somit die Anforderungen anunsere Plattform.

Wir werden zunächst kein Vielfachzugriffsverfahren, wie beispielsweise TD-MA, FDMA oder CDMA, die wir in Kapitel 2.2.1 ausführlich beschriebenhaben, zur simultanen Übertragung an mehrere Knoten konzipieren. Dieseskann allerdings im Anschluss durch weitere Projekte implementiert werden.Hierdurch kann der Datendurchsatz erhöht und die Latenz des Netzwerkesgemindert werden. Hierbei stellt CDMA wohl die Beste zu realisierende Lö-sung dar, da bei TDMA die geringe Geschwindigkeit der Schallwallen eine zu

4.2. Entwurf 75

hohe Latenz verursacht und FDMA bei der geringen akustischen Bandbreiteziemlich beschränkt ist.

Bei der Modulationstechnik könnte, wie in Kapitel 4.1 schon erläutert, stattASK in Form von OOK, wie zum Großteil auch in den zuvor beschriebenenPapern, das FSK-Verfahren gewählt werden. Dies hätte den Vorteil, dass wir jenachdem, wie viele verschiedene Frequenzen wir wählen entsprechend mehrBits gleichzeitig überragen können. An dieser Stelle sei auf den Unterschiedzwischen FSK und FDMA hingewiesen. FDMA nutzt mehrere Frequenzen fürdie Trägerwelle für die gleichzeitige Übertragung an mehrere Knoten, wobeiFSK ein Modulationsverfahren darstellt, dass für eine Verbindung von einemKnoten zu seinem Empfänger konzipiert ist und mittels Veränderung der Fre-quenz digitale Signale in analoge überführt. Hier findet somit ein ständigerWechsel der Frequenz der Trägerwelle statt, was bei FDMA für einen Kanalnicht der Fall ist.

4.2.2. Zusammenfassung

Zusammenfassend kann gesagt werden, dass wir nach Vergleich der Alterna-tiven und der Auswahl, für die für uns am besten zu realisierende Option, dieBlaupause für unser akustisches Modem zur Implementierung bereit steht.Hierbei entschieden wir uns für die Physical-Computing-Plattform ArduinoUno Rev. 3.0 aufgrund seines geringen Preises, seiner guten Erweiterbarkeit,der Echtzeitfunktionalität und dem niedrigen Stromverbrauch und der Nut-zung eines Mikrocontrollers, wie er auch in vielen anderen Projekten, diewir in Kapitel 4.1 beschrieben haben, am besten zu unseren Anforderungenpasst. Bei dem Transceiver-Modul entschieden wir uns für die Verwendungdes SRF02 Ultraschall-Sensors, der mit einem einzigen Schallwandler sowohlals Empfänger, als auch als Sender fungieren kann. Somit erhalten wir mitdem SRF02 den Großteil eines Transceiver-Moduls und ersparen uns damitdie aufwendige Konzeption und Kalibrierung dieses Moduls. Bei der Modu-lationstechnik verwenden wir ASK in Form von OOK, was im Gegensatz zuFSK, das öfters in den gesichteten Papern verwendet wird, hier uns am Pas-sendsten zu sein scheint. Wir werden im ersten Schritt bei der Erstellung desakustischen Modems auf keine Mehrfachzugriffstechniken und Mediumzu-griffsprotokolle eingehen, da wir diese erst in Kapitel 5 bei der Konzeption ei-nes Schwarms berücksichtigen werden. Was wir jedoch schon konzipiert underläutert haben, ist der grundsätzliche Aufbau von Meta- und Datenpaketenund den jeweilig dafür veranschlagten Bits und deren Bedeutung.

76 4. Realisierung eines akustischen Modems

4.3. ImplementierungIn diesem Kapitel werden wir die genaue Implementierung des akustischenModems schildern. Dies gliedert sich in die drei Bestandteile: Einrichtung derSoftwareumgebung (IDEs und Bibliotheken), Hardwareaufbau und Steuerung(Prototyping mit Steckbrett, Ansteuerung des SRF02) sowie der Softwareim-plementierung in C++ und dem bisher recht rudimentären Übertragungspro-tokoll.

4.3.1. Einrichtung der SoftwareumgebungFür die Programmierung des ATmega328, der vom Arduino Uno Rev 3.0 ver-wendete Mikrocontroller, können wir durch den schon vorab in das Arduinointegrierten Bootloader direkt über den USB-Anschluss programmieren. Dieskann entweder über die Arduino IDE, über AVRStudio oder über ein AVR-Plugin in Eclipse realisiert werden. Eine andere Möglichkeit wäre ein extraISP zu nutzen, was wir jedoch nicht präferieren.

Wir haben uns anfänglich dafür entschieden die Arduino eigene Entwick-lungsumgebung zu verwenden, da hier die Arduino eigenen Bibliotheken teil-weise schon integriert waren und eine leichtes Aufspielen des Binärcodes aufden ATmega328 gewährleistet war. Ein für uns zu großer Nachteil dieser IDE,stellte jedoch die nicht vorhandene Autovervollständigung beim Erstellen desQuellcodes innerhalb der IDE dar. Abbildung 4.8 zeigt das Hauptfenster mitder Menüleiste dieser IDE.

Zur Optimierung der Programmierung suchten wir eine bessere IDE, welchewir mit Eclipse in Verbindung mit den Plugins CTD, das für die Erstellungvon C und C++ Quellcode notwendig ist und AVR, das für das Beschreibendes Atmel Mikroprozessors der Mikroprozessorfamilie AVR gefunden haben.Hier können wir durch die vorhandene Autovervollständigung für Quellcodeeffektiver programmieren.

Für die Einrichtung des AVR-Plugins müssen in den Einstellungen der ge-naue MCU-Typ und dessen Taktungs-Frequenz angegeben werden. Des wei-teren muss die Arduino-IDE für das Einbinden der Arduino-Bibliotheken (dieprivaten und die Grundbibliotheken)4 installiert sein und dessen Pfade auchin den Einstellungen vermerkt werden.

Für das Bespielen des Mikroprozessors verwendet das Eclipse AVR Plugin,das gleichzeitig mit installierte Programm AVRDude für den Download/U-pload und der Manipulation eines AVR-Mikrocontrollers. Eigentlich ist AVR-Dude für einen ISP konzipiert, die Arduino Plattform kann jedoch als solchergenutzt werden.

4Die privaten Bibliotheken sind beispielsweise die Timer1 Bibliothek, die nachträglich vomNutzer eingebunden werden können und in einem separaten Verzeichnis getrennt vonden Arduino Grundbibliotheken abgespeichert werden.

4.3. Implementierung 77

Zur Erstellung eines Arduino-Projektes muss über den Menüpunkt ”Ardui-no” ein dementsprechendes Projekt erstellt werden. Dadurch werden die Grund-bibliotheken für das zu erstellende Projekt eingebunden und die Arduino spe-zifischen Besonderheiten berücksichtigt. Die Bibliotheken sind teils in C undteils in C++ geschrieben.

Eigener Programmcode kann nun hinzugefügt werden, wobei die Arduino-Referenzstruktur mit den zwei notwendigen Methoden: setup() und loop()bei Verwendung der Arduino Grundbibliotheken im eigenen Programmcodeimplementiert werden müssen, da sie von diesen erwartet werden.

Hierbei ist die Methode setup() für die Initialisierung zu verwenden und dieMethode loop() als Endlosschleife für den generellen Programmfluss zu nut-zen.

Abbildung 4.8.: Screenshot der Arduino IDE. Im Hauptfenster sind die Me-thoden setup() und loop(), die implementiert werden müssen,schon vorab rudimentär durch die IDE erstellt worden.

Da wir mit unserem Transceiver-Modul mit dem I2C-Bus kommunizierenwollen, müssen wir noch die dafür notwendige Bibliothek der Arduino-Communityeinbinden. Diese ist die Wire Library. Bei dem von uns verwendeten Ardui-no Uno Rev 3.0 werden hierbei die Pins A4 als Datenleitung (SDA) und A5als Taktungsleitung (SCL) für den I2C-Bus per Software gesteuert. Die WireBibliothek ist in der Arduino IDE schon vorhanden und muß nicht externheruntergeladen werden. Diese muss jedoch per import-Befehl in C++ einge-bunden werden.

Zunächst werden wir noch keine Interrupts für die synchrone Signalabtas-tung verwenden, sondern statt dessen die maximale Zeit für eine Messung

78 4. Realisierung eines akustischen Modems

Abbildung 4.9.: Screenshot der Arduino IDE, wobei diesmal der Bereich umdie Methoden setup() und loop() vergrößert wurde.

als Intervall nutzen. Diese ist mit 65ms hoch genug, dass Nachbarknoten inReichweite in dieser Zeit ein Bit versenden und empfangen können, ohne die-sen Intervallbereich zu überschreiten. Dies führt jedoch zu einer Datenratevon nur 10−3

65 = 15, 38 Bits. Diese ist dafür sehr robust und funktioniert, wiewir in Kapitel 4.4 nachweisen werden, auch über eine Entfernung von bis zu13m im Hauptstrahl des Ultraschallsensors fehlerfrei. In Kapitel 4.4 werdenwir eine alternative Lösung mit einer höheren Datenrate vorstellen. Hierbeiwerden wir Interrupts für eine zeitlich genauere Abtastung des Eingangsi-gnals anwenden.

Wir haben in einem weiteren Schritt versucht auf Basis von künstlichen Pau-sen (Delays), den Programmablauf so weit zu verzögern, dass wir kleinereIntervalle, als 65ms erreichen konnten um ein Bit zu empfangen. Da wir je-doch eine geringere zeitliche Genauigkeit, als beispielsweise durch Interruptshierbei erzielen, konnten wir hier jedoch keine fehlerfreie Datenübertragungmehr erreichen. Daher werden wir in Kapitel 4.4.1 diesen Versuchsteil für ei-ne höhere Datenrate vorstellen und gezielter den vielversprechenden Ansatzüber Interrupts behandeln.

4.3.2. Hardwareaufbau und Steuerung

Bei der Implementierung der Hardware, setzen wir den Entwurf, den wir inKapitel 4.2 konzipiert haben, unverändert in die Realität um. Dies lies sichdurch die Physical-Computing-Plattform Arduino Uno Rev 3.0, dem Ultra-schallsensor, einem Kondensator zum Glätten der Stromzufuhr und einemSteckbrett mit den nötigen Kabeln auf einfache Weise, schnell erreichen. Zubeachten ist hierbei das Widerstände für die Datenleitung (SDA) und A5 alsTaktungsleitung (SCL) des I2C-Busses zusätzlich notwendig werden, sobald

4.3. Implementierung 79

noch weitere Komponenten an den I2C-Bus angeschlossen werden müssen.Diese müssen hier als größere Pullup-Widerstände fungieren, als die schon inden Pins integrierten Widerstände. Der Knoten, der momentan nur als Senderfungieren soll, statten wir mit einer 6× 1, 5AA = 9V akkumulierten Batterieaus. Unser Empfangsmodul wird per USB mit Strom versorgt, da wir zumDebugging und der Evaluation den Seriellen-Bus per USB verwenden, umeine grafische Ausgabe der empfangenen Pakete und den Messwerten desUltraschallsensors an einem PC zu applizieren.

Wir wenden uns als nächstes der Steuerung des SRF02 zu. Dabei gehen wirnun detailliert auf die Registeransteuerung ein. Wir nutzen hierbei vor allemdas Register0 (Befehlsregister zur Steuerung des Ultraschallsensors), Register2(Entfernungswert - High Byte) und Register3 (Entfernungswert - Low Byte),sowie die Befehle 0x58 (Synchroner Messvorgang), 0x5C (startet einen achtzyklischen 40kHz Impuls/Ton).

Abbildung 4.10.: Angenommene Signalerfassung eines 1110101101 Signals.Im vorderen Bereich ist im blauen Kasten die schnelle Ab-tastung zur Erkennung des Start-Bits zu sehen. Im weite-ren Bereich sieht man die synchronen Abtastintervalle unddie zeitlich vermuteten logischen 1-Bit-Werte als rote Pfeiledargestellt.

In unserer nachfolgenden Softwareimplementierung für den Empfänger set-zen wir die Befehle für den SRF02 per Wire-Bibliothek als Erstes in das Regis-ter0 (Befehlsregister) und fragen daraufhin zuerst fortlaufend in einer Dau-erschleife die Firmwareversion des Ultraschallsensors ab, um wie schon be-reits in Kapitel 4.2 beschrieben die Abtastung mit dem Empfang des erstenHIGH-Bits möglichst zeitnah zu starten. Hierauf beginnen wir nach einer ak-kumulierten künstlichen Programmpause durch einen Delay von 12 bis 18ms,den ersten synchronen Messvorgang mit dem Befehl 0x58. Wir werden aufdiese Werte im Unterkapitel 4.3.3 noch näher eingehen. Wichtig im Momentfür uns ist jedoch der Grund, wieso wir diese künstliche Pause eingebauthaben. Dies resultiert aus dem Beweggrund, dass Abtastintervall mittig zuden zu erwarteten Bits auszurichten, um sowohl in positiv als auch negativerzeitlicher Abweichung des Empfangs eines Bits noch innerhalb des Abtastin-tervalls zu liegen. Zudem sollen hiermit Verschiebungen des Empfangs einesBits durch Ungenauigkeiten, die mit fortlaufender Abtastung auftreten kön-nen, ausgeglichen werden. So sieht man in Abbildung 4.10 die fortlaufendeDauerschleife, in der wir alle 2ms die Firmwareversion während eines Mess-vorgangs abfragen, um vor den maximal 65ms, die eine Messung brauchen

80 4. Realisierung eines akustischen Modems

kann, schon nach empfangenen Signalen zu suchen. Tritt hierbei kein Signalein, so wird die nächste Messung nach 65ms angestossen und fortwährendalle 2ms die Firmwareversion abgefragt. Diese Prozedur sieht man in Abbil-dung 4.10 in dem durch einen blauen Rahmen gekennzeichneten Bereich. Derprognostizierte Empfang eines Bits sieht man nun im rechten Bereich durchden ersten roten Pfeil, der das STARTBIT darstellt. Die empfangenen logi-schen 1-Werte sind zudem in Form eines Pfeils dargestellt und wenn es sichum ein Low-Bit handelt, mit einem leeren Intervall. Wie man hierbei sehenkann, sind die High-Bits um den Mittelpunkt eines Intervalls verteilt und ha-ben jeweils einen Puffer zum oberen und unteren Ende eines Abtastintervalls.Daraufhin fragen wir den Messwert des jeweils abgeschlossenen Zeitintervallsab und bestimmen anhand dessen Wert, ob eine logische 1 oder eine logische0 empfangen wurde.

Hier nahmen wir zunächst an, dass die Größe der Abtastintervalle sich nichtändert, sondern konstant bleibt. Wie wir in Kapitel 4.4 jedoch sehen werden,ist diese theoretische Annahme in der praktischen Umsetzung nicht der Fall.Hierauf werden wir später noch eingehen.

bitwert :=

{0 falls tMessung ≥ MAX_MEASURE_TIME = 652791 sonst

(4.1)

Hierbei stellt ein Messwert der kleiner als MAX_MEASURE_TIME = 65279den Empfang eines Signals und somit eine logische 1 dar und Werte größerals MAX_MEASURE_TIME = 65279 kein empfangenes Signals und dahereine logische 0 dar. Dies kann mathematisch durch Formel 4.1 genauer spe-zifiziert werden. Jeweils nach zwei Delays von jeweils 68ms und 2ms fragenwir den Messwert des abgeschlossenen Abtastintervalls ab. Da unser Senderebenso eine 70ms Pause zwischen jedem Bit verwendet, erhalten wir somittheoretisch eine relativ synchrone Signalabtastung. Da wir hier jedoch nichtmit Interrupts arbeiten, wie wir es in Kapitel 4.4 für höhere Datenraten im-plementieren werden, gehen wir theoretisch davon aus, dass es zu einer zeit-lichen Verschiebung der Intervalle, sowohl in positiver als auch in negativerRichtung durch unterschiedliche Befehlsausführung des Mikrocontrollers un-d/oder des SRF02 geben kann. Dies führt zu einer Erhöhung oder Senkungder Messwerte von logischen 1-Signalen. Zudem spielt hier der Ultraschall-sensor, als solches noch eine Rolle, der hardwareseitig nicht immer die glei-chen Zeitintervalle möglich macht. Wir haben uns hier für Intervalle von 70msstatt 65ms entschieden, um noch einen zusätzlichen Puffer für die Messungzu ermöglichen. Auf die Verarbeitung der empfangenen Bits gehen wir andieser Stelle nicht weiter ein, da hier die grundlegende Signalabtastung unddie Registersteuerung behandelt werden sollen.

4.3. Implementierung 81

Der Code für unseren Sender ist momentan recht einfach gehalten, da wirihn zu reinen Testzwecken nutzen werden. Hierbei schickt der Knoten, der alsSender fungiert, jede 70ms entweder für eine vorgegebene logische 1 durchdie Befehlsübergabe der Anweisung 0x5C einen acht zyklischen 40kHz Im-puls/Ton an das Register0 dieses Knotens ab oder bleibt einfach in einemRuhemodus, falls es sich um eine logische 0 handeln sollte.

4.3.3. Softwareimplementierung

Bei der Softwareimplementation werden wir anhand des Quellcodes den Pro-grammablauf skizzieren. Hierbei gehen wir zuerst auf die Initialisierung derverwendeten konstanten und globalen Variablen ein und widmen uns da-nach der weiteren Initialisierung, die innerhalb der setup()-Methode stattfin-det. Abschließend werden wir den Programmfluss der in einer Endlosschleifeiterativ aufgerufenen loop()-Methode darstellen.

4.3.4. Zusammenfassung

In diesem Kapitel beschrieben wir die Einrichtung der Softwareumgebung.Hier kann festgehalten werden, dass die Arduino IDE für einen produkti-ven Einsatz nicht zu empfehlen ist. Daher haben wir uns für die Nutzungvon Eclipse in Verbindung mit dem Plugin CTD für die C/C++ Programmie-rung und dem Plugin AVR, dass mit dem Programm AVRDude dem AtmelMikrocontroller die Binärdateien übermitteln kann, entschieden. Des weite-ren beschrieben wir teilweise die Bibliotheken, die für unsere Zwecke wichti-gen Grundbibliotheken, wie die Wire-Bibliothek für die Ansteuerung des I2C-Bussystems, die wir in Unterkapitel 4.3.3 weiter vertieft haben. Des weiterenerläuterten wir die von uns eingesetzte Hardware, der SRF02 Ultraschallsen-sor und die Physical-Computing-Plattform Arduino Uno Rev. 3.0 und derenVerknüpfung über den seriellen Bus I2C. Hier gingen wir insbesondere aufdie verwendeten Register und Befehlssätze für den SRF02 ein. Hierauf aufbau-end stellten wir den Programmablauf für den Datenempfang und Datenver-sand, der durch Abtastintervalle realisiert wird, dar. Dabei wird ein Startbitmöglichst schnell durch das Auslesen des Firmwareregisters bewerkstelligt.Durch die Verschiebung des Startpunktes des ersten Abtastintervalls, wollenwir so theoretisch die logischen 1-Werte jeweils in der Mitte eines solchen Ab-tastintervalls empfangen. Zudem sollen durch die so erzeugten Pufferzonen,die ungenauer werdenden zeitlich abgestimmten Abtastintervalle und mög-liche zeitlich unterschiedlich eintreffende Bits in den Abtastintervallen, aus-geglichen werden. Bei der Einteilung der abschließend an ein Abtastintervallauszuwertenden Messvorgang gehen wir von einer logischen 0 aus, sobaldtMessung ≥ MAX_MEASURE_TIME = 65279 ..., und andernfalls von einerlogischen 1. Abschließend kann zur Softwareimplementation noch erwähnt

82 4. Realisierung eines akustischen Modems

werden, dass der Programmablauf in die Teile: Globale Deklaration und In-itialisierung, der weiteren Initialisierung in der setup()-Methode und dem an-schließenden eigentlichen Programmablauf in der loop()-Methode eingeteiltwerden kann. Die Verarbeitung der Bits folgt als nächstes wie in Kapitel 4.2anhand des Paket-Konzepts nach STARTBIT, MSG-TYPE, MAC-FROM, MAC-TO, den optionalen Teilen DATA-SIZE und DATA. Hierbei verwenden wirkeine ”Wörter” im ASCII oder einem ähnlichen Format, sondern handhabendie einzelnen Informationen, als Bitwerte für positiv Vorzeichen-beschränkteZahlenwerte.

4.4. Evaluierung 83

4.4. Evaluierung

Im Folgenden werden wir das in Kapitel 4.3 erstellte akustische Modem eva-luieren. Hierbei testen wir zuerst, ob die von einem Senderknoten ausgesen-deten Bits korrekt von einem Empfangsknoten entgegengenommen werden.Hierbei testen wir zuerst, zu welchem Zeitpunkt die logischen 1-Werte eintref-fen um in weitergehenden Arbeiten eventuell auftreffenden Fehlern entgegenwirken zu können.

4.4.1. Evaluation des akustischen Modem mit Pausen-VerzögertenAblauf für die Abtastintervall-Erzeugung

Wir testen im ersten Schritt die Abtastintervalle und die empfangenen Bit-werte in Form von empfangenen 40kHz Messwerten und Leerzeiten in derEinheit Mikrosekunden. Hierbei gestaltet sich der Versuchsaufbau wie folgt:

• Ein Netzwerkknoten wird als reiner Sender eingesetzt und dient aus-schließlich der Übertragung des Test-Signales in Form von einem START-BIT und darauf folgenden Bitwerten. Es wird hier keine Paketstrukturangewandt, da hier lediglich der Versand und der Empfang des Test-signals evaluiert werden soll, um die Funktionsweise des akustischenModems zu testen, zu analysieren und zu evaluieren.

• Ein weiterer Netzwerkknoten wird ausschließlich als Empfänger für dasTestsignal genutzt, um wie im Punkt zuvor beschrieben die Funktions-weise des akustischen Modems zu analysieren und zu überprüfen.

• Den Abstand zwischen Sender und Empfänger gestalten wir variabel.

• Die Größe der Abtastintervalle werden wir zunächst konstant bei einerLänge von 70ms einstellen, damit die Zeitmessung des Ultraschallsen-sors inklusive etwaigen Schwankungen am Ende des Abtastintervallsabgeschlossen ist und somit ein neuer Messvorgang nach 70ms nach In-itiierung des vorherigen Messvorgangs erneut gestartet werden kann.

• Die Messwerte werden anhand einer seriellen USB-Verbindung des Em-pfangs-Knotens, an einen PC an die Eclipse-IDE mit einer Baudrate von19200 an die darin integrierte Konsole übermittelt. Dabei gestalten wirdie Ausgabe in Form eines CSV-Formats, welches direkt in Latex undhier insbesondere in tikzpicture zur grafischen Funktionsabbildung ver-wendet werden kann.

• Das Abtastintervall wird versetzt zu dem Sendeintervall, jedoch mit an-nähernd gleicher Größe, von uns implementiert, die nach vorherigerKalibrierung des akustischen Modems in Bezug auf die Sende- undAbtastintervalle entstehen konnten. Hierbei wurde darauf geachtet das

84 4. Realisierung eines akustischen Modems

Sendeintervall mittig zu dem Abtastintervall auszulegen, um Pufferzo-nen jeweils in beide Richtungen zu realisieren, die sich aus vermutetenIntervall-Unterscheidungen zwischen Sender und Empfänger ergebensollten.

Abbildung 4.11 zeigt die erste Messreihe bei einer fortwährenden Übertra-gung von logischen 1-Werten inklusive STARTBIT. Wider erwarten zeigen dieaufgezeichneten Messwerte eine linear auf- und absteigende Struktur. Dieskann über reine Fehlertoleranz nicht erklärt werden, da hier entweder einschwankender Funktionsverlauf auf nichtlinearer Basis bei sich fortwähren-den Schwankungen der Abtastintervalle in Form von unterschiedlicher Zeit-gestaltung durch Delays und der Programmausführung dazu zuzählenderZeit ergeben müsste. Zudem müsste eine sich fortwährend linear steigenderoder fallender Funktionsverlauf einstellen, falls die Abtastintervalle zwar im-mer die fast identische Größe aufweisen, jedoch das Sendeintervall sich mar-ginal vom Abtastintervall des Empfängers unterscheidet.

Abbildung 4.11.: Fortwährende Übertragung von logischen 1-Werten bei Ab-tastintervallen von 95ms

Abbildung 4.12 zeigt jedoch eine nicht einfache linear steigende oder fallendeFunktion in Bezug auf den Trend der Messwerte (beziehungsweise der Regres-sionsgeraden der Messpunkte), sondern eine sowohl linear steigende, fallendeund sich stabilisierende Funktion in einem sich verengenden Zeitbereich derMesswerte, so das sich dort eine lineare Trendkurve entwickelt.

4.4. Evaluierung 85

Abbildung 4.12.: Messwerte für Abtastintervall 120µs + 63ms und 100cmDistanz

Dies widerspricht unseren Annahmen aus Kapitel 4.2 vollkommen. Für denAusschluss von fehlerhafter Hardware und mangelnder Energieversorgungwurden darauf hin sowohl die Batterie des Senders, als auch der komplet-te Empfangsknoten ausgetauscht. Dies veränderte jedoch nicht die vorherigesich ergebende Funktionskurve.

Als nächste Evaluationsschritt versenden wir folgende Daten: STARTBIT,00110011... sowie im Anschluss STARTBIT, 01010101... .

Auch hier testen wir nun die Auswirkung des Abstandes auf die Datenüber-tragung. Abbildung 4.15 und 4.16 zeigen hierbei die aufgezeichneten Mess-werte.

Als Erklärung für den für uns unerwarteten Verlauf führen wir auf eine inter-ne Regulierung des SRF02 zurück.

Wir passen daher unser akustisches Modem dem unerwarteten Verlauf an, in-dem wir den Bereich bis zur Stabilisierung der Messwerte trendmäßig parallelzur X-Achse verlaufen. Da bis zu diesem Zeitpunkt alle Bitwerte übertragenwerden können, ergibt sich für uns die Konsequenz die Datenpakete inklu-sive Metadaten im Header auf maximal 150 Bytes für eine fehlerfreie Über-tragung zu begrenzen und zudem das Abtastintervall möglichst zeitnah mitdem Sendeintervall zu synchronisieren, um einen Messpuffer in den höherenBereich zu realisieren. Dieser Puffer ist notwendig um den trendmäßig linea-ren Verlauf im ersten Abschnitt der Funktionskurve zu verlängern und den

86 4. Realisierung eines akustischen Modems

Abbildung 4.13.: Messwerte für Abtastintervall 120µs + 63ms und 100cm Di-stanz, 0011

Abbildung 4.14.: Messwerte für Abtastintervall 120µs + 67ms und 40cm Di-stanz, 0101

4.4. Evaluierung 87

Abbildung 4.15.: Messwerte für Abtastintervall 120µs+ 67ms und 4m Distanz,0101

Abbildung 4.16.: Messwerte für Abtastintervall 120µs+ 67ms und 4m Distanz,0101

88 4. Realisierung eines akustischen Modems

für uns fehlerhaften rechten Bereich mit einer parallel zur X-Achse verlau-fenden Trendkurve erst nach möglichst hoher Anzahl an versendeten Bits zuerhalten. Dieser Bereich kann für eine fehlerfreie Datenübertragung sodannvon uns genutzt werden.

Da jedoch die Delays dem Programmcode, wegen unterschiedlich sich darausergebenden Ausführungszeiten des Mikrocontrollers angepasst werden müs-sen, können die verwendeten Delays ausschließlich für diesen implementier-ten Programmcode, für die von uns nutzbaren Funktionsbereiche verwendetwerden. Jede serielle Ausgabe auf unserer Konsole verändert die Funktions-kurve so gravierend, da sich die Intervalle von Sender und Empfänger nichtmehr fehlerfrei in Verbindung setzten lassen.

Bei dem zuvor implementierten 70ms-Abtastintervall mussten wir vornehm-lich wegen der maximal 65ms-Messung des SRF02 unsere Datenrate künst-lich auf 14,285 Bits/Sekunde beschränken. Wir waren darauf angewiesen denMessvorgang vor dem nächsten Abtastintervall zu beenden, um gleich nach70ms den nächsten Messvorgang starten zu können.

Mit der Einführung von Stop-Bits nach jedem Daten- beziehungsweiseMetadaten-Bit, kann die Datenrate deutlich erhöht werden. Hier nützen wirdie Eigenschaft des SRF02 aus, das nach Eingang eines Messwertes der Mess-wert abgefragt werden kann und die Messung somit als beendet gilt. Da wirdas Sendeintervall so gestalten, dass nach spätestens 70ms mit absoluter Si-cherheit eine logische 1 folgt, kann jeweils nach Eintreffen dieser sogenanntenSTOPBITS ein neues Abtastintervall durch Initialisierung eines neuen Mess-vorgangs realisiert werden. So senken wir zwar durch die Einführung desSTOPBITS vorerst die Datenrate, da wir nun zwei Bits für ein Daten-Bit be-ziehungsweise Metadaten-Bit benötigen, können jedoch im Gegenzug hier-durch die Beschränkung auf 65ms für einen Messvorgang auf den von unsgewünschten Wert reduzieren.

Da wir hier in einen sehr zeitkritischen Bereich eindringen, ändern wir zu-dem den Programmcode durch Hinzunahme von Interrupts, die zeitlich ge-nauere Abtast- und Sendeintervalle erzeugen. Hierbei unterscheidet sich dieHerangehensweise mit Interrupts gegenüber derjenigen mit Delays, über ei-ne durch einen sofortigen Abbruch des momentan laufenden Programmcodesund der sofortigen zeitkritischen Ausführung des im Interrupt verwiesenenProgrammcodes. Hierbei initialisieren wir nicht direkt über diesen Interrupteinen Messvorgang, sondern nutzen eine Dauerschleife und der Abfrage einesFlags für die sofortige Ausführung eines Mess- beziehungsweise Sendeinter-valls. Dabei starten wir bei Kennzeichnung des Flags die Methode zur In-itialisierung eines Messvorgang. Interrupts sind dabei gekennzeichnet durcheine Pull- statt Push-Charakteristik. Somit muss nicht ständig nach einem pe-riodisch auftretendem allerdings zeitkritischem Signal nachgefragt werden,sondern wird zeitnah sofort bei Hervorrufen des Signals ausgelöst.

4.4. Evaluierung 89

Hierbei nutzen wir einen von drei möglichen Timer-Registern des ArduinoUno. Und zwar den Timer1. Hierbei handelt es sich um ein Register desArduino Uno Rev. 3.0 der als Zähler die Interrupt-Methode, die wir imple-mentiert haben, unabhängig vom Programmcode auslöst und mit prioritärgegenüber dem normalen Programmcode ausführt. Hierbei spielen die dreifolgenden Parameter eine entscheidende Rolle:

1. Taktungsfrequenz des Mikrocontrollers. Diese liegt beim Arduino UnoRev. 3.0 bei 16MHz.

2. diese kann in den Stufen von 1,8,64,256,1024 durch eine Prescaler umdiesen Faktor für das Timer-Register herabgesetzt werden.

3. der von uns zu nutzenden Frequenz für das automatische Auslösen ei-nes Ereignisses.

4. dem maximal möglichen Zahlenwert für das Timer-Register das bei16.000.000 / Prescaler liegt.

5. der Maximalwert für das Hochzählen des Timer01-Registers (16 Bit):65535.

Bei der Evaluation der veränderten Implementation unseres akustischen Mo-dems gehen wir mit dem Unterschied vor, dass hier die Abtast- und Sender-Intervalle durch Interrupts, statt Delays bewerkstelligt werden.

Wir evaluieren hier eine Datenrate von 100Bits/Sekunde, was einer Steigerungder zuvor erzielten Datenrate von 14,285 Bits/Sekunde entspricht. Durch dieSTOPBITS müssen allerdings effektiv 200Bits/Sekunde übertragen werden.

Der erste Messreihe legen wir auf, wie eben schon erwähnt 100MBits, für denreinen Daten- und Metadaten-Versand fest. Die Entfernung beträgt hierbei40cm. Das Datenpaket bestand ausschließlich aus:STARTBIT,1,STOPBIT,1,STOPBIT,1,STOPBIT,... .Dabei ergab sich wie in Abbildung 4.17 zu sehen ist ein interessanter Verlaufder Messwerte. So steigen die Messwerte konstant linear bis zum maximalmöglichen Messwert von 1250. Das Abtastintervall und Sendeintervall sindsomit nicht synchron und besitzen fortwährend die gleiche Länge. Durch dieVerwendung von Interrupts konnten jedoch kleinere Messintervalle realisiertwerden, die bei Delays zu ungenau ausfallen würden.

4.4.2. Zusammenfassung

Die Evaluation des akustischen Modems ergab eine unerwartete Funktions-kurve der Messwerte, so dass nicht die von uns zuvor theoretisch angenom-mene Sender- und Abtastintervall-Verschiebung, die sich durch nicht 100%-ig

90 4. Realisierung eines akustischen Modems

Abbildung 4.17.: Messwerte für Abtastintervall mit Interrupt

präzises Angleichen ergeben sollte, nicht in um einen Mittelwert alternieren-de Messwerte resultierte. Statt dessen ergab sich eine mehrteilig linear ver-laufende Trendkurve, die sowohl steigende, fallende als auch um einen Mit-telwert schwankende Messwerte ergab. Hierbei ist der jeweilig stückweise li-neare Bereich bis zur abschließend folgenden zur X-Achse parallelen linearenTrendlinie von Bedeutung, da hier keinerlei Fehler auftraten und somit vonunserem Modem genutzt werden sollte. Dies basiert aller Wahrscheinlichkeitnach auf internen Regelungen des SRF02, wobei zuvor durch Hardwareaus-tausch ausgeschlossen wurde, dass es sich um einen Defekt der Hardwarehandelt. Es wurde die reine Datenübertragung in der Form von 01010101...und 111111..., als auch der Paketversand zwischen zwei Knoten, mit demvereinfachten Paket-Protokoll und OOK, wie wir es in Kapitel 2.2 konzipierthaben. Um die Datenübertragung fehlerfrei zu realisieren, adaptierten wirdarauf aufbauend unsere Implementation derart, dass wir das Abtastintervallzeitnah mit dem Sender-Intervall durch ein Delay gleich nach Empfang desSTARTBITS anpassten, um eine möglichst große Anzahl an Bits empfangenzu können, ohne das sich Fehler bemerkbar machen.

5. Anpassung des akustischenModems für eine bidirektionaleDatenübertragung im Schwarm

In diesem Kapitel werden wir konzeptionell das schon implementierte akus-tische Modem beziehungsweise die Netzwerkknoten um eine bidirektionaleDatenübertragung durch ein MAC-Protokoll erweitern. So befassen wir unsals erstes mit der Analyse der schon vorhandenen Lösungsansätze, den not-wendigen Schritte zur Realisierung in Kapitel 5.1 ein und erstellen in Kapitel5.2 die Konzeption für die Realisierung dieses MAC-Protokolls. Da wir in die-ser Diplomarbeit von einer Implementierung dieser Lösung nicht Gebrauchmachen werden, verlagern wir diese auf auf dieser Diplomarbeit aufbauen-den Arbeiten.

925. Anpassung des akustischen Modems für eine bidirektionale Datenübertragung im

Schwarm

5.1. AnalyseFür die Nutzung des zuvor erstellten akustischen Modems in einem ganzenSchwarm von Netzwerkknoten, mangelt es noch um ein Protokoll für den Zu-griff von mehreren Knoten in dem Medium Luft. Dazu benötigt es einer Ab-stimmung und Erkennungsmechanismen von Signalen der Knoten, um mög-liche Anfrage- oder Paketkollisionen zu minimieren und einen fehlerfreienund energiesparenden Betrieb des Schwarms zu garantieren. Dabei gestaltetsich gerade die Kollisionsvermeidung der Datenpaketen schwierig, da in ei-ner terrestrischen Umgebung die Schallgeschwindigkeit sehr hohe Latenzenaufzeigt. Um diesen Latenzen entgegenzuwirken.

5.1.1. Existierende Lösungsansätze

Bei der Lösung unserer in Kapitel 4.1.1 erstellten Anforderungen in Bezugauf die bidirektionale Kommunikation in einem Schwarm gibt es schon einelangjährige Erfahrung im Bereich der Unterwasserakustik und hier insbeson-dere bei der Konzeption von Unterwassernetzwerken. Wir stützen uns hiervornehmlich auf die Erkenntnisse bei der Unterwasserakustik und den UANin denen Milica Stojanovic mit dem MIT und der Northeastern UniversityForschung betrieben hat und aktuell auch noch betreibt.

So nutzen wir die Erkenntnis, dass Protokolle einen erheblichen Einfluss aufden Energieverbrauch in der Akustik mit seiner niedrigen Schallgeschwin-digkeit und somit einer hohen Latenz haben, indem wir, wie bereits in 2.3erwähnt das Slotted-FAMA Protokoll mit seinen für die Akustik optimier-ten Eigenschaften für die Medienzugriffsteuerung unseres Modems verwen-den. Da wir jedoch für dieses Protokoll eine Zeitsynchronisierung der Knotenkonzipieren müssen, können wir wie anhand Clock Synchronization for Wire-less Networks [FaCL05] oder Mobi-Sync: Efficient Time Synchronization for Mobi-le Underwater Sensor Networks [LZPC10] spezialisierte Knoten mit in unserenSchwarm integrieren, die mit beispielsweise einem zusätzlichen GPS-Modul,in Form eines Shields ausgestattet sind und als Zeitgeber für die anderenSchwarmknoten genutzt werden. In Clock Synchronization for Wireless Networks[FaCL05] wird hierfür ein Algorithmus vorgestellt und was für uns noch be-deutsamer ist, die Verwendung eines GPS-Moduls. Da wir es bei elektroma-gnetischen Funkübertragungen mit geringen Latenzen zu tun haben, werdenwir den Algorithmus hier nicht weiter erläutern, da er für uns nicht praktika-bel ist. Wichtig ist hier nur die Erkenntnis spezialisierte Knoten als Zeitgeberzu verwenden, was wie schon mehrmals erwähnt durch ein GPS-Modul be-werkstelligt werden kann.

In Mobi-Sync: Efficient Time Synchronization for Mobile Underwater Sensor Net-works [LZPC10] wiederum werden auch spezialisierte Knoten als Zeitgebergenutzt, nur ist hier auch das Verfahren an die Unterwasserakustik angepasst.

5.1. Analyse 93

5.1.2. Zusammenfassung

Für die Konzeption einer Medienzugriffssteuerung sind hier vorzugsweise dieErkenntnisse aus der Unterwasserakustik anzuwenden. Hierbei sollte man vorallem auf existierende Lösungsansätzen im Unterwasserbereich eingehen. Da-bei verwenden wir vorzugsweise das Slotted-FAMA-Protokoll, das wir kon-zeptionell um einen Synchronisierungs-Algorithmus und einem Synchroni-sierungsimpuls im späteren Verlauf erweitern werden.

Bei der Analyse der bewerkstelligten Synchronisierung der Unterwassernetz-werke, kann festgehalten werden, dass vornehmlich spezialisierte Knoten alsAusgangspunkte für die Synchronisierung im Schwarm eingesetzt werden.

945. Anpassung des akustischen Modems für eine bidirektionale Datenübertragung im

Schwarm

5.2. EntwurfIn diesem Kapitel erweitern wir unser akustisches Modem konzeptionell umein MAC-Protokoll, damit auf diese Weise in späteren Arbeiten die Kom-munikation im Schwarm-Netzwerk ermöglicht werden kann. Dabei wendenwir wie in Kapitel 4.2 das Slotted-FAMA für die Konzeption unseres akusti-schen MAC-Protokolls an. Da wir hierzu jedoch synchrone Netzwerkknotenbenötigen, steht für uns als erster Schritt die Konzeption eines Synchronisie-rungsverfahrens für die spätere Implementation eines Slotted-FAMA. Dabeiverwenden wir für die Konzeption wie in 4.2 spezialisierte Netzwerkknoten,die später mit einem GPS-Modul ausgestattet werden sollen, um genaue Zeit-werte zu ermöglichen. Von diesem oder diesen Netzwerkknoten ausgehend,sollen Synchronisierungsimpulse an das Netzwerk ausgesendet werden, umdie einzelnen internen Timer der Mikrocontroller auf die gleiche Zeit umzu-stellen. Hierbei handelt es sich nicht um den Timer1 des Arduino Uno Rev. 3.0sondern um den Timer2, den wir für unsere Zwecke für die Startpunkte derSlots verwenden wollen. Zudem dient dieser Timer2 ebenso für Timestamp-Anwendungen, wie zum Beispiel dem Protokollieren der Sensordaten.

Wir konzipieren daher einen Synchronisierungsalgorithmus. Wir haben unshierbei für einen selbst erstellten naiven Algorithmus, den wir im folgendenKapitel 5.2.1 beschreiben werden entschieden. Diesen werden wir durch eineSimulationsumgebung in Python, die wir näher in Unterkapitel 5.3.1 evaluie-ren werden.

5.2.1. Synchronisierungsalgorithmus

Unser Algorithmus zur Zeitsynchronisierung in einem Schwarm-Netzwerkmit vielen Knoten, werden wir in den folgenden Absätzen genauer definieren.

Spezielle Knoten, die wir als Beacons, sowie als Nodes bezeichnen, sind mitgenauen Timern durch ein GPS-Modul ausgestattet. Netzwerkknoten, die nichtspezialisiert sind und von sich aus nicht über eine genauere Zeit verfügen,werden wir folgend nur als Nodes bezeichnen.

Unser Algorithmus nutzt eine Distanzeinteilung in Bezug zu Beacons in Formvon Layern, um weiter entferntere Netzwerkknoten mit einer höheren Layer-Nummer zu kennzeichnen. Hierbei sucht ein Netzwerkknoten, der mit einerLayer-Nummer von -1 initialisiert wird, um zu kennzeichnen, dass er nochnicht in das Routing eingebunden ist, zuerst in der Umgebung nach einemNetzwerkknoten mit einer möglichst geringen Layer-Nummer, die kennzeich-net, das sich dieser andere Knoten am Nächsten zu einem Beacon befindet,oder selbst bei der Layer-Nr.0 ist. Durch periodisches Abfragen der Netzwer-knoten in der Nachbarschaft, die in Reichweite sind, können somit immer bes-sere Routings genutzt werden. Wir nutzen somit eine euklidische Metrik fürdie Abstandsberechnung und dem Aufbau des Routings. Die Layer-Nummern

5.2. Entwurf 95

der erreichbaren Nachbarschaftsknoten werden in eine Tabelle, mit ihrer IDsowie der Layer-Nummer eingetragen. Dies ermöglicht uns ein Fallback, fallsein Knoten defekt wird, beziehungsweise eine andere Layer-Nummer erhältund somit ein anderer in unserer Tabelle eingetragener Knoten nun als Gate-way für unsere Datenpakte fungieren soll. Ein Gateway ist hierbei der Knoten,der in unserer Nachbarschafts-Tabelle mit der geringsten Layer-Nummer ein-getragen ist. Dieser Knoten dient uns als Empfänger in einem Sensornetzwerkfür die Übermittlung an die spezialisieren Beacons. Der Netzwerkknoten ansich erhält, wie schon erwähnt, bei der Initialisierung die Layer-Nummer -1,nach dem Empfang von Signalen von Nachbarknoten mit Layer-Nummern,die nicht -1 sind, die Layer-Nummer des Gateways erhöht um den Wert 1.Bei der Synchronisierung haben die Layer-Nummern nun die Aufgabe zu be-stimmen, von welchem Knoten Synchronisierungs-Signale entgegengenom-men werden sollen.

Fällt ein Knoten aus oder verändert seine Layer-Nummer, so wird er entspre-chend in der Nachbarschafts-Tabelle mit seiner neuen Layer-Nummer verse-hen oder komplett gestrichen, falls er nach einem von uns zuvor festgelegtenZeitraum keine Signale mehr ausgesendet hat.

loopif tcurrent − tlast signal arrived > MAX_MISSING_TIME(nodej) then

DELETE nodej FROM nb_listend ifif signal_incoming() then

if nodej /∈ nb_list thenput_node_into_nb_list(nodej)

elseupdate_nb_list(nodej)

end ifend ifif nb_list={} or ∀nodej in nb_list =⇒ layerj = −1 then

gateway = nodeilayeri = −1

elsefor nodej in sort(nb_list, ascenendent) do

if layerj 6= −1 thengateway = nodejlayeri = layerj + 1break

end ifend for

end ifend loop

965. Anpassung des akustischen Modems für eine bidirektionale Datenübertragung im

Schwarm

Wir werden in Unterkapitel 5.2.3 dies anhand der Simulations-GUI mittelsScreenshots illustrieren und erklären.

Auf den Synchronisierungsimpuls, beziehungsweise Ping werden wir im fol-genden Unterkapitel 5.2.2 näher beschreiben, da er unabhängig von allemanderen ist.

Wir gehen aus Vereinfachungsgründen davon aus, dass die Netzwerkknotenzu Beginn synchron getaktet sind, und somit annähernd die gleichen Timer2-Werte aufweisen, damit das TDMA schon nach der Initialisierung angewandtwerden kann. Dies funktioniert nur, wenn die Slots zur richtigen Zeit vonjeden Netzwerkknoten erkannt werden. Dies ist bei dieser Prämisse der Fall.

Hierdurch erhalten wir zudem ein automatisches Routing der Datenpakete ineinem Sensornetzwerk, wo die Netzwerkknoten Daten sammeln sollen undzu zentralen Stellen, den Beacons zur weiter entfernten Einheiten per FunkDaten übertragen können.

5.2.2. SynchronisierungsimpulsFür die Synchronisierung benötigen wir den Abstand zwischen dem jeweili-gen Gateway und dem zu synchronisierenden Knoten, um einerseits die Lauf-zeit des Synchronisierungsimpuls berechnen zu können und andererseits denversendeten Zeitwert um diese Laufzeit zu erhöhen. Zudem wird dieser benö-tigt, um den aktuellen Zeitwert richtig zu bestimmen und mit dem im eigenenTimer2 zu aktualisieren, um ein synchrones Netzwerk für das Slotted-FAMAProtokoll zu erhalten. Diese Herangehensweise der Berechnung der Entfer-nungen und dem Versand eines Synchronisierungsimpulses haben wir denbereits schon mehrfach erwähnten Papern entnommen.

Wir haben dabei zwei Möglichkeiten um den Synchronisierungsimpuls zuimplementieren.

1.) bei einem stationären ad hoc Schwarmnetzwerk kann einmalig die Entfer-nung bestimmt werden und anschließend entweder über einen Synchronisie-rungsimpuls periodisch der aktuelle Zeitwert des Gateway abgefragt werden,oder der Zeitwert in den regulär stattfindenden Paketversand und somit indas Paket-Protokoll eingebunden werden. Letzteres hat hierbei den Vorteil,dass kein zusätzlicher Overhead im Netzwerk erzeugt wird, jedoch den Nach-teil, dass Timer-Abgleiche nur nach einem Datenversand stattfinden können.Hierbei kann bei dem Slotted-FAMA wie folgt vorgegangen werden:

Der Gateway gibt den aktuellen Timer2-Wert mit einem Datenpaket mit aufdem Weg zu dem Knoten. Aufgrund der einmal festgelegten Entfernung derstationären Eigenschaft des Netzwerkes, kann hier einfach die Zeit dazu ad-diert werden, die für den Paketversand notwendig war, um an dem Emp-fangsknoten anzukommen. Zudem muss hier noch die Verarbeitungszeit je-weils von Empfänger und Sender hinzugefügt werden.

5.2. Entwurf 97

2.) Bei einem mobilen ad hoc Schwarmnetzwerk haben wir zudem mit einersich unter Umständen ständig verändernden Netzwerktopologie zu kämpfen.Hier können nicht einmalig die Entfernung zwischen den Nachbarschafts-Knoten gemessen und später verwendet werden, sondern müssen periodischaktualisiert werden um die richtigen Latenzwerte bei der Datenübertragungzu berücksichtigen.

Hier können bei einem ständig stattfindenden Datenversand die Synchroni-sierungsimpulse in die Pakete integriert werden. Da bei Slotted-FAMA zu-vor ein Handshake RTS-CTS vor dem eigentlichen Paketversand stattfindet,können wir selbiges für die Entfernungsberechnung nutzen, um die richtigenLatenzwerte zu berechnen.

So können wir den aktuellen Timer2-Wert des zu synchronisierenden Kno-tens in ein RTS integrieren und den momentan richtigen Zeitwert des Gate-way in ein CTS einbetten. Da ein Datenversand nicht sofort nach Empfangeines RTS bei Slotted-FAMA stattfindet, müssen die Wartezeiten hier nochgespeichert werden. Dies kann durch Speicherung des Empfangszeitpunktesdes RTS beim Gateway und dem aktuellen Timer2-Wert des Gateways beimVersand des CTS mit zu dem synchronisierenden Knoten geschickt werden.

Die Latenz kann über einen Durchschnittswert der Sende- und Empfangsein-gänger wie folgt berechnet werden:

latenz =(tGateway

EinganszeitRTS − ttoSyncSendezeitpunktRTS) + (ttoSync

EinganszeitCTS − tGatewaySendezeitpunktCTS)

2(5.1)

Dabei sei erläutert, dass wir hierbei jeweils die Empfangs- und Sendezeit-punkte im Slotted-FAMA in den RTS und CTS integrieren müssen, damitbei dem zu synchronisierenden Knoten der aktuelle synchrone Timer2-Wertberechnet werden kann. Die Verarbeitungszeit wird hierbei automatisch ver-nachlässigt und die reinen Übertragungszeiten jeweils hin zum Gateway, so-wie auch wieder zurück erfasst und durch einen Mittelwert ermittelt.

985. Anpassung des akustischen Modems für eine bidirektionale Datenübertragung im

Schwarm

5.2.3. SimulationDie Simulationsumgebung erstellten wir mit der Programmiersprache Py-thon, der IDE Eclipse und für die GUI-Oberfläche und das Backend Pysi-de, welche eine Open-Source-Variante von Qt darstellt. Wir nutzen diese Si-mulationsumgebung, um unseren Algorithmus zu evaluieren. Hierbei konntefestgestellt werden, dass der Algorithmus die Synchronisierung, wie wir sieuns vorstellen, verwirklichen kann. Diese zeigen die Abbildungen anhand derverwirklichten Synchronisierungs-Routen, welche grün gestrichelt dargestelltsind. Routings, die nicht bis zu einem Beacon reichen, werden hingegen graugestrichelt dargestellt. Innerhalb der GUI werden zudem die Daten der Nach-barknoten aufgezeigt. Dies waren in Detail: ID, Layer und Entfernung. Desweiteren wird der maximale Senderadius für einen markierten Knoten in derSimulationsumgebung gezeigt.

Die Simulationsumgebung verwendet den in Kapitel 5.2.1 erwähnten Syn-chronisierungsimpuls für jeden einzelnen Knoten und geht zufallsbedingtsämtliche Knoten hierbei durch, damit autonom dezentral die Gateways, Layer-Nummern und Nachbarschafts-Tabellen erstellt werden können. Dies machenwir mit der Absicht den Algorithmus dezentral auf jeden Netzwerkknotenausführen zu können, da wir es mit redundanten Schwarm-Teilnehmern zutun haben.

Die grafische Benutzeroberfläche kann in die folgenden Bestandteile zerlegtwerden:

1. Das Hauptfenster, in dem die Knoten und die Synchronisierungsverbin-dungen dargestellt werden.

2. Das Menü im oberen Bereichs des Fensters, mit den Optionen eine Simu-lation mit veränderbaren Parametern zu erstellen und über den Menü-punkt INIT eine direkte Initialisierung des Synchronisierungsalgorith-mus und der automatischen Erstellung der gesamten Routen in einemSchritt für die zuvor erstelle Simulations-Instanz zu starten.

3. Den Ausgabewerte der Variablen und der Nachbarschafts-Tabelle, dieman auf der rechten Seite von Abbildung 5.2 sehen kann. Hierbei han-delt es sich um genau diese Variablen: Knoten-ID, Layer-Nummer, Gate-way, den Koordinaten des Knotens in dem Versuchsfeld, den Vektor derGeschwindigkeit des Knotens, ob es sich um ein Beacon handelt und derNachbarschafts-Tabelle.

4. Darunter schließen sich die Aktionsfelder an für eine Veränderung derGeschwindigkeit eines Knotens, der Möglichkeit einen weiteren Kno-ten einzufügen, einen bestehenden Knoten zu löschen, einen gelöschtenKnoten wiederherzustellen und einen Knoten als funktionsunfähig zukennzeichnen und somit für den Empfang und dem Versand von Datenzu sperren.

5.2. Entwurf 99

5. Im untersten Abschnitt der Simulationsumgebung findet man die Re-gelung der Simulations-Instanz. Wir gehen hier an dieser Stelle nichtweiter auf die einzelnen Aktions-Knöpfe ein, da sie selbsterklärend seinsollten.

Wir werden nun auf das Dialogfenster, welches man in Abbildung 5.1 sieht,und für die Erstellung einer Simulations-Instanz verwendet wird, näher ein-gehen.

Das Dialogfenster gliedert sich in zwei Bereiche: Objekte (Objects) und Um-gebung (Environment) und dem Simulationsparameter seed, der für die Re-produzierbarkeit der einzelnen Simulationsinstanz angewendet wird.

Wir werden zuerst auf die Parameter der Objekte eingehen. Hier können wirdie Anzahl der normalen Netzwerkknoten, der Beacons, die Länge und somitauch den Betrag des Geschwindigkeitsvektors, der für jeden Knoten gleichinitialisiert wird, und ebenso einen bestimmten Richtungsvektor angeben.

Bei den Umgebungsparametern können wir die Größe des zweidimensionalenVersuchsfeldes vorgeben.

Abbildung 5.1.:

Wir können nun, durch die eben charakterisierte Simulationsumgebung gra-fisch nachweisen, dass unser Synchronisierungs-Algorithmus funktionsfähigist und unseren Anforderungen genügt. Dabei sieht man auf Abbildung 5.2,dass die Routings der Netzwerkknoten, die auf einem Beacon enden syn-chron sind. Die isolierten und damit nicht mit einem Beacon verbundenenNetzwerkknoten, welche durch grau gestrichelte Linien dargestellt sind, zei-gen zwar ein Routing auf, dies führt jedoch nicht zu einer zeitsynchronenTimer-Ausrichtung.

Wir müssten nun im nächsten Schritt das Slotted-FAMA-Protokoll inklusiveSynchronisierungs-Handshake konzipieren. Dies verlegen wir auf diese Di-plomarbeit aufbauenden Arbeiten. Der generelle Aufbau des Slotted-Famakann jedoch wie in Kapitel 2.2.2 erläutert hier noch einmal kurz skizziert wer-den.

1005. Anpassung des akustischen Modems für eine bidirektionale Datenübertragung im

Schwarm

Abbildung 5.2.: Teilweise synchrones Schwarm-Netzwerk. Auf der rechtenSeite kann ein unsynchrones Cluster gesehen werden.

Das Protokoll baut hier auf der Berücksichtigung, der durch die langsame Ge-schwindigkeit auftretenden Latenz. Dies wird durch Verwendung von Carrier-Sense und einem Handshake realisiert, der wie schon erwähnt aus einem RTS-CTS-DATA besteht.

In diesem Handshake wie in Kapitel 2.2.2 beschrieben, kann die Entfernungs-messung integriert werden. So ist es möglich in den Metadaten des RTS denaktuellen Timer2-Wert mit abzuspeichern. In einem CTS kann dann nach demEmpfang dieser Eintreffs-Zeitpunkts festgehalten werden und zudem bei ei-nem verfügbaren Slot-Anfang der diesbezügliche Zeitpunkt in den Metadatendes CTS integriert werden können.

5.2.4. Zusammenfassung

Zusammenfassend kann gesagt werden, dass für die Implementierung desSlotted-FAMA Protokolls, durch die Konzeption eines von uns selbst erstell-ten Synchronisierungsverfahren notwendig ist, das über Layer und einer eu-klidischen Abstandsmessung beruht und hierbei durch die Integration vonZeitstempeln in das Handshake dieses Protokolls integriert werden kann. Da-durch erhalten wir unseren Synchronisierungsalgorithmus, der zugleich auchein Routing für ein Sensornetzwerk darstellt.

5.3. Evaluierung 101

5.3. EvaluierungDie Evaluation des von uns konzipierten Synchronisierungsalgorithmus aufBasis von einer Euklidischen Norm und der Einteilung von Enfternung-Layernzu einem Beacon werden wir auf den folgenden Seiten nun näher beschrieben.

Dabei werden wir anhand einer selbst erstellen GUI die mit Python und demGUI-Framework in Form von Pyside realisiert wurde, auf graphischer Art denvon uns erstellten Algorithmus testen und auswerten. Dies ist dadurch mög-lich, da unsere GUI Synchronisierungs-Routings zu den wie in Kapitel 5.2beschriebenen Gateways durch farbliche Markierung entweder grau für eineVerbindung zu einem Gateway, jedoch mit keiner indirekten Verbindung überdiesen Gateway zu einem Beacon und einer grün gestrichelten Linie für eineindirekte Verbindung über diesen Gateway zu einem Beacon. Dabei stellt eineindirekte Verbindung zu einem Beacon die Realisierung unseres Synchroni-sierungsverfahrens dar, da hier eine möglichst geringer Synchronisierungs-verlust durch Einbeziehung von mehreren Stufen bis zu dem zu synchronisie-renden Knotens gemindert werden kann. Zudem erhalten wir dadurch auto-matische ein Routing zu einem spezialisierten Hub für beispielsweise einemSensornetzwerkes.

5.3.1. Synchronisierungs-Algorithmus

Anhand unserer erstellten Simulationsumgebung werden wir in den folgen-den Absätzen auf die Korrektheit unseres Synchronisierungsalgorithmus mitLayer-Distanzeinteilung eingehen.

Wir verwenden hierzu in der ersten Evaluation folgende Parameter:

• Anzahl der normalen Netzwerkknoten ohne GPS-Modul beträgt 21

• Wir verwenden in dieser Simulationsrunde genau einen Beacon mit derKnoten-ID beziehungsweise MAC-Adresse 0.

• Die Knoten werden initialisiert über einen Zufallsgenerator mit vorge-gebenen Seed-Wert, so das die Ergebnisse reproduzierbar sind.

• Zu Anfang sind Beacons mit der Layer-Nummer 0 und die anderen Kno-ten mit -1 initialisiert.

• Die Geschwindigkeit der mobilen Knoten beträgt 1 m/s

• Die zweidimensionale Simulationsumgebung wird mit 410x530 veran-schlagt.

• Der Seed erhält den Wert 1,0.

• Der maximale Senderadius legen wir auf MAX_TRANSMITTION_RANGE=115m fest.

1025. Anpassung des akustischen Modems für eine bidirektionale Datenübertragung im

Schwarm

Abbildung 5.3.: Initialisierung des Schwarm-Netzwerkes.

Die mit diesen Parameterwerten initiierte Simulations-Instanz sehen wir inAbbildung 5.3. Wie hier zu sehen ist, sind die Netzwerkknoten zufällig in derUmgebung verteilt, wobei der Beacon mit der ID mit der Nummer 0 sich imunteren linken Bereich befindet. Von diesen Knoten sollen die Timer2-Registerauf den kompletten Schwarm ausbreiten, da er als genauer Zeitgeber mit GPS-Modul konzipiert werden soll. Zusätzlich wird der maximale Empfangs- undSenderadius des Beacons anhand eines roten Kreises um ihn herum darge-stellt. Alle in diesem Radius sich befindlichen Knoten sind hier in der Nach-barschaftstabelle mit ihren Initialisierungswerten von -1 für normale Knoteneingetragen, sowie deren Entfernung zu dem markierten Knoten, der in die-sem Fall der Beacon ist, vermerkt. Wir haben zu diesem Zeitpunkt noch keineSynchronisierungs-Routen, daher werden diese auch nicht als gestrichelte Li-nien dargestellt.

Nachfolgend haben wir manuell einige knoten verschoben und die Simu-lationsinstanz gestartet. So ergeben sich die in Abbildung 5.4 aufgezeigtenSynchronisierungs-Routen in Clustern. So gibt es eine funktionsfähige Syn-chronisierung zwischen Knoten0 und Knoten5. Davon abgesehen sind dieCluster, bestehend aus den Knoten: 1,2,3,4,6,7,8,11,15,16,17,18; sowie den Kno-ten: 13,20,21 und den Knoten: 9,10,12,14,19 zwar mit einem Routing versehen,dieses führt jedoch nicht zu einer verbesserten Zeiterfassung, da diese nichtmit einem Beacon in Kontakt stehen. Daher werden diese Verbindungen auchgrau gestrichelt, im Gegensatz zu dem synchronen Teil, der grün markiertwird, dargestellt.

5.3. Evaluierung 103

Abbildung 5.4.: Hier sieht man die Bildung von Routing-Cluster.

Gerade bei Betrachtung des hier markierten Knotens mit der ID 12, kannaus den Werten abgelesen werden, das er als Gateway den Knoten10 mit ei-ner Layer-Nummer von 16 und selbst eine Layer-Nummer von 17 momentandurch unseren dezentralen Synchronisierungs-Algorithmus zugewiesen be-kommen hat.

Wir bleiben beim weiteren zeitlichen Verlauf bei der Markierung des Netz-werkknotens mit der ID 12. Dieser ist nun, wie auch der Rest des Schwarmsdirekt oder indirekt mit dem Beacon in Abbildung 5.5 über einen oder meh-rere Layer verbunden. Dies ist durch die vollständig grün gestrichelten Li-nien ersichtlich. Hierbei erhält unser markierter Knoten12 den Gateway mitder ID9, was korrekt ist, da eine Verbindung zwischen Knoten9 zu Knoten5oder Knoten0 aufgrund einer zu geringen Reichweite nicht möglich ist. Beider Layer-Nummer wird dieser markierte Knoten auf den Wert 4 gesetzt, wo-bei aus der Nachbarschafts-Tabelle ersichtlich ist, das der Gateway die Layer-Nummer 3 durch unseren Algorithmus zugewiesen bekommen hat. Aus derAbbildung ist zudem erkennbar, das es noch 3 Hops bis zum Beacon sind,und daher die folgerichtige Layer-Nummer von 0 für einen Beacon durchSubtraktion von 3− 3 = 0 ergibt.

In Abbildung 5.6 sehen wir die Simulations-Instanz nach fortlaufender Ab-spielzeit und der sich neu ergebenden Routing-Topologie. Durch unserenSynchronisierungs-Algorithmus passen sich die Routings und somit auch dieSynchronisierung der jeweils sich veränderten Knoten-Struktur an und er-zeugen, wenn möglich ein komplett synchrones Schwarm-Netzwerk. Dies ist

1045. Anpassung des akustischen Modems für eine bidirektionale Datenübertragung im

Schwarm

Abbildung 5.5.: Ein komplett synchrones Schwarm-Netzwerk.

allerdings nur möglich, wenn auch die notwendigen Sende- und Empfangs-reichweiten dies zulassen.

Dies ist beispielsweise in Abbildung 5.7 nicht mehr der Fall, wodurch sich einabgesondertes Cluster, bestehend aus den Knoten:16,19,20 am rechten Randergibt.

Wir haben anschließend weitere Simulations-Instanzen mit den Seed-Werten:2,3,4,10,15,20,100 und veränderten Parametereinstellungen in Bezug auf dieAnzahl der Knoten, Beacons, dem Geschwindigkeitsvektor erzeugt. Diese er-gaben, jedes Mal die gleichen Beobachtungen, wie wir sie eben illustrativ be-schrieben haben.

Hierdurch schließen wir darauf das unser Synchronisierungs-Algorithmus,war nicht formal beweisen als Korrekt anzusehen istm, aber mit hoher Wahr-scheinlichkeit anzunehmen ist, das er unseren Zwecken für unseren zu kon-zipierenden akustischen ad hoc Netzwerk-Schwarm genügt.

5.3.2. Zusammenfassung

Bei der Simulation des von uns konzipierten Synchronisierungsalgorithmuskonnte durch die von uns erstellte Simulationsumgebung in der Program-miersprache Python und Pyside graphisch nachgewiesen werden, das der Al-gorithmus in dieser Form, wie wir ihn konzipiert haben funktionsfähig undkorrekt ist. Dies bezieht sich nur auf eine graphische Evaluation und nicht aufeine formale Korrektheitsprüfung.

5.3. Evaluierung 105

Abbildung 5.6.: Synchrones Schwarm-Netzwerk mit veränderter Topologie.

Die Simulationsumgebung zeigte anhand grün gestrichelter Linien Synchro-nisierungspfade. Diese Synchronisierungspfade konnten erreicht werden, daNetzwerkknoten mit genauen Zeitgebern, in Form von beispielsweise einemGPS, die annähernd gleichen Abtast- und Sendeintervalle, durch die synchro-ne Timer2 Ausrichtung des Schwarms eingebunden wurden. Netzwerkkno-ten, die zwar Cluster bilden konnten, jedoch keinen Kontakt zu einem Syn-chronisierungsknoten aufbauen konnten, erstellten zwar Pfade, diese warenwegen dem fehlenden Kontakt zu einem Beacon nicht mit dem Schwarm aus-gerichtet und somit farblich grau markiert.

1065. Anpassung des akustischen Modems für eine bidirektionale Datenübertragung im

Schwarm

Abbildung 5.7.: Teileweise synchrones Schwarm-Netzwerk. Auf der rechtenSeite kann ein unsynchrones Cluster gesehen werden.

6. Zusammenfassung und Ausblick

In der Diplomarbeit konnten wir nach genauer Analyse von Unterwassernetz-werken, die Erfahrungswerte dieser und mit Hilfe eigener Ansätze ein akus-tisches ad hoc Schwarm-Netzwerk konzipieren. Anhand geeigneter Quellenaus diesem Bereich, konnten die Anforderungen und die Rahmenbedingun-gen für unseren terrestrischen Bereich erstellt werden. Hier stellt vor allemdie geringe Ausbreitungsgeschwindigkeit von Schallwellen in der Luft füreine effektive Datenübertragung in einem Schwarm eine große Herausforde-rung dar, da diese zu hohen Latenzen führt und man nicht schon vorhandeneMAC-Protokolle für drahtlose Funknetze übernehmen kann. Statt dessen istman darauf angewiesen, um eine möglichst effiziente Energieverwendung derNetzwerkknoten zu gewährleisten, möglichst wenig Paketkollisionen entste-hen zu lassen. Dies kann durch die Verwendung des Slotted-FAMA Proto-kolls, das extra für die hohen Latenzen in Unterwassernetzwerken konzipiertwurde auch für unsere terrestrische Anwendung genutzt werden.

Bei der Auswahl der zu verwendeten Frequenz für das Signal der Trägerwellemuss abgewägt werden, dass eine höhere Bitrate mit einer höheren Frequenzkorreliert und dabei jedoch einem immer gerichteteren Ausbreitungsverlaufunterliegt. Da die Kommunikation im einem Schwarm jedoch in einem Bursterfolgen, sind höhere Bitraten essentiell, zudem da die Dichte der Knoteninnerhalb eines bestimmten Bereichs möglichst hoch veranschlagt werden soll.Dadurch sind wir darauf angewiesen möglichst hohe Bitraten und somit auchFrequenzen zu verwenden.

Im Rahmen dieser Diplomarbeit wurden nach Analyse der vergleichbarenUnterwassernetzwerken zwei Prototypen von Netzwerkknoten erstellt, diekonzeptionell für den Einsatz in einem Schwarm-Netzwerk ausgerichtet sindund in Form eines akustischen Modems implementiert wurden, das mit ei-nem vereinfachten Paket-Protokoll und einem OOK als MAC-Protokoll im-

108 6. Zusammenfassung und Ausblick

plementiert wurden. Dabei wurde konzeptionell auch ein MAC-Protokoll, dasSlotted-FAMA und das dazugehörige Synchronisierungsverfahren theoretischerstellt und durch eine Simulationsumgebung in Bezug auf den verwendetenSynchronisierungs-Algorithmus evaluiert.

Da wir im Rahmen des Slotted-FAMA Protokolls auf synchronisierte Zeitwer-te angewiesen sind, da diese für die Funktionsweise dieses Protokolls notwen-dig sind, konzipierten wir einen Synchronisierungs-Algorithmus, der zumeinen auf ein möglichst kurzes Routing zu einem spezialisierten Synchron-isierungs- und gleichzeitig auch als Hubknoten fungierenden Netzwerkkno-ten aufbaut. Hierbei wird die euklidische Metrik in Form von Layern genutzt,die sich durch die Erreichbarkeit von sogenannten Beacons, welche die genaueZeiterfassung durch GPS-Module ermöglichen oder als Gateway dazwischenliegenden Knoten, die mit einer höheren Layer-Nummer, je weiter sie von ei-nem Beacon entfernt sind, realisiert.

Hierbei war bei der theoretischen Konzeption zu beachten, dass sich einemöglichst genau Synchronisierung der Netzwerkknoten nur durch eine Lauf-zeitmessung zwischen dem jeweiligen Gateway und einem Knoten bewerk-stelligen lässt. Diese Zeitmessung kann wiederum in den Handshake, der ausRTS-CTS-DATA besteht integriert werden.

Bei der genauen Implementierung der Bitübertragung, wird zum einen einAnsatz über künstliche Pausen (Delays) im Programmfluss unseres Quellco-des der akustischen Modems, als auch über Interrupts, die noch eine genauerezeitliche Gestaltung der Abtast- und Sendeintervalle, realisiert. Dabei wird beidem Ansatz mit Interrupts zudem ein weiteres STOPBIT eingesetzt, um höhe-re Datenraten zu ermöglichen, da wir sonst auf die Beendigung eines Mess-vorgangs nach maximal 65ms vor dem Auslösen eines weiteren angewiesensind.

Diese Netzwerkknoten wurden im Rahmen einer einfachen Testdatenübertra-gung von einem Senderknoten zu einem Empfängerknoten in einer bidirek-tionalen Datenübertragung evaluiert. Hierbei stellte sich eine überraschenderVerlauf der gemessenen Messwerte heraus. So münden auf Grund von Re-gelungen innerhalb des SRF02 oder des Arduino Uno Abtastintervalle undSendeintervalle unterschiedlich versetzt nach bestimmten Anzahlen von ein-gegangenen Messwerten einerseits in einem linearen Trendverlauf der einmalabsteigend, aufsteigend und stabil parallel zur X-Achse ausfällt. Dabei ist fürdie fehlerfreie Datenübertragung nur der Bereich vor dem sich stabilisieren-den parallel zur X-Achse verlaufenden Trendkurve der Messwerte mit fehler-haften Bitwert-Auswertungen für uns nutzbar.

Die Netzwerkknoten-Prototypen konnten anhand der Physical-Computing-Plattform Arduino Uno Rev. 3.0 und einem Ultraschallsensor, der die meistenBestandteile eines Transceiver-Moduls schon für uns integriert hatte, realisiert

109

werden. Diese bestehen im Einzelnen aus den folgenden Komponenten: Ver-stärker, Bandpassfilter, Schallwandler, Signalgeber, verarbeitende Einheit fürden Vergleich der Trägerwelle und der Zeitmessung des Signals. Dabei warvon ausschlaggebender Bedeutung, dass ein Piezo-Schallwandler mit seinemhohen Wirkungsgrad für eine geringe Leistungsaufnahme von dem SRF02genutzt wird, da wir zum einen eine geringe Leistungsaufnahme für einenmöglichen mobilen, beziehungsweise längeren autonomen Betrieb in einemSchwarm ermöglichen wollen. Zudem liegt mit 40kHz die Trägerwelle außer-halb des Ultraschallbereichs, welcher nicht mehr in der menschlichen Wahr-nehmung liegt und somit von uns genutzt werden kann. Dies hat jedoch denNachteil, das wir mit einer Richtungscharakteristik mit einem Halbwertwinkelvon 30 beziehungsweise 60 Grad uns auseinandersetzen müssen. Dies kann je-doch durch die Verwendung mehrerer Ultraschallsensoren, die so angeordnetwerden, das sich möglichst wenig Interferenzen bilden ausgeglichen werden.

Im Folgenden soll noch die Realisierung, die möglichen Erweiterungen be-ziehungsweise die mögliche Implementation, der von uns rein konzeptionellerarbeiteten Bestandteile erörtert werden.

Durch die Verwendung der Physical-Computing-Plattform Arduino Rev. 3.0stehen zudem viele interessante Anwendungszwecke, wie beispielsweise Sen-sornetzwerke durch zusätzlich leicht integrierbarer Peripherie zur Verfügung.Hierbei kann gerade durch Verwendung von Shields auf einfachste Art undWeise der Funktionsumfang der Knoten des Schwarms erweitert oder ange-passt werden. So steht auch die Option zur Verfügung spezialisierte Schwarm-knoten zu erstellen und so den Schwarm beispielsweise dem Aufbau einerAmeisenkolonie anzugleichen.

Für eine verbesserte Richtungscharakteristik in Form von einer annäherndkreisförmigen Ausbreitung sollten zudem mehrere Ultraschallsensoren oderSchallwandler mit zugehörigen Transceiver-Modulen zusätzlich implemen-tiert werden. Hierbei muss jedoch auf die entstehenden Interferenzen durchÜberschneidung der jeweiligen Schallwellenausbreitungen geachtet werden,da es sonst zu einer fehlerhaften Datenübertragung kommen kann.

Abschließend kann gesagt werden, das wir anhand unserer Diplomarbeit zei-gen konnten, dass eine akustische Datenübertragung mit einem Ultraschall-sensor und der Physical-Computing-Plattform Arduino realisiert werden kann.Der Einsatz für einen Schwarm wurde durch diese Arbeit vorbereitet undkann in Bezug auf die Hardware schon praktisch implementiert werden. Füreinen vollständigen Einsatz in einem akustischen ad hoc Schwarmnetzwerksind noch die Implementierung des MAC-Protokolls, das von uns konzipiertwurde notwendig. Hier wurden von uns schon die essenziellen Bestandtei-le, wie die Synchronisierung und die weitere Anpassung des Slotted-FAMA-Protokolls für diese Zwecke entworfen. Es muss jedoch beachtet werden, dass

110 6. Zusammenfassung und Ausblick

die akustische Datenübertragung im terrestrischen Umfeld der elektromagne-tischen Übertragung, durch die deutlich geringere Ausbreitungsgeschwindig-keit zu geringeren Datenraten, höherer Latenzen et cetera unterlegen ist. Da-durch ist diese Art der Datenübertragung eher für den Einsatz Unterwasserund in Umgebungen, wo elektromagnetische Übertragungen nicht zu präfe-rieren sind, anzuwenden.

A. Anhang

112 A. Anhang

A.1. Quellcode

Listing A.1: Quellcode des Empfaenger Knotens der mittels Interrupts die Ab-tastintervalle erzeugt. Receiver.cpp

1 // Do not remove the include below#include "Receiver.h"

3 //#include "TimerOne.h"#include "Wire.h"

5

unsigned i n t measure1 =0;7 unsigned i n t measure2 =0;

v o l a t i l e bool f l a g S i g n a l I n c r e a s e = f a l s e ;9 v o l a t i l e bool f l a g S i g n a l = f a l s e ;

v o l a t i l e bool f l a g S i g n a l 2 = f a l s e ;11

v o l a t i l e unsigned i n t t e s t =0;13 v o l a t i l e unsigned i n t b u f f e r P o i n t e r =0;

v o l a t i l e unsigned i n t b u f f e r S t a r t P o s =0;15 v o l a t i l e unsigned i n t b u f f e r S i g n a l s [ 1 0 0 ] ;

17 const unsigned i n t INTERVALL = 4000;//32000boolean l a s t _ b i t _ f l a g = f a l s e ;

19 boolean echo_of f= f a l s e ;const i n t ULTRA_TRANS_ADDRESS = 1 1 2 ;

21 const i n t ULTRA_RECEIV_ADDRESS = 1 1 3 ;const unsigned i n t MAX_MEASURE_TIME=65279;

23 unsigned i n t reading =0;i n t contro l le rReadout =−1;

25 i n t counter =0;const unsigned i n t TIMEOUT=0; //too much 15752;// old 11000

27 const i n t TIMEOUT_2=20000;boolean f l a g = f a l s e ;

29 const unsigned long WAITING_TIME=2; //65 //1000 //285 //282.9999 toof a s t ! ! 282 .99999 too slow /// 20

boolean b i t _ f l a g = f a l s e ;31 unsigned long s t a r t _ t i m e = 0 . 0 ;

unsigned long end_time = 0 . 0 ;33

35 / / * * * * * * * * * * * * HEADER * * * * * * * * * * * * * *

37 //START BITSunsigned char HEADER_START_BITS_SIZE=1;

39

//DATA, RTS , CTS , . . . in b i t s f o r b i t s ! !41 unsigned char MSG_TYPE_SIZE=4;

43 //Maximal number of i n d i v i d u a l s in a l o c a l network in b i t s f o r b i t s! !

unsigned char MAC_Address_SIZE =8;45

//Max DATA−s i z e in b i t s f o r BYTES ! ! ! ( * * * be c a r e f u l l y * * * )

A.1. Quellcode 113

47 unsigned char DATA_SIZE=8;

49 //Number of B i t s in one Byteunsigned char BYTE=8;

51

53 / / * * * * * * * * * * * * HEADER END * * * * * * * * * * * * * *

55

57

59

/**61 * S e t s the board in a mode to get t ransmiss ion packets .

*/63 void act ivate_rece iv ing_mode ( ) {

/*65 * Act iva te r e c e i v e r to l i s t e n to the channel

*/67

Wire . beginTransmission ( 1 1 3 ) ; //I2C ID69 Wire . wri te ( byte (0 x00 ) ) ; // Set po inter to −> r e g i s t e r 0 −>

c o n t r o l r e g i s t e rWire . wri te ( byte (0 x58 ) ) ; // operat ion −> look f o r 40k s i g n a l

71 Wire . endTransmission ( ) ;}

73

75

/**77 * Look f o r a 40k s i g n a l and return a f t e r f i r s t seen a 1 .

*/79

bool s t a r t _ s y n c h r o n i z e ( ) {81 while ( t rue ) {

contro l le rReadout =−1;83 act ivate_rece iv ing_mode ( ) ;

85 Wire . beginTransmission ( 1 1 3 ) ;// I2C IDWire . wri te ( byte (0 x00 ) ) ; // Set po inter to −> r e g i s t e r 0 −>

c o n t r o l r e g i s t e r87 Wire . endTransmission ( ) ;

delay ( 2 ) ;89

91

while ( contro l le rReadout ==−1)93 {

114 A. Anhang

95 //Wire . requestFrom ( 1 1 3 , 1 ) re turns −1, i f a measurement i ss t i l l in progress . Otherwise a number i s returned and the loopw i l l break .

Wire . requestFrom ( 1 1 3 , 1 ) ; //I2C ID 1 1 3 ; r e g i s t e r 0 look f o r 1byte

97 contro l le rReadout=Wire . read ( ) ;delay ( 2 ) ;

99

}101

// R e g i s t e r Pointer to 0x02103 Wire . beginTransmission ( 1 1 3 ) ; // I2C ID 113

Wire . wri te ( byte (0 x02 ) ) ; // Set po inter to −> echo #1register (0x02)

105 Wire . endTransmission ( ) ;delay ( 2 ) ;

107

109 //Readout low and high b i t of r e g i s t e r 0x02Wire . requestFrom ( 1 1 3 , 2 ) ;

111 reading=Wire . read ( ) ;reading =( reading * 256) + Wire . read ( ) ;

113 //delay ( 2 ) ;

115

// S e r i a l . p r i n t ( "DATA−BIT : " ) ;117 //0 i f 65ms measurement i s without echo

i f ( reading !=TIMEOUT ) {119 //1 rece ived

S e r i a l . p r i n t l n ( " P o s s i b l e packet i s incoming " ) ;121

//This delay i s important to e l i m i n a t e f u r t h e r 40k s i g n a l sfrom one measurement process .

123 // delay ( 1 ) ;//12//20return true ;

125 }}

127

129 }

131

/**133 * Read out the firmware information of the SRF02

*/135 void read_firmware ( ) {

Wire . beginTransmission ( 1 1 3 ) ; //IC2 ID 113137 Wire . wri te ( byte (0 x00 ) ) ; // Set po inter to −> r e g i s t e r 0 −>

c o n t r o l r e g i s t e rWire . endTransmission ( ) ;

139 delay ( 2 ) ;

A.1. Quellcode 115

Wire . requestFrom ( 1 1 3 , 1 ) ; //Readout 1 byte from r e g i s t e r , t h a twas before chosen .

141 contro l le rReadout=Wire . read ( ) ;contro l le rReadout =−1;

143 delay ( 2 ) ;}

145

147

/**149 * Returns 1 b i t of a t ransmiss ion .

*/151 unsigned char r e c e i v e _ b i t ( ) {

153

155 //save s t a r t−time f o r synchronizat ion of r e c e i v i n g b i t i n t e r v a l s .// s t a r t _ t i m e = m i l l i s ( ) ;

157

//Go i n t o r e c e i v i n g mode159 act ivate_rece iv ing_mode ( ) ;

161

/*163 * Po inter to R e g i s t e r 0x02

*/165 //delay ( 2 ) ;

Wire . beginTransmission ( 1 1 3 ) ; // transmit to device #112167 Wire . wri te ( byte (0 x02 ) ) ; //Set po inter to −> r e g i s t e r (0 x02 )

Wire . endTransmission ( ) ;169

while ( not f l a g S i g n a l ) {171 //noInter rupts ( ) ;

// f l a g S i g n a l 2 = f l a g S i g n a l ;173 // i n t e r r u p t s ( ) ;

// S e r i a l . p r i n t l n ( Timer1 . read ( ) ) ;175 // S e r i a l . p r i n t ( " Loop " ) ;

}177 noInter rupts ( ) ;

f l a g S i g n a l = f a l s e ;179 i n t e r r u p t s ( ) ;

181

/*183 * Read low and high b i t from r e g i s t e r (0 x02 )

*/185 //delay ( 2 ) ;

Wire . requestFrom ( 1 1 3 , 2 ) ;187 reading=Wire . read ( ) ;

reading =( reading * 256) + Wire . read ( ) ;189

116 A. Anhang

191

i f ( reading >7000) {193 noInter rupts ( ) ;

f l a g S i g n a l I n c r e a s e =true ;195 i n t e r r u p t s ( ) ;

}197 e l s e {

i f ( reading >5000) {199 noInter rupts ( ) ;

f l a g S i g n a l I n c r e a s e = f a l s e ;201 i n t e r r u p t s ( ) ;

}203 e l s e {

i f ( reading >6000) {205 noInter rupts ( ) ;

f l a g S i g n a l I n c r e a s e =true ;207 i n t e r r u p t s ( ) ;

}209 e l s e {

noInter rupts ( ) ;211 f l a g S i g n a l I n c r e a s e = f a l s e ;

i n t e r r u p t s ( ) ;213 }

215

}217

}219

221

223

225 delay ( 2 ) ;//delay ( 2 ) ;

227 // S e r i a l . p r i n t l n ( reading ) ;

229

// S e r i a l . p r i n t ( " Reading_ : " ) ;231

i f ( f l a g S i g n a l 2 ) {233 // S e r i a l . p r i n t ( "DOWN" ) ;

}235 e l s e { // S e r i a l . p r i n t ( "UP" ) ;

}237

// S e r i a l . p r i n t l n ( reading ) ;239 i f ( reading >INTERVALL or reading==0 ) {

S e r i a l . p r i n t ( " 0 " ) ;241 re turn 0 ;

}

A.1. Quellcode 117

243 e l s e {S e r i a l . p r i n t ( " 1 " ) ;

245 re turn 1 ;

247 }

249 // measure2=measure1 ;// measure2=reading ;

251 // i f ( ( unsigned i n t ) ( measure1−measure2 ) <1000) {// i f ( measure1<measure2 ) {

253 // noInter rupts ( ) ;// f l a g S i g n a l I n c r e a s e =true ;

255 // i n t e r r u p t s ( ) ;// }

257 // e l s e {// noInter rupts ( ) ;

259 // f l a g S i g n a l I n c r e a s e = f a l s e ;// i n t e r r u p t s ( ) ;

261 //// }

263 // }

265

}267

269

271

void star t_rece iv ing_mode ( ) {273 S e r i a l . p r i n t l n ( " * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * " ) ;

S e r i a l . p r i n t l n ( " RECEIVING STATE ON " ) ;275 S e r i a l . p r i n t l n ( " * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * " ) ;

while ( ! s t a r t _ s y n c h r o n i z e ( ) ) { }277 delayMicroseconds ( 1 0 0 0 ) ;

noIn ter rupts ( ) ;279 TIMSK1=0x01 ; // enabled globa l and timer overflow i n t e r r u p t ;

TCNT1=63036; // 16 b i t counter r e g i s t e r281 TCCR1B = 0x03 ; // s t a r t t imer/ s e t c lock

i n t e r r u p t s ( ) ;283

}285

287

289 /*** Reads packet information f o r " number_of_bits " p laces .

291 */unsigned char r e c e i v e _ b i t s ( unsigned char number_of_bits ) {

293 unsigned char number =0;f o r ( unsigned char i =0; i <number_of_bits ; i ++) {

118 A. Anhang

295 number = number << 1 ;number = number + r e c e i v e _ b i t ( ) ;

297 }

299 re turn number ;

301

}303

//Looks f o r the305 unsigned char look_for_msg_type ( ) {

re turn r e c e i v e _ b i t s ( MSG_TYPE_SIZE ) ;307 }

309 unsigned char look_for_MAC_address ( ) {re turn r e c e i v e _ b i t s ( MAC_Address_SIZE ) ;

311 }

313

unsigned char look_for_data_ length ( ) {315 re turn r e c e i v e _ b i t s (DATA_SIZE) ;

}317

unsigned char look_for_1_byte_data ( ) {319 re turn r e c e i v e _ b i t s (BYTE) ;

321 }

323 //type to boolean ? !unsigned char l o o k _ f o r _ p a r i t y _ b i t ( ) {

325 re turn r e c e i v e _ b i t s ( 1 ) ;}

327

boolean p a r i t y _ b i t _ c h e c k ( boolean p a r i t y b i t , unsigned char b i t s ) {329 //return true ;

b i t s ^= b i t s > >4;331 b i t s ^= b i t s > >2;

b i t s ^= b i t s > >1;333 b i t s &= 1 ;

335 i f ( ! b i t s == p a r i t y b i t ) {re turn true ;

337

}339 e l s e {

re turn f a l s e ;341 }

343 }

345

A.1. Quellcode 119

347 S t r i n g look_for_data ( unsigned char number_bytes ) {S t r i n g data=" " ;

349 unsigned char data_1_byte ;boolean p a r i t y = f a l s e ;

351 f o r ( unsigned char i =0; i <number_bytes ; i ++) {

353 data_1_byte=look_for_1_byte_data ( ) ;

355

//PARITY357 S e r i a l . p r i n t l n ( ) ;

S e r i a l . p r i n t ( " Par i ty−BIT : " ) ;359 p a r i t y = p a r i t y _ b i t _ c h e c k ( l o o k _ f o r _ p a r i t y _ b i t ( ) , data_1_byte ) ;

i f ( p a r i t y ) {361 S e r i a l . p r i n t l n ( ) ;

S e r i a l . p r i n t l n ( "PARITY_CHECK : OK" ) ;363 S e r i a l . p r i n t l n ( ) ;

}365 e l s e {

S e r i a l . p r i n t l n ( ) ;367 S e r i a l . p r i n t l n ( "PARITY_CHECK : ERROR" ) ;

S e r i a l . p r i n t l n ( ) ;369 //WHAT RETURN? ? ? ? ? ? ? ? ? ? ? ? ? ?

re turn "ERROR" ;371 }

373

375

377

data=data+data_1_byte ;379

381

383 data=data+" _ " ;

385

}387

re turn data ;389

391 }

393

unsigned char msg_type =0;395 unsigned char mac_address_from =0;

unsigned char mac_address_to =0;397 unsigned char data_length =0;

S t r i n g data=" " ;

120 A. Anhang

399 boolean p a r i t y = f a l s e ;unsigned char h e a d e r _ s t a r t =0;

401

403 unsigned char h e a d e r _ s t a r t _ b i t s ( ) {re turn r e c e i v e _ b i t s ( HEADER_START_BITS_SIZE ) ;

405

}407

409

void rece ive_packe t ( ) {411

S e r i a l . p r i n t l n ( ) ;413 S e r i a l . p r i n t ( "HEADER START BITS : " ) ;

S e r i a l . p r i n t l n ( " 1 " ) ;415 S e r i a l . p r i n t l n ( ) ;

417

419

msg_type=look_for_msg_type ( ) ;421

423 S e r i a l . p r i n t l n ( ) ;S e r i a l . p r i n t ( "MSG_TYPE : " ) ;

425 S e r i a l . p r i n t l n ( msg_type ) ;S e r i a l . p r i n t l n ( ) ;

427

//PARITY429 S e r i a l . p r i n t ( " Par i ty−BIT : " ) ;

p a r i t y = p a r i t y _ b i t _ c h e c k ( l o o k _ f o r _ p a r i t y _ b i t ( ) , msg_type ) ;431 i f ( p a r i t y ) {

S e r i a l . p r i n t l n ( ) ;433 S e r i a l . p r i n t l n ( "PARITY_CHECK : OK" ) ;

S e r i a l . p r i n t l n ( ) ;435 }

e l s e {437 S e r i a l . p r i n t l n ( ) ;

S e r i a l . p r i n t l n ( "PARITY_CHECK : ERROR" ) ;439 S e r i a l . p r i n t l n ( ) ;

//WHAT RETURN? ? ? ? ? ? ? ? ? ? ? ? ? ?441 re turn ;

}443

445

447

mac_address_from=look_for_MAC_address ( ) ;449

S e r i a l . p r i n t l n ( ) ;

A.1. Quellcode 121

451 S e r i a l . p r i n t ( "MAC_FROM: " ) ;S e r i a l . p r i n t l n ( mac_address_from ) ;

453 S e r i a l . p r i n t l n ( ) ;

455 //PARITYS e r i a l . p r i n t ( " Par i ty−BIT : " ) ;

457 p a r i t y = p a r i t y _ b i t _ c h e c k ( l o o k _ f o r _ p a r i t y _ b i t ( ) , mac_address_from ) ;i f ( p a r i t y ) {

459 S e r i a l . p r i n t l n ( ) ;S e r i a l . p r i n t l n ( "PARITY_CHECK : OK" ) ;

461 S e r i a l . p r i n t l n ( ) ;}

463 e l s e {S e r i a l . p r i n t l n ( ) ;

465 S e r i a l . p r i n t l n ( "PARITY_CHECK : ERROR" ) ;S e r i a l . p r i n t l n ( ) ;

467 //WHAT RETURN? ? ? ? ? ? ? ? ? ? ? ? ? ?re turn ;

469 }

471 mac_address_to=look_for_MAC_address ( ) ;

473

475 S e r i a l . p r i n t l n ( ) ;S e r i a l . p r i n t ( "MAC_TO: " ) ;

477 S e r i a l . p r i n t l n ( mac_address_to ) ;S e r i a l . p r i n t l n ( ) ;

479

//PARITY481 S e r i a l . p r i n t ( " Par i ty−BIT : " ) ;

p a r i t y = p a r i t y _ b i t _ c h e c k ( l o o k _ f o r _ p a r i t y _ b i t ( ) , mac_address_to ) ;483 i f ( p a r i t y ) {

S e r i a l . p r i n t l n ( ) ;485 S e r i a l . p r i n t l n ( "PARITY_CHECK : OK" ) ;

S e r i a l . p r i n t l n ( ) ;487 }

e l s e {489 S e r i a l . p r i n t l n ( ) ;

S e r i a l . p r i n t l n ( "PARITY_CHECK : ERROR" ) ;491 S e r i a l . p r i n t l n ( ) ;

//WHAT RETURN? ? ? ? ? ? ? ? ? ? ? ? ? ?493 re turn ;

}495

497

499

i f ( msg_type==2) {501

data_length=look_for_data_ length ( ) ;

122 A. Anhang

503

S e r i a l . p r i n t l n ( ) ;505 S e r i a l . p r i n t ( "DATA SIZE : " ) ;

S e r i a l . p r i n t ( data_length ) ;507 S e r i a l . p r i n t l n ( " bytes " ) ;

S e r i a l . p r i n t l n ( ) ;509

511 //PARITYS e r i a l . p r i n t ( " Par i ty−BIT : " ) ;

513 p a r i t y = p a r i t y _ b i t _ c h e c k ( l o o k _ f o r _ p a r i t y _ b i t ( ) , data_length ) ;i f ( p a r i t y ) {

515 S e r i a l . p r i n t l n ( ) ;S e r i a l . p r i n t l n ( "PARITY_CHECK : OK" ) ;

517 S e r i a l . p r i n t l n ( ) ;}

519 e l s e {S e r i a l . p r i n t l n ( ) ;

521 S e r i a l . p r i n t l n ( "PARITY_CHECK : ERROR" ) ;S e r i a l . p r i n t l n ( ) ;

523 //WHAT RETURN? ? ? ? ? ? ? ? ? ? ? ? ? ?re turn ;

525 }

527

529 data= look_for_data ( data_length ) ;

531

S e r i a l . p r i n t l n ( ) ;533 S e r i a l . p r i n t ( "DATA: " ) ;

S e r i a l . p r i n t l n ( data ) ;535 S e r i a l . p r i n t l n ( ) ;

537

539 }e l s e {

541 S e r i a l . p r i n t l n ( ) ;S e r i a l . p r i n t ( "NO DATA INCLUDED" ) ;

543 S e r i a l . p r i n t l n ( ) ;

545 }

547

549

551 switch ( msg_type ){

553 //RTScase 0 :

A.1. Quellcode 123

555 break ;

557 //CTScase 1 :

559 break ;

561 //DATAcase 2 :

563 break ;}

565 }

567

void doIT ( void ) {569 // t e s t ++;

// b u f f e r S i g n a l s [ b u f f e r P o i n t e r ] = b u f f e r P o i n t e r ;571 // i f ( b uf fe r Po in ter <98) {

// b u f f e r P o i n t e r = b u f f e r P o i n t e r +1;573 // }

// e l s e {575 // b u f f e r P o i n t e r =0;

// }577 f l a g S i g n a l =true ;

// S e r i a l . p r i n t ( "P" ) ;579 }

581

void setup ( ) {583 //Receiving s t a t e

S e r i a l . begin ( 1 9 2 0 0 ) ;585 Wire . begin ( ) ;

587 //Timer1 . r e s t a r t ( ) ;//delay ( 4 ) ;

589 //Timer1 . s t a r t ( ) ;delay ( 1 0 0 ) ;

591 //Timer1 . i n i t i a l i z e ( 3 2 0 0 0 ) ;//Timer1 . stop ( ) ;

593 //Timer1 . a t t a c h I n t e r r u p t ( doIT ) ;noInter rupts ( ) ; // d i s a b l e a l l i n t e r r u p t s

595 TIMSK1=0x01 ; // enabled globa l and timer overflow i n t e r r u p t ;TCCR1A = 0x00 ; // normal operat ion page 148 ( mode0 ) ;

597 //TCCR1B = 0x04 ; // s t a r t t imer/ s e t c locki n t e r r u p t s ( ) ; // enable a l l i n t e r r u p t s

599 s tar t_rece iv ing_mode ( ) ;

601

603 }

605 ISR ( TIMER1_OVF_vect ) {i f ( f l a g S i g n a l I n c r e a s e ) {

124 A. Anhang

607

TCNT1 = 63036−100;//63536 // preload timer609 f l a g S i g n a l 2 =true ;

611

613 }e l s e {

615 f l a g S i g n a l 2 = f a l s e ;TCNT1 = 63036+100;//63536 // preload timer

617

}619 //TCNT1 = 63536;//63536 // preload timer

// S e r i a l . p r i n t l n ( "MUH" ) ;621 f l a g S i g n a l =true ;

// b u f f e r S i g n a l s [ b u f f e r P o i n t e r ] = b u f f e r P o i n t e r ;623 // i f ( b uf fe rPo in ter <98) {

// b u f f e r P o i n t e r = b u f f e r P o i n t e r +1;625 // }

// e l s e {627 // b u f f e r P o i n t e r =0;

// }629 }

631

633

635 void loop ( ) {// S e r i a l . p r i n t ( " Po inter : " ) ;

637 // S e r i a l . p r i n t l n ( b u f f e r P o i n t e r ) ;// S e r i a l . p r i n t l n ( b u f f e r S i g n a l s [ b u f f e r P o i n t e r ] ) ;

639 // S e r i a l . p r i n t ( t e s t ) ;// i n t e r r u p t s ( ) ;

641

// rece ive_packe t ( ) ;643 // noInter rupts ( ) ;

// TIMSK1=0x00 ; // enabled globa l and timer overflow i n t e r r u p t ;645 // i n t e r r u p t s ( ) ;

647 r e c e i v e _ b i t ( ) ;// star t_rece iv ing_mode ( ) ;

649

651

}653

Listing A.2: Quellcode des Sendeknotens Knotens der mittels Interrupts dieSendeintervalle erzeugt. Transmitter.cpp

// Do not remove the include below2 #include "Transmitter.h"

A.1. Quellcode 125

//#include "TimerOne.h"4 #include "Wire.h"

6

v o l a t i l e bool f l a g S i g n a l = f a l s e ;8 i n t po inter = 0 ;

v o l a t i l e unsigned i n t t e s t =0;10 v o l a t i l e unsigned i n t b u f f e r P o i n t e r =0;

v o l a t i l e unsigned i n t b u f f e r S t a r t P o s =0;12 v o l a t i l e unsigned i n t b u f f e r S i g n a l s [ 1 0 0 ] ;

14 //Message f o r eva luat ion purposesbool msg [ ] = { true , true , true , f a l s e , true , f a l s e , true , f a l s e , true , f a l s e ,

true ,16 true , true , f a l s e , true , true , true , f a l s e , true , true , true , f a l s e ,

true , true , true , f a l s e , true , true , true ,f a l s e , true , f a l s e , true , f a l s e , true , f a l s e , true , f a l s e , true , f a l s e

, true , true , true , true , true , true , t rue } ;18

20 const i n t ULTRA_TRANS_ADDRESS = 1 1 2 ;const i n t ULTRA_RECEIV_ADDRESS = 1 1 3 ;

22 i n t reading =0;i n t contro l le rReadout =−1;

24 i n t counter =0;const unsigned long WAITING_TIME= 1 6 ; //32 //65

26

28 void send_bi t_0 ( ) {

30 }

32 void send_bi t_1 ( ) {

34 /** Send 8 Impulses

36 */

38

Wire . beginTransmission ( 1 1 2 ) ;40 Wire . wri te ( byte (0 x00 ) ) ; // R e g i s t e r 0 −> c o n t r o l r e g i s t e r

Wire . wri te ( byte (0 x5C ) ) ; // Erzeugt einen 8 zykl i schen 40khzImpuls/Ton

42 Wire . endTransmission ( ) ;

44

46 }

48 //Inter rupt−Variantvoid doIT ( void ) {

50 f l a g S i g n a l =true ;

126 A. Anhang

S e r i a l . p r i n t l n ( "MUH" ) ;52

}54

56

58

60 // I n i t i a l i s a t i o nvoid setup ( ) {

62 S e r i a l . begin ( 1 9 2 0 0 ) ;Wire . begin ( ) ;

64 noInter rupts ( ) ; // d i s a b l e a l l i n t e r r u p t sTIMSK1=0x01 ; // enabled globa l and timer overflow i n t e r r u p t ;

66 TCCR1A = 0x00 ; // normal operat ion page 148 ( mode0 ) ;TCNT1=64286; // 16 b i t counter r e g i s t e r

68 TCCR1B = 0x03 ; // s t a r t t imer/ s e t c locki n t e r r u p t s ( ) ; // enable a l l i n t e r r u p t s

70

}72

//The i n t e r r u p t s e r v i c e rout ine t h a t s e t s a f lag , a f t e r Timer1−Overflow

74 ISR ( TIMER1_OVF_vect ) {TCNT1 = 64286 ; // preload timer

76 // S e r i a l . p r i n t l n ( "MUH" ) ;f l a g S i g n a l =true ;

78 }

80 //The main loopthat s t a r t s an i n f i n i t y−while lopp , t h a t i s brokena f t e r the i n t e r r u p t t r i g g e r s a f l a g

void loop ( ) {82 //delayMicroseconds ( 1 0 0 0 0 ) ;

// S e r i a l . p r i n t l n ( " ? " ) ;84 // S e r i a l . p r i n t l n ( po inter ) ;

while ( not f l a g S i g n a l ) {86 //delayMicroseconds ( 1 0 0 0 0 ) ;

}88

//sends a hig−b i t90 i f (msg[ pointer ] ) {

send_bi t_1 ( ) ;92 }

//sends a low−b i t94 e l s e {

send_bi t_0 ( ) ;96 }

//noInter rupts ( ) ;98 f l a g S i g n a l = f a l s e ;

// i n t e r r u p t s ( ) ;100

A.1. Quellcode 127

i f ( pointer >=46) {102 pointer =1;

// noInter rupts ( ) ;104 // TIMSK1=0x00 ; // stop timer c lock

// delay ( 5 0 0 0 ) ;106 // TIMSK1=0x01 ;

// TCNT1=64536; // 16 b i t counter r e g i s t e r108 // TCCR1B = 0x04 ; // s t a r t t imer/ s e t c lock

// i n t e r r u p t s ( ) ;110

112 }e l s e {

114 pointer=pointer +1;}

116

118

120

122

// old Variant of the Package with par i ty−b i t s , MSG−TYPE , MAC−FROM,MAC−TO, DATA

124

126

// //HEADER_START128 // send_bi t_1 ( ) ;

// delay (WAITING_TIME) ;130 //

// //MSG_TYPE 2132 // send_bi t_0 ( ) ;

// delay (WAITING_TIME) ;134 // send_bi t_1 ( ) ;

// delay (WAITING_TIME) ;136 //

// send_bi t_0 ( ) ;138 // delay (WAITING_TIME) ;

// send_bi t_1 ( ) ;140 // delay (WAITING_TIME) ;

//142 // send_bi t_1 ( ) ;

// delay (WAITING_TIME) ;144 // send_bi t_1 ( ) ;

// delay (WAITING_TIME) ;146 //

// send_bi t_0 ( ) ;148 // delay (WAITING_TIME) ;

// send_bi t_1 ( ) ;150 // delay (WAITING_TIME) ;

//

128 A. Anhang

152 // //Par i ty_BIT// send_bi t_0 ( ) ;

154 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

156 // delay (WAITING_TIME) ;//

158 ////

160 //// //MAC_FROM

162 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

164 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

166 //// send_bi t_0 ( ) ;

168 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

170 // delay (WAITING_TIME) ;//

172 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

174 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

176 //// send_bi t_0 ( ) ;

178 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

180 // delay (WAITING_TIME) ;//

182 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

184 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

186 //// send_bi t_0 ( ) ;

188 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

190 // delay (WAITING_TIME) ;//

192 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

194 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

196 //// send_bi t_1 ( ) ;

198 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

200 // delay (WAITING_TIME) ;//

202 // //Par i ty_BIT// send_bi t_0 ( ) ;

A.1. Quellcode 129

204 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

206 // delay (WAITING_TIME) ;//

208 //// //MAC_TO

210 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

212 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

214 //// send_bi t_0 ( ) ;

216 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

218 // delay (WAITING_TIME) ;//

220 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

222 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

224 //// send_bi t_0 ( ) ;

226 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

228 // delay (WAITING_TIME) ;//

230 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

232 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

234 //// send_bi t_0 ( ) ;

236 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

238 // delay (WAITING_TIME) ;//

240 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

242 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

244 //// send_bi t_0 ( ) ;

246 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

248 // delay (WAITING_TIME) ;//

250 // //Par i ty_BIT// send_bi t_0 ( ) ;

252 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

254 // delay (WAITING_TIME) ;//

130 A. Anhang

256 //// //DATA_SIZE 2 bytes

258 //// send_bi t_0 ( ) ;

260 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

262 // delay (WAITING_TIME) ;//

264 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

266 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

268 //// send_bi t_0 ( ) ;

270 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

272 // delay (WAITING_TIME) ;//

274 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

276 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

278 //// send_bi t_0 ( ) ;

280 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

282 // delay (WAITING_TIME) ;//

284 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

286 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

288 //// send_bi t_1 ( ) ;

290 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

292 // delay (WAITING_TIME) ;//

294 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

296 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

298 //// //Par i ty_BIT

300 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

302 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

304 ////

306 ////

A.1. Quellcode 131

308 // //DATA 1 s t byte// send_bi t_1 ( ) ;

310 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

312 // delay (WAITING_TIME) ;//

314 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

316 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

318 //// send_bi t_1 ( ) ;

320 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

322 // delay (WAITING_TIME) ;//

324 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

326 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

328 //// send_bi t_1 ( ) ;

330 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

332 // delay (WAITING_TIME) ;//

334 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

336 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

338 //// send_bi t_1 ( ) ;

340 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

342 // delay (WAITING_TIME) ;//

344 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

346 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

348 //// //Par i ty_BIT

350 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

352 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

354 ////

356 // //DATA 2nd byte// send_bi t_0 ( ) ;

358 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

132 A. Anhang

360 // delay (WAITING_TIME) ;//

362 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

364 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

366 //// send_bi t_0 ( ) ;

368 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

370 // delay (WAITING_TIME) ;//

372 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

374 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

376 //// send_bi t_1 ( ) ;

378 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

380 // delay (WAITING_TIME) ;//

382 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

384 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

386 //// send_bi t_0 ( ) ;

388 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

390 // delay (WAITING_TIME) ;//

392 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

394 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

396 //// //Par i ty_BIT

398 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

400 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

402 //// delay ( 1 0 0 0 0 ) ;

404 ////

406 //// //HEADER_START

408 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

410 //// //MSG_TYPE 2

A.1. Quellcode 133

412 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

414 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

416 //// send_bi t_0 ( ) ;

418 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

420 // delay (WAITING_TIME) ;//

422 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

424 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

426 //// send_bi t_0 ( ) ;

428 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

430 // delay (WAITING_TIME) ;//

432 // //Par i ty_BIT// send_bi t_0 ( ) ;

434 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

436 // delay (WAITING_TIME) ;//

438 ////

440 //// //MAC_FROM

442 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

444 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

446 //// send_bi t_0 ( ) ;

448 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

450 // delay (WAITING_TIME) ;//

452 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

454 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

456 //// send_bi t_0 ( ) ;

458 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

460 // delay (WAITING_TIME) ;//

462 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

134 A. Anhang

464 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

466 //// send_bi t_0 ( ) ;

468 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

470 // delay (WAITING_TIME) ;//

472 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

474 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

476 //// send_bi t_1 ( ) ;

478 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

480 // delay (WAITING_TIME) ;//

482 // //Par i ty_BIT// send_bi t_1 ( ) ;

484 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

486 // delay (WAITING_TIME) ;//

488 //// //MAC_TO

490 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

492 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

494 //// send_bi t_0 ( ) ;

496 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

498 // delay (WAITING_TIME) ;//

500 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

502 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

504 //// send_bi t_0 ( ) ;

506 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

508 // delay (WAITING_TIME) ;//

510 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

512 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

514 //// send_bi t_0 ( ) ;

A.1. Quellcode 135

516 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

518 // delay (WAITING_TIME) ;//

520 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

522 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

524 //// send_bi t_0 ( ) ;

526 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

528 // delay (WAITING_TIME) ;//

530 // //Par i ty_BIT// send_bi t_0 ( ) ;

532 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

534 // delay (WAITING_TIME) ;//

536 //// //DATA_SIZE 2 bytes

538 //// send_bi t_0 ( ) ;

540 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

542 // delay (WAITING_TIME) ;//

544 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

546 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

548 //// send_bi t_0 ( ) ;

550 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

552 // delay (WAITING_TIME) ;//

554 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

556 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

558 //// send_bi t_0 ( ) ;

560 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

562 // delay (WAITING_TIME) ;//

564 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

566 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

136 A. Anhang

568 //// send_bi t_0 ( ) ;

570 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

572 // delay (WAITING_TIME) ;//

574 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

576 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

578 //// //Par i ty_BIT

580 // send_bi t_0 ( ) ;// delay (WAITING_TIME) ;

582 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

584 ////

586 ////

588 // //DATA 1 s t byte// send_bi t_0 ( ) ;

590 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

592 // delay (WAITING_TIME) ;//

594 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

596 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

598 //// send_bi t_0 ( ) ;

600 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

602 // delay (WAITING_TIME) ;//

604 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

606 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

608 //// send_bi t_0 ( ) ;

610 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

612 // delay (WAITING_TIME) ;//

614 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

616 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

618 //// send_bi t_0 ( ) ;

A.1. Quellcode 137

620 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

622 // delay (WAITING_TIME) ;//

624 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

626 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

628 //// //Par i ty_BIT

630 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

632 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

634 ////

636 // //DATA 2nd byte// send_bi t_1 ( ) ;

638 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

640 // delay (WAITING_TIME) ;//

642 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

644 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

646 //// send_bi t_1 ( ) ;

648 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

650 // delay (WAITING_TIME) ;//

652 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

654 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

656 //// send_bi t_1 ( ) ;

658 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

660 // delay (WAITING_TIME) ;//

662 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

664 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

666 //// send_bi t_1 ( ) ;

668 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

670 // delay (WAITING_TIME) ;//

138 A. Anhang

672 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

674 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

676 //// //Par i ty_BIT

678 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

680 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

682 ////

684 // //DATA 1 s t byte// send_bi t_0 ( ) ;

686 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

688 // delay (WAITING_TIME) ;//

690 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

692 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

694 //// send_bi t_0 ( ) ;

696 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

698 // delay (WAITING_TIME) ;//

700 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

702 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

704 //// send_bi t_0 ( ) ;

706 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

708 // delay (WAITING_TIME) ;//

710 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

712 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

714 //// send_bi t_0 ( ) ;

716 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

718 // delay (WAITING_TIME) ;//

720 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

722 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

A.1. Quellcode 139

724 //// //Par i ty_BIT

726 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

728 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

730 ////

732 // //DATA 2nd byte// send_bi t_1 ( ) ;

734 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

736 // delay (WAITING_TIME) ;//

738 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

740 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

742 //// send_bi t_1 ( ) ;

744 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

746 // delay (WAITING_TIME) ;//

748 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

750 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

752 //// send_bi t_1 ( ) ;

754 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

756 // delay (WAITING_TIME) ;//

758 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

760 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

762 //// send_bi t_1 ( ) ;

764 // delay (WAITING_TIME) ;// send_bi t_1 ( ) ;

766 // delay (WAITING_TIME) ;//

768 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

770 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

772 //// //Par i ty_BIT

774 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

140 A. Anhang

776 // send_bi t_1 ( ) ;// delay (WAITING_TIME) ;

778 //// delay ( 1 0 0 0 0 ) ;

780 //

782 }

784

Listing A.3: Quellcode des Empfaenger Knotens der mittels Interrupts die Ab-tastintervalle erzeugt. Transmitter.h

1 // Only modify t h i s f i l e to inc lude// − func t ion d e f i n i t i o n s ( prototypes )

3 // − inc lude f i l e s// − extern v a r i a b l e d e f i n i t i o n s

5 // In the appropriate s e c t i o n

7 #ifndef AcousticSwarm_H_#define AcousticSwarm_H_

9 #include "Arduino.h"#include <avr/io.h>

11 #include <avr/interrupt.h>//add your inc ludes f o r the p r o j e c t AcousticSwarm here

13

15 //end of add your inc ludes here#ifdef __cplusplus

17 extern "C" {#endif

19 void loop ( ) ;void setup ( ) ;

21 #ifdef __cplusplus} // extern "C"

23 #endif

25 //add your funct ion d e f i n i t i o n s f o r the p r o j e c t AcousticSwarm here

27

29

//Do not add code below t h i s l i n e31 #endif /* AcousticSwarm_H_ */

Listing A.4: Quellcode des Empfaenger Knotens der mittels Interrupts die Ab-tastintervalle erzeugt. Receiver.h

1 // Only modify t h i s f i l e to inc lude// − func t ion d e f i n i t i o n s ( prototypes )

3 // − inc lude f i l e s// − extern v a r i a b l e d e f i n i t i o n s

5 // In the appropriate s e c t i o n

A.1. Quellcode 141

7 #ifndef AcousticSwarm_H_#define AcousticSwarm_H_

9 #include "Arduino.h"#include <avr/io.h>

11 #include <avr/interrupt.h>

13 //add your inc ludes f o r the p r o j e c t AcousticSwarm here

15

//end of add your inc ludes here17 #ifdef __cplusplus

extern "C" {19 #endif

void loop ( ) ;21 void setup ( ) ;#ifdef __cplusplus

23 } // extern "C"#endif

25

//add your funct ion d e f i n i t i o n s f o r the p r o j e c t AcousticSwarm here27

29

31 //Do not add code below t h i s l i n e#endif /* AcousticSwarm_H_ */

Literaturverzeichnis

[Air13] Air Ultrasonic Ceramic Transducers 400ST/R160, 2013.

[Ardu13] Arduino. SRFxx Sonic Range Finder Reader. http://arduino.cc/en/Tutorial/SFRRangerReader, 2013.

[BaKr13] S. F. Barrett und J. Kridner. Bad to the Bone: Crafting ElectronicSystems with BeagleBone and BeagleBone Black. Synthesis Lectureson Digital Circuits and Systems 8(2), 2013, S. 1–430.

[Banz09] M. Banzi. Getting Started with arduino. O’Reilly Media, Inc. 2009.

[Banz13] M. Banzi. Send in the clones. http://blog.arduino.cc/2013/07/10/send-in-the-clones/, 2013.

[BuDH13] P. Buxmann, H. Diefenbach und T. Hess. The Software Industry:Economic Principles, Strategies, Perspectives. Springer. 2013.

[chac13] cooking hacks.com. Raspberry Pi to Arduino shields connec-tion bridge. http://www.cooking-hacks.com/skin/frontend/default/cooking/images/catalog/documentation/raspberry_table/raspberry_xbee_small.png, 2013.

[ChSS08] M. Chitre, S. Shahabudeen und M. Stojanovic. Underwater acou-stic communications and networking: Recent advances and futurechallenges. Marine technology society journal 42(1), 2008, S. 103–116.

[Corp13] P. W. E. Corp. APPLICATION NOTE AP050830. 2013, S. 1–8.

[EcGD11] J. Eckert, R. German und F. Dressler. An indoor localization frame-work for four-rotor flying robots using low-power sensor nodes.Instrumentation and Measurement, IEEE Transactions on 60(2), 2011,S. 336–344.

[FaCL05] R. Fan, I. Chakraborty und N. Lynch. Clock synchronization forwireless networks. In Principles of Distributed Systems, S. 400–414.Springer, 2005.

[FGSP+05] L. Freitag, M. Grund, S. Singh, J. Partan, P. Koski und K. Ball. TheWHOI micro-modem: an acoustic communications and navigati-on system for multiple platforms. In OCEANS, 2005. Proceedingsof MTS/IEEE. IEEE, 2005, S. 1086–1092.

144 Literaturverzeichnis

[Frie08] H. J. Friedrich. Tontechnik für Mediengestalter: Töne hören-Technikverstehen-Medien gestalten. Springer-Verlag. 2008.

[Gass12] O. Gassmann. Crowdsourcing, S. 12–13. Hanser Verlag. 2012.

[GLRL95] M. Garstang, D. Larom, R. Raspet und M. Lindeque. Atmosphe-ric controls on elephant communication. Journal of ExperimentalBiology 198(4), 1995, S. 939–951.

[HaHo06] M. Hazas und A. Hopper. Broadband ultrasonic location systemsfor improved indoor positioning. Mobile Computing, IEEE Transac-tions on 5(5), 2006, S. 536–547.

[HHRH05] S. Holm, O. B. Hovind, S. Rostad und R. Holm. Indoors data com-munications using airborne ultrasound. In Acoustics, Speech, andSignal Processing, 2005. Proceedings.(ICASSP’05). IEEE InternationalConference on, Band 3. IEEE, 2005, S. iii–957.

[http13a] http://circuitco.com/. BeagleBone Capes. http://circuitco.com/support/index.php?title=BeagleBone_Capes, 2013.

[http13b] http://circuitco.com/. BeagleBoneBlack. http://circuitco.com/support/index.php?title=BeagleBoneBlack, 2013.

[Inst13] T. Instruments. Programmable Realtime Unit SubSystem.http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem, 2013.

[KBSO08] M. Kluge, T. Becker, J. Schalk und T. Otterpohl. Remote acousticpowering and data transmission for sensors inside of conductiveenvelopes. In Sensors, 2008 IEEE. IEEE, 2008, S. 41–44.

[KrQu79] M. L. Kreithen und D. B. Quine. Infrasound detection by the ho-ming pigeon: A behavioral audiogram. Journal of Comparative Phy-siology 129(1), 1979, S. 1–4.

[KuPa10] S. Kuznetsov und E. Paulos. Rise of the expert amateur: DIYprojects, communities, and cultures. In Proceedings of the 6th Nor-dic Conference on Human-Computer Interaction: Extending Boundaries.ACM, 2010, S. 295–304.

[LeSW09] R. Lerch, G. Sessler und D. Wolf. Technische Akustik. 2009.

[Ltd13] D. Ltd. Ultrasonic Rangers FAQ. http://www.robot-electronics.co.uk/htm/sonar_faq.htm, 2013.

[LZPC10] J. Liu, Z. Zhou, Z. Peng und J.-H. Cui. Mobi-Sync: efficient timesynchronization for mobile underwater sensor networks. In Glo-bal Telecommunications Conference (GLOBECOM 2010), 2010 IEEE.IEEE, 2010, S. 1–5.

Literaturverzeichnis 145

[MaHa] J. Maye und E. Hagmann. Design of a High Speed, Short RangeUnderwater Communication System.

[MIT13] MIT. Physics III: Vibrations and Wa-ves. http://ocw.mit.edu/courses/physics/8-03-physics-iii-vibrations-and-waves-fall-2004/index.htm#,2013.

[MoSt06] M. Molins und M. Stojanovic. Slotted FAMA: a MAC protocol forunderwater acoustic networks. OCEANS 2006 - Asia Pacific, Mai2006, S. 1–7.

[MoSt07] M. Molins und M. Stojanovic. Slotted FAMA: a MAC protocolfor underwater acoustic networks. In OCEANS 2006-Asia Pacific.IEEE, 2007, S. 1–7.

[NaAn07] H. Nam und S. An. An ultrasonic sensor based low-power acou-stic modem for underwater communication in underwater wire-less sensor networks. In Emerging Directions in Embedded and Ubi-quitous Computing, S. 494–504. Springer, 2007.

[Olym06] N. Olympus. Ultrasonic transducers technical notes. Technicalbrochure: Olympus NDT, Waltham, MA, 2006.

[Plat07] J. Plate. Linux Hardware Hackz: Messen, Steuern und Sensorik mitLinux. Hanser Verlag. 2007.

[PrSo01] J. Proakis und E. Sozer. Shallow water acoustic networks. Com-munications . . . , 2001.

[PSRS01] J. G. Proakis, E. M. Sozer, J. A. Rice und M. Stojanovic. Shallowwater acoustic networks. Communications Magazine, IEEE 39(11),2001, S. 114–119.

[QuMD11] J. Quintas, P. Menezes und J. Dias. Cloud Robotics: Towards Con-text Aware Robotic Networks. In Proc. of the 16th IASTED Interna-tional Conference on Robotics, Pittsburgh, USA, 2011.

[RiWa12] M. Richardson und S. Wallace. Getting Started with Raspberry Pi.Make. 2012.

[Robo13a] A. Robotics. Comparing the Sensors. http://www.acroname.com/robotics/info/articles/devantech/srf.html, 2013.

[robo13b] robotikhardware.de. SRF02 Datenblatt, 2013.

[robo13c] robotikhardware.de. SRF02 Datenblatt (Deutsch/Englisch). 2013,S. 1–28.

[RSPS02] V. Raghunathan, C. Schurgers, S. Park und M. B. Srivastava.Energy-aware wireless microsensor networks. Signal ProcessingMagazine, IEEE 19(2), 2002, S. 40–50.

146 Literaturverzeichnis

[SBYS11] A. Sanchez, S. Blanc, P. Yuste und J. Serrano. A low cost andhigh efficient acoustic modem for underwater sensor networks.In OCEANS, 2011 IEEE-Spain. IEEE, 2011, S. 1–10.

[Seal00] D. Seal. ARM architecture reference manual. Pearson Education.2000.

[SLMR05] J. A. Stankovic, I. Lee, A. Mok und R. Rajkumar. Opportunitiesand obligations for physical computing systems. Computer 38(11),2005, S. 23–31.

[SoSP00a] E. Sozer, M. Stojanovic und J. Proakis. Underwater acoustic net-works. IEEE Journal of Oceanic Engineering 25(1), Januar 2000, S. 72–83.

[SoSP00b] E. M. Sozer, M. Stojanovic und J. G. Proakis. Underwater acousticnetworks. Oceanic Engineering, IEEE Journal of 25(1), 2000, S. 72–83.

[Stoj95] M. Stojanovic. Underwater acoustic communications. In Electro/95International. Professional Program Proceedings. IEEE, 1995, S. 435–440.

[Stoj96] M. Stojanovic. Recent advances in high-speed underwater acousticcommunications. Oceanic Engineering, IEEE Journal of 21(2), 1996,S. 125–136.

[StPr09] M. Stojanovic und J. Preisig. Underwater acoustic communicati-on channels: Propagation models and statistical characterization.Communications Magazine, IEEE 47(1), 2009, S. 84–89.

[VaDR07] I. Vasilescu, C. Detweiler und D. Rus. AquaNodes: an underwatersensor network. In Proceedings of the second workshop on Underwaternetworks. ACM, 2007, S. 85–88.

[WaAM11] J.-D. Warren, J. Adams und H. Molle. Arduino for Robotics. Sprin-ger. 2011.

[WiHW11] H. Winner, S. Hakuli und G. Wolf. Handbuch Fahrerassistenzsyste-me: Grundlagen, Komponenten und Systeme für aktive Sicherheit undKomfort. Springer DE. 2011.

[Wiki13a] Wikipedia. Arduino-Plattform. http://de.wikipedia.org/wiki/Arduino-Plattform, 2013.

[Wiki13b] Wikipedia. AtmelAVR. http://de.wikipedia.org/wiki/AtmelAVR, 2013.

[Wiki13c] Wikipedia. Mikroprozessor. http://de.wikipedia.org/wiki/Mikroprozessor, 2013.

Literaturverzeichnis 147

[Wiki13d] Wikipedia. Nahfeld und Fernfeld (elektromagnetische Wel-len). http://de.wikipedia.org/wiki/Nahfeld_und_Fernfeld_(elektromagnetische_Wellen), 2013.

[Wiki13e] Wikipedia. Raspberry Pi. http://de.wikipedia.org/wiki/Raspberry_Pi, 2013.

[Wiki13f] Wikipedia. Raspberry Pi. http://en.wikipedia.org/wiki/Raspberry_Pi, 2013.

[Wiki13g] Wikipedia. Ultrasound. http://en.wikipedia.org/wiki/Ultrasound, 2013.

[WiYH06] J. Wills, W. Ye und J. Heidemann. Low-power acoustic modem fordense underwater sensor networks. In Proceedings of the 1st ACMinternational workshop on Underwater networks. ACM, 2006, S. 79–85.