[diddi]

Hallo Uwe,

da gebe ich Die vollkommen Recht. Es ist halt im Open Source so, dass Du das gegebene immer nach Deinen Wünschen verbessern kannst. Die anderen machen es auch meistens nur in ihrer Freizeit. Ich z.B. speichere bei jedem Programmende die Positionen der Loks ab. Railcom ist mir zu teuer. Bei mir werden die Loks von der Software von Block zu Block übergeben. Wenn einer die Lok von Hand schiebt wenn die Anlage aus ist, funktioniert das natürlich nicht mehr.

SG Dietmar

[LDG]

Hallo Uwe,

Zitat von Uwe Post

---

Mich wundert eigentlich ein bisschen, dass der SRCPd kein Feature hat, um alle Zustände zu speichern und wiederherzustellen.

---

Du kennst die Bedeutung des "S" in SRCP?
Es gibt ja bereits Software, die den SRCP-Server (SRCPd) als (eine von vielen) Zentrale(n) unterstützt und die Speicherung der Zustände übernehmen kann.

Gruß,
Lothar

[Uwe Post]

Hallo Lothar,

Du sprichst sicher von RocRail. Klar, kenn ich, kann man machen. Ich wollte auch keinesfalls die Entwickler von SRCP(d) dafür kritisieren, dass sie 1. das ominöse S vorangestellt haben und 2. keinen Persistenzlayer (etwas technisch ausgedrückt) vorgesehen haben. Ich bin froh, dass es dieses Produkt, und zwar als Open Source, überhaupt gibt. Ein definiertes Protokoll erweitert man auch nicht mal eben so. Daher betrachte ich es als Aufgabe eines Clients, die "fehlende" Funktionalität nachzurüsten, so wie RocRail es eben tut, und so wie es meine eigene App (noch) nicht tut. Steht aber auf meiner TODO-Liste.
Zur vielleicht unausgesprochenen Frage, warum ich kein RocRail verwende: Es ist mir zu groß. Ich habe sechs Loks (davon wenn es hoch kommt zwei gleichzeitig in Bewegung) und sechs Weichen und kein Rückmeldesystem. Außerdem habe ich Spaß daran, Apps zu basteln (ist mein erwählter Beruf). Daher der Eigenbau, der exakt meinen Bedürfnissen entspricht und vermutlich keiner sonst gebrauchen kann ops: Insofern ist es freilich etwas vermessen, zu diesem Thema hier die Forumsdatenbank zu füllen, also reduziere ich das künftig auf ein Minimum. Die grundsätzlichen Fragen sind ja alle beantwortet, und wer zufällig an irgendwelchen Details meiner Lösung Interesse hat, kann mich ja gerne fragen.

Und jetzt muss ich aber dringend den E2749 abfahren lassen, die Fahrgäste schimpfen schon, dass die Umbauwagen wackeln!

Gruß
Uwe

[LDG]

Hallo Uwe,

ich meine nicht nur Rocrail. Auch JMRI und einige Andere können SRCP als Server verwenden. Fast alle noch aktiven Projekte sind ebenfalls OpenSource. Es gibt bisher nur sehr wenige kommerzielle Produkte/Hersteller im SRCP-Umfeld.

Gruß,
Lothar

[Uwe Post]

Hallo Lothar,

ja, sicher, aber es gibt m.W. noch keine Android-App, die ohne eine "Middleware" wie RocRail oder JMRI direkt mit dem SRCDp spricht, nicht wahr? Ausnahme ist der SRCP-Client von Michael Blank, aber der steuert nur Loks, keine Weichen, erlaubt keine Programmierung, und die Zustände speichern tut er auch nicht. Im Vergleich ist meine App schon etwas weiter (und sieht vielleicht einen Tacken besser aus ops: ), obwohl sie längst nicht fertig ist. Smartphones (oder Tablets) können heutzutage unheimlich viel, da halte ich zumindest bei einfachen Anlagen den "Mittelteil" für verzichtbar.

Schönen Gruß
Uwe

[bertr2d2]

Hallo,

Zitat von Uwe Post

---

...
genau so ist es. Bei DCC über RS232 (aka DDL/DDW) wird die serielle Schnittstelle auf recht komplizierte Weise mit "künstlichen" Daten beschickt, so dass am Ende "ziemlich genau" ein NMRA-konformes DCC-Signal herauskommt. Dieses "ziemlich genau" ist halt der Knackpunkt. Diese Schwäche hat mein Bastelsystem nicht, weil der Raspberry das Signal ohne Umwege mit dem exakt richtigen Timing erzeugt!

---

ich habe mir mal einen typischen Vertreter der preiswerten USB2Serail Wandler angeschaut. Mit dem CP2102 kann man das
Timing perfekt (was insbesondere die Frequenz betrifft) nachbilden:




Der Trick: Man modifiziert das EEPROM so, das man eine beliebige Frequenz benutzen kann. Die Formel:
Baud Rate = (24,000,000/Prescaler)/(65536 - Reload)

Zusammen mit der großen FIFO (640 Bytes) steht nichts im Weg, DCC Signale ohne große Klimmzüge 1:1 nachzubilden. Und dabei
stellt die mangelnde Echtzeitfähigkeit des Betriebssystem kein Problem dar.


Gruß

Gerd

Referenz:
http://bb.osmocom.org/trac/wiki/Hardware/CP210xTutorial
https://www.silabs.com/Support%20Documen...lDocs/an205.pdf
https://github.com/GBert/misc/tree/master/cp2102-dcc

[Uwe Post]

Hallo Gerd,

das ist eine spannende Sache. Sobald ich dazu komme, setze ich mal ein Oszi-Bild des "unmodifizierten" Signals (also SRCPd/UART) dagegen.

Danke&Gruß
Uwe

[bertr2d2]

Hallo Uwe,

Zitat von Uwe Post

---

Hallo Gerd,

das ist eine spannende Sache. Sobald ich dazu komme, setze ich mal ein Oszi-Bild des "unmodifizierten" Signals (also SRCPd/UART) dagegen.

Danke&Gruß
Uwe

---

die Bilder wären für mich interessant.

Ich glaub, ich werde mal eine Machbarkeitsstudie für einen Modellbahnsteuerung für unter 20 Euro (billigst OpenWRT Router + CP2102 Adapter und L298n Board) machen. Zusammen mit Deiner App wäre das IMHO der preiswerteste Einstieg in digitale Modellbahnsteuerung mit reichlich Potential

Gruß

Gerd

[Uwe Post]

Hallo Gerd,

hier zwei Bilder, gemessen am Gleisausgang des Delta Control. Das Signal wird in diesem Fall erzeugt von SRCPd via UART, dazwischen ist noch der RS232-Pegelwandler.

Hier der "kurze" DCC-Puls mit 45 µs Breite:



Und der "lange" mit 106 µs:



Die 45 µs für ein halbes 1-Bit sind ein bisschen wenig, der Standard schreibt vor, dass Decoder ab 52 µs reagieren sollten. Die Messungenauigkeit mit meinem Beispiel ist aber sicher +/- 5 µs. Vom Optimalwert 58 µs bin ich aber ein Stück entfernt.
Das 0-Bit mit 2x 106µs (laut Standard >=100 µs) passt jedenfalls.

Mein "eigenes" (via GPIO) erzeugtes Signal ist ein bisschen näher an den 58 µs. Das kann ich bloß gerade nicht beweisen, weil ich davon keinen Screen mit eingeblendetem Cursor habe

Was genau SRCPd mit den Baudraten veranstaltet, weiß ich nicht, ohne in den Code zu schauen. Ich kann nur sagen, dass die Anlage in der Praxis gut reagiert, bloß leider oft mit einer Verzögerung von 1 Sekunde, die ich noch nicht verorten konnte.

Schönen Gruß
Uwe

[bertr2d2]

Hallo Uwe,

vielen Dank für Deine Osci-Bilder - sehr aufschlussreich. Nimmst Du den vorhandenen Uart des PIs ?
Hast Du die Consolen Ausgaben abgeschaltet ? IMHO hat der PI nur eine serielle Schnittstelle.

Ich werde mir mal den CP2102-Treiber vornehmen. Laut dem Rocrail-Wiki fehlt dem Linux-Treiber
des CP2102 die "Uart transmitter empty" Funktion für Märklin/Motorola, obwohl der CP210x
die Funktion ansich kennt.

Zitat von Uwe Post

---

Was genau SRCPd mit den Baudraten veranstaltet, weiß ich nicht, ohne in den Code zu schauen. Ich kann nur sagen, dass die Anlage in der Praxis gut reagiert, bloß leider oft mit einer Verzögerung von 1 Sekunde, die ich noch nicht verorten konnte.

---

Für DCC verwendet SRCPd bzw Rocrail eine Funktion des TTY-Treibers, der IMHO ein übler (Linux-) Hack ist:
Mit der Baudrate B38400 kann man von den üblichen Baudraten abweichen und in gewissen Rahmen eine
beliebige Baudrate (hängt vom UART-Baustein und Treiber ab) einstellen. Hier ein ein Kommentar aus dem
FTDI Treiber:

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

	/*
	 * The logic involved in setting the baudrate can be cleanly split into
	 * 3 steps.
	 * 1. Standard baud rates are set in tty->termios->c_cflag
	 * 2. If these are not enough, you can set any speed using alt_speed as
	 * follows:
	 *    - set tty->termios->c_cflag speed to B38400
	 *    - set your real speed in tty->alt_speed; it gets ignored when
	 *      alt_speed==0, (or)
	 *    - call TIOCSSERIAL ioctl with (struct serial_struct) set as
	 *	follows:
	 *      flags & ASYNC_SPD_MASK == ASYNC_SPD_[HI, VHI, SHI, WARP],
	 *	this just sets alt_speed to (HI: 57600, VHI: 115200,
	 *	SHI: 230400, WARP: 460800)
 

Woher die von Dir beobachtete Verzögerung her kommt, wäre interessant zu wissen. Siehst Du die Verzögerung
nur unter Verwendung des UARTs oder auch mit dem GPIO-DCC Programm ?

Gruß

Gerd

[Uwe Post]

Moin Gerd,

ja, ich (bzw. der SRCPd auf dem Raspberry) benutze die eine dort vorhandene serielle Schnittstelle.
Das System benutzt sie als Terminal, was ich eigentlich abgeschaltet habe - aber beim Hochfahren sehe ich dennoch "Datenverkehr" auf dem Kanal, was auch schonmal meine Loks zu einem "Sprung" veranlasst hat (weil sie sich kurzzeitig an einem aufgedrehten Gleichstromregler wähnen), seitdem drehe ich den Trafo am Delta Control immer erst auf, wenn der Raspberry hochgefahren ist. Keine sehr elegante Lösung...

In der Tat tritt die Verzögerung zwischen Abschicken des SRCP-Kommandos und Stellen der Weiche (oder Reaktion der Lok) nicht bei meinem eigenen SRCP-Server auf, der über GPIO arbeitet. Daher vermute(!) ich die Ursache irgendwo im srcpd.

Ich verwende im Moment mein eigenes Programm nicht, weil es noch nicht alle DCC-Befehle unterstützt, und ich im Moment nicht die Zeit finde, mich da tiefer einzuarbeiten. Das Programm ist ja ein Fork eines (lange eingestellten) Projekts auf github, das nur Lok-Befehle (GL) unterstützte, und das ich um Weichenbefehle (GA) erweitert habe. Was anderes kann es aber noch nicht. Von der ursprünglichen Idee, meinen Pi-GPIO-DCC-Generator als SRCP-Modul zu verwirklichen, bin ich irgendwann abgekommen, weil mir das zu aufwändig erschien.

Übrigens hatte ich auch mal überlegt, Bluetooth zu verwenden. Das kann auch eine serielle Schnittstelle darstellen, und ich habe sogar irgendwo einen ganz billigen Empfängerbaustein herumliegen, an dem man wiederum einen Pegelwandler hängen müsste. Dann könnte (theoretisch) ein Android-Tablet das DCC-SIgnal erzeugen und drahtlos über BT auf den Booster geben. Habe ich aber bisher weder näher durchdacht noch annähernd verwirklicht, denn die Signalerzeugung müsste man unter Android natürlich nativ, also mit NDK, machen. Reizvoll wäre es - dann könnte sogar noch der EInplatinencomputer aus dem ganzen AUfbau verschwinden...

Schönen Gruß
Uwe

[Uwe Post]

Hallo,

ich möchte hier einmal als vielleicht finales Posting für alle, die über diesen Thread stolpern, eine Zusammenfassung versuchen.

1. SRCPd/DDL auf Raspberry Pi über serielle Schnittstelle läuft sauber. (Hinweis: Das DDx-Modul in Rocrail nicht, daher geht es nicht ohne den SRCPd)
2. Man braucht je nach Booster einen Pegelwandler auf 5 Volt (z.B. bei Verwendung eines Märklin Delta Control).
3. Als Client eignet sich z.B. Rocrail, oder aber auch meine eigene Android-App "Stellwerk". Diese ist nicht bei Google Play verfügbar, weil sich nicht perfekt ist und ich mich nicht, sorry, Ahnungslosen herumschlagen möchte, die der App eine 1-Sterne-Bewertung geben, weil sie dachten, es wäre ein neues Spiel. Wer Interesse an der App hat, kann mir gerne eine PN schreiben. Ich gebe sie kostenlos und unverbindlich und ohne Garantie ab. Aber sie funktioniert.

Bei mir funktioniert das Gesamtsystem wie oben skizziert seit mehreren Wochen weitestgehend sauber. Gelegentlich stellt sich eine Weiche mit 1 Sekunde Verzögerung, das ist aber auch alles. Verwendet werden dort übrigens Decoder von der Gelsenkirchener IEK mbh. Loks mit Decodern von ESU, Tams, Lenz und Trix fahren problemlos. Lediglich ein Viessmann-Decoder ließ sich partout nicht in Betrieb nehmen, aber der war möglicherweise einfach kaputt.

Kurzer Überblick über die Kosten des Systems:

- Raspberry Pi ca. 30 Euro
- Beliebiger Booster und passender Trafo ab ca. 25 Euro (für ein altes Märklich Delta mit Transformer)
- Pegelwandler (wenn erforderlich) bei ebay 5 Euro
- Android-Tablet oder Phone ab ca. 79 Euro (wenn nicht ohnehin vorhanden)
- Software komplett kostenlos und Open Source

Nachteile dieses ganz einfachen Aufbaus seien nicht verschwiegen:

- Keine Rückmeldung, kein Railcom etc.

Wer mehr zum praktischen Einsatz wissen möchte, kann mich gerne fragen.

Schönen Gruß

Uwe

[Peacy Stein]

Hallo zusammen,

bezüglich openWRT

Zitat von bertr2d2

---

Hallo Uwe,
[...]
Ich glaub, ich werde mal eine Machbarkeitsstudie für einen Modellbahnsteuerung für unter 20 Euro (billigst OpenWRT Router + CP2102 Adapter und L298n Board) machen. Zusammen mit Deiner App wäre das IMHO der preiswerteste Einstieg in digitale Modellbahnsteuerung mit reichlich Potential

Gruß

Gerd

---

und Raspberry Pi gibt es meines Erachtens zwei interessante/wichtige News:
Für die Raspberry Pi gibt es ein 7"-Touchdisplay:
7-Zoll-Touch-Display für Raspberry Pi ab sofort erhältlich

und für openWRT-Router sind die Tage wohl gezählt, wenn ich diesen Artikel richtig gelesen habe:
Funkregulierung als Angriff auf alternative Software: "Open-Source-Projekte gefährdet"

Viele Grüße

[M.Metall.f.d.Kids]

Hallo,

Ich grab das hier mal aus der Versenkung aus.

Hat einer von Euch schon mal den SRCPd mit dem CP2102 USB UART ans laufen bekommen?

Ich habe die BAUD Rate nach der Anleitung von Gerd angepasset und wenn ich eine Reihe "U" an den UART pipe, dann sieht das Signal auch gut aus. Ich messe dort ein Rechtecksignal mit 8,621kHz.

Ich habe dann gestern den SRCPd auf einem Raspi installiert und der hat aber Probleme mit der UART treiber. Wenn ich die Fehlermeldung richtig interpretiere passt dem SRCPd inrgendwas beim Setzen eines Teilers nicht. Den genauen Wortlaut habe ich jetzt nicht mehr im Kopf, kann ich aber heute Abend nachliefern.

Gruß,

Michael

[bertr2d2]

Hallo Michael,

Zitat von M.Metall.f.d.Kids

---

Hallo,

Ich grab das hier mal aus der Versenkung aus.

Hat einer von Euch schon mal den SRCPd mit dem CP2102 USB UART ans laufen bekommen?

Ich habe die BAUD Rate nach der Anleitung von Gerd angepasset und wenn ich eine Reihe "U" an den UART pipe, dann sieht das Signal auch gut aus. Ich messe dort ein Rechtecksignal mit 8,621kHz.

---

der Silabs CP2102 ist wirklich eine sehr interessante Alternative, um präzise Signale zu generieren.

Zitat

---

Ich habe dann gestern den SRCPd auf einem Raspi installiert und der hat aber Probleme mit der UART treiber. Wenn ich die Fehlermeldung richtig interpretiere passt dem SRCPd inrgendwas beim Setzen eines Teilers nicht. Den genauen Wortlaut habe ich jetzt nicht mehr im Kopf, kann ich aber heute Abend nachliefern.

---

Ich erahne, was Du meinst. Hier geht es um das Setzen einer "Customer Baudrate". Ob der Treiber das unterstützt, weiss ich nicht. Prinzipiell ist es nicht (mehr) notwendig, da die "krummen" Baudraten ja schon eingestellt sind.
Was dem CP210x-Linux-Treiber fehlt, ist IMHO eine wichtige Funktion: TX-Empty. Der CP2102 beherrscht das laut Doku aber die Funktion ist nicht im Code - siehe auch: Silabs Forum
Wenn man diese Funktion in das Kernel-Modul eingebaut bekommt, dann ist der CP2102 eine wirklich sehr preiswerte Alternative um sehr präzise Gleis-Signale zu erzeugen. Zusammen mit der großen FIFO ist auch die Belastung für die CPU sehr gering.
Ich hatte auch schon angefangen, die Funktion TX-Empty abzubilden, aber es ist mal wieder etwas anderes dazwischen gekommen ...

Alternativ kannst Du ein nicht wesentlich teureres FT232RL Modul verwenden. IMHO kann man die Signale nicht ganz so genau nachbilden ("Customer Baudrates"), aber die wichtige TX-Empty Funktion ist implementiert.

Soweit ich weiss hat Uwe es aber auch ohne externen Adapter direkt mit dem RPi UART hinbekommen.

Gruß

Gerd

[M.Metall.f.d.Kids]

Hallo Gerd,

Ich danke Dir für Deine Rückmeldung.

Zitat

---

Was dem CP210x-Linux-Treiber fehlt, ist IMHO eine wichtige Funktion: TX-Empty.

---

Da könnte ich micht auch dran begeben. Wenn Du schon irgendwelche Vorarbeiten hast, auf die ich aufbauen kann, würde ich die nehmen, sonnst schaffe ich das auch so.

Dann kann ich vielleicht auch das Problem, auf dass ich gestossen bin im Zusammenhang mit SCRPd fixen.

Dann habe ich noch eine Frage an Dich. Du erwähntest, dass Du eine MS1 mit verwenden tust oder willst. Ich habe z.Z. zwei MS1 in Benutzung und könnte mir vorstellen, die auch weiterhin zu verwenden. Wie bindest Du die MS1 in deinen Aufbau ein? Ich nehme an sie läuft als Slave an der Gleisbox?

Viele Grüße in die Wetterau,

Michael

[bertr2d2]

Hallo Michael,

Zitat von M.Metall.f.d.Kids

---

Hallo Gerd,

Ich danke Dir für Deine Rückmeldung.

Zitat

---

Was dem CP210x-Linux-Treiber fehlt, ist IMHO eine wichtige Funktion: TX-Empty.

---

Da könnte ich micht auch dran begeben. Wenn Du schon irgendwelche Vorarbeiten hast, auf die ich aufbauen kann, würde ich die nehmen, sonnst schaffe ich das auch so.

---

Naja, ich habe nicht wirklich was erreicht. Den einzigen brauchbaren Hinweis auf diese Funktion habe ich hier gefunden:
https://www.silabs.com/Support%20Documen...lDocs/AN571.pdf
Ich denke, Du solltest einen aktuelles cp210x Modul nehmen und diesen entsprechend anpassen. Siehe auch den FTDI Treiber.

Zitat

---

Dann kann ich vielleicht auch das Problem, auf dass ich gestossen bin im Zusammenhang mit SCRPd fixen.

Dann habe ich noch eine Frage an Dich. Du erwähntest, dass Du eine MS1 mit verwenden tust oder willst. Ich habe z.Z. zwei MS1 in Benutzung und könnte mir vorstellen, die auch weiterhin zu verwenden. Wie bindest Du die MS1 in deinen Aufbau ein? Ich nehme an sie läuft als Slave an der Gleisbox?

---

Das ist aber eine andere Baustelle: Die MS1en verwende ich im Zusammenhang mit CAN und im Speziellen mit can2lan. Ich habe festgestellt, das man MS1en mit der Gleisbox verwenden kann, wenn man M*rklin's PC Software laufen lässt. Die MS1 ist dann im Zusammenspiel mit M*rklins Software Slave. BTW: Das funktioniert sogar mit mehreren MS1en. Ohne M*rklins Software aber quittiert die MS1 ihren Dienst mit "Kein Master". Die eigentliche Master/Slave Aushandlung fehlt im can2lan - kommt aber irgendwann

Zitat

---

Viele Grüße in die Wetterau,

---

Danke

Gruß

Gerd

[M.Metall.f.d.Kids]

Hallo Gerd,

So in etwa habe ich mir das mit der MS1 gedacht.

Ich habe heute mal das TX_EMPTY in den cp210x Treiber eingebaut. Nun kommt die Frage, wie ich das am besten Teste.

Ich habe grade im SRCPd code geguckt. Ich glaube da fehlt im cp210x Treiber noch einige IOCTLs, die sind nämlich garniht implementiert und der SRCPd nutzt die bei der tty Treiber initialisierung. Da muss ich dann noch mal bei.

Viele Grüße,

Michael

[bertr2d2]

Hallo Michael,

Zitat von M.Metall.f.d.Kids

---

Hallo Gerd,

So in etwa habe ich mir das mit der MS1 gedacht.

Ich habe heute mal das TX_EMPTY in den cp210x Treiber eingebaut. Nun kommt die Frage, wie ich das am besten Teste.

---

Wow - cool Würde gerne mal ein Blick drauf werfen ... Testen würde ich es in dem ich einen (langen) String senden würde und schauen ob TX-Empty gemeldet wird, ggf - mit usbmon.

Zitat

---

Ich habe grade im SRCPd code geguckt. Ich glaube da fehlt im cp210x Treiber noch einige IOCTLs, die sind nämlich garniht implementiert und der SRCPd nutzt die bei der tty Treiber initialisierung. Da muss ich dann noch mal bei.

---

Stimmt. Ich denke, der FTDI Treiber kann man bis zu einem gewissen Punkt als Vorlage nehmen.

Gruß

Gerd

[M.Metall.f.d.Kids]

Hi Gerd,

Ich hab Dir meine version von cp210x.c als Mail geschickt.

Zitat

---

Ich denke, der FTDI Treiber kann man bis zu einem gewissen Punkt als Vorlage nehmen.

---

Stimmt, man muss ja das Rad nicht neu erfinden.

Viele Grüße,

Michael

[thenextlevel]

Zitat von Uwe Post

---

Nachteile dieses ganz einfachen Aufbaus seien nicht verschwiegen:
- Keine Rückmeldung, kein Railcom etc.

---

Moin,

der Andreas hier. Ich habe einen fast gleichen Aufbau meiner Anlage mit PI, SRCPD, Rocrail und einem Roco10764, der ohne Pegelumsetzer an der seriellen des PI sauber arbeitet. Danke für eure Tipps hier soweit.

Zur Rückmeldung nutze ich einen s88-3 vomn TAMS und dieses hier http://www.s88udp.de/ mit Reedkontakten. Einwandfreie Rückmeldung an Rocrail. Bitte folgenden Satz beachten:

1
2
3
4
 

Der S88 Bus muss im Normalfall über Optokoppler und Pegelwandler am Raspberry Pi angeschlossen werden. ...
 * Im Sonderfall, dass die original S88 Schaltung mit ICs vom Typ 4014N und 4044N verwendet wird, kann auf Pegelwandler verzichtet werden. Die CMOS Bausteine funktionieren auch mit den 3,3 Volt des Raspberry Pi.
 * Im Sonderfall, dass die S88 Bausteine keinerlei Verbindung zum Rest der Modellbahn und Steuerung hat, kann auf die galvanische Trennung durch Optokoppler verzichtet werden.
 
 

Bis denne, Andreas

[hausi24]

Hallo zusammen,

bin neu hier, habe aber schon eifrig mitgelesen.

Bin gerade dabei meine "alte" Gleichstrombahn zu digitalisieren, um meinem Sohn das Thema damit nahe zu bringen. Ich habe dazu die Anleitung von Stephan Richter ( https://github.com/StephanRichter/model-...%C3%BCckmeldern ) umgesetzt.
Sieht kurz gefasst so aus:
Raspberry Pi mit Raspian auf dem SRCPD läuft, verbunden über die serielle Schnittstelle mit Pegelwandler an einen Roco 10764.

SRCPD läuft ich kann mich mit j-man anmelden und bekomme eine Verbindung.

Am Gleis erhalte ich eine rechteckförmige Spannung von ca 0,5 Volt, Wenn ich die Digitalspannung im Client (j-man oder andere) einschalt änder sich die Spannung am Gleis auf ca 0,6 Volt.

Gespeist wird der Roco Booster übrigens aus einem Labornetzteil mit 18V Gleichspannung.

Hier bin ich mit meinem "Latein" am Ende und wollte nun einmal hier die Gemeinde nach Rat fragen.

[Uwe Post]

Das klingt für mich entweder nach Kurzschluss irgendwo oder nach einem Problem mit dem Booster. Vielleicht braucht der aus irgendeinem Grund Wechselspannung?

[slowberg]

Moin, moin,

und erst mal ein frohes Neues! Habe gerade diesen Thread hier gelesen und bin insbesondere an der Weiterentwicklung des cp210x Treibers interessiert. @Michael, hattest du schon Zeit an den fehlenden ioctls weiter zu arbeiten? Kannst du mir deine Version des Treibers zukommen lassen?

Finde die Vorstellung einer kompletten Steuerung der Moba mit Raspi und Booster ohne großartige Adapterhardware sehr reizvoll. Und wenn es nur für den Testkringel ist.

Gruß
Siggi

PS: Lese hier mit Interesse, dass ja wohl doch einige Menschen an meiner kleinen s88udp Bastelei Freude haben

[M.Metall.f.d.Kids]

Moin Siggi,

Dir auch ein Frohes neues Jahr!

Die IOCTLs sind gecoded aber ich muss das ganze noch debuggen. Ich hatte das ganze nebenbei auf der Arbeit gemacht, solange wir noch die Infrastruktur am Laufen hatten. Inzwischen sind die Labore abgebaut, jetzt haben wir auf der Arbeit noch weniger zu tun aber auch keine Infrastruktur mehr. Der Hintergrund ist, dass der Laden zu gemacht wird.

Ich habe jetzt ein paar Tage Urlaub und werde zu hause weitermachen, Ich denke im Laufe des Januars, werde ich eine lauffähige Version haben. Dann werde ich das hier präsentieren und wer will kann den Treiber zum Testen haben.

Viele Grüße,

Michael