[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DDL-ML] SRCP 0.8



hi ddler,

Torsten Vogt schrieb:

>
> Du solltest Dir das Handbuch im PDF-Format von Lenz
> aus dem Internet besorgen und lernen Deine Dekoder richtig zu
> programmieren. Sorry Holger, das ist kein SRCP-Problem.

die dcc specs kenne ich leider nicht, hat jemand eine gezielte url, wo ich
diese gut erklärt nachlesen kann????
daß nb keine funktionen schaltet mag ja noch ok sein, daß aber n1(oder
"erweiterte" protokolle") nicht den betrieb von 14/27 fahrstufen ansteuern
kann einschließlich der 1-x funktionen finde ich merkwürdig. selbst wenn das
allles den nmra-dcc normen entsprechen sollte, bietet doch gerade eine
interessengemeinschaft das potential mit entsprechenden, vielleicht auch
individuell machbaren definitionen, sowas zur verfügung zu stellen.

zur programmierung von decodern: es liegen die entsprechenden waschzettel bei
den decodern dabei, aber es gibt für mich einige gründe nicht
umzuprogrammieren:

a) test der decoder im originalzustand auf funktionsfähigkeit, ohne sie vorher
irgendwo einzubauen, dazu habe ich mir ein testboard aufgebaut, was dieses
ermöglicht.  es wird dort erstmal angeschlossen und geprüft.

b) es gibt einige allstrom loks wo aufgrund der trägheit der motoren und der
art des modells es weder lohnt einen anderen motor oder einen anderen decoder
zu nehmen und erst recht lohnt es nicht die fahrstufen zu erhöhen. also ist
die grundeinstellung 14/27 fahrstufen mit schaltbaren funktionen, egal ob zwei
oder vier, für diese loks optimal, aber wie die definitionen in srcp ausgelegt
sind, bin ich nicht in der lage die wenigen notwendigen fähigkeiten des
decoders auszunutzen.

muß ich also annehmen diese decoder von lenz sind in ihrer grundeinstellung
nicht nmra-dcc kompatibel??

muß ich weiterhin annehmen, wenn das so ist, daß srcp nicht so flexibel ist,
daß dieses problem in den griff zu bekommen ist?

dann ist für mich die schlußfolgerung ein z.b. xml basierter server mit einer
konfigurationsdatei ist die bessere lösung, vorausgesetzt man stellt sich
nicht wieder selber grenzen, die die nutzung auf dem markt befindlicher und
noch zu erwartender hardware von vornherein einschränken.

ich kann mich daran erinnern, daß ihr softwares schreiben wolltet, die die
anwender vor wenig hürden stellen sollten und die möglichst flexibel mit der
erfüllbarkeit von anforderungen der anwender umgehen kann. genauso wie jeder
anwender ansprüche an seinen computer hat und diese sehr individuell in hard-
und software konfiguriert sind und genutzt weden, auch gerade für das ganze
ddl paket und deren verschiedene clients.

ich weiß, ihr gebt euch sehr viel mühe und hilfestellung und beweißt mehr
geduld als man selbst erwartet hatte, dafür bin ich euch allen sehr dankbar.
aufgefallene fehler werden von euch möglichst schnell und unkompliziert
beseitigt, aber manchmal habe ich das gefühl, ihr beharrt auf "alt erprobtes",
weil ihr die notwendigkeit nicht seht die ein anwender gerade hat, obwohl es
kein großer umstand für solche spitzenprogrammierer sein kann, diese
"bedürfnisse zu implementieren",  insbesonder die zwei von mir angesprochenen.

es verlangt ja keiner das dieses von heut auf morgen geschieht, sondern
"erstmal mit bedacht" wird und möglichst bei der nächsten version mit
einfließt.

es würde mich freuen wenn ihr euren ansprüchen treu bleibt und die
zusammenarbeit mit dem kollegen aus der fachhochschule die bisherige
entwicklung noch weiter vorantreibt.

viele liebe grüße puesch


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com