Servus!
Am Sonntag, 17. Juni 2012 11:18:27 UTC+2 schrieb Andreas Iwanowitsch:
> Am 17.06.2012 10:24, schrieb Oliver Zoffi:
>
> > So und jetzt will ich wissen, weshalb Ihr solche Probleme habt und ich nicht?!
> > Woran liegt es?
>
> Weil wir zu dumm sind und nicht w�rdig, die erlauchten Produkte zu
> verwenden.
Ich habe das so nie geschrieben! Ich habe weder jemanden als zu dumm, zu blöd oder sonst wie beschimpft - das sind Unterstellungen Eurerseits (wenn wir keine anderen Argumente mehr haben, kommen wir eben damit ...)
Mir kommt allerdings schon vor, dass Ihr an eingefahrenen Schienen fest haltet und gar nicht willens seit, hier u.U. anders vor zu gehen.
Ob die Produkte erlaucht sind oder nicht - entweder Ihr könnt und wollt damit umgehen, oder nicht. Da ich zumindest Eure Probleme nicht habe, diese auch nicht nachvollziehen kann - weshalb auch immer, ist es mir auch nicht möglich einen eventuellen Fehler nach zu stellen und diesen vielleicht sogar zu beheben.
Wenn ich damit nämlich zum Entwickler gehe, dann muss ich ihm das auch vorführen können - und das kann ich nicht.
>
> Ich erinnere mich noch gut, wie ich schon vor Jahren �ber Probleme mit
> dem Ansteuern von Faulhabern berichtete, und niemand es nachvollziehen
> konnte - und da� vor wenigen Monaten Andreas (P.) nach ausgedehnten
> Fahrversuchen die L�sung pr�sentiert hat.
>
> Versuch doch mal zu verstehen, was mich �rgert: Es gab da mal ein
> Produkt, MX63 bzw. MX64 genannt, das absolut perfekt (nach Andreas'
> Konfigurationsanweisung sogar mit Faulhaber) genau das tat, was es
> sollte - super Fahreigenschaften mit jeder Art von Motor,
> nachvollziehbare Geschwindigkeitskennlinie etc. pp., und das nun
> kaputtinnoviert wurde. Der �rger fing mit dem MX620 an, und seitdem
> wurde es immer schlimmer.
>
Natürlich verstehe ich Dich/Euch - ich versuche ja Eure beschriebenen Fehler nachzustellen - DAMIT ich diese herzeigen kann.
Da mir das nicht gelingt, kann es nur an der Art der Ansteuerung, und/oder an der Konfiguration liegen - was sollte es sonst sein?
Ich habe nun auch versucht mir die Sache mit dem Geschwindigektissprung grafisch darzustellen und versuche nach wie vor eine Erklärung:
Ungeachtet dessen, dass ich bitte NICHT behaupte, dass der ZIMO Decoder Fehlerfrei wäre ...
Ich habe im Decoder 252 Geschwindigkeitswerte (CV= 0-252) weil, eben nur 8 Bit pro CV gibt, die ansprechbar sind.
DCC kann davon nur maximal 7Bit nutzen, weshalb auch immer bleiben davon aber nur 126 Fahrstufen über.
Ob nun mit 28, oder 128 Fahrstufen gefahren wird, entscheidet die Zentrale. D.H. der Decoder entscheidet *automatisch* welche Fahrstufenzahl nun benutzt wird. Das könnte schon die 1. Fehlerquelle sein, weil ja hier eine Tabelle hinterlegt ist, die angibt, welche interne Fahrstufe der maximal 252 jetzt für welche der empfangenen 28, oder 128 Fahrstufen steht.
Wobei durch CV6 diese Tabelle neu berechent wird - mögliche Fehelerquelle 2!
Wird nun bei 28 FS die 3-Punkt Linie mit CV3, CV6 und CV5 benutzt und dabei zur Erzielung eines möglichst gedehnten Langsamfahrbereiches die CV6 möglichst niedrig eingestellt, so wird eben wie bereits erwähnt dies Tabelle neu berechnet und durch Rundungsfehler und mehr, kann es dann zu großen Geschwindigkeitssprüngen von einer zur nächsten FS kommen.
Ob das nun so sein muss, ein Rechenfehler ist oder was sonst noch, ist dabei unerheblich. Es ist halt so.
Es gibt nun die Möglichkeit den Decoder zu tauschen, oder sich Gedanken machen, was die Ursache sein könnte und wie ich das beheben kann.
Dies kann man also nur umgehen, in dem man manuell durch Zuweisung der Geschwindigkeit jeder Fahstufe via 28 Punkt Kennline vornimmt.
Wobei trotzdem klar sein muss, dass, je geringer die Auflösung im unteren Bereich ist, desto größer wird sie im oberen Bereich sein - man kann nur die einzelnen Geschwindigkeitspunkte verschieben und die Auflösung gleichmäßiger machen.
Wenn ich anstelle von 28, nun 128 (126) Fahrstufen nutze, die ich auch jede einzeln ansprechen kann, wird diese Auflösung logischerweise feiner sein.
Um es noch deutlicher zu machen: bei 28 FS lt. DCC ist der Sprung von FS zu FS, bei einer linearen Kurve, bei 252 möglichen Werte im Decoder NEUN Fahrstufen!
Bei 128 (126) Fahrstufen, bei gleichen Voraussetzungen, ist der Sprung nur noch ZWEI (internen) Fahrstrufen (wir erinnern uns: 252 Werte!).
D.H. also, dass selbst bei einer extrem negativ logaritmischen Beschleunigungskurve, bei 126 Fahrstufen der Sprung min/max 1 im unteren Bereich und max 3-4 im oberen Bereich sein wird.
Womit also der Unterschied zwischen FS 22 und 23 bei nur 28 FS sicher immer größer sein muss, als äquivalent bei zb. FS 90 auf 100, weil ich dazwischen 10 Fahrstufen habe, die ich nutzen kann! Ist also der messbare Unterschied von 90 zu 100 zu groß (20 kmh, ich will aber nur 5), so habe ich bei 126 FS dazu ganz sicher die Möglichkeit, das anzusteuern, bei 28 geht das einfach nicht!
Also bleibt mir gar nichts anderes über, als manuell die 28 Punkt Kurve nach meinen Wünschen - leider mit Kompromissen - anzupassen.
Mag nun sein, dass andere Decoder hier einen anderen Rechenalgorythmus nutzen und man sich darum also nicht kümmern muss - das streite ich gar nicht ab.
Dennoch ist es mit ZIMO-Decodern möglich - das entsprechende Verständiss und Wissen vorausgesetzt - das alles wunschgemäß zu konfigurieren (wenn man das wirklich will).
Ich höre übrigens schon den Ruf nach echter KMH Regelung laut werden ... Lt. DCC habe ich nur 126 FS maximal - wenn nun eine FS einen KMh bedeutet, wäre also bei 126KMh die VMAX erreicht - also muss ich wieder mit einer Tabelle arbeiten ... mit den gleichen Problemen, wie schon beschrieben.
Ich könnte natürlich eine Tabelle für den Rangierbereich und eine für den normalen Fahrbetrieb verwenden ... gibt es ja schon, den "Rangeirgang", oder "Halbgeschwindigkeit" ... und wer nutzt das wirklich?
lg
Oliver