Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #314242 > unrolled thread

CAN FD über Optokoppler

Back to article view | Back to de.sci.electronics

Contents

  CAN FD über Optokoppler Newdo <Newdo@ifmd.de> - 2021-11-21 23:10 +0100
    Re: CAN FD über Optokoppler Michael Wöstenfeld <michael.woestenfeld@gmail.com> - 2021-11-22 00:43 -0800
      Re: CAN FD über Optokoppler Newdo <Newdo@ifmd.de> - 2021-11-22 13:14 +0100
        Re: CAN FD über Optokoppler Michael Wöstenfeld <michael.woestenfeld@gmail.com> - 2021-11-22 04:49 -0800
    Re: CAN FD über Optokoppler Gerald Oppen <Gerald.Oppen@web.de> - 2021-11-28 18:45 +0100
      Re: CAN FD über Optokoppler Newdo <Newdo@ifmd.de> - 2021-11-28 19:33 +0100
        Re: CAN FD über Optokoppler Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-11-28 21:30 +0100
          Re: CAN FD über Optokoppler Newdo <Newdo@ifmd.de> - 2021-11-29 13:22 +0100
            Re: CAN FD über Optokoppler Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-11-29 22:17 +0100
              Re: CAN FD über Optokoppler Martin Τrautmann <t-usenet@gmx.net> - 2021-11-30 07:47 +0100
                Re: CAN FD über Optokoppler Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-11-30 21:21 +0100
                  Re: CAN FD über Optokoppler Martin Τrautmann <t-usenet@gmx.net> - 2021-12-01 07:28 +0100
                    Re: CAN FD über Optokoppler Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-12-01 13:54 +0100
                      Re: CAN FD über Optokoppler Martin Τrautmann <t-usenet@gmx.net> - 2021-12-01 14:31 +0100
                        Re: CAN FD über Optokoppler Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-12-01 23:34 +0100
                          Re: CAN FD über Optokoppler Martin Τrautmann <t-usenet@gmx.net> - 2021-12-02 08:05 +0100
                      Re: CAN FD über Optokoppler Newdo <Newdo@ifmd.de> - 2021-12-01 17:47 +0100
                        Re: CAN FD über Optokoppler Martin Τrautmann <t-usenet@gmx.net> - 2021-12-01 18:56 +0100
              Re: CAN FD über Optokoppler Tilmann Reh <usenet2007nospam@autometer.de> - 2021-11-30 08:27 +0100
                Re: CAN FD über Optokoppler Newdo <Newdo@ifmd.de> - 2021-11-30 09:33 +0100
                Re: CAN FD über Optokoppler Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-11-30 21:16 +0100
                  Re: CAN FD über Optokoppler Tilmann Reh <usenet2007nospam@autometer.de> - 2021-12-01 11:51 +0100
                    Re: CAN FD über Optokoppler Gerald Oppen <Gerald.Oppen@web.de> - 2021-12-02 17:22 +0100
              Re: CAN FD über Optokoppler Newdo <Newdo@ifmd.de> - 2021-11-30 09:46 +0100
                Re: CAN FD über Optokoppler Gerald Oppen <Gerald.Oppen@web.de> - 2021-12-02 17:46 +0100
                  Re: CAN FD über Optokoppler Newdo <Newdo@ifmd.de> - 2021-12-02 18:28 +0100
                    Re: CAN FD über Optokoppler Gerald Oppen <Gerald.Oppen@web.de> - 2021-12-02 20:05 +0100
          Re: CAN FD über Optokoppler Newdo <Newdo@ifmd.de> - 2021-11-29 13:27 +0100
            Re: CAN FD über Optokoppler Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> - 2021-11-29 14:05 +0000
              Re: CAN FD über Optokoppler Newdo <Newdo@ifmd.de> - 2021-11-29 23:34 +0100
                Re: CAN FD über Optokoppler Tilmann Reh <usenet2007nospam@autometer.de> - 2021-11-30 08:31 +0100
                  Re: CAN FD über Optokoppler Reinhardt Behm <rbehm@hushmail.com> - 2021-11-30 16:15 +0800

Page 2 of 2 — ← Prev page 1 [2]

#314651

Hallo Tilmann Reh,

Du schriebst am Tue, 30 Nov 2021 08:27:31 +0100:

> > Aber _genau_ _letzteres_ tut ein passiver Koppler, der z.B. aus zwei
> > Optokopplern mit ein bisserl Beschaltung besteht, und hält sich
...
> Das hört sich so an, als ob Du hier an Isolatoren für I2C denkst, bei

Ja, dort ist das ähnlich.

> denen jedes einzelne Signal bidrektional übertragen werden muß. Die
> sind schon speziell konstruiert, um genau solche "Selbsthaltung" zu
> vermeiden.

Eben.

> > BTW, genau dafür, diesem Problem abzuhelfen, gibt es die speziellen
> > Buskoppler für diesen und andere Busse, die zudem meistens von
> > vornherein auf die benötigten Geschwindigkeiten ausgelegt sind.

> Für CAN werden die Signale der beiden Richtungen separat übertragen,

Wäre mir neu - ein Bus ist doch dadurch gekennzeichnet, daß er _mehr_
als 2 Stationen miteinander verbindet. Zur Ankopplung _an_ den Bus
könnte an so auskommen, wenn der Controller die Koppel-Elektronik
steuern kann. Als Repeater zur Potentialtrennung geht das nicht.

> das geht mit ganz normalen Isolatoren (oder Optokopplern). Die
> Isolation erfolgt zwischen dem Controller und dem Transceiver (wo TXD
> und RXD noch einzeln vorliegen), nicht direkt an der Busleitung.

Nur zur Anschaltung eines Controllers, ähnlich wie bei RS485, geht das.
Zusätzlich muß halt auf die "Stärke" der Signale (dominant vs. rezessiv)
geachtet werden. Das muß dann mit passenden Pull-up/down-Schaltungen,
ggfs. mit Stromquellen/-senken, angekoppelt werden. Sowas hat z.B.
Philips im Programm, aber AFAIK nicht potentialgetrennt. Da könnte man
aber das Prinzip abschauen.

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#314669

Am 30.11.2021 um 21:16 schrieb Sieghard Schicktanz:

>> Für CAN werden die Signale der beiden Richtungen separat übertragen,
> 
> Wäre mir neu - ein Bus ist doch dadurch gekennzeichnet, daß er _mehr_
> als 2 Stationen miteinander verbindet. Zur Ankopplung _an_ den Bus
> könnte an so auskommen, wenn der Controller die Koppel-Elektronik
> steuern kann. Als Repeater zur Potentialtrennung geht das nicht.

Niemand hier - außer Dir - denkt an oder spricht über Repeater.

Es geht die ganze Zeit nur um die galvanische Trennung zwischen
Controller und Transceiver - mit ganz gewöhnlichen Optokopplern oder
Isolatoren, getrennt für TXD und RXD.

Tilmann

[toc] | [prev] | [next] | [standalone]

#314737

Am 01.12.21 um 11:51 schrieb Tilmann Reh:
> Am 30.11.2021 um 21:16 schrieb Sieghard Schicktanz:
> 
>>> Für CAN werden die Signale der beiden Richtungen separat übertragen,
>>
>> Wäre mir neu - ein Bus ist doch dadurch gekennzeichnet, daß er _mehr_
>> als 2 Stationen miteinander verbindet. Zur Ankopplung _an_ den Bus
>> könnte an so auskommen, wenn der Controller die Koppel-Elektronik
>> steuern kann. Als Repeater zur Potentialtrennung geht das nicht.
> 
> Niemand hier - außer Dir - denkt an oder spricht über Repeater.
> 
> Es geht die ganze Zeit nur um die galvanische Trennung zwischen
> Controller und Transceiver - mit ganz gewöhnlichen Optokopplern oder
> Isolatoren, getrennt für TXD und RXD.

Das hört sich in der OP-Frage anders an:

--
ich suche eine taugliche Schaltung zur galvanischen Trennung von CAN FD 
über Optokoppler.
Insbesondere betreffens der Auswahl der richtigen OKs bezüglich 
Laufzeiten und Isolation (5-8kV peak, 500..600V Vrms dauerhaft).
--
Nach meiner Auffassung eben der galvanischen / optischen Trennung von 
CAN-FD Busleitungen. Die Rx/Tx Leitungen vor einem CAN-Transceiver 
galvanisch zu trennen hat elektrisch nichts mit CAN zu tun insofern man 
der Baudrate entsprechend auf ausreichend Flankensteilheit / 
Durchlaufzeiten achtet.

GErald

[toc] | [prev] | [next] | [standalone]

#314626

Am 29.11.2021 um 22:17 schrieb Sieghard Schicktanz:
> Hallo Newdo,
> 
> Du schriebst am Mon, 29 Nov 2021 13:22:46 +0100:
> 
>>> ebenfalls. Nennt sich auch "Rückkopplung".
>>
>> Das ist das Prinzip des CAN-Busses, dass ein dominanter Pegel wenn er
> 
> Rückkopplung ist ein Prinzip des CAN-Bus? Wäre mir neu.

Den Begriff hast _Du_ letztlich eingeführt.
Das Prinzip ist, dass der Zustand des Busses direkt zurückgelesen wird. 
Wer einen dominanten Zustand erzeugt hat, kann nicht entschieden werden.
Wenn man in der Lage ist, das Prinzip auch über andere Medien 
abzubilden, gibt es da kein Lock- oder Rückkopplungs- oder wie auch 
immer genanntes Problem. Alle Macht geht vom CAN-Controller aus.
> 
>> ausgegeben wird, auch unmittelbar wieder eingelesen wird. Was soll er
>> denn sonst einlesen?
> 
> Das ist schon richtig, und das ist bei einem _Controller_ auch
> unkritisch, weil der ja "weiß", was er gesendet hat und nicht einfach
> das Empfangssignal wieder auf den Senderausgang schreibt.
> Aber _genau_ _letzteres_ tut ein passiver Koppler, der z.B. aus zwei
> Optokopplern mit ein bisserl Beschaltung besteht, und hält sich damit
> selber in einem (im dominanten) Zustand fest, so daß der
> _vorgeschaltete_ Sender nicht mehr mit einem anderen (rezessiven) Pegel
> durchkommt.
> Ist das so verständlich?

Warum die Phantasie dich in genau diese Schaltungstopologie mit den ihr 
innewohnenden Problemen leitet, kann ich ich ehrlich gesagt nicht verstehen.
> 
> BTW, genau dafür, diesem Problem abzuhelfen, gibt es die speziellen
> Buskoppler für diesen und andere Busse, die zudem meistens von
> vornherein auf die benötigten Geschwindigkeiten ausgelegt sind.

Vielleicht weisst Du auch einen lieferbaren Typen, der die beschrieben 
Anforderungen erfüllt? Das wäre eine Hilfe.

Gruß Udo

[toc] | [prev] | [next] | [standalone]

#314738

Am 30.11.21 um 09:46 schrieb Newdo:
> Am 29.11.2021 um 22:17 schrieb Sieghard Schicktanz:
>> Hallo Newdo,
>>
>> Du schriebst am Mon, 29 Nov 2021 13:22:46 +0100:
>>
>>>> ebenfalls. Nennt sich auch "Rückkopplung".
>>>
>>> Das ist das Prinzip des CAN-Busses, dass ein dominanter Pegel wenn er
>>
>> Rückkopplung ist ein Prinzip des CAN-Bus? Wäre mir neu.
> 
> Den Begriff hast _Du_ letztlich eingeführt.
> Das Prinzip ist, dass der Zustand des Busses direkt zurückgelesen wird. 
> Wer einen dominanten Zustand erzeugt hat, kann nicht entschieden werden.
> Wenn man in der Lage ist, das Prinzip auch über andere Medien 
> abzubilden, gibt es da kein Lock- oder Rückkopplungs- oder wie auch 
> immer genanntes Problem. Alle Macht geht vom CAN-Controller aus.


Bitte formuliere Deine Aufgabenstellung neu / eindeutig.
Entgegen der naheliegenden Interpretationsmöglichkeit der Ausgangsfrage 
geht es wohl nicht um eine galvanische Trennung der CAN-Bus-Leitung 
sondern einer Trennung zwischen Controller und Transceiver.
Beides ist möglich!
Ersteres (FAll1) dürfte nur 100% funktionieren wenn man es fest auf eine 
Baudrate auslegt, dafür muss man in die CAN-Nodes nicht eingreifen.
Der zweite Fall (FAll2) ist weniger abhängig von einer festgelegten 
Baudrate, dafür muss man die Node-Hardware anpassen.

>> Das ist schon richtig, und das ist bei einem _Controller_ auch
>> unkritisch, weil der ja "weiß", was er gesendet hat und nicht einfach
>> das Empfangssignal wieder auf den Senderausgang schreibt.
>> Aber _genau_ _letzteres_ tut ein passiver Koppler, der z.B. aus zwei
>> Optokopplern mit ein bisserl Beschaltung besteht, und hält sich damit
>> selber in einem (im dominanten) Zustand fest, so daß der
>> _vorgeschaltete_ Sender nicht mehr mit einem anderen (rezessiven) Pegel
>> durchkommt.
>> Ist das so verständlich?
> 
> Warum die Phantasie dich in genau diese Schaltungstopologie mit den ihr 
> innewohnenden Problemen leitet, kann ich ich ehrlich gesagt nicht 
> verstehen.

Das ist ein Fall1 Problem, tritt bei Fall2 natürlich nicht auf.

>> BTW, genau dafür, diesem Problem abzuhelfen, gibt es die speziellen
>> Buskoppler für diesen und andere Busse, die zudem meistens von
>> vornherein auf die benötigten Geschwindigkeiten ausgelegt sind.
> 
> Vielleicht weisst Du auch einen lieferbaren Typen, der die beschrieben 
> Anforderungen erfüllt? Das wäre eine Hilfe.

Deine Anforderungen (8Mbps Datenrate?) hast Du auch erst im Nachgang 
angedeutet, CAN FD kann auch niedrige Datenraten. Je höher die 
Datenrate, um so schärfer die Anforderungen.

Gerald

[toc] | [prev] | [next] | [standalone]

#314742

Am 02.12.2021 um 17:46 schrieb Gerald Oppen:
> 
> Bitte formuliere Deine Aufgabenstellung neu / eindeutig.
> Entgegen der naheliegenden Interpretationsmöglichkeit der Ausgangsfrage 
> geht es wohl nicht um eine galvanische Trennung der CAN-Bus-Leitung 
> sondern einer Trennung zwischen Controller und Transceiver.
> Beides ist möglich!

Die CAN-Datenleitungen des CAN-Controllers (RxD, TxD) sind auf HiPot und 
sollen _verstärkt isoliert_ an einem bestehenden (drahtgebundenen) CAN 
FD-Bus wirken. Und das mit 5-8Mbps Datenrate.

> Ersteres (FAll1) dürfte nur 100% funktionieren wenn man es fest auf eine 
> Baudrate auslegt, dafür muss man in die CAN-Nodes nicht eingreifen.
> Der zweite Fall (FAll2) ist weniger abhängig von einer festgelegten 
> Baudrate, dafür muss man die Node-Hardware anpassen.

Die Lösung muss mit variabler Baudrate arbeiten, bis zur angegebenen 
Obergrenze. Warum ist deiner Ansicht nach nur eine fixe Baudrate möglich?

>> Vielleicht weisst Du auch einen lieferbaren Typen, der die beschrieben 
>> Anforderungen erfüllt? Das wäre eine Hilfe.
> 
> Deine Anforderungen (8Mbps Datenrate?) hast Du auch erst im Nachgang 
> angedeutet, CAN FD kann auch niedrige Datenraten. Je höher die 
> Datenrate, um so schärfer die Anforderungen.

Das ist einer der Gründe, hier mal nachzufragen.
Wenn es physikalische Gründe für eine geringere Obergrenze gibt, dann 
muss ich mich damit abfinden.

Danke für's Mitdenken.

Gruß Udo

[toc] | [prev] | [next] | [standalone]

#314743

Am 02.12.21 um 18:28 schrieb Newdo:
> Am 02.12.2021 um 17:46 schrieb Gerald Oppen:
>>
>> Bitte formuliere Deine Aufgabenstellung neu / eindeutig.
>> Entgegen der naheliegenden Interpretationsmöglichkeit der 
>> Ausgangsfrage geht es wohl nicht um eine galvanische Trennung der 
>> CAN-Bus-Leitung sondern einer Trennung zwischen Controller und 
>> Transceiver.
>> Beides ist möglich!
> 
> Die CAN-Datenleitungen des CAN-Controllers (RxD, TxD) sind auf HiPot und 
> sollen _verstärkt isoliert_ an einem bestehenden (drahtgebundenen) CAN 
> FD-Bus wirken. Und das mit 5-8Mbps Datenrate.
> 
>> Ersteres (FAll1) dürfte nur 100% funktionieren wenn man es fest auf 
>> eine Baudrate auslegt, dafür muss man in die CAN-Nodes nicht eingreifen.
>> Der zweite Fall (FAll2) ist weniger abhängig von einer festgelegten 
>> Baudrate, dafür muss man die Node-Hardware anpassen.
> 
> Die Lösung muss mit variabler Baudrate arbeiten, bis zur angegebenen 
> Obergrenze. Warum ist deiner Ansicht nach nur eine fixe Baudrate möglich?
In Bezug auf Fall1:
Man muss erkennen auf welcher Seite der aktuelle Sender sendet und für 
ca. eine Bitzeit ("ca." weil u.a. Flankensteilheiten + Toleranzen 
berücksichtigt werden müssen) die Datenübertragungsrichtung freischalten 
um damit die Rückkopplung/Selbsthaltung zu vermeiden (Beide Seiten 
würden statisch in den dominaten Zustand gehen). Die Bitzeit hängt ja 
direkt an der Baudrate -> darum meine Aussage zu fixen Bitrate. Eine 
automatische Baudratenerkennung mit entsprechender Anpassung der obigen 
"Bitzeit" ist eventuell denkbar, aber zumindest nicht so trivial 
realisierbar wenn man gleichzeitig die Forderung erfüllen will dass kein 
Bit/Frame im Normalfall verloren gehen darf.
Anmerkung: Es geht hierbei um einen "passiven" Buskoppler - mit "passiv" 
in der Bedeutung von "es wird jedes Bit einzeln direkt übertragen". Der 
Buskoppler interessiert sich nicht für Bitkombinationen.
(D.h. passiv bedeutet hier nicht dass nur passive elektrische Bauteile 
verwendet werden.)
Im Gegensatz dazu könnte man das ganze auch aktiv als Gateway ausführen. 
Da wäre man dann frei in den Baudraten. Allerdings müssten man dann 
ganze CAN-Frames zwischenpuffern und wohl den vollständigen CAN-Stack 
implementieren. Dazu der Nachteil der Durchlaufverzögerungen.

>>> Vielleicht weisst Du auch einen lieferbaren Typen, der die 
>>> beschrieben Anforderungen erfüllt? Das wäre eine Hilfe.
>>
>> Deine Anforderungen (8Mbps Datenrate?) hast Du auch erst im Nachgang 
>> angedeutet, CAN FD kann auch niedrige Datenraten. Je höher die 
>> Datenrate, um so schärfer die Anforderungen.
> 
> Das ist einer der Gründe, hier mal nachzufragen.
> Wenn es physikalische Gründe für eine geringere Obergrenze gibt, dann 
> muss ich mich damit abfinden.
Steht und fällt vermutlich mit der Verfügbarkeit entsprechend schneller 
Optokoppler.

> Danke für's Mitdenken.

Gerne - musste mich mal mit der Problematik bzgl. Zusammenführung von 
HS- und LS-Can beschäftigen. Ob das bei Fall1 so auch für einen 
FD-CAN-Buskoppler funktionieren/gelten würde kann ich mangels Erfahrung 
nicht sagen. Vielleicht gibt es hier ja noch Anmerkungen oder bessere 
Lösungen dazu die ich nicht auf dem Schirm habe.

Gruß
Gerald

[toc] | [prev] | [next] | [standalone]

#314579

Was mich eher beschäftigt, ist die Frage nach zulässigen 
Verzögerungszeiten.

Ob man z.B. 10Mbps-Koppler bei 8Mbps Datenrate wegen der zu erwartenden 
Verzögerung ohne weiteres empfehlen kann.

Gruß Udo

[toc] | [prev] | [next] | [standalone]

#314584

Newdo <Newdo@ifmd.de> wrote:
> Was mich eher beschäftigt, ist die Frage nach zulässigen 
> Verzögerungszeiten.
> 
> Ob man z.B. 10Mbps-Koppler bei 8Mbps Datenrate wegen der zu erwartenden 
> Verzögerung ohne weiteres empfehlen kann.
> 
Schnelle Digitalisolatoren sind da vermutlich besser geeignet. 
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

[toc] | [prev] | [next] | [standalone]

#314602

Am 29.11.2021 um 15:05 schrieb Uwe Bonnes:
> Newdo <Newdo@ifmd.de> wrote:
>> Was mich eher beschäftigt, ist die Frage nach zulässigen
>> Verzögerungszeiten.
>>
>> Ob man z.B. 10Mbps-Koppler bei 8Mbps Datenrate wegen der zu erwartenden
>> Verzögerung ohne weiteres empfehlen kann.
>>
> Schnelle Digitalisolatoren sind da vermutlich besser geeignet.

Wenn sie
- lieferbar
- 600Vrms Arbeitspannung
- 5-8bps Datenrate aufweisen
- möglichst 2nd Source haben
gerne.

Es scheitert zur Zeit immer an mindestens einem Punkt.

Ideen hierzu sind immer willkommen.

Gruß Udo

[toc] | [prev] | [next] | [standalone]

#314620

Am 29.11.2021 um 23:34 schrieb Newdo:
> Am 29.11.2021 um 15:05 schrieb Uwe Bonnes:
>> Newdo <Newdo@ifmd.de> wrote:
>>> Was mich eher beschäftigt, ist die Frage nach zulässigen
>>> Verzögerungszeiten.
>>>
>>> Ob man z.B. 10Mbps-Koppler bei 8Mbps Datenrate wegen der zu erwartenden
>>> Verzögerung ohne weiteres empfehlen kann.
>>>
>> Schnelle Digitalisolatoren sind da vermutlich besser geeignet.
> 
> Wenn sie
> - lieferbar
> - 600Vrms Arbeitspannung
> - 5-8bps Datenrate aufweisen
> - möglichst 2nd Source haben
> gerne.
> 
> Es scheitert zur Zeit immer an mindestens einem Punkt.
> 
> Ideen hierzu sind immer willkommen.

Das einzige (zur Zeit) echte Problem dürfte die Verfügbarkeit sein...
Das betrifft auch nicht nur die Isolatoren :-(

Ansonsten gibt es geeignete Isolatoren von TI, AD und Skyworks (früher
Silicon Labs) - und in den meisten Fällen so kompatibel, das man bei
geeigneter Auswahl 2nd oder 3rd Source hat.

Hilft einem natürlich nicht, wenn keiner der drei vorgesehenen Typen
verfügbar ist...

Tilmann

[toc] | [prev] | [next] | [standalone]

#314623

On 11/30/21 3:31 PM, Tilmann Reh wrote:
> Am 29.11.2021 um 23:34 schrieb Newdo:
>> Am 29.11.2021 um 15:05 schrieb Uwe Bonnes:
>>> Newdo <Newdo@ifmd.de> wrote:
>>>> Was mich eher beschäftigt, ist die Frage nach zulässigen
>>>> Verzögerungszeiten.
>>>>
>>>> Ob man z.B. 10Mbps-Koppler bei 8Mbps Datenrate wegen der zu erwartenden
>>>> Verzögerung ohne weiteres empfehlen kann.
>>>>
>>> Schnelle Digitalisolatoren sind da vermutlich besser geeignet.
>>
>> Wenn sie
>> - lieferbar
>> - 600Vrms Arbeitspannung
>> - 5-8bps Datenrate aufweisen
>> - möglichst 2nd Source haben
>> gerne.
>>
>> Es scheitert zur Zeit immer an mindestens einem Punkt.
>>
>> Ideen hierzu sind immer willkommen.
> 
> Das einzige (zur Zeit) echte Problem dürfte die Verfügbarkeit sein...
> Das betrifft auch nicht nur die Isolatoren :-(
> 
> Ansonsten gibt es geeignete Isolatoren von TI, AD und Skyworks (früher
> Silicon Labs) - und in den meisten Fällen so kompatibel, das man bei
> geeigneter Auswahl 2nd oder 3rd Source hat.
> 
> Hilft einem natürlich nicht, wenn keiner der drei vorgesehenen Typen
> verfügbar ist...
> 
> Tilmann
> 

Einzige Bedingung ist, das die Verzögerung nicht zu groß ist - für Tx 
_und_ Rx zusammen. Wenn ein Sender seine eigenen Daten und ein Ack vom 
Empfänger nicht rechtzeitig sieht, muss er nach einigen solcher Fehler 
auf Störung gehen und die Füße vom Bus nehmen.
Mit den üblichen Isolatoren hab ich das schon (mit Erfolg) gemacht. Mit 
Optos ist es sportlich. Frag mich aber keiner, welche das waren, ist 
schon ~25y her.

-- 
Reinhardt

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | de.sci.electronics

csiph-web