[Sigg]

Jetzt habe ich es kapiert, "refresh_loco_one" ist korrigiert, wenn ein Protokoll (MFX odr DCC) aktiviert ist, aber keine Lok vorhanden ist, wird nun mit dem nächsten Protokoll weiter gemacht und nicht für immer und ewig kein Refresh mehr gesendet.
Update steht am üblichen Ort bereit: http://siggsoftware.ch/wordpress/srcpd-m...-erweiterungen/

Gruss Dani

[Rainer Müller]

Hallo Mitleser,

Zitat

---

Jetzt habe ich es kapiert, "refresh_loco_one" ist korrigiert, wenn ein Protokoll (MFX odr DCC) aktiviert ist, aber keine Lok vorhanden ist, wird nun mit dem nächsten Protokoll weiter gemacht und nicht für immer und ewig kein Refresh mehr gesendet.
Update steht am üblichen Ort bereit: http://siggsoftware.ch/wordpress/srcpd-m...-erweiterungen/

Gruss Dani

---

danke für das Update, habe ich bei mir mit reingenommen.

Nachdem ich in der Zwischenzeit beim Testen bin und auch die Kurzschlussabschaltung jetzt aktiv ist, mal ein Bild zum Anschluss des Boosters an den BaPi:

Am Sub-D9 habe ich folgende Signale:
- TXD gibt die Polarität des Schienensignals (pos. -> Mittelleiter pos.)
- RTS schaltet den Booster ein wenn positiv
- RXD wird z.Zt. nicht genutzt
- CTS zeigt an, dass Booster OK wenn positives Potential angelegt wird

und BaPi-seitig jeweils: Steckerpin / Port / Funktion


Ursprünglich wollte ich den RS232-Treiber mit 5V versorgen um die 3V3 zu schonen. Aber da die BaPi-Entwickler beim Runterfahren nur die 3V3 abschalten und die 5V anlassen, gibts da komische Potentiale: im Ergebnis Plus am Mittelleiter, so dass alle Loks (ohne deaktivierbaren Analogbetrieb) losrasten bis der Stecker gezogen wurde . Nach Änderung der Versorgung auf 3V3 tritt dieses Phänomen nicht mehr auf.

Gruß
Rainer

[Rainer Müller]

Hallo Gerd und weitere Mitleser,

den für den BPi angepassten Quellcode kann man hier erhalten. Allerdings ist da noch Nacharbeit und Optimierung notwendig, erstmal soll er nur zeigen, dass das Prinzip funktioniert.
Angedachte Aktivitäten sind z.B.:
- Rausschmeissen von "totem Code" zur Übersichtlichkeit (z.B. zur Ansteuerung von COM-Ports in PCs)
- Interface des DDL-Teils überarbeiten damit nicht nur das srcp zur Steuerung unterstützt wird
- ...

Eigentlich wollte ich das bisher unter Armbian 5.31 entwickelte srcpd auch testweise auf Lede bringen und hatte mir Gerds Lede-Image vom 17. August geholt (einfach Ausschalten ohne Runterfahren ist toll). Dass ich da nicht bis ans Ziel komme war klar, schließlich fehlen dort der SPI-Treiber und die Pin-Konfigurationsanpassungen.

Ein Rüberkopieren von ausführbaren Binärdateien klappte nicht wegen der Abhängigkeiten, also habe ich den gcc nachinstalliert zum Compilieren auf dem Zielsystem. Aber selbst kleinste Programme gingen nicht ohne Änderungen, so muss man wegen Native gcc uses softfp by default, should be hardfp jeden gcc-Aufruf mit "-mfloat-abi=hard" garnieren.
Damit und mit der Installation einiger weiterer Pakete aus dem Lede-Pool lassen sich alle Dateien im basrcpd compilieren. Beim Linken dann findet der Linker in der libxml2 leider die dort enthaltenen Symbole nicht und bemängelt unzählige "undefined references" auf die libxml2-Symbole. Ein Austausch gegen die libxml2 von Armbian zeigt, dass es wohl an der lib liegt, führt aber zu neuen Versionsproblemen.
Man kann sich natürlich auch fragen, wieso die Konfigurationsdatei ausgerechnet im xml-Stil aufgebaut sein muss, insbesondere wenn man die Konfiguration auch über die Weboberfläche ermöglichen will.

[quote="Rainer Müller" post_id=1740559 time=1508951978 user_id=1332]
Mein Analyseprogramm muss ich jetzt nachbessern, das hat ein Problem mit mfx-Paketen ganz dicht hinter DCC-Paketen.
[/quote]
Das ist hier nachgezogen.


Gruß
Rainer

[Rainer Müller]

Hallo,

für alle, die die BananaPi-SW selbst aus den Quelldateien erzeugen wollen, gibts jetzt bei mir die Nikolausedition. Sie beinhaltet vorzugsweise das Ausmisten von unbenutztem historischem Code und Konfigurationsoptionen ohne wesentlichen funktionalen Einfluss. Enthalten sind auch die Änderungen, die Gerd für die Lede-Anpassung eingebracht hat.

Zur Anpassung an die Zentralenkonfiguration hat der Parameter "enable_checkshort_checking" in der Konfigurationsdatei jetzt die Möglichkeiten: no / yes / inverse
- no = keine Kuzschlussabschaltung, CTS wird nicht beachtet
- yes = erwartet positives Signal auf CTS für Betrieb (nach Inverter CTS2 = GND)
- inverse = erwartet negatives Signal auf CTS für Betrieb (nach Inverter CTS2 = VCC)

Diverse andere Parameter (aus der "DCC mit UART"-Optimierungskiste) sind entfallen, da sie für die SPI-Version nicht mehr benötigt werden.

Hinzugekommen ist beim Programmaufruf die "p"-Option, die Logausgaben parallel sofort auf der Konsole ausgibt, also z.B.:
srcpd -np

Weiterhin bastle ich an einem rudimentären Webauftritt, der alle Info zusammenfassen soll.


Gruß
Rainer

[Rainer Müller]

Hallo alle,

es geht weiter, zwar nicht mit neuem Code, sondern mit den Testergebnissen des bestehenden.
Getestet habe ich mit einem modifizierten dtcltiny als srcp-Client.

MM1 und MM2 sehen mit der Analysesoftware ordentlich aus, und die entsprechend angesteuerten Loks arbeiten korrekt.

DCC ist laut Analysesoftware OK, ein etwas angestaubter LoPi1 im Prüfstand lässt sich steuern.
Programmierung im Hauptgleismodus sieht laut Analyse im Bytemodus (Schreiben 0x22 ins CV 32) so aus:

1
2
3
4
5
6
7
8
9
10
 

   2142 ms: DCC Pr.15, Daten: c0 1e 80 5e(OK)  L 30 FG1:0
   2154 ms: DCC Pr.51, Daten: c0 1e a0 7e(OK)  L 30 FG2B:0
*  2163 ms: DCC Pr.15, Daten: 1e ec 1f 22 cf(OK)  K 30 POM CV = 32, WRI 22
   2173 ms: DCC Pr.15, Daten: ff 00 ff(OK) *IDLE*
*  2185 ms: DCC Pr.15, Daten: 1e ec 1f 22 cf(OK)  K 30 POM CV = 32, WRI 22
   2195 ms: MFX A07:5 Ping an Decoder 0x1E240  +0011+
   2222 ms: MFX A07:0 Such mit 0 Bits von Id-Maske 0x0   +0011+
   2249 ms: DCC Pr.15, Daten: 01 40 41(OK)  K  1 S+D:R 0
 
 

und hier noch der Bitmodus (Setzen von Bit 3 im CV 29):

1
2
3
4
5
6
7
8
9
 

   2382 ms: DCC Pr.15, Daten: c0 1e 80 5e(OK)  L 30 FG1:0
   2394 ms: DCC Pr.51, Daten: c0 1e a0 7e(OK)  L 30 FG2B:0
*  2403 ms: DCC Pr.15, Daten: 1e e8 1c fb 11(OK)  K 30 POM CV = 29, BIT 3 WRI 1
   2414 ms: DCC Pr.15, Daten: ff 00 ff(OK) *IDLE*
*  2420 ms: DCC Pr.15, Daten: 1e e8 1c fb 11(OK)  K 30 POM CV = 29, BIT 3 WRI 1
   2430 ms: DCC Pr.15, Daten: 01 40 41(OK)  K  1 S+D:R 0
   2438 ms: DCC Pr.15, Daten: ff 00 ff(OK) *IDLE*
 
 

Probleme bereitet dagegen der Programmiergleismodus, der zwar im Protokoll definiert ist, aber z.B. eine Auswertung zum Ansteuern eines Umschalters noch nie im srcpd realisiert war. Zusätzlich ist die Paketerzeugung für die Untermodi im basrcpd noch nicht von UART auf SPI umgestellt.
Die Parameterprüfung könnte auch noch besser sein, so führt z.B. ein BIT auf 7 zu setzen zu einem OK, ebenso das 9te von 8 zu modifizieren!

mfx ist ewas aufwändiger zu testen, da es normalerweise von srcp-Clients nicht unterstützt wird, und die Anmelde-HW für das Projekt noch nicht definiert ist.
Hier die Adresszuweisung (5) für einen mfx-Decoder:

1
2
3
4
5
6
7
8
9
10
11
12
13
 

   3812 ms: DCC Pr.15, Daten: 01 40 41(OK)  K  1 S+D:R 0
   3821 ms: MFX A07:5 V3:0 F16:0 
   3828 ms: MFX A07:5 V3:0 F16:0 
   3839 ms: MM1 A= 60, F=0, D= 0  <REP> <REP> <REP>
   3867 ms: MFX A07:5 Ping an Decoder 0x1E240  +0011+
*  3894 ms: MFX A07:0 Neue Adresse 5 fuer Decoder mit Id 0x1E240 
*  3903 ms: MFX A07:0 Neue Adresse 5 fuer Decoder mit Id 0x1E240 
   3913 ms: MFX A07:0 Such mit 0 Bits von Id-Maske 0x0   +0011+
   3944 ms: MM2 A= 16, F=0, D= 0, X=13 R      <REP>
   3958 ms: MM2 A= 16, F=0, D= 0, X= 4 F2 aus <REP>
   3972 ms: DCC Pr.15, Daten: c0 1e 40 9e(OK)  L 30 S+D:R 0
 
 

und noch die Fahrbefehle an ihn:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 

   1838 ms: DCC Pr.15, Daten: 01 40 41(OK)  K  1 S+D:R 0
   1854 ms: MM1 A= 60, F=0, D= 0  <REP> <REP> <REP>
*  1882 ms: MFX A07:5 V7:3 F16:0 
*  1890 ms: MFX A07:5 V7:3 F16:0 
   1898 ms: MFX A07:5 Ping an Decoder 0x1E240  +0011+
   1924 ms: MFX A07:0 Such mit 0 Bits von Id-Maske 0x0   +0011+
*  1952 ms: MFX A07:5 V7:3 F16:0 
*  1960 ms: MFX A07:5 V7:3 F16:0 
*  1968 ms: MFX A07:5 V7:4 F16:0 
*  1975 ms: MFX A07:5 V7:4 F16:0 
   1986 ms: MM2 A= 16, F=0, D= 0, X=13 R      <REP>
   2000 ms: MM2 A= 16, F=0, D= 0, X= 3 F1 aus <REP>
   2014 ms: DCC Pr.15, Daten: c0 1e 40 9e(OK)  L 30 S+D:R 0
 
 

Ob das periodische Wiederholen der Adresszuweisung alle 11s durch den Server sinnvoll ist? Im Decoder kann das je nach Speichertechnologie und Intelligenz der Speicherroutine auch zu schneller Zellalterung führen.

Gruß
Rainer

[Sigg]

Hallo Rainer
Zur periodischen Wiederholung der MFX Adresszuweisung:
Ich habe bei mir nur das DCC Programmiergleis mit MFX Rückmeldung ausgestattet.
Da ich 3 Booster im Einsatz habe war mir der Aufwand, diese Rückmeldung über die ganze Anlage zu haben, zu gross.
Dazu kommt, dass die Störungen duch die Umschaltung der Boosterspannung immer schlimmer werden (trotz Gleichrichter vor Trafo), je grösser der Fahrstrom wird. Auf dem Prog.Gleis befindet sich normalerweise genau ein Fahrzeug, was mir die Sache wesentlich einfacher gemacht hat.
Grosser Nachteil ist natürlich, dass ein Fahrzeug, dass die Adresszuordung "vergessen" hat (war auf anderer Anlage, hatte gerade kein Strom als der Neuanmeldezähler inkrementiert wurde) damit nie mehr neu angemeldet werden konnte, es extra auf das Programmiergleis musste.
Dieses Problem habe ich mit dem periodischen Versenden der Adresszuordung umgangen.
Ich hoffe natürlich, dass die Dekoder so schlau sind und merken, wenn eine Adresszuordnung noch gleich ist.
Eine andere Möglichkeit wäre noch die Adresszuordung durch den SRCP Client bei Bedarf auszulösen. Das müsste aber noch ins SRCP Protokoll.

Gruss
Dani

[Rainer Müller]

Hallo Dani,

Zitat

---

Hallo Rainer
Zur periodischen Wiederholung der MFX Adresszuweisung:
...
Dieses Problem habe ich mit dem periodischen Versenden der Adresszuordung umgangen.
Ich hoffe natürlich, dass die Dekoder so schlau sind und merken, wenn eine Adresszuordnung noch gleich ist.

---

Das hoffe ich zwar auch, aber nachdem jetzt dann mit Esu, Märklin, bald evtl. Uhlenbrock und Piko vier verschiedene Hersteller zugange sind, ist die Möglichkeit groß, dass einer was anders macht.

Zitat

---

Eine andere Möglichkeit wäre noch die Adresszuordung durch den SRCP Client bei Bedarf auszulösen. Das müsste aber noch ins SRCP Protokoll.

Gruss
Dani

---

Bei Märklin darf laut der Protokollspezifikation nur das Masterbediengerät "MFX Verify", "MFX Bind" usw. auslösen, was bei SRCP der Client wäre. Da hast du eine andere Aufgabenteilung eingebaut mit einem selbstständigeren srcpd. Ich muss mir mal die Vor- und Nachteile überlegen vor ich da was ändere; vom offiziell spezifizierten SRCP sind wir eh schon weg.

Gruß
Rainer

[Sigg]

Hallo zusammen
Habe in meiner srcpd Implementierung nun das Thema MFX Adresszuordnung geändert.
Diese wird nun nicht mehr konstant repetiert sondern jeweils einmalig nach einem Power-Up (Booster-Go) sowie bei Empfang eines SRCP Lok-Init Kommandos gesendet. Somit kann ein SRCP Client die Adresszuordnung bewusst (auch mehrfach) auslösen.
Denke, damit sollten die Lokdekoder, auch wenn sie so blöde implementiert sind, dass sie immer wieder neu speichern, kein Problem mehr haben.

Gruss
Dani

[Rainer Müller]

Hallo,

für den basrcpd gibt es mal wieder ein Update .
Wichtigste der Änderungen ist die Möglichkeit der mfx-Adresszuweisung via SRCP ("MFX Bind").

[quote="Rainer Müller" post_id=1782551 time=1516388784 user_id=1332]
...

Zitat von Sigg im Beitrag Gleissignalerzeugung mit BananaPi

---

Eine andere Möglichkeit wäre noch die Adresszuordung durch den SRCP Client bei Bedarf auszulösen. Das müsste aber noch ins SRCP Protokoll.

Gruss
Dani

---

Bei Märklin darf laut der Protokollspezifikation nur das Masterbediengerät "MFX Verify", "MFX Bind" usw. auslösen, was bei SRCP der Client wäre. Da hast du eine andere Aufgabenteilung eingebaut mit einem selbstständigeren srcpd. Ich muss mir mal die Vor- und Nachteile überlegen vor ich da was ändere; vom offiziell spezifizierten SRCP sind wir eh schon weg.
[/quote]

Ich habe mich dafür entschieden, ablaufmäßig möglichst dicht an der MCS-Protokollspezifikation zu bleiben, um möglichst einfach sowohl CAN- als auch SRCP-Clients abfangen zu können; die Adresszuweisung erfolgt nur noch auf Anforderung und nicht mehr periodisch.

Das neue hinzukommende SRCP-Kommando mfx-Bind hat die Syntax:

1
2
3
4
5
6
7
 

> SET <bus> SM <addr> BIND <lokUid>
 
beispielsweise so:
> SET 1 SM 5 BIND 4294927222
< 1529570199.368 200 OK
 
 

entspricht funktional genau folgendem CAN-Kommando:

1
2
3
4
 

> 17:48:09.883   CAN  0x00040300  [6] FF FF 63 76 00 05       MFX Bind: MFX UID 0xFFFF6376 MFX SID 5
< 17:48:09.886   CAN  0x00050300  [6] FF FF 63 76 00 05       MFX Bind: MFX UID 0xFFFF6376 MFX SID 5
 
 

Die Signalanalyse zeigt dann:

1
2
3
4
5
6
 

...
2171 ms: MFX A07:0 Neue Adresse 5 fuer Decoder mit Id 0xFFFF6376 
2181 ms: MFX A07:0 Neue Adresse 5 fuer Decoder mit Id 0xFFFF6376 
...
 
 

Eine Abfrage mit

1
2
3
4
5
6
7
8
9
10
11
 

> VERIFY <bus> SM <addr> BIND <lokUid>
 
also im konkreten Beispiel:
> VERIFY 1 SM 5 BIND 4294927222
< 1529570209.011 200 OK
 
beziehungsweise 
> 17:48:09.909   CAN  0x00060300  [6] FF FF 63 76 00 05       MFX Verify: MFX UID 0xFFFF6376 MFX SID 5
< 17:48:09.915   CAN  0x00070300  [7] FF FF 63 76 00 05 7B    MFX Verify: MFX UID 0xFFFF6376 MFX SID 5 ASK-Verhältnis 123
 
 

wird z.Zt. mangels mfx-Rückmeldehardware stets positiv beantwortet.

Damit lassen sich jetzt mfx-Decoder über beide Arten von Clients erfolgreich bedienen.

Gruß
Rainer

[Rainer Müller]

Hallo,

noch als Ergänzung zu meinem letzten Beitrag die Liste der offenen Punkte:

mfx-Rückmeldung
Die Adresszuweisung kann man natürlich nur durchführen, wenn die UID bekannt ist, mangels Rückmeldehardware lässt sich das beim basrcpd noch nicht automatisieren. Außerdem ist Decoderauslesen nicht möglich, blindes Schreiben könnte man jedoch implementieren.

Schienensignal
Manchmal noch ungewollte Gruppen von Polaritätswechseln, sollten noch raus.

Adresse gegenüber LocID
Die internen Verwaltungsdaten werden noch SRCP-gemäß über Adressen verwaltet. Damit identische Adressen in unterschiedlichen Protokollen genutzt werden können (z.B MM 5 und mfx 5 gleichzeitig), muß die Verwaltung auf LocID (also im Beispiel 0x0005 und 0x4005) umgestellt werden.

DCC-Programmierung
Wie schon früher festgestellt, bereitet der Programmiergleismodus Probleme, der zwar im Protokoll definiert ist, aber z.B. eine Auswertung zum Ansteuern eines Umschalters noch nie im srcpd realisiert war. Die Paketerzeugung für die Untermodi im basrcpd ist noch nicht von UART auf SPI umgestellt, aber zwischenzeitlich stillgelegt um Hänger bei versehentlichem Ansprechen zu vermeiden.
Die Parameterprüfung könnte auch noch besser sein, so führt z.B. ein BIT auf 7 zu setzen zu einem OK, ebenso das 9te von 8 zu modifizieren!

Temperaturabfrage
Beim Lesen aus dem sys-Filesystem gibt es unter meinem Entwicklungs-Armbian Probleme, während es unter Lede funktioniert: Lesebefehle der "get-Gruppe" arbeiten so schnell (~100µs) wie unter Lede, liefern aber nicht wirklich aktuelle Werte, die der "read-Gruppe" liefern sinnvolle Werte, aber blockieren der Rechner für Hunderte von Millisekunden!

Gruß
Rainer

[Rainer Müller]

Hallo,

es geht langsam weiter, hier erst mal eine Skizze meiner Testkonfiguration:

Die Zahlen stellen die verwendeten Portnummern dar.


Einer meiner offenen Punkte ist geklärt:
[quote="Rainer Müller" post_id=1847998 time=1530434843 user_id=1332]
Temperaturabfrage
Beim Lesen aus dem sys-Filesystem gibt es unter meinem Entwicklungs-Armbian Probleme, während es unter Lede funktioniert: Lesebefehle der "get-Gruppe" arbeiten so schnell (~100µs) wie unter Lede, liefern aber nicht wirklich aktuelle Werte, die der "read-Gruppe" liefern sinnvolle Werte, aber blockieren der Rechner für Hunderte von Millisekunden!
[/quote]
Die Ursache liegt am ultralangsamen Temperatursensor auf dem BPi, der für eine Messung eine halbe Sekunde braucht. Bei Armbian startet der Treiber sun4i_gpadc die Wandlung und blockiert den rufenden Thread bis sie fertig ist, bei Lede veranlasst der Treiber sun4i-ts periodisch alle 2 Sekunden eine Wandlung und speichert das Ergebnis, das er dann bei Anfrage in wenigen Mikrosekunden zur Verfügung stellen kann.

Zum Glück gibt es den sun4i-ts auch bei Armbian, man muss nur verhindern, dass sich der sun4i_gpadc beim Starten vordrängt.
Dazu erstellt man eine Datei /etc/modprobe.d/temp-blacklist.conf mit folgendem Inhalt:

1
2
3
4
5
6
 

# block very slow gpadc to give sun4i-ts the chance for fast temperature reading
 
blacklist sun4i_gpadc_iio
blacklist sun4i_gpadc
 
 

Gruß
Rainer

[Rainer Müller]

Hallo,

das ist jetzt entsprechend angepasst in der neuen Version 1809:
[quote="Rainer Müller" post_id=1847998 time=1530434843 user_id=1332]
Adresse gegenüber LocID
Die internen Verwaltungsdaten werden noch SRCP-gemäß über Adressen verwaltet. Damit identische Adressen in unterschiedlichen Protokollen genutzt werden können (z.B MM 5 und mfx 5 gleichzeitig), muß die Verwaltung auf LocID (also im Beispiel 0x0005 und 0x4005) umgestellt werden.
[/quote]
Das bedeutet, dass nun
- identische Adressen in unterschiedlichen Protokollen genutzt werden können
- die höchste Adresse größer als die Anzahl der möglichen Adressen sein darf.

Was ich in meinem letzten Beitrag noch vergessen habe zu erwähnen:
ich habe auch die Version 1806 in Gerds Lede-Image vom 30 Juni 2018 getestet, und sie funktionierte genau so wie unter Armbian - so wie es sein soll.


Gruß
Rainer

[bertr2d2]

Hallo,
[quote="Rainer Müller" post_id=1868891 time=1535993819 user_id=1332]
... das ist jetzt entsprechend angepasst in der neuen Version 1809:
[/quote]
neueste Version kann nun auch per Upgrade im OpenWRT/Lede Image geladen werden.

@Rainer,
vielen Dank für die neue Version

Gruß

Gerd

[Rainer Müller]

Hallo Gerd,

besten Dank fürs Übernehmen.

Zitat

---

Hallo,
[quote="Rainer Müller" post_id=1868891 time=1535993819 user_id=1332]
... das ist jetzt entsprechend angepasst in der neuen Version 1809:

---

neueste Version kann nun auch per Upgrade im OpenWRT/Lede Image geladen werden.

Gruß

Gerd
[/quote]
Upgrade hat hervorragend geklappt, ich habe jetzt auch basrcpd 1809 auf Lede - und natürlich den Betriebstest mit der Anlage gleich gemacht. Kein Unterschied zwischen den Betriebssystemen feststellbar.

Gruß
Rainer

[Rainer Müller]

Hallo Mitleser,

lasst beim Armbian-Update Vorsicht walten. In meiner Testumgebung ging gestern beim Update der Kernel von 4.14.84 auf 4.19.13 und dabei erhielt ich auch einen neuen DeviceTree - mit dem Erfolg, dass kein SPI mehr tut und damit auch kein basrcpd.
In dem DT-Overlay fehlen schon im Installationspaket Dateien für den a20-spi.

Vorübergehende Abhilfe gelang, indem ich aus einer Sicherungskopie den alten DeviceTree wieder nach /boot kopiert und den Link dtb auf das Verzeichnis mit dem alten Inhalt gesetzt habe.

Gruß
Rainer

[Rainer Müller]

Hallo,

es gibt mal wieder eine neuen Version 1902 des basrcpd auf meiner Gleissignalerzeugungs-Seite.

Verbesserungen sind:
- verbesserte Datenübernahme bei mehreren Clients
- eigene UID in Power-Antworten über CAN-Bus wenn Kommando an alle
- Stopp/Go-Abfrage über CAN-Bus hinzugefügt
- Dummyantwort vom MCS-Gateway auf Stellbefehle damit keine Blockade des MCS-Clients
- Schreiben von mfx-CV über CAN-Bus

Von Armbian-Seite wurde durch ein erneutes Update (jetzt auf Kernel 4.19.20) das berichtete Problem gelöst:
[quote="Rainer Müller" post_id=1929140 time=1548097823 user_id=1332]
... ging gestern beim Update der Kernel von 4.14.84 auf 4.19.13 und dabei erhielt ich auch einen neuen DeviceTree - mit dem Erfolg, dass kein SPI mehr tut und damit auch kein basrcpd.
[/quote]
Es gab wohl noch weitere SPI-Anwender die lahmgelegt wurden ...


Gruß
Rainer

[Rainer Müller]

Hallo Mitmacher,

nachdem Gerd einen neuem OpenWrt-Kernel zum Testen bereitgestellt hatte, musste ich hier feststellen, dass es damit ein Problem beim srcpd gibt:

Zitat

---

Prinzipiell läuft der basrcpd, gibt aber beim Start auffallend viele Meldungen über "Interrupted system call" aus. Bei usleep ist das eher als Schönheitsfehler einzustufen, aber beim MCS-Gateway triffts ein select, und da habe ich wohl die Fehlerbehandlung vermurkst: oft friert der Thread ein.

---

Dafür gibt auf die Schnelle eine neuen Version 1903 des basrcpd auf meiner Gleissignalerzeugungs-Seite.

Verbesserungen sind:
- Korrektur der Fehlerbehandlung im MCS-Gateway
- Erweitern von gleichlautenden Fehlermeldungen (z.B. um Zeilennummern) damit besser unterscheidbar
- Verbesserung bei wiederholter Kurzschlussbehandlung


Gruß
Rainer

[bertr2d2]

Hallo Rainer & Andere,
[quote="Rainer Müller" post_id=1949013 time=1551892527 user_id=1332]
Dafür gibt auf die Schnelle eine neuen Version 1903 des basrcpd auf meiner Gleissignalerzeugungs-Seite.
[/quote]
ist im neuesten Image eingearbeitet und steht zum Download bereit. Enpacken nicht vergessen

Gruß

Gerd

[Rainer Müller]

Hallo,

Zitat

---

Hallo Rainer & Andere,
[quote="Rainer Müller" post_id=1949013 time=1551892527 user_id=1332]
Dafür gibt auf die Schnelle eine neuen Version 1903 des basrcpd auf meiner Gleissignalerzeugungs-Seite.

---

ist im neuesten Image eingearbeitet und steht zum Download bereit. Enpacken nicht vergessen

Gruß

Gerd
[/quote]
alles was mir auffiel und mehr ist darin jetzt gelöst:
- MCS startet jetzt immer, auch nach "Interrupted system call"
- mein Netzwerk wird nicht mehr durch den dnsmasq irritiert
- der SPI-Treiber kann jetzt auch 64er-Pakete
- als knaller ein neues Begrüßungslogo

Einzige neue Kleinigkeit: die Konfigurationsdatei für den basrcpd heisst jetzt im Image "srcpd.conf-spi0". Sie muss entweder in "srcpd.conf" umbenannt werden oder der basrcpd muss mit der f-Option gestartet werden:
"srcpd -f srcpd.conf-spi0".

Gruß
Rainer

[Rainer Müller]

Hallo,

es gibt mal wieder eine neuen Version 1905 des basrcpd auf meiner Gleissignalerzeugungs-Seite.

Anlass ist die Korrektur der falschen Fahrtrichtung bei mfx, da im Protokoll SRCP die 1 als vorwärts, in mfx aber die 1 als rückwärts betrachtet wird. Bei diesr Aktion habe ich gleich noch diverse Optimierungen bei der Digitalsignalerzeugung und Verbesserungen bei der Parameterprüfung für SRCP eingeführt.

Beim Testen fiel mir dann noch auf, dass mein Analyseprogramm keine Stellbefehle anzeigen konnte, weder für MM noch für DCC. Eine erweiterte Version ist hier im Unterverzeichnis "diganal" verfügbar.


Gruß
Rainer

[Rainer Müller]

Hallo,

als Vorbereitung für eine größere Bereinigung der Digitalsignalerzeugung (DDL) habe ich am Unterbau gearbeitet, zu finden unter Version 1906 des basrcpd auf meiner Gleissignalerzeugungs-Seite.

Änderungen in Version 1906:

- das Stellen der Magnetartikel über das MCS-Gateway ist jetzt eingebaut mit Synchronisation zwischen SRCP- und MCS-Clients, d.h. man sieht z.B. das Umschalten einer Weiche in einem Client, wenn man das im anderen veranlasst. (Allerdings schaltet die Weiche dann im spdrs60 hart ohne die Umlaufanimation).

- die SRCP-Parameterprüfung wurde auf die Möglichkeit von 32 Funktionen erweitert, bisher waren es 29 für NMRA/DCC. Die tatsächliche Behandlung von 32 Funktionen folgt aber erst im Zuge der oben genannten Bereinigung.

- nebenbei habe ich die Anzahl der Warnhinweise von cppcheck bei "angefassten" Modulen reduziert


Gruß
Rainer

[bertr2d2]

Hallo Rainer,
[quote="Rainer Müller" post_id=1981479 time=1560068073 user_id=1332]
Hallo,

als Vorbereitung für eine größere Bereinigung der Digitalsignalerzeugung (DDL) habe ich am Unterbau gearbeitet, zu finden unter Version 1906 des basrcpd auf meiner Gleissignalerzeugungs-Seite.
[/quote]
vielen Dank für das Update. Ich habe die neueste Version in die OpenWRT/Lede Images integriert. Die Images sind über die etablierten Links abrufbar.

Gruß

Gerd

[Rainer Müller]

Hallo,

und schon wieder gibt es eine neue Version 1907 des basrcpd auf meiner Gleissignalerzeugungs-Seite.

Um mich bei Korrekturen und Änderungen nicht immer wieder im DDL-Dickicht zu verlaufen, habe ich bei den voneinander abhängigen Threads (nur einer kann gleichzeitig auf das SPI) aufgeräumt:
Die bisher verwendeten Threads
- thr_sendrec_DDL (Senden geänderter Werte)
- thr_refresh_cycle (Senden von Wiederholungen)
- thr_delayedGAReset (Abschalten von Magnetartikeln nach Zeit)
- thr_mfxManageThread (periodische MFX-Aktivitäten)
wurden zum neuen Thread "thr_Manage_DDL" zusammengefasst. Dadurch konnte ich auch die Einschaltzeitbegrenzung für die Schaltdecoder auf "nicht ablaufblockierend" umstellen.

Sonstige Änderungen in Version 1907:
- Bei MFX können jetzt 32 Funktionen bedient werden anstatt bisher 16 (von Dani übernommen und angepasst)
(allerdings nur mit Gleissignalanalysator getestet, da ich keine Lok mit mehr als 16 Funktionen habe)

- Bei MM1 wurde die Verwendung des alten Funktionsprotokolls ermöglicht, d.h. bei Einstellung MM1 mit 5 Funktionen werden die zusätzlichen 4 mit doppelter Frequenz (Stichwort "Funktionen mit 40 kHz") gesendet.

- Das durch diverse Änderungen irrtümlich entfallene Abspeichern des Neuanmeldezählers wird wieder durchgeführt.

- Anlass von Warnhinweisen von cppcheck beim Modul srcp-gl.c beseitigt

- Im Headerfile "platform.h" musste ich das Symbol für den Mehrfacheinbindeschutz ändern, weil irgendwo anders das nach Systemupdate plötzlich auch definiert wird. Da kommt man ins Grübeln, wenn eine Headerdatei zwar gelesen wird, aber ihr Inhalt vom Compiler als nichtexistent betrachtet wird.


Gruß
Rainer

[Sigg]

Hallo
Ich habe mit meiner srcpd MFX Implementierung immer wieder mal folgendes Problem:
Eine MFX Lok nimmt nach Booster Aktivierung keine Kommandos an, reagiert nicht.
Auch das erneute Senden einer Schienenadresse hilft nicht. Nur wenn der Booster (der Strom) ausgeschaltet wird nimmt die Lok dann nach erneutem Einschalten wieder Kommandos an.
Ich habe keine Ahnung an was das liegen kann, was hier falsch läuft. Hat jemand von euch schon solche Erfahrungen gemacht?

Gruss Dani

[Rainer Müller]

Hallo Dani,

Zitat

---

...
Auch das erneute Senden einer Schienenadresse hilft nicht. Nur wenn der Booster (der Strom) ausgeschaltet wird nimmt die Lok dann nach erneutem Einschalten wieder Kommandos an.
Ich habe keine Ahnung an was das liegen kann, was hier falsch läuft. Hat jemand von euch schon solche Erfahrungen gemacht?

Gruss Dani

---

eigentlich sollte ein mfx-Dekoder nach Empfang der Zentralen-UID und Zuweisung einer Schienenadresse aktiv sein. Bei mir hat das bisher immer geklappt, aber meine Stichprobe ist auch überschaubar.

Betrifft das bei dir immer den gleichen Dekoder oder einen Typ oder evtl nur eine Firmwareversion oder kann das reihum bei jedem passieren?

Gruß
Rainer