ich bin gerade dabei meine Moba-Anlage zu automatisieren und wüßte gerne, ob
DCC oder auch MM-Decoder während dem Betrieb ACK-Signale aussenden, nachdem
sie einen für Sie bestimmten Befehl ausgeführt haben. Beim Programmieren
tuen dies die DCC-Decoder ja sowieso. Wenn dies auch im Betrieb der Fall
ist, kann mir jemand sagen:
* welche Decoder unterstützen dieses Feature ?
* werden die ACK-Signale immer ausgesendet (also als allgemeines ACK für das
Empfangen eines Befehls oder nur, wenn das ein Befehl ist, der auf die
Adresse passt) ?
* wie genau sehen die ACK-Signale als DCC-Paket aus ? Was für Daten werden
alles mitgesendet ?
Vielen Dank schonmal im Vorraus.
Gruß,
Nils
> ich bin gerade dabei meine Moba-Anlage zu automatisieren und wüßte gerne,
> ob DCC oder auch MM-Decoder während dem Betrieb ACK-Signale aussenden,
> nachdem sie einen für Sie bestimmten Befehl ausgeführt haben.
Nein, nicht wirklich.
Ja, sie führen den Befehl aus und die Wirkung ist das ACK.
> Beim
> Programmieren tuen dies die DCC-Decoder ja sowieso. Wenn dies auch im
> Betrieb der Fall ist, kann mir jemand sagen:
>
> * welche Decoder unterstützen dieses Feature ?
Keiner.
> * werden die ACK-Signale immer ausgesendet (also als allgemeines ACK für
> das Empfangen eines Befehls oder nur, wenn das ein Befehl ist, der auf die
> Adresse passt) ?
> * wie genau sehen die ACK-Signale als DCC-Paket aus ? Was für Daten werden
> alles mitgesendet ?
Es gibt kein DCC-Paket dafür. Das ACK-Signal beim Programmieren besteht aus
einer erhöhten Stromaufnahme für eine kurze Zeit. Dazu wird der Motor und
oder das Licht eingeschaltet.
Es gibt Entwicklungen, die Kommunikation auch bidirektional zu gestalten.
Dies ist mangels fertiger Normen bisher nur bei wenigen Herstellern
(Umelec, Digitrax, Lenz) und auch nicht immer untereinander kompatibel
eingeführt.
Über MM kann ich nicht so viel sagen, aber das ist so einfach gestaltet,
dass ich mir da keine Rückmeldung irgendwelcher Art vorstellen kann. Es
wird auch nichts mehr kommen, weil neuere Entwicklungen stattdessen bei mfx
stattfinden.
--
Viele Grüße,
Jens Schmidt
>> * welche Decoder unterstützen dieses Feature ?
> Keiner.
Es gibt manche Decoder, die antworten auf PoM mit einer Art ACK, d.h. die
Lichter blinken auf und die Lok macht u.U. einen Ruck. Ich vermute aber es
handelt sich dabei um ein programmiertechnisches Relikt und ist nicht so
gewollt. IMHO sollte es jedenfalls nicht so sein.
> (Umelec, Digitrax, Lenz) und auch nicht immer untereinander kompatibel
> eingeführt.
Zimo nicht zu vergessen. Die Zugnummernerkennung nach System Zimo
funktioniert
soweit ich weiß so, dass auf einen Fahrbefehl mit der jeweiligen Adress mit
einem kontrollierten, erhöhten Stromfluß (Mikrokurzschluss) geantwortet
wird.
--
SchöNe Grüße aus WieN,
Peter Wagner. Spur N, DCC.
Technischer Referent des Modelleisenbahnclub "Die 160er"
naja ich wollte soetwas wie ein abgespecktes Bidir, da es ja wahrscheinlich
noch Jahre dauern wird, bis die sich einigen und dann wird die HW wieder
teuer sein. Wenn es so ein "dummes" ACK geben würde, dann könnte man die
Anlage in Blocks unterteilen und zu jedem Block eine Versorgung inkl.
Sniffer legen, der würde sich jeden befehl merken und wenn es dann ein ACK
vom Gleisabschnitt gibt, wüßte man, dass da die Lok drinn steht / fährt.
Diese Info könnte man dann eventuell per XFER-Befehl vom Loconet senden oder
eben ein anderes Transferverfahren zum PC nehmen .....
Gruß,
Nils
> ich bin gerade dabei meine Moba-Anlage zu automatisieren und wüßte
> gerne, ob DCC oder auch MM-Decoder während dem Betrieb ACK-Signale
> aussenden, nachdem sie einen für Sie bestimmten Befehl ausgeführt
> haben. Beim Programmieren tuen dies die DCC-Decoder ja sowieso.
> Wenn dies auch im Betrieb der Fall ist, kann mir jemand sagen:
>
> * welche Decoder unterstützen dieses Feature ?
Mir ist das nur von Zimo und Tran bekannt, diese Funktion nennt sich
Zimo Zugnummernimpulse.
> * werden die ACK-Signale immer ausgesendet (also als allgemeines
> ACK für das Empfangen eines Befehls oder nur, wenn das ein Befehl
> ist, der auf die Adresse passt) ?
Nur wenn die Adresse passt, erhöhen diese Decoder die Stromaufnahme,
indem die Motorendstufe kurz durchgeschaltet wird.
> * wie genau sehen die ACK-Signale als DCC-Paket aus ? Was für Daten
> werden alles mitgesendet ?
Es ist nur ein Impuls mit erhöhter Stromaufnahme, bei 2 Loks mit
Tran DCX73 kann ich diese bei hoher Gleisspannung als leises Ticken
hören.
Bei Zimo gibt es dazu passene Auswerteschaltungen, die so die in
diesem Gleisabschnitt befindlichen Lokadressen ausgeben können.
Matthias
--
Achtung: Dieses Posting kann Ironie und Sarkasmus enthalten!
> ich bin gerade dabei meine Moba-Anlage zu automatisieren und wüßte gerne, ob
> DCC oder auch MM-Decoder während dem Betrieb ACK-Signale aussenden, nachdem
> sie einen für Sie bestimmten Befehl ausgeführt haben. Beim Programmieren
> tuen dies die DCC-Decoder ja sowieso. Wenn dies auch im Betrieb der Fall
> ist, kann mir jemand sagen:
>
> * welche Decoder unterstützen dieses Feature ?
Im MM Bereich ist mir diesbezüglich gar nichts bekannt, bin aber da
nicht wirklich gut im Bilde was es an Produkten gibt. Ev. kann mich da
jemand korrigieren. mfx hat die Möglichkeit nur das ist derzeit alles
properitär Märklin.
ZIMO, cT Elektronik (Tran) quittieren den Empfang von Paketen an ihre
Adresse mit einem kurzen Hochstromimpuls. Der ist etwa 1-2A stark und
kann von Gleisabschnittmodul gelesen weden. Zur Anlagenautomatisierung
ist das sehr hilfreich, nur eben derzeit an das ZIMO System gebunden.
Das Gute daran die Technik ist public domain. Aufwand im Decoder keiner
man braucht nur entsprechende SW die das tut.
Weiters hat Digitrax ein Transpondersystem. Da die aber offensichtlich
sehr allergisch auf Geld sind und keinerlei Lizenzen vergeben ist es
wohl uninterresant.
Als dritte Möglichkeit bietet sich BiDi an. Ich erwarte hier nachdem die
Technik grundsätzlich genormt wurde anlässlich der Messe weitere
Produkte und Lösungen. Derzeit gibt es defacto nichts ausgereiftes,
daher unbedingt, falls das auf Interesse stößt, einen Decodervedor
wählen der Decoder updates kann. Es ist sicher dass die Firmware in den
jetzigen Decodern die schon BiDi HW drauf haben, sicher nicht ausreichen
wird um die Neuerungen zu beherrschen.
> * werden die ACK-Signale immer ausgesendet (also als allgemeines ACK für das
> Empfangen eines Befehls oder nur, wenn das ein Befehl ist, der auf die
> Adresse passt) ?
ZIMO Zugnummern quittieren den Empfang eines DCC Pakets
BiDi gibt es: Aussenden eines Broadcast Signals, zB eigene Adresse, oder
gezielt Antwort auf eine zuvor über DCC übertragene Frage. Letzteres
könnte zum Beispiel den Inhalt einer CV übertragen, oder den Zugtyp angeben.
> * wie genau sehen die ACK-Signale als DCC-Paket aus ? Was für Daten werden
> alles mitgesendet ?
ZIMO Zugnummer ein Stromimpuls mit etwa 1-2A wenige µS lang, am Anfang
der Präambelbits gesendet wird. Stört damit keine Datenübertragung. Sehr
betriebssicher und leicht zu detektieren, auch über lange Leitungen.
Nutzbar derzeit nur über MX9 von ZIMO. Tran überlegt auch etwas
anzubieten... aber nichts genaues weiß man nicht net ;-)
BiDi ist eine Stromschleife mit ein paar mA. Energie kommt aus dem
Pufferkondensator am Decoder. Die daten werden in den ersten
Präambelbits gesendet. Dazu wird der Booster abgetrennt, und die Schiene
kurzgeschlossen. So kann der Decoder Daten senden. Voraussetzung keine
parasitären Verbraucher paralell zum Decoder. Also alle Künstler die
Lämpchen direkt ans Gleis anschließen haben sich gegen BiDi entschieden.
Abhilfe: Lämpchen über einen Gleichrichter anschließen.
HTH
--
|[#]| . \=/ Arnold Hübsch
|[_]|--/^\--H<| http://www.huebsch.at/train
|_ _________ \ http://amw.huebsch.at
_o (x)-(x)-/oo\\___ http://www.waschzettel.at
> ZIMO, cT Elektronik (Tran) quittieren den Empfang von Paketen an ihre
> Adresse mit einem kurzen Hochstromimpuls. Der ist etwa 1-2A stark und kann
> von Gleisabschnittmodul gelesen weden. Zur Anlagenautomatisierung ist das
> sehr hilfreich, nur eben derzeit an das ZIMO System gebunden. Das Gute
> daran die Technik ist public domain. Aufwand im Decoder keiner man braucht
> nur entsprechende SW die das tut.
Ca. 90 % meiner Decoder (Loks) sind Zimo oder CT, aber mein Digitalsystem
ist nicht Zimo: IB als Steuereinheit und Lenz LV 102 als Booster. Wie genau
funktioniert das bei Zimo / CT ? Senden die nur Quittierung, wenn es deren
Paket ist oder immer ?
Sag mal weißt du zufällig ob CT auch ABC mal implementieren wird, wie dies
jetzt bei Zimo der Fall ist ?
> Weiters hat Digitrax ein Transpondersystem. Da die aber offensichtlich
> sehr allergisch auf Geld sind und keinerlei Lizenzen vergeben ist es wohl
> uninterresant.
vollkommen uninterresant. Wenn ich ne Punktidientifikation haben will nehme
ich was Lissy-ähnliches .... dazu gibt es einige Freewareversionen, die man
noch etwas erweitern müsste ....
> Als dritte Möglichkeit bietet sich BiDi an. Ich erwarte hier nachdem die
> Technik grundsätzlich genormt wurde anlässlich der Messe weitere Produkte
> und Lösungen. Derzeit gibt es defacto nichts ausgereiftes, daher
> unbedingt, falls das auf Interesse stößt, einen Decodervedor wählen der
> Decoder updates kann. Es ist sicher dass die Firmware in den jetzigen
> Decodern die schon BiDi HW drauf haben, sicher nicht ausreichen wird um
> die Neuerungen zu beherrschen.
Naja ich bin da wie gesagt, etwas skeptisch .... Mit dem wir bringen
demnächst was auf den Markt .....
Gruß,
Nils
> Ca. 90 % meiner Decoder (Loks) sind Zimo oder CT, aber mein Digitalsystem
> ist nicht Zimo: IB als Steuereinheit und Lenz LV 102 als Booster. Wie genau
> funktioniert das bei Zimo / CT ? Senden die nur Quittierung, wenn es deren
> Paket ist oder immer ?
Die Decoder quittieren nur nach Empfang eines Paketes an ihre Adresse.
Das tun sie aber nur wenn nach den Daten Bytes und *vor* den Präambelbis
eine "0" auftaucht. Diese wird AFAIK nur von den ZIMO Zentralen
ausgesendet. Diese "0" ist nicht wirklich nötig, ist aber aus
historischen Gründen da und die Decoder schauen derzeit darauf.
> Sag mal weißt du zufällig ob CT auch ABC mal implementieren wird, wie dies
> jetzt bei Zimo der Fall ist ?
Da Lenz die ABC Sache durch seine Patentanmeldung flach gemacht hat,
unterstützt Tran das nicht. Es kann aber Asymmetrisches DCC nach UMELEC
zum Anhalten.
> Naja ich bin da wie gesagt, etwas skeptisch .... Mit dem wir bringen
> demnächst was auf den Markt .....
Ja daher derzeit Produkte wählen die eine Updatemöglichkeit haben.
obwohl das auch keine Sicherheit garantiert.
>> Ca. 90 % meiner Decoder (Loks) sind Zimo oder CT, aber mein Digitalsystem
>> ist nicht Zimo: IB als Steuereinheit und Lenz LV 102 als Booster. Wie
>> genau funktioniert das bei Zimo / CT ? Senden die nur Quittierung, wenn
>> es deren Paket ist oder immer ?
>
> Die Decoder quittieren nur nach Empfang eines Paketes an ihre Adresse. Das
> tun sie aber nur wenn nach den Daten Bytes und *vor* den Präambelbis eine
> "0" auftaucht. Diese wird AFAIK nur von den ZIMO Zentralen ausgesendet.
> Diese "0" ist nicht wirklich nötig, ist aber aus historischen Gründen da
> und die Decoder schauen derzeit darauf.
D.h. ohne Zimo-Zentrale kann ich das nicht ohne weiteres benutzen ?
>> Sag mal weißt du zufällig ob CT auch ABC mal implementieren wird, wie
>> dies jetzt bei Zimo der Fall ist ?
>
> Da Lenz die ABC Sache durch seine Patentanmeldung flach gemacht hat,
> unterstützt Tran das nicht. Es kann aber Asymmetrisches DCC nach UMELEC
> zum Anhalten.
Naja ist ja fast das gleiche, aber ich finde nirgendswo eine Anmerkung bei
Tran auf der Homepage. Wo steht dass das die Decoder das unterstützen oder
können die das nur nach einem update und da Herr Tran ja keine Releasenotes
auf seiner Seite hat und auch in Sachen Dokumentation etwas schwach
aufgestellt ist, dies nur nicht da steht ?
Können die Trans auch konstanten Bremsweg ?
>> Naja ich bin da wie gesagt, etwas skeptisch .... Mit dem wir bringen
>> demnächst was auf den Markt .....
>
> Ja daher derzeit Produkte wählen die eine Updatemöglichkeit haben. obwohl
> das auch keine Sicherheit garantiert.
Sollten alle meine Decoder sein, bis auf den Kuehn, aber der dürfte eh bald
fliegen .... Werde mich wahrscheinlich auf Zimo und eventuell noch Tran
festlegen ..... Monokulturen sind zwar nicht immer so sonderlich gut, aber
was bleibt einem übrig, außer vielleicht selbst Decoder zu bauen ;-)
Gruß,
Nils
Was kennst Du da, gibts dazu was im Netz?
--
lg aus Wien
Christoph
ja das Orginal ist von einem Schweden. Ich würde es aber auf Atmel
umschreiben und eventuell ans Loconet hängen. Das Problem ist aber, dass das
wie gesagt Punktkontakte sind, d.h. für den Betrieb wäre es gut, aber wenn
man die Anlage einschaltet, müsste der Zug zuerst über so eine Stelle fahren
oder die Steuerungssoftware müsste reinitialisiert werden ....
Hier die URL:
http://home.swipnet.se/perz/ir.html
Gruß,
Nils
"Christoph Wuczkowski" <wu...@gmx.at> schrieb im Newsbeitrag
news:d3654$45aa3a9b$557cefc5$12...@news.inode.at...
Hallo Nils!
Ich habe mir überlegt, ob man die Codierung nicht auf ein Etikett unter
eine Lok klebt, auf der die Loknummer dann ausgelesen wird.
z.b. 2 Zeilen nebeneinander, wobei eine Zeile den "Takt" enthält und die
andere den Code. Damit müsste man nicht einmal die Lok öffnen? Für dem
Leser könnte man zwei Reflexlichtschranken verwenden.
> > Ca. 90 % meiner Decoder (Loks) sind Zimo oder CT, aber mein
> > Digitalsystem ist nicht Zimo: IB als Steuereinheit und Lenz LV
> > 102 als Booster. Wie genau funktioniert das bei Zimo / CT ?
> > Senden die nur Quittierung, wenn es deren Paket ist oder immer ?
>
> Die Decoder quittieren nur nach Empfang eines Paketes an ihre
> Adresse. Das tun sie aber nur wenn nach den Daten Bytes und *vor*
> den Präambelbis eine "0" auftaucht. Diese wird AFAIK nur von den
> ZIMO Zentralen ausgesendet. Diese "0" ist nicht wirklich nötig, ist
> aber aus historischen Gründen da und die Decoder schauen derzeit
> darauf.
Meine Tran-Decoder haben an der Daisy immer die Quittung gesendet.
> D.h. ohne Zimo-Zentrale kann ich das nicht ohne weiteres benutzen ?
AFAIK ist das derzeit so weil keine andere Zentrale die "0" erzeugt.
Weiters können nur die Oberklasse Zentralen die SW verändern um sowas
ev. nachzubessern.
Die Quittierungsimpulse könnten, obwohl sehr kurz, das Lesen der
Präambelbits stören. An sich sollte es sich ausgehen weil 14 gesendet
werden sollen der Decoder aber bei 12 aufsynchronisieren soll. Es gibt
aber immer wieder Dumme die Zentralen mit nur 12 Präambelbits am Markt
bringen - wohl klingende Namen dabei! Das verstößt klar gegen die DCC
Specs! Daher quitieren die ZIMO und Tran Decoder in solchen Fällen nicht
im Lesefehler, auch von Nachbardecoern, zu vermeiden. Es ist ja nicht
definiert wo das Bit abgetastet werden soll. Daher sollten mehr
Präambelbits da sein als man braucht um sicherzustellen, dass der
Decoder wieder aufsynchronisieren kann.
ZIMO sendet noch mehr Präamelbits um da das HLU hinein zu codieren, aber
das ist eine ganz andere Sache. Es gibt aber ein Proposal das ohne
weiteren Präambelbits auskommt und schneller überträgt.
>>> Sag mal weißt du zufällig ob CT auch ABC mal implementieren wird, wie
>>> dies jetzt bei Zimo der Fall ist ?
>> Da Lenz die ABC Sache durch seine Patentanmeldung flach gemacht hat,
>> unterstützt Tran das nicht. Es kann aber Asymmetrisches DCC nach UMELEC
>> zum Anhalten.
>
> Naja ist ja fast das gleiche,
Ja aber frag' einen Juristen die verdienen mit dem vermeintlichen
Unterschied viel Geld! :-)
> aber ich finde nirgendswo eine Anmerkung bei Tran auf der Homepage.
> Wo steht dass das die Decoder das unterstützen oder können die das
> nur nach einem update und da Herr Tran ja keine Releasenotes auf
> seiner Seite hat und auch in Sachen Dokumentation etwas schwach
> aufgestellt ist, dies nur nicht da steht ?
Ich find's auch grad' nicht. Es muss in der CV49 oder so wo drinnen
sein. Jedenfalls kann er anhalten...
> Können die Trans auch konstanten Bremsweg ?
NOPE!
Ich persönlich halte nichts davon, weil damit die Sache unnötig komplex
wird. Wenn man mit solchen Decodern rangieren will ist es manchmal recht
komisch. OK dafür gibt es die Rangiertaste - aber genau das is es was
ich mit komplex meine. Für einfach Anhaltemanöver im reinen
Automatikbetrieb aber durchaus eine Alternative.
Ich bevorzuge vorzubremsen, soweit möglich in mehreren Stufen, sodass
man sich mit sehr geringer Geschwindigkeit dem Signal nähert. Der
Halteweg ist dann sehr kurz und ermöglicht eine hohe Haltegenauigkeit.
Christoph Wuczkowski schrieb:
>> Hier die URL:
>> http://home.swipnet.se/perz/ir.html
Das kann man fertig kaufen, heißt dann LISSY. Der Vorteil: Die
Signalerzeugung in der Lok übernehmen die (passenden) Dekoder.
Der Nachteil: teure Empfänger.
> Ich habe mir überlegt, ob man die Codierung nicht auf ein Etikett unter
> eine Lok klebt, auf der die Loknummer dann ausgelesen wird.
Das gibt es hier:
http://www.holtermann-modellbahntechnik.de/
Ich fürchte außer den zwei Lichtschranken brauchst Du ein gerüttelt Maß
Elektronik und Erfahrung, damit das tut.
Grüße
Werner
--
MODELLEISENBAHN FÜR KINDER ==> http://www.kinderbahn.de
THEMA SCHMALSPURBAHN ==> http://www.thema-schmalspurbahn.de
mailto:wf.usenet...@werner-falkenbach.de (das kommt schon an)
Genausoviel Elektronik wie bei dem Infrarot-Teil, nur dass hier halt die
Sender wegfallen. Ausserdem sollte die Rückmeldung halt nicht nur auf
einem Display angezeigt werden sondern in eines der üblichen Programme
zurückgemeldet werden können (bevorzugt in ein Open-Source Projekt)
Nils Brönner schrieb:
> Hallo Arnold,
>> Weiters hat Digitrax ein Transpondersystem. Da die aber
>> offensichtlich sehr allergisch auf Geld sind und keinerlei
>> Lizenzen vergeben ist es wohl uninterresant.
Sie glauben mehr Geld zu verdienen, wenn sie alles selbst
verkaufen.
> vollkommen uninterresant. Wenn ich ne Punktidientifikation
> haben will nehme ich was Lissy-ähnliches
Und da zeigt sich wieder, dass Digitrax mit dem Begriff
"Transponding" alle Leute verwirrt. Denn es hat nichts mit den
Transpondern wie bei RFID oder dem System von Helmo zu tun. Es
geht wie bei BiDi oder den Zimo-Zugnummern Pulse über das
Gleis, d.h es wird ein beliebig langer Abschnitt überwacht.
Dabei wird aber nicht nur ein kurzer Puls erzeugt, sondern eine
"Signatur" gesendet, d.h. eine Bestimmte Abfolge von Pulsen
innerhalb eines Präambelbits. Das Problem dabei ist aber, dass
Decoder mit hochfrequenter Motoransteuerung sehr ähnliche
"Signaturen" produzieren. Daher funktioniert das nicht richtig,
wenn Decoder mit Hochfrequenter PWM im Einsatz sind.
Gruß,
Reinhard
> parasitären Verbraucher paralell zum Decoder. Also alle Künstler die
> Lämpchen direkt ans Gleis anschließen haben sich gegen BiDi entschieden.
Also alle von den grossen Modellbahnherstellern angebotenen
Wagen-Innenbeleuchtungen funktionieren nicht mit Bidi?
Hey, jetzt kriege ich aber auch schon langsam die Krise.
Wer denkt da eigentlich überhaupt mit in der Branche?
Schaut Euch doch die Produkte an, z.B.:
- MTX Doppelstockwagen in N mit fest eingebauter Innenbeleuchtung
- GFN Desiro Neukonstruktion in N: Innenbeleuchtung selbst bei der
Digitalversion
nicht digital schaltbar, Birnen hängen parallel Gleis!
- diverse Steuerwagen mit Schleppschalter, Lampen nicht ausschaltbar
aber:
- keine gernomte Decoder-Schnittstelle mit Zusatzfunktionen
- keine genormte Schnittstelle für Funktionsdecoder
Ich finde es wird langsam ein Graus.
> AFAIK ist das derzeit so weil keine andere Zentrale die "0" erzeugt.
> Weiters können nur die Oberklasse Zentralen die SW verändern um sowas ev.
> nachzubessern.
> Die Quittierungsimpulse könnten, obwohl sehr kurz, das Lesen der
> Präambelbits stören. An sich sollte es sich ausgehen weil 14 gesendet
> werden sollen der Decoder aber bei 12 aufsynchronisieren soll. Es gibt
> aber immer wieder Dumme die Zentralen mit nur 12 Präambelbits am Markt
> bringen - wohl klingende Namen dabei! Das verstößt klar gegen die DCC
> Specs! Daher quitieren die ZIMO und Tran Decoder in solchen Fällen nicht
> im Lesefehler, auch von Nachbardecoern, zu vermeiden. Es ist ja nicht
> definiert wo das Bit abgetastet werden soll. Daher sollten mehr
> Präambelbits da sein als man braucht um sicherzustellen, dass der Decoder
> wieder aufsynchronisieren kann.
>
> ZIMO sendet noch mehr Präamelbits um da das HLU hinein zu codieren, aber
> das ist eine ganz andere Sache. Es gibt aber ein Proposal das ohne
> weiteren Präambelbits auskommt und schneller überträgt.
Ich habe wie gesagt die IB, weißt du zufälligerweise wieviele Präambelbits
die aussendet ?
>
>>>> Sag mal weißt du zufällig ob CT auch ABC mal implementieren wird, wie
>>>> dies jetzt bei Zimo der Fall ist ?
>>> Da Lenz die ABC Sache durch seine Patentanmeldung flach gemacht hat,
>>> unterstützt Tran das nicht. Es kann aber Asymmetrisches DCC nach UMELEC
>>> zum Anhalten.
>>
>> Naja ist ja fast das gleiche,
>
> Ja aber frag' einen Juristen die verdienen mit dem vermeintlichen
> Unterschied viel Geld! :-)
Weiß ich, ist aber das gleiche Prinzip ;-)
>
>> aber ich finde nirgendswo eine Anmerkung bei Tran auf der Homepage. Wo
>> steht dass das die Decoder das unterstützen oder können die das
>> nur nach einem update und da Herr Tran ja keine Releasenotes auf
>> seiner Seite hat und auch in Sachen Dokumentation etwas schwach
>> aufgestellt ist, dies nur nicht da steht ?
>
> Ich find's auch grad' nicht. Es muss in der CV49 oder so wo drinnen sein.
> Jedenfalls kann er anhalten...
Kannst du bitte nochmal nachsehen, habe mal die Anleitung vom SL-51-2 und
vom DCX51 runtergeladen, beim DCX ist zum CV 49 gar nix beschrieben und beim
SL-51-2 regelt man damit den Sound. Weißt du zufällig auch, ob die Decoder
das Bremsen nach Assymetrie von Haus aus beherrschen, oder ob sie ein Update
(wie bei Zimo) brauchen ?
>
>> Können die Trans auch konstanten Bremsweg ?
>
> NOPE!
> Ich persönlich halte nichts davon, weil damit die Sache unnötig komplex
> wird. Wenn man mit solchen Decodern rangieren will ist es manchmal recht
> komisch. OK dafür gibt es die Rangiertaste - aber genau das is es was ich
> mit komplex meine. Für einfach Anhaltemanöver im reinen Automatikbetrieb
> aber durchaus eine Alternative.
> Ich bevorzuge vorzubremsen, soweit möglich in mehreren Stufen, sodass man
> sich mit sehr geringer Geschwindigkeit dem Signal nähert. Der Halteweg ist
> dann sehr kurz und ermöglicht eine hohe Haltegenauigkeit.
Ja genau das brauche ich denn ich habe nur eine kleine H0-Anlage mit 2,4 x
2,4 m und 20 m Gleis. Bei diesen Maßen versteht man glaub ich, dass ich das
Feature brauchen könnte .....
Gruß,
Nils
Ich will auch, dass die Infos dann über irgendwein weg an meine
Open-Source-SW kommen. Da ich die IB nutze inkl. Rückmeldung via Loconet
(Locoio mit Stromfühler) würde ich zur Weiterführung das Loconet benutzen.
Für die Atmel-ICs gibt es ein Open-Source-Projekt, welches das Loconet
implementiert hat (embedded-Loconet), dieses in c geschrieben Programm
müsste man dann noch um die Routine erweitern für das Auslesen der Codes.
Danach würde ich XFER-Befehle nutzen um das ganze zum Locobuffer zu
bekommen. Dort würde ich dann noch meine Software anpassen, dass sie das
Zeug versteht und fertig.
Das löst aber nicht mein letztes Problem für eine möglichst einfach zu
bedienende und sichere Automatiklösung: Was passiert wenn ich die Anlage aus
mache, nehm ne Lok runter, gleise sie woanders wieder auf und schalte die IB
wieder an ...... Was nun ? Entweder ich muss der Software sagen, hey Lok XYZ
steht nicht mehr da sondern dort oder die Lok muss solange fahren bis sie
wieder ein Kontakt (IR) erreicht.
Das wird aber wiederum schwierig bei meiner recht kompakten H0-Anlage (2,4 x
2,4m / 20 m Gleis). Daher würde ich hierbei eine 3+1 Lösung nutzen, die
vielleicht machen als übertrieben erscheint, aber für mich und auch vorallem
für größere Anlagen mehr sicherheit bringt:
* Stromfühler => Rückmeldung Gleis besetzt / frei
* Lissy eigenbau => Woher kommt die Lok, Erkennung im Betrieb
* Railcom eigenbau / Quitierung => Aha Lok steht beim Einschalten in
Abschintt XYZ
* Als zusatzsicherheit sollten die Decoder noch ABC und konstanten Bremsweg
haben, dann kann man Blocks aufbauen, hat keine Kurzen oder
unkontrollierbare Loks etc .....
Damit hätte man zumindest aus sicht der Loks eine Automatisierung möglichst
abgesichert.
Gruß,
Nils
Na das ist doch wenigsten mal ein Ansatz, aber wieder mal wie so einiges bei
Digitrax (zumindest in meinen Augen) schlecht ausgeführt. Ich bin
Programmierer und sehr skeptisch wenn eine Software alles mögliche
überwachen und steuern soll und dann auch noch HW-Ausfälle vorbeugen .....
da gehe ich lieber den Weg, dass die HW so viel wie möglich kann, ohne die
Software allerdings zu bevormunden, z.B. eine Art Lissy, aber ohne Schalten,
das sollte der PC tun .....
Gruß,
Nils
P.S.: bitte ohne ie ;-)
"Peter Wagner" <ps...@hotmail.com> schrieb im Newsbeitrag
news:56bfb$45aa7c5f$3eb29112$4...@news.chello.at...
> "Arnold Huebsch" <Arn...@Huebsch.at> schrieb im Newsbeitrag
> news:50ujmcF...@mid.individual.net...
>
>> parasitären Verbraucher paralell zum Decoder. Also alle Künstler die
>> Lämpchen direkt ans Gleis anschließen haben sich gegen BiDi entschieden.
>
> Also alle von den grossen Modellbahnherstellern angebotenen
> Wagen-Innenbeleuchtungen funktionieren nicht mit Bidi?
>
> Hey, jetzt kriege ich aber auch schon langsam die Krise.
> Wer denkt da eigentlich überhaupt mit in der Branche?
>
> Schaut Euch doch die Produkte an, z.B.:
>
> - MTX Doppelstockwagen in N mit fest eingebauter Innenbeleuchtung
> - GFN Desiro Neukonstruktion in N: Innenbeleuchtung selbst bei der
> Digitalversion
> nicht digital schaltbar, Birnen hängen parallel Gleis!
> - diverse Steuerwagen mit Schleppschalter, Lampen nicht ausschaltbar
>
> aber:
>
> - keine gernomte Decoder-Schnittstelle mit Zusatzfunktionen
> - keine genormte Schnittstelle für Funktionsdecoder
>
> Ich finde es wird langsam ein Graus.
Ja ich denke, dass keiner so richtig mitdenkt. Alle meinen, Sie müssten
maximalen Profit rausholen und ihre Lösung abschotten .... das kann man sich
in einem Massenmarkt vielleicht erlauben, aber bei Moba ..... bitte Leute
arbeitet doch mehr zusammen, als gegeneinander .... es ist ein Hobby :-).
Aber wie ich schon ein paar mal oben indirekt erwähnt habe, unterstütze ich
sowas nur soweit ich muss, alles was ich kann, designe ich selbst oder
schließe mich mit Leuten zusammen die sowas können und liefere Ideen, etwas
weiterzuentwicklen ..... macht sowieso mehr spass .....
Ich wäre dafür dass die Leute mehr selbst entwickeln und anderen zur
Verfügung stellen. Es gibt so vieles, dass für kein oder wenig Geld zur
Verfügung gestellt wird und dabei dann gleichviel oder meistens sogar mehr
kann als die teuere vermeindliche Markenware..... speziell bei stationären
Decodern ist mir das aufgefallen, vergleiche man mal Märklin (etrem) mit
Littfinski (mittelmäßig) und den Decodern von Gerard Clemens. Das ist ein
Unterschied zwischen Tag und Nacht, ich will hier keine Schleichwerbung
machen, sondern nur meine Erfahrungen wiederspiegeln (mit den Decodern von
G.C., die habe ich und bin damit vollkommen zufrieden). Dass es noch weiter
gehen kann zeigt Open-DCC ......
Gruß,
Nils
Aber die Frage, wo is welche Lok und kann/darf sie da auch sein ist
wohl ziemlich entscheidend für die Steuerung. Man sollte vielleicht
auch mal an RFID denken - Chip im Gleis und die Lok liest aus bzw.
anders rum - RFIDF Leser im Gleis und in der Lok ein Transponder.
Servus Wolfgang
>Aber die Frage, wo is welche Lok und kann/darf sie da auch sein ist
>wohl ziemlich entscheidend für die Steuerung. Man sollte vielleicht
>auch mal an RFID denken - Chip im Gleis und die Lok liest aus bzw.
>anders rum - RFIDF Leser im Gleis und in der Lok ein Transponder.
Nichts zu danken.
RFID finde ich ist, zur Zeit zumindest, keine Lösung, da die billigsten
Lesegeräte (z.B.) Conrad immer noch um die 20 - 30 ? kosten. Außerdem müsste
die Lesegeräte relativ nahe an die Loks / Waggons und ich glaube selbst bei
Digitrax müssen die Dinger seitlich / 90 Grad zum Gleis eingebaut werden.
Dann muss man das ganze wieder tranen etc.
Natürlich könnte man das eine oder andere umkehren. Am liebsten wäre es mir,
ich baue die Sendedioden für das IR ins Gleisbett, die Lok fährt drüber,
merkt sich wo sie ist und meldet dies (wie auch immer) an die Zentrale
zurück. Man könnte dies auch eventuell über Funk tun, aber das wird wieder
störanfällig und / oder teuer.....
Also alles nicht so einfach.... :-(
Gruß,
Nils
> Ich habe wie gesagt die IB, weißt du zufälligerweise wieviele Präambelbits
> die aussendet ?
Weiß ich nicht aber glaube mich zu erinnern dass es 14 wie von der NMRA
in der Norm beschrieben sind. Zusätzlich gibt es weitere Signale wenn MM
oder Selektix eingeschaltet ist. In dem Fall werden nach den DCC Bytes
auch "0"en erzeugt um den Decodern anzuzeigen, dass jetzt kein DCC kommt.
> Kannst du bitte nochmal nachsehen, habe mal die Anleitung vom SL-51-2 und
> vom DCX51 runtergeladen, beim DCX ist zum CV 49 gar nix beschrieben und beim
> SL-51-2 regelt man damit den Sound. Weißt du zufällig auch, ob die Decoder
> das Bremsen nach Assymetrie von Haus aus beherrschen, oder ob sie ein Update
> (wie bei Zimo) brauchen ?
Hab' nix gefunden, werd den Meister in Wr. Neustadt telefonisch befragen
und die Antwort hier posten.
>> Ich bevorzuge vorzubremsen, soweit möglich in mehreren Stufen, sodass man
>> sich mit sehr geringer Geschwindigkeit dem Signal nähert. Der Halteweg ist
>> dann sehr kurz und ermöglicht eine hohe Haltegenauigkeit.
>
> Ja genau das brauche ich denn ich habe nur eine kleine H0-Anlage mit 2,4 x
> 2,4 m und 20 m Gleis. Bei diesen Maßen versteht man glaub ich, dass ich das
> Feature brauchen könnte .....
Da Du eine I-Box hast empfehle ich Dir eine SW auszuwählen die über
Zugverfolgungsmethode (an sich nicht so mein Fall) die Fahrzeuge früh
genug abbremst und dann langsam dem Haltepunkt nähert, und dort dann zum
Halten bringt.
Lt Telefonat von grad' vorhin mit ihm: Das Feature ist bei einigen
seiner Decoder realisierbar, dort wo die nötige HW drauf ist.
freigegeben ist es noch nicht. Einer der Gründe dafür befindet sich in
Giessen.
Verifiziert am DCX70 aber eben nicht in der Serie verfügbar.
>> Hab' nix gefunden, werd den Meister in Wr. Neustadt telefonisch befragen
>> und die Antwort hier posten.
>
> Lt Telefonat von grad' vorhin mit ihm: Das Feature ist bei einigen seiner
> Decoder realisierbar, dort wo die nötige HW drauf ist. freigegeben ist es
> noch nicht. Einer der Gründe dafür befindet sich in Giessen.
> Verifiziert am DCX70 aber eben nicht in der Serie verfügbar.
Danke nochmal. Mal wieder toll .... hauptsache Insellösung ....
Gruß,
Nils
Nils Brönner schrieb:
> "Peter Wagner" schrieb:
>> Also alle von den grossen Modellbahnherstellern angebotenen
>> Wagen-Innenbeleuchtungen funktionieren nicht mit Bidi?
Nicht ohne Umbau. Das ist einer der Punkte, die mich an dem
Prinzip mit der Lücke im Datenstrom stören. Aber es sollte
deutlich zuverlässiger werden, als das was Digitrax anbietet.
>> Hey, jetzt kriege ich aber auch schon langsam die Krise.
>> Wer denkt da eigentlich überhaupt mit in der Branche?
"Mit" im Sinne von Mitbewerber? ;-)
Nein, jeder denkt an seine Produkte. Soll der Hersteller von
Zubehör sehen, wie er damit klarkommt.
>>- MTX Doppelstockwagen in N mit fest eingebauter Innenbeleuchtung
>>- GFN Desiro Neukonstruktion in N: Innenbeleuchtung selbst bei der
>> Digitalversion
>> nicht digital schaltbar, Birnen hängen parallel Gleis!
>>- diverse Steuerwagen mit Schleppschalter, Lampen nicht ausschaltbar
Birnen sind wirklich ein Problem, LEDs sind da schon einfacher,
weil sie selbst eine minimale Flussspannung mitbringen. D.h. mit
dem vermehrten Einsatz von LEDs wird das Problem langsam kleiner.
>>- keine gernomte Decoder-Schnittstelle mit Zusatzfunktionen
>>- keine genormte Schnittstelle für Funktionsdecoder
Wenn wir mal einen der neuen Stecker endlich genormt haben, kann
man da auch locker Funktionsdecoder anschliessen. Die Kontakte
für den Motor kann man ja für stromhungrige Funktionen nehmen.
>> Ich finde es wird langsam ein Graus.
Es bewegt sich was, aber zu langsam im Vergleich mit der
Entwicklung der Geräte selbst.
> Ja ich denke, dass keiner so richtig mitdenkt. Alle meinen, Sie
> müssten maximalen Profit rausholen und ihre Lösung abschotten ....
Na ja, jeder möchte überleben. Das geht nur, wenn man die eigenen
Produkte verkauft. Der Druck sich einem Standard zu unterwerfen
sinkt mit der Firmengröße. Und auch wenn man im Grundsatz einem
Standard folgt, so gibt es immer noch genügend Freiräume.
> das kann man sich in einem Massenmarkt vielleicht erlauben, aber
> bei Moba ..... bitte Leute arbeitet doch mehr zusammen, als
> gegeneinander .... es ist ein Hobby :-).
Nicht für die Firmen. Und die betreiben den Spagat zwischen bei
DCC mitmachen, weil das sonst keiner mehr kauft, und eigenen
Sonderlösungen, die eine Markenbindung bringen sollen.
> Ich wäre dafür dass die Leute mehr selbst entwickeln und anderen
> zur Verfügung stellen. Es gibt so vieles, dass für kein oder wenig
> Geld zur Verfügung gestellt wird und dabei dann gleichviel oder
> meistens sogar mehr kann als die teuere vermeindliche Markenware.....
> speziell bei stationären Decodern ist mir das aufgefallen, vergleiche
> man mal Märklin (etrem) mit Littfinski (mittelmäßig) und den Decodern
> von Gerard Clemens.
Klar:
Märklin ist Systemanbieter. Von dem wird erwartet, dass er alles
anbietet. Da aber keiner alles selbst entwickeln kann, wird
zugekauft. Zudem ist es eine große Firma mit dem entsprechenden
Überhang an Verwaltung.
Littfinski ist ein reines Familenunternehmen. Die Stecken mehr
Zeit rein, als es ein Angestellter tun würde. Verwaltung ist
sichlich deutlich weniger.
Beiden gemeinsam ist, dass sie für ihre Produkte einstehen müssen.
Also Garantie, Gewährleistung und Kundenbetreuung. Gerard muss das
nicht. Das muss Darisus leisten, aber die haben die Entwicklung
(überwiegend) kostenlos erhalten.
Es ist eben schon ein Unterschied, ob jemand von einer Sache leben
muss, oder es rein als Hobby betreibt. Eine Firma muss für einen
Mindestumsatz sorgen. Also Werbung machen und auf Messen gehen.
Wenn man das nur nebenbei macht, ist einem der Umsatz egal und man
braucht das nicht.
Damit ist Selbstbau natürlich billiger. Natürlich könnten wir alles
selbst bauen. Aber dann auch bitte wirklich alles. Denn dann gibt
es keine Firmen mehr, die dem technisch weniger begabten Einsteiger
fertige Systemlösungen anbieten.
Ich gehöre auch zu den Modellbahnern, von denen keine Firma leben
kann. Und bei vielen hier in der NG ist das ähnlich. Die Firmen
leben nicht von uns, sondern von den Kunden, die sich im Laden oder
auf Messen beraten lassen und dort Fertigprodukte kaufen.
Gruß,
Reinhard