[thagu]

Servus zusammen

ich meld mich hier weil ich im Rocrail Forum irgendwie nicht weiterkomme. Mir fehlt das technisches Verständnis für die Vorgänge ein wenig.
Falls meine Frage hier nicht ausreichend beschrieben, hier der Link auf's Rocrail Forum: https://forum.rocrail.net/viewtopic.php?f=117&t=17606
Also, Ausgangslage:
Ich habe Rocrail auf PC, Redbox als Centrale, und fahre mit DCC. Dann habe ich einen Arduino über ein DCC Leser ans Gleis angeschlossen. Ziel ist es, damit Signale zu steuern.
Da ich mehr als 2 Aspekte habe beim Signal, würde sich das Extended Accessory Decoder Protokoll anbieten. Rob hat dies nun für die Redbox im Rocrail umgesetzt. Nur erhalte ich auf dem Arduino die falschen Adressen. Die Aspects sind richtig.
Ich habe es mit der NMRA DCC Library versucht, auch mit anderen (jenem vom Microbahner, Programmcode selbst erweitert für Extended Acc.).
So wie ich das verstehe, läuft es technisch so ab:
In Rocrail Signal schalten
Rocrail schickt P50x Telegramm XtrntX an Redbox
Redbox wandelt es in DCC Telegramm um
Arduino empfängt DCC Telegramm und wertet Adresse aus.

Protokoll von P50x:

1
2
3
4
5
6
7
8
9
10
11
 

	0: 0x91 XTrntX
	1: LSB des Extended-Accessory-Decoders (A0 .. A7)
	2: MSB des Extended-Accessory-Decoders (A8 .. A10) inkl. Aspect
	bit#   7     6     5     4     3     2     1     0
	    +-----+-----+-----+-----+-----+-----+-----+-----+
	    | As4 | As3 | As2 | As1 | As0 | A10 |  A9 |  A8 |
	    +-----+-----+-----+-----+-----+-----+-----+-----+
 
	  As4..As0 5 Bit Aspect (Bedeutung abh�ngig vom Decoder)
	  A10..A8    MSBs des Extended-Accessory-Decoders
 
 

Protokoll DCC Extended Acc. Decoder (gemäss NMRA s-9.2.1_2013):

1
 

{preamble} 0 10AAAAAA 0 0AAA0AA1 0 000XXXXX 0 EEEEEEEE 1
 

Wobei ich herausgefunden habe anhand der DCC Library, dass die Bits wie folgt zur Adresse zusammengesetzt werden:
1. Byte: 10AAAAAA --> bit 0-5
2. Byte: 0AAA0AA1 --> die ersten 3 A's werden zu Bit 6-8, die rechten beiden bilden der output-Port(gemäss Decodern mit 4 Ausgängen)

Also: Byte 1: 1 0 A5 A4 A3 A2 A1 A0
Byte 2: 0 A8 A7 A6 0 P1 P0 wobei P1 und P0 für den Outputport stehen.

Dann hat der Decoder folgende Adresse: A8 A7 A6 A5 A4 A3 A2 A1 A0
und der Output-Port ist: P1 P0

Soviel zur Theorie.
Wenn ich nun Signale sende, erhalte ich aber folgende Zuordnungen:

Rocrail Adresse (PADA)	DCC Adresse auf Arduino	DCC Raw Package
119	60	8F 77 2 FA
41	21	86 71 0 F7
10	6	82 73 0 F1

Hat jemand Erfahrung damit? Wo liegt der Fehler? Mach ich was falsch, liefert Rocrail falsche Protokolle, ...
Braucht ihr mehr Infos?
Ich wäre um Unterstützung riesig dankbar!
Grüsse
Guido

[Pirat-Kapitan]

Moin Guido,
hast Du mal versucht, den Vorgang aufzusplitten, also die Signale direkt über die Redbox-Zentrale anzusteuern und funktioniert dieser Teil?
Wenn nicht, brauchst Du m.E. gar nicht erst in Richtung Rocrail als "Eingabegerät" zu schauen.
Alternativ würde ich es mal mit Q-Decoder Signaldecodern versuchen, da gibt es fast unbegrenzte Möglichkeiten der Signalansteuerung. Wenn das klappt, hättest Du zumindest ein funktionierendes Muster für Deine Nachbildung auf dem Arduino.
Wenn mich nicht alles täuscht, ist bei DCC die Weichenadressierung unterschiedlich zur Adressierung einer Lok, hast Du das beachtet?
Letztendlich bin ich mir nicht sicher, ob das P50x Protokoll als Zentralenanbindung an Rocrail die optimale Wahl ist. Mir ist dieses Protokoll als mit doch sehr gravierenden Einschränkungen behaftet bekannt (eigenes Erleben).

Schöne Grüße
Johannes

[thagu]

Hallo Johannes

du hast deine Fühler also auch hier, nicht nur im Rocrail Forum. super!
Zu deinen Punkten:
- wie soll ich das tun, die Signale direkt über die Redbox Zentrale ansteuern? ich habe nur den Computer und Rocrail, um so was zu tun.. CV-Navi?
- Q-Decoder kenn ich, möchte ich aber vermeiden (ich habe noch keine). Selbstbau ist lustiger, flexibler und günstiger. Einen anderen Extended Accessory zum testen habe ich - so glaube ich - nicht. Werde das noch prüfen und ggf. durchführen. Gute idee.
- Addressierung im Rocrail läuft über Adressfeld auf Signal. Von dem her kann ich da nicht viel ändern. Und der DCC Sniffer erkennt ja die Extended Accessory Pakete offenbar.
- zur P50x Anbindung: ist die nicht vorgegeben von Rocrail und den Decodern? Gibt's alternativen auf dem bestehenden System? Zudem liefert der XTrntX Befehl eigentlich genau das, was ich brauche. Basic Accessory Decoder (also z.B. normale Weichen/Servos) funktionieren wunderbar.

Grüsse
Guido

[moppe]

Zitat

---

Selbstbau ist lustiger, flexibler und günstiger.

---

Aber - funktioniert nicht.......


Klaus

[thagu]

1
 

Aber - funktioniert nicht....... :twisted:
 

Danke für den überaus konstruktiven Beitrag...

Gerne würde ich ja wissen, warum. Ein System zu verstehen scheint mir immer besser, als unbekannte Dinge miteinander zu verknüpfen. Und dann bei Problemen auch vor dem Berg zu stehen.

Mich reizt die technische Herausforderung. Und bis jetzt ging das mit den Arduinos und den Servos sehr gut, warum also nicht auch mit Signalen?

[MicroBahner]

Hallo Guido,

Zitat

---

Ich habe es mit der NMRA DCC Library versucht, auch mit anderen (jenem vom Microbahner, Programmcode selbst erweitert für Extended Acc.).

---

Das ist eigentlich dasselbe, da ich auch die NMRAdcc Lib einsetze. Da ich mich dort auch bei der Entwicklung einbringe, glaube ich sie recht gut zu kennen. Gerade zu den Adressen habe ich vor dem letzten Update recht intensiv mit Alex diskutiert, da die Normen hier nicht ganz eindeutig sind.

Deine Berechnung der Adressen mit den Outputports ist für die extended Telegramme nicht richtig. Das gilt für die Basis Telegramme mit Decoder-Adressierung. Das gibt es bei den extended Zubehörtelegrammen nicht. Da sind die beiden Bits, die Du als P0/P1 bezeichnest, A0 und A1 der Adresse. Das niederwertigste Bit im ersten Byte ist dann bereits A2.

1
2
 

Paket:   1 0 A  A  - A  A  A  A   | 0  A    A   A  - 0 A  A  1
Adresse: – – A7 A6 - A5 A4 A3 A2  | – /A10 /A9 /A8 - – A1 A0 -
 

Allerdings gibt es da noch eine Diskrepanz bei den verschiedenen Normenblättern. Es geht darum welche Telegrammadresse als Adresse '1' in den Benutzeroberflächen dargestellt werden soll. Das hängt damit zusammen, dass die meisten Hersteller bei der Decoderadressierung den Decoder '0' nicht verwenden, und so der erste Ausgang am Decoder '1' als Weichen/Signaladresse '1' interpretiert wird. ROCO hat dies aber nicht gemacht, so dass bei Roco der erste Ausgang am Decoder '0' die Weichenadresse '1' ist.
Diese Diskrepanz hat sich leider auch bei den extended Adressierungen durchgezogen. Es geht also darum, ob die Telegrammadresse '0' als Signaladresse '1' dargestellt wird, oder eben die Telegrammadresse 4 = Signaladresse 1 ist ( Eine Adresse '0' soll dem Anwender wohl nicht zugemutet werden ).
In deiner Tabelle entsprechen die 'Adressen auf Arduino' dem Fall, dass Telegrammadresse '4' als Signaladresse '1' interpretiert wird. Ich meine allerdings, dass wir bei der NMRAdcc-Lib diesen Offset nicht drin haben. Da bin ich mir aber nicht mehr ganz sicher wie wir uns letztendlich entschieden haben, da muss ich nochmal machschauen.

Die Rocrailadressen kann ich im Moment nicht den Telegrammen zuordnen. Soweit ich mich erinnere gibt es bei Rocrail aber verschiedene Adressinterpretationen (MADA/PADA/FADA) wobei aber PADA wohl eigentlich dem 'Outputadressing' entsprechen sollte, bei dem eben alle Adressbits linear verwendet werden und es keine getrennte Adressierung von Decoder und Ausgängen gibt.

[thagu]

Guten Abend MicroBahner

wow, super, vielen Dank für die kompetente Unterstützung.

Zitat

---

1
2
 

Paket:   1 0 A  A  - A  A  A  A   | 0  A    A   A  - 0 A  A  1
Adresse: – – A7 A6 - A5 A4 A3 A2  | – /A10 /A9 /A8 - – A1 A0 -
 

---

Da habe ich mich etwas umständlich ausgedrückt. Am Ende habe ich das auch so verstanden, allerdings andere Interpretationen auch durchgerätselt. Trotzdem geht's aber noch nicht auf. Die Raw Pakets sind ja genau so umgerechnet, das habe ich geprüft (war auch zu erwarten). D.h. die Raw Pakets entsprechen schon nicht dieser Anforderung.

Zitat

---

Es geht darum welche Telegrammadresse als Adresse '1' in den Benutzeroberflächen dargestellt werden soll

---

Das würde aber höchstens einen Offset von 1 bedeuten, egal wie interpretiert, oder?

Zitat

---

da muss ich nochmal machschauen.

---

wäre super, wenn du das klären könntest...

Zitat

---

gibt es bei Rocrail aber verschiedene Adressinterpretationen

---

so habe ich es auch verstanden und so steht es auch im Wiki von Rocrail. Ich beabsichtige, mit der PADA Adressierung zu fahren, anderes wäre aber auch möglich. Wie du schreibst, entspricht die PADA Addressierung am besten der Verwendung mit Arduino, da ich da keine Ports an sich habe, die ich so gruppieren müsste.

Kannst du aber bestätigen, dass meine grundsätzlichen Gedankengänge richtig sind? Ich habe noch vor, das Verhalten mit unterschiedlicher Addressierung in Rocrail zu beobachten, dh. PADA, MADA, etc... ev. bringt das noch Licht ins Dunkle, resp. lässt eine Zuweisung der Einstellung im Rocrail mit dem DCC Telegramm erahnen...
Danke schon mal für den Support
Grüsse
Guido

[MicroBahner]

Hallo Guido,

Zitat

---

Das würde aber höchstens einen Offset von 1 bedeuten, egal wie interpretiert, oder?

---

Es bedeutet einen konstanten Offset von 3 ( Telegrammadresse 4 wird zu Zubehöradesse 1 ).

Ich habe auch nochmal nachgeschaut. Wir hatten uns letztendlich entschieden, die Adressberechnung für die extended Telegrame (Signaltelegramme) genauso zu behandeln wie die Output-Adressierung bei den Basis Telegrammen. D.h. auch da ist der Offset drin. Das passt mit den Werten aus deiner Tabelle zusammen. Nur die Rockrailwerte in der Tabelle passen nicht dazu. Die Frage ist, wie aus der Rockrailadresse das DCC-Telegramm entsteht und wo auf diesem Weg der Fehler passiert. Die Rockrailadresse in deiner Tabelle passt jedenfalls definitiv nicht zu dem RAW Telegramm in der Tabelle.

Ich hatte damals die NMRAdcc Lib bei den Basis-Telegrammen und Output-Adressing auch mit Rockrail getestet. Da hat das mit den PADA-Adressen gepasst. Ich hatte aber keinen Weg gefunden, die extended (Signal) Telegramme mit Rockrail zu erzeugen (kenne mich aber mit Rockrail auch nicht gut aus). Als Zentrale hatte ich einen Arduino mit DCC++ Sketch verwendet.

[thagu]

Hallo MicroBahner und ggf Mitleser

ich habe gestern noch ein wenig rumprobiert mit verschiedenen Einstellungen im Rocrail und tatsächlich einen Weg gefunden, wo die Adressen bedingt 1:1 stimmen zwischen Sender und Empfänger:

Auch wenn meines Verständnis' nach Rocrail mit linearer Adressierung bei Signalen arbeitet, ist dies nur bedingt der Fall. Erklärung:
Ich habe zwei Felder, Decoder und Port, die ich füllen kann. Bisher habe ich nur immer Decoder gefüllt, da ich das so verstanden habe.
Wenn ich aber nur das Port-Feld fülle, erreiche ich die korrekte Zuweisung. Beispiel: DCC Acc Addresse 145 verlangt nach Einstellung im Rocrail: Decoder = 0, Port = 145.
Alternativ geht auch eine Mischform mit Decoder und Port, dann darf Port aber nicht 0 sein. also: DCC Acc Addresse 145 ist im Rocrail Decoder 37 und Port 1. Die Rechnung geht wie folgt:

(decoder -1)*4 + port
also (37-1)*4 + 1 = 145.
Wenn der Port 0 ist, geht's nicht, dann kommt irgendwas komisches raus.

Das passt für mich so, Problem eigentlich erledigt. Ich werde das Verhalten auch noch im Rocrail Forum posten.
Noch Kommentare?

Grüsse
Guido

[Pirat-Kapitan]

Moin Guido,
bei Rocrail,sollte es wohl Adresse und Port und nicht Decoder und Port heißen.

Schöne Grüße
Johannes