Hallo,

ich habe einen Piko SmartDecoder 56401 sowie einen Piko SoundDecoder 56483. Bei beiden Decodern funktioniert die Railcom Adressrückmeldung nicht, wenn ich den Railcom Channel1 (CV28, Bit0=0) ausschalte und nur mit Channel2 (CV28, Bit1=1) fahre. Das ist sehr unschön, da ich Channel1 eigentlich nirgendwo mehr nutzen möchte wegen der Datenflut. Gerade wenn man mehrere Loks in einem Gleisabschnitt hat, kommt es dann zu Fehlmeldungen.
Kennt jemand einen Trick, wie man dieses Problem lösen kann? Piko habe ich schon angeschrieben, da kam jedoch bisher keine Antwort.
Den Smartprogrammer von Piko habe ich nicht und könnte deswegen auch kein Decoder Firmware-Update durchführen, falls das die Lösung wäre.

Hallo André und "Digital-Anwender",

ich besitze von Piko die Vossloh DB Cargo G6 #52654. Die meldet mir in CV8 den Herstellercode 85, welcher der Fa. Uhlenbrock GmbH zugeordnet ist. Soweit mir bekannt, sind die Piko SmartDecoder in Kooperation mit Uhlenbrock entwickelt worden und dürften damit zumindest ähnliche Eigenschaften aufweisen.

Ich beobachte in meiner Testumgebung (D&H FCC mit D&H Rückmelder und TrainController bzw D&H Tool) bei diesem Decoder das gleiche Phänomen. Deaktiviere ich den RailCom Channel1 und habe nur noch Channel2 aktiv (CV28=2), dann erhalte ich von der Lok keine Adressrückmeldung (Adr.: 212) mehr.

Aktiviere ich Channel1 wieder indem ich den Wert von CV28 zurück auf den Default 3 setze, dann funktioniert es wieder. Der gleiche Effekt tritt auch auf, wenn ich das Gleissignal mit der z21 (weiß generiere und die FCC zusammen mit dem Rückmelder nur als Interface in Richtung PC/Software verwende. Sehr merkwürdig und nicht konform zur RCN-217.

Mir ist nicht bekannt, ob der Decoder in meiner Vossloh DB Cargo G6 auf eine automatische Channel1/Channel2 Nutzung (deaktiviert automatisch Channel1 und aktiviert Channel2, wenn er an ihn adressierte Daten empfängt) parametriert werden kann. Muss mal in der Richtung suchen/forschen.

Beste Grüße
Werner

Zitat

---

Ich beobachte in meiner Testumgebung (D&H FCC mit D&H Rückmelder und TrainController bzw D&H Tool) bei diesem Decoder das gleiche Phänomen. Deaktiviere ich den RailCom Channel1 und habe nur noch Channel2 aktiv (CV28=2), dann erhalte ich von der Lok keine Adressrückmeldung (Adr.: 212) mehr.
...
Der gleiche Effekt tritt auch auf, wenn ich das Gleissignal mit der z21 (weiß generiere und die FCC zusammen mit dem Rückmelder nur als Interface in Richtung PC/Software verwende. Sehr merkwürdig und nicht konform zur RCN-217.

---

Was passiert mit Deiner z21 im Maintenance-Tool, wenn Kanal 1 ausgeschaltet ist?
Auslesen der CVs mit POM geht?

MfG

vik

Hallo zusammen,

deaktiviere ich den RailCom Channel1 (CV28=2) und versuche nun über die z21 in Kombination mit dem Maintenance Tool über POM CV-Parameter auszulesen, dann erhalte ich in dem Tool die Fehlermeldung: "Kann CV xy nicht lesen. Result=NACK!". CV´s auslesen über POM ist bei dieser Parametrierung also nicht mehr möglich.

Die identische Problematik zeigt sich auch, wenn ich komplett auf mein D&H Equipment (FCC, Rückmelder, D&H Tool) umstecke/-schalte. Auch hier kommt nichts mehr an.

Beste Grüße
Werner

Hallo zusammen,

Sowas habe ich befürchtet. Die SmartDecoder melden sich mit CV8=162 als PIKO Decoder. Die bucklige Uhlenschrott-Verwandschaft lässt sich erkennen. Ich war schon kurz davor mir einen Smartprogrammer zu kaufen, damit meine Piko Loks in Zukunft auch einen SmartDecoder bekommen (mit den ESUs laufen die immer wieder mal nicht rund). Aber mit diesem Pazer ist der SmartDecoder nun direkt raus aus der Verlosung. Auch sonst sind die Fahreigenschaften der Piko Loks mit dem SmartDecoder nicht unbedingt toll. Der Motor macht zudem den bekannten Uhlenbrock Lärm. Im Zusammmenspiel mit den ESU LoPis pfeiffen die Motoren (Modelle 243 576 & V180 203) nicht so schrill. Schade.
Vielleicht kommt noch irgendwann ein Update für die Decoder, damit Channel2 so funktioniert, wie er soll. Vielen Dank für Euer Feedback.

Hallo André,

Zitat

---

Die SmartDecoder melden sich mit CV8=162 als PIKO Decoder. Die bucklige Uhlenschrott-Verwandschaft lässt sich erkennen. Ich war schon kurz davor mir einen Smartprogrammer zu kaufen, damit meine Piko Loks in Zukunft auch einen SmartDecoder bekommen (mit den ESUs laufen die immer wieder mal nicht rund). Aber mit diesem Pazer ist der SmartDecoder nun direkt raus aus der Verlosung. Auch sonst sind die Fahreigenschaften der Piko Loks mit dem SmartDecoder nicht unbedingt toll. Der Motor macht zudem den bekannten Uhlenbrock Lärm. Im Zusammmenspiel mit den ESU LoPis pfeiffen die Motoren (Modelle 243 576 & V180 203) nicht so schrill. Schade.
Vielleicht kommt noch irgendwann ein Update für die Decoder, damit Channel2 so funktioniert, wie er soll. Vielen Dank für Euer Feedback.

---

auf ein Update habe ich beim Piko SmartControl bzw. der Piko Smartbox auch lange gehofft, vergeblich!

MfG

vik

Hallo Gemeinde,

Uhlenbrock hat mit ihrem *Hauseigenen Marco System* ein sehr gut funktionierendes Railcom System . Hierzu Uhlens....... zu sagen, ist Fehl am Platz. Vielleicht ist ein Update nötig oder es liegt eine Fehlbedienung vor.

Gruß
Andreas

Hallo Andreas,

Zitat

---

Uhlenbrock hat mit ihrem *Hauseigenen Marco System* ein sehr gut funktionierendes Railcom System . Hierzu Uhlens....... zu sagen, ist Fehl am Platz. Vielleicht ist ein Update nötig oder es liegt eine Fehlbedienung vor.

---

Nein, es scheint wohl eher das "chinesische" Geschäftsmodell von Piko zu sein, Entwicklungen von Firmen mit einem renomierten Namen preisgünstig einzukaufen, die billigste und angespeckteste Variante fertigen zu lassen und dabei den Kunden Glauben zu machen er bekomme das bekannte "Originalprodukt" nur eben günstiger über die Vertriebsstrukturen von Piko. Dabei scheint Piko dann auch noch zu hoffen, dass die Entwicklerfirmen in Problemfällen den Support beim Kunden schon übernehmen werden, um Schaden für den eigenen Ruf abzuwenden.

MfG

vik

Hallo RailCom User,

ich zweifele keinesfalls an, dass Uhlenbrock Komponenten im Programm hat, die mit RailCom Funktionalität beworben werden. So eben auch die hier diskutierten Lokdecoder, die sich aber ganz offensichtlich nicht so recht konform zum RailCom Standard verhalten. Zumindest nicht der, der sich in meiner Piko Vossloh DB Cargo G6 befindet.

Laut der CV-Liste auf der Uhlenbrock Homepage ist für CV28 folgende Parametrierung möglich: Bit0 = 1 -> Kanal1 ein, Bit1 = 1 -> Kanal2 ein, Bit7 = 1 -> RailCom Plus® ein. Ich denke, dies gilt auch für meinen Decoder in der Piko-Lok, zumindest hinsichtlich Bit0 u. Bit1. Gibt der sich doch als ein Uhlenbrock zu erkennen. Leider verhält er sich nicht so, wie die aufgeführten Parameter dies erwarten lassen. Ich bin der Meinung, dass hier eindeutig ein nicht konformes Verhalten vorliegt und ein Update angesagt ist.

BTW noch eine kurze Anmerkung zu dem MARCo-Empfänger mit zwei RailCom Eingängen und LocoNet. Ich bin sicher, dass auch dieser keine nicht vorhandenen RailCom Signale im Cutout an die Zentrale/Interface melden kann. Und wenn, dann müsste er noch einige Klippen erfolgreich umschiffen. Dazu sollte man sich vor Augen halten, dass das Bussystem LocoNet, welches von der Fa. Digitrax entwickelt/definiert wurde und lizensiert wird, keine Übertragung von RailCom Daten vorsieht.

Digitrax verwendet ein als Transponding bezeichnetes Verfahren, um Daten von Lok-Decodern zu erfassen und mittels entsprechenden Decodern auf dem LocoNet zu übertragen. Darauf wurde das LocoNet Protokoll abgestimmt. Uhlenbrock und andere, die ihrerseits nichts mit Transponding im Programm (am Hut) haben, verwenden (um nicht zu sagen missbrauchen) auf dem LocoNet die für die Transponding-Daten vorgesehen Befehle und nutzt diese, um RailCom Daten einzubetten.

Alleine die Übertragung der Lokadresse zusammen mit der Fahrtrichtung ist bei diesen schon trickreich gelöst. Von Seiten Digitrax steht der Befehl OPC_MULTI_SENSE zur Verfügung, der von Digitrax selbst und z.B. von Blücher Elektronik verwendet wird. Dieser leidet allerdings darunter, dass er zwar die Lokadresse übertragen kann, aber nicht ohne Trick auch noch die Fahrtrichtung.

Als Lösung haben sich findige Köpfe ausgedacht, einfach das Adressbit 12 als Fahrtrichtungsbit zu missbrauchen. Das führt allerdings dazu, dass man nur noch 12 Bit (0..11) zur freien Verfügung hat und nur noch Lokadressen aus dem Bereich 0..4095 verwenden kann.

Da das unschön ist, kam man auf die Idee anstatt das fehlende Bit der Lokadresse zu rauben, dies der Blockadresse zu entnehmen. Jetzt muss man aber beachten, dass selbige in diesem Fall auf 2048 beschränkt sind. Auch das ist nicht gerade ideal und so kam es zu dem neuen LocoNet Befehl OPC_MULTI_SENSE_L der die oben genannten Einschränkungen nicht mehr aufweist.

Es erklärt sich von selbst das speziell ältere Zentralen/Interface - womöglich aber auch die ein oder andere aktuelle Komponente - mit diesem neuen Befehl nichts anfangen kann und so rauschen die Daten am Bus einfach an ihnen vorbei. Damit aber auch diese nicht dumm bleiben hat sich der ein oder andere Hersteller von RailCom fähigen Rückmeldern gedacht, dann senden wir die Daten doch einfach in beiden Varianten. Damit wir damit aber nicht unnötig das eh nicht gerade performante LocoNet zumüllen machen wir das alles parametrierbar.

Blickt da noch einer durch? Ich nicht wirklich. Mich interessiert aber schon, welche der o.g. Übertragungsvarianten MARCo nutzt bzw. unterstützt? Und vor allem auch, wie sich das Verhalten hinsichtlich Reaktionsgeschwindigkeit und validierten Daten bei >50 RailCom Abschnitten darstellt? Ich habe da so meine Bedenken im Zusammenspiel LocoNet - RailCom. JM2C.

Fände es schön, wenn Andreas mit dem MARCo-Empfänger und einem Uhlenbrock Decoder, welcher nur für die Verwendung von Channel2 parametriert ist, auch einen entsprechenden Test macht und sein Ergebnis hier präsentiert. Eventuell kann er in diesem Kontext dann auch noch etwas zur Parametrierung des MARCo-Empfängers sagen.

Beste Grüße
Werner

Hallo Werner,

Zitat

---

die hier diskutierten Lokdecoder, die sich aber ganz offensichtlich nicht so recht konform zum RailCom Standard verhalten. Zumindest nicht der, der sich in meiner Piko Vossloh DB Cargo G6 befindet.

Laut der CV-Liste auf der Uhlenbrock Homepage ist für CV28 folgende Parametrierung möglich: Bit0 = 1 -> Kanal1 ein, Bit1 = 1 -> Kanal2 ein, Bit7 = 1 -> RailCom Plus® ein. Ich denke, dies gilt auch für meinen Decoder in der Piko-Lok, zumindest hinsichtlich Bit0 u. Bit1. Gibt der sich doch als ein Uhlenbrock zu erkennen. Leider verhält er sich nicht so, wie die aufgeführten Parameter dies erwarten lassen. Ich bin der Meinung, dass hier eindeutig ein nicht konformes Verhalten vorliegt und ein Update angesagt ist.

---

Du hast eine Piko Vossloh DB Cargo G6 mit ab Werk eingebautem Lokdecoder erworben, die sich nicht so verhält wie Du es erwartest?
Was hat Piko denn in der Bedienungsanleitung dazu verlauten lassen?
https://www.google.com/url?sa=t&rct=j&q=...86Y-NxUs023F_A-
https://www.h0-modelleisenbahn.de/files/modelle/1236_1_.pdf
Ich kann da nirgendwo lesen "Gehen Sie auf die Homepage von Uhlenbrock"? Ich lese da: "56464 PIKO SmartDecoder 4.1 Sound MTU"
Wie meldet sich der Decoder? Was steht z.B. in CV 8 des Lokdecodes Deiner Piko Vossloh DB Cargo G6?

Zitat

---

Ich bin der Meinung, dass hier eindeutig ein nicht konformes Verhalten vorliegt und ein Update angesagt ist.

---

Sehe ich auch so aber von Piko. Selbst wenn Piko die Decoder von Uhlenbrock fertigen ließ, wahrscheinlich hat Piko sie genauso bestellt.

MfG

vik

Guten Morgen vik,

ja es ist eine PIKO Vossloh DB Cargo G6 im Originalzustand (Artikelnr.: 52655, gerade noch mal die Verpackung hervorgeholt) mit einem PIKO Digital-Decoder mit Plux22 und der Artikelnr.: 56123.
BTW vielen Danke für die Links zur Bedienungsanleitung/Ersatzteilliste. Auf der PIKO Homepage kann ich diese Dokumente leider genau so wenig finden, wie ein Manual zum Decoder. Hier sehe ich noch deutliches Optimierungspotential.

In der Verpackung fand ich auch die entsprechenden Unterlagen zu dem Artikel vor. Auch dazu kann ich nach kurzer Durchsicht deine Ausführungen absolut bestätigen. An keiner Stelle fand ich einen Verweis in der Art "Gehen Sie auf die Homepage von Uhlenbrock". Bleibt die Frage, wie kam ich dazu dort nachzuschauen?

In der Anleitung zum Decoder #56123 sind unter Eigenschaften NMRA konform und RailCom aufgeführt. In der CV-Liste wird dann allerdings die CV28 nicht aufgeführt. Dies veranlasste mich den Herstellercode aus der CV8 auszulesen. Dieser lieferte den Wert 0x55 (=85, siehe auch meine Post #2). Exakt das veranlasste mich die Uhlenbrock Homepage aufzusuchen, um dort eventuell etwas über die CV28 in Erfahrung zu bringen. Hoffe, ich habe damit nichts falsch gemacht.

Auch wenn die Herstellerkennung auf Uhlenbrock verweist, ist mir absolut klar, dass ich mich mit allen Reklamationen an PIKO und nicht an Uhlenbrock wenden muss. Wahrscheinlich ist es so wie von dir angemerkt, PIKO hat auf der Suche nach Alleinstellungsmerkmalen explizit in das Lastenheft geschrieben, dass sich der Decoder nicht konform zu RailCom verhalten soll und diesen dann mit entsprechender Firmware bei Uhlenbrock geordert.

Allem Anschein nach hat PIKO in seinem Decoder Manual die Beschreibung von CV28 ganz bewusst weggelassen. Wenn man die für die Konfiguration von RailCom gemäß Standard/Norm vorgesehen CV28 nicht beschreibt, dann sollte PIKO jedoch RailCom auch nicht als Feature aufführen. Kann gut sein, dass das nicht konforme RailCom Verhalten nicht auf Uhlenbrock zurück zuführen ist und sie bei mir nur in den Verdacht kamen da der Decoder ihre Herstellerkennung trägt und nicht die von PIKO.

In Ermangelung eines „echten“ Uhlenbrock Decoders kann ich dessen RailCom Verhalten leider nicht testen. Wäre toll, wenn hierzu ein Anwender von Uhlenbrock Deccodern über seine Erfahrungen speziell hinsichtlich RailCom berichten würde.

Beste Grüße
Werner

Hallo zusammen,

ich habe gestern meinen Frust in eine sehr launigen Bemerkung 'Uhlenschrott' ihren Lauf gelasen. Dafür möcht ich mich bei der Fa. Uhlenbrock entschuldigen. Ich gehe davon aus, dass bei Uhlenbrock alle Mitarbeiter ihr Bestes geben. Obwohl ich sehr unzufreiden bin mit Artikeln von Uhlenbrock ist eine solche Bemerkung daher nicht angebracht.

Zum Thema Railcom Channel2 kann man sagen, dass dieser zusammen wie alle anderen Railcom Einstellungen in CV28 im Detail und in CV29 für die generelle Aktivierung genormt sind. Dies trifft nicht auf viele CVs zu, auf diese beiden jedoch schon. Daher kann man an dieser Stelle kaum einen Anwendungsfehler machen, wenn man CV28:Bit0=0 und CV28:Bit1=1 sowie CV29:Bit3=1 einstellt. Als Anwender erwarte ich, dass dann eine Adressmeldung erfolgt, wenn sich die Lok in einem entsprechenden Gleisabschnitt mit Railcom Detector befindet.

Die Anmerkungen zum Thema Railcom over Loconet kann ich leider nur bestätigen. Ich selber hatte bis vor kurzen die Railcom-Loconet Produkte von Digikeijs in Verwendung. Glücklich bin ich damit jedoch nie geworden, da die Adress-Meldung immer sehr wacklig waren. Bei 3-5 Loks klappte das einigermasen. Wenn man aber 10 oder mehr Loks auf die Gleise stellt, dann kann man es vergessen. Wenn man jedoch nur 3-5 Loks auf einer Anlage hat, dannn ist diese Anlage sehr wahrscheinlich relativ klein und Railcom braucht mann dann mMn auch nicht.

Hallo Stummis,

als erstes, ich bin kein Elektroniker sondern Maschinenbauer.
Vieles hier geschriebene ist mir schon zu hoch, aber interessant.

Im Uhlenbrock Decoder zB. Intellidrive2, kann ich über die genormten CVs 28 und 29 Railcom einschalten.

Bit0=Channel 1, Bit1=Channel 2, Bit7=Railcom Plus.

Channel 1 wird derzeit nur in der Intellibox verarbeitet (ohne Gewähr).

Zu den Marco Modulen:

Sie bestehen aus 2 Detektoren (Channel 1) und aus 2 Rückmeldern. Die Rückmelder sind hier uninteressant. So kann ich mit einem Marco die Richtung bestimmen. Von 1 nach 2, oder 2 nach 1. Die Bausteine beinhalten eine umfangreiche Steuerung mit reichlich LNCVs.

Jetzt habe ich hiermit die Möglichkeit:

-Züge mit der Adresse zu erkennen und zu melden, inkl Richtung,
-Pendelzugsteuerung,
-Geschwindigkeitsbeeinflussung,
-Lokabhängige Schattenbahnhofsteuerung,
usw. ,Siehe Handbuch,

Das Marco System ist mw. identisch mit der Lissy-Steuerung.

Ich habe 10 Marco, 2 Rückmelder je 16 Eingänge und 2 Universalsteuerungen, im Einsatz.
Fahre Motorola und DCC gemischt ohne Probleme.

Mit freundlichen Grüßen
Andreas

Hallo Werner,

Zitat

---

ja es ist eine PIKO Vossloh DB Cargo G6 im Originalzustand (Artikelnr.: 52655, gerade noch mal die Verpackung hervorgeholt) mit einem PIKO Digital-Decoder mit Plux22 und der Artikelnr.: 56123.
...
Bleibt die Frage, wie kam ich dazu dort nachzuschauen?

In der Anleitung zum Decoder #56123 sind unter Eigenschaften NMRA konform und RailCom aufgeführt. In der CV-Liste wird dann allerdings die CV28 nicht aufgeführt. Dies veranlasste mich den Herstellercode aus der CV8 auszulesen. Dieser lieferte den Wert 0x55 (=85, siehe auch meine Post #2). Exakt das veranlasste mich die Uhlenbrock Homepage aufzusuchen, um dort eventuell etwas über die CV28 in Erfahrung zu bringen. Hoffe, ich habe damit nichts falsch gemacht.

---

Zitat

---

ich besitze von Piko die Vossloh DB Cargo G6 #52654. Die meldet mir in CV8 den Herstellercode 85, welcher der Fa. Uhlenbrock GmbH zugeordnet ist.

---

Nein, hätte ich natürlich auch so gemacht und erwartet, dass da eine "162" drin steht.

Dass eröffnet auf jedenfall Raum für Nachfragen direkt bei Uhlenbrock.

Zitat

---

Allem Anschein nach hat PIKO in seinem Decoder Manual die Beschreibung von CV28 ganz bewusst weggelassen. Wenn man die für die Konfiguration von RailCom gemäß Standard/Norm vorgesehen CV28 nicht beschreibt, dann sollte PIKO jedoch RailCom auch nicht als Feature aufführen. Kann gut sein, dass das nicht konforme RailCom Verhalten nicht auf Uhlenbrock zurück zuführen ist und sie bei mir nur in den Verdacht kamen da der Decoder ihre Herstellerkennung trägt und nicht die von PIKO.

---

Würde mich wirklich interessieren, was Uhlenbrock zu den von ihnen "gezeichneten" Decodern sagt.

Zu der unklaren Situation bei der Implementierung von RailCom muss ich Dir natürlich recht geben, das ganze ist historisch in den letzten 15 Jahren entstanden und nicht immer haben alle am selben Strang gezogen.
An der Norm RCN-217 kann man das besonders gut sehen, die ist in den letzten Jahren inkonsistent überarbeitet worden. Zwischen ESU, Zimo und Kufer ist da mit dem inzwischen eher desinteressierten Segen von Lenz für Modellbahner kein wirklicher Fortschritt rausgekommen. Kein Wunder, dass die sich Modellbahner inzwischen reihenweise mit Zugverfolgung zufrieden geben und die wirkliche Zugerkennung aufgegeben haben. Ein Normungsgremium in dem die konkurrierenden Hersteller unter sich sind ist einfach kein Erfolgsmodell für die gesamte Communiy der Modellbahner. Eine zufriedenstellende Behebung des Channel 1 Designfehlers von Bernd Lenz scheint bis auf Weiteres nicht in Sicht.
Und so lange ist es z.B. Märklin auch nicht zu verdenken, das sie das Thema einfach weiterhin ignorieren.

MfG

vik

Der PIKO SmartProgrammer liest CVs unter POM auch mit deaktiviertem Kanal 1. War das jetzt die Frage? Firmware auf dem SmartDecoder 4.1 ist bei mir die 33.

Zitat

---

Der PIKO SmartProgrammer liest CVs unter POM auch mit deaktiviertem Kanal 1. War das jetzt die Frage? Firmware auf dem SmartDecoder 4.1 ist bei mir die 33.

---

Frage war m.E., ob Du bei diesem Decoder CV 28 lesen kannst und was da ggf. eingetragen ist.

MfG

vik

Hallo Stummis,

da ich zu den Menschen gehöre die einen Fehler zugeben können, habe ich den ursprünglichen Text entfernt.

Meine Aussagen beruhten auf Irrtum, ich hatte völlig übersehen, dass die Beteiligten hier über das entsprechende Equipment verfügen.
Meine Aussagen sind daher unangebracht und in diesem Umfeld natürlich dann Blödsinn.

Sorry Stummis, werde beim nächsten Mal genauer hinschauen.

Gruß Klaus

Hallo Klaus,

Zitat

---

Die Lok-Decoder Schellte ist somit unangebracht.

---

Es ging hier darum was für ein Decoder in der Piko-Lok ab Werk drin ist, wie die Decodereigenschaften in den dazugehörigen Unterlagen dokumentiert sind und was im Decoder selbst auslesbar ist, insbesondere auch über die Railcomfähigkeiten.

Das hat zunächst nichts mit der Zentrale zu tun, ist aber vielleicht interessant für die Frage in welchem Umfeld man die Lok einsetzen will. Mir scheint das sehr verwirrend zu sein und es stellte sich die Frage, ob der Fahrzeughersteller Piko ein Firmware-Update zur Verfügung gestellt hat.

MfG

vik

In der CV28 steht original Channel 1 und 2 aktiv beim 4.1 Decoder. Die kann man auch entsprechend der Norm verändern.

Hallo,

Zitat

---

In der CV28 steht original Channel 1 und 2 aktiv beim 4.1 Decoder. Die kann man auch entsprechend der Norm verändern.

---

Vielen Dank!

Zitat

---

Der PIKO SmartProgrammer liest CVs unter POM auch mit deaktiviertem Kanal 1. War das jetzt die Frage? Firmware auf dem SmartDecoder 4.1 ist bei mir die 33.

---

Das steht in CV 7?
Was liest der Smartprogrammer unter CV 8 und CV 7?

Kann man mit dem Smartprogrammer die lesbaren CVs des Piko SmartDecoder 4.1 in eine Liste ausdrucken?

MfG

vik

SmartDecoder 4.1:
CV7=33
CV8=162
CV28=131 (default)

Wenn ich CV28 auf 130 setze (oder Bit 0=0 ist) verschwindet Kanal 1 nachdem der Decoder stromlos und wieder eingeschaltet wurde.
Ebenso kann Kanal 2 mit Bit 1 ein- und ausgeschaltet werden. Der Decoder macht also, was er soll.

Zitat

---

SmartDecoder 4.1:
CV7=33
CV8=162
CV28=131 (default)

---

demnach handelt es sich um einen anderen Decoder als in #11 dieses Threads beschrieben.
Soweit ich weiß sollte sich die Herstellerkennung in CV 8 auch durch ein Firmwareupdate nicht ändern lassen. Der in #11 beschriebene Decoder hatte in CV 8 die Kennung 55, Deiner die Kennung 162.

Zitat

---

Wenn ich CV28 auf 130 setze (oder Bit 0=0 ist) verschwindet Kanal 1 nachdem der Decoder stromlos und wieder eingeschaltet wurde.
Ebenso kann Kanal 2 mit Bit 1 ein- und ausgeschaltet werden. Der Decoder macht also, was er soll.

---

Wo kann man die Beschreibung des des Herstellers "162" (Piko) finden, was sein SmartDecoder 4.1 oder 4.2 mit der Firmware Stand 33 alles machen kann. Ich habe bisher leider nur einen Auszug der CV-Liste
https://www.manualslib.de/manual/633243/...und-Plux22.html
und
https://www.google.com/url?q=https://www...dgxTVjyXW3R9qkX

gefunden. Hättest Du da einen Link von Piko für mich?

MfG

vik

Firmware für PIKO SmartDecoder 4.1 ist mittlerweile 35. Die SmartProgrammer-App gibt eine ganze Menge CVs in den Einstellungen an, die mit den Reglern verändert werden können. Eine Druckfunktion gibt es leider nicht. Links zu kompletten CV-Listen sind mir nicht bekannt.

Hallo Stummis,

ursprünglichen Text entfernt, beruhte auf Irrtum und war daher unangemessen.

Sorry Stummis, werde beim nächsten Mal genauer hinschauen.

Gruß Klaus

Zitat

---

Zitat

---

Andre schrieb:
Bei beiden Decodern funktioniert die Railcom Adressrückmeldung nicht, wenn ich den Railcom Channel1 (CV28, Bit0=0) ausschalte und nur mit Channel2 (CV28, Bit1=1) fahre. Das ist sehr unschön, da ich Channel1 eigentlich nirgendwo mehr nutzen möchte wegen der Datenflut.

---

Das ist doch alles Blödsinn.

---

Mich interessiert, ob ich eine Lok mit diesem Decoder in meiner vorhandenen Umgebung problemlos einsetzen kann.
Da erwarte ich eine hilfreiche Information des Lokherstellers, bei dem ich die Lok kaufe.
Wenn ich dazu eine andere Zentrale oder auch nur einen Lokhersteller spezifisches Programmierwerkzeug benötige, ist das ganze für mich uninteressant.

Insgesamt erinnert mich dIe Kommunikation von Piko zum SmartDecoder 4.1 schon irgendwie an die Piko-C4-Story.
Wie Dampfstoß schreibt:

[quote=Dampfstoß]
Firmware für PIKO SmartDecoder 4.1 ist mittlerweile 35. Die SmartProgrammer-App gibt eine ganze Menge CVs in den Einstellungen an, die mit den Reglern verändert werden können. Eine Druckfunktion gibt es leider nicht. Links zu kompletten CV-Listen sind mir nicht bekannt.
Die einzige real existierende Ordnung ist das Chaos.
[/quote]

MfG

vik