RS485 galvanisch trennen

@  Stephan (Gast)

>Wenn ich mich recht erinnere wird dies bei Ethernet doch auch so
>gemacht.

Ja, aber

>Geht dies, oder nicht bzw was spricht dafür bzw dagegen?

Das geht nur, wenn dein Leuitungscode gleichspannungsfrei ist. Also 
Manchester (10M Ethernet), oder 4B5B (100M Ethernet) oder 8B10B (GB 
Ethernet). Einfaches RS232 ist NICHT gleichspannungs.

MFg
Falk

@  Stephan (Gast)

>Das heißt, wenn ich meine zu versendenden Daten entsprechend codiere
>(Manchester, 4B5B, ...) und dann in meinen UART schiebe, RS485 Baustein,
>Übertrager und auf der anderen Seite das gleiche Spiel sollte dies doch
>funktionieren.

Eigentlich schon.

MFg
Falk

@  Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik)

>völlig falsch. Die Gleichspannungsfreiheit per Manchester muss am
>TxD-Ausgang des UARTs gegeben sein, nicht beim Laden der Daten.

Ja, wird aber praktisch dennoch funktionieren. Sei es über eine Päambel 
zunm einpegeln des Mittelwerts oder wie auch immer.

>Manchester lässt sich daher nur bei synchroner Übertragung aktivieren.

Stimmt nicht. Manchester hat mit synchron (mit Takt) oder asynchron 
(ohne Takt) gar nichts zu tun. Vor allem, weil Manchestercode bei 
synchroner Übertragung relativ sinnlos wäre.

MFG
Falk

Falk Brunner schrieb:

> Vor allem, weil Manchestercode bei
> synchroner Übertragung relativ sinnlos wäre.

Es scheint mir eher so zu sein, daß Manchester typisch für synchrone 
Übertragung und bei asynchroner zwar nicht sinnlos aber doch unüblich 
ist, denn normalerweise braucht man hier keine seiner beiden 
Eigenschaften: Taktrückgewinnung findet nicht statt und 
Gleichspannungsfrei ist man eh nicht.

Bei synchroner Übertragung muß man nochmal unterscheiden zwisch "mit 
Taktleitung" und "mit Taktrückgewinnung aus dem Datensignal". Für 
letzteres ist Manchester einer der möglichen Leitungscodes. Aber selbst 
bei einer Übertragung mit Taktleitung kann Manchester sinnvoll sein, 
wenn sie gleichspannungsfrei sein muß.

Ich verweise auf die Wikipedia-Artikel zu "Synchrone_Datenübertragung", 
"Leitungscode" und "Manchester-Code".

@  Reinhard Max (rmax)

>Es scheint mir eher so zu sein, daß Manchester typisch für synchrone
>Übertragung

Beispiel?

>und bei asynchroner zwar nicht sinnlos aber doch unüblich
>ist, denn normalerweise braucht man hier keine seiner beiden
>Eigenschaften: Taktrückgewinnung findet nicht statt und
>Gleichspannungsfrei ist man eh nicht.

Eben!

>Bei synchroner Übertragung muß man nochmal unterscheiden zwisch "mit
>Taktleitung" und "mit Taktrückgewinnung aus dem Datensignal".

Nöö, zweiteres wäre ja asynchron ala RS232!

>bei einer Übertragung mit Taktleitung kann Manchester sinnvoll sein,
>wenn sie gleichspannungsfrei sein muß.

Beispiel einer praktischen Anwendung?

>Ich verweise auf die Wikipedia-Artikel zu "Synchrone_Datenübertragung",
>"Leitungscode" und "Manchester-Code".

Na dann stell doch gleich die Links hier rein.

Der "Artikel" "Synchrone_Datenübertragung" ist schlicht falsch. Da 
werden diverse Sachen vermischt. Sendepausen gibts auch bei synchroner 
Übertragung, z.B. SPI.

MfG
Falk

Falk Brunner schrieb:
> @  Reinhard Max (rmax)
>
>>Es scheint mir eher so zu sein, daß Manchester typisch für synchrone
>>Übertragung
>
> Beispiel?

Schau' Dir das Beispiel in http://de.wikipedia.org/wiki/Manchester-Code 
an. Siehst Du da irgendwo die für eine asynchrone (UART) Üertragung 
üblichen Start- und Stopbits?

>>und bei asynchroner zwar nicht sinnlos aber doch unüblich
>>ist, denn normalerweise braucht man hier keine seiner beiden
>>Eigenschaften: Taktrückgewinnung findet nicht statt und
>>Gleichspannungsfrei ist man eh nicht.
>
>Eben!

OK, wenn der Manchester-Code also nach Deiner Aussage von weiter oben 
bei synchroner Übertragung sinnlos ist und Du mir hier zustimmst, daß 
man ihn für asynchrone Übertragung eigentlich nicht braucht, wofür 
braucht man ihn dann überhaupt?

>>Bei synchroner Übertragung muß man nochmal unterscheiden zwisch "mit
>>Taktleitung" und "mit Taktrückgewinnung aus dem Datensignal".
>
> Nöö, zweiteres wäre ja asynchron ala RS232!

Falsch. Asynchron ist, wenn beide Seiten unabhängige Taktquellen haben, 
synchron ist, wenn eine Seite den Bit-Takt (und nicht nur die 
Wortgrenzen wie bei RS232) von der anderen Seite bezieht. Ob das per 
separater Leitung oder durch eine entsprechende Leitungscodierung 
geschieht, ist unerheblich. Beispiele für synchrone Datenübertragung 
ohne Taktleitung sind ISDN und DSL.

>>bei einer Übertragung mit Taktleitung kann Manchester sinnvoll sein,
>>wenn sie gleichspannungsfrei sein muß.
>
> Beispiel einer praktischen Anwendung?

Ob das irgendwo praktisch angewendet wird, weiß ich nicht, aber wenn 
sowohl Takt- als auch Datenleitung per Übertrager galvanisch getrennt 
werden sollen (um mal wieder halbwegs zum Thread-Thema zurückzukehren), 
kann man Manchester nehmen, um die Leitung gleichspannungsfrei zu halten 
(auch wenn es in dem Fall wahrscheinlch bessere Möglichkeiten gibt).

> Der "Artikel" "Synchrone_Datenübertragung" ist schlicht falsch. Da
> werden diverse Sachen vermischt. Sendepausen gibts auch bei synchroner
> Übertragung, z.B. SPI.

Falsch würde ich nicht sagen, aber vielleicht etwas ungenau. Der 
entscheidende Unterschied ist eben, ob der Empfänger seinen Bit-Takt mit 
dem Sender synchronisiert wie bei ISDN und Ethernet oder gar seinen Takt 
direkt vom Sender bezieht wie bei I²C und SPI, oder ob die Takte von 
Sender und Empfänger eben asyncron laufen und von sich aus genau genug 
sein müssen, damit die Übertragung klappt.

Da schliess ich mich seppl an. Das Ganze ist z.B. bei dem DMX-Interface 
[[http://www.digital-enlightenment.de/usbdmx.htm]] per Optokoppler, 
DC/DC-Wandler und RS485-TTL-Wandler realisert und läuft super.

@  Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik)

>Du solltest dich wirklich mal mit den Grundlagen von asynchron und
>synchron befassen,

Hab ich gemacht, vor langer Zeit im Studium der Kommunikationstechnik.

> dann würdest du hier nicht solchen Unsinn verzapfen.

Das sagt der Richtige ;-)

>Da steht z.B. laut und deutlich  drin, dass für die Taktrückgewinnung
>genügend Flanken vorhanden sein müssen und daher ab einer bestimmten
>Anzahl Nullen oder Einsen künstlich ein Logikwechsel eingeführt wird -

Ja und? Hat das einer bestritten?

>wenn das für dich asynchron ist, hast du dir wohl die Definitionen
>selbst ausgedacht, mit der bekannten Technik hat das nichts zu tun.

Wer lesen kann ist klar im Vorteil. Lies meine Postings nochmal.

>Vielleicht hast du ja auch einfach synchron und asynchron geistig
>vertauscht,

Nö.

>Das Niveau hier im Forum ist oft erstaunlich hoch, aber manchmal finden
>auch Sturzflüge in unbekannte Tiefen statt.

Literaturtip, nur für dich.

http://de.wikipedia.org/wiki/Arroganz

@ Reinhard Max (rmax)

>Schau' Dir das Beispiel in http://de.wikipedia.org/wiki/Manchester-Code
>an. Siehst Du da irgendwo die für eine asynchrone (UART) Üertragung
>üblichen Start- und Stopbits?

Was führt dich zu der irrigen Annhame, asynchrone Übertragung muss 
Start- und Stopbits haben? Nur weil RS232 seit über 40 Jahren exitiert 
und hier in jedem 3. Posting durchgekaut wird, heisst das noch lange 
nicht, dass es die ultimative Definition einer asynchronen Kommunikation 
ist.

>OK, wenn der Manchester-Code also nach Deiner Aussage von weiter oben
>bei synchroner Übertragung sinnlos ist und Du mir hier zustimmst, daß
>man ihn für asynchrone Übertragung eigentlich nicht braucht,

Auch du hast eine Leseschwäche. Wo stimme ich dir hier zu?
Du hast eher synchron und asynchron in deiner Aussage verwechselt.

"Es scheint mir eher so zu sein, daß Manchester typisch für synchrone
Übertragung und bei asynchroner zwar nicht sinnlos aber doch unüblich
ist, denn normalerweise braucht man hier keine seiner beiden
Eigenschaften: Taktrückgewinnung findet nicht statt und
Gleichspannungsfrei ist man eh nicht."

>braucht man ihn dann überhaupt?

Hää?
Für asynchrone Kommunikation zur a) Taktrückgewinnung und b) 
Gleichstromfreiheit, damit es per Übertrager oder Kondensator gekoppelt 
werden kann. Siehe Ethernet, ISDN, whatever.

>Falsch. Asynchron ist, wenn beide Seiten unabhängige Taktquellen haben,
>synchron ist, wenn eine Seite den Bit-Takt (und nicht nur die
>Wortgrenzen wie bei RS232) von der anderen Seite bezieht.

Ja.

> Beispiele für synchrone Datenübertragung
>ohne Taktleitung sind ISDN und DSL.

Jain. Der Begriff asynchron/synchron wird nun mal vielschichtig 
verwendet. Auf Bit-, Bytes und Blockebene. Da reden wir teilweise 
aneinander vorbei.

>> Beispiel einer praktischen Anwendung?

>Ob das irgendwo praktisch angewendet wird, weiß ich nicht,

Das war aber meine Frage ;-)

> aber wenn
>sowohl Takt- als auch Datenleitung per Übertrager galvanisch getrennt
>werden sollen (um mal wieder halbwegs zum Thread-Thema zurückzukehren),
>kann man Manchester nehmen, um die Leitung gleichspannungsfrei zu halten

Hat keiner bestritten.

>(auch wenn es in dem Fall wahrscheinlch bessere Möglichkeiten gibt).

Eben.

>Falsch würde ich nicht sagen, aber vielleicht etwas ungenau. Der
>entscheidende Unterschied ist eben, ob der Empfänger seinen Bit-Takt mit
>dem Sender synchronisiert wie bei ISDN und Ethernet oder gar seinen Takt
>direkt vom Sender bezieht wie bei I²C und SPI, oder ob die Takte von
>Sender und Empfänger eben asyncron laufen und von sich aus genau genug
>sein müssen, damit die Übertragung klappt.

Nein, synchronisieren muss der Empfänger IMMER! Auch bei RS232. Dass es 
dabei verschiedene Mechanismen gibt ist eine andere Frage.

MFG
Falk

Thilo M. schrieb:

> Ich hab's so realisiert, bin zufrieden damit.

Wieso hast du 6N139 verwendet, statt der hier naheliegenden 6N137?

Was ist der Sinn von Q1,Q2? Das können die Koppler doch selbst 
übernehmen.

@  STK500-Besitzer (Gast)

>Wo gewinnt man denn bei RS232 den (Bit-)Takt zurück?

Mit der fallenden Flanke des Startbits. Und implizit während der 
Übertragung eines Bytes aus dem notwendigen, kleinen Frequenzfehler. OK, 
kann man sich streiten.

>Bei Manchester wird der Empfänger durch die Präambel auf den Sender
>synchronisiert.

Auch, aber nicht nur. Während des weiteren Datenempfangs muss im 
Allgemeinen fortlaufend der lokale Oszillator nachgeführt werden, sonst 
läuft die Phase  bei langen Datenpaketen weg. Stichwort PLL.

> Der Sender muss eigentlich nur die Taktrate für eine
>Übertragung konstant halten.

Jaja, wenns nur so einfacvh wäre wie man es hier sich bunt ausmalt.
Stichwort Phasendrift zwischen Sender und Empfänger.

> Bei der nächsten, kann er eine andere Taktrate wählen.

Klar, und wo wird sowas gemacht? So ziemlich niergends.

MfG
Falk