Was erwarte ich von einem OpenSourche Decoder?

[Muenchner Kindl]

Auch hier ein herzliches Hallo,

was erwarten wir eigentlich von einem solchen Projekt? Ohne jetzt groß ins Detail zu gehen, welche Erwartungen habt Ihr und was könnte das Ziel sein?

[Mobahner]

Hallo,

ich würde mir wünschen, endlich eingetretene Pfade zu verlassen. Also bspw. keinen speziellen Lokprogrammer vorhalten zu müssen oder auch die Programmierung/Einstellung des Dekoders über eine Software am PC vornehmen zu können. Ich bitte euch Leute, CVs sind doch die Altlast aus den 1980er Jahren! Wenn man die ganzen Fragethemen zu der Berechnung und überhaupt Bedeutung der einzelnen CVs liest... ein großes Durcheinander! Fast jeder Hersteller kocht hier sein eigenes Süppchen...
Ein gesponnenes Szenario: Ein Programmiergleis mit USB-Anschluss (Spannung mal außen vor gelassen), welches man am Rechner anschließt und über eine grafische (!) Software den Dekoder in der Lok einstellt. Ebenso das Aufspielen eines anderen Sounds auf die Lok, Dekoderupdates... Hach wäre das schön!
Ich möchte also weg von proprietären (teuren) Komponenten (warum benötigt man 15 verschiedene Dekoder-Programmer?), hin zur Nutzung von am Markt etablierten (günstigen) Geräten.


Grüße

[bahnix]

Was erwarte ich von einem OpenSourche Decoder?

Gesundheit!

Grüß Gott,

Thomas, womöglich hast Du da ein "h" zu viel in der Überschrift.


Von einem OpenSource Dekoder erwarte ich, daß er zunächst einmal Standards einhalten kann. Für eine neue exklusive Richtung wird er vom Start weg nicht die Kraft haben, alles Etablierte beiseite zu schieben. Es wäre fatal, die fünfundzwanzigste Hardware-Schnittstelle und das zwölfte neue Protokoll in den Markt drücken zu wollen. Meines Erachtens wäre die mtc21 Schnittstelle vorteilhaft. Ich kann die patentrechtliche Situation nicht einschätzen, aber der Märklin mLD/mSD trifft bei mir den Punkt in Bezug auf Schnittstelle und Protokolle. DCC und mfx wären toll. Die Abgrenzung im Markt wären Zusatzfunktionen und -schaltungen, die entweder aufgesteckt, oder bereits integriert sind.

Die Programmierung über Programmiergleis oder eine geeignete Schnittstelle zum PC mit Hilfe einer Steckverbindung ohne Lokomotive drumherum hätte seinen Charme. Aber die grafische Bedienoberfläche bitte nicht nur auf Microsoft Windows beschränken. Es gibt auch noch GNU/Linux und Mac OS X.

Gruß
Sven

[Der Ruinenbaumeister]

Ich fände es gut, einen Decoder zu haben, bei dem ich das genaue Verhalten der Ausgänge in C programmieren kann, ohne mich mit den Feinheiten des verwendeten Protokolls auseinanderzusetzen. Mit den Decodern von Sven Brandt geht das allerdings schon für einfache Anwendungen, nur dass dort eben Assembler verwendet wird.

Mit einem etwas größer angelegten Projekt könnte man dann nach dem Baukastenprinzip vorgehen. Ich will zum Beispiel gar nicht wissen, wie mein Digitalsignal am Gleis aussieht, so dass ich dafür vorgefertigten Programmcode verwenden würde. Aber eventuell brauche ich die Aktivierung der Ausgänge in einer bestimmten Reihenfolge. Das ließe sich recht einfach in C umsetzen. Und dann will ich vielleicht einen Motor mit PWM ansteuern. Dafür lässt sich dann der Code verwenden, der für den Lokmotor vorgesehen ist etc.

[Wracker]

Hallo.

Ich erwarte von einem OpenSource Decoder

Es soll sich um ein oder 2 Standard Decoderboards handeln kompatible zu den jetzigen Normen (21MTC, ....) pro Spurgröße
Die Motorendstufe soll separat vom Decoder sein. (Wunschdenken)
Einfach zu konfigurieren für jedermann.

Um sich von anderen abzuheben

Ein 2 Draht Bussystem zum Modularen Ausbau.
a) Synchron schalten einiger Decoder (Doppeltration)
b) Ansteuern zusätzlicher Motorendstufen (Sinus-Motoren von Tante M., Multimotor-Loks, Triebwagen,..)
c) Frei programmierbare Funktionsausgänge.
d) Modulares Sound System (mehrere Soundendstufen pro Decoder für Triebwagen)
e) Einfache Soundgestaltung für alle Lok-Typen. Sounddatenbank sollte für gänigen Loks zur Verfügung stehen.

Das ist meiner Meinung nach was ein "user" erwartert und ist auch bereit für solche individualisierbaren Teile tiefer in die Tasche zu gereifen .

MfG Wracker

[SAH]

Guten Abend Mobahner,

Dein Beitrag hat viele gute Ideen, doch meiner Ansicht nach einen entscheidenden Nachteil:

ich würde mir wünschen, endlich eingetretene Pfade zu verlassen. Also bspw. keinen speziellen Lokprogrammer vorhalten zu müssen oder auch die Programmierung/Einstellung des Dekoders über eine Software am PC vornehmen zu können. Ich bitte euch Leute, CVs sind doch die Altlast aus den 1980er Jahren! Wenn man die ganzen Fragethemen zu der Berechnung und überhaupt Bedeutung der einzelnen CVs liest... ein großes Durcheinander! Fast jeder Hersteller kocht hier sein eigenes Süppchen...
Ein gesponnenes Szenario: Ein Programmiergleis mit USB-Anschluss (Spannung mal außen vor gelassen), welches man am Rechner anschließt und über eine grafische (!) Software den Dekoder in der Lok einstellt. Ebenso das Aufspielen eines anderen Sounds auf die Lok, Dekoderupdates... Hach wäre das schön!
Ich möchte also weg von proprietären (teuren) Komponenten (warum benötigt man 15 verschiedene Dekoder-Programmer?), hin zur Nutzung von am Markt etablierten (günstigen) Geräten.

das Fettgedruckte kann nur als Option vorhanden sein, denn sonst wäre ein Großteil potentieller Interessenten weg vom Fenster und vom Interesse: nämlich all jene, die die betreffenden Funktionalitäten nicht nutzen können (z.B: diejenigen sie nur eine CU 6021 haben o.ä.....).
Als Option bin ich sofort dabei, als Ausschließlichkeitskriterium nicht (oder ich habe Dich falsch verstanden).

Nun zu meinen Vorstellungen eines Open Source Dekoders:
wie bei den bekannten OS-Projekten ist die Dokumentation und der Informationsaustausch (RFC's usw) das A und O des Gesamtprojekts. Problematisch wirds dann, wenn Befindlichkeiten geweckt werden, die die vorhandene Patentsituation antasten könnten (z.B. mfx-Funktionalität; man vergleiche mit den mp3-Funktionalitäten unter Linux).
Ein solcher OS-Dekoder sollte nach Möglichkeit sowohl bestehende (ohne diese Kompatibilität ist das Projekt IMHO nicht beständig!), als auch neue und/oder alternative Wege beschreiten können. Die Ansprüche werden sich im Laufe der Diskussionen herauskristallisieren.

mit freundlichen Grüßen,
Stephan-Alexander Heyn

[Alter Schwede II]

Hallo !

Ganz oben steht bei mir, egal was für ein Decoder entwickelt wird, Kompatibilität.

Als Träumerei für unser „New Generation“ Lokdecoder :

Rückmeldung und „Intelligenz“

Wenn ein Decoder nicht nur Informationen verarbeiten kann sondern auch Externe Triggers vermitteln könnte.
Ich denke dabei an so was wie die Rückmeldung von Externe Daten z.B. RFID.

-Das Lok meldet wo er sich befindet und löst entweder extern ( in der Centrale ) oder intern ( Im Zug ) Kommandos aus…

- Auf die Anlage werden „Tags“ verteilt. Ohne Verkabelung….

- Ein kleines Gedächtnis die bei Abfrage sagen könnte wo er ist, wo er zuletzt war. ( Auch nach ein Absturz der Centrale )

So was könnte der gesamte Rückmeldesituation und Zugsteuerung erheblich verändern.
Kurz : Eine BiDi Decoder der etwas mehr kann.

Auch die von „Mobahner“ angesprochenen Decoder zu Decoder Kommunikation finde ich sehr Interessant.

Optimal wäre wenn die Kommunikation Drahtlos erfolgen könnte. ( MiWi / ZigBee ) Egal was für eine Centrale oder Infrastruktur im Einsatz wäre könnte man damit Kompatibilität schaffen.

Wahrscheinlich sind diese „wünsche“ nicht Real umsetzbar. Aber es wäre toll….


Beste Grüsse

Erich

Edit : MiWi / ZigBee

[rainerwahnsinn]

Hallo !
Als Träumerei für unser „New Generation“ Lokdecoder :

Hallo Erich,

Träume können Wirklichkeit werden...
und Beiträge wie deine könnten dies sogar bewirken.

Hier mal ergänzend eine kleine Linksammlung dazu. Achtung: sehr interessant!

Firma: http://www.microchip.com/pagehandler/en ... s/wireless
Programmierung: http://www.microchipdirect.com/
Anbieter: http://www.electronic-data.com/Ausg_red ... 2011_03850
Info: http://zigbee.org/
Detail: http://waste.informatik.hu-berlin.de/~p ... zigbee.pdf

Viele Grüße
Rainer...W

[HeinzH.]

Hallo Freunde,
ich würde mir von einem OpenSourche Decoder wünschen, daß er eine Sound-Nachrüstungsoption hat, sei es über die bekannte SUSI-Schnittstelle oder irgendwie anders. Ich müßte mich dann bei der Digitalisierung älterer Loks nicht mehr vorab entscheiden.....
Bis später,
HeinzH.

[Sharp57]

Hallo Zusammen,

ich halte es für extrem wichtig, unabhängig von Aufbau und den Möglichkeiten der zukünftigen Hardware, dass Otto-Normaldecoderverbraucher sich diesen Decoder entsprechend seinen Vorstellungen über ein ansprechenden GUI "programmieren" kann.

Wenn die Decoderhardware von Kersten Tams (oder anderen Herstellern die mit einsteigen wollen) später in ausreichenden Stückzahlen, und somit zu einen ansprechenden Preis, verkauft werden kann, muß die "Programmierung" einfach sein.

Wenn ich mir anschaue wie viele Anwender bei dem Lopi V4 schon nicht mehr mitkommen wird mir schlecht. Das ist dann nicht mehr Anwenderfreundlich.

Wenn diese Voraussetzungen nicht geschaffen werden dann wird dieses, wie ich finde tolle Projekt, nur einigen Wenigen vorbehalten bleiben und das wäre, wenn es sich in die von Euch gewünschte Richtung entwickelt, jammerschade.

Ich kenne die OpenDCC Seite und lese dort bisweilen auch mal was nach, aber als Plattform für den eigenen Einstieg wäre mir das zu aufwändig. Und ich kann mir auch nicht vorstellen dass dort die Masse der Modellbahner angesprochen wird.

Also, vergesst nicht den Normalanwender der nicht im stillen Kämmerlein Programmiersprachen erlernen möchte und bezieht diese User in eure Überlegungen mit ein. Jeder Fan des Projektes ist ein potenieller Käufer der dazu beitragen kann Stückzahlen an Hardware zu generieren auf der Euer Projekt nachher läuft.

Gruß,

Ingo

[rainerwahnsinn]

Hallo Zusammen,
Wenn die Decoderhardware ... später in ausreichenden Stückzahlen, und somit zu einen ansprechenden Preis, verkauft werden kann, muß die "Programmierung" einfach sein.
Also, vergesst nicht den Normalanwender der nicht im stillen Kämmerlein Programmiersprachen erlernen möchte und bezieht diese User in eure Überlegungen mit ein.
Ingo

Hallo Ingo,

ein herzliches Dankeschön für diese wirklich relevante Anregung!

Denn abgesehen von den techn. Aspekten stellt sich vorrangig ja folgende Kernfrage:

Was könnte einen Modeleisenbahner dazu bewegen,
a) nochmals Geld auszugeben um vorhandene Dekoder abzulösen ?
b) erstmals Geld auszugeben um nun doch zu digitalisieren ?

Ich denke, dass hier für den Modeleisenbahner schon echte Kaufgründe her müssen. Und die Bedienerfreundlichkeit ist ganz gewiss eines davon.

Allerdings muss man hier beim Wortgebrauch etwas unterscheiden. Ich mache das jetzt mal bewusst etwas ausführlicher:

- Programmierung: ist die Erstellung und Anpassung der Software durch die Entwickler. Sie erstellen und modifizieren z.B. die Firmware des Dekoders, aber auch die Benutzeroberfläche auf den Zentralen oder PC-Anwendungen für Modelleisenbahner (Rocrail usw.)

- Konfiguration: ist die Eingabe von Daten/Werten durch den Anwender. Sie liefern die "Betriebsparameter" welche die Software benötigt, um auf die individuellen Bedürfnisse eingehen zu können. Ein typisches Beispiel sind hier die Konfigurationsvariablen (CV's) von Dekodern (Einjustieren des Anfahrkicks, der Höchstgeschwindigkeit, der Licht-/Soundfunktionen, des Rangierbetriebs usw.)

- System: das ist die Software die im Untergrund werkelt, und den technischen Betrieb erst möglich macht (Juhu meine Anlage läuft )

- Anwendung: das ist die Software, die dem Benutzer Funktionen für bestimmte Anwendungszwecke bereitstellt (Dekoderkonfiguration, Gleisplanung, Gerätesteuerung, Schattenbahnhof, etc.). Und dies hoffentlich über eine geeignete Bedieneroberfläche

- Daten: sie sind genau genommen in dem Ganzen das eigentlich Entscheidende (was häufig übersehen wird). Das kann die Lokdatenbank sein, die Werteliste für CV's, Protokolldaten, Betriebsdaten, Positionsdaten, Gleispläne, Normen uvm. Fehlen die Daten bzw. sind sie falsch oder zu ungenau, kann man letzendlich alles vergessen (insbesondere die Programmierung).

Puh, deine Anforderung heisst also, dass der Käufer eine Software zum Dekoder erhält, die ihn bei der Konfiguration seiner Lokdekoder komfortabel unterstützt. Insbesondere bei der Optimierung des Fahrverhaltens und der Konfiguration der Dekoderfunktionen. Und dies gemeinwirtschaftlich für die hiesige Dekoderflotte.

Ja, so eine Software zum Dekoder wäre gewiss ein Kaufgrund! Insbesondere wenn man sich mal anschaut, was die Zentralen sonst so bereithalten.
P.S. könnte ja auch eine App sein

Viele Grüße
Rainer...W

[Sharp57]

Hallo Rainer,
ich versuche mal die einzelnen Punkte zu kommentieren:

Hallo Zusammen,
Wenn die Decoderhardware ... später in ausreichenden Stückzahlen, und somit zu einen ansprechenden Preis, verkauft werden kann, muß die "Programmierung" einfach sein.
Also, vergesst nicht den Normalanwender der nicht im stillen Kämmerlein Programmiersprachen erlernen möchte und bezieht diese User in eure Überlegungen mit ein.
Ingo

Hallo Ingo,

ein herzliches Dankeschön für diese wirklich relevante Anregung!

Denn abgesehen von den techn. Aspekten stellt sich vorrangig ja folgende Kernfrage:

Was könnte einen Modeleisenbahner dazu bewegen,
a) nochmals Geld auszugeben um vorhandene Dekoder abzulösen ?
b) erstmals Geld auszugeben um nun doch zu digitalisieren ?

Für mich entscheidendes Kriterium eine vernünftige Konfigurationssoftware und technischer Mehrwert. Wenn mir Funktionen beim alten Decoder fehlen, dann würde ich lieber einen preiswerten neuen Decoder in die Lok einbauen bevor ich einen Funktionsdecoder hinzu rüste, was auch oft an Platzmangel scheitert.

Ich denke, dass hier für den Modeleisenbahner schon echte Kaufgründe her müssen. Und die Bedienerfreundlichkeit ist ganz gewiss eines davon.

Nach meinem Dafürhalten ein Garant für kommerziellen Erfolg, Anwender die vor Hürden gestellt werden verlieren die Lust am Decoder und kaufen keinen Zweiten.
man sieht gerade bei einem renommierte Hersteller im Forum, dass sich dort sehr großer Unmut über die neue Decodergeneration breit macht.

Allerdings muss man hier beim Wortgebrauch etwas unterscheiden. Ich mache das jetzt mal bewusst etwas ausführlicher:

- Programmierung: ist die Erstellung und Anpassung der Software durch die Entwickler. Sie erstellen und modifizieren z.B. die Firmware des Dekoders, aber auch die Benutzeroberfläche auf den Zentralen oder PC-Anwendungen für Modelleisenbahner (Rocrail usw.)

- Konfiguration: ist die Eingabe von Daten/Werten durch den Anwender. Sie liefern die "Betriebsparameter" welche die Software benötigt, um auf die individuellen Bedürfnisse eingehen zu können. Ein typisches Beispiel sind hier die Konfigurationsvariablen (CV's) von Dekodern (Einjustieren des Anfahrkicks, der Höchstgeschwindigkeit, der Licht-/Soundfunktionen, des Rangierbetriebs usw.)

- System: das ist die Software die im Untergrund werkelt, und den technischen Betrieb erst möglich macht (Juhu meine Anlage läuft )

- Anwendung: das ist die Software, die dem Benutzer Funktionen für bestimmte Anwendungszwecke bereitstellt (Dekoderkonfiguration, Gleisplanung, Gerätesteuerung, Schattenbahnhof, etc.). Und dies hoffentlich über eine geeignete Bedieneroberfläche

- Daten: sie sind genau genommen in dem Ganzen das eigentlich Entscheidende (was häufig übersehen wird). Das kann die Lokdatenbank sein, die Werteliste für CV's, Protokolldaten, Betriebsdaten, Positionsdaten, Gleispläne, Normen uvm. Fehlen die Daten bzw. sind sie falsch oder zu ungenau, kann man letzendlich alles vergessen (insbesondere die Programmierung).

Die Unterschiede zwischen Programieren und Konfigurieren etc. sind mir schon geläufig.
Darum habe ich, auch um im allgemeinen Sprachgebrauch der Anwender (und teilweise auch der Hersteller) zu bleiben, den Begriff Programmieren oben in Hochkommata gesetzt.

Puh, deine Anforderung heisst also, dass der Käufer eine Software zum Dekoder erhält, die ihn bei der Konfiguration seiner Lokdekoder komfortabel unterstützt. Insbesondere bei der Optimierung des Fahrverhaltens und der Konfiguration der Dekoderfunktionen. Und dies gemeinwirtschaftlich für die hiesige Dekoderflotte.

Nicht pauschal für die Decoderflotte, nur für dieses OSD Projekt. Alles Andere wäre nur möglich wenn Du für jeden Decodertyp die komplette CV-Liste hättest (wird nicht jeder Hersteller rausrücken) und dann im Idealfall noch das passende GUI in der Konfigurationssoftware einblenden.

Ja, so eine Software zum Dekoder wäre gewiss ein Kaufgrund! Insbesondere wenn man sich mal anschaut, was die Zentralen sonst so bereithalten.
P.S. könnte ja auch eine App sein

Viele Grüße
Rainer...W

[/quote]


Ich hätte da sicher noch mehr Ideen und Anregungen, aber ich warte erst einmal ab ob das Projekt nun anläuft. Leider wird hier in den anderen Threads mal wieder einiges zu Tode diskutiert. Die Idee von Kersten Tams ist genial, ich hoffe sehr es wird vorwärts damit gehen.

Gruß,

Ingo

[rainerwahnsinn]

Hallo Rainer,
... Die Unterschiede zwischen Programieren und Konfigurieren etc. sind mir schon geläufig.
..., den Begriff Programmieren oben in Hochkommata gesetzt.
Nicht pauschal für die Decoderflotte, nur für dieses OSD Projekt.
Ingo

Hallo Ingo,
das hatte ich schon bemerkt
Vorangig für die OSD Dekoderflotte natürlich! Für die anderen mit, wäre aber auch kein schlechtes Feature

P.S. bin mal deinem Link gefolgt. Deine Begeisterung für Pola ist echt nachvollziehbar! Sei also gewappnet, wenn ich da mal auf dich zukommen sollte

Viele Grüße
Rainer...W

[LDG]

Hallo,

Puh, deine Anforderung heisst also, dass der Käufer eine Software zum Dekoder erhält, die ihn bei der Konfiguration seiner Lokdekoder komfortabel unterstützt. Insbesondere bei der Optimierung des Fahrverhaltens und der Konfiguration der Dekoderfunktionen. Und dies gemeinwirtschaftlich für die hiesige Dekoderflotte.

Ja, so eine Software zum Dekoder wäre gewiss ein Kaufgrund! Insbesondere wenn man sich mal anschaut, was die Zentralen sonst so bereithalten.
P.S. könnte ja auch eine App sein

Viele Grüße
Rainer...W

Bei Tams gibt es CV-Navi. Das ist ein Java-Programm um Tams-Decoder/-Zentralen/-Zubehör mit p50x-Zentralen (MC, OpenDCC, IB) zu konfigurieren ("programmieren" ). Ich könnte mir vorstellen, daß man daraus ein plattformübergreifendes Konfigurationsprogramm für einen neuen Decoder weiterentwickeln könnte. Ich denke Kersten wäre in dieser Richtung auch kooperativ

Gruß,
Lothar

[Sharp57]

Hallo Rainer,
... Die Unterschiede zwischen Programieren und Konfigurieren etc. sind mir schon geläufig.
..., den Begriff Programmieren oben in Hochkommata gesetzt.
Nicht pauschal für die Decoderflotte, nur für dieses OSD Projekt.
Ingo

Hallo Ingo,
...........
P.S. bin mal deinem Link gefolgt. Deine Begeisterung für Pola ist echt nachvollziehbar! Sei also gewappnet, wenn ich da mal auf dich zukommen sollte

Viele Grüße
Rainer...W

Bin sehr gern dazu bereit.

Gruß,

Ingo

[rainerwahnsinn]

Hallo,
Bei Tams gibt es CV-Navi. Das ist ein Java-Programm um Tams-Decoder/-Zentralen/-Zubehör mit p50x-Zentralen (MC, OpenDCC, IB) zu konfigurieren ("programmieren" ). Ich könnte mir vorstellen, daß man daraus ein plattformübergreifendes Konfigurationsprogramm für einen neuen Decoder weiterentwickeln könnte. Ich denke Kersten wäre in dieser Richtung auch kooperativ
Gruß,
Lothar

Hallo Lothar,
ein guter Hinweis!
Das mit dem P50X Interface ist interessant. Hast du eine Source, das man sich das Handling der Befehle über die COM Schnittstelle mal anschauen kann?

Viele Grüße
Rainer...W

[Samy1981]

Ich erwarte von einem OpenSource Decoder:

-Vorteile gegenüber bestehenden Decodern.
-Innovationen

Das ist jetzt natürlich sehr allgemein gehalten, aber wenn ich hier die doch schon sehr speziellen Wünsche einiger lese, frage ich mich 1.braucht das die breite Masse überhaupt und 2.wie lange soll es dauern bis man an erstmal an dem Punkt ist, Spezialwünsche zu realisieren.....

Vorteile zu bestehenden Decodern können sein:

-preisgünstiger
-einfaches Programmieren/Konfigurieren

Mehr sehe ich da einfach nicht. Ich finde die erhältlichen Decoder bieten schon einen so breiten Funktionsumfang das die breite Masse es doch jetzt schon kaum ausnutzt. Auch die Fahreigenschaften sind zu 99% eigentlich mehr als zufriedenstellend.

Ich sehe auch nicht die Notwendigkeit die CVs neu zu erfinden, CVs sind nichts anderes als eine Tabelle/Liste, wie das dem Benutzer dann Präsentiert wird ist einfach eine Frage der GUI.

Aber ich sehe die Notwendigkeit die Moba endlich mal einfach und kostengünstig an den PC zu bringen. Man kann heutzutage das gesamte Haus mit PC und Smartphone steuern, doch wenn man das mit seiner Anlage machen möchte muss man entweder erstmal ordentlich Technik anschaffen oder ein Technik Freak sein der irgendwelche Bastel-Lösungen umsetzt.

Das hat jetzt in erster Linie nichts mit dem Decoder selbst zu tun, aber man sollte sich diesen Weg offen halten......

[SAH]

Guten Abend Thomas,

Du hast einen wunden Punkt treffend benannt, den ich näher erörtern möchte:

Ich sehe auch nicht die Notwendigkeit die CVs neu zu erfinden, CVs sind nichts anderes als eine Tabelle/Liste, wie das dem Benutzer dann Präsentiert wird ist einfach eine Frage der GUI.

gefühlte 85-90% aller Nutzer wollen einen Dekoder, der nach dem Einbau exakt ihre Vorstellungen in mindestens akzeptabler Weise trifft ohne gtoßen Programmieraufwand. Dekoder die wesentlich mehr können gibt es, doch deren Beliebheit hat (siehe Zimo) in gefühlter Weise abgenommen in dem Maße, wie Einstellungen möglich sind (O-Ton ,,Ich will nach dem Einbau nicht noch 5-6 Stunden mit Programmieren verbringen müssen!").

Es könnte eine Stärke von OS-Dekodern sein, diese Aufgaben o.g. 85-90% abzunehmen. Dies erfordert nicht nur exakte Planung, sondern auch profunde Sachkenntnis (Motor-/Modelleigenschaften, CV-Einstellungen, Wirkungsweise derselben usw....) und viel Fleißarbeiten (o.g. Erkenntnisse zu dokumentieren und zusammenzutragen).
Preisfrage (die automatisch gestellt wird!): lohnt sich das überhaupt?
Antwort (frei nach Radio Eriwan): Im Prinzip ja, aber.....

mit freundlichen Grüßen,
Stephan-Alexander Heyn

[rainerwahnsinn]

Guten Abend Thomas,
Guten Abend Stephan-Alexander,

ich weiß noch, wie ich beim ersten Mal wegen den Fahreigenschaften verzweifelt das CV gesucht hatte, um den Dekoder passend für Motortyp und Getriebeart zu konfigurieren (ob DCM, LFCM, SFCM, etc. ob Schnellzug, Rangierlok usw.). Und ?

Kurz zuvor durchforstete ich meine MS 2 nach einem Menüpunkt wie "Dekoderdiagnose". Die Lok stand nu mit frisch eingebauten Dekoder aufm Gleis und nichts tat sich. War da nicht zumindest eine kleine Led auf dem Dekoder? Die grün, oder rot leuchtet, oder gar blinkt? Woran lässt sich erkennen, ob das Ding überhaupt Strom kriegt oder was?

Hmh, mal die Beschreibung lesen..., huch ist das die für den Servicetechniker? Wo ist denn die Bedienungsanleitung ???

Ich höre jetzt lieber auf, bevor ich richtig warm werde...

Viele Grüße
Rainer...W

[Samy1981]

Guten Abend Thomas,
Guten Abend Stephan-Alexander,

ich weiß noch, wie ich beim ersten Mal wegen den Fahreigenschaften verzweifelt das CV gesucht hatte, um den Dekoder passend für Motortyp und Getriebeart zu konfigurieren (ob DCM, LFCM, SFCM, etc. ob Schnellzug, Rangierlok usw.). Und ?

Kurz zuvor durchforstete ich meine MS 2 nach einem Menüpunkt wie "Dekoderdiagnose". Die Lok stand nu mit frisch eingebauten Dekoder aufm Gleis und nichts tat sich. War da nicht zumindest eine kleine Led auf dem Dekoder? Die grün, oder rot leuchtet, oder gar blinkt? Woran lässt sich erkennen, ob das Ding überhaupt Strom kriegt oder was?

Hmh, mal die Beschreibung lesen..., huch ist das die für den Servicetechniker? Wo ist denn die Bedienungsanleitung ???

Ich höre jetzt lieber auf, bevor ich richtig warm werde...

Viele Grüße
Rainer...W

Dein Thread ist glaube ich ein gutes Beispiel für so einiges.......

Eine einzige CV bei der sich Einstellen lässt welcher Motor oder Zugtyp es sein soll wird nicht reichen, das ist eher eine Summe mehrerer CVs, und das ist wiederrum eine Sache der Benutzeroberfläche, dort müsste man auswählen können welcher Motor verbaut ist und die Software setzt dann im Hintergrund die entsprechenden CVs.

Die Idee mit der LED finde ich gut, aber ich höre schon die ersten meckern, das es aus ihrer Lok irgendwo grün rausleuchtet......

Und Beschreibungen, ja das ist so eine Sache, wo dem einen noch viel zu wenig drin steht, hat der andere schon entnervt aufgegeben. Dafür gibt es seit einiger Zeit ja zusätzlich sogenannte Schnellstart-Guides, doch dann meckern wieder welche warum es jetzt 2 Anleitungen gibt......

[Sharp57]

Hallo Zusammen,

eine LED wäre sicherlich sehr praktisch. ABER auch die braucht wieder Platz auf dem Decoder, also nicht so praktikabel, wenn man den Decoder möglichst klein halten möchte.

Übrigens, die Led könnte man dann ja über einen CV abschaltbar machen, denn auch ich will nicht das es grün aus meinen Loks heraus schimmert.

Gruß,

Ingo

[aftpriv]

Hi Forianer

so könnte eine Eingabemaske für CV´s aussehen:

a) für Binäre CV´s


Detail links

Detail rechts


b) für Dezimale CV´s


Detail links


Erklärung:
ich habe mir mal die Mühe gemacht, die CV´s von Zimo in eine Access2003-Datenbank einzutragen und die Erklärungen usw. in der Maske sichtbar gemacht. So oder ähnlich wird das Handbuch nicht mehr benötigt.

Gruß

Alf

PS: in einem Stummi-eigenen Decoder könnte man die meisten CV´s (zumindest die, die für Hersteller frei verwendbaren) auch logisch anordnen und nicht wild durcheinander wie Istzustand.

[rainerwahnsinn]

Hi Forianer

ich habe mir mal die Mühe gemacht, die CV´s von Zimo in eine Access2003-Datenbank einzutragen und die Erklärungen usw. in der Maske sichtbar gemacht. So oder ähnlich wird das Handbuch nicht mehr benötigt.

Hallo Alf,

da Touch PAD's immer erschwinglicher werden ist es absehbar, dass die Hersteller der Digitalzentralen keine eigenen aufwändigen Displaylösungen mehr in die Zentralen verbauen, sondern zunehmend auf den Anschluss von PAD's setzen und ihre Softwarelösungen dazu anbieten. Ist einfach billiger, schneller und leichter ausgestaltbar. Das wird schon eine feine Sache (im Gegensatz zu klobigen Notebooks usw.).

P.S.: hierfür Dekoderseitig schon etwas vorzubauen, wäre also nicht ganz dumm

Was die Unterstützung für Modelbahner angeht, denke ich daher auch, dass dies eine softwareseitige Sache ist. Auch um das Papierwerk auf das notwendige Maß zu reduzieren z.B. Quickstart (schematisch).

Es gibt ja auch schon einiges z.B. für die Dekoderkonfiguration per Programm. Man muss sich eben nur ein halbes Jahr zuvor mit der zugrundeliegenden Technik und den Fachbegrifflichkeiten und den Einschränkungen vertraut machen, dann erscheint die Oberfläche und die Benutzerführung sogar wieder plausibel.

Bezeichnungen wie CV's, Register, Motorkennlinie, Bit, Increment, Binär, PID-Regelung uvm. also besser nicht auf der Benutzeroberfläche, und die Thematik eher aus der Sicht von Modeleisenbahnern (und Verkäufern ) angegangen.

Aber: technisch Interessierte/Versierte dürften es eher so bevorzugen, wie du das hier zeigst (Servicemode). Da zähle ich mich gern hinzu.

Viele Grüße
Rainer...w

[melior]

Hallo Rainer,

Das mit dem P50X Interface ist interessant. Hast du eine Source, das man sich das Handling der Befehle über die COM Schnittstelle mal anschauen kann?

sieht so aus, als wäre das Tool von Tams nicht Open Source. P50X-Befehle über eine serielle Leitung schicken (in Java) ist aber nicht sooo spannend. Da kannst Du auch in den Sourcecode vom BiDiB-Wizard schauen, der macht so etwas mit BiDiB-Kommandos.

Tschüß André

[ktams]

moin,
wer will, kann die Sourcen haben und weiter entwickeln.
Habe ich auf Anfrage schon immer raus gegeben.
Allerdings ist es teilweise recht schweinemäßig programmiert, da das mein Übe-Projekt mit Java war
Gruß Kersten Tams