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