Serielle Interfaces

[Kalle]

Hi,

aufgrund von zwischendurch durchgefuehrten Testphasen mit meinem Interface an der seriellen Schnittstelle habe ich den Prozessor zwischendurch betreffend der Baudrate umprogrammiert und neben dem Betrieb mit 57600 Bd auch Versuche mit 9600 Bd und 19200 Bd. durchgefuehrt. Im Prinzip sind die Ansichten, eine hoehere Baudrate bringt viel Rueckmeldegeschwindigkeitszuwachs, ALLES GROSSER QUATSCH.  Spiele "Tango" auf der "s-88-Rueckmeldetastatur". Trotz groesserer Datenmengen sind Verzoegerungen auch bei 9600 Bd. nicht zu bemerken obwohl ich 52 Module mit je 16 Kontakten = 832 Kontakte abfrage und die Aenderungen an WDP uebermittle. Prinzipiell aehnlich einem schnellen Flackern. Schon 9600 Bd. als reine "Rueckmeldegeschwindigkeit" sind fuer eine groessere Anlage mit 31 Modulen eigentlich schon voellig ausreichend, wenn Verzoegerungen auftreten, dann im Millisekunden-Bereich, duerfte bei einer MoBa  keine Rolle spielen.
Was wohl bei einer hoeheren Baudrate sich verkuerzt ist die Uebertragungszeit pro Befehlsuebertragung, eigentlich nur ein Vorteil fuer Kombi-Zentralen mit s-88 und digitalen Lok- bzw. Weichensteuerungen, da ja noch Ein-Ausgabebefehle fuer die Lok-Weichen-Ansteuerungen hinzukommen.
Dass der PC oft mit Interfaces mehr oder weniger haengenbleibt, vermute ich mehr, in den, sage mal auf gut Deutsch, "beschissenen" Schaltungsauslegungen sog. profimaessig hergestellten Interfaces. Vernuenftig gemacht, es bleibt nichts haengen und stuerzt nichts ab, auch bei WDP und Train-Controller nicht.

[Friedel Weber]

Hallo Karl

Solche Beiträge finde ich immer "klasse":
Da geht mal jemand her und misst, wie es ist, statt "altbekannte Weisheiten" nachzuplappern.

Also halten wir "von nun an bis in Ewigkeit" fest, dass die Geschwindigkeit zwischen PC und HSI-88 mit 9600 Baud immer ausreicht und dass höhere Geschwindigkeiten zur Zentrale für die Rückmeldegeschwindigkeit nur dann Sinn machen, wenn eben kein HSI verwendet wird. Mir scheinen 57600 Baud dabei auch weit jenseits aller Notwendigkeiten zu liegen. Soweit - so beruhigend!

Mir fällt auf - oder täusche ich mich da? -, dass mit jedem Update von WDP die gesamte Steuerung schneller und präziser abläuft, als wenn die Entwickler da ständig an den "Optimierungsschräubchen" gedreht hätten. Meine Loks halten jetzt durchgängig immer schon auf den ersten Zentimetern der Stoppkontakte, die bei mir sowieso nur 15 cm kurz sind. Manchmal steht nur die erste Achse des vorderen Drehgestells auf dem Stoppkontakt und nach dessen Auslösung verschwindet oft die Belegtmeldung wieder, weil z. Bsp. das kleine Laufrad nicht ganz sauber ist. Ich stelle jetzt überall die Bremsgeschwindigkeit höher ein, sonst reicht der Schwung angesichts der schnellen Auslösung der Rückmelder gar nicht mehr, wenigstens 5 cm auf den Stoppkontakt zu fahren.

Ist der Eindruck richtig, dass es mehrfach deutliche Verbesserungen an der Reaktionsgeschwindigkeit von WDP gegeben hat?

Wenn es einen Engpass der Signalübertragung gibt, kann der doch eigentlich nur in der Digitalspannung selbst liegen.
Hast Du oder hat irgendwer sonst mal bei laufendem Betrieb mit einem "Oszilloguck" analysiert, was da so über das Gleis an "Telegrammen" läuft und wieviel freie Kapazität da noch ist?

Anhand der im Protokoll vorgegebenen Frequenz von Motorola oder DCC und der Länge eines Fahr- oder Schaltbefehls muss man doch ermitteln können, wieviele Befehle pro Sekunde im Maximum gesendet werden können, und wenn man da höher als ca. 80% kommt, gibt es sicher Warteschlangen. Hast Du eine Vorstellung, ob ein "normaler" Moba-Freak mit einer größeren Anlage - z. Bsp. 20 gleichzeitig fahrende Loks - in der Praxis da an Grenzen stößt?

Hat sonst jemand Erfahrungen damit?
Oder liegt die Grenze soweit draußen, dass wir alle beruhigt weiter schlafen können?

Viel Spaß mit der Moba in 2008 wünscht

Friedel Weber

www.moba-tipps.de

[Gian Bott]

Hallo,

Solche Beiträge finde ich immer "klasse":
Da geht mal jemand her und misst, wie es ist, statt "altbekannte Weisheiten" nachzuplappern.

.....und betätigt das schon immer gesagte (auch von Dr.Peterlin), dass nie die serielle Schnittstelle der Flaschenhals ist sondern die angeschlossene Zentrale und deren Verarbeitung der diversen Informationen (GBM, Weichenbefehle, Lokbefehle). Da nutzen 57600 Baud tatsächlich nichts, wenn die Daten von der Zentrale ganz langsam kommen. Auch steigt das Risiko mit 57600 Baud, dass sich eine schlecht konstruierte Schnittstelle, im PC oder im Interface der Zentrale, schlicht verhaspelt - bis zum Absturz. Darum benutze ich als Baudwert 19200 anstelle der möglichen 57600 Baud, so bin war ich schon immer auf der sicheren Seite (benutze aber auch nicht das HSI-88).

[

Mir fällt auf - oder täusche ich mich da? -, dass mit jedem Update von WDP die gesamte Steuerung schneller und präziser abläuft, als wenn die Entwickler da ständig an den "Optimierungsschräubchen" gedreht hätten.

Das ist keine Täuschung sondern Tatsache und für das Programm und die Entwicklern sprechend. Nur schlecht programmierte Software wird mit jedem Update langsamer und sperriger, im Vertrauen darauf, dass schnellere Prozessoren das wieder wettmachen.

mit freundlichen Grüssen

Gian

[Markus Herzog]

Hallo zusammen,

das deckt sich ja auch mit den Dingen, die immer wieder zum Baudratenwahnsinn predige z.B. in diesem Beitrag.

Wobei ich allerdings als Elektroingenieur der Meinung bin, dass es heute eigentlich kein Gerät mehr geben sollte, dass mit 9.600 Baud stabiler läuft als mit 115.200 Baud. Wenn doch haben die Entwickler gepennt, denn 115.200 Baud ist ja Standard. Die meisten Mikroprozessoren können auf ihrer seriellen Schnittstellen ohne Weiteres 3.000.000 Baud (nur die PCs halt nicht), dies setze ich beruflich schon seit Jahren zur Prozessorkommunikation teilweise mit einigen Meter langen ungeschirmten Dreidrahtleitungen.
Aber wie gesagt für die Moba braucht man das wohl nicht.

Nehmen wir nochmal Selektrix als Beispiel: Hier rolliert der Bus ~13mal pro Sekunde d.h. bei ständiger Änderung aller Adressleitungen würden dem PC 13(Bus-Rollierungen pro Sekunde)*16 bit (2 Byte pro Rückmeldung)*112 Adressen=23296 Bit/s übertragen. Und da dies ein Extrembeispiel ist und wohl nicht praxisrelevant, tun es auch locker 9600 Baud oder 19200 Baud. Ich persönliche nutze bei mir allerdings sogar die 57600 Baud ohne Probleme (Warum nicht 19200? Weil die Dipschalter beim Kauf schon auf 57600 standen ;-) ).

Grüße
Markus

[Kalle]

Hi,

Markus schrieb unter anderem:

..... dass es heute eigentlich kein Gerät mehr geben sollte, dass mit 9.600 Baud stabiler läuft als mit 115.200 Baud. Wenn doch haben die Entwickler gepennt, denn 115.200 Baud ist ja Standard.

denke mal, dass dieses Problem hauptsaechlich bei optisch isolierten Schnittstellen auftritt, insbesondere bei sehr sparsam ausgefuehrten Schaltungen. Dort wird die Stromversorgung fuer die LED´s der Optokoppler aus einer Signalspannung eines Schnittstellenpins gewonnen. Durch die internen Schaltungswiderstaende in den Schnittstellenbausteinen des z. B. PC´s ist der Strom begrenzt. Laienhaft mal weiter beschrieben: - Pufferelkos werden bei hoeheren Datengeschwindigkeiten oder Datenraten immer mehr entladen, der Schnittstellenpin kann aber nicht mehr Strom liefern und die Spannung der simplen Stromversorgung der LED´s bricht zusammen, wenn auch nur fuer kurze Augenblicke, dann gibt´s "Datenmuell". Dauert die hoehere Datenrate laenger an, reisst die Verbindung ab, da der in den Schnittstellen vorhandene UART-Baustein (Universal-Asynchronius-Receiver-Transmitter), ja nicht weiss was los ist, stellt eine Fehlfunktion in der Datenrate (da ja die Bit-Pegel und Bit-Zeiten sich nicht mehr normenkonform verhalten), fest und meldet dies dem PC-Controller oder wen sonst auch immer. Anschliessend bekommt das Programm die Fehlermeldung und teilt sich auf ueber dem Bildschirm dem Anwender mit. Klar, mit Pruefsummen oder sonstige Kontrollen kann man ein Programm veranlassen den Befehl zu wiederholen nutzt aber in den meisten Faellen nichts, da die Spannung immer wieder zusammenbricht. Ausserdem wuerde eine immer wiederkehrende oeftere Wiederholung die Schnittstelle wirklich stark ausbremsen.

@ Friedel,

mit meinem Standard-Guckiscope sehe ich bei den "Draht-Schwamm-Tests" eh nur Zacken. Da muesste schon etwas speicherndes her und dieses habe ich nicht. Aber man kann´s ja ungefaehr ausrechnen wie Markus es macht.

Gleiches gilt fuer die Digitalimpulse zum Gleis. Die Protokolle und Zeiten sind festgelegt, werden nacheinander gesendet, zwei Befehle parallel gleichzeitig geht seriell eh nicht. Es gibt protokollmaessige "Verschachtelungsmethoden", denke mal bei SX-Gleissignal ist es der Fall da die Datenmengen-Summe der Befehle und Daten immer konstant ist). Die Zeiten der Digitalsignale sind genormt - NMRA kucken.
Dies erklaert auch das DCC bei wenigen Fahrzeugen und Funktionen schneller ist als SX, ab einer bestimmten Anzahl von Befehlsuebertragungen dauert eine Befehlsperiode immer laenger und laenger, auch bedingt durch den Protokolloverhead - Präambel und Checksumme, welche bei jedem Befehl mit uebertragen werden und die Befehle immer nacheinander gesendet werden.
 

Man koennte die Digitalsignale von der Zentrale zum Gleis zeitlich kuerzen, es gibt dann neue Fehlerursachen weil hoehere Frequenz im Spiel ist und jede "Antennenanlage" - (Gleise der MoBa-Anlage) anders aufgebaut und unterschiedlich gross ist. Ausserdem wuerde das "Fernmeldeamt" -(unter neuem Namen irgendwas mit Bundesbehoerde), meckern.

[Frank Mondorf]

Hallo zusammen,

um die doch recht fragwürdigen Verallgemeinerungen vom S88-Interface auf andere Protokolle, Systeme und Schnittstellen ein wenig zu bremsen, hier eine gelungene Funktionsbeschreibung des S88 im saisonalem Design:

Viele Grüße
Frank

[Nohabfan (Wolfgang)]

Hallo Frank,

das ist echt stark! [/color]

Liebe Grüße

Wolfgang

[Dr. Jürgen Martin]

Hallo an die Spezialisten,
diesen Thread und vergleichbare habe ich die ganze Zeit nur aus theoretischem Interesse verfolgt. Aus konkretem Anlass habe ich aber jetzt zu den Ergebnissen eine direkte Frage.
Mein HSI-88 hat vor zwei Tagen den Geist aufgegeben. Ich weiß noch nicht warum, aber es muss wohl zur Reparatur. Ich hatte es mir ursprünlich nicht wegen der Möglichkeit mit den drei Strängen, sondern wegen der höheren Baud-Rate und der sofortigen Event-Verarbeitung gekauft. Die jetzige Diskussion lässt jedoch den Schluß zu, dass auch eine größere Anzahl von s88-Modulen auch ohne HSI ausreichend schnell abgefragt wird. Gibt den dann ein HSI-88 bei ca  20 s88-Modulen einen Sinn? Die Weichen und Signale werden bei mir über ein Märklin-Interface geschaltet und die Lok's fahren mit der Tams-MC (zur gleichen Zeit maximal ca. 15 Lok's aktiviert, also fahrend oder in Warteposition). Die s88-Module könnte man dann doch direkt an die Tams-MC anschließen. In der Zählweise der Module gäbe es  keine Änderung, weil die drei Stränge mit ihrem Modulen ohne Lücken hintereinander lagen. Das HSI war bzw. ist in PC-Nähe eingebaut und die Module befinden sich ausnahmslos alle nahe beim HSI (d.h. der Auwand, das HSI in Rente zu schicken, ist verhältnismäßig gering). Ich müsste nur die (bisherigen) drei Stränge in der richtigen Reihenfolge hintereinander hängen und das erste Modul direkt an der Tams-MC anschließen.
Oder habe ich etwas falsch interpretiert?
Allen einen guten Rutsch in das Jahr 2008

[Hans-Jürgen Mangelmann]

Hallo Dr. Martin,

schließen Sie die Module an die Tams-MC an. Sie können dort bis zu 48 Module je 8 RMK's anschließen.

Habe Sie das neueste Update (Beta-Version 1.4.4.b) installiert. Wenn nicht bitte nach holen. läuft sauber und stabil.

Wenn sie dabei die Reihenfolge nicht ändern, sollte alles klappen.

Gruß aus Berlin und guten Rutsch ins Neue Jahr

Hans

[Frank Mondorf]

Hallo Herr Dr. Martin,

ein HSI macht eine PC-Steuerung für reine WDP-Fahrer aus meiner Sicht einfacher, das es als isoliertes System für die Rückmeldung einfacher zu verstehen ist und im Falle einer Störung die Ursache einfacher zu ermitteln ist.

Die Vorteile die durch die 3 Stränge entstehen dürften bei 20 Modulen und zentraler Anordnung noch keine spürbare Rolle spielen:

Die durchschnittliche Verzögerung der Rückmeldung durch den S88-Bus liegt bei 20 8er Modulen bei ca 30 Millisekunden (schwankend um +/-100% je nach Eintreffen der Lok im RM-Bereich bzw. momentanem Zustand des Abfragezyklus).

Die theoretisch denkbare maximale Verbesserung um 20 ms auf 10 ms bei gleichmässiger Aufteilung auf 3 Stränge sollte keine praktische Bedeutung haben, da sie z.b. beim Stoppen der Lok aus 40km/h Langsamfahrt (~12cm/s) gerade mal durchschnittlich 2,4 mm (bzw. 4,8 mm Maximal) ausmacht.

Der Vorteil kürzerer und deswegen gegen ungünstige Bedingungen unempfindlicherer Clock-Leitungen im S88 Bus bei Aufteilung auf 3 Stränge spielt bei Ihrer zentralen Anordnung der Module keine Rolle.

Bis auf die meines Erachtens bessere Übersichtlichkeit und Wartbarkeit der Moba bei Verwendung eines HSI spricht im S88 selbst eigentlich nichts gegen die TAMS-Lösung.

Inwieweit die Rückmeldung für die TAMS eine zu nennenswerten Verzögerungen führende Last darstellt, kann ich mangels Kenntnis dieser DS nicht beziffern, halte das für unwahrscheinlich und habe auch diesbezüglich noch keine Klagen gehört oder gelesen.

Viele Grüße
Frank

[Dr. Jürgen Martin]

Hallo Hans und Frank,
besten Dank für die schnellen, klaren und kompetenten Antworten.
Das finde ich im Forum immer so toll, dass man mit den Antworten auch etwas anfangen kann.
Übrigens hatte ich die Version 1.4.4.b noch nicht auf der MC installiert. Das werde ich sofort machen.