Hi zusammen,

was mich jetzt am meisten interessiert - ich hoffe das auch jemand aus dem "Decoder-Thread" mitliest,

Spielt die Z21pg jetzt auch mit den Eigenbau-Loconet-Decodern aus Microbahners (Franz-Peter) Thread? Das es mit "reinem" DCC funktioniert dass weiß ich, das habe ich selber schon getestet, aber wie sieht es jetzt mit den Loconet Decodern aus.

Und nein, ich möchte nicht wissen ob es mit Digik.., ESU, oder sonstigen kommerziellen Typen funktioniert. Wenn Eigenbau - dann richtig. O.K. von Lok Decodern habe ich nie gesprochen, es geht mir nur um Zubehördecoder.

Ich hoffe das jemand da etwas positives zu berichten kann.

Verschneite Grüße aus Castrop-Rauxel

Ulrich

Zitat von Ingolf im Beitrag Suche Erfahrungsaustausch zur Z21 nach Philipp Gahtow

---

habe angefangen, die erste Seite zu überarbeiten, aber noch nicht fertig.
Bitte mal drüber schauen.

---

Zitat

---

Andre hat einen sehr schönen, bebilderten Baubericht geschrieben. (Beitrag 535 Seite 22).
Dieser enthält auch eine Zip-Datei mit allen Schaltplänen, Material-Liste etc.

---

So ist das toll, man sieht auf der ersten Seite um was es geht und kann sich gut orientieren.
@ alle
Gibt es noch bei jemandem die Platine zu Z21Pollin, würde gerne 1-2 erwerben.
@ uwe
bin gespannt auf den Bericht zum Loconet.

Wünsche allen einen schönen Abend.
Grüße Matthias

Lieber Ulrich,

Zitat

---

Spielt die Z21pg jetzt auch mit den Eigenbau-Loconet-Decodern aus Microbahners (Franz-Peter) Thread? Das es mit "reinem" DCC funktioniert dass weiß ich, das habe ich selber schon getestet, aber wie sieht es jetzt mit den Loconet Decodern aus.

---

Sehr interessant. Leider funktioniert in deinem Beitrag der Link nicht. Mit der Suchmaschine habe ich auch nur Zubehördekoder vom Microbahner (Franz-Peter) für LocoNet gefunden, keinen Belegtmelder mit RailCom.

Wenn Du so ein Teil gebaut hast, bin ich gern bereit den dieses Teil bei mir zu Testen. Einfacher für Dich ist es jedoch Dir eine (vereinfachte) Z21PG zu bauen und gleich selbst zu Testen. Sparst Du Dir den Weg zur Post und kannst hier über Deine Erfolge berichten.

Ich habe leider noch keinen gebaut und auch kein Interesse und Bedarf irgend so ein komerzielles Teil zu kaufen.

Viele Grüße aus dem kalten Dresden
Uwe

Hallo Uwe,

Zitat

---

nur Zubehördekoder vom Microbahner (Franz-Peter) für LocoNet gefunden, keinen Belegtmelder mit RailCom

---

Es war nie die Rede von Belegtmelder mit Railcom. Es geht mir nur um die Loconet Decoder aus diesem Thread ( viewtopic.php?f=5&t=144916 ) und hier um die Version 6.

Zitat

---

Einfacher für Dich ist es jedoch Dir eine (vereinfachte) Z21PG zu bauen und gleich selbst zu Testen

---

Ich habe hier eine, nicht nur vereinfachte, Z21pg mit der soweit alles funktioniert. Nur wie soll ich z.B. den Loconet Teil überprüfen? Selbst wenn die Hardware in Ordnung ist, wer sagt mir wie ich das Teil z.B. bei RocRail einbinde um es zu überprüfen?

Das gleiche Problem sehe ich bei Belegtmeldern die auf dem Arduino basieren und an den S88 Bus angeschlossen werden....

Deshalb meine Frage ob hier schon jemand die Z21pg zusammen mit einem Eigenbau Loconet Decoder im Einsatz hat.

Mit Railcom hab ich nix am Hut, können meine Lokdecoder nicht...

Viele Grüße aus Castrop-Rauxel, der größten Stadt des Ruhrgebiets zwischen Datteln und Herne

Ulrich

Hallo Ulrich,

du liest hier schon etwa 1/2 Jahr mit und deine Frage wurde schon mehrfach beantwortet.
Aber für Dich noch einmal, der LocoNet-Anschluss an der z21PG ist ein L.NET T - Interface für Handregler und Rückmelder.

Für deine Zubehördekoder brauchst du ein L-NET B - Interface für Zusatzgeräte und Booster.
Du kannst Dir eine DR5000 Zentrale zulegen, da ist diese Schnittstelle vorhanden.

Andreas

Hallo Andreas,
korrigier mich bitte:

Loconet-B = Loconet-T + RailSync (im Grunde DCC im Loconet-Kabel)

D.h. beim Loconet-B sind die äußeren beiden Leitungen RailSync - bei Loconet-T fehlen diese. Das Eigentliche Loconet (Protokoll) geht über die inneren 4 Leitungen.

Der Eigenbaudecoder sieht die inneren 4 Leitungen vor. RailSync bleibt frei. Hardwareseitig sollte es passen. Ich habe allerdings gerade keinen Überblick wie das Softwareseitig aussieht.

Zitat von juergiboy im Beitrag Arduinobasierter DIY Zubehördecoder V7.0.0 freigegeben

---

Die dritte Version ist über LocoNet angesteuert, hier stehen 10 Ausgänge zur Verfügung, 2 immer für Servo, 8 wahlweise auch über einen ULN2803:
Arduino LocoNet Decoder

---

Hallo Uwe,

ich habe noch keine Erfahrung mit dem LocoNet und habe es so gelesen,
LocoNet B - diese Buchse stellt nicht nur die LocoNet-Signale zur Verfügung, sondern auch das Schienensignal,
LocoNet T - an dieser Buchse steht das Schienensignal nicht zur Verfügung, stattdessen liegt hier eine Gleichspannung an.
(Uhlenbrock - LocoNet-Bus)

Der Fahrregler sendet auf dem LocoNet den Befehl Weiche '23' - gerade. Die LocoNet Digitalzentrale hört auf diesen Befehl und gibt auf der Schiene das Signal für den Weichendecoder aus.

Die z21PG ist eine Z21 DCC Digitalzentrale auf Basis eines Arduino mit dem Z21 Protokoll und einem LocoNet-Adapter.
Ich habe PG Beschreibung zur Integration des LocoNet-Interface so verstanden, LocoNet-Schnittstelle als Brücke für FRED oder DAISY Handregler zum Z21 Protokoll
oder LocoNet-Client Mode (Slot-Server abschaltbar) für den Anschluss an der Intellibox (z21PG mit Wlan und App ist "Handregler" an der Intellibox),
Programmierung von LocoNet LNCV über die Z21 mobile APP.

Den Anschluss z.B. von Rückmelder beschreibt PG nicht, so denke ich, es werden nicht alle Funktionen des LocoNet durch das LocoNet-Interface "übersetzt" oder die Informationen werden in einem TCP-Paket weitergegeben.

Zitat

---

verpackt die Z21PG die LN-MELDUNG nur in ein TCP-Paket welches von RR verstanden von der App jedoch NICHT verstanden wird.

---

Viele Grüße
Andreas

Hallo Andreas,

zum ersten Punkt: Richtig "Schienensignal" == "RailSync"
Diese Leitungen dienen aber beim Loconet-B auch der Stromversorgung der Handregler/FREDS. Beim Loconet-T (z.B. an der PG) wird da nur 12 V zur Stromversorgung angelegt.

>>Der Fahrregler sendet auf dem LocoNet den Befehl Weiche '12' - gerade. Die LocoNet Digitalzentrale hört auf diesen Befehl und gibt auf der Schiene das Signal für den Weichendecoder aus.
Richtig, das ist Aufgabe der z21PG als "DCC Digitalzentrale"

Weiterhin (gerade getestet) sendet die Z21PG bytes in das LocoNet:
STX:(7) B0 0B 10 54
STX:(7) B0 0B 30 74

Siehe Digitrax Handbuch Seite 9/10
OPC_SW_REQ 0xB0 ;REQ SWITCH function
<0xB0>,<SW1>,<SW2>,<CHK> REQ SWITCH function
Das sollte der LocoNet-Zubehördecoder verstehen. Muss nun nur noch einer ausprobieren.


Die Rückmelder beschreibt PG zwar nicht sind aber implementiert.
Die Rückmelderereinisse aus dem LocoNet OPC_SW_REQ werden an im Z21-Protokoll einerseits "eingewickelt" mit z21.setLNMessage() und andererseits als Belegtmeldung z21.setLNDetector() weitergereicht. Übrigens UDP und nicht TCP .

Belegtmeldung vom LocoNet
LnRX: B2 03 60 2E
Weiterleitung an RocRail oder was auch immer ...
1 Z21 TX: 8 0 A0 0 B2 3 60 2E ETX 1 BC:10000 : 8 0 A0 0 B2 3 60 2E
RC-Loknummer vom LocoNet
LnRX: E0 09 00 07 00 58 00 00 49
Weiterleitung an ...
1 Z21 TX: D 0 A0 0 E0 9 0 7 0 58 0 0 49 ETX 1 BC:10000 : D 0 A0 0 E0 9 0 7 0 58 0 0 49

Warum die App nicht geht habe ich noch einen anderen Verdacht. Im Gegensatz zur schwarzen Z21 muss bei der PG die Information abonniert werden.
Ein Starten von RocRail und ggf. der App muss nach dem Start der PG erfolgen. Werd ich irgendwann nochmal testen.

Viele Grüße und gute Nacht.
Uwe

Liebe Z21-Bastler!

Nach einem Monat mit umfangreichen Tests und Softwareanpassungen möchte ich nun mal mit einer Zsammenfassung beginnen. Ursache für diese Forschungen war ein habwegs stabiler Betrieb der DR5088RC an der Z21PG mit RailCom-Kanal 1. Beim Kanal 2 zappelte es jedoch ganz schön gewaltig.

Vorab noch einige Worte während im Hintergrund noch einige Langzeittests laufen:

Ziel war es "mal eben schnell" zu Testen ob die PG21 im Zusammenspiel mit RocRail und den Belegtmelder DR5088RC (keinen Loconet-Funktionsdecoder !!!) hinsichtlich der Loknummernerkennung via RC funktioniert. Insgesamt hat das dann doch ca. 120 h Arbeitszeit und ein paar Nerven gekostet. Die Freude am Lernen und das es jetzt "funzt" gleicht das jedoch aus.

Warum ich einen Kauf-Belegtmelder genommen und nicht alles selber bauen ? Nun, Ideen sowas umzusetzten hätte ich schon, nur ... Ich glaube fest daran, dass ich sowas könnte und spare mir Zeit und Geld - OK Außerdem ist es keine Kunst zwei Eigenbaugeräte aufeinander abzustimmen. Reizvoller war es schon, mit einer vorhandenen Blackbox, auf die man keinen Einfluss hat, zurechtzukommen.

Doch, was geht nun ? Ich versuch mal das Pferd von hinten aufzuzäumen (chronologisch erfolgten Forschungen/Erkenntnisse/Änderungen in ungekehrter Reihenfolge, also von unten nach oben).

Zur Info:
Beim Ermitteln der RC-Adresse über Kanal 1 wird die eine Rückmeldung des Dekoders (ACK) ausgewertet wenn dieser mit seiner eigenen Adresse Angesprochen wird. D. h. es sollte im Normalfall nur eine Lok antworten. Hierzu ist es allerdinges erforderlich, dass alle Loks in einem bestimmten Zeitfenster zyklisch angesprochen werden. Dabei wird ein Ringspeicher verwendet in dem alle während der Laufzeit der Zentrale gesendeten DCC-Pakete abgelegt werden. Geänderte Pakete (z.B. Funktion wieder aus, andere Geschwindigkeit) werden überschrieben. Damit alle Loks in einem minimalen Zeitfenster einmal bedient werden, habe ich die Software angepasst (siehe unten). Ohne diese Anpassung werden u. U. alle Pakete einer Lok hintereinander und dann alle anderen Loks "angepingt". Der Abstand dieser Rückmeldungen ist dann bei vielen Loks mit vielen aktiven Funktionen einfach zu groß und der Detektor meldet die Lok "abwesend".

Ein Rechenbeispiel:
Pro Lok können neben einem Paket für die Geschwindigkeit bis zu 5 Pakete mit Funktionsausgängen gesendet werden. Diese werden im DCC-Refresh-Ringspeicher zyklisch wiederholt. Der Ringspeicher kann eine maximale Größe von 255 Paketen haben. Ein Paket benötigt ca. 8 ms für die Übertragung. Das bedeutet - im Extremfall max 255 Loks = 2 Sekunden für die Wiederholung. So viel Geduld hat die DR5088 nicht - max. 1200 ms = 150 Loks. Dabei darf es jedoch zu keinerlei Übertragungsstörungen kommen. Das ist praktisch ausgeschlossen. Die folgenden Werte habe ich in Langzeittests mit simulierten Loks ermittelt.

Getestet habe ich die PG21-MEGA, Rocrail und DR5088RC mit den Werkseinstellungen:

Belegungdetectorzähler: 15
Polaritätszähler: 2
Adressendetektionswartezeit: 250 ms
Multiplexer Scan-Zeit: 33 ms
Detektor (1-17) Eigenschaften - Aus Wartezeit: 750 ms
 

Mit meiner aktuellen Softwareadaption (2019-02-0x) und der DR5088-Version 1.4.1 (Werkseinstellungen) geht:
- die Erkennung mittels Railcom Kanal 1 (CV #28 = 3), max eine Lok pro Abschnitt
- die Erkennung mittels Railcom Kanal 2 (CV #28 = 2), Haken DR5088 "Verwende Kanal 2 ..."
- max. vier Loks pro Abschnitt
- max. 32 aktive Loks, gesamt max. 172 DCC-Pakete, Werkseinstellungen in DR5088
- max. 33 aktive Loks, 178 DCC-Pakete, DR5088-Multiplexer Scan-Zeit: 34 ms
- max. 37 aktive Loks, 207 DCC-Pakete, DR5088-Multiplexer Scan-Zeit: 35 ms, neue Befehle führen zu Aussetzern
- max. 38 aktive Loks, 213 DCC-Pakete, DR5088-Multiplexer Scan-Zeit: 36 ms
- max. 40 aktive Loks, 225 DCC-Pakete, DR5088-Multiplexer Scan-Zeit: 38 ms, XpressNet blockiert !!!
- max. 40 aktive Loks, 151 DCC-Pakete, DR5088-Multiplexer Scan-Zeit: 38 ms
- max. 44 aktive Loks, 167 DCC-Pakete, DR5088-Multiplexer Scan-Zeit: 38 ms
- max. 50 aktive Loks, 191 DCC-Pakete, DR5088-Multiplexer Scan-Zeit: 38 ms, 2h fehlerfrei, XpressNet OK
- max. 60 aktive Loks, 231 DCC-Pakete, DR5088-Multiplexer Scan-Zeit: 38 ms, 1h fehlerfrei, XpressNet OK
- max. 70 aktive Loks, 204 DCC-Pakete, DR5088-Multiplexer Scan-Zeit: 38 ms, instabil, XpressNet blockiert !!!
- max. 70 aktive Loks, 136 DCC-Pakete, DR5088-Multiplexer Scan-Zeit: 38 ms, instabil
- max. 64 aktive Loks, 126 DCC-Pakete, Refresh-Zyklus 430 ms, DR5088 angepassten Einstellungen (s.u.): Stunden-Test OK

Diese Extremwertbetrachtungen sind jedoch nicht ohne weiteres auf den Praxisbetrieb übertragbar. Neue Kommandos drängeln sich dazwischen und führen zwangsläufig zu kurzen Unterbrechungen der Belegtmeldung. Praktisch scheinen 25 Loks (mit DR 5088 Werkseinstellungen) und 45 mit folgenden angepassten Einstellungen praktikabel:

Belegungdetectorzähler: 5
Polaritätszähler: 2
Adressendetektionswartezeit: 15 ms
Multiplexer Scan-Zeit: 38 ms
Detektor (1-17) Eigenschaften - Aus Wartezeit: 1200 ms
 

Das Ganze ist nun etwas träge aber wenn es sein muss ...

Welche Wirkung der Multiplexer hat ist mir nicht ganz klar. Ich denke jedoch, dass die DR5088 hardwareseitig für den Kanal 1 entwickelt wurde (da braucht man entweder viele serielle Schnittstellen, einen Multiplexer oder eine Mischung aus beiden). Kanal 2 wurde wohl softwareseitig nachgeschoben. Ein Multiplexer ist grundsätzlich für Kanal 2 nicht nötig, da ja nur eine Lok antworten sollte.

Doch wie kommen die Loks überhaupt in diesen Refreshspeicher?
1. ALLE Loks manuell z. B. über Multimaus oder RocRail ansprechen (F0 an/aus, V=0) - unbequem!!!
2. selber in die PG-Software feste Loks reinprogramieren - ungünstig, nur zum Testen
3. in der PG-Software die Loks im EEPROM ablegen - müssten wie einen Programmierer einstellen
4. im RocRail - Automatik - "Bei Gleisspannung EIN Geschwindigkeits-Befehl Null senden" aktivieren.
Dabei werden nach dem Einschalten von RR alle parametrierten Loks einmal angesprochen. Rob hat die Funktion ab Version 14900 gängig gemacht und ich konnte es am 24.01.2019 mit 14916 erfolgreich testen.

Bei richtig vielen Loks die auch nur gelegentlich verwendet werden müsste der Refreshspeicher noch mit einer Funktion des Vergessens versehen werden. Ziel pro Lok nur noch ein Paket. Unbenutzte (Funktionen aus, V=0), überzählige Pakete pro Lok raus. Weiterhin könnte man "stehende" Loks (V=0) anders priorisieren und die Abmeldungen stehender Loks im LocoNet abfangen. Da fehlt aber ein universelles Gesamtkonzept, Zeit und die Zahl der fahrfähigen Loks Loks bauenhat Vorfahrt!
Die Frage ist weiterhin ob das bei der MEGA-Zentrale überhaupt sinnvoll ist (Speicher, Prozessorleistung).

--------------------- Achtung ! Ab hier kommen langweilige technische Details. -----------------------------------

Hinweis: Die folgenden Änderungen wurden so eingebaut, dass sie mit #define in den ersten Zeilen der jeweiligen Dateien wieder rückgängig gemacht werden können (Auskommentieren mit "//" vor dem jeweiligen #define). Das soll das Testen für mich und die nicht so programmieraffinen unter Euch erleichtern.

1.
Um alle Loks mit einer ausreichenden Regelmäßigkeit ansprechen zu können musste ein hinsichtlich Lesbarkeit, Speicher und Rechenleistung günstiger Algorithmus gefunden werden. In der Refresh-Queue werden jetzt die jeweiligen Lok-/Adresspakete beieinander gehalten. Das erste Paket der Lok wird am DCC ausgegeben, alle weiteren dieser Lok wieder hinten angefügt, und zuguterletzt das eben ausgegebene als letztes hinten angefügt. Dann kommt die nächste Lok/Adresse. Somit hat ein Zyklus maximal die Länge von 8 ms * Anzahl Loks. Kommt ein neues Paket aus der Repeat-Queue in die Refresh-Queue wird es nur hinten angefügt und ein Flag gesetzt ("packet->setRepeat(0x3F);"). Ist die Lok/Adresse das nächste mal dran, werden alle Pakete dieser Adresse in der Queue zusammengesammelt und als Block hinten angefügt. Rechenleistungsbedarf ist OK, da das pro eingefügten Packet nur einmal erfolgen muss.

librariesDCCInterfaceMasterDCCPacketQueue.cpp
#define RC_CH2_OPTIMIZED        // Optimiert für Belegtmeldung mir RailCom-Kanal-2, sendet Pakete aller Loks/Adressen gleichverteilt, unabhängig wieviele Paketarten/Funktionen aktiviert
 
 

2.
Bei jedem eingefügten Packet wird die gesamte Queue durchsucht ob Adresse und Funktionsart ("Kind") schon enthalten sind. Wenn ja wird es überschrieben, sonst angefügt. Allerdings erfolgt im ursprünglichen Code dieser Exist-Check immer. Wurde das Paket eben entnommen ist diese Prüfung jedoch überflüssig. Der Exist-Check wird nun nur noch bei neu eingefügten Paketen durchgeführt.

librariesDCCInterfaceMasterDCCPacketQueue.cpp
#define CHECKEXIST false  // false fügt gerade gelesene Pakete am Ende der Queue ein ohne nochmal auf Vorhandensein zu prüfen, true ist Unsinn, da Pakete bereits geprüft --> Performance und Laufzeitkritisch
 
 

3.
Leider führt eine zu lange Rechenzeit für das Umsortieren der Queue dazu, dass deas Aussenden des DCC-Packetes schon beginnt, bevor die Daten hierfür bereitstehen. Dauert die Berechnung länger als bis zum Ende der Präambel, werden im DCC-Bitstrom lauter "1" eingefügt was zu einem ungültigen Packet und CHK führt. Änderung durch Entkoppelung der Prozesse insofern, das die neuen Daten vorab bereitgestellt werden und anschließend umsortiert werden.

librariesDCCInterfaceMasterDCCPacketSheduler.cpp
#define ENTKOPPLESHEDULER   //UH 2019-01-30, ermöglicht DCC-Ausgabe entkoppelt, von der refresh_queue-Umsortierung
 
 

Der untere Kanal zeigt die ob die Funktion readPacket() mit dem Umsortieren des Ringspeichers beschäftigt ist (Debug-Pin 23 wird am Anfang der Funktion gesetzt und am Ende wieder auf 0 zurückgesetzt).

4.
Zur Erzeugung des DCC-Signals wird ein Interrupt (TIMER2) verwendet der immer hzur rechten Zeit die ISR (Interrupt Service Routine) aufruft und den Flankenwechsel veranlasst. Ist gerade ein anderer Interrupt aktiv sind standardmäßig alle anderen Interrupts verboten. Das bedeutet die DCC-Flanke wird um eine gewisse Zeit verzögert. Da der Xpressnet-Interrupt ca. 15 us benötigt kommt es zu Flankenverschiebungen von 15 us (siehe Bilder) - zulässig sind 3 oder 6 us ... Abhilfe schafft jetzt die Möglichkeit den Xpressnet-Interrupt durch einen anderen Interrupt zu unterbrechen.



Die roten Kreuze und Punkte im DCC-Signal zeigen die verjitterten Stellen/Flankenwechsel. Unten ist dann alles gut

//UH 2019-01-24 verursacht DCC-Jitter, 2019-01-25 Anpassung in librariesXpressNetMasterxpressnetmaster.cpp
#define ENABLE_IE_RX      //Erlaubt Unterbrechng der XpressNet-RX-Interrupte, alleine nicht ausreichend, gemeinsam praktisch 100%-tig
#define ENABLE_IE_TX      //Erlaubt Unterbrechng der XpressNet-TX-Interrupte, Minimum zur Jitterunterdrückung, geringer Jitter, Kaum Enfluss auf XpressNet-MM
#define DISABLE_IE_TIMER0 //Verbietet Unterbrechng der XpressNet-Interrupte durch Timer0 (ca. 5 us Ausführungszeit)
 
 

5.
Der arduinoeigene Timer0 dient u. A. delay(), millis() und somit dem Zählen der Millisekunden. Der Aufruf erfolgt aller 1 ms und hinterlässt recht regelmäßig im DCC-Signal einen weiteren Jitter von ca. 5 us.



Auch dieser stört das DCC-Signal. Es ist dem aber nicht so einfach beizukommen. Es sind Änderungen an der Datei wiring.c im Programme-Pfad erforderlich (Admin-Rechte!!!). Diese gilt dann für alle Arduino-Projekte!!! Wer das nicht möchte - für 5 bis 8 Loks scheint es zu gehen (ausreichend Zyklen im Prüfzeitraum der DR508 für mehr Loks sollte man die Anpassung vornehemen. Ähnlich dem XpressNet wird hier anderen Interrupts (und so auch DCC) erlaubt hier einzuspringen und zu unterbrechen.

// import aus C:Program FilesArduinohardwarearduinoavrcoresarduinowiring.c
// UH 2018-01-27 Enable the Global Interrupt Enable flag so that other interrupts can be processed 
// #define ENABLE_IE == Änderung um kleinen DCC-Jitter auszuschalten (ca. 5 us)
 
#if defined(__AVR_ATtiny24__) || defined(__AVR_ATtiny44__) || defined(__AVR_ATtiny84__)
ISR(TIM0_OVF_vect)
#else
ISR(TIMER0_OVF_vect)
#endif
{
  // Enable the Global Interrupt Enable flag so that other interrupts can be processed 
  #define ENABLE_IE
  #ifdef ENABLE_IE
      char oldTIMSK0;
      oldTIMSK0 = TIMSK0;
      TIMSK0 = 0;
      sei(); // Enable the Global Interrupt Enable flag so that interrupts can be processed 
  #endif
 
...
 
  #ifdef ENABLE_IE
      cli();  //disable interrupts
      TIMSK0 = oldTIMSK0;
  #endif
}
 
 

Die angepasste Funktion ist nochmal am Ende der *.ino als Kommentar angefügt.

6.
Um nun noch genug Speicher für die ganzen Datenpakete zu haben, müssen die Queuegrößen noch angepasst werden (nur beim MEGA).

librariesDCCInterfaceMasterDCCPacketSheduler.cpp
#define MAX_REFRESH_QUEUE   //UH 2019-01-26 gosser DCC-Repeat- und maqximaler DCC-Refrsh-Puffer
 
 

7.
RailCom-CutOut: Die Datenübertragung von der Zentrale zum Decoder wird nicht ununterbrochen durchgeführt, sondern es wird ein Zeitmultiplex eingeführt, welches Zeitschlitze für die Übertragung zum Decoder und für den Rückweg vorsieht. Der Zeitschlitz für die Rückübertragung (=cutout, grau dargestellt) ist wie folgt definiert:


Quelle: https://www.opendcc.de/info/railcom/railcom.html


Cutout der PG ohne (oben) und mit Anpassung (unten)

Ich habe festgestellt, dass die z21PG einen etwas anderen Zeitschlitz erzeugt. Die Vermutung, dass dies Ursache der spontanen Unterbrechnungen der Belegtmelders ist hat sich zwar nicht bestätigt - es hat offensichtlich keinen Einfluss. Die Anpassung ist im Code verblieben jedoch aus Performancegründen auskommentiert. Sollte es pingelige Decoder oder Besetztmelder geben, besteht die Möglichkeit es wieder reinzunehmen.

librariesDCCInterfaceMasterDCCHardware.c
//#define ISRDIVRC	//UH 2019-01-13, RCN-konformes RC-Cutout
 
 

8.
Übrigens, ein einfacher "8 Kanal Logik Analyser, CH 8 Channel USB Logic Analyzer" mit 24MHz ist sehr hilfreich. Die Saleae-Logic-Software ist super, kann von Haus aus das Async-Serial des RailCom-Signals in der Rohform (vor Decodierungstabelle) auslesen. Als Plug-In gibt es auch einen DCC-Decoder vom freundlichen Dähnen:
https://www.ejberg.dk/portfolio/saleae-dcc-decoder/

9.
Mischbetrieb von Loks mit und ohne Kanal 1 geht zwar prinzipiell. Die Auswirkunden auf das Steuerprogramm können jedoch von sehr unterschiedlicher Natur sein. Es empfiehlt sich per POM-Write auf Lok 0* CV #28= 2 zusetzen und Kanal 2 im DR5088 zu setzen oder an alle CV #28= 3 und Kanal 2 zu deaktivieren -> Kanal 1 zu nutzen.
* Ja, das geht jetzt bei der PG im Gegensatz zum Original - zumindest bei Zimo-Decodern. Bei meinem ESU gehts nicht.

10.
Das Steuerprogramm (z. B. RocRail) muss nach der Z21PG gestartet werden, da die Informationen (z. B. LocoNet-Belegtmeldungen) bei der PG abonniert werden müssen. Nach jedem Neustart der Z21PG muss (im Gegensatz zum Original) RocRail o. Ä. auch neugestartet werden.

Ich werde in den nächsten Stunden den Quellcode noch etwas aufräumen und dann an der bekannten Stelle (siehe Signatur) hochladen. Quellcode mit der NANO-Variante ist getestet.

@Andre: War schön mal zu swatzen. Aktualisiere mal Deine neue Z21-App. Bei mir gehts jetzt.

So, Schaffenspause
Viele Grüße
Uwe

Hallo Uwe,
Wow, 120 h Arbeit, deren Ergebnis sich echt sehen lassen kann.
[quote="240 007-4" post_id=1935237 time=1549140657 user_id=35172]

Die Frage ist weiterhin ob das bei der MEGA-Zentrale überhaupt sinnvoll ist (Speicher, Prozessorleistung).
[/quote]

Ich denke es macht Sinn das ganze zumindest als konfigurierbar zu begrenzen, z.B. 12, 20 etc. und eine Empfehlung für Betriebsszenarien auszusprechen.

[quote="240 007-4" post_id=1935237 time=1549140657 user_id=35172]


--------------------- Achtung ! Ab hier kommen langweilige technische Details. -----------------------------------
[/quote]

echt spannend, hast Du das Saleae Logic Original oder einen Clone?

Danke jedenfalls für die Screenshots und die Links.!

[quote="240 007-4" post_id=1935237 time=1549140657 user_id=35172]

Ich habe festgestellt, dass die z21PG einen etwas anderen Zeitschlitz erzeugt. Die Vermutung, dass dies Ursache der spontanen Unterbrechnungen der Belegtmelders ist hat sich zwar nicht bestätigt - es hat offensichtlich keinen Einfluss. Die Anpassung ist im Code verblieben jedoch aus Performancegründen auskommentiert.


Sollte es pingelige Decoder oder Besetztmelder geben, besteht die Möglichkeit es wieder reinzunehmen.

librariesDCCInterfaceMasterDCCHardware.c
//#define ISRDIVRC	//UH 2019-01-13, RCN-konformes RC-Cutout
 
 

[/quote]
Hast Du denn einen anderen Grund gefunden?

[quote="240 007-4" post_id=1935237 time=1549140657 user_id=35172]

Mischbetrieb von Loks mit und ohne Kanal 1 geht zwar prinzipiell. Die Auswirkunden auf das Steuerprogramm können jedoch von sehr unterschiedlicher Natur sein. Es empfiehlt sich per POM-Write auf Lok 0* CV #28= 2 zusetzen und Kanal 2 im DR5088 zu setzen oder an alle CV #28= 3 und Kanal 2 zu deaktivieren -> Kanal 1 zu nutzen.
* Ja, das geht jetzt bei der PG im Gegensatz zum Original - zumindest bei Zimo-Decodern. Bei meinem ESU gehts nicht.
[/quote]
Das ist Interessant! Funktioniert denn ein Broadcast z.B. zur Ein/Ausschaltung von Kanal 1 bzw. 2 bei allen Decodern? Diesen lokalen Ringspeicher in Detektoren, der in RCN-217 für Kanal 2 vorgesehen ist kennt aber das DR5088RC noch nicht?
[quote="240 007-4" post_id=1935237 time=1549140657 user_id=35172]

So, Schaffenspause
[/quote]
Danke, Du bietest uns ja reichlich zum Lesen an....

MfG

vik

Guten Morgen,

ich kann nur wieder sagen : Waaahnsinns-Arbeit.

Grüße Ingo

Hallo Vik,

Zitat

---

hast Du das Saleae Logic Original oder einen Clone?

---

Clone

Zitat

---

Hast Du denn einen anderen Grund gefunden?

---

Ja, die beiden beschriebenen Interruptprobleme (Timer0, XpressNet).

Zitat

---

Funktioniert denn ein Broadcast z.B. zur Ein/Ausschaltung von Kanal 1 bzw. 2 bei allen Decodern?

---

Wie geschrieben, bei mir nur Zimo, ESU nicht. "Alle" kann ich nicht testen da nicht alle habe
Geht auch nur mit RocRail. Die Apps weigern sich Adresse 0 anzunehmen -vielleicht auch besser so ...

Zitat

---

Diesen lokalen Ringspeicher in Detektoren, der in RCN-217 für Kanal 2 vorgesehen ist kennt aber das DR5088RC noch nicht?

---

Korrigier mich wenn ich falsch liege - ein Ringspeicher ist m. E. in der RCN-217 nicht vorgesehen und bedeutet - wie ein Bremsgenerator - das Generieren eines eingenen lokalen DCC-Signals. Dazu muss praktisch eine kleine Zentrale mit Booster im Detektor eingebaut sein, das macht m. E. keiner. Problematisch sind dann auch die Microkurzschlüsse an den Trennstellen durch unterschiedliche DCC-Signale.
Möglich wäre das sicher bei Riesen-Anlagen. Da können jedoch auch mehrere Zentralen mit Umschaltstrecken an den Übergängen genutzt werden.

Laut RCN-217 sind max 2 RC-Detektoren in Reihe zulässig - also globaler und lokaler RC-Detektor. Das bedeutet die Zentrale allein erzeugt das Signal mit CutOut inkl dem "Zentralen-Kurzschluss". Es werden dann seweils die Detektor-Widerstände (bei der PG die 0,1 Ohm) in Reihe geschaltet. Die beim RC-Senden darüber abfallende Spannung wird ausgelesen.
Ein ganz einfacher Kanal 2 (ausschließlich) Detektor müsste nur das DDC auswerten und gucken ob im RC-CutOut Teil 2 irgendwelche Bits zurückkommen ... Gänge im simpelsten Fall mit 'nem Digispark für 1€ - wenn man nur einen Abschnitt überwachen will.

Viele Grüße und einen schönen Sonntag noch
Uwe

Hallo Uwe,[quote="240 007-4" post_id=1935475 time=1549193946 user_id=35172]
.....

Ja, die beiden beschriebenen Interruptprobleme (Timer0, XpressNet).
[/quote]
D.h., wenn man die XpressNet-Lib nicht benötigt, könnte das Problem vielleicht entschärft werden?
[quote="240 007-4" post_id=1935475 time=1549193946 user_id=35172]

Zitat

---

Funktioniert denn ein Broadcast z.B. zur Ein/Ausschaltung von Kanal 1 bzw. 2 bei allen Decodern?

---

Wie geschrieben, bei mir nur Zimo, ESU nicht. "Alle" kann ich nicht testen da nicht alle habe
Geht auch nur mit RocRail. Die Apps weigern sich Adresse 0 anzunehmen -vielleicht auch besser so ...
[/quote]
Danke!
[quote="240 007-4" post_id=1935475 time=1549193946 user_id=35172]

Zitat

---

Diesen lokalen Ringspeicher in Detektoren, der in RCN-217 für Kanal 2 vorgesehen ist kennt aber das DR5088RC noch nicht?

---

Korrigier mich wenn ich falsch liege - ein Ringspeicher ist m. E. in der RCN-217 nicht vorgesehen und bedeutet - wie ein Bremsgenerator - das Generieren eines eingenen lokalen DCC-Signals. Dazu muss praktisch eine kleine Zentrale mit Booster im Detektor eingebaut sein, das macht m. E. keiner. Problematisch sind dann auch die Microkurzschlüsse an den Trennstellen durch unterschiedliche DCC-Signale.
Möglich wäre das sicher bei Riesen-Anlagen. Da können jedoch auch mehrere Zentralen mit Umschaltstrecken an den Übergängen genutzt werden.
[/quote]
Du hast Recht, das DCC-Signal müsste im Abschnitt über einen lokalen Booster wiederholt werden und dabei müssten einige DCC-Pakete für die Decoder, die sich gerade im Anschnitt befinden "on the fly" verändert werden. Da die Änderungen nur an wenigen Stellen in wenigen Paketen wären und nur im Monent der Überbrückung einer Trennstelle aufträten, halte ich das eigentlich für nicht problematisch. Das würde es aber ermöglichen Kanal 1 eines bestimmten Decoders (der z.B. noch kein Kanal 2 beherrscht) immer mal wieder kurz ein oder auszuschalten, damit er die Klappe hält oder sich meldet.
[quote="240 007-4" post_id=1935475 time=1549193946 user_id=35172]
Laut RCN-217 sind max 2 RC-Detektoren in Reihe zulässig - also globaler und lokaler RC-Detektor. Das bedeutet die Zentrale allein erzeugt das Signal mit CutOut inkl dem "Zentralen-Kurzschluss". Es werden dann jeweils die Detektor-Widerstände (bei der PG die 0,1 Ohm) in Reihe geschaltet. Die beim RC-Senden darüber abfallende Spannung wird ausgelesen.
Ein ganz einfacher Kanal 2 (ausschließlich) Detektor müsste nur das DDC auswerten und gucken ob im RC-CutOut Teil 2 irgendwelche Bits zurückkommen ...
[/quote]
Ja im Kanal 2 muss der Detektor nur die Nachrichten vom Decoder an die Zentrale "aufarbeiten".
[quote="240 007-4" post_id=1935475 time=1549193946 user_id=35172]
Gänge im simpelsten Fall mit 'nem Digispark für 1€ - wenn man nur einen Abschnitt überwachen will.
[/quote]
Hast Du so etwas für einen Abschnitt, z.B. mit einem Arduino oder ATTiny 85 schon mal erfolgreich gemacht?

Konntest Du mit Deinem Saleae Logic auch schon die Railcom-Nachrichten selbst darstellen? Falls ja, kann man die im Screenshot

tatsächlich sehen?

MfG

vik

Hallo Vik,

Zitat

---

D.h., wenn man die XpressNet-Lib nicht benötigt, könnte das Problem vielleicht entschärft werden?

---

Ja! War auch mein erster Ansatz (oder der 4., 5. 6., ...). Ist aber meiner gestern hochgeladen Version schon drin. Entschärft bei funktionierendem XpressNet !!! Da bringt das deaktivieren des XpressNet natürlich nix mehr.

Zitat

---

Hast Du so etwas für einen Abschnitt, z.B. mit einem Arduino oder ATTiny 85 schon mal erfolgreich gemacht?

---

Nein. Der Hardwareentwurf liegt in einzelnen Modulen auf dem Tisch (seit einem knappen Jahr). Da hat sich die die PG-Software zwischengedrängelt. RC-Baustein nach PG wie ich's auch meinem 1. MEGA und dem NANO spendiert habe und ein Digispark der DCC versteht ...

Zitat

---

Konntest Du mit Deinem Saleae Logic auch schon die Railcom-Nachrichten selbst darstellen? Falls ja, kann man die im Screenshot

---

Ja, allerdings nur die Rohdaten (4/8-Code). Du siehst die Werte im Channel 0 des Bildes in den blauen Kästchen (0xA3, 0xAC). Musst sie nur noch per Win-Taschenrechner in Binär wandeln (10100011, 10101100) und mit Tabelle 2 aus RCN-217 übersetzten (0x00, 0x04) und interpretieren.

Besser geht das Übersetzen aber mit dieser Tabelle:

4/8	Wert		4/8	Wert
0x0F	ACK		0x87	RES
0x17	0x33		0x8B	0x0E
0x1B	0x34		0x8D	0x0D
0x1D	0x35		0x8E	0x0C
0x1E	0x36		0x93	0x0A
0x27	0x3A		0x95	0x09
0x2B	0x3B		0x96	0x0B
0x2D	0x3C		0x99	0x08
0x2E	0x37		0x9A	0x07
0x33	0x3F		0x9C	0x06
0x35	0x3D		0xA3	0x04
0x36	0x38		0xA5	0x03
0x39	0x3E		0xA6	0x05
0x3A	0x39		0xA9	0x02
0x3C	NACK		0xAA	0x01
0x47	0x24		0xAC	0x00
0x4B	0x23		0xB1	0x0F
0x4D	0x22		0xB2	0x10
0x4E	0x21		0xB4	0x11
0x53	0x1F		0xB8	0x12
0x55	0x1E		0xC3	RES
0x56	0x20		0xC5	0x2B
0x59	0x1D		0xC6	0x30
0x5A	0x1C		0xC9	0x2A
0x5C	0x1B		0xCA	0x2F
0x63	0x19		0xCC	0x31
0x65	0x18		0xD1	0x29
0x66	0x1A		0xD2	0x2E
0x69	0x17		0xD4	0x2D
0x6A	0x16		0xD8	0x2C
0x6C	0x15		0xE1	RES
0x71	0x25		0xE2	0x28
0x72	0x14		0xE4	0x27
0x74	0x13		0xE8	0x26
0x78	0x32		0xF0	ACK
 
 

Vom ersten Byte sind nun die unteren 2 Bits mit 0x40(64) zu multiplizieren und zum 2. zu Addieren.
Das erste Byte nun durch 4 dividieren (Shift 2 Bit nach rechts) ergibt die ID nach RCN.217 Tabelle 2.

Hier nun das vollständige Beispiel (in der 2. Lücke stand 0x95, 0x65)

Ausgangswerte im Kanal 1:
(0xA3, 0xAC), (0x95, 0x65)
nach Tabelle decodieren:
(0x04, 0x00), (0x09, 0x18)
Erstes Byt /4 oder >>2:
(ID 1=app:addr_high), (ID 2 =app:addr_low)
Erstes Byt & 0x3 /4 oder >>2 (die zwei rechten/unteren Bits):
(0x00, 0x00), (0x01, 0x18)
Nun im dezimalen und erstes Byte mit 0x40(64) zu multiplizieren:
(0, 0), (64, 24)
und addieren:
(0), (88)
Tataaaaaaaaaaaa: 
Die Lok hört auf die Adresse 88!
 

Viele Grüße
Uwe

Liebe Z21-Bastler!

vor einigen Wochen hat sich die Festplatte in meinem PC mal eine Auszeit genommen, leider sind einige Pläne verloren.
Aber dank der sehr guten Arbeit von Ingo, die Seite 1, ist es jetzt leichter ein Bericht zu finden.
Danke Ingo.

Um an meiner Eigenbau Zentrale auch einmal den Booster-Anschluß zu testen, habe ich den ORD-VC1 Booster mit diesem Anschluß aufgebaut.
https://wiki.rocrail.net/doku.php?id=ord-vc-1-de

Für den ersten Test ist die MULTIMAUS als Zentrale verbunden.



Für den zweiten Test ist die kleine Zentrale angeschlossen.



Der Aufbau des Booster ist gleich der CDE-Version, neu ist der Spannungsregler 12V für den Booster-Bus und den Lüfter.
https://www.amazon.de/PEMENOL-Einstellba...words=Step+down

Die Schraubklemmen, die Stiftleiste und den Kondensator auf der H-Brücke habe ich wieder umgebaut. Den Kühlkörper danach mit zwei Glimmerscheiben (für Gehäuse TO 21 und Wärmeleitpaste wieder montiert.

Der Lüfter ist mit zwei Schrauben M2x20 und Muttern auf der Platine befestigt.
https://www.amazon.de/Brushless-Cooling-...er+40+x+40+x+10

In den Lüfteranschluss kommt noch eine Temperaturregelung.
https://www.amazon.de/L%C3%BCfter-Temper...ersteuerung+12v

Viele Grüße
Andreas

Hallo Z21-Bastler!

ich habe die Platine der Zentrale etwas geändert um den Aufbau zu verbessern.

Bild

Bild

Bild

Leider ist der Step Down Regler auch keine gute Wahl. Nach 30 min Test mit 15V Spannung, 2,9A an der Zentrale hatte er 65°C und mit 19V, 2,5A habe ich den Test bei 85°C abgebrochen.
Zwei der Dioden hatten nach 30 min. 46°C und die anderen 35°C. (SBX3030)
Das Gehäuse über dem TLE 5206 hatte 43°C, also bis auf den Spannungsregler ein gutes Ergebnis.
Fortsetzung folgt.

Viele Grüße
Andreas

gibt es das geänderte Layout bereits ?

Danke Peter

Hallo Peter,

ich hatte den Spannungsregler auf einen alten CPU-Kühler aufgebaut und bei 3A ist seine Grenze erreicht.
Es scheint kein original XL4005 zu sein. Ich werde noch einen anderen Regler testen und es wird noch eine Anpassung auf der Platine geben.
Ich möchte es erst Testen und dann die Dateien weitergeben.

Damit das Warten nicht zu langweilig wird habe ich noch ein paar Bilder.

Bild

Bild

Bild

Bild

Diese Zentrale ist noch nicht fertig aufgebaut und getestet, aber LAN, Wlan, Xpressnet und Booster haben eine erste Lokfahrt bestanden.
Abweichend von den Fotos gibt es in den Dateien für das LAN-Modul auch wieder einen Wannenstecker. Ich hatte für dieses Modul eine andere Idee, aber das ist keine so lustige Geschichte und ich bin froh das es jetzt arbeitet.
Die Platine soll in das Strapubox 5002 Universal-Gehäuse 168 x 117 x 56 eingesetzt werden.

Viele Grüße
Andreas

Hallo Uwe,

@Z21-Bastler,

danke für die sehr guten Erweiterungen für die Zentrale.
Mir ist es jetzt auch gelungen Deinen Sketch Fehlerfrei auf den Arduino zu übertragen.

Einen Test mit der Platine habe ich auch durchgeführt.
Mit einer Last von 2,6A erreicht der Alu-Block nach 30 min 58°C, am Kühlkörper sind es ca. 31°C, für das Kunststoff-Gehäuse etwas zu viel.

Bild

Bei einem zweiten Test mit 1,9A ist die Temperatur nach 30 min. an der Sole des Kühlkörper 40°C, an den Kühlrippen sind es ca.28°C.
Mit Lüftungsöffnungen sollte es möglich sein, 2A mit diesem Aufbau zu nutzen.

Bild

ich wünsche allen ein schönes Wochenende
Andreas

Danke für das aktuelle Layout
werde das mal auf der Cnc raus fräsen

aber bitte helft mir kurz
ich versteh nicht ganz was ihr schreibt mit den Amper
ist es nicht eh so das eine gewisse Anlagengrösse sowieso Booster voraus setzt.
oder würde die Zentrale trotz Booster so heiß werden ?

wird die original z21 auch so heiß?

lg
peter

Hallo Peter,

der Test soll nur zeigen wie weit man die Zentrale ohne Booster nutzen kann. Sind Booster geplant kann der Kühlkörper kleiner aufgebaut werden.
Die Dickschichtwiderstände ("D3", "D6" & "D7") sind hier mit 30 Watt aufgebaut, auch diese Bauteile können dann mit anderen Werten bestückt werden.
(CAD MP930-0.33 und CAD MP930-0.10 /Reichelt)
Mit einem kleineren Kühlkörper würde ich den Widerstand 0,33Ohm auf 0,47Ohm ändern, dann löst die Abschaltung bei einem Kurzschluß früher aus.
(bei 0,33Ohm und 15V am TLE5206-2S schaltet die Zentrale bei einem Strom von ca. 3,5A ab)
Für die Platine schreibe ich gerade an der Materialliste und lege sie dann zu den Dateien, also bitte später noch einmal reinschauen lohnt sich.

Viele Grüße
Andreas

Hallo Peter,

die Durchkontaktierung habe ich mit Hohlnieten 0,4mm gemacht. Die Bohrungen dazu sind 0,7mm, für die Bohrungen nutze ich gebrauchte Vollhartmetallbohrer.
https://www.reichelt.de/hohlnieten-fuer-...100391.html?r=1
http://www.lerrox.de/bohrer/bohrer-gebraucht/index.php

Ich habe LeRROX auch mit einem Stand auf der Messe modell-hobby-spiel in Leipzig gesehen.
Ein Bekannter von mir nutzt hier auch gern die Zweischneider Fräser.

An den Kondensatoren und an dem Wannenstecker sind es Nieten ø 1,0 mm, die Bohrungen waren bei mir 1,5mm.
Einige Verbindungen habe ich auch mit dem Bauteil selbst hergestellt, (z.B am TLE5206-2S) wo ich mit der Lötnadel gut arbeiten konnte.
Für den Einbau der Nieten nutze ich einen abgebrochenen Bohrer ø 0,4mm.

Viele Grüße
Andreas

Hallo Z21-Bastler!

Ist die Zentrale später viel Unterwegs, sollte der Optokoppler und das Wlan-Modul mit etwas Heißkleber befestigt werden.
(z.B. an den Stiftleisten eine Klebestelle anbringen)
Wird die Zentrale ohne Display aufgebaut, kann der Sketch von Philipp Gahtow genutzt werden. (ohne jede Veränderung)

Mit Display ist der Sketch von Uwe auf dem Arduino. Hier können die Werte für die Temperatur-, Strom- und Spannungsanzeige,
z.B. in Rocrail, noch im Sketch eingestellt werden. (vor dem Einbau in das Gehäuse bitte testen)

Danke Uwe, dass Du für uns diese sehr gute Programmierarbeit zur Verfügung stellst.

Für die Bearbeitung des Gehäuse stelle ich die Platine mit Distanzhülsen (ca. 42mm) in das Unterteil.

Bild

Auf dem Tesakrepp kann dann auf einer planen Fläche mit einem Winkel die Lage der Buchsen usw. angezeichnet werden.
Mit einer Laubsäge habe ich die Öffnungen grob ausgeschnitten und mit einer Feile nachgearbeitet

Bild

Um die Platine in das Gehäuse einzusetzen, die Platine mit der Rückseite zuerst in das Gehäuse einführen.
Dann die Vorderseite vom Gehäuse etwas nach außen drücken und die Platine rutscht in das Unterteil.

Bild

Jetzt können noch Lüftungsöffnungen z.B seitlich in das Oberteil gebohrt werden und die Beschriftung fehlt noch.
In zwei Bilder habe ich mal etwas Text eingefügt.
Befestigt wird die Platine durch das Verschrauben der Gehäuseteile.

Bild

Bild

Bild

Bild

Bild

Viel Spaß beim Basteln wünscht euch
Andreas

sieht richtig schick aus !

Grüße Ingo