Mein Senf zu dem Thema:

Aktuell ist mir nur EIN Decoderhersteller (von den 3 Dutzend, die sich am Markt tummeln) bekannt, der einen neuen Lok-Decoder ein Planung hat, der einen Funktions-EINGANG aufweist!
Wenn der Decoder einen EINGANG hat, dann hat er was zu MELDEN.

Ob das mit MFX oder DCC geht, ist mir persönlich egal. Aber ich habe BEDARF für solche Spielzeuge!

Ich habe auch nix dagegen alte Zöpfe abzuschneiden wenn das neue Produkt dann "besser" ist?!

Doch was heisst das? Wann ist ein Protokoll besser als das alte? Doch nur dann, wenn es Möglichkeiten für die Anwendungen zulässt die das alte Protokoll nicht oder nur mit erheblichem Aufwand bieten kann?!

Die Diskussion wird IMHO falsch geführt, denn so ist es das Problem mit der Henne und dem Ei:

- wofür braucht man ein neues Protokoll wenn es keine Anwendungsfälle gibt?
- man hätte ein paar Anwendungsfälle die heute nicht funktionieren, hat aber kein passendes Protokoll?

Schwierig. Ich mache das gleiche Thema gerade mit "IPv6" durch ...


Viele Grüße,

Kalle

Hi,

Zitat von ozoffi

---

Hallo!
Da ich ja erwähnt wurde und nun lese, dass es offenbar gar keine "Ärgernsise mit DCC" gibt ... nun ja, wer eine digitale Steuerung nur als Mehrzugsteuerung benutzt, wird kaum Ärgernisse finden - bis auf die Üblichen, begründet durch zu wenig Leistung, oder unzureichender Kurzschlußerkennung etc. (DAS hat aber mit dem Protokoll an sich nichts zu tun).

---

Tja, und wie war das noch mal mit dem CV Read ??
Da hat ein Hersteller gemeint solche Befehle sind 2x zu senden und ein anderer dachte, wenn
der beim 1. mal nicht reagiert, dann ists ein Fehler, ...

Oder da war doch auch noch so eine Sache mit der Verwendung des Broadcast Channels.
Lt NMRA steht dort ....., aber dann wurde im stillen Kämmerlein beschlossen es anders zu machen.

Nur mal zwei so DCC Ärgerniss Meldungen, welche mir ohne langem Suchen so einfallen.

Mir ist es dabei vollkommen egal ob nun A oder B recht hat, denn unterm Strich bin ich der
(Der MoBahaner/Käufer) 'Dumme'.

Nur abgesehn von solchen Dingen, hat O.Zoffi ganz sicher recht, da gibt es 28 DCC Funktionen,
rein theoretisch auch noch diese Binary States und Analog Fx soll es da auch noch wo geben.
Tja, aber die Fx Zuordnung hört irgendwie bei 14 auf, und selbst da kann man nicht jede
'Taste' jedem 'Ausgang' zuordnen, von Sounds will ich da gleich gar nicht erst anfangen.

Das aber bitte nun nicht falsch verstehen, ich will keineswegs, das alle Dekoder das gleiche
können und vollkommen 'uniform' funktionieren.
Aber zumindest eine grundsätzlich einheitliche Struktur, an die man sich halten kann
sollte schon machbar sein. Was dann jeweils im Detail 'drinnsteckt' kann jeder Hersteller
halten wie er will. Nur es ist schon ein massiver Fortschritt, wenn man weis, unter CV10.00
befinden sich eben die Angaben für Taste '0'.

Also sich einfach hinzustellen und zu sagen, bei DCC gibts keine Probleme, ist genauso,
als würde ich sagen, mfx hat keine Probleme.

Ich nutze zum Fahren MS1, MS2 und CS2, und mir ist bisher noch kein einziges hier angeführtes
Problem untergekommen. Dewegen lese ich die diverse Ärgernachrichten trotzdem,
und wenn Sie mir 'verdächtig' sind, versuche ich die auch nachzustellen, einfach um
im Falle des Falles vorbereitet zu sein. Gelungen ist mir das aber bisher nicht, das besagt
aber im Grunde nur, das ich eben mit meiner Ausrüstung 'Glück' habe, und keine Montags
Geräte erwischt habe, mehr aber auch nicht.

mfg
Mike

Mensch Leute
Eure Probleme möchte haben........
Ne, eigentlich liber nicht.

hatten wir doch alles beim offenen Brief schon, in leicht abgeänderter Form.

Hallo Heinz,

aber bisher auf einem anderen Niveau. Hoffentlich bleibt das auch so!

Gruss

est2fe

Bei der Gelegenheit mal die Frage, was hat Herr Ziegler bisher erreicht als "Topic Leader" für das immer noch aktive NMRA-"Topic"

Zitat

---

Topic 0603241 — New Packet Format

Peter Ziegler is Topic Leader. The intention is to have the possibility of longer and faster packets.

---

Aus:
http://www.nmra.org/standards/DCC/WGpubl...ion_topics.html

Gibt`s da Leute mit genügend Nähe zu Zimo, bzw. Dr. Ziegler, um etwas über den Stand der Dinge schreiben zu können?

Es scheint wohl darum zu gehen, auf der Basis des aktuellen Protokolls eine Verschlankung und Beschleunigung des Datenverkehrs am Gleis erzielen zu können - so wie das hier auch von einzelnen angeregt wurde?

Gruss,
Manfred

P.S.: Das erweiterte Zimo-Zugnummererkennungssystem heisst laut neuestem Update der Zimo-Homepage "ZACK", vermutlich für "ZIMO Acknowledgement".

Hallo Kalle,

ein Stück weit hast du ja recht. Nur, wenn jede Lok da jetzt jeden "Pieps" zurückmelden würde, dann wäre eine normale embedded-Zentrale irgendwann überfordert. Ein PC könnte das von der Rechenleistung her noch bewältigen. Nur wollen viele nicht unbedingt immer einen PC dabei haben. Das kann ich sogar verstehen. Ebenso müsste irgendwann der Rückkanal vermutlich mehr Daten übertragen können, als der Kanal von der Zentrale zum Decoder. Das ist aber nicht wirklich unser Wunsch, oder etwa doch? Wenn ja, dann frage ich, warum denn?

Auf was ich raus will ist folgendes:
Komplexe Funktionen sollte man, sofern sie nicht auch andere "Verkehrsteilnehmer" beeinflussen, mit lokal verteilter Intelligenz begegnen. Was meine ich damit? Ein gutes Beispiel ist der "Kupplungswalzer". So etwas kann man mit Hilfe von einer in der Zentrale ablaufenden Steuerungssequenz machen, oder einfach dem lokalen Rechner (= Decoder) das übertragen und zu dem nur sagen: "Hinten abkuppeln". Den Rest erledigt der Decoder selber, also kurz zurücksetzen, hintere Kupplung öffnen, wieder vorfahren, hintere Kupplung abschalten.
Das kann man aber auch aufwendig mit Hilfe einer ausgeklügelten Rückmeldung über das Gleis lösen: Lok langsam rückwärts mit x km/h fahren lassen, dabei die zurückgelegte Strecke zur Zentrale melden. Wenn x cm/mm erreicht sind oder der Melder "Wagen auf Druck" meldet, Lok anhalten. Kupplung betätigen vorwärts, bis ca. 2 cm laut Rückmeldung ereicht sind, dann anhalten und Kupplung abschalten. Das alles wird von der Zentrale initiiert, gesteuert und überwacht, benötigt Schienenbandbreite und einen sehr guten Rückmeldekanal. Aber mit etwas mehr Hirnschmalz im Decoder und einem erweiterten Protokoll wäre in diesem Fall nicht mal der Rückkanal nötig, vielleicht noch eingeschränkt als Quittung, dass alles abgearbeitet ist.

Bei deinem Beispiel mit dem "Melden"-Eingang (wenn ich mich recht erinnere, langsam vorfahren, bis man eine Wagengruppe erreicht hat und dann wieder anhalten) das ist auch so ein Fall für den es eigentlich besser wäre, das würde der Decoder gleich selber erledigen, denn er merkt es (über seinen "melden"-Eingang) zuerst, wenn er die Wagengruppe erreicht hat, und kann dann viel schneller reagieren, als wie wenn das über die Zentrale gesteuert werden würde, mit allen Latenzen, die dabei auftreten. Ich würde da dem Decoder einfach von der Zentrale so ein lokales Macro zum Abarbeiten übertragen und es dann den Decoder ausführen lassen. Warum eigentlich nicht? Der Decoder meldet dann einfach per 1-Bit Quittung zurück, dass er fertig ist, oder per RailCom im Klartext, wenn etwas nicht geklappt hat.

Für Multitraktionen wäre es auch besser, wenn der Decoder selber die vorgegebene Speed versucht einzuhalten, als dass da über eine eingemessene Kennlinie im Steuerungsprogramm mit allen mathematischen Möglichkeiten versucht wird, mehrere Loks synchron fahren zu lassen. In diesem Fall würde ich eine Möglichkeit vorsehen, den Decoder in echten 1:87 km/h fahren zu lassen. Das Einmessen ist dann nicht für das PC-Programm oder die Zentrale, sondern für den Decoder in genau dieser Lok. Der Decoder wird zusammen mit dem Fahrzeug eingemessen und die Ergebnisse in einer Tabelle im Decoder hinterlegt, dass wenn die Zentrale 80km/h vorgibt, der Decoder mit seinen technischen Möglichkeiten das auch versucht einzuhalten. Der kann das viel besser und genauer als eine Zentrale oder PC über einen Rückmeldekanal. Dann ist so eine Rückmeldung ala Tachowelle vermutlich nicht mal mehr unbedingt nötig und die Technik dahinter kann man sich nebenbei auch noch sparen.

Klar, dass man, wenn man in km/h fährt, bei Multitraktionen auch auf eine gemeinsame alternative Consistadresse umschalten muss, damit bei allen daran beteiligten Decodern der Fahrbefehl, in diesem Fall über die Consistadresse, auch gleichzeitig ankommt. Die ABV muss in so einem Fall auch auf allen Decodern automatisch auf gleiche ABV-Zeiten (nur dem Consistdatensatz zugeordnet) umgeschaltet werden.

Ich wiederhole mich: Wenn ich das bisher Machbare sinnvoll einsetze, sind heute schon viele Sachen möglich.

Ich bin mir sicher, uns fallen noch weitere gute Beispiele ein. Man muss da nur etwas das Oberstübchen in Bewegung bringen.

Gruss

est2fe

Mike,

Zitat

---

Tja, und wie war das noch mal mit dem CV Read ??
Da hat ein Hersteller gemeint solche Befehle sind 2x zu senden und ein anderer dachte, wenn
der beim 1. mal nicht reagiert, dann ists ein Fehler, ...

Oder da war doch auch noch so eine Sache mit der Verwendung des Broadcast Channels.
Lt NMRA steht dort ....., aber dann wurde im stillen Kämmerlein beschlossen es anders zu machen.

Nur mal zwei so DCC Ärgerniss Meldungen, welche mir ohne langem Suchen so einfallen.

---

Sind das nicht eher RailCom-Ärgernisse?
Wenn ich nach Ärgernissen und Problemen mit DCC suche, ist die Suche ziemlich erfolglos.

Zitat

---

aber bisher auf einem anderen Niveau. Hoffentlich bleibt das auch so!

---

Du meinst Wolke 7 Niveaux ?

Ne im Ernst: erwartet ihr im wirklich von einer profitorientierten Firma ein komplett neues System zu Steuerung von Modelleisenbahnen ?
Das scheitert doch alleine schon an der Kompatibilität.
Kein Mensch würde heute mfx fahren wenn er seine alten Loks nicht mehr Fahren lassen könnte.

Also wenn ihr was revolutionäres erwartet, dann setzt euch zusammen und entwickelt etwas neues.

Eine Idee gebe ich mal vor:
Meine Idee zu etwas komplett neuem gehen dann schon eher Richtung Funksteuerung. (etwa 2,4Ghz ? )
Die Geleise werden mit einer banalen Gleichspannung gespiesen von einem 0815 Speisegerät ohne jegliche inteligenz. Erst mal kein Protokoll nichts. Jede Lok hat einen 2,4Ghz Empfänger/Sender genauso wie die mobile, akkugespiesne, oder auch stationäre, "Funkzentrale". Die Zentrale könnte mittels eines USB Senders/Empfängers durch einen PC ersetzt werden.
Für Positionsbesimung montiert man über der Bahn an der Decke 3 (oder mehr) Sateliten die mittels laufzeitunterschiede die Position jeder Lok bestimmen könnten.
Oder aber jede Lok moduliert der Speisespannung eine Kennung auf. Mittels Trennfilter an den Streckenblockgrenzen wird verhindert, dass sich die Kennung grossflächig ausbreitet. Jeder Streckenblock erhällt nun einen "lokalen Detektor" und meldet via Funk die Lokkennung. Zusammen mit der (von der Lok direkt) übermittelten aktuellen Geschwindigkeit und oder dem zurückgeleten Weg ab letztem Streckenblocktrennfilter, liessen sich de Positionen gar ohne die Sateliten bestimmen. U.U sogar für mehrere Loks im selben Abschnitt.
Weichen und andere Magnetartikel erhielten ebenfalls einen Funk Sender/Empfänger

Ggenügend revolutionär?

Ich verstehe nicht, warum manche das "alte Zeug" so verteidigen, vor allem wenn das Fundament nicht mehr die "neue Last" tragen kann. Heute haben wir das Internet2 (nicht zu verwechseln mit dem Web 2.0). Hätte man damals das Internet nicht umgestellt, würden nur ein paar Universitäten und das Militär das Internet benutzen. Man hat aber die Probleme im alten Protokoll erkannt und festgestellt, das die verbesserungen dort nur besserer Pfusch waren. Deshalb hat man ein neues Protokoll entwickelt.

Als Anfänger will ich bei mir nicht Hunderte Strippen ziehen müssen, nur damit etwas Altes funktioniert, wenn man es Neu besser machen könnte. Warum können Weichen, Signale, etc. ihre Befehle auch über das Gleis erhalten und bestätigen, ohne dass der Betrieb gefährdet wird und ohne das gepfuscht wird (Railcom Kurzschluss). Wenn ein Anfänger neben der Stromversorgung noch hundert andere Strippen ziehen muss, sucht er sich ein "einfacheres" Hobby.


Es gibt schon lange erprobte und robuste Techniken, die nur noch portiert werden müsste.
Das beste Beispiel ist Power Lan. Es passt wie die Faust aufs Auge zu der Modellbahn. Hier wird ein Netzwerk über die bestehenden Stromverkabelung realisiert. Es ist bis zu 833MBit/s schnell und hat eine Reichweite von 300m. Es funktioniert auch in alten Häuser, wo die Elektroinstallationen nicht so hochwertig sind. Es braucht keine Zentrale (kann aber eine haben), da es nach dem Peer-to-Peer (P2P) Prinzip funktioniert. Da die Technik schon alt ist, ist sie auch billig und klein genug, um in eine Lokomotive zu passen - einfach den Dekoder tauschen und fertig. Die Bandbreite auf der Schiene ist hoch genug, um Echtzeit-Betrieb und Kommunikation mit allen Teilnehmern zu gewährleisten. Und durch die P2P Technik wird die MoBa automatisch Plug&Play fähig. Dies ist vor allem für Einsteiger interessant, da diese keine Romane studieren müssen/wollen, um das erste digitale Erfolgserlebnis zu haben.

Das Protokoll ist eine andere Geschichte. Damit es wirklich Zukunftssicher ist, sollte es dem ISO/OSI-Schichtmodell entsprechen. Auch hier ist die Technik schon vorhanden. Mann kann TCP/IP oder UDP/IP nehmen.

Das Problem sehe ich bei den Firmen, die Ihren Gewinn abschröpfen wollen und sich deshalb gegen einfache und weit verbreitete Methoden wehren.

Edit:Typo

Zitat von est2fe

---

Ich würde da dem Decoder einfach von der Zentrale so ein lokales Macro zum Abarbeiten übertragen und es dann den Decoder ausführen lassen. Warum eigentlich nicht? Der Decoder meldet dann einfach per 1-Bit Quittung zurück, dass er fertig ist, oder per RailCom im Klartext, wenn etwas nicht geklappt hat.

---

Aber gern!

Bislang haben wir für ein gesichertes ANKOPPELN einer Lok an einen Wagenverband keine hinreichend sichere Lösung! Die bisherigen Lösungen (ich nenne hier mal die alte Messe-Fleischmann Anlage mit Kopfbahnhof wo automatisch die Lok gewechselt wurde ... schon vor vielen Jahren) benötigen alle sehr viel "Rückmelder" in Form von Schienenrückmeldern um zu wissen wo die Lok ist und auch dann ist es ein Ratespiel, wann die Lok auf den Wagenverband trifft. Meist schiebt die Lok dann noch ein wenig die Wagen nach um sicher zu sein, dass auch wirklich angekuppelt wurde ...

Wenn das durch den Decoder automatisch getriggert werden kann, ähnlich dem Abkuppelmanöver von T4T - nun, ich habe da nix dagegen und wäre ein potentieller Käufer!

Also brauchen wir eine "Makrosprache" für die Decoder ... oje, wer kommt denn von den sehr verehrten Kollegen damit noch zurecht?!


Viele Grüße,

Kalle

Zitat von kaeselok

---

Also brauchen wir eine "Makrosprache" für die Decoder ... oje, wer kommt denn von den sehr verehrten Kollegen damit noch zurecht?!

---

Ich denke, bei DCC2 werden auf die Decoder je nach Bedarf kleine APPs gespielt. Und es gibt Klartext-Programmierung und Klartext-Befehle, die gesendet werden. Eine Kamera-Funktion ist als Standard mit dabei und Geräusche lassen sich im laufenden Betrieb aufspielen und wieder löschen.

Zitat von Peter Müller

---

Zitat von kaeselok

---

Also brauchen wir eine "Makrosprache" für die Decoder ... oje, wer kommt denn von den sehr verehrten Kollegen damit noch zurecht?!

---

Ich denke, bei DCC2 werden auf die Decoder je nach Bedarf kleine APPs gespielt. Und es gibt Klartext-Programmierung und Klartext-Befehle, die gesendet werden. Eine Kamera-Funktion ist als Standard mit dabei und Geräusche lassen sich im laufenden Betrieb aufspielen und wieder löschen.

---

... und nicht vergessen, daß uns dann auch der "1:87-Lokführer" zuwinken wird.

Didi

Hallo!

Nun wegen der "Macrosprache" mache ich mir weniger Sorgen - man denken da nur an die "Sprache" von LEGO ... Die wird mitels grafischen Elementen als Ablaufdiagramm gezeichnet. Das können Kinder (dazu müssen sie nicht einmal lesen können)!

Die Funkidee, oder auch das "Powerlan" finde ich gut!

Es gibt bereits mehr als genug fertige Produkte, die man für Modellbahnsteuerungen verwenden könnte, ohne dabei unendlich viel neu entwicklen zu müssen.

Ich würde als Hersteller zb. Funk und bestehendes DCC koppeln.
Damit könnte Neues neben Bestehenden exisitieren, ohne sich gegenseitig auszuschließen. Auch die Sache mit der "ausgelagerten Inteligenz" sollte genauso sein (ist sie beim Kupplungswalzer ja eh schon).
Die Idee mit den "Satelitten" gefällt mir ausnehmen gut (Reichweite von 20cm bis 20m) - damit wäre imho auch ein "indoor-GPS" machbar und man könnte vieles ohne Gleisabschnitte realisieren (genau darauf spekuliere ich .

Erfreulich, wie viele Leute sich hier beteiligen und gute Ideen einbringen - obwohl offenbar der Mehrheit Vorbildtreue (und um diese beim Fahrverhalten, Effekten etc. zu erreichen ist Technik nötig!) eher egal ist (also ganz so wurscht ist das dann ja doch nicht

Übrigens, was die Sache mit dem Funk und bestehender Technik angeht:
Im http://www.spassbahn.de Forum beschäftigt man sich genau damit. Hier werden bestehende 2,4GHz Sender (WLAN) und handelsübliche Bauteile/Technik verwendet, um Loks zu steuern.
Gefahren wird mit dem iPhone als Handregler. Die Zentrale ist ein PC und die Fahrzeuge in "G-Spur" ... genau das ist aber "unser Problem"! Noch sind die Teile in Summe zu groß und die "G-Loks" vollgestopft damit. Es geht denen aber mehr um die Technik und darum alles mit handelsüblichen Teilen selbst bauen zu können - das scheint gelungen.
Derzeit wird hier auch "nur" gesteuert. Also keine Rückmeldung etc. Ist im Grunde lediglich eine ander Art einer Funkfernsteuerung auf WLAN Basis (aber noch unidirektional).
Soweit ich das verfolgt habe bestehen auch keine Ambitionen für Rückmeldung, Positionsbestimmung, div. Effekte etc. - denen geht es nur um das direkte Steuern eines Fahrzeuges, egal ob mit Schienenstrom, oder Akku.
Allerdings gibt es DAFÜR von einigen Herstellern schon entsprechende Lösungen (zb. Aristocraft), die genau das machen! Hier auf der gleichen Ebene eine Bastellösung zu entwickeln, halte ich eigentlich für wenig Sachdienlich.

Wenn schon was Neues, dann wären Entwickler gut beraten, sich bestehende Systeme WELTWEIT anzusehen (nicht nur DCC!) und sich das Beste davon herauszupicken!
Ich meine damit dann allerdings nicht nur die Technik, das Protokoll etc., sondern vor allem die Usability! Wie sehen Handregler aus, was bieten sie, was kann die Zentrale an Features, was der Decoder ...

Bei vielen Systemen kommt es mir so vor, als hätte ein Technikfreak sein Demoboardlayout in ein Gehäuse gepfercht - und das ist jetzt der Handregler (bestes Beispiel imho Digitrax!).
Andere haben einfach ein altbekanntes Tachenrechnerlayout genommen, ein fetziges Gehäuse drum rum designd und jetzt darf der User sich die Finger brechen, wenn er mit 10 Tasten 28 Funktionen bedienen will, wobei immer noch jede Taste eine fix zugeordnete Funktion hat...

Man könnte beim Funktionmapping das Pferd nämlich auch von hinten aufzäumen:
Wenn ich die gewünschte Funktion an die Position meines Handregler legen und dazu noch ein Symbol definieren kann, dann ist es mir eigentlich egal, an welchen Funktionsausgang diese Funktion am Decoder liegt!
Denn eigentlich zäumen wir ja JETZT das Pferd verkehrt herum auf!
Um zb. den Rauch auf der Taste 5 zu haben, muss ich diese Funktion IM DECODER ummappen, wenn der Rauchgenerator an FA1 angeschlossen ist....
MIR ist es aber sowas von egal, ob das nun F5 an FA1 ist! ICH will lediglich den Rauch mit der Taste rechts aussen in der 2. Reihe schalten. Und weil ich sehr vergesslich bin, will ich beim Anwählen einer Adresse deren Funktionen grafisch dargestellt auf meinen Tasten sehen.

Wie Ihr seht, wäre es vielleicht besser, "DCC2" nicht nur von der Protokoll-, Übertragungsseite her zu sehen, sondern in seiner Gesamtheit. Denn sonst haben wir vielleicht dann ein super tolles und sauschnellen bidirektionales Protokoll mit einem super Übertragungsweg, möglicherweise noch weitere Features im Decoder, aber der Rest bleibt unverändert und zieht mit diesen Gegebenheiten nicht mit. Man hat dann immer noch nur EINEN Regler für die Geschwindigkeit (wie war das mit "aktiven" bremsen?) und ein 10er Tastenfeld aus dem Taschenrechner für die Funktionen.
Funtkionen von Fahrzeugen einzeln in Mehrfachtraktionen aufrufen ist jetzt nicht durchdacht und eher umständlich möglich - wird sich dann nicht ändern, weil das Eingabegerät das weiterhin nicht berücksichtigt ...

Wenn wir uns auf DCC2 = IEEE 802.11 einigen (oder von mir aus auch IEEE 802.15, ich weiß nicht was besser geeignet wäre), wäre ja schon viel gewonnen. Handregler, Zentralen, Decoder, etc. haben damit nichts zu tun, dass sind andere Themen. Einen Zwischenschritt wie RailCom oder Gleichwertiges braucht es dann nicht mehr. Und die Nachfolge von WLAN oder Bluetooth erhält zu gegebener Zeit Einzug auf die Modelleisenbahn.

DCC/Mfx/MM bleiben bei Bedarf im Gleis und können weiter genutzt werden. In einer ersten Phase regelt DCC2 in den meisten Fällen smarte Funktionen, keine harten Kommandos. Gerade die smarten Funktionen sind es ja, wo DCC an seine Grenzen stößt. Bei den harten Kommandos ist DCC ausgereift und kann durchaus weiter verwendet werden (50 Jahre Kompatibilität als Vorgabe).

Das wäre ein Konzept, bei dem jeder weiter machen kann wie bisher oder aber mit dem Stand der Technik erweitern. Ich warte schon seit Jahren darauf, dass das Einzug erhält. Meine Zuversicht diesbezüglich steigt von Jahr zu Jahr. Gleichzeitig schwindet die Bereitschaft, Geld für Eigenentwicklungen der MoBa-Hersteller auszugeben. Als ESU RailCom kaperte, war die Entscheidung eigentlich gefallen.

IEEE 802.1x hätte den Vorteil, dass man es in analoge Anlagen integrieren kann.

Hi,

Zitat von est2fe

---

Nur, wenn jede Lok da jetzt jeden "Pieps" zurückmelden würde, dann wäre eine normale embedded-Zentrale irgendwann überfordert. Ein PC könnte das von der Rechenleistung her noch bewältigen. Nur wollen viele nicht unbedingt immer einen PC dabei haben.

---

Nun das manche Zentralen damit Probleme haben könnten, will ich nicht beurteilen.
Nur EIN Piep nach dem Befehlserhalt ist nicht echt viel, aktuell braucht ein DCC Befehl
so etwa 5mS und das ist selbst für 'kleine' Controller keine echte Anforderung.

Zitat von est2fe

---

Komplexe Funktionen sollte man, sofern sie nicht auch andere "Verkehrsteilnehmer" beeinflussen, mit lokal verteilter Intelligenz begegnen. Was meine ich damit? Ein gutes Beispiel ist der "Kupplungswalzer".

---

Dem kann ich nur zustimmen. Solche Aktionen per Zentrale durchzuführen geht 'vor-Ort'
einfach besser.

Zitat von est2fe

---

Für Multitraktionen wäre es auch besser, wenn der Decoder selber die vorgegebene Speed versucht einzuhalten, als dass da über eine eingemessene Kennlinie im Steuerungsprogramm mit allen mathematischen Möglichkeiten versucht wird, mehrere Loks synchron fahren zu lassen.

---

Auch richtig, allerdings sind dazu Befehle notwendig, welche keine FS sondern kmH vorgeben.
UND diese Vorgabe muss ziemlich genau sein.

Zitat von est2fe

---

Ich wiederhole mich:
Wenn ich das bisher Machbare sinnvoll einsetze, sind heute schon viele Sachen möglich.

---

Ich denke, vieles von Deinen Vorstellungen (und Denen kann ich viel abgewinnen) ist sogar
schon zum Großteil vorhanden, nur bisher hats noch keiner 'zusammengeführt', und ein
paar aber eben wesentlichen 'Ergänzungen' gibts noch nicht.
Nur genau darum soll es bei dem Thema ja gehen.

mfg
Mike

Hi

Zitat von Peter Müller

---

Wenn wir uns auf DCC2 = IEEE 802.11 einigen (oder von mir aus auch IEEE 802.15, ich weiß nicht was besser geeignet wäre), wäre ja schon viel gewonnen. Handregler, Zentralen, Decoder, etc. haben damit nichts zu tun, dass sind andere Themen. Einen Zwischenschritt wie RailCom oder Gleichwertiges braucht es dann nicht mehr. Und die Nachfolge von WLAN oder Bluetooth erhält zu gegebener Zeit Einzug auf die Modelleisenbahn.

---

Nun WLan würde durchaus Sinn machen, nur leider spielt es das noch längerfristig nicht.
Zum einen ist ein WLan Chip (der reine HF Teil) noch ein rechtes Monster, das kann man bei
Spur 0/1 sicher unterbringen, aber spätesten bei H0 ist Schluß.
(HF kostst einfach Platz). Nur mit den reinen Sende/Empfangs Chip ist da noch nicht getan,
ein Prozessor, der WLan gemäß Norm hinbekommt braucht auch ne Menge Rechenleistung.
Nimmt man das alles zusammen, dann sind zumindest derzeit gute 3cm2 mehr Platz notwendig
und auch gleich noch gute 20€ Materialkosten. Das würde gute 60 ... 100€ Mehrkosten/Dekoder
bedeuten, ich denke, DA hätten die 'Ist doch alles zu teuer Lamentierer' dann ein echtes
Argument.

Einen MoBa WLan Chip werds aber erst geben, wenn alle anderen Bereiche abgedeckt sind,
wir sind für Chip Hersteller leider kein Markt.

mfg
Mike

Hi,

Zitat von ozoffi

---

Nun wegen der "Macrosprache" mache ich mir weniger Sorgen - man denken da nur an die "Sprache" von LEGO ... Die wird mitels grafischen Elementen als Ablaufdiagramm gezeichnet. Das können Kinder (dazu müssen sie nicht einmal lesen können)!

---

So ähnlich denke ich auch. Mittlerweile gibt es da schon einige 'Kindergerechte' Beispiele,
wie man Ablaufdiagramme hinbekommen kann.
Ob das nun 'Bauklötze' sind, einfache Listen, etc. wenns 'Kinder' begreifen, dann sollte es
für einen MoBahner auch reichen. Wenn nicht, dann will er sich einfach nicht damit beschäftigen.

Zitat von ozoffi

---

Man könnte beim Funktionmapping das Pferd nämlich auch von hinten aufzäumen:
Wenn ich die gewünschte Funktion an die Position meines Handregler legen und dazu noch ein Symbol definieren kann, dann ist es mir eigentlich egal, an welchen Funktionsausgang diese Funktion am Decoder liegt!
Denn eigentlich zäumen wir ja JETZT das Pferd verkehrt herum auf!

---

Das denke ich mir auch schon lange, im Grunde will ich ja die jeweilige Funktion an einer
bestimmten Stelle haben.
Auf einem PC Desktop kann ich die diversen Elemte ja auch 'rumschieben', ohne deswegen
die dahinterliegenden Programme zu ändern. Eine klare Trennung zwischen GUI und Funktion
sollte schön langsam auch bei der MoBa Einzug halten.

Zitat von ozoffi

---

Wie Ihr seht, wäre es vielleicht besser, "DCC2" nicht nur von der Protokoll-, Übertragungsseite her zu sehen, sondern in seiner Gesamtheit.

---

Auch richtig, nur irgendwelche Elektrik Definitionen, Frame Definitionen, Rückmelde Geschichten
alleine reichen sicher nicht für DCC NEW, da muss man schon weiter gehen.

Wobei, irgendwo muss man ja anfangen, und auch wenns nicht so 'brikelnd' ist, ohne dem Low-Level
Zeug, funktionierts leider nicht.
In dem Punkt kann ich alle, welche Richtung WLan, Power Lan schielen voll verstehen.
In den Fällen ist genau dieser Low-Level Aufwand einfach mal 'delegiert' bzw. 'fertig'.
Aktuell sind diese beiden Techniken aber einfach noch extrem Teuer und wenn überhaupt den
grossen Spuren vorbehalten.

mfg
Mike

Zitat von MikeF

---

Aktuell sind diese beiden Techniken aber einfach noch extrem Teuer und wenn überhaupt den grossen Spuren vorbehalten.

---

Dann warte ich aber lieber, als noch einen Zwischenschritt zu gehen.

Ich sehe schon, mit Wolke 7 hatte ich gar nicht so unrecht.

Das Problem etwas neues zu machen, sehe ich eigentlich weniger bei den Grundlagen der Technik. Power Lan ist doch aber wie schon gesagt immer noch Grössenordnungen zu gros und auch zu heiss für eine H0 Lok. Da wäre also schon noch einiges zu entwickeln.
Das Problem sehe ich dann auch eher bei der Zeit. Neue Techniken sind heute so schnelllebig, dass die Entwicklungskosten innert kürzester Zeit eingespielt werden müssen. Mit den den modellbahntypischen Stückzahlen dürfte das niemals möglich werden.
Deshalb wette ich, das wir in 20 Jahren noch bei bei DCC und mfx sind, bestennfalls bei DCC+ und mfy )

Zitat von Heinzi

---

Deshalb wette ich, das wir in 20 Jahren noch bei bei DCC und mfx sind, bestennfalls bei DCC+ und mfy )

---

Oh?! MFY löst also MFX ab?!

Ist ja toll!


Viele Grüße,

Kalle

*Umfrage* gefällig?

Zitat von Heinzi

---

.....Mit den den modellbahntypischen Stückzahlen dürfte das niemals möglich werden....

---

Moin,


und die modellbahntypischen Stückzahlen werden in 20 Jahren nochmals mind. halbiert, weil die Modellbahner sich mehr wie halbieren bzw. aussterben und nix mehr nachkommt.

Daher war mfx vor 7 Jahren nochmal der letzte Versuch mit was neuem....und hat es die Millionengewinne für M* gebracht ?

Heute was Neues zu bringen ist schon wesentlich schwieriger als 2004 und in 20 Jahren, naja da kann jeder mal selbst drüber nachdenken.

Nicht nur das die Modellbahner weniger werden, auch das freie zur Verfügung stehende Geld fürd Hobby wird immer weniger.


Gruß Markus

Zitat von Marky

---

Nicht nur das die Modellbahner weniger werden, auch das freie zur Verfügung stehende Geld fürd Hobby wird immer weniger.

---

Kannst Du die Aussage mal untermauern?

Zitat von Peter Müller

---

Zitat von Marky

---

Nicht nur das die Modellbahner weniger werden, auch das freie zur Verfügung stehende Geld fürd Hobby wird immer weniger.

---

Kannst Du die Aussage mal untermauern?

---

Moin Peter,


neee untermauern natürlich nicht, aber mein "Feeling" sagt mir das. Man(n) kommt ja rum und bekommt so manches mit.



Gruß Markus

Hallo,

ich muß noch was zu Funklösungen sagen, egal auf welchem Standard die basieren: man darf in zwei engen Bändern, welche hier in Frage kommen, anmeldefrei senden, aber nur mit 10mW. Das geht recht brauchbar bei freier Sicht, wenn Metall und/oder Störungen (andere Netze) dazwischen sind, wird es spannend. Zum Test möge man einfach mal den WLAN-Router in die Gleiswendel oder unter einen Berg mit Fliegengitter stellen. 2,4GHz hat 12cm Wellenlänge.

Und zu GPS: Das basiert auf Triangulierung von mind. 3 Ortskoordinaten. Wenn ich da 10cm genau werden will, dann brauche ich 300ps Zeitauflösung bei der Erfassung der Sender (und entsprechend genau sychnronisierte Sender), auch das ist eine ziemliche Herausforderung und bedeutet einiges an Rechenleistung für die Filter. Und ich denke, auch da wird man mit den Reflexionen und Abschattungen kämpfen.

mfg W.K.