Anzeige:
THEMA: TWIN-Decoder
THEMA: TWIN-Decoder
dobbygolf - 27.08.06 23:21
Hallo liebe N-Gemeinde,
gibt es einen Gedächtnisverlust bei GFN TWIN-Decodern und hat da schon jemand seine Erfahrung gemacht?
Bedingt durch Landschaftsbau- Einschottern habe ich meine Loks einige Monate nicht bewegt.
Als ich dies nun nachholen wollte, fuhren diese (GFN 67171, GFN 67235) nicht mal an, eine (GFN 67138) bewegte sich nur kurz vorwärts, um dann mit blinkender Schlussleuchte stehen zu bleiben.
Beim Auslesen im TC waren bei ersteren die eingegebenen Adressen verschwunden, eine Lok hatte sich sogar auf die "Auslieferungsadresse 3 zurückgestellt".
Mehr Probleme scheint die blinkende Lok zu machen. Dies deutet - laut Beiblatt - auf einen Kurzschluss hin. Die Schlepptenderlok habe ich aber erst kurz vorher vom Kundendienst zurückbekommen, sie hat noch das Rep.-Schildchen um. Trotzdem habe ich sie geöffnet und die Verkabelung überprüft. Ist alles OK.
Liegt das evtl. am Decoder?
Weiter Loks wollte ich nicht aufs Gleis stellen. Kann mir hierzu jemand einen Rat geben, was zu tun?
Besten Dank schon im Voraus
Uwe
gibt es einen Gedächtnisverlust bei GFN TWIN-Decodern und hat da schon jemand seine Erfahrung gemacht?
Bedingt durch Landschaftsbau- Einschottern habe ich meine Loks einige Monate nicht bewegt.
Als ich dies nun nachholen wollte, fuhren diese (GFN 67171, GFN 67235) nicht mal an, eine (GFN 67138) bewegte sich nur kurz vorwärts, um dann mit blinkender Schlussleuchte stehen zu bleiben.
Beim Auslesen im TC waren bei ersteren die eingegebenen Adressen verschwunden, eine Lok hatte sich sogar auf die "Auslieferungsadresse 3 zurückgestellt".
Mehr Probleme scheint die blinkende Lok zu machen. Dies deutet - laut Beiblatt - auf einen Kurzschluss hin. Die Schlepptenderlok habe ich aber erst kurz vorher vom Kundendienst zurückbekommen, sie hat noch das Rep.-Schildchen um. Trotzdem habe ich sie geöffnet und die Verkabelung überprüft. Ist alles OK.
Liegt das evtl. am Decoder?
Weiter Loks wollte ich nicht aufs Gleis stellen. Kann mir hierzu jemand einen Rat geben, was zu tun?
Besten Dank schon im Voraus
Uwe
Hallo,
habe auch eine 218er von GFN mit Twin-Decoder (die Version mit dem korrekten Lichtwechsel beim Richungswechsel). Alle paar Wochen mal verliert der Decoder seine Adresse und steht dann wieder auf Adresse 3. Das ist bisher aber immer im laufenden Betrieb passiert, d.h. die Lok bleibt einfach stehen und reagiert nicht mehr auf Ihre ursprünglich programmierte Adresse. Alle anderen Loks mit älterer Twin-Decoder-Version oder anderen Decodern verhalten sich normal. Scheint meiner Meinung nach ein Fehler in dieser Decoder-Version zu sein.
Stefan
habe auch eine 218er von GFN mit Twin-Decoder (die Version mit dem korrekten Lichtwechsel beim Richungswechsel). Alle paar Wochen mal verliert der Decoder seine Adresse und steht dann wieder auf Adresse 3. Das ist bisher aber immer im laufenden Betrieb passiert, d.h. die Lok bleibt einfach stehen und reagiert nicht mehr auf Ihre ursprünglich programmierte Adresse. Alle anderen Loks mit älterer Twin-Decoder-Version oder anderen Decodern verhalten sich normal. Scheint meiner Meinung nach ein Fehler in dieser Decoder-Version zu sein.
Stefan
Um welche Version (CV7) handelt es sich genau?
Was sagt GFN dazu?
Was sagt GFN dazu?
Hallo,
endlich kann ich weiteres berichten. Herr Schmidt vom GFN Kundendienst meint, dass bei längerem Stillstand die Decodereinstellungen sich nicht verändern - das passiert nur bei Störungen während des Betriebes.
Die Loks 67138 und 67235 habe ich durchgereinigt, danach Reset durchgeführt und neu programmiert - sie fahren wieder.
Die Lok mit dem offensichtlichen Kurzschluss soll ich nochmals einschicken - es ist bereits das 2.mal seit dem Erwerb in 2004.
#1 Stefan, kann es sein, dass auf Deiner Anlage irgendwo mal ein Kurzschluss aufgetreten ist, als die 218 auf den Schienen war? Bei mir war es so, das könnte ein Grund sein, den/die Decoder zum "Verstellen" zu bringen.
#2 GFN 67138 hat CV 7=52
GFN 67236 hat CV7=42
Uwe
endlich kann ich weiteres berichten. Herr Schmidt vom GFN Kundendienst meint, dass bei längerem Stillstand die Decodereinstellungen sich nicht verändern - das passiert nur bei Störungen während des Betriebes.
Die Loks 67138 und 67235 habe ich durchgereinigt, danach Reset durchgeführt und neu programmiert - sie fahren wieder.
Die Lok mit dem offensichtlichen Kurzschluss soll ich nochmals einschicken - es ist bereits das 2.mal seit dem Erwerb in 2004.
#1 Stefan, kann es sein, dass auf Deiner Anlage irgendwo mal ein Kurzschluss aufgetreten ist, als die 218 auf den Schienen war? Bei mir war es so, das könnte ein Grund sein, den/die Decoder zum "Verstellen" zu bringen.
#2 GFN 67138 hat CV 7=52
GFN 67236 hat CV7=42
Uwe
Michorius* - 05.09.06 10:07
Hallo,
ich habe immer schlechte erfahrungen mit Twin Decoder gehabt. Ich habe 2 dieser Decoder gehabt, die erste in einer 218, die war nach 3 Tage vollig zerstort durch eine einwendige Kurzschluss und auch die Lichtwechsel funktionierte nicht (trotzdem richte fahrstufen eingestellt). Dann habe ich eine neue Twin Decoder einbauen lassen und nach 2 Tage war wieder eine Kurzschluss im Lok, die Lok fahrt noch, aber die Beleuchtung ist total kaputt. Ich empfehle darum: verwende andere Decoder wann es geht!
ich habe immer schlechte erfahrungen mit Twin Decoder gehabt. Ich habe 2 dieser Decoder gehabt, die erste in einer 218, die war nach 3 Tage vollig zerstort durch eine einwendige Kurzschluss und auch die Lichtwechsel funktionierte nicht (trotzdem richte fahrstufen eingestellt). Dann habe ich eine neue Twin Decoder einbauen lassen und nach 2 Tage war wieder eine Kurzschluss im Lok, die Lok fahrt noch, aber die Beleuchtung ist total kaputt. Ich empfehle darum: verwende andere Decoder wann es geht!
Hallo,
gestattet mir eine Expertise zu den GFN Decodern. Leider kann ich den Twin Decodern kein gutes Zeugnis ausstellen.
Wenn ich ehrlich sein darf, muss ich leider objektiv feststellen, dass die GFN Decoder allesamt ein Krampf sind. Jede Type und Version hat irgendeine Macke, das Timing streut von Exemplar zu Exemplar und ist zudem temperaturabhängig. Letzteren Effekt habe ich noch bei keinem anderen Mitbewerber gesehen. Wie das bei einem quarzstabilen Microcontroller passieren kann, ist mir ein Rätsel. Es muss wohl ein anderes Bauteil (keramischer Chipkondensator?) in der Dimensionierung hart an der Grenze sein.
Dabei hat sich der Programmierer doch sehr bemüht, das muss man lobend erwähnen, denn die CVs und Programmierfunktionen sind streng nach Norm implementiert. Bei der Motorregelung wird jedoch fehlendes Know-How deutlich. Soweit ich aus gut informierten Kreisen gehört habe, sei sich Fleischmann aber der Sachlage bewusst. Ich weiß allerdings nicht ob es offizielle Statements in dieser Richtung gibt bzw. jemals geben wird.
Version 4.2 ist der "H0"-Decoder 6846 - de facto handelt es sich um einen FMZ Decoder mit zusätzlichem DCC-Protokoll, so dass dieser funktionell selbst in der zweiten Version steinzeitlich anmutet. Leider wurde die Software nie auf den Level 5.2 gehoben. Dennoch wird dieses meiner Meinung nach stark überholte Produkt immer noch verbaut und verkauft! Ich hatte mir vor ein paar Monaten eine digitale BR 141 neu gekauft und war sehr enttäuscht, in einer N Lok dieses "Urgestein" vorzufinden, zumal der Verkaufspreis einen Einfachdecoder nicht rechtfertigt.
Version 5.2 ist der neuere "N"-Decoder 6849 - dieser wähnt relativ leicht ein Programmierkommando im Datensalat zu entdecken. Dabei kommt anscheinend intern Unsinn heraus, was den Decoder zu sofortigem Reset veranlasst.
Bei meinen Tests mit dem 6846 (4.2) hatte ich leider massivste Timing-Probleme beim Auslesen von CV #7 (geht nie im Direct Mode) und CVs ab #9 (korrekter Wert z.T. nur nach mehrmaligem Versuch) mit der Lenz Zentrale LZV100 festgestellt. Die "kleinen" Zentrale habe ich mit diesem Decoder nicht getestet. Ein Gegentest mit IB/TC steht noch aus.
Bei meinen Tests mit dem 6849 (5.1 und 5.2) musste ich festgestellen, dass die Programmierung mit Lenz Compact, Lokmaus2 und Zimo MX1EC nicht zuverlässig funktioniert. Beim Compact ist es wohl die geringe Programmierspannung, welche den Decoder während des CV Schreibens abstürzen lässt - vermutlich klappt das Schreiben des EEPROM nicht, und der Decoder führt dann ein Reset aus. Bei der Lokmaus tritt ähnliches auf, wenn der Page Mode als Programmierverfahren aktiviert ist. Beim MX1EC gibt es kein separates Programmiergleis, der fliegende Wechsel von Fahrbefehlen in den Service Mode verkraftet der Decoder irgendwie nicht und schreibt augenscheinlich Datenmüll im Registermode und quittiert diese auch brav - man kann zusehen wie die Lok nach einem CV-Lese- oder Schreibbefehl mehrfach zu rucken beginnt, anschließend sind die CV# 1,3,4,29 mit unsinnigen Werten überschrieben was darauf schließen lässt, dass zuvor irrtümlich Schreiboperationen auf R1-R5 abgearbeitet wurden. Hinsichtlich der "chronischen Resetitis" scheint die Version 5.2 noch empfindlicher zu sein als 5.1
Grüße, Peter W.
gestattet mir eine Expertise zu den GFN Decodern. Leider kann ich den Twin Decodern kein gutes Zeugnis ausstellen.
Wenn ich ehrlich sein darf, muss ich leider objektiv feststellen, dass die GFN Decoder allesamt ein Krampf sind. Jede Type und Version hat irgendeine Macke, das Timing streut von Exemplar zu Exemplar und ist zudem temperaturabhängig. Letzteren Effekt habe ich noch bei keinem anderen Mitbewerber gesehen. Wie das bei einem quarzstabilen Microcontroller passieren kann, ist mir ein Rätsel. Es muss wohl ein anderes Bauteil (keramischer Chipkondensator?) in der Dimensionierung hart an der Grenze sein.
Dabei hat sich der Programmierer doch sehr bemüht, das muss man lobend erwähnen, denn die CVs und Programmierfunktionen sind streng nach Norm implementiert. Bei der Motorregelung wird jedoch fehlendes Know-How deutlich. Soweit ich aus gut informierten Kreisen gehört habe, sei sich Fleischmann aber der Sachlage bewusst. Ich weiß allerdings nicht ob es offizielle Statements in dieser Richtung gibt bzw. jemals geben wird.
Version 4.2 ist der "H0"-Decoder 6846 - de facto handelt es sich um einen FMZ Decoder mit zusätzlichem DCC-Protokoll, so dass dieser funktionell selbst in der zweiten Version steinzeitlich anmutet. Leider wurde die Software nie auf den Level 5.2 gehoben. Dennoch wird dieses meiner Meinung nach stark überholte Produkt immer noch verbaut und verkauft! Ich hatte mir vor ein paar Monaten eine digitale BR 141 neu gekauft und war sehr enttäuscht, in einer N Lok dieses "Urgestein" vorzufinden, zumal der Verkaufspreis einen Einfachdecoder nicht rechtfertigt.
Version 5.2 ist der neuere "N"-Decoder 6849 - dieser wähnt relativ leicht ein Programmierkommando im Datensalat zu entdecken. Dabei kommt anscheinend intern Unsinn heraus, was den Decoder zu sofortigem Reset veranlasst.
Bei meinen Tests mit dem 6846 (4.2) hatte ich leider massivste Timing-Probleme beim Auslesen von CV #7 (geht nie im Direct Mode) und CVs ab #9 (korrekter Wert z.T. nur nach mehrmaligem Versuch) mit der Lenz Zentrale LZV100 festgestellt. Die "kleinen" Zentrale habe ich mit diesem Decoder nicht getestet. Ein Gegentest mit IB/TC steht noch aus.
Bei meinen Tests mit dem 6849 (5.1 und 5.2) musste ich festgestellen, dass die Programmierung mit Lenz Compact, Lokmaus2 und Zimo MX1EC nicht zuverlässig funktioniert. Beim Compact ist es wohl die geringe Programmierspannung, welche den Decoder während des CV Schreibens abstürzen lässt - vermutlich klappt das Schreiben des EEPROM nicht, und der Decoder führt dann ein Reset aus. Bei der Lokmaus tritt ähnliches auf, wenn der Page Mode als Programmierverfahren aktiviert ist. Beim MX1EC gibt es kein separates Programmiergleis, der fliegende Wechsel von Fahrbefehlen in den Service Mode verkraftet der Decoder irgendwie nicht und schreibt augenscheinlich Datenmüll im Registermode und quittiert diese auch brav - man kann zusehen wie die Lok nach einem CV-Lese- oder Schreibbefehl mehrfach zu rucken beginnt, anschließend sind die CV# 1,3,4,29 mit unsinnigen Werten überschrieben was darauf schließen lässt, dass zuvor irrtümlich Schreiboperationen auf R1-R5 abgearbeitet wurden. Hinsichtlich der "chronischen Resetitis" scheint die Version 5.2 noch empfindlicher zu sein als 5.1
Grüße, Peter W.
Hallo Uwe
hatten ähnliche probleme mit unserer br62 (gfn 67053). nach längeren standzeiten
war gesamte programmierung weg und lok wieder auf werkseinstellung.
wir fahren dcc und nach einiger tüfftelei (sind da auch noch nicht so fit mit digital)
haben wir FMZ im Twin-decoder abgeschaltet. Seither gibts keine probleme mehr
auch wenn die lok wochenlang in verpackung lag, aufs gleis stellen und alles
funktioniert wie eingestellt.
grüssle
willi
PS: Peter hats sehr wissenschaftlich ausgedrückt - ich sags mal leihenhaft :
die GFN Decoder sind wirklich nicht doll und für weniger Geld gibts
anderstwo wirklich Bessere.
Beitrag editiert am 05. 09. 2006 11:19.
hatten ähnliche probleme mit unserer br62 (gfn 67053). nach längeren standzeiten
war gesamte programmierung weg und lok wieder auf werkseinstellung.
wir fahren dcc und nach einiger tüfftelei (sind da auch noch nicht so fit mit digital)
haben wir FMZ im Twin-decoder abgeschaltet. Seither gibts keine probleme mehr
auch wenn die lok wochenlang in verpackung lag, aufs gleis stellen und alles
funktioniert wie eingestellt.
grüssle
willi
PS: Peter hats sehr wissenschaftlich ausgedrückt - ich sags mal leihenhaft :
die GFN Decoder sind wirklich nicht doll und für weniger Geld gibts
anderstwo wirklich Bessere.
Beitrag editiert am 05. 09. 2006 11:19.
Hallo,
ein interessanter Aspekt. Ich selbst habe das "Vergessen" der Einstellungen im normalen Betrieb, auch nach längerer Lagerung, bei den Twins noch nicht gesehen, dafür hatte ich es aber beim DCC-Decoder (Version 6.2, digitale BR 80) nachdem die Lok an ein Hindernis gefahren war.
Allerdings habe ich nur reines DCC Signal am Gleis und schalte aus Prinzip beim Aufgleisen von Fahrzeugen die Schienenspannung immer ab.
Grüße, Peter W.
ein interessanter Aspekt. Ich selbst habe das "Vergessen" der Einstellungen im normalen Betrieb, auch nach längerer Lagerung, bei den Twins noch nicht gesehen, dafür hatte ich es aber beim DCC-Decoder (Version 6.2, digitale BR 80) nachdem die Lok an ein Hindernis gefahren war.
Allerdings habe ich nur reines DCC Signal am Gleis und schalte aus Prinzip beim Aufgleisen von Fahrzeugen die Schienenspannung immer ab.
Grüße, Peter W.
Guten Abend
Zum Thema FMZ habe ich eine weitere Frage. Ich besitze eine FLM V212. Diese habe ich gestern nun zum Zwecke der Kohlenerneuerung geöffnet. Nachdem die Kohlen und Federn ausgetauscht waren fuhr die Lok auf der Anlage eindeutig besser. Aber das Spitzensignal ist nun leider vertauscht, d.h.: es leuchtet immer in die falsche Richtung. Darum wollte ich die Decoderdaten mit der IB auslesen und siehe da bei CV#1, CV#2 usw. meldet die IB immer "Fehler". Die Lok läuft aber noch unter der vorherigen Basisadresse CV#1=1. Welches Problem liegt hier vor? Bisher habe ich den Decoder immer sauber auslesen und programmieren können. Wer hat zu den beschriebenen Problemen einen Tip.
Wie immer, vielen Dank im Voraus.
Mfg
K.H.Nick
Zum Thema FMZ habe ich eine weitere Frage. Ich besitze eine FLM V212. Diese habe ich gestern nun zum Zwecke der Kohlenerneuerung geöffnet. Nachdem die Kohlen und Federn ausgetauscht waren fuhr die Lok auf der Anlage eindeutig besser. Aber das Spitzensignal ist nun leider vertauscht, d.h.: es leuchtet immer in die falsche Richtung. Darum wollte ich die Decoderdaten mit der IB auslesen und siehe da bei CV#1, CV#2 usw. meldet die IB immer "Fehler". Die Lok läuft aber noch unter der vorherigen Basisadresse CV#1=1. Welches Problem liegt hier vor? Bisher habe ich den Decoder immer sauber auslesen und programmieren können. Wer hat zu den beschriebenen Problemen einen Tip.
Wie immer, vielen Dank im Voraus.
Mfg
K.H.Nick
Hallo,
Ich nehme an Du hast beim Zusammenbau den Motor verdreht. Drehe den Motor um 180°, dann stimmt die Fahrtrichtung wieder mit dem Licht überein. Weshalb das Auslesen/Programmieren jetzt nicht funktioniert, kann ich so nicht sagen.
Grüße, Peter W.
Ich nehme an Du hast beim Zusammenbau den Motor verdreht. Drehe den Motor um 180°, dann stimmt die Fahrtrichtung wieder mit dem Licht überein. Weshalb das Auslesen/Programmieren jetzt nicht funktioniert, kann ich so nicht sagen.
Grüße, Peter W.
Hi, Peter
Vielen Dank. Auf den verdrehten Motor hätte ich auch selber kommen können. Habe leider nicht daran gedacht. Hatte früher schon mal ein ähnlichesProblem, das dann nur durch eine Veränderung der CV-Werte gelöst werden konnte. Deswegen habe ich das Lesen der CV's durchgeführt . Nun bleibt das Problem mit der IB und dem Decoder. Ist es möglich, das durch ein Update der Intellibox diese ältere Decoder nicht mehr lesen kann?
mfg
K.H.Nick
Vielen Dank. Auf den verdrehten Motor hätte ich auch selber kommen können. Habe leider nicht daran gedacht. Hatte früher schon mal ein ähnlichesProblem, das dann nur durch eine Veränderung der CV-Werte gelöst werden konnte. Deswegen habe ich das Lesen der CV's durchgeführt . Nun bleibt das Problem mit der IB und dem Decoder. Ist es möglich, das durch ein Update der Intellibox diese ältere Decoder nicht mehr lesen kann?
mfg
K.H.Nick
Nur registrierte und eingeloggte User können Antworten schreiben.
Einloggen ->
Noch nicht registriert? Hier können Sie Ihren kostenlosen Account anlegen: Neuer N-Liste Account
Zum Seitenanfang
© by 1zu160.net;