Habe jetzt eine Besonderheit der NanoxAl festgestellt: Eine meiner Schmalspurdampfloks - eine Roco NWE21 mit integrierter 6 pol. DSS, hat bisher einen Decoder von Kühn eingebaut. Bei diesem muß man darauf achten welche Firmware auf dem Pic verwendet wird. Mit der Firmware die bisher bei mir drauf ist läßt sich dieser Decoder nicht steuern. Mit einer ESU Zentrale/ dem ESU Lokprogrammer tritt dieses Problem nicht auf.
Auf Seite 7 diesen Beitrags wird auf das gleiche Problem bei TAM´s Decodern von "fehn" schon einmal hingewiesen...
Gruß Udo (Hannover) DCC H0 (DRG Epoche 2) & H0e, mehrere RocoMM, z21 & etwas RocRail
Moin, jepp, dass es Tams betrifft, stand irgendwo. Dass Kühn-Decoder sich mit der Nanox nicht vertragen, wusste ich auch schon eine Weile, weil Torsten die Erfahrung gemacht hat. Ich hatte nur versäumt, es hier reinzuschreiben...
Die Firmware ohne "stretching zeros" funktioniert jedoch gut, ist kompatibel und vermutlich wird keiner von uns einen Unterschied feststellen. Der Nachteil ist halt, dass man die Anzahl an Eingabegeräten (Mäuse, XBus-TCO) auf deutlich unter 10 beschränken sollte (angenommener Wert).
Ab wie vielen Mäusen der Bus wirklich in die Knie gezwungen wird, werde ich vielleicht im Zusammenhang mit dem Forenbahntreffen testen können (und dort dann im direkten Vergleich zu Roco und Lenz).
Stretching zeros braucht man doch nur, wenn eine nicht mit einem Decoder versehene Lok betrieben werden soll. Welchen Zusammenhang soll das mit dem XBus haben?
Thomas
Das Schöne an einheitlichen Standards ist es, dass es so viele verschiedene davon gibt. Toleranz ist die Erkenntnis, dass es sinnlos ist, sich aufzuregen.
ZitatStretching zeros braucht man doch nur, wenn eine nicht mit einem Decoder versehene Lok betrieben werden soll. Welchen Zusammenhang soll das mit dem XBus haben?
vielleicht, weil die stretched zeros dem Prozessor Zeit bringen, sich um den Bus zu kümmern?
Ich glaube, daß der Prozessor mit der Aufgabe ziemlich ausgeknautscht ist!
Danke für die Idee, in die Richtung hatte ich nicht überlegt. Wenn das Ding leistungstechnisch so randgenäht sein könnte, werde ich wohl für meine Experimente doch lieber zu OpenDCC greifen, außerdem ist das nicht closed source. Macht ja keinen Sinn, das Gleissignal auszubremsen, nur damit die "normalen" Aufgaben erledigt werden können.
Thomas
Das Schöne an einheitlichen Standards ist es, dass es so viele verschiedene davon gibt. Toleranz ist die Erkenntnis, dass es sinnlos ist, sich aufzuregen.
die Stretching zeros braucht man nicht um Analoge Lok´s zu betreiben, sondern für RailCom. In der Zeit sendet ein Railcomdekoder info´s an die Zentrale. Es gibt Dekoder die mit den Stretching zeros nicht zurecht kommen ( zB. ESU Lokpilot Basic ) Ich verwende die Version ohne die Stretching zeros, seither habe keine probleme mehr.
Nein, das ist falsch. Stretching zeros werden für die Steuerung von Loks ohne Decoder benötigt, indem durch eine Längenvariation der Nullbits eine Gleichspannungsverschiebung erzeugt wird und die resultierende Spannung damit über der Zeit von Null verschieden ist und damit ein direkt angeschlossenen Motor zum Drehen gebracht werden kann. Ist nicht besonders gut für die Motoren. Railcom benötigt eine Austastlücke, also einen Slot ohne dass ein Null- oder Einsbit gesendet wird. In dieser Lücke sendet der Decoder. Das Beides sind also verschiedene Sachen. Ob die Nanox für Railcom ausgelegt ist, weiß ich nicht. Dieser Trick, mit stretching zeros Rechenzeit zu gewinnen, ist mir heutzutage zu windig; leistungsfähige µCs kosten nur wenig Geld.
Thomas
Das Schöne an einheitlichen Standards ist es, dass es so viele verschiedene davon gibt. Toleranz ist die Erkenntnis, dass es sinnlos ist, sich aufzuregen.
Ok, dann haben wohl eher die Decoder ein Problem mit der Austastlücke.
Thomas
PS: Irgendwie bin ich zu dusslig, die Stelle auf der Paco-Seite zu finden, wo ein Zusammenhang zwischen Anzahl der XBus-Geräte und Firmware/Austastlücke beschrieben wird.
Das Schöne an einheitlichen Standards ist es, dass es so viele verschiedene davon gibt. Toleranz ist die Erkenntnis, dass es sinnlos ist, sich aufzuregen.
ZitatPS: Irgendwie bin ich zu dusslig, die Stelle auf der Paco-Seite zu finden, wo ein Zusammenhang zwischen Anzahl der XBus-Geräte und Firmware/Austastlücke beschrieben wird.
bitte nicht verwechseln: Die Austastlücke (komplett stromlos) ist für Railcom. Das ist was anderes, als eine gestreckte 0.
Das ist schon klar, dass das zwei unterschiedliche Sachen sind. Danke für den Link, das ist mir in der Doku durchgerutscht. Also rettet man sich mit den stretching zeros aus dem Engpass Rechenzeit, gefällt mir aber nicht wirklich, da bei DCC eher das Gleissignal der limitierende Faktor ist und nicht der XBus. Und die stretching zeros bringen die beiden Decodertypen aus dem Tritt, die also nicht den Normen entsprechen.
Thomas
Das Schöne an einheitlichen Standards ist es, dass es so viele verschiedene davon gibt. Toleranz ist die Erkenntnis, dass es sinnlos ist, sich aufzuregen.
ich weiß, ich bin ein bißchen spät dran, aber ich habe seit Neuestem eine Multimaus und dachte mir, das wäre doch eine gute Gelegenheit, ein GenLI USB aufzubauen.
Also habe ich usb_interface-1.5.zip genommen und die Platine aufgebaut.
Jetzt kommen meine Fragen:
- Ist das die neueste Version? - Gibt es auch den Sourcecode für den PIC? - Sollte sich das Interface so wie das ursprüngliche verhalten, das hier beschrieben ist? - Wenn ja, sollte ich dann mit Hilfe eines Terminalprogramms mit dem Interface sprechen können (Kommando "dccdcc")? - Wie kann ich mit einfachen Mitteln testen, ob das Interface funktioniert? - Muß zum Testen unbedingt ein Xpressnet-Gerät angeschlossen sein oder unterhält sich das Interface auch so mit dem PC?
Hallo Andre´! Ich habe mir das GenLi-USB vor ca. 14 Tagen auch gebaut. Da es zwingend auf die Stromversorgung über das XPressnet angewiesen ist, habe ich es an meine Lenz-Zentrale und danach an den Computer angeschlossen. Dann einfach nach der Bauanleitung fortfahren.Es lässt sich mit Hyperterminal sofort die XPressnet-Adresse auslesen oder ändern. Ich konnte auch mit Rocrail über das GenLi auf die DCC-Lok- und Weichendecoder zugreifen. Viele Grüße Heinz aus Bochum
ZitatIch habe mir das GenLi-USB vor ca. 14 Tagen auch gebaut. Da es zwingend auf die Stromversorgung über das XPressnet angewiesen ist, habe ich es an meine Lenz-Zentrale und danach an den Computer angeschlossen.
ich habe nur eine Multimaus und einen Roco 10764 zur Verfügung.
Vielleicht mache ich auch nur einen Denkfehler:
Version a) Ich schließe das GenLI an die Master-Buchse des 10764 und die Multimaus an die Slave-Buchse an.
-> Multimaus sagt Err 13
Version b) Ich schließe das GenLI an die Slave-Buchse des 10764 und die Multimaus an die Master-Buchse an.
-> Multimaus sieht ok aus
In beiden Fällen habe ich versucht, über ein Terminalprogramm mit dem GenLI zu sprechen. Bei a) kommt gar nichts an, bei b) kommen ein paar binäre Zeichen an. So etwas wie ein Menü, um die Adresse auszulesen, sehe ich aber nie.
Zur Stromversorgung: Wenn ich den Schaltplan richtig verstehe, dann wird der PIC über die USB-Buchse und die Optokoppler über Xpressnet versorgt. Was mir aber nicht klar ist: Spricht der PIC selbst per USB mit dem PC oder leitet er nur die Daten vom Xpressnet an den PC weiter bzw. umgekehrt.
Version B ist richtig, die Multimaus muss in Deiner Konstellation zwingend immer Master sein.
Thomas
edit: Datenmüll im HT deutet auf eine falsche Einstellung der Schnittstelle hin. Ist wirklich 9600,8N1 eingestellt?
[ Editiert von topla am 24.03.12 17:23 ]
Das Schöne an einheitlichen Standards ist es, dass es so viele verschiedene davon gibt. Toleranz ist die Erkenntnis, dass es sinnlos ist, sich aufzuregen.
ZitatVersion B ist richtig, die Multimaus muss in Deiner Konstellation zwingend immer Master sein.
Deine Antwort hat mir Mut gemacht, danke! Jetzt habe ich nochmal RocRail bemüht und siehe da, wenn ich an der Multimaus STOP drücke, reagiert der Power-Button in RocRail entsprechend. Und wenn ich in RocRail eine Lok auf Adresse 3 konfiguriere, synchronisiert sich der Status der F-Tasten in beide Richtugen. So weit so gut!
Zitatedit: Datenmüll im HT deutet auf eine falsche Einstellung der Schnittstelle hin. Ist wirklich 9600,8N1 eingestellt?
Ja, ziemlich sicher. Ich habe es mit minicom und hterm probiert. Soweit ich weiß ist das Xpressnet-Protokoll binär, da wundert mich der Datenmüll gar nicht mehr.
Aber es gibt da noch diese Anleitung, wie man die Xpressnet-Adresse des GenLI verstellen kann und das bekomme ich noch nicht hin.
Zitatedit: Datenmüll im HT deutet auf eine falsche Einstellung der Schnittstelle hin. Ist wirklich 9600,8N1 eingestellt?
ich sehe gerade im RocRail-Log, daß er sich mit 57600 bps verbindet. Aber auch das ändert nichts daran, daß das GenLI im Terminalprogramm nicht mit mir reden will.
ZitatGepostet von melior (...) Aber es gibt da noch diese Anleitung, wie man die Xpressnet-Adresse des GenLI verstellen kann und das bekomme ich noch nicht hin.
Tschüß André
Moin André, das wird auch nix: die Anleitung bezieht sich auf das Genli von Paco, du hast jedoch ein völlig anderes. Im Zusammenhang mit der Nanox bin ich auf darauf "herein gefallen": es funktioniert zwar, hat aber Fehler. Diese Verwechslung ist schon in diesem Thread beschrieben, der allerdings auch recht lang ist...
Zitatdie Anleitung bezieht sich auf das Genli von Paco, du hast jedoch ein völlig anderes.
aha! Na die Gefahr war natürlich da. Dann hat sich Ronny Gabler wohl die Mühe gemacht, eine komplett neue Firmware für die USB-Version des GenLI zu entwickeln.
Bis jetzt war es noch nicht nötig, die GenLI-Adresse zu ändern, hoffentlich bleibt es so.
H0-Modellbahnforum.de - das Forum mit der Forumbahn!
»
Technik und Steuerung von Fahrzeugen und Anlage
»
Digitaltechnik
»
GenLi - NanoX & Co.
Thema drucken
21.02.2012 08:11
Antworten
Mit einer ESU Zentrale/ dem ESU Lokprogrammer tritt dieses Problem nicht auf.
