Jugend forscht 2002

Mobiler Internetzugang für
grafikfähige Taschenrechner

Schriftliche Arbeit für Jugend forscht 2002
von Burkart Lingner, Alexander Mann und Marc Schappeit

Ziel unseres Projektes ist es, die Datenübertragung zwischen einem PC und einem oder mehreren graphikfähigen Taschenrechnern in einem Netzverbund herzustellen. Die reine Datenübertragung ist dabei die Grundlage für eine Vielzahl weitergehender Möglichkeiten: Der PC fungiert in dem Netzwerk als Datenserver mit Internetanbindung. Dadurch wird es den Benutzern der Taschenrechner möglich, mobil auf das Internet zuzugreifen, womit ihnen alle Möglichkeiten des World Wide Web zur Verfügung stehen: Sie können mit den Taschenrechnern SMS an Handys in aller Welt und E-Mails versenden, ihre E-Mail-Konten abrufen, mit anderen Menschen aus aller Welt chatten oder einfache Recherchen in dem immer größer werdenden Angebot von WAP-Seiten betreiben. Auch im täglichen Schulalltag bietet die Vernetzung der Taschenrechner viele Anwendungsmöglichkeiten.

1. Einleitung
2. Die Hardware
1. Übersicht
2. Der TI-8x
3. Der Linkport des TI-8x
4. Der Microcontroller AT89C52
5. Das Herzstück der Funkübertragung: Der nRF401
6. Die serielle Schnittstelle des PC
7. Der Dolmetscher: Das Interface
8. Die TI-Net V2.0 Platine
3. Die Software
1. Low-Level-Protokoll
2. Intermediate-Level-Protokoll
3. High-Level-Protokoll
4. Kommunikation von TI und Microcontroller
4. Ausblick
5. Anhang
1. Quellen
2. Auszug aus dem Datenblatt des nRF401
3. Auszug aus dem Datenblatt des AT89C51
4. Schaltplan
5. Platinenlayout
6. Danksagung

An unserer Schule, dem Felix-Klein-Gymnasium, wird seit einiger Zeit von der 9. Klasse an im Unterricht ein grafikfähiger Taschenrechner eingesetzt, so dass gut die Hälfte der Schülerschaft einen solchen besitzt, größtenteils den "TI82"¹⁾. Dieser gut 50 Euro teure Taschenrechner kann nicht nur rechnen und Graphen zeichnen, sondern auch noch Einiges mehr, was die Schüler auch bald herausfanden. So ist zum Beispiel das Chatten per Taschenrechner in einer 11. Klasse an unserer Schule inzwischen sehr beliebt. Leider funktioniert dies bisher aber nur per Kabelverbindung zwischen den Rechnern, so dass die Reichweite auf (höchstens) wenige Meter beschränkt bleibt. Wir haben uns gedacht, dies muss nicht so sein, und uns daran gemacht, die Fähigkeiten des Taschenrechners ein wenig zu erweitern, einerseits durch die Möglichkeit der Übertragung der Daten per Funk, andererseits durch die Anbindung des Taschenrechners (über Funk und einen PC) ans Internet.

Die Anbindung des Taschenrechners ans Internet bietet viele verschiedene Anwendungs- und Kommunikationsmöglichkeiten: Man kann E-Mails versenden und empfangen. Über besondere Internetdienste ist es sogar möglich, Textnachrichten an Handys zu verschicken. Man kann sich mit Leuten in aller Welt per Chat unterhalten, Nachrichten aus Newsgroups lesen oder sich auf vielfältige Weise informieren und kleine Recherchen betreiben. Das Internet bietet hierbei so viele Möglichkeiten, dass es uns in unserem Projekt nicht möglich ist, alles Mögliche umzusetzen. Außerdem setzen natürlich auch die Fähigkeiten des Taschenrechners den Nutzungsmöglichkeiten des Internets Grenzen. Durch die Verwendung der Taschenrechner in der Schule ergibt sich ein weiteres Anwendungsgebiet: Schulbezogene Daten wie z.B. die täglichen Hausaufgaben, Unterrichtsmaterialien, Klausurentermine, schulinterne Termine und Bekanntmachungen oder der Vertretungsplan können unkompliziert den Schülern zur Verfügung gestellt werden.

Weitere Ausblicke und Anregungen, was noch alles mit dem "Taschenrechner als Surfbrett" möglich wäre, werden u.a. im Kapitel 4: Ausblick gegeben.

Die Arbeiten an unserem Projekt unterteilen sich grundsätzlich in zwei Bereiche, weshalb wir auch die folgenden schriftlichen Ausführungen in diese beiden Bereiche untergliedert haben: Die Hardware und die Software. Kapitel 2 befasst sich mit der Hardware, die für die Verbindung der Netzwerkteilnehmer per Funk erforderlich ist, Kapitel 3 mit der Software für PC und Taschenrechner bzw. Microcontroller. Zur Realisierung der Funkübertragung greifen wir auf den Transceiver-Chip nRF401 zurück, welcher auch im Kapitel 2 noch einmal ausführlich beschrieben wird. Besonders wichtig war es uns in unseren Überlegungen, dass nicht nur ein sondern mehrere Taschenrechner gleichzeitig mit dem als Server fungierenden PC kommunizieren können, was wiederum spezielle Anforderungen an die Protokoll-Software stellt, aber Voraussetzung für eine sinnvolle Umsetzung des Projektes ist.

¹⁾ Eine genauere Beschreibung des Taschenrechners folgt im Kapitel 2: Die Hardware.

So stellt sich unser Projekt schematisch dar: Mehrere Taschenrechner mit ihren jeweiligen Microcontrollern, die per Funkverbindung mit einem PC verbunden sind. Der PC ist dabei über ein Interface mit dem nRF401 verbunden, bei den Taschenrechnern ist die Hardware etwas aufwändiger. Hier steuert ein Microcontroller die Datenübertragung per Funk, speichert die zu sendenden und empfangenen Daten in einem eigenen Speicher und gibt sie unabhängig von dem zeitkritischen Sendeprotokoll der Funkverbindung an den Taschenrechner weiter.

Da der Taschenrechner und seine Möglichkeiten für unser Projekt eine große Rolle spielen, sollen hier kurz seine wichtigsten Eigenschaften erläutert werden. Es handelt sich bei den Taschenrechnern, die wir verwenden, um den TI-82 und TI-83 der Firma Texas Instruments, die in wesentlichen Punkten gleich sind und sich nur im firmwarebedingten Funktionsumfang unterscheiden (was sich durch die unterschiedliche Größe des ROM ausdrückt: beim TI-82 128 kB, beim TI-83 256 kB). Sie verfügen über ein 96*64 Pixel großes schwarz/weiß LC-Display, Graustufen sind durch die Software in beschränktem Umfang emulierbar. Der Prozessor ist ein mit 6 MHz getakteter 8-Bit-Mikroprozessor (ein Z80). Als Programmiersprache wird ein Basic-Dialekt ("TI-Basic") mitgeliefert. Der TI-83 unterstützt zusätzlich auch Assemblerprogramme, beim TI-82 ist dies nur über eine sogenannte "Shell" möglich. Wir verwenden die Shell "CrASH". Programmieren müssen wir in Assembler, da Basic viel zu langsam wäre, gerade wenn es um zeitkritische Programmieraufgaben geht wie z.B. die Einhaltung von Protokollen. Sowohl der TI-82 als auch der TI-83 verfügen über 32 kB RAM, von dem ungefähr 27 kB frei verfügbar sind. Außerdem sind sie mit einem Link-Port ausgerüstet, der im nächsten Abschnitt genauer erklärt wird.

Die Taschenrechner TI-82 und TI-83 verfügen über einen Linkport, der es erlaubt, mittels eines speziellen Kabels Daten zwischen dem Taschenrechner und einem PC (oder zwischen zwei Taschenrechnern) auszutauschen, dies können z.B. Funktionen, Grafiken oder Programme sein. Hardwareseitig weist der Linkport zwei Datenleitungen mit einer gemeinsamen Masseleitung auf. Die Datenleitungen können entweder auf 5 oder 0 Volt gelegt werden. Es handelt sich um bidirektionale Leitungen: Legt einer der Kommunikationspartner die Leitung auf 0V, so wird an beiden Enden 0V ausgelesen. 5V werden nur ausgelesen, wenn beide Partner ihren Ausgang auf 5V legen. Die beiden Leitungen sind jeweils bitweise anzusteuern. Im ROM liegen zwar Routinen zum byte-weisen Versenden von Daten mit dem Protokoll von Texas Instruments, für unser Projekt ist dies jedoch nicht praktikabel, so dass wir auf die Programmierung eigener Routinen angewiesen sind, mit deren Hilfe der Taschenrechner und der Microcontroller Daten austauschen.

Zu Anfang unseres Projektes haben wir sämtliche Programme auf dem Taschenrechner laufen lassen, es stellte sich jedoch heraus, dass dieser mit der Emulation einer seriellen Schnittstelle sowie der Unterstützung der verschiedenen Protokollebenen (siehe Kapitel 3) sehr stark ausgelastet wurde. Um dem Nutzer des Taschenrechners ein komfortables Arbeiten zu gewährleisten, entschieden wir uns daher dafür, zwischen die Funkstrecke, also den nRF401, und den Taschenrechner noch einen Microcontroller zu schalten, der sich um die genannten Aufgaben kümmert und nur noch ausgewählte Daten an den Taschenrechner sendet, der sich dadurch voll auf die Ein- und Ausgabe von Benutzerdaten konzentrieren kann. Der Microcontroller sollte von Haus aus das Protokoll der seriellen Schnittstelle unterstützen, neben ausreichend Codespeicher möglichst mehr als 1 kB Datenspeicher haben und natürlich zu einem möglichst geringen Preis erhältlich sein. Unsere Wahl fiel schließlich auf den AT89C52 von Atmel, der alle genannten Vorteile auf sich vereint, abgesehen davon, dass er leider nur über 128 Byte Datenspeicher verfügt. Da dieser Microcontroller aber zum Intel 8051 kompatibel ist, bietet er die Möglichkeit, externes SRAM über einen gemultiplexten Adress-/Datenbus anzusprechen. Hierzu wird noch ein Latch-IC benötigt, ansonsten sind als äußere Beschaltung lediglich ein Quarz mit zwei Kondensatoren sowie ein Widerstand und ein Kondensator zwecks Auto Power-On Reset vonnöten. Hierdurch verfügen wir nun über 8 kB Codespeicher, 32 kB externes SRAM, eine serielle Schnittstelle sowie 12 weitere freie I/O-Pins für die Kommunikation mit dem nRF401 (wie z.B. das Umschalten zwischen Senden und Empfangen) und dem Taschenrechner sowie eventuelle zukünftige Erweiterungen. Der AT89C52 ist in den Gehäuseformen DIP-40 und PLCC-44 erhältlich.

Der wichtigste Bestandteil der Hardware in Bezug auf die Funkübertragung ist der IC nRF401 der Firma nordIC. Seine Komplexität macht ihn zum teuersten aber auch zum wertvollsten Element unserer Hardware und erspart uns komplizierte Schaltungen, auch wenn das Löten der SMD-Technik nicht ganz einfach war.

Bei dem nRF401 handelt es sich um einen sogenannten Transceiverchip, das heißt um einen IC, der sowohl empfangen als auch senden kann. Der nRF401 wurde speziell entwickelt, um digitale Daten empfangen und senden zu können, mit der Konsequenz, dass sich die Ansteuerung für uns sehr einfach gestaltet: Wir übergeben dem IC auf der einen Seite der Funkverbindung die Daten in digitaler Form²⁾ und können sie am anderen Ende der Funkstrecke auch wieder digital auslesen und brauchen uns so nicht um die Frequenzmodulation und -demodulation zu kümmern.

Der nRF401 arbeitet im sogenannten ISM-Band (Industrial, Scientific and Medical), wobei er die Möglichkeit bietet, auf zwei verschiedenen Kanälen zu senden bzw. zu empfangen, die bei 433,92 und 434,33 MHz liegen. Das ISM-Band ist ein Frequenzbereich, in dem jeder ohne besondere Genehmigung³⁾ senden darf. Nach Herstellerangaben beträgt die maximale Reichweite des Senders bei voller Leistung (auf freiem Feld) knapp 800 Meter. Aufgrund der simplen "Loop-Antenne" (eine Leiterbahn auf der Platine), die wir verwenden, und unter Berücksichtigung der Tatsache, dass wir in einer Stadt in einem Gebäude senden, liegt unsere maximale Reichweite deutlich darunter.

Die maximale Datenübertragungsrate beträgt 20 kBit/s (mehr als viele ältere Modems schaffen), was 2000 Zeichen pro Sekunde entspricht und für unsere Zwecke vollkommen ausreicht, da der hauptsächliche Teil der Daten, die wir übertragen wollen, Texte sind und keine aufwendigen Multimediainhalte wie z.B. Grafiken oder Musik, welche sich auf dem Taschenrechner gar nicht wiedergeben ließen. (Natürlich müssen sich alle Teilnehmer des Netzwerkes diese Rate teilen, da nicht mehr als ein Sender gleichzeitig senden darf, worauf wir im folgenden noch genauer eingehen werden.)

Der IC hat 20 Anschlüsse, von denen hier die wichtigsten kurz erklärt werden sollen:

Die restlichen 15 Pins dienen der Stromversorgung und dem Anschluss der Antenne und externer Bauteile.

Zu beachten ist, dass der Transceiverchip beim Umschalten vom Sende- in den Empfangsmodus und umgekehrt eine Pause von wenigen Millisekunden braucht, in der weder gesendet noch empfangen werden kann, was natürlich die Übertragungsrate bei häufigem Umschalten empfindlich schmälert. Wir haben deshalb versucht, die Häufigkeit des Umschaltens so gering wie möglich zu halten (siehe Kapitel 3: Software).

²⁾ TTL-Logik wie beim Linkport des TI: eine digitale Null entspricht 0 Volt, eine Eins 5 Volt

³⁾ bei einer maximalen Sendeleistung von 10mW

Die serielle Schnittstelle weist neben einigen Steuerleitungen auch zwei Datenleitungen auf, über die im RS-232 Protokoll Bytes übertragen und empfangen werden. Hierzu wird dem Steuerchip im PC, dem UART, das zu sendende Byte übergeben bzw. wird von ihm ein empfangenes Byte angefordert. Um die Umwandlung in elektrische Signale kümmert sich der Chip. Die Signalpegel liegen bei +3 bis +15 Volt für eine logische 0 und bei -3 bis -15 Volt für eine logische 1. Der UART unterstützt besonders im Bereich der höheren Übertragungsraten nur einige vorgegebene Bitraten. Unterhalb der Grenze von 20 kBit/s, die der nRF401 vorgibt, sind dies die Raten 19,2 kBit/s, 16,5 kBit/s, 14,4 kBit/s und viele kleinere Raten. Ein Beispiel des Übertragungsprotokolls ist unter 3.1. abgebildet.

Da die serielle Schnittstelle und der nRF401 - wie unter 2.5 und 2.6 beschrieben - unterschiedliche Signalpegel zur Darstellung digitaler Daten verwenden, ist es notwendig, diese aneinander anzugleichen. Hierzu verwenden wir einen IC (MAX232), der zwischen den PC und den nRF401 geschaltet ist und über dieselbe Spannungsversorgung wie der nRF401 betrieben werden kann. Auf Seiten des Microcontrollers ist diese Maßnahme nicht notwendig, weil die Signalpegel des Microcontrollers und des Transceiver-Chips kompatibel sind.

Um die von uns verwendeten Komponenten für den alltäglichen Einsatz geeigneter zu gestalten, haben wir die gesamte für die Datenübertragung per Funk erforderliche Hardware auf einer Platine zusammengefasst, die folgende Funktionen bietet:

• Integration aller notwendigen Bauteile (Microcontroller, nRF401, 32kB SRAM, Spannungsversorgung) auf kleinstem Raum (Platinengröße ca. 65 mm mal 72 mm) durch Einsatz von SMD-Technik
• auf der Platine integrierte Loop-Antenne, sowie die Möglichkeit, durch Umschalten eine externe 50Ω-Antenne anzuschließen
• stabilisierte Spannungsversorgung, die ein korrektes Arbeiten der Bauteile auch bei sinkender Akkuspannung gewährleistet
• sechs Status-LEDs, die über verschiedene Zustände des TI_Net V2.0 informieren (wie z.B. der gerade gewählte Kanal)
• in das Gehäuse integrierter Reset- und Ein-/Ausschalter
• wahlweise Akku- oder Netzteilbetrieb
• regelbare Sendeleistung

Während wir die (im herkömmlichen 2,54 mm Rastermaß entworfenen) Programmiergeräte und Testplatinen für die ersten Versuche mit dem Microcontroller noch selbst herstellen konnten, haben wir bei der Weiterentwicklung des Projektes festgestellt, dass die notwendige SMD-Technik mit konventioneller Ätz- und Löttechnik nicht in ausreichender Qualität herzustellen ist, und deshalb den Entwurf des Platinenlayouts und die Produktion der Platinen in Kooperation mit Firmen durchgeführt, die auf die Herstellung von SMD-Platinen spezialisiert sind. Allein das Erstellen des Platinenlayouts hat dabei etwa 25 Arbeitsstunden in Anspruch genommen.

Das größte Problem bei jeder Datenübertragung ist die Synchronisation zwischen Sender und Empfänger. Die einfachste Lösung ist, neben der Datenleitung (bzw. den Datenleitungen) eine weitere Leitung mit einem Taktsignal zu belegen, das nur dazu dient anzuzeigen, wann auf der Datenleitung ein Datenbit anliegt und gelesen werden muss. Da wir unsere Daten per Funk übertragen, steht uns keine weitere Leitung für ein Taktsignal zur Verfügung, sondern wir müssen uns auf insgesamt eine Leitung beschränken. Es ist daher erforderlich, in den Daten, die über die Datenleitung gesendet werden, auch eine Synchronisation unterzubringen, die es dem Empfänger ermöglicht zu erkennen, wann auf der Leitung das nächste Datenbit anliegt.

Hierzu hat die Leitung einen definierten Grundzustand von 5 Volt. Jeder beginnende Datentransfer wird durch ein Startbit (0 Volt) angezeigt, auf das in definiertem Abstand die Datenbits folgen, wobei 5 Volt für eine binäre Eins und 0 Volt für eine Null stehen. Die Übertragung eines Bytes wird durch ein Stoppbit (5 Volt) abgeschlossen, wodurch die Leitung in den Grundzustand geht, und ein folgendes Startbit wieder als Wechsel von 5 nach 0 Volt erkannt werden kann. Dieses Verfahren wird RS-232-Protokoll genannt. Während wir in früheren Ansätzen unseres Projektes das serielle Protokoll noch auf dem TI durch eine selbstgeschriebene Software emuliert haben, ist dies durch die Verwendung des Microcontrollers 89C52 nicht mehr nötig, da dieser über eine serielle Schnittstelle verfügt. Andererseits benötigen wir jetzt für die Datenübertragung zwischen Taschenrechner und Microcontroller ein weiteres Protokoll, das unter 3.4 erläutert wird.

Eine Besonderheit des RS-232-Protokolls ist, dass zuerst das LSB (least significant bit) und das MSB (most significant bit) zuletzt übertragen werden. Ein Byte könnte also zum Beispiel so aussehen:

Ein kleines "c" als Bitfolge mit Start- (S) und Stoppbit (P) bei einer Datenrate von 19,2kBit/s, (Binärdarstellung: 01100011)

Mit Hilfe des Low-Level-Protokolls (dem RS-232-Protokoll) können wir nun also einzelne Bytes übertragen. Der nächste Schritt ist, mehrere Bytes zu einzelnen Datenpaketen zusammenzufügen. Diese Pakete "verpacken" die Daten, d.h. sie enthalten zusätzliche Informationen, die den Datenfluss lenken und eine fehlerfreie Übertragung gewährleisten. Dies ist dadurch erforderlich, dass unsere "Leitung" sich als Funkverbindung mit mehreren Partnern wesentlich von einer Kabeldatenleitung mit zwei Partnern unterscheidet, und zwar in zweierlei Hinsicht:

1.) An unserem Netzwerk aus Taschenrechner und PC nehmen außer dem PC nicht nur ein, sondern bis zu 250 Taschenrechner teil, die aber alle auf einem gemeinsamen Funkkanal senden. Jede Sendung von jedem Teilnehmer wird also von jedem anderen empfangen. Deshalb enthalten die Pakete neben den reinen Daten auch Informationen über den Absender und den Empfänger. Andernfalls wäre nicht klar, wer gerade an wen Daten schickt.

2.) Durch Fremdeinflüsse kann es zu Störungen bei der Datenübertragung kommen, so dass Daten nur unvollständig oder verstümmelt ankommen. Sofern dies nicht bereits durch das Low-Level-Protokoll abgefangen wird, muss hier das Intermediate-Level-Protokoll eingreifen. Dazu enthält jedes Paket eine Prüfsumme. Stimmt die im Paket enthaltene Prüfsumme nicht mit der überein, die der Empfänger aus den empfangenen Daten ermittelt, dann muss die Übertragung fehlerhaft gewesen sein. Der Empfänger sendet dann eine negative Bestätigung (NACK = Not ACKnowledged), um dem Server mitzuteilen, dass dieser das Paket erneut senden soll. Dies tut der Server auch in dem Fall, dass er gar keine Rückmeldung bekommt, solange bis er eine Bestätigung (ACK = ACKnowledged) erhält, dass das Paket korrekt empfangen wurde.

Wie schon im Kapitel "Hardware" erwähnt, handelt es sich bei dem verwendeten Frequenzband um einen Bereich, in dem jeder senden darf, und in dem auch viele alltägliche Geräte (Fernbedienungen, Funkkopfhörer etc.) senden. Es muss also verhindert werden, dass fremde Daten in unserem Netzwerk Unheil stiften. Auch hierzu dient die Prüfsumme, durch die Daten, die nicht den Regeln unseres Netzwerks entsprechen, erkannt und herausgefiltert werden können. Wir verwenden das CRC8-Verfahren, weil es eine Vielzahl verschiedener Fehlertypen erkennt, dadurch recht sicher ist und gleichzeitig aber auch recht unaufwendig ist, was angesichts der Hardware-Möglichkeiten des Microcontroller wichtig ist.

Wir müssen also auf jeden Fall mit Fehlern rechnen, allerdings lässt sich die Fehlertoleranz dadurch erhöhen, dass anstelle weniger langer Pakete viele kurze versandt werden. Die Wahrscheinlichkeit, dass ein Paket einen Fehler erhält, wird dadurch geringer:

Andererseits wird bei kurzen Paketen das Verhältnis von "Verpackung" (Absender, Empfänger, Prüfsumme etc.) und "Inhalt" (Daten) ungünstiger, wodurch die Menge der reinen Daten, die pro Zeiteinheit gesendet werden können wieder abnimmt:

(grau: Übertragungsvolumen, das als "Verpackungsmüll" verloren geht)

Es gilt hier also einen Kompromiss zu finden, durch den das mengenmäßig begrenzte Übertragungsvolumen möglichst effektiv ausgenutzt werden kann.

Wie eben erläutert, können wir Pakete nicht beliebig groß machen. Je kleiner ein Paket ist, desto weniger Daten kann es logischerweise beinhalten. Da etwa für E-Mails auch sehr lange Texte transportiert werden können müssen, ist es notwendig, eine Möglichkeit zu haben, große Datenmengen auf mehrere Pakete zu verteilen. (Wir nennen dieses Verfahren "multi packet".) Es muss dann aber sichergestellt werden, dass der Empfänger sie auch wieder richtig zusammensetzen kann, weshalb jedes Datenpaket eine Nummer erhält. Das erste Paket enthält anstelle seiner Nummer die Anzahl der Pakete, die zu dieser Paketserie gehören, wobei dieser Wert auch eins sein kann, wenn einfach nur ein einzelnes Paket gesendet werden soll. Um das erste Paket als solch erstes Paket auszuzeichnen, verwenden wir Bit 7 der Content-ID. (Die Content-ID gibt ansonsten die Art des Inhaltes eines Paketes an, also ob z.B. ein Text, eine Grafik oder ein Auswahlmenü gesendet wird.) Zum einfacheren Verständnis jetzt erstmal der Paketaufbau im Überblick, danach nochmal eine kurze Erläuterung zum Verfahren des "multi packet".

Der Aufbau eines Datenpaketes ist also:

Wenn also ein Teilnehmer des Netzwerks ein Paket empfängt, guckt er nach, ob Bit 7 der Content-ID (Byte 3) gesetzt ist. Ist dies der Fall, handelt es sich um ein Folgepaket. Das Byte 5 enthält dann die Paketnummer. Andernfalls, falls Bit 7 nicht gesetzt ist, enthält Byte 5 die Anzahl der Pakete, und das gerade empfangene Paket ist das erste Paket einer etwaigen Paketserie.

Da alle Daten von jedem Sender an jeden Empfänger über nur einen Funkkanal laufen, ist Übertragungsvolumen kostbar. Daher muss ein möglichst ununterbrochener Datenfluss gewährleistet sein, und es sollten so wenig überflüssige oder redundante Daten wie möglich übertragen werden. Es besteht aber auch die Gefahr, dass sich zwei Sender gegenseitig übersenden und dadurch gar nichts bei den Empfängern ankommt. Aufbauend auf dem Intermediate-Level-Protokoll müssen wir also ein strenges Regelwerk festlegen, nach welchem Muster die Sender senden dürfen. Des weiteren muss der Server hin und wieder eine sogenannte Anmeldefreigabe senden, an die sich eine kurze Sendepause anschließt, die es neuen Clients⁴⁾, die noch nicht Teilnehmer des Netzwerks sind, ermöglicht, sich am Netzwerk anzumelden, womit sie auch eine Adresse erhalten, mit der sie fortan angesprochen werden.

Wir hatten uns hierfür zwei theoretische Möglichkeiten überlegt, von denen wir jetzt nur noch die endgültig realisierte Version darstellen wollen.

In dem High-Level-Protokoll, das wir entwickelt haben, spielen die Adressen, die die Clients bei der Anmeldung zugewiesen bekommen, eine wesentliche Rolle: Mit ihr werden nicht nur die Teilnehmer des Netzwerks identifiziert, sondern sie geben auch die Reihenfolge des Sendeprozesses an. Dieser verläuft in einer sich immer wieder wiederholenden Schleife. (Die Beschreibung beginnt also eigentlich an einer willkürlich gewählten Stelle.)

1. Der Server sendet der Reihe nach an alle Clients ein Paket.
2. Der Server sendet die Sendefreigabe an Client 1.
3. Alle Clients senden der Reihe nach ein Paket an den Server.
4. Der Server sendet die Anmeldefreigabe, schaltet in den Empfangsmodus und wartet eine kurze Zeit (im Millisekundenbereich), ob sich ein neuer Client anmelden möchte; ist dies der Fall, wird die Anmeldung durchgeführt

Hat der letzte Client gesendet, beginnt die Schleife wieder von vorne.

Hierzu sind jetzt noch ein paar Erläuterungen nötig. Der hohen Datenmenge, die der Server sendet, wird Rechnung getragen, indem er nicht nur einmal senden darf (wie die Clients) sondern pro Schleifendurchlauf für jeden Client ein Datenpaket sendet, also theoretisch soviel wie alle Clients zusammen. Außerdem obliegt dem Server die Aufgabe, für einen reibungslosen Ablauf des High-Level-Protokolls zu sorgen. Als Konsequenz ist er der einzige, der Sende- und Anmeldefreigaben senden darf.

Im oberen Ablauf mag der Schritt 2, also die Sendefreigabe an Client 1 überflüssig erscheinen, da dieser doch einfach abwarten könnte, bis der Server an den letzten Client gesendet hat, und dies dann für den Client 1 das Zeichen sein könnte, seinerseits mit dem Senden zu beginnen. Da der Microcontroller jedoch über einen sehr begrenzten Codespeicher verfügt, sollen die Anforderungen des Protokolls an diesen möglichst einfach gehalten werden. Die Sendefreigabe wird außerdem genutzt, falls ein Client das Netzwerk verlässt, ohne sich ordnungsgemäß abzumelden, also nicht sendet, wenn er eigentlich sollte. Das High-Level-Protokoll würde an dieser Stelle also einfach stehen bleiben, weil der nachfolgende Client in alle Ewigkeit darauf warten würde, dass sein (ausgeschiedener) Vorgänger seinen Sendevorgang abschließt. Die Sendefreigabe gibt dem Server die Möglichkeit, hier einzugreifen, indem er einfach dem wartenden Client eine extra Sendefreigabe sendet und so die entstehende Lücke überbrückt.

⁴⁾ Die Bezeichnung Server bezieht sich im folgenden immer auf den PC. Mit Clients sind die Taschenrechner gemeint, bzw. genau gesagt die Microcontroller, die den Taschenrechnern die Abarbeitung des High-Level-Protokolls abnehmen.

Während der Microcontroller für das Versenden und Empfangen der per Funk übertragenen Daten zuständig ist, hat der Taschenrechner die Aufgabe, diese Daten darzustellen und Benutzereingaben entgegenzunehmen. Zur Kommunikation dieser beiden Hardwareeinheiten war ein geeignetes Protokoll zu entwickeln. Es werden die zwei Datenleitungen des Taschenrechnerports und zwei freie I/O-Pins des Microcontrollers verwendet. Dadurch, dass wir hierbei zwei Teilnehmer bei zwei verfügbaren Datenleitungen haben, verwenden wir ein einfaches synchrones Protokoll, bei dem jedes gesendete Bit vom Empfänger auf der zweiten Datenleitung bestätigt wird. Dieses Protokoll hat den Vorteil, dass keine feste Synchronisation notwendig ist, was es sowohl Taschenrechner als auch Microcontroller ermöglicht, das Protokoll im Hintergrund abzuarbeiten. Hierüber liegt ein übergeordnetes Protokoll zwecks Versendung von Datenpaketen. Empfängt nun der Microcontroller ein Paket für den Taschenrechner, wird das Paket zwischengespeichert und an den Taschenrechner weitergeleitet, sobald dieser bereit ist, die Daten zu verarbeiten. Hat der TI Daten (Benutzereingaben) an den Server zu senden, gibt er die Daten an den Microcontroller weiter, der diese gemäß High-Level-Protokoll über Funk an den Server sendet.

In diesem Kapitel soll nun ein kurzer Ausblick gegeben werden, was noch alles möglich wäre und was unmöglich ist. Wie in der Einleitung erwähnt, bietet das Internet zu viele Möglichkeiten der Informationsabfrage, als dass man sie alle in unser Projekt integrieren könnte. Abgesehen davon gäbe es aber noch einige Möglichkeiten, die durchaus interessant und auch sinnvoll wären. Das Paradebeispiel dafür wäre es, über den TI den Zugriff auf WAP-Seiten zu ermöglichen. Der Vorteil an WAP-Seiten ist, dass sie speziell für Handys geschrieben wurden, und damit grafisch sehr wenig aufwendig sind, da viele Handys (noch) über kein sehr gutes Grafikdisplay verfügen. Dadurch könnten diese Seiten auch auf dem TI so dargestellt werden wie sie konzipiert wurden, und müssten nicht wie HTML-Seiten, die Auflösungen von 800*600 Pixeln in Farbe oder noch mehr verlangen, bis zur Unkenntlichkeit reduziert werden.

Weiterhin hatten wir angedacht, ob wir den zweiten Kanal, den der nRF zur Verfügung stellt, zu "privaten" Zwecken zur Verfügung stellen, sprich für eine Kommunikation direkt zwischen Taschenrechnern in einem "peer to peer"-Netzwerk ohne die Teilnahme eines PC als Server. Damit könnten kleine, durch die Funkreichweite lokal beschränkte unabhängige Netzwerke entstehen, in denen z.B. gechattet oder gespielt werden könnte. Es könnte dann eine Einstellung an der nRF-Schaltung geben, über die die Funkleistung des Senders so gesenkt wird, dass sie keine anderen Netzwerke stört. Dies hätte auch den angenehmen Nebeneffekt der Stromersparnis.

Theoretisch möglich wäre auch das Übertragen von Graustufenbildern. Eine displayfüllende Grafik mit 3 Bit Farbtiefe (2³ = 8 Graustufen) hätte ein Übertragungsvolumen von 2 kB (= 768 Byte * 3). Solange nicht viele Netzwerkteilnehmer sich diesen Luxus erlauben möchten, wäre dies möglich, auch wenn ein Bild dann fast 2 Sekunden zum Laden bräuchte, fehlerfreie Übertragung vorausgesetzt.

Etwas, was wir auf jeden Fall in naher Zukunft noch zu realisieren versuchen werden, ist die Kompression der per Funk zu übertragenden Daten. Texte lassen sich sehr gut komprimieren, wodurch die Übertragungsrate auf schätzungsweise das Doppelte bis Dreifache gesteigert werden könnte, eine durchaus verlockende Aussicht.

Für Interessierte seien hier noch Referenzen zu weiterführenden Informationen aufgelistet.

The Nordic VLSI nRF401 true single chip 433MHz RF transceiver

GENERAL DESCRIPTION

nRF401 is a true single chip UHF transceiver designed to operate in the 433MHz ISM (Industrial, Scientific and Medical) frequency band. It features Frequency Shift Keying (FSK) modulation and demodulation capability. nRF401 operates at bit rates up to 20kbit/s. Transmit power can be adjusted to a maximum of 10dBm. Antenna interface is differential and suited for low cost PCB antennas. nRF401 features a standby mode which makes power saving easy and efficient. nRF401 operates from a single +3 - 5V DC supply.

As a primary application, nRF401 is intended for UHF radio equipment in compliance with class I.a of the European Telecommunication Standard Institute (ETSI) specification EN 300 220-1 V1.2.1.

QUICK REFERENCE DATA

8-bit Microcontroller with 4K Bytes Flash AT89C51⁵⁾

Features:

• Compatible with MCS-51™ Products
• 4K Bytes of In-System Reprogrammable Flash Memory (Endurance: 1,000 Write/Erase Cycles)
• Fully Static Operation: 0 Hz to 24 MHz
• Three-level Program Memory Lock
• 128 x 8-bit Internal RAM
• 32 Programmable I/O Lines
• Two 16-bit Timer/Counters
• Six Interrupt Sources
• Programmable Serial Channel
• Low-power Idle and Power-down Modes

Description

The AT89C51 is a low-power, high-performance CMOS 8-bit microcomputer with 4K bytes of Flash programmable and erasable read only memory (PEROM). The device is manufactured using Atmel’s high-density nonvolatile memory technology and is compatible with the industry-standard MCS-51 instruction set and pinout. The on-chip Flash allows the program memory to be reprogrammed in-system or by a conven-tional nonvolatile memory programmer. By combining a versatile 8-bit CPU with Flash on a monolithic chip, the Atmel AT89C51 is a powerful microcomputer which provides a highly-flexible and cost-effective solution to many embedded control applications.

⁵⁾ Wir verwenden den 89C52, der sich vom 89C51 dadurch unterscheidet, dass er doppelt soviel Flash-ROM hat.

Der folgende Bestückungsplan soll einen Eindruck vermitteln, wie groß die TI-Net V2.0 Platine ist.

Wir danken allen, die uns bei der Arbeit an diesem Projekt unterstützt haben. Besonders möchten wir erwähnen:

Herrn Brunk von der Firma VisiCon, der uns zwei Evaluation Boards zur Verfügung gestellt, uns viel bei der Hardware geholfen und bei der Herstellung der Platinen finanziell und organisatorisch unterstützt hat. Ohne ihn und die Hilfe seines Kollegen Alexander Eickhoff hätten wir nicht rausgefunden, dass beim Funken nicht gilt: "Viel (Sendeleistung) hilft viel".

Herrn Goretzki von der Firma Dikon, der mit uns die Umsetzung der Schaltpläne in Platinen vorgenommen hat. Mit viel Zeit und Geduld hat er sich allen unseren Fragen gestellt, und uns geholfen, unsere Wünsche zu realisieren.

Herrn Fricke, der Geschäftsführer der Firma Dikon, der uns als Ansprechpartner zur Verfügung stand und uns die Unterstützung seiner Firma anbot.

Herrn Ebrecht vom II. Physikalischen Institut der Georg-August-Universität Göttingen, der uns beim Ätzen unserer ersten SMD-Platine geholfen hat, und immer bereit war, alles stehen und liegen zu lassen, um sich mit unseren Fragen und Problemen zu befassen.

Frau Margherita Muller von Coilcraft Europe, die uns die für die Schaltung des nRF benötigten Induktivitäten geschenkt hat.

Herrn Endre Rindalsholt von der Firma nordIC, der uns ausführlich auf unsere Fragen bezüglich des nRF401 geantwortet hat.

Wir bedanken uns auch bei unserem betreuenden Lehrer Herrn Dr. Juraschek, der uns viele Kontakte vermitteln konnte und der uns ermutigt hat, bei Jugend forscht mitzumachen.