Hallo zusammen Einige werden jetzt denken, schon wieder das alte Thema. Meine Frage ist jedoch, kann ich eine RS485 nicht auch mit einem Übertrager galvanisch trennen, also das differentielle Signal einfach auf den Übertrager und das wars (natürlich beim Sender und Empfänger)? Wenn ich mich recht erinnere wird dies bei Ethernet doch auch so gemacht. Geht dies, oder nicht bzw was spricht dafür bzw dagegen? Vielen dank im voraus. MfG Stephan
@ 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
Hallo zusammen @Falk 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. Oder habe ich dies falsch verstanden? MfG Stephan
@ 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
Ist es nicht so, dass ein fester Pegel anliegt, wenn gar nichts kommt? Das waere dann pure Gleichspannung. Gast4
> 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. Es gibt fertige Bauteine zur galvanischen Trennung, die machen im Prinzip genau das, z.B. die ADuM12xx von Analog (siehe Prinzipschaltbild im Datenblatt).
Stephan schrieb: > Hallo zusammen > > @Falk > > 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. > Oder habe ich dies falsch verstanden? Hallo Stephan, völlig falsch. Die Gleichspannungsfreiheit per Manchester muss am TxD-Ausgang des UARTs gegeben sein, nicht beim Laden der Daten. Prinzipiell ist das bei asynchroner Übertragung garnicht möglich, weil bei asynchron in den Pausen eine konstante 1 gesendet wird. Manchester lässt sich daher nur bei synchroner Übertragung aktivieren. Du könntest also synchron arbeiten, wenn die Hardware das zulässt, ist aber beim PC normalerweise nicht der Fall. Es gibt ICs, die den ausgehenden Datenstrom mit höherer Frequenz zerhacken und dann übertragen, aber die sind teurer als Optokoppler. Gruss Reinhard
@ 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: >>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! > Du solltest dich wirklich mal mit den Grundlagen von asynchron und synchron befassen, dann würdest du hier nicht solchen Unsinn verzapfen. 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 - wenn das für dich asynchron ist, hast du dir wohl die Definitionen selbst ausgedacht, mit der bekannten Technik hat das nichts zu tun. Vielleicht hast du ja auch einfach synchron und asynchron geistig vertauscht, dann machen deine Äusserungen immer noch etwas mehr Sinn als so. Das Niveau hier im Forum ist oft erstaunlich hoch, aber manchmal finden auch Sturzflüge in unbekannte Tiefen statt. Gruss Reinhard
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.
Denke mal über die galvanische Trennung zwischen TxD-Ausgang bzw. RxD-Eingang des Uart (oder was auch immer) und dem RS485-Treiber nach. Der RS485-Treiber muß dann natürlich über einen DC-DC-Wandler oder eine galvanisch getrennte Versorgung betrieben werden. Diese Lösung habe ich schon mehrfach angewendet, etwas aufwändig, funktioniert aber prima. Gruß Seppl
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
Ich hab's so realisiert, bin zufrieden damit. Was hinten dranhängt is' ja egal, ob MAX232 oder RS485.
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.
Der 6N139 hat nur 1.6mA Iforward an den Sendedioden, entlastet den Sender etwas. Q1 und Q2 deshalb, weil die Flanken durch die optische Kopplung verschliffen werden, deshalb wäre die Baudrate sehr begrenzt. Mit den übersteuerten Transistoren kommt hinten ein sauberer Rechteck 'raus (das Datenblatt empfiehlt sogar Logikgatter).
Falk Brunner schrieb: > Wer lesen kann ist klar im Vorteil. Lies meine Postings nochmal. Hab ich: Zitat: >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! Zitat Ende Das ist eine glasklare Behauptung: Synchron mit Taktrückgewinnung = asynchron ala RS232 nur leider völlig absurd. Auf diesem unterirdischen Niveau gibt es keinerlei Verständigungsmöglichkeit. Reinhard
Wo gewinnt man denn bei RS232 den (Bit-)Takt zurück? Wenn der Sender eine andere Baudrate verwendet als der Empfänger, dann gewinnt man einen Blumenkohl oder Hyroglyphen, erkennt aber keine sinnvollen Daten. Bei Manchester wird der Empfänger durch die Präambel auf den Sender synchronisiert. Der Sender muss eigentlich nur die Taktrate für eine Übertragung konstant halten. Bei der nächsten, kann er eine andere Taktrate wählen.
@ 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
>Klar, und wo wird sowas gemacht? So ziemlich niergends.
Kann... muss aber nicht...
Schöne Grüße von R.V.L. Hartley, ihr habt beide recht ... Das ist das schöne an nicht genormten Definitionen jeder Depp kann irgend was rein interpretieren! In diesem Sinne ...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.