Anzeige:
THEMA: Umfrage zu GFN DCC Decoder
THEMA: Umfrage zu GFN DCC Decoder
Werte Gemeinde,
einige haben ja festgestellt, das die GFN DCC Decoder ein Problem
mit dem Nothalt haben.
Gelegentlich reagieren diese eben nicht bzw. verspätet auf den Nothalt.
Um dem Problem auf den Grund zu gehen, benötige ich Angaben zu den
Steuergräten (Digitalzentralen) und deren Softwarestand.
Könnt ihr mir also bitte mal mitteilen, wer das Problem mit
welcher Zentrale hat und welche Software Version diese Zentrale hat.
Vielen Dank im Voraus und schöne Grüße
Uli
www.uli-johann.de
einige haben ja festgestellt, das die GFN DCC Decoder ein Problem
mit dem Nothalt haben.
Gelegentlich reagieren diese eben nicht bzw. verspätet auf den Nothalt.
Um dem Problem auf den Grund zu gehen, benötige ich Angaben zu den
Steuergräten (Digitalzentralen) und deren Softwarestand.
Könnt ihr mir also bitte mal mitteilen, wer das Problem mit
welcher Zentrale hat und welche Software Version diese Zentrale hat.
Vielen Dank im Voraus und schöne Grüße
Uli
www.uli-johann.de
Gebhard [Gast] - 04.03.05 11:48
Hallo,
habe dieses Thema noch einmal hervorgeholt, weil ich auch Probleme mit den GFN DCC-Decodern (6857-6859) habe bzw. hatte. Ich betreibe die Decoder mit dem TC, Softwarestand 1.1.
Bisher habe ich die Decoder immer mit den Werkseinstellungen (Ausnahme: CV 29 Bit 1 von 1auf 0 gestellt) und optimierter Geschwindigkeitskennlinie (CV 67-CV 94) gefahren. Probleme mit dem Überfahren von Haltepunkten auch bei der eingestellten Verzögerung von CV 4 = 3 sind hierbei nicht eingetreten.
Gestern habe mal an einem Decoder in der BR 78 Änderungen an folgenden CV vorgenommen:
CV 12 von 1 auf 0, CV 29 von 22 auf 2 und CV 5 von 132 auf 65
Übersetzt bedeutet das ja, dass nur digitaler Betrieb mit 28 Fahrstufen und der Geschwindigkeitskennlinie CV 2 und CV 5 möglich ist.
Das Ergebnis war dann das verspätete Anhalten der Lokomotive bei Halt.
Anfang 2004 hatte ich schon mal dieses Problem an einem Schienenbus mit dem GFN-Decoder. Aus lauter Frust habe ich ihn durch einen Tran-Decoder ersetzt. Auf der Messe in Dortmund hatte ich allerdings dieses Problem mit dem Kundendienst von Fleischmann besprochen. Es konnte mir nicht sofort geholfen werden, aber nach ca. einer Woche erhielt ich eine E-Mail mit einer Problemlösung. Da ich ja den Decoder ausgewechselt hatte, war der Vorschlag von GFN momentan für mich nicht mehr wichtig. Die E-Mail war bei mir jedoch auf dem Rechner gespeichert.
Gestern habe ich noch einmal nachgeschaut. Der Kundendienst von GFN schlug vor, die Sonderoption 904 im TC von 28 auf 40 zu verstellen. Mit dieser Maßnahme sollen die DCC-Befehle häufiger gesendet werden.
Ich habe die Sonderoption 904 entsprechend verstellt. Das Ergebnis kann sich sehen lassen. Das Überfahren des Haltepunktes gehört bei mir der Vergangenheit an.
Ich habe nicht mehr geprüft, welche CV nun für das o.g. Problem verantwortlich ist. Vielleicht hilft es ja auch denen, die mit einem anderen Steuergerät ihre Anlage betreiben.
Viele Grüße
Gebhard
http://www.gk-moba.de
habe dieses Thema noch einmal hervorgeholt, weil ich auch Probleme mit den GFN DCC-Decodern (6857-6859) habe bzw. hatte. Ich betreibe die Decoder mit dem TC, Softwarestand 1.1.
Bisher habe ich die Decoder immer mit den Werkseinstellungen (Ausnahme: CV 29 Bit 1 von 1auf 0 gestellt) und optimierter Geschwindigkeitskennlinie (CV 67-CV 94) gefahren. Probleme mit dem Überfahren von Haltepunkten auch bei der eingestellten Verzögerung von CV 4 = 3 sind hierbei nicht eingetreten.
Gestern habe mal an einem Decoder in der BR 78 Änderungen an folgenden CV vorgenommen:
CV 12 von 1 auf 0, CV 29 von 22 auf 2 und CV 5 von 132 auf 65
Übersetzt bedeutet das ja, dass nur digitaler Betrieb mit 28 Fahrstufen und der Geschwindigkeitskennlinie CV 2 und CV 5 möglich ist.
Das Ergebnis war dann das verspätete Anhalten der Lokomotive bei Halt.
Anfang 2004 hatte ich schon mal dieses Problem an einem Schienenbus mit dem GFN-Decoder. Aus lauter Frust habe ich ihn durch einen Tran-Decoder ersetzt. Auf der Messe in Dortmund hatte ich allerdings dieses Problem mit dem Kundendienst von Fleischmann besprochen. Es konnte mir nicht sofort geholfen werden, aber nach ca. einer Woche erhielt ich eine E-Mail mit einer Problemlösung. Da ich ja den Decoder ausgewechselt hatte, war der Vorschlag von GFN momentan für mich nicht mehr wichtig. Die E-Mail war bei mir jedoch auf dem Rechner gespeichert.
Gestern habe ich noch einmal nachgeschaut. Der Kundendienst von GFN schlug vor, die Sonderoption 904 im TC von 28 auf 40 zu verstellen. Mit dieser Maßnahme sollen die DCC-Befehle häufiger gesendet werden.
Ich habe die Sonderoption 904 entsprechend verstellt. Das Ergebnis kann sich sehen lassen. Das Überfahren des Haltepunktes gehört bei mir der Vergangenheit an.
Ich habe nicht mehr geprüft, welche CV nun für das o.g. Problem verantwortlich ist. Vielleicht hilft es ja auch denen, die mit einem anderen Steuergerät ihre Anlage betreiben.
Viele Grüße
Gebhard
http://www.gk-moba.de
Hallo Gebhard,
vielen Dank für diese wertvolle Info. Dies deutet eindeutig auf ein Problem im Decoder hin.
Dieser Wert in der SO der IB/TC kaschiert ganz offensichtlich einen schweren Firmwarefehler (vermutlich Timing-Problem) im Bereich der Decodierung von DCC Paketen im allgemeinen oder von Fahrbefehlen im speziellen.
Wenn GFN so eine Umgehung in der Zentrale vorschlägt, ist das wohl der eindeutige Beweis dafür dass sie ein Problem in der Firmware des Decoders haben.
Dann sollten sie aber dieses bitte auch beheben und nicht munter weiter fehlerhafte Decoder ausliefern!!!
Grüße, Peter W.
vielen Dank für diese wertvolle Info. Dies deutet eindeutig auf ein Problem im Decoder hin.
Dieser Wert in der SO der IB/TC kaschiert ganz offensichtlich einen schweren Firmwarefehler (vermutlich Timing-Problem) im Bereich der Decodierung von DCC Paketen im allgemeinen oder von Fahrbefehlen im speziellen.
Wenn GFN so eine Umgehung in der Zentrale vorschlägt, ist das wohl der eindeutige Beweis dafür dass sie ein Problem in der Firmware des Decoders haben.
Dann sollten sie aber dieses bitte auch beheben und nicht munter weiter fehlerhafte Decoder ausliefern!!!
Grüße, Peter W.
jaN [Gast] - 04.03.05 15:28
Ich kann mich nur Peters Statement anschließend.
Ich habe ebenfalls diese Probleme gehabt und eine Mail an GFN geschrieben und bis heute keine Antwort erhalten! Aus lauter Frust habe ich die Decoder dann ausgetauscht.
Ich fahre mit Lenz Set 90, Version 3.5.
Gibt es denn ein Statement von GFN, daß das Problem behoben ist,
Fragt sich
jaN
Ich habe ebenfalls diese Probleme gehabt und eine Mail an GFN geschrieben und bis heute keine Antwort erhalten! Aus lauter Frust habe ich die Decoder dann ausgetauscht.
Ich fahre mit Lenz Set 90, Version 3.5.
Gibt es denn ein Statement von GFN, daß das Problem behoben ist,
Fragt sich
jaN
Uli Johann [Gast] - 05.03.05 10:55
Hallo jaN,
nein, es gibt kein Statement von GFN.
Man nimmt sich der Sache an. Anders als bei Lenz, von dort kommen öfters
nur Antworten, "Mit unseren Geräten funktioniert alles".
Gruß
Uli
nein, es gibt kein Statement von GFN.
Man nimmt sich der Sache an. Anders als bei Lenz, von dort kommen öfters
nur Antworten, "Mit unseren Geräten funktioniert alles".
Gruß
Uli
Klaus Killinger [Gast] - 05.03.05 12:24
Hallo,
mit meinem VT95 (87400, gekauft in 11/2003) habe ich ebenfalls Probleme.
Das Hauptproblem ist (oder war?), daß sich das Tfz nicht kontrolliert anhalten läßt
und mehrfach auch auf Nothalt nicht reagiert.
Ich fahre mit Intellibox, SW Version 1.201, und mit Lenz-Booster LV101.
Von GFN kam vor kurzem folgender Tip zum Nothaltproblem:
1. IB SO 25=1
2. IB SO 907=4
3. IB Grundeinstellung > Datenformat=DCC, 128 FS
4. IB Grundeinstellung Zurücksetzen > Lok-Datenformat
Die Einstellungen 1-3 waren bei meiner IB bereits so vorgenommen. Die
Rücksetzung des Lok-Datenformats hat das Nothalt-Problem bei mir erstmal
beseitigt. Früher hatte ich mal ein Tfz mit Selectrix-Decoder laufen, so
daß mit Sicherheit entsprechende Daten in der IB vorhanden waren.
Mein VT95 läßt sich jetzt kontrolliert anhalten und reagiert auf jeden
Nothalt. Bisher habe ich etwa eine Stunde getestet.
Allerdings hat ein Vereinskollege das Nothaltproblem weiterhin, trotz Einstellungen der Zentrale wie oben beschrieben.
Die SO 904 steht bei mir auf 28. Da werde ich noch einen höheren Wert ausprobieren. Danke für diesen Tip!
Gruß
Klaus
mit meinem VT95 (87400, gekauft in 11/2003) habe ich ebenfalls Probleme.
Das Hauptproblem ist (oder war?), daß sich das Tfz nicht kontrolliert anhalten läßt
und mehrfach auch auf Nothalt nicht reagiert.
Ich fahre mit Intellibox, SW Version 1.201, und mit Lenz-Booster LV101.
Von GFN kam vor kurzem folgender Tip zum Nothaltproblem:
1. IB SO 25=1
2. IB SO 907=4
3. IB Grundeinstellung > Datenformat=DCC, 128 FS
4. IB Grundeinstellung Zurücksetzen > Lok-Datenformat
Die Einstellungen 1-3 waren bei meiner IB bereits so vorgenommen. Die
Rücksetzung des Lok-Datenformats hat das Nothalt-Problem bei mir erstmal
beseitigt. Früher hatte ich mal ein Tfz mit Selectrix-Decoder laufen, so
daß mit Sicherheit entsprechende Daten in der IB vorhanden waren.
Mein VT95 läßt sich jetzt kontrolliert anhalten und reagiert auf jeden
Nothalt. Bisher habe ich etwa eine Stunde getestet.
Allerdings hat ein Vereinskollege das Nothaltproblem weiterhin, trotz Einstellungen der Zentrale wie oben beschrieben.
Die SO 904 steht bei mir auf 28. Da werde ich noch einen höheren Wert ausprobieren. Danke für diesen Tip!
Gruß
Klaus
Christoph S. [Gast] - 05.03.05 16:39
Hallo,
die Probleme mit dem Fleischmann-Decoder waren hier schon mal Thema vor ca. einem Jahr:
http://www.1zu160.net/scripte/slimboard1/forum_show.php?id=46910
Ich hatte mir damals den GFN-Schienenbus (BR795, Kat.-Nr. 87402) und die BR064 (Kat.-Nr. 87064) in der digitalisierten Version zugelegt und habe bei beiden Fahrzeugen die gleichen Probleme (genauere Beschreibung in o.g. Link ab Antwort Nr. 10).
Ich benutze folgende Konfiguration:
Zentrale: Lenz LZ100, Version 3.1
Handregler: Lenz LH100, Version 3.0
Booster: Lenz LV100
Stromversorgung: Märklin 6002
Lokdecoder: Lenz LH030/040/010XF/011XF/075,
Arnold 81xxx (LDE030), Arnold 81210, Uhlenbrock 73500, ESU-Sounddecoder in GFN 77236 = 218-Doppeltraktion (funktionieren alle anstandslos);
GFN 696859 (in bereits digitalisierten 87064 bzw. 87402),
Fazit: In meinem vorhandenen "Decoder-Zoo" funktionieren alle außer den GFN-Teilen 696859 einwandfrei (ja, auch der Uhlenbrock.png)
), also nehme ich an, daß das Problem wirklich in den Decoderen steckt und nicht im Lenz-System.
Viele Grüße
Christoph S.
die Probleme mit dem Fleischmann-Decoder waren hier schon mal Thema vor ca. einem Jahr:
http://www.1zu160.net/scripte/slimboard1/forum_show.php?id=46910
Ich hatte mir damals den GFN-Schienenbus (BR795, Kat.-Nr. 87402) und die BR064 (Kat.-Nr. 87064) in der digitalisierten Version zugelegt und habe bei beiden Fahrzeugen die gleichen Probleme (genauere Beschreibung in o.g. Link ab Antwort Nr. 10).
Ich benutze folgende Konfiguration:
Zentrale: Lenz LZ100, Version 3.1
Handregler: Lenz LH100, Version 3.0
Booster: Lenz LV100
Stromversorgung: Märklin 6002
Lokdecoder: Lenz LH030/040/010XF/011XF/075,
Arnold 81xxx (LDE030), Arnold 81210, Uhlenbrock 73500, ESU-Sounddecoder in GFN 77236 = 218-Doppeltraktion (funktionieren alle anstandslos);
GFN 696859 (in bereits digitalisierten 87064 bzw. 87402),
Fazit: In meinem vorhandenen "Decoder-Zoo" funktionieren alle außer den GFN-Teilen 696859 einwandfrei (ja, auch der Uhlenbrock
), also nehme ich an, daß das Problem wirklich in den Decoderen steckt und nicht im Lenz-System.Viele Grüße
Christoph S.
Uli Johann [Gast] - 05.03.05 16:50
Hallo Christoph,
es steht außer Frage, das es am Decoder liegt. Es gibt aber Kollegen, die
haben z.B. ein Digitrax Gerät und kennen das Problem nicht.
Gruß
Uli
http://www.uli-johann.de
es steht außer Frage, das es am Decoder liegt. Es gibt aber Kollegen, die
haben z.B. ein Digitrax Gerät und kennen das Problem nicht.
Gruß
Uli
http://www.uli-johann.de
Fränzi [Gast] - 07.03.05 12:34
Ich finde es schon sehr ärgerlich von Fleischmann, dass in vollem Wissen um die Probleme trotzdem Decoder eingebaut werden, die nur punktuell funktionieren. Bei Billiganbietern muss man damit rechnen, aber bei dem Preisniveau von Fleischmann ist das eine Unverschämtheit gegenüber treuen Kunden.
thomasb [Gast] - 07.03.05 13:44
Habe alle GFN-DCC-Decoder ausgetauscht gegen Zimo-Decoder. Lediglich im ICE-T von GFN ist noch ein GFN-Decoder, weil der ICE-T sich mit den Zimo-Decodern wohl nicht verträgt.
Der Grund, warum ich getauscht habe:
Wenn ich am Twin-Center den Fahrregler ab Fahrstufe 4 bis 28 gedrückt habe (Nothalt) und wollte dann die Fahrtrichtung wechseln, machte jede Lok mit eingebautem GFN-DCC-Decoder einen kleinen Sprung.
Grüße
Thomas
Der Grund, warum ich getauscht habe:
Wenn ich am Twin-Center den Fahrregler ab Fahrstufe 4 bis 28 gedrückt habe (Nothalt) und wollte dann die Fahrtrichtung wechseln, machte jede Lok mit eingebautem GFN-DCC-Decoder einen kleinen Sprung.
Grüße
Thomas
@9
>Lediglich im ICE-T von GFN ist noch ein GFN-Decoder, weil der ICE-T sich mit den Zimo-Decodern wohl nicht verträgt.
Was hast du denn für Probleme gehabt, und speziell mit welchem Decoder?
fragt
Helmut
der seinen ICE-T auch noch auf Zimo umrüsten muss
>Lediglich im ICE-T von GFN ist noch ein GFN-Decoder, weil der ICE-T sich mit den Zimo-Decodern wohl nicht verträgt.
Was hast du denn für Probleme gehabt, und speziell mit welchem Decoder?
fragt
Helmut
der seinen ICE-T auch noch auf Zimo umrüsten muss
thomasb [Gast] - 07.03.05 14:19
Der ICE-T blieb einfach immer mal wieder plötzlich stehen.
Es gibt da auch einen Extra-Thread. Und Peter W. wollte sich mal bei Zimo bei einem Stammtisch erkundigen, weil hier schon einige User von solchen Problemen mit den Zimo-Decodern geschrieben haben.
Mit beiden Decodern (MX62 und MX63) hatte ich beim ICE-T diese Probleme.
Ansonsten bin ich mit den Zimo-decodern aber sehr zufrieden.
Es gibt da auch einen Extra-Thread. Und Peter W. wollte sich mal bei Zimo bei einem Stammtisch erkundigen, weil hier schon einige User von solchen Problemen mit den Zimo-Decodern geschrieben haben.
Mit beiden Decodern (MX62 und MX63) hatte ich beim ICE-T diese Probleme.
Ansonsten bin ich mit den Zimo-decodern aber sehr zufrieden.
Hallo,
die Problemstellungen sind bei Zimo inzwischen bekannt aber ich weiß nicht ob es schon gelang, die Effekte unter Laborbedingungen nachzuvollziehen und messtechnisch zu erfassen bzw. eine Lösung zu finden.
Grüße, Peter W.
die Problemstellungen sind bei Zimo inzwischen bekannt aber ich weiß nicht ob es schon gelang, die Effekte unter Laborbedingungen nachzuvollziehen und messtechnisch zu erfassen bzw. eine Lösung zu finden.
Grüße, Peter W.
thomasb [Gast] - 08.03.05 08:25
Danke, Peter!
Grüße
Thomas
Grüße
Thomas
Uli Johann [Gast] - 08.03.05 10:00
thomasb [Gast] - 08.03.05 10:23
Hallo Uli,
du kennst ja meine Probleme mit den Decodern. Gerade mit dem ICE-T.
Aber die Zimo-Decoder sind da trotzdem die bessere Wahl. Die Langsamfahreigenschaften sind viel, viel besser als bei den GFN-DCC-Decodern. Ich habe da sehr lange getestet und verglichen.
Grüße, Thomas
du kennst ja meine Probleme mit den Decodern. Gerade mit dem ICE-T.
Aber die Zimo-Decoder sind da trotzdem die bessere Wahl. Die Langsamfahreigenschaften sind viel, viel besser als bei den GFN-DCC-Decodern. Ich habe da sehr lange getestet und verglichen.
Grüße, Thomas
Uli,
auch die Decoderfabrikatnen kochen alle nur mit Wasser. Leider wird die Möglichkeit der offiziellen Qualitätssicherung im Rahmen einer Zertifizierung durch die NRMA DCC Working Group (NMRA Konformitätssiegel) nur sehr wenig in Anspruch genommen. Die meisten Decoderhersteller führen derzeit die QA selbst durch, und zwar mit dem gleichen Messsystem. Jedoch ist dann für den Endkunden nicht sichtbar, ob die Produkte die festgelegten Mindestkriterien erfüllen oder nicht.
Grüße, Peter W.
auch die Decoderfabrikatnen kochen alle nur mit Wasser. Leider wird die Möglichkeit der offiziellen Qualitätssicherung im Rahmen einer Zertifizierung durch die NRMA DCC Working Group (NMRA Konformitätssiegel) nur sehr wenig in Anspruch genommen. Die meisten Decoderhersteller führen derzeit die QA selbst durch, und zwar mit dem gleichen Messsystem. Jedoch ist dann für den Endkunden nicht sichtbar, ob die Produkte die festgelegten Mindestkriterien erfüllen oder nicht.
Grüße, Peter W.
Uli Johann [Gast] - 08.03.05 15:09
Hallo Peter und Thomas,
ich weiß doch, es sollte ja absichtlich eine Spitze sein, da ich bombardiert werde mit
Klagen und Beschimpfungen und mal wieder hysterisch auf einem Hersteller rum gekloppt wird.
Es hilft aber nix. Alle haben ihre Leichen im Keller und nur der Dialog hilft das abstellen. Einzig wer nicht in den Dialog tritt, wie Kühn z.B. kricht auch von mir kloppe.png)
Gruß
Uli
ich weiß doch, es sollte ja absichtlich eine Spitze sein, da ich bombardiert werde mit
Klagen und Beschimpfungen und mal wieder hysterisch auf einem Hersteller rum gekloppt wird.
Es hilft aber nix. Alle haben ihre Leichen im Keller und nur der Dialog hilft das abstellen. Einzig wer nicht in den Dialog tritt, wie Kühn z.B. kricht auch von mir kloppe
Gruß
Uli
thomasb [Gast] - 08.03.05 16:12
Hallo Uli,
hatte es schon so verstanden.
Grüße
Thomas
hatte es schon so verstanden.
Grüße
Thomas
Hallo Uli,
gestern hatte ich einen neuen Effekt. Bei Tests mit geringerer Gleisspannung (ca. 13 V) hatte ich durch Aussetzer 2x einen Decoder-Crash mit destruktiver Auswirkung auf die CV-Werte im EEPROM (eigentlich ungewollt) hervorgerufen.
Plötzlich warte einige CVs (jedenfalls CV1, CV3 und CV29) auf unsinnige Werte verstellt.
Soetwas darf meiner Meinung nach nicht so einfach passieren.
Grüße, Peter W.
gestern hatte ich einen neuen Effekt. Bei Tests mit geringerer Gleisspannung (ca. 13 V) hatte ich durch Aussetzer 2x einen Decoder-Crash mit destruktiver Auswirkung auf die CV-Werte im EEPROM (eigentlich ungewollt) hervorgerufen.
Plötzlich warte einige CVs (jedenfalls CV1, CV3 und CV29) auf unsinnige Werte verstellt.
Soetwas darf meiner Meinung nach nicht so einfach passieren.
Grüße, Peter W.
Stephan [Gast] - 03.06.05 20:05
Hallo Peter,
ich betreibe meine Anlage mit dem TC von GFN im Mischbetrieb FMZ/DCC/SX. Seit einiger Zeit beobachte ich hierbei, dass sich einige Trix decoder (66836/38) selbsttätig umprogrammieren. Plötzlich sind alle Werte verändert. Kann dies auch mit der Gleisspannung zusammenhängen? Denn ich habe die Anlage Step bei Step erweitert und zum Teil stehen 20 Loks unter Trom (hiervon sind max. im Fahrbetrieb)?
Gruß Stephan
ich betreibe meine Anlage mit dem TC von GFN im Mischbetrieb FMZ/DCC/SX. Seit einiger Zeit beobachte ich hierbei, dass sich einige Trix decoder (66836/38) selbsttätig umprogrammieren. Plötzlich sind alle Werte verändert. Kann dies auch mit der Gleisspannung zusammenhängen? Denn ich habe die Anlage Step bei Step erweitert und zum Teil stehen 20 Loks unter Trom (hiervon sind max. im Fahrbetrieb)?
Gruß Stephan
thomasb [Gast] - 02.12.05 10:36
Ich möchte diesen Thread mal wieder nach oben holen.
Gibt es mittlerweile eine Stellungnahme von Fleischmann?
Weisen die neuen GFN-Decoder diese Fehler immer noch auf?
Grüße
Thomas
Gibt es mittlerweile eine Stellungnahme von Fleischmann?
Weisen die neuen GFN-Decoder diese Fehler immer noch auf?
Grüße
Thomas
Hallo,
mir ist keine Stellungnahme bekannt - hat sich überhaupt jemand mit GFN in Verbindung gesetzt? Werde nach München, also nächste Woche, mal bei der NMRA anfragen ob da was weiter geht.
Grüße, Peter W.
mir ist keine Stellungnahme bekannt - hat sich überhaupt jemand mit GFN in Verbindung gesetzt? Werde nach München, also nächste Woche, mal bei der NMRA anfragen ob da was weiter geht.
Grüße, Peter W.
Fleischmann kennt den Fehler, denkt aber nicht daran, ihn zu beheben.
O-Ton am Telefon: "Kein Mensch benötigt die adressbezogene Notstopfunktion". Nach deren Meinung bin ich kein Mensch, aber ich kaufe auch kein einzigen Digitalprodukt mehr von GFN.
O-Ton am Telefon: "Kein Mensch benötigt die adressbezogene Notstopfunktion". Nach deren Meinung bin ich kein Mensch, aber ich kaufe auch kein einzigen Digitalprodukt mehr von GFN.
Hallo,
diese Reaktion seitens eines so tollen Herstellers wie GFN ist sehr sehr bedauerlich denn dies zeigt wie wenig Sach- und Marktkenntnis sie auf dem Sektor der digitalen Mehrzugsteuerung noch haben.
Es gibt auch noch andere Dinge wie z.B. Anfälligkeit ggü. Signalverzerrung durch Nichteinhaltung der lt. Spec geforderten Signal-Toleranzen oder gänzliches Fehlen des PoM (Hauptgleisprogrammierung). Letzteres ist wettbewerbsverzerrend da GFN die Decoder bewirbt so dass beim Endkunden der Eindruck entstehen könnte, alle Funktionen der hauseigenen Zentrale (TC) würden auch von den hauseigenen Decoder unterstützt.
Betreffend den adressspezifischen Nothalt: Ist es nicht so, dass man bei der IB/TC laut Doku 2x auf den Knopf hauen soll und erwarten kann dass die Lok dann sofort steht?
Grüße, Peter W.
diese Reaktion seitens eines so tollen Herstellers wie GFN ist sehr sehr bedauerlich denn dies zeigt wie wenig Sach- und Marktkenntnis sie auf dem Sektor der digitalen Mehrzugsteuerung noch haben.
Es gibt auch noch andere Dinge wie z.B. Anfälligkeit ggü. Signalverzerrung durch Nichteinhaltung der lt. Spec geforderten Signal-Toleranzen oder gänzliches Fehlen des PoM (Hauptgleisprogrammierung). Letzteres ist wettbewerbsverzerrend da GFN die Decoder bewirbt so dass beim Endkunden der Eindruck entstehen könnte, alle Funktionen der hauseigenen Zentrale (TC) würden auch von den hauseigenen Decoder unterstützt.
Betreffend den adressspezifischen Nothalt: Ist es nicht so, dass man bei der IB/TC laut Doku 2x auf den Knopf hauen soll und erwarten kann dass die Lok dann sofort steht?
Grüße, Peter W.
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;