Hallo Uwe,

meine Anlage ist kein Großprojekt . Ich wollte allerdings die Nummern 1-32 für S88 Rückmelder reservieren, das ist schwierig, da diese Nummern auch von den Railcomdetektoren belegt werden.

[quote="240 007-4" post_id=2203211 time=1607457491 user_id=35172]
Größer 64 bedeutet mehr als 4x 16er Platinen oder 8x 8er richtig ?
[/quote]

Hallo Uwe,

irgendwie bin ich grad blind. Wo finde ich denn Deine 16er-Variante?

Zitat

---

Die zweite Meldung ist eine normale Belegtmeldung, hier wird nur bis Adresse 64 korrekt ausgegeben (nicht bis Adresse 80 wie irrtümlich in einem meiner letzten Beiträge angegeben), 65 wird wieder "1" rückgemeldet, usw. Leider reichen meine Programmierkentnisse nicht aus, um den Bug in dem Sketch zu lösen.

---

Vielleicht will dies hier ja mal jemand probieren, hab leider den Aufbau der Schaltung nicht und kann es nicht testen.
Im Sketch wird zur Rückmeldung (Besetztmeldung) das Packet für Loconet selbst erzeugt. Hier liegt auch der Fehler bei den Bytes IN1 und IN2. Die LocoNet Bibliothek bietet hier schon komfortable eine fertige Funktion an:

LN_STATUS LocoNetClass::reportSensor( uint16_t Address, uint8_t State )
 

Diese einfach mal das hier:

LocoNet.reportSensor((i*INVERTBLOCKADDR + FIRSTBLOCKADDR - 1), (0x01 * ((belegt & (1 << i)) != 0)) );
 

dort einfügen und bestehende Zeilen auskommentieren. Im Sketch findet sich dies ab Zeile 1438 ("RCdec-nano-test40_LCD_OLED") und sollte dann wie folgt aussehen:

#if defined(LOCONET)
  for (int i = 0; i < BLOCKANZ; i++) {
    lnMsg SendPacket ;
 
    if(belegtInitDelay<250) belegtInitDelay++;
 
    if ( ((belegtOld & (1 << i)) !=  (belegt & (1 << i)))            //Belegung geaendert ?
       ||((belegtInit & (1 << i)) != 0)&&(belegtInitDelay>=250)  ) { //aktueller Zustand noch nicht gemeldet 2019-12-22
      belegtInit = belegtInit & ~(1 << i);
      
      //SendPacket.data[ 0 ] = 0xB2 ;
      //SendPacket.data[ 1 ] = (((i*INVERTBLOCKADDR + FIRSTBLOCKADDR - 1) / 2) & 0x1F) ; //LN Sensor/2   =0x00 = 2, 0x01 = 4, 0x02 = 6, 0x03 = 8
      //SendPacket.data[ 2 ] = 0x40 + (0x10 * ((belegt & (1 << i)) != 0)) + 0x20 * ((i*INVERTBLOCKADDR + FIRSTBLOCKADDR - 1) % 2); //LN Sensor + on/off + "Adresse+1"
 
      //LocoNet.send( &SendPacket ) ;  //checksum wird automatisch berechnet
      //LocoNet_sendX( &SendPacket ) ;  //checksum wird automatisch berechnet
 
      LocoNet.reportSensor((i*INVERTBLOCKADDR + FIRSTBLOCKADDR - 1), (0x01 * ((belegt & (1 << i)) != 0)) );
    }
  }
#endif
 

Hallo Philipp,

die von Dir vorgeschlagene Änderung habe ich mal ausprobiert. Danach war die Nummer des belegten Blocks immer um eins kleiner als die Railcombelegtnummer. Ich habe daraufhin deine Programmzeile geringfügig modifiziert:

LocoNet.reportSensor((i*INVERTBLOCKADDR + FIRSTBLOCKADDR), (0x01 * ((belegt & (1 << i)) != 0)) );

Jetzt stimmen die Nummern überein.

Vielen Dank nochmal!

Die neueste Version V4.85 der Software für die Zentrale habe ich jetzt mal aufgespielt, nachdem ich die Temperaturauswertung an meine Hardware angepaßt hatte.

Leider werden Loks auf dem Hauptgleis immer noch mitprogrammiert bei Programmierung einer Lok auf dem Programmiergleis. Glücklicherweise hatte ich nur eine Lok auf dem Hauptgleis, es war aber reproduzierbar.

Hallo.

Danke an Philipp und Ralf! Ich wäre mangels zugänglicher Hardware erst nächste Woche dazugekommen.
Schön das mein "Versuch" läuft

Zitat

---

Jetzt stimmen die Nummern überein.

---

Ich werd´s bei Gelegenheit mal mit einbauen und hochladen.

Viele Grüße und einen schönen 3. Advent

Uwe

Ralf,

das Programiergleis funktioniert doch so, dass das Hauptgleis per Relais während des Programmierens abgeschaltet wird. Klappert denn Dein Relais überhaupt?

Zitat

---

Leider werden Loks auf dem Hauptgleis immer noch mitprogrammiert bei Programmierung einer Lok auf dem Programmiergleis. Glücklicherweise hatte ich nur eine Lok auf dem Hauptgleis, es war aber reproduzierbar.

---

Franz,

ja, das Relais klappert munter vor sich hin Auslesen auf dem Programmiergleis ist auch kein Problem. Leider wird auch jeder Dekoder auf dem Hauptgleis mitprogrammiert.

Irgendwo da muss der Hase begraben sein... Fast so als ob das Relais nicht erfolgreich schaltet... Eigentlich sollte es wohl idealerweise nicht ständig hin und her schalten, aber bei mir macht es das auch. Ich habe meine Zentrale aber noch voll in Betrieb.

Es gibt nur die Möglichkeit, dass meine Hardware defekt ist oder das der Fehler in der Software liegt.
Einfach mal eine Lok auf das Programmiergleis stellen und eine zweite Lok auf das Hauptgleis, dann eine CV verändern.

Kannst ja mal probieren und berichten.

Hallo
das klappernde Relais hatte ich auch,
meiner Meinung nach startet der Programmiervorgang etwas zu schnell, da ist das Relais noch nicht richtig angezogen und das Hauptgleis ist noch nicht getrennt. Das führt zum Fehlerfall.
Ich habe an der passenden Stelle ( //POWER set configuration: ) die Zeile "delay" (eine kleine Pause) eingefügt. Damit läuft auf meiner Zentrale die Programmierung tadellos.

break;
case csServiceMode:
#if defined(DCC)
dcc.setpower(SERVICE); //already on!
digitalWrite(ProgRelaisPin, HIGH);
delay(100); //ProgTrack
#endif
#if defined(BOOSTER_EXT)
#if defined(BOOSTER_INT)
digitalWrite(GoExtPin, BOOSTER_EXT_OFF);
#else
if (digitalRead(ShortExtPin) == LOW)
digitalWrite(GoExtPin, BOOSTER_EXT_ON);
#endif
#endif

Wo finde ich deine Beschreibung wie man den Programmcode in dem kleinen Fenster darstellt?

Das mit dem Delay für die Verzögerung des Relais ist sehr unglücklich und kann Auswirkungen auf alle Interface mit sich ziehen.
Ich denke eher, dass es am Relais Typ liegt. Denn ich habe extra nachdem die Hinweise aufgekommen sind das Relais schaltet zu spät, die DCC Bibliothek angepasst. Zu lange kann leider aber auch hier im Code nicht auf das Relais gewartet werden.
Das Klappern des Relais kommt daher das Teils die Erkennung des ACK Signal je nach Dekoder nicht immer eindeutig ist und mehrfach gelesen wird und die Zentrale wieder in den “normalen” Betrieb schaltet. Vielleicht kann man hier den Timeout verkürzen, damit das Relais nicht mehr klappert. Aber das könnte auch die Erkennung beeinflussen.

Hallo Bastler,

Mit der Zentrale habe ich noch einen Lasttest durchgeführt.
Für den Test habe ich einen Kühlkörper 80mm x 40mm x 40mm und ein kleinen Lüfter an dem L6203 und den Dickschichtwiderständen 30 W befestigt.
Das Netzteil ist ein Notebook Schaltnetzteil 19,5V bis 3,3 Ampere.

Der Lüfter ist ein Noctua NF-A4 x20 PWM, (40x40x20 mm, 12V, 4-Pin Molex)
Die Platine hat durch den Kühlkörper die Maße ca. 200mm x 100mm.

Passt auf euch auf und bleibt gesund!

Viele Grüße
Andreas

Hallo,
ich habe festgestellt, daß mein Tablet jetzt zu Verbindungsabbrüchen des WLAN führt, sobald ich eine Weiche im Stellwerk schalte (Samsung Tab A, Android 10). Da hilft dann nur ein Neustart der Zentrale. Vor dem Update hatte ich das Problem nicht. Irgend jemand mit dem gleichen Problem?

Hallo Bastler,

für einen weiteren Test ist ein Netzteil 15V/5A angeschlossen. Die Verbraucher am Gleisanschluss habe ich auf ca. 3,5A geändert.
Die Temperatur am Kühlkörper ist nach 10 min. 36°C, nach 20 min. 37°C und auch nach 30 min. steht die Temperatur bei 37°C.

In Rocrail wird 15V und 3,31A angezeigt.
Der Sketch auf dem Arduino ist die Version 4.80.

Viele Grüße
Andreas

Hi, hat jemand zufällig noch eine Platine/Teile übrig?

vielen Dank!

Grüße,

Patrick

Hello Andreas

In your post 1450 you put 2 schemes: the booster with the new CI L6203 and the general design,
but the booster scheme is different from the one in the general design.
Which scheme should I follow for the internal booster?

Regards

Frank

Hallo Frank,

mit dem Trimmer kann die Anzeige der Spannung in z.B. Rocrail eingestellt werden.
Der Trimmer ist auf 5 Kohm voreingestellt, dann kann die Eingangsspannung an der Zentrale ohne Last gemessen werden und die Anzeige eingestellt werden. Die Zentrale kann auch mit dem 4,7 Kohm Widerstand genutzt werden.

Grüße,

Andreas

Update: Railcom auslesen getestet

Hallo,

ich bin jetzt stolzer Benutzer einer von Andre (murdok1980) super sauber gebauten Z21PG mit dem Platinenlayout von Andreas (andreas21) und natürlich dem Design von Philipp, danke euch allen tausend mal dafür!

Jetzt habe auch erfolgreich (ausser Loconet, siehe unten) die 4.85 aufgespielt.

Ein paar Probleme habe ich noch:

• Das Programmieren bzw. Auslesen von CVs funktioniert nicht vollständig zuverlässig. Getest habe ich sowohl mit der z21 App als auch mit jmri DecoderPro und Rocrail. Alle getesteten Loks ruckeln fröhlich, aber das Auslesen funktioniert nur in weniger als der Hälfte der Fälle. Ich fahre H0m mit Bemo-Loks, die haben relativ kleine Motoren mit geringer Stromaufnahme. Mit zwei meiner Loks mit 5-Pol Motoren funktioniert das Auslesen zuverlässiger (80%), mit den 3-Polern nur in einem von drei Fällen. Die Time-outs (?) bringen dabei die z21 App regelmäßig zum Abstürzen und [url="https://www.jmri.org/help/en/html/tools/programmer/messages.shtml"]DecoderPro meldet dann[/url] "310 - Sequence Error: For some reason, the programming operation ended early and the command station returned to normal mode (left service mode) before it should have."
  Mein Verdacht ist, dass die Ansprechschwelle für die Rückmeldung zu niedrig ist, da die Loks nicht so viel Strom aufnehmen. Kann ich das irgendwo einstellen im Code? Gleisspannung ist 19V.
• Railcom auslesen funktioniert auch nicht ganz zuverlässig, getestet mit z21 App. [s]Erst ging es, jetzt irgendwie gar nicht mehr. Muss ich noch mehr systematisch testen.[/s] Update: Railcom auslesen hat das gleiche Problem wie CV: Die Dreipoler geben alle nichts zurück, die 5-Poler lassen sich zuverlässig auslesen. Alle haben aktuelle ZIMO-Dekoder.
• Im Loconet-Dispatch ist ein Bug in der 4.85. Mit der Version, die mir Andre draufgespielt hatte (wahrscheinlich 4.80) funktionierte alles. Jetzt werden dem Fredi aber die falschen Lokadressen angewiesen. Dabei scheint es so, also würden nur die unteren 7 Bit der Lokadresse verwendet. Getestet habe ich, sowohl mit Rocrail als auch der z21 App, welche Lokadresse freigeben wurde und welche der Fredi erhalten hat: 58 > 58 (stimmt also), 203 > 75, 407 > 23, 511 > 127, 608 > 96, 621 > 109, 2436 > 4. Also immer die unteren 7 Bit der Adresse. Vielleicht eine Variable falsch definiert? Kann das jemand auf Anhieb finden? Sonst muss ich mal in den Quellcode einsteigen...

Hallo Franz, bei den Problemen am Programmiergleis und bei RailCom bitte zuerst mal die Spannungsversorgung prüfen. Zuerst ein anderes Netzteil verwenden, dann sicherstellen das die verwendeten Regler eine wirklich stabile und lineare Spannung erzeugen.
Normalerweise ist egal was für ein Motor verbaut ist die Stromaufnahme in der DCC Norm festgelegt und daher ist die verwendete Baugröße auch nicht relevant.
Mit dem Dispatch Adressen schaue ich mir im Quellcode an. Ich teste meist auch nur die Adressen unter 100!

Hallo Philipp,

danke, werde ich gleich ausprobieren - da hätte ich auch selbst drauf kommen können.

Der Dispatch hat wie gesagt in der vorherigen Version funktioniert, und ich habe es auch mit hohen Adressen erfolgreich probiert.

Hallo,

ich habe es mit einem anderen Netzteil getestet, CV auslesen ist etwas zuverlässiger aber noch nicht perfekt, Railcom das gleiche wie vorher. Leider habe ich keine Ausrüstung (oszi) um die Netzteile zu testen. Es sind natürlich beides Schaltnetztteile. SInd das Problem denn wohl die hochfrequenten Anteile oder die Spannungsstabilität bei den Auslesepulsen?

Hat jemand einen Tipp, wie ich die Spannungen glätten könnte (Tiefpass?). Sonst muss ich mir aus einem alten Märklintrafo ein Gleichsspannungsnetzteil bauen.

Hallo Franz,

hast du es mit dem Sketch v.4.80 getestet?
Wenn möglich nutze ein Schaltnetzteil mit 14V - 16V.
Warum nutzt du 19V?

(Zitat von Tillig, Dampflok BR99.22 H0m)
"Bitte prüfen Sie vor inbetriebnahme der Lok die Spannung an ihrer Digitalzentrale. Für den Betrieb von Fahrzeugen der Spurweiten TT, H0, H0e und H0m wird eine Digitalspannung von max. 14 Volt empfohlen. Höhere Spannungen führen zu einem höheren Verschleiß der Motoren. Decoderdefekte (durch Überlast), die durch diese Ursache entstehen, fallen nicht unter die Gewährleistung."


Viele Grüße
Andreas

Hallo Andreas,

danke. Ja, mit der 4.80 war es das gleiche was CV und Railcom betrifft, Loconet ging wie gesagt.

Ich habe zunächst 16V verwendet, aus den von Dir genannten Gründen, dann auf 19V geändert, da ich ausprobieren wollte, ob ich da eine sicherere Auslesung hinbekomme. In allen Fällen machte die Spannung keinen Unterschied. Ich kann nochmal suchen gehen, ob ich ein Netzteil mit 14V finde.

Hallo Franz,

ich bin der Meinung, dass es nicht am Netzteil liegt.
Auch mit meiner Platine aus dem letzten Test, konnte ich bei 19,5V und mit 15V CVs lesen und schreiben.
Es funktioniert auch schon mit 12V, zum Testen z.B. mit deinen Loks.

Meine Spur N Loks sind etwas zu leicht für das Programmiergleis und es braucht schon mal einen 2. Versuch.
Das Lesen & Schreiben, "Programmierung auf dem Hauptgleis", funktioniert mit der Zentrale und der App sehr gut.
Ich nutze dazu noch den Sketch v. 4.80.

Wenn du vielleicht einen anderen Arduino Mega testen kannst, damit würde ich die Suche beginnen.
Am Sketch von Philipp habe ich für die Zentrale keine Änderungen vorgenommen. (v. 4.80 & v. 4.85)

Viele Grüße
Andreas