Problem mit Laser-Datenübertragung

[Murus]

Hallo zusammen,

ich arbeite seit einiger Zeit hier an der Datenübertragung per Laser.
Mein Fernziel ist es, am Sender einen Text einzugeben, abzulasern und beim Empfänger den Text wieder auslesen.

Die Hardware hab ich gebaut und die funktioniert. Als Laser hab ich eine normale Laserdiode aus nem Laserpointer im Gebrauch, angesteuert von einem Hexfet. Als Empfänger ne Photodiode mit nachgeschaltetem OpAmp, der, wenn er voll vom Laser beleuchtet wird, +3V gegen Masse rauslässt.
Im Sender und Empfänger sitzen zwei Mega8, intern mit 1MHz getaktet.
Die Übertragung möchte ich per Ein- und Ausschalten des Lasers realisieren.

Zum Sender:
Momentan arbeite ich noch mit zwei fest eingestellten Bytes und einer Präambel, die ebenfalls 1 Byte gross ist. Die Präambel sieht so aus: 10101010. Danach werden zwei weitere, beliebige Bytes gesandt, die auch in einem Array stecken. Nach jedem Timer1-Overflow-Interrupt wird das nächste Bit an den Laser ausgegeben, so, dass er blinkt.

Zum Emfpänger:
Hier arbeite ich mit dem Komparator. Ich verwende die interne Referenz von 1.25V. Am Eingang hängt der OPV, der von der Photodiode angesteuert wird. Der Komparator ist so getrimmt, dass er bei jeder L/H-Flanke einen Interrupt auslöst. Wenn die Präambel reinkommt (Laser beginnt zu blinken), wird in der Komparator-Interrupt-Routine der Zählerstand des Timer1 ausgelesen. Dies passiert 4mal. Am Schluss hab ich den Timerwert, der zwischen zwei H/L-Flanken der Präambel liegt. So kann ich denn auch weiterrechnen. Nach der Präambel wird der Komparator-Interrupt ausgeschaltet und der Timer1 wird mit dem zuvor berechneten Wert voreingestellt, und zwar so, dass der Interrupt immer dann kommt, wenn die Hälfte einer Flanke am Laser anliegt, also nur dann, wenn entweder dunkel oder hell ist. Wenn der Timer1 überläuft, wird der Komparator-Wert (1 oder 0, je nach Beleuchtung der Photodiode) in ein Array gespeichert.
Wenn die beiden Bytes durch sind, werden sie an einem LCD angezeigt.

Mit niedrigen Übertragungsfrequenzen funktioniert diese Methode. Wird man aber nur etwas schneller, fällt die ganze Geschichte auseinander, die Synchronisation stimmt hinten und vorne nicht mehr.
Was schlägt ihr für andere Methoden vor? Wie könnte man das noch lösen? Während der Übertragung auch noch synchronisieren? Ich hab halt das Problem, dass auch mehrmals nacheinander derselbe Zustand eintreffen kann....
Was habt ihr da so für Ideen?

Herzlichen Gruss
Mario

[super_castle]

"Die Übertragung möchte ich per Ein- und Ausschalten des Lasers realisieren."

Das wird so nicht gehen, weil der Spannungsabfall in den Leitungen eine Induktion erzeugt und der Wiederaufbau der Spannung dadurch verzögert wird. Kannste eigentlich so vergessen.

Castle

[Murus]

Na ja, ich werde wohl mit meiner "primitiven" Software keine so grossen Datenraten realisieren können, dass dieser Aspekt zum Zuge kommen wird....

Aber ich hab mir jetzt überlegt, den Komparatorinterrupt jedes mal kommen zu lassen, wenn eine Flanke ankommt. So kann ich auch während der Datenübertragung mitsynchronisieren. Ich werde das morgen mal testen.
Wie würde man es denn sonst machen, wenn nicht ein- oder ausschalten?

Herzlichen Gruss
Mario

[Felix G]

Also Datenübertragung per an/ausschalten des Lasers geht nur bei recht niedrigen Frequenzen,
denn für sowas sind weder die billigen LD-Treiber noch die Laserdioden selbst ausgelegt.

Normalerweise verwendet man daher modulierbare LD-Treiber, die zwischen zwei Leistungsniveaus umschalten können.
Anstatt die Diode also ganz abzuschalten drosselt man sie nur auf z.B. 25% was sehr viel schneller geht. (und schonender ist es auch)

Es gibt zwar seit einiger Zeit auch spezielle Laserdioden die sich beim kompletten abschalten genauso schnell modulieren lassen, aber die sind teuer und schwer zu kriegen.



Aber natürlich stellt sich erstmal die Frage ob das bei deiner Software schon eine Rolle spielt
(da wäre es sehr praktisch wenn du das empfangene Signal auf einem Oszi anschauen könntest)
denn es wäre ja ärgerlich wenn du Geld in einen modulierbaren LD-Treiber investieren würdest obwohl der Fehler ganz woanders liegt.

[ThSteier]

Hallo,

kennt hier jemand das "Ronja"-Laserlink-Projekt? Die haben Übertragungsraten bis 10 MBps über etliche 100m realisiert - vielleicht könnte man daraus Anregungen entnehmen.

Die Homepage ist leider in russisch, aber hier gibt es ein PDF mit diversen Infos dazu.

Viele Grüße,
Thomas

[Murus]

Ja, das soll nur ein Hobby-Projekt sein... Und zum ein paar Bytes Text übertragen reicht das allemal. Die Hardware wollt ich so einfach wie möglich machen, deshalb schalt ich den Laser an und ab, ist auch von der Sofware einfacher.

[skillii]

Ich hab halt das Problem, dass auch mehrmals nacheinander derselbe Zustand eintreffen kann....
Was habt ihr da so für Ideen?

Da musst du dir eine Codierung einfallen lassen...
z.B eine Manchester Kodierung.
Google findet bestimmt etwas!!!

[Murus]

Hmm, dann hätte ich ja nur eine Abfolge von Nullen und Einsen... Nah, zu kompliziert... Ich bin kurz davor, mein jetziges System zum laufen zu bringen, bei dem ich den Komparator immer den Interrupt kommen lasse, wenn die Flanke wechselt. So kann ich auch während der Datenübertragung mitsynchronisieren. Mein Problem ist nur, dass während der Übertragung, wenn dann ein Komparator-Interrupt kommt, stellt er mir irgendwie das ganze System auf Null zurück.....Hab schon alles probiert, momentan häng ich da fest.

Herzlichen Gruss
Mario

[Felix G]

Es gibt sehr viele Möglichkeiten den Taktgehalt zu erhöhen...

1. Manchester Codierung
+ sehr hoher Taktgehalt (eine Flanke für jedes Bit)
- Baudrate doppelt so hoch wie Datenrate

verwendet bei: 10MBit Ethernet


2. Bitstuffing
nach einer bestimmten Anzahl gleicher Bits wird ein komplementäres Bit in den Bitstrom eingefügt
+ Baudrate nur leicht erhöht
+ ausreichender Taktgehalt
- softwaremässig nicht besonders gut realisierbar

verwendet bei: CAN


3. Blockcodes
Die zu sendenden Blöcke werden mit mehr Bits codiert als notwendig (also z.B. 10Bit statt 8 um ein Byte zu übertragen)
dabei sucht man sich aus dem "Überangebot" an Symbolen natürlich solche aus,
die eine bestimmte maximale Anzahl aufeinanderfolgender gleicher Bits nicht überschreiten.
(Bei 8B10B hat man ja immerhin 1024 Symbole zur Verfügung von denen man sich nur 256 aussuchen muss)
+ ausreichender Taktgehalt
+ Baudrate nur leicht erhöht

verwendet bei: Fast Ethernet, Gigabit Ethernet, SDH


4. Scrambler
Der Datenstrom wird durch einen sog. Scrambler geschickt, der die Bits ein bischen durcheinanderwürfelt und so lange konstante Bitfolgen verhindert.
Am Empfänger sitzt ein Descrambler der die Bits wieder in die richtige Reihenfolge bringt.
+ hardwaremässig sehr leicht realisierbar (besteht im wesentlichen aus ein paar Schieberegistern)
+ ausreichender Taktgehalt

verwendet bei: ISDN



Ich persönlich würde von Manchester aufgrund der hohen Baudrate abraten,
auch Bitstuffing ist wohl nicht so ideal da es per Software nunmal etwas umständlich ist einzelne Bits in einen Datenstrom einzufügen.

Fazit: Nimm einen Blockcode wenn du keine zusätzliche Hardware möchtest, ansonsten geht auch ein Scrambler




edit:
hier mal ein Beispiel für einen gängigen Blockcode:
(4B5B Codierung von 100BASE-FX Ethernet)

0000 11110
0001 01001
0010 10100
0011 10101
0100 01010
0101 01011
0110 01110
0111 01111
1000 10010
1001 10011
1010 10110
1011 10111
1100 11010
1101 11011
1110 11100
1111 11101


wenn man also als Rohdaten z.B. die Kombination 1000 hat, sendet man das Symbol 10010.

[Murus]

Hmmm, haste recht, ich brauch ne Codierung.... momentan ist mir das zu heikel.
Ich werde probieren, das Ganze mit dem Manchester zu bauen.
Mal gucken, ob ich nen Algorithmus hinkriege, der mir das korrekt de- und entcodiert...

Herzliche Grüsse
Mario