An Aus


RE: Vergleich Leistungsumfang MFX versus DCC fahren

#76 von vikr , 21.02.2022 20:37

Hallo Frank,

Zitat von fschum im Beitrag #74
Wenn es um den Befehls-ACK geht, dann wird dieser immer im selben DCC Frame gesendet. Also DCC-Befehl und Railcom-ACK gehoeren unteilbar zusammen. Der Befehls-ACK kommt somit "elektrisch" in 450 Microsekunden.
Wenn Du von "sekundenlang" schreibst, dann meinst Du vermutlich etwas anderes.
Ja, angenommen es sind etwa 30 Loks auf der Anlage unterwegs, alle mit eingeschalteter Beleuchtung. Die Anlage ist in Abschnitte unterteilt und alle Abschnitte sind mit Railcom-Rückmeldern ausgestattet. Ich betrachte exklusiv die lokale Rückmeldung über RailCom Kanal 2. Ziel ist die Anzeige im Gleisbild, sobald ein Fahrzeug einen überwachten Abschnitt befährt oder verläßt. Wie lange dauert es bis die Zentrale davon "erfährt" und diese Info z.B. an ein Modellbahn-Steuerprogramm weiterzuleiten?

MfG

vik


im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix


vikr  
vikr
ICE-Sprinter
Beiträge: 7.327
Registriert am: 23.10.2011
Gleise M, C u. K.
Spurweite H0, N
Stromart Digital, Analog

zuletzt bearbeitet 21.02.2022 | Top

RE: Vergleich Leistungsumfang MFX versus DCC fahren

#77 von fschum , 21.02.2022 23:03

Hallo Vic,

Zitat von vikr im Beitrag #77
... angenommen es sind etwa 30 Loks auf der Anlage unterwegs, alle mit eingeschalteter Beleuchtung. Die Anlage ist in Abschnitte unterteilt und alle Abschnitte sind mit Railcom-Rückmeldern ausgestattet. Ich betrachte exklusiv die lokale Rückmeldung über RailCom Kanal 2. Ziel ist die Anzeige im Gleisbild, sobald ein Fahrzeug einen überwachten Abschnitt befährt oder verläßt. Wie lange dauert es bis die Zentrale davon "erfährt" und diese Info z.B. an ein Modellbahn-Steuerprogramm weiterzuleiten?


Das haengt von zwei Dingen ab,

  • Wie arbeitet der DCC refresh (vergleichbar mit einem task scheduler, d.h. wie intelligent priorisiert er die DCC Befehle)
  • Melde-Latenz (wie lange dauert die Uebertragung vom Detector zum Gleisbildsystem)

Um bei Deinem Szenario zu bleiben,

  • Ein DCC Befehl dauert ~10ms (um die Mathematik einfach zu halten)
  • 30 Loks im Refresh
  • Jede Lok bekommt 1x Geschwindigkeit und 1x Licht zyklisch gesendet

Um die Lok-Liste 1x durchzurattern muessen 30 x 2 Befehle je 10ms gesendet werden. Die Rundenzeit betraegt somit 600ms. Und das ist noch optimistisch. Sollten je Lok zwei Funktionen aktiv sein, die in verschiedenen Funktionsbloecken liegen, wuerden 3 Befehle je Lok notwendig. Wir waeren dann bei fast 1 Sekunde Rundenzeit. Faehrt eine Lok auf in einen neuen Meldeabschnitt, just nachdem sie zuvor per DCC angesprochen wurde, dauert es 600ms (900ms) bis Sie erneut angesprochen wird. Erst jetzt kann Sie sich "melden". Die von Dir genannte Verzoegerung waere da. Jetzt kommt noch die Zeit dazu, die der Melder+Bus benoetigt, die Information zum Gleisbild zu schicken ...

Zwischen-Fazit: DCC Refresh Strategie ist (sehr) wichtig und die Latenzzeit im Meldesystem.

Beides habe ich seit langem auf meinem Radar, weil ich genau hier durchaus Verbesserungspotential sehe.


MfG,
Frank


 
fschum
InterRegio (IR)
Beiträge: 113
Registriert am: 18.10.2018
Homepage: Link
Ort: BW
Spurweite N
Stromart Digital

zuletzt bearbeitet 22.02.2022 | Top

RE: Vergleich Leistungsumfang MFX versus DCC fahren

#78 von vikr , 22.02.2022 02:02

Hallo Frank,

Zitat von fschum im Beitrag #78
Um die Lok-Liste 1x durchzurattern muessen 30 x 2 Befehle je 10ms gesendet werden. Die Rundenzeit betraegt somit 600ms. Und das ist noch optimistisch. Sollten je Lok zwei Funktionen aktiv sein, die in verschiedenen Funktionsbloecken liegen, wuerden 3 Befehle je Lok notwendig. Wir waeren dann bei fast 1 Sekunde Rundenzeit. Faehrt eine Lok auf in einen neuen Meldeabschnitt, just nachdem sie zuvor per DCC angesprochen wurde, dauert es 600ms (900ms) bis Sie erneut angesprochen wird. Erst jetzt kann Sie sich "melden". Die von Dir genannte Verzoegerung waere da.
ich sehe Du siehst das Problem. Und dazu kommt, dass ganz zufällig der gerade gefragte Decoder auch der nächste (erste) sein kann, der in der Refreshliste gerade daran ist. Die Antwortzeit kann also bei 30 Loks - für dieselbe Lok - schon mal ein dutzend Milisekunden oder eine Sek betragen (Jitter). Über Kanal 2 ist also mit den aktuellen Zentralen leider auch nicht annähernd so etwas wie eine Echtzeitrückmeldung möglich.

MfG

vik


im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix


vikr  
vikr
ICE-Sprinter
Beiträge: 7.327
Registriert am: 23.10.2011
Gleise M, C u. K.
Spurweite H0, N
Stromart Digital, Analog

zuletzt bearbeitet 22.02.2022 | Top

RE: Vergleich Leistungsumfang MFX versus DCC fahren

#79 von hb059 , 22.02.2022 06:16

Hallo vik,

die lokalen Rückmeldungen würden über Ethernet an der Steuersoftware im Rechner ankommen. Ich habe noch keinen Weg gefunden, die Daten direkt auf die ECoS zu bekommen. iTrain oder auch WinDigipad funktionieren z.B. wunderbar.

Gruß
Hagen


hb059  
hb059
Regionalbahn (RB)
Beiträge: 38
Registriert am: 02.02.2022
Ort: Lohr a. Main
Gleise Peco Code 55
Spurweite N
Steuerung LoDi-Rektor
Stromart Digital


RE: Vergleich Leistungsumfang MFX versus DCC fahren

#80 von fschum , 22.02.2022 08:22

Guten Morgen,

Zitat von vikr im Beitrag #79
Die Antwortzeit kann also bei 30 Loks - für dieselbe Lok - schon mal ein dutzend Milisekunden oder eine Sek betragen (Jitter). Über Kanal 2 ist also mit den aktuellen Zentralen leider auch nicht annähernd so etwas wie eine Echtzeitrückmeldung möglich.


Bei einem einfachen "round-robin" Refresh ist das i.d.T. so. Ich habe das in den vergangenen Jahren oft beobachtet. Jitter von bis zu ~2 Sekunden habe ich gemessen.

Ein Grund warum ich mich entschied, Refresh Strategien zu prototypen. Mein aktueller Favorit: Fahrende Loks werden 8x pro Sekunde (also alle 125ms) angesprochen (garantiert). Stehende Loks sinken asymptotisch gegen 1 Befehl pro 2.5 Sekunden. Der Refresh ist ausgelegt fuer max. 10 gleichzeitig fahrende Loks (= 80 DCC Befehle/Sekunde). Bei typ. 120 DCC Befehle/Sek bleiben 40 Befehle/Sek fuer stehende Loks was wiederum 100 Loks entspricht (=40x2.5). Zusammengefasst hat der Algorithmus folgende Eigenschaften,

  • 10 maximal zeitgleich fahrende Loks
  • bis zu 100 angemeldetete aber stehende Decoder
  • maximaler Jitter der fahrenden Loks ~125ms
  • Echtzeitverhalten: Ja, bei fahrenden Loks
  • Gleichbleibende Latenz bei wenigen bzw. vielen Decodern


Geschwindigkeits- bzw. FN-Aenderungen werden adhoc zwischengeschoben und haben hoechste Prioritaet. Das ganze System muss noch seine Alltagstauglichkeit unter Beweis stellen, aber die bisherigen Tests sind vielversprechend. Die weiter oben gezeigten Messkurven sind Meldedaten von fahrenden Loks. Diese senden jeweils 8 Messpunkte pro Sekunde.

Die Reaktionszeit des Systems darf m.E. nicht Lastabhaengig sein, weil das erschwert die Automatisierung. Das ist das Ziel.


MfG,
Frank


 
fschum
InterRegio (IR)
Beiträge: 113
Registriert am: 18.10.2018
Homepage: Link
Ort: BW
Spurweite N
Stromart Digital

zuletzt bearbeitet 22.02.2022 | Top

RE: Vergleich Leistungsumfang MFX versus DCC fahren

#81 von vikr , 22.02.2022 08:54

Hallo Frank,

Zitat von fschum im Beitrag #81
Die Reaktionszeit des Systems darf m.E. nicht Lastabhaengig sein, weil das erschwert die Automatisierung. Das ist das Ziel.
eine Anforderung an Zentralen, die für alle Rückmeldungen erfüllt werden müsste, insbesondere auch auf Basis von mfx, was dort bislang völlig unrealistisch erscheint. Hoffen wir mal, dass Märklin Dein Anliegen entsprechend berücksichtigt, wenn sie die CS3 fit für ihre Zweileiterfahrer (Trix, minitrix, LGB und Spu1) machen, eine Differenzierung zwischen stehenden und fahrenden Fahrzeugen beim Refresh....

MfG

vik


im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix


vikr  
vikr
ICE-Sprinter
Beiträge: 7.327
Registriert am: 23.10.2011
Gleise M, C u. K.
Spurweite H0, N
Stromart Digital, Analog

zuletzt bearbeitet 22.02.2022 | Top

RE: Vergleich Leistungsumfang MFX versus DCC fahren

#82 von Stummilein , 22.02.2022 09:45

Zitat von WiBu im Beitrag #65
Hallo
wird die Diskussion nicht viel zu akademisch ?

Ich finde es ist völlig egal was da wirklich auf der Leitung passiert, welche Modulationen, wie lange eine Rückmeldung dauert etc.

Wenn Vorteile / Nachteile eines der Systeme den Ausschlag geben sollen, welches System man sich zulegen möchte, dann gibt es aus meiner Sicht nur zwei Entscheidungen
  • ich entscheide mich für ein proprietäres System eines Herstellers, der nach eigenem Gutdünken jederzeit daran Änderungen vornehmen kann
    Zweitanbietern ist es schwer die Funktionalitäten zu bieten, da das Protokoll nicht öffentlich ist
  • ich entscheide mich für ein offenes System, deren Spezifikation öffentlich zugängig ist
    Jeder der möchte und die Kapazität hat, kann Produkte mit diesem Protokoll auf den Markt bringen

Irgendwie erinnert mich das an die Diskussion Viedeo 2000 <-> VHS oder Token Ring <-> TCPIP.
Das vermeintlich (der Befürworter) schlechtere hat sich durchgesetzt, weil das Angebot einfach größer war.

Nicht ohne Grund haben die proprietären Decoder die offene Fremdsprache hinzugelerent

(ich habe in den 60er Jahren den Absprung geschafft und meine Loks in die Hamo Versionen umgebaut oder ausbuchsen lassen

Hallo,

ich finde die Diskussion hochinteressant, zumal nun tatsächlich über die Kommunikation bzw. Protokolle zwischen den Endgeräten (Decoder, Zentrale) diskutiert wird.

Ob diese nun als Entscheidungshilfe oder als Grundlage für eigene Experimente genutzt wird, spielt dabei keine Rolle, denn der Informationsgehalt ist für mich sehr interesant.


Beste Grüße Ralf


 
Stummilein
Administrator / Foreninhaber
Beiträge: 7.508
Registriert am: 26.04.2005
Homepage: Link
Spurweite H0
Stromart AC, Digital, Analog

zuletzt bearbeitet 22.02.2022 | Top

RE: Vergleich Leistungsumfang MFX versus DCC fahren

#83 von WolfgangReder , 22.02.2022 10:12

Hallo !

Zu den Refreshzyklen:
Eine clevere Zentrale macht einfaches Round-Robin Schdule nur wenn sich bei keinem Empfänger etwas geändert hat.

Ansonsten wird priorisiert; also eine Lok die Fährt und bei der sich die Geschwindigkeit ändert wird auf jeden Fall vor gereiht.
Eine Lok die schon sein Stunden nur herum steht (z.B. im BW) bekommt ihre (Refresh)Befehle erst dann wenn sonst nichts zu tun ist.
Ich denke das sollte mittlerweile für alle Zentralen Standard sein.
Leistungsstarke Prozessoren sind mittlerweile genügend vorhanden (keine Aussage zur aktuelle Lieferfähigkeit). Niemand braucht mehr einen 8bit Microcontroller in eine Zentrale verbauen.

Ganz generell kann man sagen, dass die Protokolle bei kluger Umsetzung wesentlich leistungsfähiger sind, als die einfachen Rechenbeispiele vermuten lassen.
Wenn notwendig kann man dann mit lokalen Maßnahmen (ABC,HLU,etc) auch noch zusätzlich Präzision ins (automatische) Fahren bringen.

lg
Wolfi


WolfgangReder  
WolfgangReder
InterRegio (IR)
Beiträge: 230
Registriert am: 31.03.2020
Gleise Roco
Spurweite H0
Steuerung Zimo MX10
Stromart Digital


RE: Vergleich Leistungsumfang MFX versus DCC fahren

#84 von vikr , 22.02.2022 11:05

Hallo Wolfi,

Zitat von WolfgangReder im Beitrag #83
Ganz generell kann man sagen, dass die Protokolle bei kluger Umsetzung wesentlich leistungsfähiger sind, als die einfachen Rechenbeispiele vermuten lassen.
da schafft nur - testen, testen, testen - Klarheit.
Ein plausibles Test-Szenario wäre sehr hilfreich... .

MfG

vik


im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix


vikr  
vikr
ICE-Sprinter
Beiträge: 7.327
Registriert am: 23.10.2011
Gleise M, C u. K.
Spurweite H0, N
Stromart Digital, Analog

zuletzt bearbeitet 22.02.2022 | Top

RE: Vergleich Leistungsumfang MFX versus DCC fahren

#85 von fschum , 22.02.2022 11:53

Hallo Wolfgang,

Zitat von WolfgangReder im Beitrag #83
... Geschwindigkeit ändert ... wird auf jeden Fall vor gereiht.
... Eine Lok die schon sein Stunden nur herum steht bekommt ihre (Refresh)Befehle erst dann wenn sonst nichts zu tun ist.



Genau, aber wer wird verdraengt? wie oft? wie lange? usw. Das ist ggf. nicht trivial und wie Du schreibst, auf 8-Bittern kaum implementierbar.

Neue, bessere, CPUs loesen das Rechenpower Problem. Was bleibt ist der Bandbreitenengpass auf dem Gleis. Letztenedlich betreiben wir Mangelverwaltung. Das m.E. aussichtsreichste Ziel, Ausmisten! Einer abgestellten Lok im BW pro Stunde 1800x "STOP" zu senden ist ziemlich sinnlos. Haben wir 100 Loks rumstehen, senden wir 180.000x "STOP" pro Stunde.

Das Ziel: Abgestellte Loks komplett aus dem DCC Refresh rauszuschmeissen.
Das Problem: Dabei fallen die Railcom-Meldungen dieser Loks weg. Das waere sehr schlecht!
Der Plan: Wir brauchen einen alternativen Meldekanal fuer diese abgestellten Loks. Dieser Kanal muss unabhaengig von DCC Addressen sein. Da kommt einem Railcom Kanal-1 in den Sinn ... und genau den moechte ich umdefinieren, sodass dieser kollisionsfrei arbeiten kann. Mir steht natuerlich nicht zu, DCC Specs umzudefinieren. Es geht hier lediglich um die Machbarkeit - PoC. Gemaess diesem Ansatz, stuende dann die gesamte DCC Bandbreite den fahrenden Loks zur Verfuegung. Die abgestellten Loks melden in dem Kanal-1 Paralleluniversum ihre Existens bzw. melden Kommunikationsbedarf an. Ein Echtzeitverhalten sowohl bei fahrenden und stehenden Loks waere machbar. Allerdings dreht man dabei schon an grossen Raedern ...


MfG,
Frank


 
fschum
InterRegio (IR)
Beiträge: 113
Registriert am: 18.10.2018
Homepage: Link
Ort: BW
Spurweite N
Stromart Digital

zuletzt bearbeitet 22.02.2022 | Top

RE: Vergleich Leistungsumfang MFX versus DCC fahren

#86 von WolfgangReder , 22.02.2022 14:11

Hallo !

Zitat
Genau, aber wer wird verdraengt? wie oft? wie lange? usw. Das ist ggf. nicht trivial und wie Du schreibst, auf 8-Bittern kaum implementierbar.


Genau, die werden ich aktuellen Zentralen ohnehin nicht mehr verbaut.

Zitat
Neue, bessere, CPUs loesen das Rechenpower Problem. Was bleibt ist der Bandbreitenengpass auf dem Gleis. Letztenedlich betreiben wir Mangelverwaltung. Das m.E. aussichtsreichste Ziel, Ausmisten! Einer abgestellten Lok im BW pro Stunde 1800x "STOP" zu senden ist ziemlich sinnlos. Haben wir 100 Loks rumstehen, senden wir 180.000x "STOP" pro Stunde.

Das Ziel: Abgestellte Loks komplett aus dem DCC Refresh rauszuschmeissen.
Das Problem: Dabei fallen die Railcom-Meldungen dieser Loks weg. Das waere sehr schlecht!
Der Plan: Wir brauchen einen alternativen Meldekanal fuer diese abgestellten Loks. Dieser Kanal muss unabhaengig von DCC Addressen sein. Da kommt einem Railcom Kanal-1 in den Sinn ... und genau den moechte ich umdefinieren, sodass dieser kollisionsfrei arbeiten kann. Mir steht natuerlich nicht zu, DCC Specs umzudefinieren. Es geht hier lediglich um die Machbarkeit - PoC. Gemaess diesem Ansatz, stuende dann die gesamte DCC Bandbreite den fahrenden Loks zur Verfuegung. Die abgestellten Loks melden in dem Kanal-1 Paralleluniversum ihre Existens bzw. melden Kommunikationsbedarf an. Ein Echtzeitverhalten sowohl bei fahrenden und stehenden Loks waere machbar. Allerdings dreht man dabei schon an grossen Raedern ...



Meine Ausführungen zum Scheduling waren sehr grob, und sicher nicht als Dokumentation einer konkreten Implementierung gemeint. Zumindest von keiner sehr klugen. Es ging ums Prinzip des Schedulings.
Für alle nicht Informatiker (die soll es in diesem Forum angeblich auch geben): Mit Scheduling meine ich die Regeln ob und wann welches Paket ausgesendet wird.
Zu deinem Ziel: Kein Problem weil,

dein Problem keines ist: Die Zentrale weiß welche Funktionen eingeschaltet sind, kennt die Geschwindigkeit (0), und solange sich niemand darum kümmert, kann man die Lok sich selbst überlassen. Auch Positionsinformationen kann sich die Stellwerkssoftware ohne Rückmeldung merken. Für den Fall dass eine Lok neu aufs Gleis kommt, werde ich ja irgend etwas tun. Außerdem wenn man Positionsinformationen via RAILCOM machen möchte braucht man für jeden Abschnitt ohnehin einen eigenen Detektor, und da jeder Decoder auf jeden Befehl mit seiner Adresse auf Kanal 1 antwortet, kommt man auch so zu seinen Informationen (zumindest solange nur ein Decoder im Abschnitt steht).

Der Plan ist gut, aber nur sehr schwer umsetzbar:

1. Administratives: Normen soll und kann man nur sehr behutsam umsetzen, denn die Hersteller müssen das alles auch Umsetzen können und wollen(!) (vor allem Betriebswirtschaftlich, den im Gegensatz zu uns Bastlern, müssen die von Ihrer Beschäftigung mit der Modelleisenbahn leben).
2. Je höher die Bandbreite sein soll, um so größer werden die Anforderungen an Verkabelung und Kontakt. Wenn man sich dieses (und auch andere) Forum so durchliest sind viele Anwender mit dem derzeitigen Anforderungen schon am Limit ihrer Fähigkeiten. Modellbahn soll Spass machen, und auch wenn es sicher nicht schadet sich mit der Materie zu beschäftigen; es soll kein abgeschlossenes Studium notwendig sein, nur um eine Modellbahn aufzubauen.
3. Das Einhalten der entsprechenden Vorschriften bezüglich Funkentstörung wir auch immer komplexer.

Für mich ist das Bandbreitenproblem keines. Auf meiner persönlichen Bahn hatte ich noch nie das Gefühl, dass die Bandbreite am Gleis ein Problem darstellt (40 Loks am Gleis, 15-20 Fahren).
Und wenn die Lok nicht sofort bei Grün weg fährt, dann ist halt der Lokführer gerade pinkeln ...

lg
Wolfi


WolfgangReder  
WolfgangReder
InterRegio (IR)
Beiträge: 230
Registriert am: 31.03.2020
Gleise Roco
Spurweite H0
Steuerung Zimo MX10
Stromart Digital

zuletzt bearbeitet 22.02.2022 | Top

RE: Vergleich Leistungsumfang MFX versus DCC fahren

#87 von fschum , 22.02.2022 15:05

Hallo Wolfgang,

Zitat von WolfgangReder im Beitrag #86
Je höher die Bandbreite sein soll, um so größer werden die Anforderungen an Verkabelung und Kontakt.


Mein Plan ist, die verfuegbare Bandbreite effizienter zu nutzen. Ich plane nicht, die Bandbreite zu erhoehen. Somit bleibt die Verkabelung wie sie ist, aber das Protokoll aendert sich marginal.


MfG,
Frank


 
fschum
InterRegio (IR)
Beiträge: 113
Registriert am: 18.10.2018
Homepage: Link
Ort: BW
Spurweite N
Stromart Digital


RE: Vergleich Leistungsumfang MFX versus DCC fahren

#88 von WolfgangReder , 22.02.2022 15:39

Hallo !

Zitat von fschum im Beitrag #87
Hallo Wolfgang,

Zitat von WolfgangReder im Beitrag #86
Je höher die Bandbreite sein soll, um so größer werden die Anforderungen an Verkabelung und Kontakt.


Mein Plan ist, die verfuegbare Bandbreite effizienter zu nutzen. Ich plane nicht, die Bandbreite zu erhoehen. Somit bleibt die Verkabelung wie sie ist, aber das Protokoll aendert sich marginal.


Da sind bei mir die Gedanken schon etwas weiter (durch)gegangen .
Zur Effizienz: Scheduling macht genau das. Der RAILCOM Rückkanal hat genau die Dauer von 4 1-bit (nicht byte) pro Paket; hier sind die Einsparungsmöglichkeiten sehr begrenzt.
Zu Kollisionsfreiheit auf Kanal 1: Hast du da ein Konzept? Würde mich ehrlich interessieren? Übliche Kollisionserkennungsmechanismen setzen ein Zurücklesen der selbst gesendeten Daten voraus; ist mit der derzeit vorhandenen HW eher nicht kompatibel, macht die Software im Decoder deutlich komplizierter (was natürlich sofort Auswirkungen auf den Preis bzw. Qualität hat). Wenn man da nur etwas ins Detail geht relativiert sich der Begriff "marginal" schon sehr schnell.
Und das alles wie gesagt für eine praktisch eher untergeordnetes Problem.
RAILCOM ist weit davon entfernt perfekt zu sein, aber es funktioniert auch nicht so schlecht. Es ist immer eine Frage der Verhältnismäßigkeit.
Die meisten Probleme lassen sich mit einer geschickten Kombination aus Lokal- und Globaldetektoren sehr gut lösen.

lg
Wolfi


WolfgangReder  
WolfgangReder
InterRegio (IR)
Beiträge: 230
Registriert am: 31.03.2020
Gleise Roco
Spurweite H0
Steuerung Zimo MX10
Stromart Digital


RE: Vergleich Leistungsumfang MFX versus DCC fahren

#89 von fschum , 22.02.2022 16:45

Hallo,

ich glaub wir kommen grad vom Thema ab. Nur kurz,

Zitat von WolfgangReder im Beitrag #88
Zu Kollisionsfreiheit auf Kanal 1: Hast du da ein Konzept?


Ja ... auf dem Papier. Fuer einen real-life PoC brauche ich Decoder die sich entsprechend verhalten. Die baue ich derzeit.

Zitat von WolfgangReder im Beitrag #88
Würde mich ehrlich interessieren?


Gerne, aber dann in einem anderen Thread. Passt dann nicht mehr zu diesem Thema.

Zitat von WolfgangReder im Beitrag #88
Übliche Kollisionserkennungsmechanismen ...


Ich schrieb "kollisionsfrei" und meine damit Kollisionsvermeidung. D.h. die Daten werden so gesendet das keine Kollisionen entstehen. Falls doch, dann gibt es noch das Railcom 6/8 encoding als Sicherheitsnetz.


MfG,
Frank


WolfgangReder und vikr haben sich bedankt!
 
fschum
InterRegio (IR)
Beiträge: 113
Registriert am: 18.10.2018
Homepage: Link
Ort: BW
Spurweite N
Stromart Digital


RE: Vergleich Leistungsumfang MFX versus DCC fahren

#90 von hb059 , 22.02.2022 17:24

Hallo Wolfi,

ich glaube ich muss noch einmal den Unterschied zwischen Railcom Kanal 1 und Kanal 2 erklären.

Der Railcom Kanal 1 ist 2 Byte lang. Nach der Dekodierung (8 auf 6) ergeben sich 12 Bits. Kanal 1 wird ausschließlich zur Übermittlung der Lokadresse verwendet. Jede Lok sendet dort ungefragt zwei Pakete im Wechsel, aus denen sich zusammengenommen die Lokadresse ergibt. Kanal 1 ist somit nur für lokale Rückmelder auswertbar. Ein Kollision ist leicht erkennbar. Vor der Dekodierung sind genauso viele '1' Bits wie '0' Bits im Paket. Trifft dies nicht mehr zu, liegt wahrscheinlich eine Kollision vor. Der zweite Indikator ist die Polarität. Stehen zwei Loks in unterschiedlicher Ausrichtung auf dem Gleis, erzeugt die eine einen positiven Rückmeldeimpuls, die andere einen negativen. In dem Moment wo du bei der Dekodierung einen Wechsel der Polarität feststellst, hast du ebenfalls eine Kollision.

Railcom Kanal 2 ist insgesamt 6 Byte lang. Nach der Dekodierung ergeben sich bis zu 36 Bit Nutzdaten. Dieser Kanal steht dem im direkt davor liegenden DCC-Paket angesprochenen Dekoder exklusiv zur Verfügung. Dort bekommst du wirklich Daten. Solange es keine zwei Dekoder mit derselben Adresse auf der Anlage gibt, ist eine Kollision ausgeschlossen.

Es wird nicht funktionieren, stehende Loks gar nicht mehr anzusprechen. Diese schalten dann irgendwann das Licht und den Sound aus. Alle zwei Sekunden einmal halte ich für einen guten Kompromiss. Bei 2 DCC-Paketen mit zusammen 13 ms kostet das dann pro Lok 0,65% der verfügbaren Bandbreite. Bei 50 stehenden Loks also 32,5% der Bandbreite. Das halte ich verschmerzbar. Das Ziel, diese Loks gar nicht mehr zu refreshen ergibt somit keinen Sinn. Wenn die Loks wirklich Licht und Sound aus haben, kannst du sie natürlich ganz rausnehmen. Sie werden dann von den lokalen Meldern über Kanal 1 gefunden.

Ein interessanter Ansatz für ein gutes Scheduling ergibt sich vielleicht aus aus den Echtzeitbetriebssystemen. Die dort verwendeten Scheduler für Tasks stehen vor einem ähnlichen Problem. Such mal mit Google nach "Least Laxity First" oder "Earliest Deadline First". Dann kannst du dir noch überlegen, mit welcher Latenz du geänderte Werte auf dem Bus haben möchtest. Ist nur mal ein Denkansatz :)

Gruß
Hagen


hb059  
hb059
Regionalbahn (RB)
Beiträge: 38
Registriert am: 02.02.2022
Ort: Lohr a. Main
Gleise Peco Code 55
Spurweite N
Steuerung LoDi-Rektor
Stromart Digital


RE: Vergleich Leistungsumfang MFX versus DCC fahren

#91 von fschum , 22.02.2022 18:36

Hallo Hagen,

Zitat von hb059 im Beitrag #90
Es wird nicht funktionieren, stehende Loks gar nicht mehr anzusprechen. Diese schalten dann irgendwann das Licht und den Sound aus.
Hagen


Es funktioniert mit keinem heute verfuegbaren Decoder, weil der Kanal-1 anders verwendet wuerde (Konjunktiv). Darum baue ich ja die Decoder dafuer selbst. Ausschliesslich Decoder, die dieses Konzept kennen, koennen dieses Feature nutzen. Das Licht/Sound Problem existiert dann nicht mehr. Aber nochmal ... es handelt sich hierbei um eine "Technologie Studie" - mehr nicht. Stehende (nicht fahrende) Decoder im Refresh zu halten skaliert schlicht nicht. Der Refresh alle 2 Sekunden ist der temporaere "workaround".

Zitat von hb059 im Beitrag #90
Wenn die Loks wirklich Licht und Sound aus haben, kannst du sie natürlich ganz rausnehmen. Sie werden dann von den lokalen Meldern über Kanal 1 gefunden.
Hagen


Nein. Ueber Kanal-1 wird dann nix mehr "gefunden", denn dieser hat dann eine andere Funktion. Sprich, der klassische Kanal-1 Address broadcast ist dann Geschichte. Gefunden wuerden die Decoder per Logon ... z.B. DCCA.


MfG,
Frank


 
fschum
InterRegio (IR)
Beiträge: 113
Registriert am: 18.10.2018
Homepage: Link
Ort: BW
Spurweite N
Stromart Digital


RE: Vergleich Leistungsumfang MFX versus DCC fahren

#92 von ukw , 22.02.2022 20:05

Hallo vik,

Zitat von vikr im Beitrag #76
Ja, angenommen es sind etwa 30 Loks auf der Anlage unterwegs, alle mit eingeschalteter Beleuchtung. Die Anlage ist in Abschnitte unterteilt und alle Abschnitte sind mit Railcom-Rückmeldern ausgestattet. Ich betrachte exklusiv die lokale Rückmeldung über RailCom Kanal 2.


Ich sehe das so:

1. Gibt es genügend Abschnitte mit lokalen Railcom-Rückmeldern (z.B. 30), gibt es in Kanal 1 keine Kollisionen.
2. Wenn alle lokalen Rückmelder den Inhalt von Kanal 1 an die Zentrale melden, ist Dein Problem mit mit den Round-Robin-Zeiten auf Kanal 2 keines mehr

Man braucht dann lediglich einen Scheduler für die Rückmelder, um alle Daten schnellstmöglich zu einzusammeln. Dieser ist dann aber komplett unabhängig vom DCC-Frame. Es dürfte kein Problem sein, innerhalb eines (folgenden) DCC-Frames mehrere lokale Rückmelder abzufragen.

Viele Grüße

Frank (nicht zu verwechseln mit fschum)


ukw  
ukw
RegionalExpress (RE)
Beiträge: 82
Registriert am: 06.01.2022


RE: Vergleich Leistungsumfang MFX versus DCC fahren

#93 von vikr , 22.02.2022 20:10

Hallo Frank (ukw),

Zitat von ukw im Beitrag #92
Zitat von vikr im Beitrag #76
Ja, angenommen es sind etwa 30 Loks auf der Anlage unterwegs, alle mit eingeschalteter Beleuchtung. Die Anlage ist in Abschnitte unterteilt und alle Abschnitte sind mit Railcom-Rückmeldern ausgestattet. Ich betrachte exklusiv die lokale Rückmeldung über RailCom Kanal 2.


1. Gibt es genügend Abschnitte mit lokalen Railcom-Rückmeldern (z.B. 30), gibt es in Kanal 1 keine Kollisionen.
2. Wenn alle lokalen Rückmelder den Inhalt von Kanal 1 an die Zentrale melden, ist Dein Problem mit mit den Round-Robin-Zeiten auf Kanal 2 keines mehr

Ich betrachte exklusiv die lokale Rückmeldung über RailCom Kanal 2.

MfG

vik


im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix


vikr  
vikr
ICE-Sprinter
Beiträge: 7.327
Registriert am: 23.10.2011
Gleise M, C u. K.
Spurweite H0, N
Stromart Digital, Analog

zuletzt bearbeitet 22.02.2022 | Top

RE: Vergleich Leistungsumfang MFX versus DCC fahren

#94 von ukw , 22.02.2022 20:40

Hallo vik,

Zitat von vikr im Beitrag #93
Ich betrachte exklusiv die lokale Rückmeldung über RailCom Kanal 2.



Ja, das habe ich schon verstanden, aber warum diese Beschränkung? Liegt es an der vorhandenen Hardware, welche Ergebnisse auf Kanal 1 nicht liefern kann? Ich habe gedacht, dass Kanal 1 genau für den Fall einer Lokalisierung gedacht ist.

Man könnte das Prinzip dabei noch optimieren:

- Jeder lokale Rückmelder decodiert die Hamming-Byte selbst
- Jeder lokale Rückmelder baut die komplette Adresse, die sich aus ID1 und ID2 im Kanal 1 ergibt, selbst zusammen und merkt sich diese.
- Empfängt der lokale Rückmelder in einem der folgenden DCC-Frames nichts mehr auf Kanal 1, verwirft er die ermittelte Adresse

Dann könnte jeder lokale Rückmelder im Round-Robin-Verfahren gepollt werden (z.B. RS485) - unabhängig vom DCC-Frame-Scheduling. Alternativ könnte jeder der lokalen Rückmelder über ein Multimaster-System (wie CAN) sogar ungefragt seine Informationen an die Zentrale melden. Dabei würde der lokale Rückmelder seine Infos nur an die Zentrale melden, wenn sich diese tatsächlich ändern (Lok da/nicht da). Da dieses komplett unabhängig vom DCC-Frame-Scheduling passiert, gibt es keinen Engpass mehr - auch bei mehr als 30 Loks.

Okay, wenn dies nicht für Dich in Frage kommt, werde ich mich von nun an zurückhalten. Wie Du vielleicht noch aus einem anderen Thread (Märklin-Decoder mit DCC-Fähigkeit Railcom-fähig?) weißt, baue ich gerade an einer WLAN-fähigen DCC-Zentrale basierend auf einem System bestehend aus einer Kombination von STM32 und ESP8266 - mit Railcom-Detector. Auf jeden Fall werde ich mich mit diesem Problem (Engpass Railcom-Daten) beschäftigen. Mein Railcom-Detector meldet sowohl Inhalte aus Kanal 1 als auch aus Kanal 2 an den STM32.

Viele Grüße

Frank


ukw  
ukw
RegionalExpress (RE)
Beiträge: 82
Registriert am: 06.01.2022


RE: Vergleich Leistungsumfang MFX versus DCC fahren

#95 von vikr , 22.02.2022 21:04

Hallo Frank,

Zitat von ukw im Beitrag #94
Liegt es an der vorhandenen Hardware, welche Ergebnisse auf Kanal 1 nicht liefern kann?
es geht m. E. in diesem Thread darum, was welche aktuelle Hardware und Software leisten kann und was nicht geht. Ich bezweifle, dass viele Modellbahner bereit sind, ihre Infrastruktur auszutauschen. Also stellt sich die Frage, ob und wie man die bestehende Infrastruktur ggf. ergänzen kann.
Die Kanal 1 Rückmeldung funktioniert ja z.B. mit der ECoS und 50098 schon, hat aber schon immer gewisse Einschränkungen. Ob die Info nun per Kabel oder drahtlos vom Detector weiter übermittelt werden soll, ist davon völlig unabhängig.

MfG

vik


im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix


vikr  
vikr
ICE-Sprinter
Beiträge: 7.327
Registriert am: 23.10.2011
Gleise M, C u. K.
Spurweite H0, N
Stromart Digital, Analog

zuletzt bearbeitet 22.02.2022 | Top

RE: Vergleich Leistungsumfang MFX versus DCC fahren

#96 von fschum , 22.02.2022 22:31

Jetzt haben wir uns bzgl. DCC die Koepfe heiss diskutiert. Offenbar ein streitbares Protokoll. immerhin, denn es ist relativ gut dokumentiert.

Wie schaut es denn bzgl. Mfx aus? Sind denn da alle Nutzer zufrieden? Oder gibs Dinge die verbesserungswuerdig sind?


MfG,
Frank


 
fschum
InterRegio (IR)
Beiträge: 113
Registriert am: 18.10.2018
Homepage: Link
Ort: BW
Spurweite N
Stromart Digital


RE: Vergleich Leistungsumfang MFX versus DCC fahren

#97 von vikr , 23.02.2022 00:48

Hallo Frank,

Zitat von fschum im Beitrag #96
Wie schaut es denn bzgl. Mfx aus? Sind denn da alle Nutzer zufrieden? Oder gibs Dinge die verbesserungswuerdig sind?

1. es gibt mit mfx anscheinend keinerlei Möglichkeit lokale Rückmelder zu implementieren.
2. es gibt keine offizielle Möglichkeit, die mfx-Anmeldeprozedur auf dem Hauptgleis einer CS2/CS3 auszuschalten, außer durch komplettes ausschalten in der Zentrale oder im Decoder selbst.
3. es gibt mit mfx keine Möglichkeit eine bestimmte Adresse für einen bestimmten Decoder zu reservieren, wie etwa IP-Adressen in einer DHCP-Umgebung. In Vereinen führt es regelmäßig zu Problemen, wenn private mfx-Loks wiederholt abwechselnd an der heimischen mfx-Zentrale und an der Vereinsanlage angemeldet werden. Beim Aufgleisen wird jeweils eine Adresse ausgehandelt, was insbesondere in Umgebungen mit PC-Steuerprogrammen und vom Programm eingemessenen Loks sehr lästig ist.

MfG

vik


im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix


vikr  
vikr
ICE-Sprinter
Beiträge: 7.327
Registriert am: 23.10.2011
Gleise M, C u. K.
Spurweite H0, N
Stromart Digital, Analog

zuletzt bearbeitet 23.02.2022 | Top

RE: Vergleich Leistungsumfang MFX versus DCC fahren

#98 von Railwolf , 26.03.2022 14:39

Hallo,

Zitat von vikr im Beitrag #97
3. es gibt mit mfx keine Möglichkeit eine bestimmte Adresse für einen bestimmten Decoder zu reservieren, wie etwa IP-Adressen in einer DHCP-Umgebung. In Vereinen führt es regelmäßig zu Problemen, wenn private mfx-Loks wiederholt abwechselnd an der heimischen mfx-Zentrale und an der Vereinsanlage angemeldet werden. Beim Aufgleisen wird jeweils eine Adresse ausgehandelt, was insbesondere in Umgebungen mit PC-Steuerprogrammen und vom Programm eingemessenen Loks sehr lästig ist.


Nun ja... mit der tams-Zentrale (die allerdings m3 praktiziert) kann der Lok eine bestimmte Adresse "eingeschrieben" werden, und zwar auf dem Hauptgleis. Es ist sogar möglich, einen ganzen Lokschuppen voller Lokomotiven mit neuen mfx-Adressen zu versehen.
Wenn das mit Märklin- oder Esu-Zentralen derzeit nicht möglich ist, dann sollte es nicht am Protokoll liegen, sondern an der Implementierung in den Zentralen.

Zur Eingangsfrage: unklarer kann sie kaum gestellt werden. Was ist mit "Leistung" überhaupt gemeint? Mein Citroën Zephyr hat 60 kW Leistung. Der Fendt vom Nachbarn ungefähr 350 kW, wenn ich's richtig weiß, auf hundert mehr oder weniger kommt es aber dabei nicht an. Trotzdem kann mein Zephyr den Fendt ohne weiteres überholen, wenn die Straße frei und breit genug ist. Und der Allgaier von meinem Schwiegervater hat nur 12 PS, fährt auch kaum 20 km/h Spitze, ist aber in der Lage, meinen Zephyr aus dem Acker zu ziehen, wenn ich es mit dem Fendt-Überholen übertrieben habe und feststecke.
Datenblätter sind geduldig; wichtig ist, ob das Angebotene den Anforderungen entspricht.

Für den durchschnittlichen Modellbahner dürften sich im Betrieb wenig Unterschiede ergeben. Die automatische Vergabe der mfx-Adressen ist in der derzeitigen Form, wie @vikr beschrieben hat, mit Makeln behaftet, wenn man zwischen mehreren Zentralen hin und her wechselt. Dem könnte einfach entgegengewirkt werden, wenn in der Praxis Vereine auf mfx verzichten... denn zwischenzeitlicher Betrieb an einer DCC-Zentrale sorgt m.W. nicht für Neuanmeldung im mfx-System. Außerdem sind nicht alle Modellbahner in Vereinen aktiv, ebenso wie nicht alle auf iTrain oder TC setzen, um ihre Anlagen zu betreiben.

Ich persönlich empfinde, anders als @SAH , die DCC-Programmierung mit CV-Nummern als lästig. Es ist vielleicht erträglich, wenn man nur Decoder einer Marke hat, die alle dieselbe CV-Tabelle verwenden; der Durchschnittsmodellbahner - jedenfalls wenn er die Frage nach den Protokollen stellt, was auf Offenheit gegen verschiedene Hersteller hinweist - hat dann auch verschiedene Decoder im Einsatz. Noch dazu kommt, daß die Zahl der verfügbaren CV längst nicht mehr ausreicht, um hochtechnische Decoder einzustellen, und dann komplizierte CV-Abfolgen gesendet werden müssen, die der Decoder auch richtig empfangen und umsetzen muß.
Mfx erläßt einem die Kenntnis der CV ab und bietet sofort die grafische Oberfläche. Gewiß, die gibt es bei manchen Programmern auch - die sind aber ebenso proprietär, wie es dem mfx-Protokoll immer vorgeworfen wird. Und es gibt eine freie Open-Source-Software, deren Name mir gerade entfallen ist, die aber immer noch sehr nach DOS-Oberfläche aussieht - aber sie ermöglicht es, Decoder zu programmieren, sobald sich ein Altruist der Sache angenommen und die entsprechenden Masken und Fenster programmiert hat. Danach muß nur noch die Zentrale mitspielen...

So setzt aber jeder die Akzente dessen, was ihm wichtig ist, anders. Und darum kann m.M.n. nur gesagt werden: sag uns, was du umsetzen willst, und wir sagen dir, ob das mit dem einen oder anderen Protokoll (und, nicht zu vergessen, der dazu erhältlichen Hardware) einfacher geht.


Mit vielen Grüßen

Wolf 🐺


werner1952 und Andreas85 haben sich bedankt!
Railwolf  
Railwolf
Metropolitan (MET)
Beiträge: 2.745
Registriert am: 08.07.2019
Gleise alle Arten von Skipiste
Spurweite H0
Steuerung tams RedBox
Stromart AC, Digital


   

PIKO Smartdecoder 4.1 -> Decodersperre lösen
DCC Protokoll Märklin Drehscheibe ?

  • Ähnliche Themen
    Antworten
    Zugriffe
    Letzter Beitrag
Xobor Einfach ein eigenes Forum erstellen
Datenschutz