[suffix]

[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
(Die nicht nur Traffic auf dem Gleisbus verursacht, sondern auch eine Menge Rechenleistung verlangt. Aus diesem Grund - und weil Rocrail mit Server-Client-Architektur arbeitet - kann man mit überschaubarer Rechnerleistung unter Rocrail eine Show wie MiniWorld Lyon steuern; mit TC oder WDP und im PC errechneten Bremskurven käme man schnell an die Grenzen des Rechners.)
[/quote]

Das halte ich für ein starkes Gerücht. Jeder halbwegs aktuelle Rechner hat massiv massiv mehr GOPS als für so etwas benötigt. Verglichen mit den Tasks die heutige Rechner sonst so stemmen müssen ist das absolute Pillepalle (letztendlich lineare Interpolation - was genau soll da einen Rechner an die Grenzen bringen??).

[Erich Müller]

Hallo Florian,

kennst du Mini-World? Oder wie kommst du zu diesem Urteil?

[suffix]

Hä? Wieso muss ich diese Anlage/Park für meine Aussage kennen?

- Ich weiss was aktuelle Rechner leisten können (GOPS oder ähnliche Kennwerte)
- Ich kenne die mathematische Komplexität (wenn man dieses Wort hier überhaupt benutzen darf) von Bremskurven

Das reicht aus um sagen zu können, dass du einen aktuellen Rechner niemals nimmer mit der Berechnung von Bremskurven an seine Leistungsgrenze bringen kannst. Da müsste man schon extrem schlechten Code schreiben, und das wäre dann auch nicht die Schuld vom Rechner/einer nicht vorhandenen Komplexität dieser Aufgabe. Wir sind nicht mehr in den 80ern. Heute könnte dir ein Rechner auch in Sekundenbruchteilen ein Routing von mehreren Zügen auf grösseren Anlagen errechnen, optimiert nach definierbaren Kriterien.

Wenn schon dann scheitert die Aufgabe am Durchsatz des - nach heutigen Standards - sehr sehr langsam Moba-Busses (Bereich kbit/s, egal welches konkrete Bussystem).

[Erich Müller]

Hallo Florian!

Schön. Du weißt also nicht, wovon die Rede ist.
Auch meist gepflegten Umgangsformen hast du Nachholbedarf - hier ist es üblich, zu grüßen und nicht mit "Hä?“ daherzupoltern.

Da aber das eine wie das andere bestenfalls äußerst am Rande mit dem C-Digital-System zu tun hat, lassen wir es am besten auf sich beruhen.

[Martin_G]

Grüß dich Erich,

Nichts zu Danken, gerne geschehen.
[quote="Erich Müller" post_id=1830032 time=1525687079 user_id=26147]
Martin, noch einmal vielen Dank für deine Reaktionen.
Neben der anderen Informationsübertragung, die Klaus noch einmal angesprochen hat, sehe ich da auch viel mehr "Intelligenz" in den Decodern, jedenfalls verglichen mit den handelsüblichen Decodern der marktbeherrschenden Systeme.[/quote]
Also ich glaube ich weiß schon, was du damit meinst und aus deiner Sicht sieht es evtl. auch etwas so aus, als wäre da "mehr Intelligenz" in meinen Decodern. Ich bin mir da nicht sicher und sehe das ein wenig differenzierter:
Bei meinen Decodern sind manche Dinge -wie sage ich's am besten- vielleicht "vollständiger/kompletter" umgesetzt und auch das stimmt nur begrenzt.

• Meine Motorregelung ist wohl aufwändiger und konsequenter umgesetzt als die meisten anderen, -auch wegen der autom. Konfiguration und der Anpassung an eisenkernlose Motoren.
• Die Einstellmöglichkeiten bei der Fahrstufenkurve und deren Anzahl fällt bei meinen Decodern deutlich geringer aus als bei anderen (außer D&H), dafür habe ich noch die aufwändigere Einstellung der Beschleunigungskurve und diese beiden Themen konsequent getrennt.
• Ein wirklicher Unterschied ergibt sich bei der Einstellbarkeit des autom. Haltens. Die Stärke des adaptiven Bremsens, die Anhalteweglänge (auch zu jeder FS einzeln, wenn man will) und die Entscheidung, ob immer gleichen Weg oder Bremskrafverlauf lässt sich einstellen. DCC Decoder haben da deutlich weniger und auch nur, wenn diese ABC oder so etwas können.
• Beim Funktionsumfang und Mapping ist mein Decoder doch nur Durchschnitt, denke ich. Alleine schon, weil ich keinen Sound unterstütze und auch aktuell "nur" 16 Funktionen gesendet werden. Andere Decoder liefern hier doch doppelt so viel?
• Thema Multiprotokoll, was für einen Decoder keinen unmerklichen Posten darstellt, gibt es bei mir logischerweise auch garnicht.
• Was die Decoder-Rückmeldung angeht, haben meine Decoder momentan die Nase leicht vorne, denke ich. :

Letztendlich möchte ich meinen, gibt es keinen wirklichen Unterschied zwischen den "Intelligenzgraden" zwischen meinen und anderen Decodern. Der Fokus liegt teilweise wo anders und folglicherweise auch das Quantum an mehr "Intelligenz".
Punkt1 geht in vielen Fällen wahrscheinlich an mich.
Punkt2 ausgeglichen
Punkt3 geht an mich
Punkt4 geht an andere
Punkt5 geht an andere
Punkt6 geht wahrscheinlich an mich oder eben ausgeglichen.
--------------------------------------
Das sieht doch ziemlich ausgeglichen aus, oder?

[quote="Erich Müller" post_id=1830032 time=1525687079 user_id=26147]
Und deine Decoder legen da noch wieder einiges an Können drauf.
[/quote] Wie gesagt, tun sie dass wahrscheinlich am Ende gar nicht wirklich.

[quote="Erich Müller" post_id=1830032 time=1525687079 user_id=26147]
Über Geld redet man nicht, man hat es, sagt der Volksmund - aber: ist das denn finanziell halbwegs machbar, zumal bei den kleinen Stückzahlen, die für C-Digital produziert werden können?
[/quote]
Das ist wiederum interessanter und ein ganz anderes (leidliches) Thema.
Ich hatte es ja schon einmal erwähnt, dass das bei mir/uns momentan so ausgelegt ist, dass am Ende eine Nullrechnung herauskommt. Gewinne machen wir keine. Ich muss nur darauf achten, dass ich nicht draufzahle - oder zumindest sehr geringfügig.
Aus meiner Sicht ergibt sich für mich folgende Situation:
Wenn ich an meinem Hobby ohne eigene Digitalprodukte auskommen möchte, kostet mich das eine Stange Geld -wirklich nicht wenig- und manche Wünsche und Vorstellungen blieben sogar unerfüllt. Manche Dinge genügen auch nicht ganz meinen persönlichen Ansprüchen.
Dem gegenüber steht das Weiterbauen und Entwickeln der eigenen schon existierenden Digitalprodukte. Da bleibt auch einiges an Geld, was so oder so ins Hobby fließen würde, das man auch in Entwicklungen stecken kann.
Da der Kundenkreis gering ist, gibt es auch keine "Massenproduktion", wo man eben mal für einen höheren 3stelligen oder 4stelligen €-Bereich größere Stückzahlen an Komponenten komplett fertigen lässt. (Für geringe Stückzahlen gibt es keine komplette Fertigung.)
Sollte es aufeinmal mehr Kunden und wirkliche Interessenten geben, müssten wir erst auf eine gewisse Zahl sicherer Abnehmer warten, um dann komplett industriell fertigen zu lassen.

Für mich privat ist es jedoch auch ein großer "Luxus", das eigene Digitalsystem zu nutzten. Wenn ich für mich privat eine Kleinigkeit irgendwo doch etwas anders haben will, programmiere ich mir das eben um oder baue es etwas anderes . Außerdem bleibt mir der Spaß an der ganzen Sache des Entwickelns und Gestaltens.

Grüße,
Martin

[suffix]

[quote="Erich Müller" post_id=1830367 time=1525733565 user_id=26147]
Hallo Florian!

Schön. Du weißt also nicht, wovon die Rede ist.
Auch meist gepflegten Umgangsformen hast du Nachholbedarf - hier ist es üblich, zu grüßen und nicht mit "Hä?“ daherzupoltern.

Da aber das eine wie das andere bestenfalls äußerst am Rande mit dem C-Digital-System zu tun hat, lassen wir es am besten auf sich beruhen.
[/quote]

Jesses. Entschuldige diese absolut grobe Ausdrucksweise.

Hallo Erich, sei herzlich gegrüsst. So okay? Ansonsten kannst auch du ja was sachliches schreiben und mir erklären worin mein Irrtum besteht.

Ich habe hier nochmal deinen ursprünglichen Beitrag zitiert, auf den ich mich beziehe. Und meiner bescheidenen Meinung nach behauptest du hier ganz klar, dass "Fahrstufenkurven und Ortsberechnung" [..] "eine Menge Rechenleistung verlange[n]".

[quote="Erich Müller" post_id=1830367 time=1525733565 user_id=26147]
Wenn man aber, wie Rocrail und wie Klaus das für C-Digital parallel auch dargestellt hat, mit mehreren Meldepunkten je Abschnitt arbeitet, dann braucht man diese berechnete Ortsbestimmung gar nicht: am ersten Melder im Abschnitt wird der Lok ein Langsamfahrbefehl gegeben, u.u. durch einen oder mehrere weitere(n) Melder noch mal abgestuft (1.Melder 60, 2.Melder 30) und am letzten Melder Haltbefehl gegeben. Das System ist sicher und zuverlässig und nicht auf die Fahrstufenkurve und die Ortsberechnung angewiesen. (Die nicht nur Traffic auf dem Gleisbus verursacht, sondern auch eine Menge Rechenleistung verlangt. Aus diesem Grund - und weil Rocrail mit Server-Client-Architektur arbeitet - kann man mit überschaubarer Rechnerleistung unter Rocrail eine Show wie MiniWorld Lyon steuern; mit TC oder WDP und im PC errechneten Bremskurven käme man schnell an die Grenzen des Rechners.)
Diese Zwei- bzw. Drei-Melder-Technik funktioniert aber auch mit andren Programmen. Sie hat noch dazu den großen Vorteil, dass Gastlokomotiven ohne zeitraubendes Einmessen sofort in Betrieb genommen werden können.
[/quote]

Was habe ich nun falsch verstanden?

[Martin_G]

Hallo Florian,

Ich weiß jetzt nicht, über welches Fachwissen du genau verfügst, also sieh es mir bitte nach, wenn ich hier und da etwas schreibe, was dir eh klar ist.

Zitat

---

- Ich weiss was aktuelle Rechner leisten können (GOPS oder ähnliche Kennwerte)
- Ich kenne die mathematische Komplexität (wenn man dieses Wort hier überhaupt benutzen darf) von Bremskurven

---

Da du über Fachkenntnisse verfügst, möchte ich dich daran erinnern, dass die Softwares auf den Rechnern, die für den Consumer-Markt gefertigt werden, nicht direkt auf der Maschine laufen. Da sind zig Ebenen dazwischen, die die eigentliche, physische Rechenleistung enorm herabsetzen. Sieh dir nur einmal an wie langsam manche Smartphones oder Tabletts werden, wenn da ein paar "lächerliche" Apps drauf laufen. Oder nimm einen simplen Primzahlrechner (in der Console, also nur rechenen, kaum Grafik) und schau dir an wie schnell die CPU-Auslastung enorm zunimmt.
Die verbauten CPUs und RAMs könnten eigentlich viel viel mehr, nur sind diese schon mit zahlreichen Aufgaben gut beschäftigt. (BUS-Kommunitkation zw. verschiedenen Hardwarekomponenten und das über mehrere Ebenen usw. und dann auch noch der ganze grafische Schnick-Schnack und die Sicherungen/Gewährleistungen nicht zu vergessen. Ein iOS will ja sicher laufen...)
Es hat schon seinen Grund, wesshalb bei Anwendungen, wo es auf echtes Real-Time-Tasking ankommt, man keinen einfachen Rechner (aus dem Consumer-Bereich) hinstellt, der diese Aufgaben übernehmen soll.

Zitat

---

Das reicht aus um sagen zu können, dass du einen aktuellen Rechner niemals nimmer mit der Berechnung von Bremskurven an seine Leistungsgrenze bringen kannst.

---

Das ist doch eigentlich nur eine Frage, wie oft dieser Rechenprozess annähernd gleichzeitig ausgeführt werden muss. Vielleicht gerät ein Rechner erst ab mehreren Tausend gleichzeitig ausgeführten Berechnungen in die Bredoullie, aber dass es "niemals nimmer" möglich ist, glaube ich nicht .
Du meintest wahrscheinlich so eine Berechnung alleine - das stimmt natürlich!

Zitat

---

Heute könnte dir ein Rechner auch in Sekundenbruchteilen ein Routing von mehreren Zügen auf grösseren Anlagen errechnen, optimiert nach definierbaren Kriterien.

---

Das wiederum ist auch eine Frage der Komplexität des Routings und wie hoch die Anzahl "mehreren" denn am Ende wirklich ist, bzw. max. sein darf (dann sieht man natürlich noch einen Puffer von 20 bis 30% vor).
Eine 100%ige Auslastung ist doch im Übrigen nicht bei 100%ger Auslastung einer Maschine gegeben, sondern bei etwa 80%.

Zitat

---

Wenn schon dann scheitert die Aufgabe am Durchsatz des - nach heutigen Standards - sehr sehr langsam Moba-Busses (Bereich kbit/s, egal welches konkrete Bussystem).

---

Ja, das ist der wohl wichtigste Punkt an der ganzen Sache, - die Aus- bzw. Überlastung des Datenbus, wenn man für jede Lok einzeln einen kompletten Bremsweg in Echtzeit berechnen lässt. Denn diese Info muss durch alle Ebenen hindurch bis zum einzelnen Lok-Decoder.

Also ein BUS kann doch nur so schnell sein, wie die Komponenten, die diesen aufbauen. Außerdem ist die mögliche Geschwindigkeit am Ende auch von der Verdrahtung/dem Medium abhängig.
Ich sehe es ebenso wie du, dass man darauf achten sollte, dass eine Zentrale einen hohen Durchsatz ermöglichen kann. Für mich stellt ein zusätzlicher Rechner mit Software hinter der Zentrale auch eben nur ein "Steuergerät" dar.
Die Zentrale muss in der Lage sein, das hohe Datenaufkommen zu verarbeiten.
Über LAN/W-LAN oder Bluetooth ergeben sich so Übertragungsraten von bis zu 4Mbit/s (bei mir). Man darf aber nicht vergessen, dass hier bei diesen "großen" Protokollen einiges an Sicherung usw. mitgeschickt wird und es demzufolge einen relativ großen "Overhead" gibt. Betrachtet man nur die Nutzdaten am Ende, so ergibt sich etwa nur noch ein 4tel der Übertragungsrate für die reinen Nutzdaten (960 kbit/s bis 1.1Mbit/s).

Da aber kein Mensch überall auf seiner Anlage Zentralen (embedded Rechner) verbauen will, muss der BUS Anwendungsspezifisch angepasst (abgestuft) werden, welcher von der Zentrale dann eine Kommunikation mit anderen Hardwarekomponenten ermöglicht (bei mir Zentrale -> CAN -> ...).
Man könnte sich das metaphorisch wie einen Baum vorstellen:
- Der Breite highspeed BUS ist der Stamm, wo die Zentrale sitzt und alles zusammenläuft.
- Die Wurzeln sind zahlreiche Eingabekomponenten, -je wichtiger, desto dicker.
- Vom Stamm geht es dann weiter über größere, dickere Äste, mit niedrigerem "Traffic"
- bis in die kleinsten und feinsten Äste, wo nur noch ein Bruchteil des "Traffic" vorhanden ist und auch nicht mehr benötigt wird, wenn man es "richtig" macht.

Das wiederum ist eben auch ein sehr wichtiger Punkt, den ich hier schon angesprochen habe:
Die unterschiedlichen Astdicken kann man in einzelne Ebenen zusammenfassen. Für diese Ebenen sollte man streng darauf achten, dass Informationen nur dort zur Verfügung stehen, in welchen diese auch benötigt werden und gehören.
Dann ergibt sich automatisch ein hoher Datendurchsatz, der nur von der "Dicke des Stamms", also der Zentrale und dessen Bus-Speed abhängig ist. Obwohl der Traffic in den anderen Ebenen deutlich langsamer ist, ist dieser für die Information noch bei weitem schnell genung und kann mit relativ günsitger, unkomplizierter Hardware aufgebaut werden. Außerdem ist die Verdrahtung bei diesen Geschwindigkeiten (z.B. seriell 19200) ziemlich robust gegen Störungen trotz ihrer Einfachheit.

Ach was ich noch sagen wollte:
Am Ende ist nicht direkt die Übertragungsgeschwindigkeit und die GOPS entscheident, sonder was "hinten raus kommt" , wie man so schön sagt.
Eine schnelle Übertragung (Protokoll) mag toll sein, muss man allerdings in Relation zu den Nutzdaten sehen, gerade was auch den Overhead angeht. (und Berücksichtigung des Mediums nicht vergessen)
Ein BUS wie CAN, der sowohl in Automobilen, als auch in einem komplexen technischen System wie einem Flugzeug genügt, sollte das doch auch bei der Modellbahn alle mal tun.

Gruß,
Martin

[suffix]

Hallo Martin,

vielen Dank für deine Antwort und dass du verstehst um was es mir geht. Mal vorneweg, ich verfolge C-Digital und die Diskussion hier schon seit längerem und bin wie andere ziemlich begeistert was du auf die Beine gestellt hast. Vor allem würde mich eine Doku zum "neuen" C-Digital interessieren die insbesondere auf die Rückmeldemöglichkeiten eingeht. Logischerweise verstehe ich dein Zeitproblem voll und ganz - also keine Eile.

Zum Thema Rechenleistung. Da stimme ich dir natürlich in allen Punkten zu. Allerdings bin ich schon der Meinung, dass man auch auf halbwegs aktuellen Betriebssystemen einigermassen effizienten "Bare-Metal" Code schreiben kann, trotz allem Scheduling und Ressource-Management seitens OS. Ansonsten würden ja sämtliche rechenintensive Tasks moderner Software die sich nicht auf die GPU auslagern lassen eine Ewigkeit dauern. Und ein H.264-Video ist nun wirklich eine ganz andere Hausnummer als eine Bremskurve... Dass dabei ab und zu mal höheren Latenzen entstehen weil sich das OS entschieden hat, grade einem anderen Thread CPU Zeit zu geben ist klar. Und die gängige Lösung dazu ist eben nun mal low-level real-time embedded OS.

Ich denke das ist aber ein generelles Problem und hat nichts mit der Komplexität von Bremskurven zu tun. Ich habe es nicht ausgerechnet, wage aber mal zu behaupten, dass folgendes Szenario mit halbwegs aktuellen Rechnern und sauberer Implementierung problemlos machbar ist:

1) Sammle alle Adressen, die im nächsten Digitalbus-Refresh-Zyklus ein Update benötigen
2) Frage CPU Zeit an
3) Rechne alle Fahrstufen aus
4) Schicke diese zur Digitalzentrale

Ich wage mal kühn zu behaupten, dass der obige Vorgang auch mit vielen vielen Adressen hinreichend schnell zwischen zwei Refresh-Zyklen ausgeführt werden kann. Sollte das mal nicht klappen, da wir wahrscheinlich bei 2) etwas warten müssen, klappt es beim nächsten mal und zumindest für den Betrachter der Anlage sollte es unbeachtet bleiben (da Refresh-Zyklus Grössenordnung ms).

Und mal ehrlich, die eigentliche Berechnung in Punkt 3) ist nun wirklich - bei jeder einigermassen realistischen Zahl an Adressen - für die CPU Pillepalle.

Gehen wir mal von einer extremen Anlage mit 1000 gleichzeitig aktiven Fahr-Adressen aus. Ich glaube kaum, dass das irgendwo erreicht wird, nicht mal im MiWuLa. Dann ist doch in jedem Digital-System der Refresh-Zyklus bereits so lang (Grössenordnung Sekunden), dass eine feinfühlige, reaktive Steuerung auf welche Art auch immer gar nicht mehr möglich ist. Klar, das Decoder-lokale Anhalten ist immer noch flüssig, aber das System als Ganzes ist nicht mehr reaktiv und damit schwer benutzbar - eine Unterteilung in mehrere Untersysteme mit Adress-Handover beim Überfahren von Grenzen ist dann wohl angebracht.

Und das war eigentlich meine ursprüngliche Aussage, dass in so einem System wohl kaum der Desktop-Rechner der limitierende Faktor ist.

[Martin_G]

Hallo Florian,

Danke für die Lorbeeren für C-Digital. Schön, dass es dich interessiert und begeistert . Die nächste Zeit (halbes Jahr?) habe ich leider wenig Zeit zum Entwickeln und damit auch für die Dokus.

Zitat

---

Allerdings bin ich schon der Meinung, dass man auch auf halbwegs aktuellen Betriebssystemen einigermassen effizienten "Bare-Metal" Code schreiben kann, trotz allem Scheduling und Ressource-Management seitens OS.

---

Der Meinung bin ich auch. Es ist nur die Frage, ob die verschiedenen Steuerungssoftwares auch so geschrieben werden? Das glaube ich leider weniger, da man sonst auch alles andere "zu Fuß" programmieren müsste. Wenn ich mir die Layouts mancher Mobasoftware anschaue, so meine ich deutlich zu sehen, dass da vieles aus nem "Baukasten" stammt. Wer sollte da dann schon jedes Fenster, Button, Schieber, Dropdown-List usw. von Hand programmieren?
Eine andere Möglichkeit ist "Bare-Metal" Code einzuflechten, der eben nicht von einem OS abhängig ist, sondern mehr oder weniger direkt auf der Maschine läuft. Da bin ich mir auch nicht sicher, ob das jemand macht. Aber klar ginge das.

Zitat

---

Dass dabei ab und zu mal höheren Latenzen entstehen weil sich das OS entschieden hat, grade einem anderen Thread CPU Zeit zu geben ist klar. Und die gängige Lösung dazu ist eben nun mal low-level real-time embedded OS.

---

Ganz genau. Die OS auf dieser "hohen" Ebene, erlauben einem keine wirklich zeitkritischen Tasks. Mit einem embedded OS oder ganz ohne sieht es da schon anders aus.
Ich wollte mal auf einem embedded PC (ARM A mit Windows CE als OS einen Port in 100us getacktet schalten. Es ist mir nicht geglückt, da es immer wieder zu Latenzen kam. Das schnellste, was möglich war, war 1ms, obwohl schnelleres physisch locker leicht möglich ist. Ohne OS ist das alles kein Problem. Jeder kleine uC kann die Sys.Clock auf einen Port geben, - und da ist man dann ja im ns-Bereich.
Je komplexer diese Systeme sind, desto schwieriger/unmöglicher wird es Realtime-Tasks ablaufen zu lassen.

Übrigens, werden häufig zeitkritische Tasks, wie z.B. das Encodieren von Audio-Streams (ac3, dts,...) wegen der zeitkritischen Thematik, auf eigenen hardwareimplementierten Chips vollzogen. Danach kann die CPU dann einen gepufferten Packet-Stream abfragen und die Info weiterverwenden. Gerade im Bereich Audio können sich bereits Latenzen im ms-Bereich deutlich auswirken. (Audio und Video Encoding ist auch immer gepuffert)

Zitat

---

Ich denke das ist aber ein generelles Problem und hat nichts mit der Komplexität von Bremskurven zu tun.

---

Ja. Und ich glaube, dass das Erich auch nicht so gemeint hat, auch wenn man das aus seinem Text lesen kann, zumal er ja auch von der Verzögerung bei der Übertragung geschrieben hat.
Die Berechnung mehrerer Bremskurven stellt für keinen Rechner ein wirkliches Problem dar, solange die Software über eine konkrete Ausgangssituation bescheid weis. Da ein Rechner über massig Speicher verfügt, könnte man diese sogar abspeichern und für ein passendes Szenario immer wieder verwenden, anstatt jedes Mal neu berechenen zu müssen.

Zitat

---

Ich habe es nicht ausgerechnet, wage aber mal zu behaupten, dass folgendes Szenario mit halbwegs aktuellen Rechnern und sauberer Implementierung problemlos machbar ist:

1) Sammle alle Adressen, die im nächsten Digitalbus-Refresh-Zyklus ein Update benötigen
2) Frage CPU Zeit an
3) Rechne alle Fahrstufen aus
4) Schicke diese zur Digitalzentrale

Ich wage mal kühn zu behaupten, dass der obige Vorgang auch mit vielen vielen Adressen hinreichend schnell zwischen zwei Refresh-Zyklen ausgeführt werden kann. Sollte das mal nicht klappen, da wir wahrscheinlich bei 2) etwas warten müssen, klappt es beim nächsten mal und zumindest für den Betrachter der Anlage sollte es unbeachtet bleiben (da Refresh-Zyklus Grössenordnung ms).

---

Das meine ich auch. Aber auch hier muss ich sagen, dass das Problem des Refresh ab einer größeren Anzahl an Loks, wohl zu einem Versatz beim Haltepunkt führt. Da hilft es einem dann natürlich nicht viel, wenn die Daten zum Bremsen zwar berechnet vorliegen, jedoch nicht rechtzeitig zur Lok gelangen. Also haben wir wieder den BUS als Flaschenhals.

Zitat

---

Und mal ehrlich, die eigentliche Berechnung in Punkt 3) ist nun wirklich - bei jeder einigermassen realistischen Zahl an Adressen - für die CPU Pillepalle.

---

Ja, va. wenn man hier und da auch mal etwas speichert und linear bremst...
Das ganze wird etwas schwieriger, wenn die Bremskurve nicht linear verläuft (sigmodial) und man ausgehend von der Anfangsgeschwindigkeit so eine Kurve aufstellen muss, dann die Umkehrfunktion benötigt und die Ableitung, damit man auf den Zeitverlauf beim Bremsen kommt.
Aber auch so eine Berechnung, würde ich für jede FS einmal machen und das Ergebnis speichern. Dann braucht man nur noch einen Faktor zum Skalieren, um einen betrieblichen Versatz zu berücksichtigen.

Zitat

---

Gehen wir mal von einer extremen Anlage mit 1000 gleichzeitig aktiven Fahr-Adressen aus. Ich glaube kaum, dass das irgendwo erreicht wird, nicht mal im MiWuLa. Dann ist doch in jedem Digital-System der Refresh-Zyklus bereits so lang (Grössenordnung Sekunden), dass eine feinfühlige, reaktive Steuerung auf welche Art auch immer gar nicht mehr möglich ist. Klar, das Decoder-lokale Anhalten ist immer noch flüssig, aber das System als Ganzes ist nicht mehr reaktiv und damit schwer benutzbar - eine Unterteilung in mehrere Untersysteme mit Adress-Handover beim Überfahren von Grenzen ist dann wohl angebracht.

---

Wahrscheinlich ist das so, da habe ich zu wenig Detailwissen. Aber genau das, dass die Systeme wegen der Aus- bzw. Überlastung des BUS, dann nicht mehr reaktiv sind ist ja das Problem.
Ich umgehe das einwenig, indem ich so eine Struktur verwende, wie ich es dir mit der Baum-Metapher geschildert habe.
So kann es halt noch zu Latenzen (400 bis 800ms) bei der händischen Steuerung bei Funktionsbetätigung kommen. Das denke ich ist aber ein sehr geringes Übel. Viel wichtiger sind eben Fahr- und v.a. Halt-Befehle, weil es da oft auf einen bestimmten Punkt beim Halten ankommt. Man darf ja auch nicht vergessen, dass es mit der Sendung der Information an die Lok noch nicht vorbei ist, diese muss die Sendung auch noch korrekt empfangen. Setzt man hier eine schlechte Quote von 50% bis 75% an, verzögert sich das ganze noch deutlicher.

Zitat

---

Und das war eigentlich meine ursprüngliche Aussage, dass in so einem System wohl kaum der Desktop-Rechner der limitierende Faktor ist.

---

Ja, natürlich nicht. Die zugrundeliegende Topologie ist das größte Problem. Das ist es ja auch, was ich hier schon mehr mals klar machen wollte. Eine zentrale "Intelligenz" = Rechner mit Software, die alles handeln soll, - an der dann über virtual serial oder W-Lan ein Protokollumsetzter hängt und fertig - , ist in der mir bekannten Form nicht sehr leistungsfähig.
Entweder man setzt dann auf ein mehr "dezentrales" Netz, wo best. Informationen nur in bestimmten Ebenen verfügbar sind, oder man benützt einen viel schnelleren BUS, was zu den Problemen führt die ich dir in meinem vorigen Post schon geschrieben habe.
Außerdem kann man auch Sendungen priorisiert erfolgen lassen. Damit kann ich z.B. sicherstellen, dass bei 100 Loks die alle gleichzeitig eine Sache aktualisiert brauchen, es max. ~700ms dauert, bis die Lok diese Info hat. Damit liege ich noch relativ weit unter 1s und die Wahrscheinlichkeit, dass das bei 100 Loks gleichzeitig auftritt ist sehr sehr gering.

Eine andere mögliche Methode, wenn man schon den Rechner als zentrale Instanz haben möchte, wäre eine PCI-Karte als "Digitalzentrale", die einem einen rel. schnellen BUS zur Anlage zur verfügung stellt. Hier wäre allerdings das Programmieren von Treibern unabdingbar und ich glaube kaum, dass das eine Mobafirma zahlt.

Grüße,
Martin

[Marky]

Moin,

ich kann absolut nicht mithalten um darüber mitreden zu können was in den Tiefen der Software, des PCs oder den Zentralen so abgeht und wie grenzwertig das mit den Auslastungen/Überforderungen der Systeme, hauptsächlich wohl der Zentrale sein kann, aber ich glaube hier gibt es zu viel Schwarzseherei.

Ich glaube kaum, daß ein "Noramal-User" wie unsereins ein System an seine Grenzen bringen kann. Der muß dann schon eine "Atom-Anlage" haben.

Ich kann es nur nochmal für meine Anlage wiederholen. Da sind immer zwischen 7-10 Züge am fahren. Insegesamt in einer Session wenn ich nach Fahrplan fahre auch mind. 40 Züge bei der Zentrale im Refresh. Ich beobachte nun schon seit Jahren so gut ich kann die Haltepunkte SBH und Bahnsteige und kann da nie irgendwelche größeren Schwankungen feststellen und behaupte da ist nie mehr als +/- 2 cm drin. Eher fast gar nix.. Will/braucht man mehr ? Ich sehe das nicht. Beim autom. Ankuppeln geht das noch genauer, weil ich da die RM etwwas besser "aufgestellt " habe. Meißt schiebt sich beim Ankuppeln nur der Kupplungskaken unter die Bügelkupplung und kuppelt ohne die Wagen auch nur einen Millimeter wegzuschieben.
Das ist doch affengeil. Wozu da ständig Bedenken haben über Ungenauigkeiten und Maßnahmen zur Entlastung kreieren zu müssen. Einfach freuen, daß es so fantastisch funktioniert. Für mich mmer wieder erstaunlich und Freude zugleich.

Wie schlimm ist es für den User/Zuschauer wenn tats. mal ein Güterzug von der Rangierlok beim Ankuppeln 1 cm weggeschoben wird. Geht da die Welt von unter ?

Ich sehe zumindest keinen Grund, daß man da mit irgnedwelchen Maßnahmen "traffic" vermeiden müsste.

Gruß Markus

[Erich Müller]

Hallo Markus,

was meinst du mit "Atom-Anlage"? Atome sind furchtbar klein... :

Die von mir verlinkte Anlage ist ein Riesenteil, inklusive Tagzeiten-Lichtsteuerung und ziemlich viel Klimbim. Da fahren geschätzt um den Faktor 40 bis 100 mehr Züge als bei dir, entsprechend erhöht ist auch der Traffic auf den Schnittstellen.
Martin hatte mich da schon richtig verstanden; ich hatte nicht nur die pure Rechenleistung des PC gemeint, sondern das Gesamtsystem, bis der Befehl zum Decoder kommt.
Und da fällt so einiges an, was teilweise auch mit Timern versehen ist, damit die Decoderbefehle sich nicht überschneiden mit der Ausführung des vorherigen Befehls. (Manche 4fach-Decoder "überhören" neue Befehle, solange noch einer zur Ausführung ansteht.) Ich habe selbst für meine Kleinanlage den Weg gewählt, für die Weichen- und Signalstellung eine eigene Zentrale einzusetzen (zum Glück gibt es günstige Black-Boxen für DCC im zweistelligen Euro-Bereich), so dass da keine Gefahr besteht, dass Lok- und Schaltbefehle sich gegenseitig ausbremsen. Auch wenn die modernen Protokolle da wesentlich weniger Leerlauf zwischen haben als das antike MM.

Umgekehrt gibt es einen Trend, die Modellbahn mit immer kleineren PCs laufen zu lassen, die auf fruchtige Namen, aber nicht Apfel, hören. Sie laufen unter Linux und werden dann (bei Rocrail) vom Tablet bedient.

[Marky]

[quote="Erich Müller" post_id=1830911 time=1525883398 user_id=26147]
Hallo Markus,

was meinst du mit "Atom-Anlage"? Atome sind furchtbar klein... :


[/quote]

Hallo Erich,

ich denke aus dem Gesamttext hast Du schon vetrstanden was ich mit "Atom-Anlage" gemeint habe. Bei mir bedeutet schon seit Jahrzenhten----> Atom =riesig, obwohl ich mir sehr wohl bewußt bin das "Atom" für winzig steht. So bin ich halt

Ja, Dein Beispiel ist natürlich schon was Besonderes, aber Du bist sicher mit mir überein, wenn ich mal behaupte, daß nicht mal 2 User hier aus dem Forum auch nur annähernd eine solch große Anlage haben werden.

Was ich mit meinem Beitrag meinte ist sicher klar. Für fast alle hier wird es zu keinen "Traffic-Problemen" kommen. Lokbefehle und schaltbefehle laufen bei mir selbstverständlich auch auf zwei "Kanälen"


Gruß markus

[Martin_G]

Guten Abend werte Mitstreiter,

Lieber Markus, es tut mir leid, wenn bei dir der Eindruck entstanden ist, wir wollten hier Schwarzmalerei betreiben.
Das ist ganz und garnicht meine Intention und Florians bestimmt auch nicht.

Wir haben hier über Grundsätzliches gesprochen. Dabei stand nicht im Fokus, ob das ein oder andere auch für den "Durchschnittsmodellbahner" ein merkliches Thema oder Problem darstellt.

Bei meinem System bekommt man auch etwa +-2 oder +-3cm genauigkeit beim autom. Halt und ich bin deiner Meinung, dass es nicht mehr benötigt. Das ist doch auch total ok, wenn ein Zug in echt mit einer maximalen Schwankung von 3,48m beim Haltepunkt hält. Ein Lokführer fährt seine Lok bestimmt auch auf einen Meter genau, aber ich denke, dass das trotzdem noch realistisch ist.

Zitat

---

Wozu da ständig Bedenken haben über Ungenauigkeiten und Maßnahmen zur Entlastung kreieren zu müssen.

---

Wie gesagt, war und ist das ganz und garnicht die Intention. Das ist vielleicht falsch rüber gekommen, -schade.
Ich habe für mich nicht über Maßnahmen zur Entlastung nachgedacht, sondern mir von Anfang an das Thema angeschaut und mir eine Struktur überlegt, die der Sache - nach meinem Verständnis - bestmöglich Rechnung trägt bzw. gerecht wird.

In meinen Augen ist es nunmal aus mehreren Gründen nicht besonders sinnvoll, für mehrere Loks beim Anfahren oder Bremsen jede FS einzeln von einer zentralen Einheit zu schicken. Diese Information gehört für mich nicht dort hin, ganz einfach. Das hat dann auch Auswirkungen auf die Auslastung des oder der BUS-Systeme, aber dieses und anderes kommt erst im zweiten Schritt.

Ich freue mich für dich, dass du viel Spaß, Begeisterung und Freude mit deinem Hobby hast und hoffe, dass du dadurch auch andere mit dem "Virus" infizieren kannst.

Grüße,
Martin

[EpcheIV_Fan]

Hallo an die Runde,

Ich bin zufällig beim durchstöbern der stärker frequentierten Threads auf diesen hier gestoßen, nachdem ich zuvor schon in dem über die "Motorsteuerung bei DCC Decodern" ein wenig über dieses mir unbekannte C-Digitalsystem gelesen hatte.

Ich habe in den letzten Tagen immer wieder ein wenig hier gelesen und durchaus interessante Beiträge gefunden. Es war mir gar nicht bewusst, was es für verschiedene Auffassungen von Digitalsteuerung und Digitalbetrieb / Konzepte etc. gibt. Es hat meinen Horizont doch schon erweitert auch wenn ich wohl nicht alles so in der Gänze verstanden habe.

Offenbar ist Martin_G der oder einer der Entwickler dieses Systems?

Ich hätte da jetzt einmal eine Frage in die Runde:

Wer nutzt denn jetzt von euch tatsächlich dieses System?

@Martin_G:
Ich habe gesehen, dass es bei diesem System einen Funkhandregler gibt. In wie weit wäre der zu anderen Systemen kompatibel?
Ist die Schnittstelle offen?
Hintergrund:
Ich suche bereits seit längerem ein kabelloses Handsteuergerät, dass meinen Anforderungen genügt. (Kompakt mit Haptik, reichweite über 30m, gut lesbares Display beleuchtet und ein aufgeräumtes Design, und natürlich nicht zu teuer)

Nette Grüße vom Rand der Platte,

Jonas

[StephanLeist]

Hallo Jonas,

Hier habe ich ja schon lange nicht mehr vorbei geschaut...

Ich antworte dir einmal, auch wenn dir Martin wahrscheinlich einiges besser beantworten kann.

Zitat

---

Offenbar ist Martin_G der oder einer der Entwickler dieses Systems?

---

Das ist korrekt. Wie du vielleicht schon gelesen hast, betreibt er das Weiterentwickeln des Systems eher als Hobby.

Zitat

---

Wer nutzt denn jetzt von euch tatsächlich dieses System?

---

Ich denke in dieser Runde niemand. Also ich zumindes nicht.
Es gab mal jemanden, der hat das Forum aber wieder verlassen.
Habe mich nur länger ernstahaft mit dem System auseinandergesetzt, weil ich einiges daran wirlkich interessant finde. Manches musste mir erst von anderen mit entsprechendem technischen Sachverstand erklärt werden, dass ich verstehen konnte, was warum welche großen Vorteile gegenüber den marktüblichen Systemen bietet. Dabei muss ich zugeben sicher nicht alle technischen Details ganz verstanden zu haben.
Aber der stärkste Grund dagegen dürfte wohl sein, dass ich aus dem DCC Segment bereits eine volle Ausstatung besitze und damit im Großen und Ganzen auch zufrieden bin. Würde ich mit Digital bei 0 anfangen sähe es evtl. anders aus?

Der "Marktanteil" dieses Systems ist verschwindent gering - so mein Eindruck. Auch wenn ich doch tatsächlich mittlerweile 2 Modellbahner zufällig in der echten Welt kennen gelernt habe, die damit Fahren und sehr zufrieden schienen. Einer hat mir erzählt das es in der Oberpfalz auch einen Modelleisenbahn Club / Verein gibt, der damit eine große Segmentanlage steuert. Den Namen habe ich leider vergessen. --> einfach mal googlen

Es scheint jedoch auch sehr viele andere zumindest zu interessieren, den Zugriffszahlen dieses Themas zu beurteilen, die sich hier aber nicht zu Wort melden, nur still mitlesen.

Was sind deine Interessensbeweggründe an diesem System?

Zitat

---

Ich suche bereits seit längerem ein kabelloses Handsteuergerät, dass meinen Anforderungen genügt.

---

Ja, das ging mir auch schon einmal so, habe mich bis heute aber noch nicht entschieden. Was ist mit W-Lan Multimaus von Roco, Märklin LGB Funkhandregler, Massoth Funkhandregler, Lenz LH101 Funk, Zimo, Piko Funkhandregler, ich glaube es gibt noch weitere?
Die erfüllen glaube ich alle deine Wünsche.

[CDC-User]

Guten Abend Jonas,

Ich habe mir verschiedene DCC-Komponenten besorgt und auch Komponenten von C-Digital.
Ich bin also einer, der dieses System nutzt und ich bin davon überzeugt. Das soll aber nicht heißen, dass es für mich nicht auch interessante features im DCC Segment gibt.

Zitat

---

Ich habe gesehen, dass es bei diesem System einen Funkhandregler gibt. In wie weit wäre der zu anderen Systemen kompatibel?
Ist die Schnittstelle offen?
Hintergrund:
Ich suche bereits seit längerem ein kabelloses Handsteuergerät, dass meinen Anforderungen genügt. (Kompakt mit Haptik, reichweite über 30m, gut lesbares Display beleuchtet und ein aufgeräumtes Design, und natürlich nicht zu teuer)

---

Ich habe mir letztes Jahr einen C-Digital Funkhandregler gegönnt und bin auch damit sehr zufrieden. Das ganze Teil macht einen sehr wertigen Eindruck, ist kompakt (7,5 x 15 cm) und liegt gut in der Hand (Schwerpunkt etwa in der Mitte) - Display ist gut lesbar, auch bei hellem Sonnenlicht, die Tasten sind super, mit deutlichem Druckpunkt ...
Die Bedienung ging für mich größtenteils intuitiv und ohne das ich die BDA zur Hand nehmen musste.

Was mir auch besonders gefällt ist, dass das Gerät vollständig auf Haptik setzt und man praktisch im Blindflug seine Lok steuern kann. Außerdem gefällt mir, dass die Fahrdaten am Display ziemlich übersichtlich und gut lesbar dargestellt sind, was ich z.B. beim Lenz LH101 (hatte ich schon hier) und der Roco Multimaus (habe ich noch) überhaupt nicht finde. Bei der Roco finde ich es schlecht, dass man eine Schriftdarstellung gewählt hat, die an die Segemente einer 7 Segmentanzeige angelehnt ist anstatt einen "normalen" Font zu nutzen. Buchstaben und Zahlen lassen sich so nicht gut lesen (unterscheiden). Warum macht man das, wenn doch ein grafisches Display verbaut ist?

Der Akku hält ziemlich lang, trotz Hintergrundbeleuchtung und Beleuchtung der Tasten. 6h auf jeden Fall ... länger habe ich noch nicht getestet, und da war der Akku etwa noch ein Drittel voll.

Die Menünavigation und Eingaben etc. gehen genauso, wie man es von den Autos mit Multifunktions Drehknopf kennt.

Zitat

---

Ich habe gesehen, dass es bei diesem System einen Funkhandregler gibt. In wie weit wäre der zu anderen Systemen kompatibel?
Ist die Schnittstelle offen?

---

Wenn du Programmieren kannst, ist im Prinzip alles offen. Der Handregler kann mit Software per USB vom PC geladen werden.
Das was man braucht ist das kopatible Interface. Das, glaube ich, ist nicht zu anderen Systemen kompatibel. Da müsst man mal Martin genau nachfragen.

Ach ja, in einem Flyer steht, dass die Software auf Kundenwunsch/ Anfrage individuell angepasst werden kann und auch die Tasten nach Wunsch beschriftet werden können.

Viel Spaß weiterhin...

[EpcheIV_Fan]

Hallo Stephan,

Zitat

---

Es scheint jedoch auch sehr viele andere zumindest zu interessieren, den Zugriffszahlen dieses Themas zu beurteilen, die sich hier aber nicht zu Wort melden, nur still mitlesen.

Was sind deine Interessensbeweggründe an diesem System?

---

Keine besonderen. Ich bin einfach nur neugierig und würde evtl. damit gerne einmal was ausprobieren. Ich habe da so ein paar Ideen für eine derzeit noch analoge Anlage, wo mir eine Digitalisierung mit DCC Probleme bereitet, bzw. sehr aufwändig und wohl teuer werden würde.

Zitat

---

Ja, das ging mir auch schon einmal so, habe mich bis heute aber noch nicht entschieden. Was ist mit W-Lan Multimaus von Roco, Märklin LGB Funkhandregler, Massoth Funkhandregler, Lenz LH101 Funk, Zimo, Piko Funkhandregler, ich glaube es gibt noch weitere?
Die erfüllen glaube ich alle deine Wünsche.

---

Der Lenz LH101 hat mich nicht voll überzeugen können, der geht aber schon sehr stark in die Richtung wie ich mir das vorstelle.
Die Multimaus finde ich nicht gelungen. Wenn man sie gewohnt ist, mag sie ok sein, aber die ist bei mir raus.
Zimo ist mir persönlich zu teuer, Piko/Märklin/Massoth (ich glaube das ist im Prinzip immer das gleiche Teil von Massoth für Piko und Mä hergestellt : )
habe ich noch nicht selbst probiert. Die Übersichtlichkeit der Display-Anzeige finde ich mangelhaft, soweit ich das bis jetzt sehen konnte, außerdem wirkt das Teil relativ wuchtig. Aber davon muss ich mich noch in Realität überzeugen.


@Klaus:
Nutzt du das C-Digitalsystem?


Nette Grüße vom Rand der Platte,
Jonas

[EpcheIV_Fan]

Hallo Hermann,

Zitat

---

Ich habe mir verschiedene DCC-Komponenten besorgt und auch Komponenten von C-Digital.

---

Das finde ich ja sehr interessant. Dann kannst du ja gegenüberstellen ...? An deinen Erfahrungen wäre ich da schon interessiert.

Ich hätte da eine derzeit noch analoge Anlage, die in Segmente aufgeteilt werden kann. Die Strecke ist in Blöcke unterteilt, um einen Bahnüblichen Blockstrecken-Betrieb zu ermöglichen. Diverse Haltepunkte und Bahnhofsgleise sind mit Halt-Abschnitten versehen, die entweder stromlos geschalten werden oder an einem analogen Bremsgeneratot angeschlossen sind.

Diese Analge möchte ich mit relativ wenig aufwand digitalisieren, ohne dass ich an den Gleisen herumbasteln muss. Und ganz wichtig, die Funktionalität sollte natürlich mindestens erhalten bleiben. Eine reine PC-Steuerung kommt hier aus mehreren Gründen nicht in Frage.


Danke für deinen ausführliche Schilderung der Eindrücke mit dem Funkhandregler.

Zitat

---

Wenn du Programmieren kannst, ist im Prinzip alles offen. Der Handregler kann mit Software per USB vom PC geladen werden.
Das was man braucht ist das kopatible Interface. Das, glaube ich, ist nicht zu anderen Systemen kompatibel. Da müsst man mal Martin genau nachfragen.

Ach ja, in einem Flyer steht, dass die Software auf Kundenwunsch/ Anfrage individuell angepasst werden kann und auch die Tasten nach Wunsch beschriftet werden können.

---

Ich werde wohl mal eine Anfrage schicken. V.a. interessiert mich auch der Preis, wenn man sich die Software anpassen lässt.
Braucht man ein spezielles Programm um den Handregler über USB zu Programmieren? Hast du Erfahrungen?

Mich würde ja gerade interessieren, ob es eben ein Interface für den Handregler gibt, dass z.B. über XpressNet angeschlossen werden kann?

Zitat

---

Bei der Roco finde ich es schlecht, dass man eine Schriftdarstellung gewählt hat, die an die Segemente einer 7 Segmentanzeige angelehnt ist anstatt einen "normalen" Font zu nutzen.

---

Ja das kann ich unterschreiben. Das finde ich auch unglücklich gewählt.
Von dem Massoth und entsprechenden Derivaten muss ich mir noch einen persönlichen Eindruck machen. Für mich ist aber auch eine übersichtliche Anzeige sehr wichtig. Man muss schnell sehen können welche Lok (Decoder Adresse) gerade welche Fahrstufe in welche Fahrrichtung bekommt. Alles andere sollte etwas in den Hintergrund treten, da nur bei bedarf von Belang.

Nette Grüße vom Rand der Platte,
Jonas

[Klaus_K]

Grüß dich Jonas,

Willkommen in der bescheidenen Diskussionsrunde.

Zitat

---

@Klaus:
Nutzt du das C-Digitalsystem?

---

Jein. Mir ist das durch einen glücklichen Zufall in die Hände gefallen, wie du evtl. eingangs gelesen hast. Ich "nutze" es nicht wirklich, weil ich meine Hauptanlage bereits seit Jahren mit DCC Komponenten betreibe und ich daran auch nichts ändern werde.
Allerdings spiele ich seit längerem mit dem Gedanken, auch mit diesem System zumindest eine kleine Anlage aufzubauen, die ich evtl. stückweise erweitere. Mich überzeugt einiges an diesem System, vor allem die ausgeklügelte Technik (Konzept der Datenübertragung, Motorregelung der Decoder).

Den neuen Handregler HRX20 habe ich noch nicht, sollte ich jedoch mit dem Bau einer C-Digital Anlage beginnen, werde ich mir bestimmt neue Komponenten zukaufen. Ein schnurloser Handregler ist in jedem Fall klasse. Das gilt systemunabhängig. Ich bin im Übrigen auch kein Freund der Touch und Wisch- Geräte und möchte eine entsprechende Haptik haben, mit einer Bedienbarkeit, die nicht nur für Feinmotoriker gedacht ist.

[EpcheIV_Fan]

Guten Abend in die Runde,

Danke für die Willkommensgrüße.

Also ich bin jetzt schon mal mit dem Ingenieurbüro Grünwald in Verbindung getreten. Mal schauen, was sich da jetzt noch ergibt.

Zitat

---

Mich überzeugt einiges an diesem System, vor allem die ausgeklügelte Technik (Konzept der Datenübertragung, Motorregelung der Decoder).

---

Ich habe mich da jetzt auch etwas eingelesen. Wenn ich das alles richtig verstanden habe, dann wird bei C-Digital die Kommunikation praktisch durch FDM (frequency division multiplexing) umgesetzt? So ergibt sich dann eine echte voll-duplexe Übertragung und dass nur mit einer Leitung + Masse. Das ist schon einzigartig, aber eigentlich total simpel. Die Idee ist echt toll - aber eigentlich ja auch nichts Neues.

Wie viele Kanäle nutzt denn C-Digital? Ich habe nur von einem mit 450kHz gelesen.

Mich wundert jetzt auch einwenig, dass das nicht auch weitere Hersteller so gemacht haben. Aber das haben sich hier ja auch schon andere gefragt - zumal das System ja anscheinend bereits Anfang der 90er entwickelt und Mitte/Ende der 90er auf den Markt kam, oder?
DCC ist doch erst seit Februar 1994 als Norm von der NMRA aufgenommen.

Bei DCC muss man sich jetzt bemühen, dass man mit Railcom und Railcom+ eine Rückmeldung der Decoder hinbekommt, indem man das mehr oder weniger in das bestehende Protokoll integriert (Lücke). Für die langen Lokadressen musste das Protokoll auch schon nachträglich aufgebläht und, wenn man ehrlich ist, etwas verbogen werden. Eine niederwertige lange Adresse ist ja z.B. nicht gleich der gleichwertigen bei kurzen Adressen.

Wie ihr seht habe ich ernsthaftes Interesse an diesem System und würde auch von euch gerne mehr Erfahrungen hören.

Ich bin ja mit dem Entwickler in Kontakt getreten. Er möchte allerdings meine konkreten Produktfragen nicht hier beantworten, weil es so aussehen könnte, als würde er diesen Diskussion-thread als Werbeplattform nutzen. Kann ich auch verstehen ...

Ich hoffe trotzdem, dass er sich auch evtl. wieder an der Diskussion beteiligt und hier und da Informationen liefert und Einblicke gewährt.
Mich würde z.B. auch noch interessieren wie denn das jetzt bei seinen Decodern so funktioniert mit dieser "bsonderen" Motorregelung. Wenn ich das hier richtig vertanden habe, hat er eine "KI" prädiktive Regelung (model predictive control) gebaut?

Was ich ganz nebenbei auch sehr sehr ansprechend finde, ist die Möglichkeit des C-Digitalsystems automatischen Halt vor roten Signalen oder Langsamfahrt einzurichten.

Ich muss schon sagen, gut dass es dieses Forum gibt, sonst hätte ich davon wohl nie etwas erfahren. Das System ist total unbekannt, wie mir deucht.


Nette Grüße vom Rand der Platte,
Jonas

[Klaus_K]

Hallo Jonas,

Zitat

---

Wenn ich das alles richtig verstanden habe, dann wird bei C-Digital die Kommunikation praktisch durch FDM (frequency division multiplexing) umgesetzt? So ergibt sich dann eine echte voll-duplexe Übertragung und dass nur mit einer Leitung + Masse. Das ist schon einzigartig, aber eigentlich total simpel. Die Idee ist echt toll - aber eigentlich ja auch nichts Neues.

Wie viele Kanäle nutzt denn C-Digital? Ich habe nur von einem mit 450kHz gelesen.

---

Momentan bin ich auch auf dem Stand, dass nur eine Trägerfrequenz (eben also nur ein Kanal) genutzt wird. Das sind diese 450 kHz. Wie ich Martin verstanden habe gibt es aber Studien/Prototypen-Komponenten wo mindestens 2 simultane unabhängige Kanäle genautzt werden. Damit kann er bei C-Digital vollkommen unabhängig mehrere (mindestens einen je Rchtung) Sende und Empfangskanäle realisieren.
=> er braucht für nichts ein extra Programmiergleis - echtes POM!, die Decoder-Rückmeldung geht mit einem eigenen Protokoll (wenn man möchte), es ist immer vollkompatibel bis zur ersten Decodergeneration die nur 450 kHz Kanal können, jede Lok kann aktiv kommunizieren - nicht nur Befehle empfangen und aus ...
Praktisch eine vollduplexe Übertragung über mehrere unabhängige Kanäle - eben wie du sagst, mit einer einzigen Leitung! (neben GND versteht sich)

Das finde ich auch echt klasse. Du hast recht, prinzipell kennen und nutzen wir fast alle sowas bei Rundfunk, Fernsehen und Internet/Telefon.

Ich muss dir leicht Zähne knirschend zustimmen, dass dagegen das DCC-Protokoll (aber meines Wissens auch die Märklin Derivate) ziemlich schwach daherkommt. Unabhängig vom aktuellen Entwicklungsstand. Rein auf die Möglichkeiten bezogen.

Zitat

---

Bei DCC muss man sich jetzt bemühen, dass man mit Railcom und Railcom+ eine Rückmeldung der Decoder hinbekommt, indem man das mehr oder weniger in das bestehende Protokoll integriert (Lücke). Für die langen Lokadressen musste das Protokoll auch schon nachträglich aufgebläht ...

---

JA, das ist leider so. Aber es funktioniert ja so auch trotzdem recht zuverlässig. Auch wenn es in Sachen Programmierung und Rückmeldung rein technologisch nie das Niveau von C-Digital erreichen kann.
Nach meiner Einschätzung kann man am DCC-Protokoll nicht mehr groß was machen. Die Möglichkeiten sind eigentlich ausgeschöpft auch was Railcom+ angeht. Wenn es hier noch neues gibt, dann wird das wohl kaum ohne größeren Schnitt gehen. Das hieße dann sicher, alte Komponenten verkaufen, verschenken oder evtl. liese sich das ein oder andere Stück an Hardware auch anpassen. Das wird dann aber sicherlich auch nicht gerade eine einfache Nummer werden.

Zitat

---

Er möchte allerdings meine konkreten Produktfragen nicht hier beantworten ...

---

Das ist ja klar. Produktanfragen gehören ja auch nicht in ein Forum. Wenn du aber diskutieren willst, nach Ideen, Konzepten/Ansätzen und Meinungen fragst, wird er sicher bei Zeit auch mit diskutieren - hat er ja früher auch.

Zitat

---

hat er eine "KI" prädiktive Regelung (model predictive control) gebaut?

---

Da hat er bis jetzt nicht so viel blicken lassen. Aber sein Ansatz ist schon toll und anspruchsvoll. Das ist ein absolutes Alleinstellungsmerkmal auf dem gesamten Markt (eigentlich genauso wie das Protokoll mit seinen Möglichkeiten).

Zitat

---

die Möglichkeit des C-Digitalsystems automatischen Halt vor roten Signalen oder Langsamfahrt einzurichten.

---

Ich finde das ist so ähnlich wie das ABC-Bremsen, nur funktioniert das "punktgenaue" Anhalten hier anscheinend besser und zuverlässiger.

Zitat

---

Das System ist total unbekannt, wie mir deucht.

---

Den Eindruck hatte/habe ich auch. Bis ich diesen Thread aufgemacht habe, habe ich so gut wie Nichts im Netz darüber gefunden. Manche Infos waren widersprüchlich und manches wurde anscheinend einfach von irgendwelchen Leuten behauptet, die keine Ahnung haben. Ich bin dann ja schließlich hier im Forum bei einem Thread von CDC-User (Hermann) gelandet. Alles weitere ist Geschichte ...

[Martin_G]

Hallo Jonas und den Rest der Runde und die zahlreichen stillen Mitleser,

Danke für das Interesse.
Gerne versuche ich auf deine Fragen, soweit es mir möglich ist, einzugehen. Leider ist bei mir Zeit ein sehr knappes Gut und ich kann hier nicht so oft vorbeischauen.

Vieles wurde dir ja schon von Klaus und Hermann beantwortet. Ich habe da auch jetzt auf die schnelle nichts korrekturwürdiges gesehen.

Hierzu muss ich aber doch etwas korrigieren...

Zitat

---

Ich finde das ist so ähnlich wie das ABC-Bremsen, nur funktioniert das "punktgenaue" Anhalten hier anscheinend besser und zuverlässiger.

---

Nach außen mag es so aussehen, dass sich das automatische Halten usw. beim C-Digitalsystem dem ABC-Bremsen ähnelt. Tatsächlich ist es aber etwas grundlegend Anderes, weil beim C-Digitalsystem die Informationen, also die Befehle, für Signalhalt, freie Fahrt und Langsamfahrt im Protokoll enthalten sind und auch darüber zu den Decodern übertragen werden. Es wird eben also gerade nicht durch zusätzliche Hardware am Gleis in einem Abschnitt eine besonder Spannung o.ä. angelegt, was der Decoder auswerten können muss. 2 Bit im Protokoll (also 4 Zustände) können den Decoder dazu veranlassen, je nach Konfiguration und Decodergeneration, entsprechend zu reagieren. Eben mit Signalhalt im Uhrzeigersinn/Gegen-Uhrzeigersinn, freie Fahrt oder Langsamfahrt.
Aus der Tatsache, diese Information im Protokoll zu haben, ergeben sich einige Eigenschaften, die überhaupt nur dadurch möglich sind. (Auch ohne, dass man erst die komplette Anlage vollständig "überwacht" in ein PC-Programm übertragen muss, dass dann vergleichbares ermöglicht.)

Ähnliches gilt für die einstllbare Massensimulation/Last-Simulation die sich in 4 (oder 8 ) Stufen während des Fahrens direkt am Steuergerät einstellen lässt - entsprechend abhängig davon, was im Decoder einprogrammiert wurde. Auch diese Information ist im Protokoll enthalten und muss nicht durch einen Programmiervorgang (POM) angepasst werden.
Dadurch lässt sich auch das "Segeln" einer Dampflok simulieren und die Bremskraft einstellen. Damit wird nicht, wie herkömmlich, einfach durch Rücknahme der Fahrstufen gebremst sondern tatsächlich durch das Anlegen einer Bremese in entsprechend einstellbarer stärke.
Das ist zwar etwas schwieriger zum Fahren, kann aber auch viel Spaß machen, va. wenn man den "Dreh" dann etwas raus hat.
Auf den Punkt gebracht gibt es zwei Regler: einen zur Einstellung der Fahrstufe und einen zum Festlegen der Bremskraft.


Ein weiterer interessanter Unterschied ist evtl auch, dass ich zwischen Fahrstufen-(kurve) und Beschleunigung(-skurve) konsequent unterscheide. Und das auch im Decoder entsprechend umsetze. Außerdem wird bei mir ein sigmoidales Beschleunigungsverhalten simuliert, so wie das bei Antrieben in Natura auch üblich/physikalisch bedingt ist.
Ich habe gesehen, dass es mittlerweile auch einige Mobahner gibt, die mittlerweile dieses Verhalten ebenfalls einstellen wollen, es allerdings nur über die Fahrstufentabelle könne, da sowohl bei den DCC als auch bei Märklin Decodern (zumindest von denen ich bis jetzt gehört habe) es keine Beschleunigungskurve gibt. Die Beschleunigungskurve ergibt sich da praktisch durch die Abstufung der externen Fahrstufen.

Zitat

---

Wenn ich das hier richtig vertanden habe, hat er eine "KI" prädiktive Regelung (model predictive control) gebaut?

---

Ja, das ist soweit korrekt, gilt aber nur für die neue Decodergeneration, an der ich noch arbeite. So eine Regelung ist deutlich aufwändiger, komplizierter und deutlich komplexer als die sonst üblichen "einfachen" PI(D) Regel-Algorithmen. Ich habe dazu einige Simulationen in MATLAB(R) Simulink(R) erstellt, was schon recht aufwändig ist.
Außerdem habe ich noch einen zweiten Lösungsansatz im Rennen, der allerdings zusätzlicher Hardware in den Fahrzeugen bedarf. Am Ende wird einer von beiden den Vorzug bekommen. Da spielen dann viele Dinge (Preis, Aufwand, Platz, Komfort, Unterschiede im Fahrverhaten,...) eine Rolle.

Zu der predictiv Regelung kann und möchte ich nicht zu viele Details hier preisgeben, weil da doch einiges an Know-How drinnen steckt, was v.a. auch für andere Industriebereiche interessant ist. Aktive Regelungstechnik ist eben ein relativ komplexes und sehr wichtiges Segment in den verschiedensten Bereichen.
Aber so viel noch dazu, Motoren können in Bereichen betrieben werden, in denen diese annhähernd lineare physikalische Eigenschaften aufweisen. Diese Bereiche sind es die auch immer bevorzugt werden.
Es gibt aber noch die Bereiche, in denen die Motoren absolut nicht lineares Verhalten aufweisen. Es gibt rein physikalisch bedingt z.B. eine Minimaldrehzahl, die aus den üblichen Gleichungen so nicht hervorgeht. Unter dieser verhält sich der Motor nicht linear. Es ist aber trotzdem möglich einen Motor erfolgreich unterhalb seiner eigentlichen Minimaldrehzahl zu betreiben. Eine Regelung in diesem Bereich gestaltet sich nun aber dann doch noch einmal deutlich komplexer, da der Regler ebenfalls mit nichtlinearem Verhalten "klar kommen" können muss.

Weiteres evtl. auf Nachfrage

Zitat

---

Wenn ich das alles richtig verstanden habe, dann wird bei C-Digital die Kommunikation praktisch durch FDM (frequency division multiplexing) umgesetzt? So ergibt sich dann eine echte voll-duplexe Übertragung und dass nur mit einer Leitung + Masse.

---

Das ist auch eine der Hauptstärken unseres Systems. Dadurch ergeben sich Möglichkeiten (wurden hier bereits angedeutet), die auf dem Markt absolut einzigartig sind. Die Frage ist dann nur, ob sich diese Vorteile auch sinnvoll ausspielen lassen.
Darüber kann ja hier genrne ein offener diskurs geführt werden, was damit wie am sinnvollsten und nütlichsten angefangen werden kann.

Zum "neuen" Steuergerät/Handregler/Funkhandregler kann ich gerne auch noch Fragen beantworten, sofern gewünscht.

[StephanLeist]

Hallo Martin,

Schön mal wieder hier von dir zu lesen.

Ich bin etwas neugierig und an der Technik interessiert, ohne dass ich jetzt ein besonderes Fachwissen mein eigen nennen kann.
Könntest du doch noch etwas zu dieser prädiktiven Regelung erklären? Ich weiß schon, hier lesen sehr viele mit, und du möchtest keine Details erklären ... hier und da werden ja auch schnell einmal Ideen und Konzepte kopiert.
Hat deine Regelung dann gar keinen PID-Regler mehr? Fällt dann das mühselige Einstellen weg? Was macht denn so eine Regelung aus, für Laien erklärt?
Was ist denn die Verbesserung zu den Decodern, von denen wir schon in den Videos tolle Regelungsfähigkeiten sehen konnten?

Mal noch eine ganz andere Frage: Wo willst du denn langfristig mit deinem System hin?

Zu dem Funkhandregler sind ja noch ein paar Fragen offen geblieben. Kann man den auch für andere Digitalsysteme/Steuerungen/Zentralen verwenden. Was ist da das Konzept dahinter?


Das mit dem Bremsen was du erklärt hast, verstehe ich nicht ganz, finde es aber sehr interessant und spannend. Könntest du das noch einmal genauer erklären? Wieso bremst eine Lok nicht, wenn man die Fahrstufen reduziert? Wie geht das dann?

Das war vorerst alles. Ich hoffe du kommst dazu meine Fragen zu beantworten, aber es drängt nicht.

[Martin_G]

Guten Abend Stephan,

Danke für dein geäußertes Interesse.

Ich weiß nicht genau, was ich dir noch Allgemeines zu prädiktiver Regelung schreiben soll, was ich nicht sowieso schon geschrieben habe - bzw. was man nicht auch von anderen Quellen im Internet mal schnell beziehen kann.
Alles was zu tief ins Detail geht, würde doch eher zu einer größeren, komplexen Lehreinheit ausarten - befürchte ich. Evtl. müsste man das in einen eigenen oder anderen Faden auslagern. ("Motorsteuerung bei DCC-Decodern" : ) auch wenn es ja keinen DCC-Decoder betrifft.

Zitat

---

Hat deine Regelung dann gar keinen PID-Regler mehr?

---

Doch, schon. Der ist die Basis für die Regelung. Rein prädiktiv lässt sich meines Wissens keine Maschine/Motor regeln. Ich wüsste jedenfalls nicht wie das funktionieren sollte. Das geht m.M.n. schon rein konzeptionell nicht. Vielleicht kann einer der Spezialisten aus dem Forum dazu was sagen...

Zitat

---

Fällt dann das mühselige Einstellen weg?

---

Ja, das fällt nahezu weg. Stand jetzt, braucht es zumindest schon einmal nur noch 2 Parameter zum Einstellen. Und das ist doch in jeglicher Hinsicht ein deutliche Verbesserung der Anwenderfreundlichkeit. Sonst stellte ich jüngst fest, dass es eher mehr Parameter anstatt weniger werden.
Erfolgreich getestet wurden bis jetzt 26 verschiedene Motortypen.
7x 3-Poler (gekapselte, Trommel-, Scheibenkollektor, schräggenutet)
8x 5-Poler (verschieden starke Magnete, gekapselte, Trommelkollektor, schräggenutet)
5x 7-Poler (verschieden starke Magnete, gekapselte, Trommelkollektor, schräggenutet)
6x Glockenankermotoren/Coreless Drives (verschiedene Bauformen und Größen)

Zitat

---

Was ist denn die Verbesserung zu den Decodern, von denen wir schon in den Videos tolle Regelungsfähigkeiten sehen konnten?

---

An manchen Stellen ergeben sich deutlich wahrnehmbare Verbesserungen, an anderen praktisch keine. Es ist aber auf jeden Fall der Komfort/Benutzerfreundlichkeit verbessert. Die Ansteuerung mancher Motoren geschieht schonender, Geräusche (also Verluste und schädliche Vibration) werden deutlich geringer.
Im Übrigen muss an dieser Stelle darauf hingewiesen werden, dass es auch "Geräusche" respektive Vibrationen gibt, die sehr schädlich sein können nur nicht immer zwingend dem Anwender auffallen (-> Abhängigkeit zw. Frequenz und wahrnehmbarer Schallpegel für Menschen -> Hörfeld )

Zitat

---

Wo willst du denn langfristig mit deinem System hin?

---

Ich möchte mir das was ich mir für die Steuerung von Modellschienenfahrzeugen vorstelle umsetzten und weiterentwickeln. Physikalisch möglichst gut abgebildet. Dabei hoffe ich, dass Interessenten und Kunden mich dabei weiter unterstützen und es auf diese Weise auch zu Weiterentwicklungen kommt.

Thema Funkhandregler:
Kompatibel zu anderen Systemen: - Prinzipiell ja - das entsprechende Interface muss geschaffen werden und evtl ist die Software des Handreglers etwas anzupassen.
Konzept Funkhandregler:
- für Rechtshand- und Linkshand-Betrieb geeignet
- handlich (nicht zu groß, tailliertes Gehäuse)
- übersichtlich
- praktisch blind bedienbar gute Haptik
- qualitativ hochwertige Komponenten, größtenteils Made in Germany
- Reichweite mindestens 100m
- Akkulaufzeit bis zu 12h
- komfortable updatefähig über einfache USB-Schnittstelle
- automatische Anmeldung am Interface (Anwender muss keine IDs/Adressen zuweisen)
- übersichtliche Darstellung, mit grafischem Display
- automatische Regelung der Beleuchtung
- intuitive Bedienung
- Sturzschutz
- ...
Weitere Details gerne auf konkrete Nachfrage.

Zitat

---

Wieso bremst eine Lok nicht, wenn man die Fahrstufen reduziert? Wie geht das dann?

---

Weil das im Decoder so eingestellt ist. Das kannst du bei DCC oder Märklin Decodern damit vergleichen, wenn man die Bremsverzögerung auf einen sehr hohen Wert einstellt. Allerdings funktioniert die Umstellung bei mir direkt im Betrieb ohne erst in die Programmierung zu müssen. Über die am Handregler direkt einstellbare Massensimulationsstufe / Bremsstärke wird eben eine Bremsstärke direkt eingestellt. So kann gezielt über das Regeln der Bremse Geschwindigkeit verringert werden.
Ich hoffe es ist etwas klarer geworden?

Achja, übrigens funktioniert das nur relativ gut, weil ich eben Fahrstufen und damit die Fahrstufen"kurve" - also die Abstufung der einzelnen FSen - konsequent von der Beschleunigungskurve unterscheide. Die Beschleunigung eines Triebfahrzeugs ist durch die simulierte Physik des Originals gegeben. Dadurch ergeben sich viele "Vorteile"/ Funktionen die mit anderen Systemen wenn überhaupt, dann nur mit einer PC-Automatik-Steuerung möglich wird. Der PC steuert dann die Fahrstufen nach einer vom Anwender einprogrammierten Weise. Doch selbst so einfache Dinge wie das realitätsgetreue Anfahren eines Zuges vom Bahnsteig geht hier trotzdem nicht so einfach.

Schönen Sonntagabend noch.

[EpcheIV_Fan]

Hallo Martin,

Also bei deiner besonderen Regelung, wo sind denn da jetzt die Unterschiede für den Mobahner? Ok, dein Konzept ist also anders, aber was ist denn in der Praxis anders? Ohne dir etwas unterstellen zu wollen, aber zunächst sind doch das alles mehr oder weniger "nur" geflügelte Worte à la Märklin "Hochleistungs"-antrieb. Weniger Parameter zum Ein- und vor allem zum Verstellen wäre ja schon einmal toll, aber wie wird sichergestellt, dass sich ein Decoder so auch gut auf einen Antrieb einstellen lässt?

Zitat

---

- Prinzipiell ja - das entsprechende Interface muss geschaffen werden

---

Wer baut das? Hättest du überhaupt daran Interesse?

Zitat

---

Doch selbst so einfache Dinge wie das realitätsgetreue Anfahren eines Zuges vom Bahnsteig geht hier trotzdem nicht so einfach.

---

Das kann doch jedes System und jeder Decoder, dass der Zug langsam auf die eingestellte Sollfahrstufe beschleunigt. Das kann man in der ABV im Decoder einstellen - wie langsam das von geschehen soll.

Zitat

---

- handlich (nicht zu groß, tailliertes Gehäuse)
- übersichtlich
- praktisch blind bedienbar gute Haptik

---

Diese Punkte finde ich auch sehr wichtig. Das sind eigentlich die ausschlagsstärksten Produnkteigenschaften für so ein Gerät. Leider sind da die mir bekannten Hersteller nicht immer ganz konsequent.

Zitat

---

qualitativ hochwertige Komponenten, größtenteils Made in Germany

---

Zitat

---

... So kann gezielt über das Regeln der Bremse Geschwindigkeit verringert werden.

---

Wie läuft das dann konkret ab. Kannst du mal ein so einen Anwendungsfall praktisch schildern?

Grüße vom Rand der Platte

Jonas