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

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

Max3232 wird heiß

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

Contents

  Max3232 wird heiß stefan <adresse@ist.invalid> - 2022-08-06 10:07 +0200
    Re: Max3232 wird heiß Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-08-06 10:41 +0200
      Re: Max3232 wird heiß Uwe Borchert <wetterfrosch@yahoo.com> - 2022-08-06 11:57 +0200
        Re: Max3232 wird heiß Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2022-08-06 12:46 +0200
          Re: Max3232 wird heiß Uwe Borchert <wetterfrosch@yahoo.com> - 2022-08-07 10:50 +0200
        Re: Max3232 wird heiß Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-08-06 22:04 +0200
          Re: Max3232 wird heiß Uwe Borchert <wetterfrosch@yahoo.com> - 2022-08-07 11:01 +0200
    Re: Max3232 wird heiß Heinz Schmitz <HeinzSchmitz@kra.org> - 2022-08-06 11:45 +0200
      Re: Max3232 wird heiß Heinz Schmitz <HeinzSchmitz@kra.org> - 2022-08-06 12:16 +0200
        Re: Max3232 wird heiß stefan <adresse@ist.invalid> - 2022-08-06 12:35 +0200
        Re: Max3232 wird heiß Michael Schwingen <news-1513678000@discworld.dascon.de> - 2022-08-06 21:26 +0000
          Re: Max3232 wird heiß stefan <adresse@ist.invalid> - 2022-08-07 07:21 +0200
          Re: Max3232 wird heiß Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-08-07 20:28 +0200
            Re: Max3232 wird heiß Kurt <kurt.bindl@t-online.de> - 2022-08-07 22:17 +0200
            Re: Max3232 wird heiß Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-08-08 17:21 +0200
              Re: Max3232 wird heiß Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-08-08 18:29 +0200
              Re: Max3232 wird heiß Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-08-08 20:39 +0200
                Re: Max3232 wird heiß Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2022-08-09 00:35 +0200
                Re: Max3232 wird heiß Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-08-10 11:34 +0200
                  Re: Max3232 wird heiß Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-08-10 11:48 +0200
                    Re: Max3232 wird heiß Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2022-08-10 12:14 +0200
                      Re: Max3232 wird heiß Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-08-10 13:23 +0200
                      Re: Max3232 wird heiß Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2022-08-10 17:59 +0200
                        Re: Max3232 wird heiß Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-08-10 18:48 +0200
                        Re: Max3232 wird heiß Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2022-08-10 19:31 +0200
                Re: Max3232 wird heiß Reinhardt Behm <rbehm@hushmail.com> - 2022-08-10 13:41 +0000
              Re: Max3232 wird heiß Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2022-08-09 00:33 +0200
                Re: Max3232 wird heiß Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2022-08-09 14:32 +0200
                  Re: Max3232 wird heiß stefan <adresse@ist.invalid> - 2022-08-09 17:47 +0200
                    Re: Max3232 wird heiß Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2022-08-09 19:36 +0200
                      Re: Max3232 wird heiß stefan <adresse@ist.invalid> - 2022-08-09 19:55 +0200
                        Re: Max3232 wird heiß Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-08-09 21:08 +0200
                          Re: Max3232 wird heiß "Wolfgang Allinger" <all2001@spambog.com> - 2022-08-09 16:44 -0400
                          Re: Max3232 wird heiß stefan <adresse@ist.invalid> - 2022-08-10 17:37 +0200
                            Re: Max3232 wird heiß Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2022-08-10 18:09 +0200
                              Re: Max3232 wird heiß stefan <adresse@ist.invalid> - 2022-08-10 19:25 +0200
                              Re: Max3232 wird heiß Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-08-11 21:13 +0200
                            Re: Max3232 wird heiß Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-08-10 20:55 +0200
                    Re: Max3232 wird heiß Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-08-09 21:09 +0200
                  Re: Max3232 wird heiß Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2022-08-09 19:54 +0200
                    Re: Max3232 wird heiß stefan <adresse@ist.invalid> - 2022-08-09 20:56 +0200
                  Re: Max3232 wird heiß "Wolfgang Allinger" <all2001@spambog.com> - 2022-08-09 16:17 -0400
                Re: Max3232 wird heiß Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-08-13 12:41 +0200
        Re: Max3232 wird heiß Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-08-08 17:27 +0200
          Re: Max3232 wird heiß Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-08-08 18:38 +0200
      Re: Max3232 wird heiß stefan <adresse@ist.invalid> - 2022-08-06 12:23 +0200
        Re: Max3232 wird heiß Hartmut Kraus <hartmut.melina@web.de> - 2022-08-06 13:52 +0200
          Re: Max3232 wird heiß stefan <adresse@ist.invalid> - 2022-08-06 14:38 +0200
    Re: Max3232 wird heiß Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-08-06 18:32 +0200
      Re: Max3232 wird heiß stefan <adresse@ist.invalid> - 2022-08-06 18:55 +0200
        Re: Max3232 wird heiß Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-08-06 19:04 +0200
          Re: Max3232 wird heiß stefan <adresse@ist.invalid> - 2022-08-06 19:10 +0200
            Re: Max3232 wird heiß Gerald Oppen <Gerald.Oppen@web.de> - 2022-08-08 02:39 +0200
              Re: Max3232 wird heiß stefan <adresse@ist.invalid> - 2022-08-08 13:27 +0200
                Re: Max3232 wird heiß Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-08-08 20:43 +0200
    Re: Max3232 wird heiß Kurt <kurt.bindl@t-online.de> - 2022-08-07 21:38 +0200
      Re: Max3232 wird heiß stefan <adresse@ist.invalid> - 2022-08-08 13:36 +0200
        Re: Max3232 wird heiß Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2022-08-08 15:18 +0200
          Re: Max3232 wird heiß stefan <adresse@ist.invalid> - 2022-08-08 17:06 +0200
            Re: Max3232 wird heiß Michael Schwingen <news-1513678000@discworld.dascon.de> - 2022-08-12 13:38 +0000
              Re: Max3232 wird heiß stefan <adresse@ist.invalid> - 2022-08-12 16:51 +0200

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#324852

Am 10.08.22 um 11:48 schrieb Gerrit Heitsch:

> Hm? Du meinst hier 57600? Das kann jeder im PC verbaute UART der den 
> Default-Takt von 1.8432 MHz bekommt, so üblich seit dem Ur-PC. Das 
> Maximum damit ist 115200.

Der UART ja, der Rest des Systems nicht unbedingt.
Spätestens, wenn mehrere serielle Schnittstellen parallel und spontan 
Daten mit hoher Baudrate empfangen müssen, laufen sehr schnell die 
Puffer über und/oder oder die kranke Interrupt-Logik der 
IBM-PC-Architektur reagiert zu träge, um alle Ports rechtzeitig zu bedienen.


> Eine gute Geschwindigkeit zum Steuern und Überwachen sind 9600.

Ja.

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

#324853

On 8/10/22 12:14, Hergen Lehmann wrote:
> Am 10.08.22 um 11:48 schrieb Gerrit Heitsch:
> 
>> Hm? Du meinst hier 57600? Das kann jeder im PC verbaute UART der den 
>> Default-Takt von 1.8432 MHz bekommt, so üblich seit dem Ur-PC. Das 
>> Maximum damit ist 115200.
> 
> Der UART ja, der Rest des Systems nicht unbedingt.
> Spätestens, wenn mehrere serielle Schnittstellen parallel und spontan 
> Daten mit hoher Baudrate empfangen müssen, laufen sehr schnell die 
> Puffer über und/oder oder die kranke Interrupt-Logik der 
> IBM-PC-Architektur reagiert zu träge, um alle Ports rechtzeitig zu 
> bedienen.

Zumindest 1 Port sollte er aber können, das bekam selbst ein Amiga mit 
68000 @ 7 MHz gerade so eben hin.

Wobei schon seit ein paar Jahren die UARTs auf Steckkarten oder dem 
Mainboard alle mindestens einen 16550A nachbilden und der hat 16 Bytes 
FIFO für Sender und Empfänger. Da stellt man den Triggerlevel auf 8 
Bytes und hat dann 8 Bytes Zeit die Daten abzuholen. Die Nachfolger 
haben mehr FIFO, gesehen habe ich bis 128 Bytes.

  Gerrit

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

#324868

On 8/10/22 12:14 PM, Hergen Lehmann wrote:
> Am 10.08.22 um 11:48 schrieb Gerrit Heitsch:
> 
>> Hm? Du meinst hier 57600? Das kann jeder im PC verbaute UART der den 
>> Default-Takt von 1.8432 MHz bekommt, so üblich seit dem Ur-PC. Das 
>> Maximum damit ist 115200.
> 
> Der UART ja, der Rest des Systems nicht unbedingt.
> Spätestens, wenn mehrere serielle Schnittstellen parallel und spontan 
> Daten mit hoher Baudrate empfangen müssen, laufen sehr schnell die 
> Puffer über und/oder oder die kranke Interrupt-Logik der 
> IBM-PC-Architektur reagiert zu träge, um alle Ports rechtzeitig zu 
> bedienen.

Die ersten PC schafften nicht einmal einen verlustfreien 9600 Baud 
Eingang, wenn nebenher etwas auf dem Bildschirm ausgegeben wurde. Für 
das Bildschirm-Update wurden die Interrupts abgeschaltet, auf die 
Bildaustastlücke gewartet, dann ein paar Pixel upgedatet, usw. bis das 
Update komplett war. Erst dann wurden die Interrupts wieder freigegeben. 
Dageben half kein Software-Cache, und UARTs mit FiFo gab es anscheinend 
noch nicht, oder sie waren zu teuer.

Damals (1987) half nur die Programmierung in GW-Basic, das erlaubte 
sogar eine graphische live Darstellung der eintrudelnden Messwerte. 
Unsere Testfahrer (Beifahrer) konnten am Laptop die interessierenden 
Signale verfolgen und rechtzeitig die Start- und Stop-Taste für die 
Abspeicherung (auf RAM-Disk) drücken. Dann ein Boxenstop zur 
Abspeicherung auf Diskette, und die nächste Fahrt konnte beginnen.

DoDi

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

#324872

On 8/10/22 17:59, Hans-Peter Diettrich wrote:
> On 8/10/22 12:14 PM, Hergen Lehmann wrote:
>> Am 10.08.22 um 11:48 schrieb Gerrit Heitsch:
>>
>>> Hm? Du meinst hier 57600? Das kann jeder im PC verbaute UART der den 
>>> Default-Takt von 1.8432 MHz bekommt, so üblich seit dem Ur-PC. Das 
>>> Maximum damit ist 115200.
>>
>> Der UART ja, der Rest des Systems nicht unbedingt.
>> Spätestens, wenn mehrere serielle Schnittstellen parallel und spontan 
>> Daten mit hoher Baudrate empfangen müssen, laufen sehr schnell die 
>> Puffer über und/oder oder die kranke Interrupt-Logik der 
>> IBM-PC-Architektur reagiert zu träge, um alle Ports rechtzeitig zu 
>> bedienen.
> 
> Die ersten PC schafften nicht einmal einen verlustfreien 9600 Baud 
> Eingang, wenn nebenher etwas auf dem Bildschirm ausgegeben wurde. Für 
> das Bildschirm-Update wurden die Interrupts abgeschaltet, auf die 
> Bildaustastlücke gewartet, dann ein paar Pixel upgedatet, usw. bis das 
> Update komplett war.

Nicht wenn man eine CGA-Karte benutzt hat. Die hat einfach geschrieben. 
Deshalb gab es beim Update auch den berühmten Schnee, die CPU hatte 
Vorrang vor dem Videocontroller.


  Erst dann wurden die Interrupts wieder freigegeben.
> Dageben half kein Software-Cache, und UARTs mit FiFo gab es anscheinend 
> noch nicht, oder sie waren zu teuer.

Nein, der 16550 kam meiner Erinnerung nach etwas später und der komplett 
funktionierende 16550A noch einen Tick später.

  Gerrit

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

#324876

Am 10.08.22 um 17:59 schrieb Hans-Peter Diettrich:

> On 8/10/22 12:14 PM, Hergen Lehmann wrote:
>> Der UART ja, der Rest des Systems nicht unbedingt.
>> Spätestens, wenn mehrere serielle Schnittstellen parallel und spontan 
>> Daten mit hoher Baudrate empfangen müssen, laufen sehr schnell die 
>> Puffer über und/oder oder die kranke Interrupt-Logik der 
>> IBM-PC-Architektur reagiert zu träge, um alle Ports rechtzeitig zu 
>> bedienen.
> 
> Die ersten PC schafften nicht einmal einen verlustfreien 9600 Baud 
> Eingang, wenn nebenher etwas auf dem Bildschirm ausgegeben wurde. Für 
> das Bildschirm-Update wurden die Interrupts abgeschaltet, auf die 
> Bildaustastlücke gewartet, dann ein paar Pixel upgedatet, usw. bis das 
> Update komplett war. Erst dann wurden die Interrupts wieder freigegeben. 
> Dageben half kein Software-Cache, und UARTs mit FiFo gab es anscheinend 
> noch nicht, oder sie waren zu teuer.

Einer meiner ersten entlohnten Programmierjobs noch während des Studiums 
war, das doch irgendwie zum Laufen zu bringen, und zwar auf acht Ports 
mit 9600-19200Baud gleichzeitig.

Zum Glück setzte der Kunde Hercules-Karten ein (die hatten das Problem 
mit der Austastlücke nicht), aber es mussten am Ende neben der 
eigentlichen Puffer-Logik auch Teile des BIOS in Assembler neu 
geschrieben werden, weil insbesondere der sehr hoch priorisierte 
Tastatur-Interrupt zu lange brauchte...

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

#324859

On Mon, 8 Aug 2022 20:39:51 +0200, Sieghard Schicktanz wrote:

> Hallo Rolf Bombach,
> 
> Du schriebst am Mon, 8 Aug 2022 17:21:51 +0200:
> 
>> > Die minimale Amplitude am Empfänger (!) ist schon seit Anbeginn der
>> > Gültigkeit des Standards per Definition +-3V.
>> 
>> Am Sender allerdings ±5 V an 3 kOhm. Das wird dann etwas sportlich für
>> einen Chip an 5 V ohne Ladungspumpe.
>> Wie da 2 V im Kabel abhanden kommen soll, keine Ahnung, ist halt
>> Toleranzreserve.
> 
> Du kennst aber den Zustand der elektrischen und
> kommunikationstechnischen Verkabelung in Usanien, auch und evtl. sogar
> vor allem im angehenden Industriezeitalter? Und das im Zusammenhang mit
> den dort normalen Entfernungen von ein paar 100km, mit "ein paar" aus
> [3...9] und drüber?

RS232 sagt max 50 Fuß Leitung.

-- 
Reinhardt

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

#324772

Am 08.08.22 um 17:21 schrieb Rolf Bombach:

> Sieghard Schicktanz schrieb:
>> Die minimale Amplitude am Empfänger (!) ist schon seit Anbeginn der
>> Gültigkeit des Standards per Definition +-3V.
> 
> Am Sender allerdings ±5 V an 3 kOhm. Das wird dann etwas sportlich für
> einen Chip an 5 V ohne Ladungspumpe.
> Wie da 2 V im Kabel abhanden kommen soll, keine Ahnung, ist halt 
> Toleranzreserve.

Das Problem bei RS232 ist die Kombination aus:
- geringem Treiberstrom (selbst der MC1488 lieferte nur 10mA, der 
MAX2323 schafft weniger als 2mA bevor der Sendepegel zu klein wird),
- Kapazitätsbelag des Kabels,
- großem erforderlichen Spannungshub am Empfänger,
- Empfindlichkeit gegenüber Störeinflüssen.

Die Flanken werden sehr schnell rund, und wenn dann zu wenig 
Pegelreserve da ist, wird das Signal nicht mehr sicher erkannt.

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

#324798

On 8/9/22 12:33 AM, Hergen Lehmann wrote:
> Am 08.08.22 um 17:21 schrieb Rolf Bombach:
> 
>> Sieghard Schicktanz schrieb:
>>> Die minimale Amplitude am Empfänger (!) ist schon seit Anbeginn der
>>> Gültigkeit des Standards per Definition +-3V.
>>
>> Am Sender allerdings ±5 V an 3 kOhm. Das wird dann etwas sportlich für
>> einen Chip an 5 V ohne Ladungspumpe.
>> Wie da 2 V im Kabel abhanden kommen soll, keine Ahnung, ist halt 
>> Toleranzreserve.
> 
> Das Problem bei RS232 ist die Kombination aus:
> - geringem Treiberstrom (selbst der MC1488 lieferte nur 10mA, der 
> MAX2323 schafft weniger als 2mA bevor der Sendepegel zu klein wird),
> - Kapazitätsbelag des Kabels,
> - großem erforderlichen Spannungshub am Empfänger,
> - Empfindlichkeit gegenüber Störeinflüssen.
> 
> Die Flanken werden sehr schnell rund, und wenn dann zu wenig 
> Pegelreserve da ist, wird das Signal nicht mehr sicher erkannt.

Ich weiß nicht, wieviel sich daran in den letzen Jahrzehnten geändert 
hat. In den 80ern waren die Empfängerbausteine TTL-kompatibel. Wir haben 
ein dickes Kabel für 13 Kanäle quer durch Institut und Maschinenhalle 
gezogen und damit allerlei Gerätschaften mit 9600 Baud an unsere 
pdp-11/34 angeschlossen. U.a. ein dummes DVM mit TTL Shift-Registern 
aufgebohrt zur seriellen Übertragung der Ziffern. Das hat jahrelang 
problemlos funktioniert, auch wenn im Keller die MW Motoren mit 
Thyristorsteuerung rauf- und runtergefahren wurden.

DoDi

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

#324807

Am 09.08.2022 um 14:32 schrieb Hans-Peter Diettrich:
> On 8/9/22 12:33 AM, Hergen Lehmann wrote:
>> Am 08.08.22 um 17:21 schrieb Rolf Bombach:

...
>> Das Problem bei RS232 ist die Kombination aus:
>> - geringem Treiberstrom (selbst der MC1488 lieferte nur 10mA, der 
>> MAX2323 schafft weniger als 2mA bevor der Sendepegel zu klein wird),
>> - Kapazitätsbelag des Kabels,
>> - großem erforderlichen Spannungshub am Empfänger,
>> - Empfindlichkeit gegenüber Störeinflüssen.

fehlende galvanische Trennung zwischen Sender und Empfänger
kein definierter Wellenwiderstand und keine Terminatoren am Kabelende

>>
>> Die Flanken werden sehr schnell rund, und wenn dann zu wenig 
>> Pegelreserve da ist, wird das Signal nicht mehr sicher erkannt.
> 
> Ich weiß nicht, wieviel sich daran in den letzen Jahrzehnten geändert 
> hat. In den 80ern waren die Empfängerbausteine TTL-kompatibel. Wir haben 
> ein dickes Kabel für 13 Kanäle quer durch Institut und Maschinenhalle 
> gezogen und damit allerlei Gerätschaften mit 9600 Baud an unsere 
> pdp-11/34 angeschlossen. U.a. ein dummes DVM mit TTL Shift-Registern 
> aufgebohrt zur seriellen Übertragung der Ziffern. Das hat jahrelang 
> problemlos funktioniert, auch wenn im Keller die MW Motoren mit 
> Thyristorsteuerung rauf- und runtergefahren wurden.

Wir hatten an der Uni in den 90ern VT100 und neuere Terminals per TTY 
mit PDPs und VAX verbunden. Da war an den Terminals jeweils ein Umsetzer 
von TTY zu RS232 und im Rechnerraum ein größerer Kasten mit dem 
Gegenstück für die PDPs und die VAX.

Probleme mit RS232 gab es durchaus wenn die Leitungen zu lang wurden und 
wenn Sender und Empfänger an unterschiedlichen Stromkreisen 
angeschlossen waren. Da war aber auch irgendwas mit der Elektrik bei uns 
im Labor faul. Teilweise konnte man 110V AC auf Stahlgerüsten messen. 
Wenn man da angefasst hat hat es aber nur wenig gekribbelt.

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

#324814

On 8/9/22 5:47 PM, stefan wrote:

> Wir hatten an der Uni in den 90ern VT100 und neuere Terminals per TTY 
> mit PDPs und VAX verbunden. Da war an den Terminals jeweils ein Umsetzer 
> von TTY zu RS232 und im Rechnerraum ein größerer Kasten mit dem 
> Gegenstück für die PDPs und die VAX.

Falls Du mit TTY current-loop meinst, dann wäre das doch für eure 
Anwendung genau das richtige gewesen?

DoDi

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

#324818

Am 09.08.2022 um 19:36 schrieb Hans-Peter Diettrich:
> On 8/9/22 5:47 PM, stefan wrote:
> 
>> Wir hatten an der Uni in den 90ern VT100 und neuere Terminals per TTY 
>> mit PDPs und VAX verbunden. Da war an den Terminals jeweils ein 
>> Umsetzer von TTY zu RS232 und im Rechnerraum ein größerer Kasten mit 
>> dem Gegenstück für die PDPs und die VAX.
> 
> Falls Du mit TTY current-loop meinst, dann wäre das doch für eure 
> Anwendung genau das richtige gewesen?
> 
> DoDi

Was meinst du jetzt?

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

#324826

Hallo stefan,

Du schriebst am Tue, 9 Aug 2022 19:55:49 +0200:

> > Falls Du mit TTY current-loop meinst, dann wäre das doch für eure 
> > Anwendung genau das richtige gewesen?
> > 
> > DoDi
> 
> Was meinst du jetzt?

20mA-Stromschleife, in Usanien als "TTY"-Anschluß bekannt, hierzulande
eben Stromschleife und von anglophilen Leuten wörtlich dorthin
übersetzt.

-- 
(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]

#324831

On 09 Aug 22 at group /de/sci/electronics in article 20220809210820.7abc6961bde937dea8234cbe@SchS.de
<Sieghard.Schicktanz@SchS.de>  (Sieghard Schicktanz)  wrote:

> Hallo stefan,

> Du schriebst am Tue, 9 Aug 2022 19:55:49 +0200:

>>> Falls Du mit TTY current-loop meinst, dann wäre das doch für eure
>>> Anwendung genau das richtige gewesen?
>>>
>>> DoDi
>>
>> Was meinst du jetzt?

> 20mA-Stromschleife, in Usanien als "TTY"-Anschluß bekannt, hierzulande
> eben Stromschleife und von anglophilen Leuten wörtlich dorthin
> übersetzt.

Jein, TTY kenne ich mit bis zu 80mA Stromschleife 110Bd (konnte man an  
einer Teletype ASR33 ein/umschalten). Haben die USAnier für TTY übern  
ganzen Kontinent benutzt. die Teletypes sind dann als Terminals für die 1.  
Prozessrechner/Compuster PDP11, hp21xx, AEG60/10, Tandem und was weiss ich  
noch alles eingestzt worden.

20mA CL ist dann eben 20mA CL! oder 20mA TTY !!

Die Boards in der PDP11/34 konnten rund 2o-25mA senden, aber auch 80mA  
empfangen. Musste halt 1 Widerling umgelegt werden.

Danch kamen dann die VT52 mit 9600Bd in Mode.
WIMRE konnten die VT52 auch 80mA CL.

Übrinx, die VT52 hatten mechanische Klick Tastaturen, jedenfalls solange  
sie eingeschaltet waren. Die ham nen mittleres (größer als ein damaliges  
KFZ) Relais ohne Kontaktsatz (also nur mit Klappanker) unter die  
Klapperaturplatine gesetzt. Bei jedem eingegebenen Zeichen das Relais  
befeuert und es prellte einem der Anker dann die Fingerspitzen :)
Ohne Power waren die Tasten schwabelig, ohne Druckpunkt und Klick!!

Manche Kiste Bier für diesen Nachweis (durch Ausbau des Gehäuses) gewonnen  
:)

Faszinierend (Spock)



Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

-- 
Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

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

#324864

Am 09.08.2022 um 21:08 schrieb Sieghard Schicktanz:
> Hallo stefan,
> 
> Du schriebst am Tue, 9 Aug 2022 19:55:49 +0200:
> 
>>> Falls Du mit TTY current-loop meinst, dann wäre das doch für eure
>>> Anwendung genau das richtige gewesen?
>>>
>>> DoDi
>>
>> Was meinst du jetzt?
> 
> 20mA-Stromschleife, in Usanien als "TTY"-Anschluß bekannt, hierzulande
> eben Stromschleife und von anglophilen Leuten wörtlich dorthin
> übersetzt.
> 

Meine Frage war eher, was du mit "eure Anwendung" meinst.

Die Anwendung hatte ich nämlich nicht beschrieben.

Es geht dabei um vernetzte Mikrocontrollersysteme.

Dazu wird die TXD* Leitung der Hauptbaugruppe mit der RXD* Leitung der 
ersten Erweiterungsbaugruppe verbunden. Deren TXD* Leitung geht dann 
entweder an die nächste Erweiterungsbaugruppe oder zurück zu 
Hauptbaugruppe. Also eine klassische Ringschaltung. Die zu übertragende 
Datenmenge ist sehr gering.

In diesen Ring kann man auch einen RS232 zu Ethernet-Adapter (Moxa) 
schalten um das ganze dann mit einen PC übers Netz fernsteuern zu 
können. Vorgesehen waren noch Barcodeleser und Etikettendrucker, aber da 
wurden nur einige Prototypen gebaut. Aber dafür wurde RS232 gebraucht.

Ich hatte ursprünglich tatsächlich TTY vorgesehen und sowohl RS232 als 
auch TTY Anschlüsse auf den Baugruppen.

Das wäre wirklich ideal gewesen, wäre aber für meinen Kunden zu 
kompliziert geworden. Und da alle Erweiterungsbaugruppen sowieso in 
demselben Gehäuse verbaut wurden haben wir dann die RS232 Variante 
gewählt und irgendwann neue Erweiterungen nur noch mit RS232 aufgebaut.

Bei anderen Projekten mit mehreren vernetzten Microcontrollern und 
größeren Leitungslängen habe ich solche Ringnetzte mit TTY laufen, 
teilweise sind die seit mehr als 30 Jahren in Betrieb und laufen 
praktisch störungsfrei.

Vielleicht hätte ich bei dem System auf den sich meine Frage bezog doch 
dabei bleiben sollen ;-)

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

#324869

On 8/10/22 5:37 PM, stefan wrote:
> Am 09.08.2022 um 21:08 schrieb Sieghard Schicktanz:

>> 20mA-Stromschleife, in Usanien als "TTY"-Anschluß bekannt, hierzulande
>> eben Stromschleife und von anglophilen Leuten wörtlich dorthin
>> übersetzt.
>>
> 
> Meine Frage war eher, was du mit "eure Anwendung" meinst.
> 
> Die Anwendung hatte ich nämlich nicht beschrieben.

Das Fehlerbild hat schon gereicht. Eine Stromschleife (current loop) ist 
viel störsicherer und paßt sich auch an lange Leitungen an - ganz im 
Gegensatz zur Spannungsschnittstelle RS-232 bzw. V-24.

DoDi

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

#324873

Am 10.08.2022 um 18:09 schrieb Hans-Peter Diettrich:
> On 8/10/22 5:37 PM, stefan wrote:
>> Am 09.08.2022 um 21:08 schrieb Sieghard Schicktanz:
> 
>>> 20mA-Stromschleife, in Usanien als "TTY"-Anschluß bekannt, hierzulande
>>> eben Stromschleife und von anglophilen Leuten wörtlich dorthin
>>> übersetzt.
>>>
>>
>> Meine Frage war eher, was du mit "eure Anwendung" meinst.
>>
>> Die Anwendung hatte ich nämlich nicht beschrieben.
> 
> Das Fehlerbild hat schon gereicht. Eine Stromschleife (current loop) ist 
> viel störsicherer und paßt sich auch an lange Leitungen an - ganz im 
> Gegensatz zur Spannungsschnittstelle RS-232 bzw. V-24.
> 
> DoDi

Absolut richtig, aber leider haben PCs nun mal RS232.

Das Eingangs beschriebene Problem hat aber wohl nichts mit der 
Kabellänge zu tun. Das tritt auf, wenn wir eine einzelne Baugruppe über 
ein 2m langes Kabel mit der Com-Schnittstelle eines PCs verbinden. Diese 
Schnittstelle am PC ist offenbar defekt. Wie und warum kann ich noch 
nicht erklären.

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

#324939

Hallo Hans-Peter Diettrich,

Du schriebst am Wed, 10 Aug 2022 18:09:44 +0200:

> im Gegensatz zur Spannungsschnittstelle RS-232 bzw. V-24.

Standardgemäß heißen die beiden Standards AFAIK "RS 232" (Usa,
Organisation weiß ich grad nicht) und "V.24" (ITU, AFAIR). Die
enthalten beide sehr viel mehr als das, was von IBM damals für die PCs
daraus implementiert wurde, u.a. eine komplette zweite Schnittstelle
für Überwachungs- und Betriebsfunktionen.

-- 
(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]

#324890

Hallo stefan,

Du schriebst am Wed, 10 Aug 2022 17:37:16 +0200:

> >>> DoDi
> >>
> >> Was meinst du jetzt?
> > 
> > 20mA-Stromschleife, in Usanien als "TTY"-Anschluß bekannt,
...
> Meine Frage war eher, was du mit "eure Anwendung" meinst.

Habe ich nicht gefragt. Du wendest Dich an den Falschen.

> Die Anwendung hatte ich nämlich nicht beschrieben.

Das hatte ich gemerkt.

> Es geht dabei um vernetzte Mikrocontrollersysteme.
> 
> Dazu wird die TXD* Leitung der Hauptbaugruppe mit der RXD* Leitung
> der ersten Erweiterungsbaugruppe verbunden. Deren TXD* Leitung geht
> dann entweder an die nächste Erweiterungsbaugruppe oder zurück zu 
> Hauptbaugruppe. Also eine klassische Ringschaltung. Die zu
> übertragende Datenmenge ist sehr gering.

Iiigittt! Ein Pseudo-Bus aus dafür völlig ungeeigneten und definitiv
nicht vorgesehenen Komponenten.
Das sticht ja noch die I2C-Bus-Verkabelung von Schaltschränken für die
Beschallungstechnik von Siemens aus, insbes. weil das ja definitiv ein
proprietäres Protokoll verwenden muß.
Aber klar, es gibt keine wirkliche Absicherung gegen mißbräuchliche
Verwendung irgendwelcher Sachen (gleich welcher Art).

-- 
(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]

#324827

Hallo stefan,

Du schriebst am Tue, 9 Aug 2022 17:47:25 +0200:

> angeschlossen waren. Da war aber auch irgendwas mit der Elektrik bei
> uns im Labor faul. Teilweise konnte man 110V AC auf Stahlgerüsten
> messen. Wenn man da angefasst hat hat es aber nur wenig gekribbelt.

Kein Potentialausgleich zwischen den Gebäuden insgesamt und spezifisch
innerhalb dieses Gebäudes.

-- 
(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]

#324821

Am 09.08.22 um 14:32 schrieb Hans-Peter Diettrich:

> On 8/9/22 12:33 AM, Hergen Lehmann wrote:
>> Das Problem bei RS232 ist die Kombination aus:
>> - geringem Treiberstrom (selbst der MC1488 lieferte nur 10mA, der 
>> MAX2323 schafft weniger als 2mA bevor der Sendepegel zu klein wird),
>> - Kapazitätsbelag des Kabels,
>> - großem erforderlichen Spannungshub am Empfänger,
>> - Empfindlichkeit gegenüber Störeinflüssen.
>>
>> Die Flanken werden sehr schnell rund, und wenn dann zu wenig 
>> Pegelreserve da ist, wird das Signal nicht mehr sicher erkannt.
> 
> Ich weiß nicht, wieviel sich daran in den letzen Jahrzehnten geändert 
> hat. [...]

Tendenziell eher zum negativen.
Die modernen Treiber haben weniger "wumms", um gegen den Kapazitätsbelag 
anzukämpfen. Die Baudraten sind wesentlich höher. Jede Menge anderer 
Digitalkram sorgt für einen hohen Störpegel in Kabelkanälen. Und der 
Geiz sorgt für allerhand fantasievolle Implementierungen, die unter 
suboptimalen Bedingungen komische Dinge tun.

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web