Dass der S88 Bus Probleme haben kann ist ja durchaus bekannt. So ist seine Störanfälligkeit bei langen oder falsch verlegten Buskabel ein Problem, dass durchaus nerven und schwierig zu lösen ist.

Ich hatte solche Probleme nicht, hatte ich doch meine S88 Bus Kabel schön weit weg (über 20cm, nicht parallel verlegt) von anderen Leitungen verlegt, und auch ein abgeschirmtes Rundkabel verwendet. 

Dann habe ich meine Weichen und Signal Decoder neu verkabelt, ich wollte alle Decoder Anschlüsse an der vorderen Anlagen Kante haben, damit ich einen Decoder besser umprogrammieren kann, siehe auch hier. Leider begannen jetzt die Probleme auf dem S88 Bus, es zeigten sich wilde flackereien in der Steuerungssoftware, Blöcke wurden belegt, die gar nicht belegt waren, was zu völlig ausser Kontrolle geratenen Zugfahrten führten.

Als erstes habe ich gewisse S88 Bus Leitungen wieder verlegt und weiter von den nun neuen Decoder Zuleitungen entfernt, Ergebnis kaum besser.

Zweites war dann, die Decoder Zuleitungen in Alufolie einzuwickeln, also abzuschirmen. Ergebnis war schon besser, aber leider war immer noch kein reibungsloser Zugbetrieb möglich.

Als drittes dann der Versuch, die Bus Versorgungsspannung von 5V auf 12V zu heben. Meine Module liesen dies zu, hatten diese doch die benötigten IC Typen 40.. drauf. Und TAMS bietet einen S88 Booster an, der genau diese machen soll. Also einen solchen beschafft und zwischen HSI und dem ersten RM montiert. Die Freude war von sehr kurzer Dauer, gerade so lange wie es brauchte um eine Leiterbahn auf dem S88 Booster zu durchbrennen. Da hatte ich wohl in der Eile falsch angeschlossen. Die Anleitung war da aber auch nicht wirklich eine Hilfe. Also die Leiterbahn mit einer Litze repariert und den Anschluss umgekehrt. Doch auch diesmal rauchte es nur kurz, eine zweite Leiterbahn durchgebrannt. Was zum Henker läuft hier falsch, also weg mit dem Ding und wieder direkt am HSI angeschlossen.
Doch oh Schreck, nun hat auch dieser was abbekommen und war nicht mehr zu gebrauchen. (wurde übrigens von Littfinski bzw. dessem Nachfolger Bühler kostenlos repariert).

Nach Recherchen im Internet entschloss ich mich, den uCon S88 Masster von LS Digital (Bühler) zu erwerben. Dieser hat ebenfalls 3 Stränge für RM Module, verfügte aber über eine Hardware Seitige Entprellung mit Ein- und Ausschaltverzögerung, und konnte am Netzwerk angeschlossen werden, benötigte also keine Windows Treiber mehr.
"Leider" waren die 3 RM Stränge nur über die neuen S88-N Anschlüsse ausgeführt, so musste ich noch weitere RM Module kaufen, die eben über diesen Anschluss verfügen, und konnte die dazwischen bauen.

So weit alles gut, es funktionierte alles auf Anhieb, leider aber nicht wie gewünscht fehlerfrei. Nun zeigte sich zwar kein flackern mehr, allerdings blieben bestimmte RM plötzlich "hängen", was dazu führte, dass ein Block belegt blieb obwohl der Zug schon lange weiter war. Ein kurzzeitiges erneutes auslösen genügte und der RM war wieder frei. Doch dies konnte nicht die Lösung sein.

Es half alles nichts, es ging einfach nicht wie gewünscht. Ich habe dann mal test weise eine andere Steuerungs Software genommen, iTrain kann ganze 2 Monate kostenlos getestet werden. Sensationeller Support.
Und es funktionierte, kein Hänger, kein Prellen, kein flackern. Somit musste wohl TrainController das Problem sein.

Dank eines sehr netten und kompetenten Benutzer aus dem Stummi Forum, Dirk Nakott, welcher mich anschrieb, konnten wir mit aufwendiger Analyse des Netzverkehr feststellen (also die Analyse machte er, ich zeichnete nur den Netzverkehr auf), dass da Paket Verluste im UDP Verkehr waren. Nur warum reagierte dann iTrain anders als TC? Auch das lies sich anhand aufwendiger Analyse durch Dirk festlegen, iTrain initialisiert den uCon anders und reagierte auf Paketverluste, dies macht der TC aber nicht. Es stellte sich heraus, dass der Hersteller von TC, Jürgen Freiwald, offensichtlich nicht darüber informiert war, dass das Protokoll des uCon S88 Master erweitert wurde. Er hätte nun zuindest die Möglichkeit, durch Änderung der Software, auf Paketverluste zu reagieren. Ob er dies macht, bleibt offen, er zeigt sich dem UDP Protokoll von uCon gegenüber sehr skeptisch (allerdings verwendet die z21 auch ein solches, dazu meint er jedoch nichts).

Stellt sich immer noch die Frage, warum so viele Paketverluste auftreten. Da habe ich auf Hinweis von Dirk und anderen mal den Switch gewechselt. Also einen komplett anderern Switch, und an diesen nur noch den PC, die Zentrale Märklin CS3 sowie den uCon S88 Master, jeweils mit fester IP Adresse.
Und es treten keine Paketverluste mehr auf. Sobald ich die restliche Hausnetz Anlage wieder verbinde beginnt der Spuck von neuem. Es muss also im übrige Hausnetz ein Gerät sein, dass den UDP Verkehr stört. Bis jetzt hab ich da noch nicht weiter geforscht, denn mit isolieren des "Moba" Netzes läuft es ja. Un dem Moba PC habe ich einen USB WLAN Adapter spendiert, so kommt er ins Netz, kann Patche und SW Updates bekommen, stört aber den Modellbahn Betrieb nicht mehr.

Fazit: auch wenn es so aussieht, ist nicht immer die SW Schuld. Auch wenn TC da noch potential zur Verbesserung hat, bei einwandfreien HW Komponenten funktioniert es einwandfrei.