[DrachenBernd]

Hallo liebe Leser.

Update zwischendurch: während noch auf ein formschönes Gehäuse gewartet wird wurde die Software - neben Bugfixes - etwas erweitert. Jetzt können "Anlagensets" von einem Webserver ausgewählt und geladen werden. Damit ist ein Ausbau der SD-Karte zum neu-/um-programmieren nicht mehr nötig. Das Gehäuse kann kommen!

Aktueller Stand:
adafruit huzzah32 ca. 23 Euro
adafruit 3.5 Zoll Touchdisplay ca. 43 Euro
2000mAh LiPo Akku ca. 7 Euro, aber mehr ist natürlich besser. Und demnächst kommt dann auch mal der Dauertest...
Arduino KY-040 Drehgeber auf Platine, ca. 1.50 Euro
Kappe für Drehgeber, ca. 1.50 Euro
Gehäuse von der Stange, ca. 6 Euro
Gesamt: 82 Euro
Das alles kann ohne Löten alles durch Stecken verbunden werden (Arduino felxible Kabelbrücken, 10x ca. 3 Euro). Nur das Kabel zur Helligkeitsteuerung des Displays muss an einem Lötpad angelötet werden.

Gruß und sturmfreie Woche
Bernd

[Lio]

Hallo Bernd,

schön, wieder einen Zwischenbericht zu hören!

Für mein - noch nicht begonnenes - ähnliches Projekt habe ich inzwischen die ultimative Hardware gefunden, ebenfalls ohne jegliches Löten: M5Stack Faces (mit ESP32). Im Set sind drei Aufstecktastaturen. Extra zu erwerben ist eine Aufsteck"tastatur" mit Drehregler. Habe ich gestern bestellt, wird Ende nächster Woche da sein. Dann kann ich bei Interesse kurz berichten. Würde aber weitere Schilderungen dann in einen eigenen Thread auslagern, damit ich hier nicht so weit vom Thema abkomme.
Wollte es dir nur mitteilen, falls du später an ein Zweitexemplar denken solltest ...

M5Stack: https://www.youtube.com/watch?v=aFDE-9YX_Mc

Und hier mit Drehregler: https://www.youtube.com/watch?v=G9XkioR7RRs

Preis zusammen (nicht aus China): 66€ + 10€ = 76€, jeweils zzgl. Versand.

[JörgBehrens]

Hallo Frank,

Zitat

---

Hallo Bernd,

schön, wieder einen Zwischenbericht zu hören!

Für mein - noch nicht begonnenes - ähnliches Projekt habe ich inzwischen die ultimative Hardware gefunden, ebenfalls ohne jegliches Löten: M5Stack Faces (mit ESP32). Im Set sind drei Aufstecktastaturen. Extra zu erwerben ist eine Aufsteck"tastatur" mit Drehregler. Habe ich gestern bestellt, wird Ende nächster Woche da sein. Dann kann ich bei Interesse kurz berichten. Würde aber weitere Schilderungen dann in einen eigenen Thread auslagern, damit ich hier nicht so weit vom Thema abkomme.
Wollte es dir nur mitteilen, falls du später an ein Zweitexemplar denken solltest ...

M5Stack: https://www.youtube.com/watch?v=aFDE-9YX_Mc

Und hier mit Drehregler: https://www.youtube.com/watch?v=G9XkioR7RRs

Preis zusammen (nicht aus China): 66€ + 10€ = 76€, jeweils zzgl. Versand.

---

Es gibt bereits ein Projekt für den M5Stack als Funkregler für die CS2/ CS3 hier im Forum. Eine Portierung auf andere Systeme sollte nicht allzu schwierig sein. Suche mal unter ‘haptisch’ hier im Unterforum (oder gehe zu Seite 2 im Unterforum). Leider bin ich durch Krankheit etwas außer Gefecht gesetzt und habe es nicht wie versprochen geschafft den Sourcecode im Januar hier zu veröffentlichen. Der Drehregler ist übrigens nur aus China erhältlich. In Europa habe ich noch keine Bezugsquelle gefunden. Der M5Stack und die Facestastaturen sind seit einiger Zeit auch bei Conrad erhältlich.

Viele Grüße
Jörg

[Lio]

Hallo Jörg,

deine Seite habe ich inzwischen gefunden (viewtopic.php?f=7&t=175023&p=2053877).

Da du dort auch wie ich hier in ein anderes Thema eingehakt hast, würde ich gern ein dediziertes M5Stack-Thema aufmachen und würde mich freuen, dich dort als Mitleser begrüßen zu dürfen.

viewtopic.php?f=7&t=177695&p=2079424#p2079424

[Lio]

Hallo Jörg,

"Der Drehregler ist übrigens nur aus China erhältlich." stimmt nicht ganz. Ich habe über Amazon bestellt (https://www.amazon.de/gp/product/B07RHZK...0?ie=UTF8&psc=1). Derzeit ist mein Regler von den USA hierher unterwegs und gerade in ... lass mich nachschauen ... Robbinsville, New Jersey

Viele Grüße
Frank

[DrachenBernd]

Hallo Zusammen.

Fast 2 Wochen her seit dem letzten Lebenszeichen, die ich aber locker u.a. mit netBiDiB verbringen konnte.
Zum Stand: der WLAN-Regler kann sich von einem Webserver neue Datensätze (für die Heimanlage, aber auch für "Gastanlagen") holen, ein Ausbau der SD-Card und ein externes Aufspielen von Daten ist damit nicht mehr nötig. Dabei kann der Datensatz über die verfügbaren Loks und deren Bilder bis hin zu den WLAN-Daten alles enthalten. Hauptproblem - neben meinem Hirn - war das Umschalten zwischen udp und tcp... auf der Wunschliste steht nur noch ein "on-the-fly"-Nachladen von Lokbildern die der Handregler noch nicht hat.
Aber sonst prima, jetzt warte ich nur noch auf den Dauerakkutest und ein hübsches Gehäuse.
In den letzten 2 Wochen durfte ich hauptsächlich mit einer Vorversion von netBiDiB experimentieren (dickes DANKE ans Team), dabei habe mittlerweile einen ersten "z21emu" geschrieben der auf der einen Seite mit meinem Regler spricht (mittels des z21-Protokolls) und auf der anderen Seite mit netBiDiB gepaart ist. Auch wenn es noch viele Bugs, Ecken und Kanten zu beseitigen gibt reicht mir der PoC einer fahrenden Lok als Motivation zum Weitermachen. Weiß auch nicht ob das z21-Protokoll über udp so gut ist, evt. switche ich noch zu tcp damit man auch bei mehr Netzwerkverkehr sicher sein kann dass die Nachricht auch ankommt.

Grüße und ein närrisches Wochenende
Bernd

[Lio]

Hallo Bernd,

schön, von deinen Fortschritten zu hören. Zu deinen leichten Zweifeln an UDP möchte ich folgendes anmerken: auch Roco setzt ja mit der WLAN-Maus auf UDP setzt. Mal vorausgesetzt, dass man sich in einem professionellen Entwicklungsprozess dort mit TCP vs. UDP auseinandergesetzt hat, würde ich postulieren, dass es auch für uns OK ist.

Ich selbst habe bei meinem WLAN-basierten Rückmelder viewtopic.php?f=21&t=169476 auch auf UDP gesetzt und bislang keine Probleme. Disclaimer: die Langzeiterfahrung fehlt noch, da ich meist baue statt zu fahren.

Sofern dein WLAN-Router im/in der Nähe des Hobbyraums steht, sollte die Netzstabilität auch gegeben sein, und zur Not hast du noch die Möglichkeiten, Pakete einfach mehrfach auszusenden.

[DrachenBernd]

Hallo Frank,

ja, UDP mag im Hobbykeller ausreichen solange nur eine Handvoll Regler rumfunken und jeder alles im Blick hat. Was passiert aber wenns mehr werden (Modultreffen und Co)? Jetzt habe ich etwas Erfahrung mit BiDiB (im Vergleich zum Z21-Proto sitzten hier die absoluten Nietenzähler ) und weiss es zu schätzen dass ich eine sichere Rückmeldung bekomme ob und was angekommen ist - das TCP-Protokoll zusammen mit der Sequenz-Nummer stellt das sicher. Bei UDP ist das nicht garantiert - nicht umsonst sieht die Z21-Protokolldefinition wohl vor dass sich jeder Handregler mindestens einmal pro Minute bei der Zentrale meldet, ansonsten fliegt er dort raus. Was macht die Zentrale mit der Lok die der Handregler hatte? Stoppen? Weiterfahren lassen? Und wie kriegt der Handregler das mit? Natürlich kann ich meine Lok abonnieren, muss das aber nicht - und falls ich es getan habe kann nicht sicher sein dass ich alle Meldungen bekomme und schon gar nicht in welcher Reihenfolge. Aber vielleicht gibt es ja einen Mitleser hier der diesbezüglich Erfahrungen hat und uns berichten kann wann und wie der Roco-WLAN-Handregler dem User mitteilt dass er die Verbindung verloren hat und was die Zentrale dann macht? Würde mich auch riesig interessieren!

Alaaf!
Bernd

[st-oldie]

Hallo Bernd,

Zitat

---

ja, UDP mag im Hobbykeller ausreichen solange nur eine Handvoll Regler rumfunken und jeder alles im Blick hat. Was passiert aber wenns mehr werden (Modultreffen und Co)? Jetzt habe ich etwas Erfahrung mit BiDiB (im Vergleich zum Z21-Proto sitzten hier die absoluten Nietenzähler ) und weiss es zu schätzen dass ich eine sichere Rückmeldung bekomme ob und was angekommen ist - das TCP-Protokoll zusammen mit der Sequenz-Nummer stellt das sicher. Bei UDP ist das nicht garantiert

---

Das stimmt zwar, daß das TCP Protokoll garantiert, daß ein Paket ankommt und UDP nicht. Aber bei dem Märklin Protokoll erlaubt das Protokoll selbst auch eine Überprüfung. Die Märklin CAN Nachrichten werden ja durch Nachrichten mit gesetztem Response Bit beantwortet. Aber auch wenn's mehr wird hat UDP Vorteile. Da die Zentrale Broadcasts versenden kann, muß sie nicht für jeden Client eine eigene Verbindung offen halten, auf der sie dann auch die Nachricht senden muß. Das kann auch zu insgesamt weniger Netzwerk Traffic führen. Wahrscheinlich hängt es von der Anzahl der Clients und der Aktivität der Clients ab, ob TCP oder UDP die bessere Wahl ist. Das müßte man dann im konkreten Fall wohl einfach testen.

Tschüß
Michael

[DrachenBernd]

Hallo Michael und sonstige Mitleser,

TCP oder UDP, das ist hier die Frage?
Auch hier bin ich kein Experte, vielleicht hilft mir jemand Kompetentes. Ich mach trotzdem mal den Anfang mit meiner Milchmädchenrechnung:
Maximale Annahmen:
- kleines Treffen von Verrückten, schnell sind die DCC-theoretischen 10000 Loks zusammen (was kostet ein Fußballstadion mit soviel Stehplätzen am Tag?).
- jeder hat ein WLAN-Regler und ist hoch nervös und etwas zittrig, weshalb er 10 Lokfahrbefehle pro Sekunde raushaut
- ein Lokfahrbefehl hat 10 Bytes im z21-Protokoll, schlagen wir noch 10 Bytes TCP-Overhead drauf, macht 20 Bytes
- jeder Fahrbefehl wird von der Zentrale quittiert, nochmal 20 Bytes
Macht pro Sekunde:
10.000*10*20*2 = 4.000.000 Bytes/s = 32.000.000 Bits/s ungefähr 32 MBits/s
Da im Moba-Keller ja gern uralt-Technik zum Einsatz kommt reicht schon ein 802-11g-WLAN aus um voll ausgelastet sein. Schock. Muss ich doch eine halbe Lok in einen 802-11ac-Router investieren? Da Rechner gerne mal 65536 Verbindungen halten können, heute schon mit Gigabit-Netzwerk ausgerüstet sind und ein paar Cores mehr haben ist das wohl kein Flaschenhals mehr - jetzt muss nur noch der DCC-Booster es schaffen 10000 Lok-Fahrbefehle auf die Schiene zu bringen. Eine einzelne Z21 schafft 100... macht ca. 320 KBits/s. Wenn jetzt jeder nur noch 1 Fahrbefehl pro Sekunde auslöst (eher schon viel?) bleiben 32 KBits/s.

Lange Rede kurzer Sinn: ich glaube das Argument "Netzwerktraffic reduzieren/klein/sparsam halten" sollte fallen gelassen werden, ist weder für udp noch für tcp ein Argument, ein Modultreffen mit 100 Fahrern/Reglern kann man schon mit einem originalen 802-11-WLAN managen, oder? Wichtiger ist wohl eher eine gute Switch die nicht nur theoretisch eine gute Bandbreite hat sondern auch liefern kann - da geht die 2. Hälfte meiner neuen Lok dahin.

Wo mache ich was falsch? Braucht meine Kuh ein neues Milchmädchen?
Bernd

PS: wenn die Mitbewohner über MEIN Wlan noch netflix in 4k streamen wollen wirds natürlich etwas eng... dann doch lieber ein eigenes Netz

[st-oldie]

Hallo Bernd,

Zitat

---

TCP oder UDP, das ist hier die Frage?
...
Lange Rede kurzer Sinn: ich glaube das Argument "Netzwerktraffic reduzieren/klein/sparsam halten" sollte fallen gelassen werden, ...

---

Ich hatte dabei auch weniger an den Traffic auf der Leitung bzw. WLAN an sich gedacht, sondern an die Rechenleistung in der Zentrale. Wenn statt einem UDP Broadcast die CPU der Zentrale jedem Teilnehmer eine TCP Nachricht versenden muß, ist das mehr Aufwand. Ich muß allerdings auch sagen, daß ich da keine genaueren Vorstellungen habe, wie stark die CPU dadurch wirklich belastet ist. Ich hab da nur unsere Switche so vor Augen, wo beim Pollen der RMON Counter oder der ATU über den MDIO Bus schon mal die konsumierte Rechenleistung hochgeht. Die CPU ist noch nicht am Anschlag, aber man merkt die Last deutlich. Und in der Zentrale sitzt ja nicht so eine leistungsfähige CPU wie in deinem PC.

Tschüß
Michael

[Pirat-Kapitan]

Moin,
das kommt aus das Display an.
ich habe ein 10 Zoll Display (touch), das via HDMI und USB mit dem RasPi verbunden wird, während mein 5 Zoll Display auf die GPIO-Leiste des RasPi aufgesteckt wird (daher habe ich keine Ahnung, welche Schnittstelle dort aktiv ist) und über einen HDMI-Doppelstecker mit dem HDMI-Port des RasPi (P2 oder P3) verbunden wird. Für die geänderte HDMI-Anschlussbuchsenanordnung am P4 wird es wohl dort nicht ohne Kabel gehen.

Zum Traffic: wenn ich mit dem Schieberegler bei Rocrail so schön über jede Fahrstufe scrolle, habe ich natürlich deutlich mehr Traffic als wenn ich die Fahrstufe über 1 Tastendruck direkt eingebe. Bei mehreren Loks (auf Fahrtagen habe ich über 10 gleichzeitig auf der Anlage) merkt man das schon sehr.

Farbdisplay: als Fahrpult nehme ich entweder monochrom Funkhandregler oder WLM, farbig eher Smartphone (Gewicht !). Beim Gleisbildstellpult komme ich um ein 7 Zoll Display als Mindestgröße nicht drumrum, auch dann wegen des Gewichtes eher Pad als RasPi mit Display.

Bei mir ist der RasPi mit Display (5 Zoll) nur im Zentralenkoffer als PC, Router und Server für das Modellbahnsteuerungsprogramm im Einsatz (mein Lastenheft).

Schöne Grüße
Johannes

[Pirat-Kapitan]

Zitat

---

Wo mache ich was falsch? Braucht meine Kuh ein neues Milchmädchen?

---

Moin Bernd,
vielleicht solltest Du mal die Saugleistung Deiner Melkmaschine (lies die Bandbreite und damit das maximale Fassungsvermögen des DCC-Protokolls) in Deine Überlegungen einbeziehen.
Bei meiner Zentrale ist bei 99 + 127 Loks gleichzeitig Schluss (Lokstapel in der Zentrale), unabhängig von der DCC-Bandbreite, andere Zentralen schaffen gerade mal 32 Loks.

Schöne Grüße
Johannes

[DrachenBernd]

Hallo Zusammen.

Danke für die Argumente. UDP : TCP = 0:1. Denn das Argument dass die Zentrale bei upd ja auch einfach mal einen Broadcast machen kann statt jeden einzelnen Client anzutippen zählt in meinen Augen nicht: wie oft kommt das vor? Bei der Z21 kann jeder Client die Loks und Weichen abonnieren von denen er gerne mehr hören will. D.h. die Zentrale schiebt m.E. nicht jedesmal einen Broadcast raus wenn sich an einer Lok was ändert sondern infomiert gezielt die paar Clients die davon hören wollen. Oder verstehe ich da die Z21-Protokolldefinition falsch? Und wenn mal ein Paket verloren geht dann schickt man halt einfach neu, geht also wenn man die Augen auf der Anlage hat, aber eine gute Absicherung sieht anders aus. Oder die Software schlußfolgert dann einfach bei verlorenen Loks aus den eingehenden Belegtmeldungen was das für eine Loks überhaupt nur sein könnte. Und die Z21 ist sicherlich als eine der neueren Zentralen deutlich leistungsfähiger als ältere Modelle. Und die wurde laut Beschreibung auf 100 Loks gleichzeitig beschränkt. Auch deine Zentrale, Johannes, ist mit 226 möglichen Loks nicht so weit weg dass die WLAN-Bandbreite wegen TCP zusammenbrechen würde. Und wenn ich dann eh einen PC zwischen Zentrale(n) und Handregler habe ist eher dessen Rechenleistung wichtig. Wie gut das funktioniert sieht man ja auch daran dass aktuelle Steuerungsprogramme ala iTrain mehrere Zentralen bedienen können.

Aber das ganze Diskutieren bringt ja nicht viel, die Z21 spricht nunmal UDP und dabei bleibt es auch erstmal, Jammern hilft nicht. Also wird mein Handregler das auch können (müssen). Aber als Handregler am netBiDiB wird er definitiv TCP sprechen, auch wenn wir noch etwas auf netBiDiB warten müssen . Also darf jeder das wählen was er gut findet

Gruß
Bernd

Saugleistung meiner Melkmaschine? Distributed Computing mit 100 GBM Boosts, muss ja alle 10000 Loks bewegen. Warte nur noch auf den Starkstromanschluss, das Milchmädchen dreht schon aus 0.25mm^2 Litzen das Anschlusskabel...

[st-oldie]

Hi Bernd,

Zitat

---

Danke für die Argumente. UDP : TCP = 0:1.

---

Das ganze ist doch kein Wettbewerb. Wenn man die Auswahl hat, benutzt man das, was man bei Berücksichtigung aller Anforderungen für das geeignetste hält. Wobei eine Einschätzung dann auch bei anderen Leuten zu anderen Ergebnissen führen kann.

Zitat

---

Denn das Argument dass die Zentrale bei upd ja auch einfach mal einen Broadcast machen kann statt jeden einzelnen Client anzutippen zählt in meinen Augen nicht: wie oft kommt das vor? Bei der Z21 kann jeder Client die Loks und Weichen abonnieren von denen er gerne mehr hören will. D.h. die Zentrale schiebt m.E. nicht jedesmal einen Broadcast raus wenn sich an einer Lok was ändert sondern infomiert gezielt die paar Clients die davon hören wollen. Oder verstehe ich da die Z21-Protokolldefinition falsch?

---

Ich kenne die z21 Spec nicht gut genug. Aber Clients sollten schon über alle Lok- und Magnetartikeländerungen informiert werden. Ich würde schon erwarten, daß zumindest diese Infos an alle Clients geschickt werden. Ich kenne das Märklin Protokoll besser, allerdings weniger das Verhalten einer CS2, da ich keine habe. Zumindest die Antwort mit gesetztem Response Bit bei Märklin sollte immer an alle Clients geschickt werden, damit jeder auch den aktuellen Status aller Loks und Magnetartikel kennt. Ich habe in meiner Software aber eingebaut, daß die angeforderten Konfigdateien nur an den Client geschickt werden, der sie angefordert hat um nicht andere Datenverbindungen oder den CAN Bus zu belasten.

Das Argument mit "wie oft kommt das vor" zählt in meinen Augen als Software Ingenieur nicht. Zumindest nicht bei professionellen Produkten. Auch in seltenen Fällen sollte ein System stabil laufen und kein undefiniertes Verhalten zeigen. Bei Basteleien im eigenen Keller kan nman natürlich seltene Fälle ausklammern, wenn man mit den Folgen leben kann.

Wir haben z.B. beim Mist61 bei den Fahrtagen mit Benutzung der Handy App für die Ecos das Problem, daß manchmal die Lok nicht auf den Befehl der Handy App reagiert, aber manchmal eine Lok Fahrbefehle bekommt, die wohl keiner abgesetzt hat. Das ist eigentlich ein No-Go für Fahrtage, da möglicherweise dann auch Auffahrunfälle passieren können. Ich werden am nächsten Wochenende mal einen Netzwertrace ziehen und schauen, ob etwas auffällt. Z.B. Bursts an Paketen, die dann möglicherweise die Ecos überlasten, Zusammenfassung von Fahrbefehlen bei TCP die die Ecos nicht richtig auswertet, ...

Zitat

---

Aber das ganze Diskutieren bringt ja nicht viel, die Z21 spricht nunmal UDP und dabei bleibt es auch erstmal, Jammern hilft nicht.

---

Stimmt, man muß sich immer mit den Gegebenheiten arrangieren.

Tschüß
Michael

[DrachenBernd]

Hallo Michael.

Zitat

---

DrachenBernd hat geschrieben: ↑
Mi 26. Feb 2020, 19:03
Danke für die Argumente. UDP : TCP = 0:1.

Das ganze ist doch kein Wettbewerb.

---

Richtig, wobei ich gehofft hatte dass sich der Videobeweis aus dem Keller gemeldet hätte

Zitat

---

Ich kenne die z21 Spec nicht gut genug. Aber Clients sollten schon über alle Lok- und Magnetartikeländerungen informiert werden. Ich würde schon erwarten, daß zumindest diese Infos an alle Clients geschickt werden.

---

Nein, da stimme ich nicht zu. Was juckt den einen Regler wenn eine Lok oder Weiche, mit der er im Moment nichts zu tun hat, geändert wird. Muss also auch nicht informiert sein. Wobei das Z21-Prot das ja auch macht: wenn man der Zentrale per Broadcast-Bit mitteilt dass man gerne informiert werden will dann passiert erstmal gar nichts. Wenn man dann eine Lok anfragt wird man von der Zentrale dann bis zum Abmelden der Lok mit Infos darüber informiert. Wobei: lustigerweise bekommt man eine Info ob die Lok gerade von einem anderen Regler belegt ist, überlässt es aber dem Regler/Benutzer was er tun will - wobei ich keine Erfahrung habe ob die Zentrale den anderen Regler irgendiw informiert dass er die Lok verloren hat oder ob dann beide Regler parallel bzw. gegeneinander arbeiten (aus der Protokollbeschreibung geht das nicht hervor). Bei iTrain als Z21-Verschnitt bekomme ich halt die Mitteilung über die anstehende Änderung, kann aber nichts dagegen machen. Schön wenn dann 2 Regler daran arbeiten - einer will bremsen, der andere Gas geben! Bei Weichen läuft das ähnlich nur dass da wohl tatsächlich eine Info über eine Änderungen an alle Clients geht die das Broadcastflag gesetzt haben. Der Client muss dann selber schauen ob ihn das was angeht oder nicht...
Wobei [Nietenzählermodus] ich noch keinen Lokführer getroffen habe der im Führerstand die Weichen stellen kann [/Nietenzählermodus], deshalb finde ich persönlich so eine Funktion am Regler leicht überflüssig. Wenn ich natürlich ein Tablet habe mit Stellwerk dann sieht das etwas anders aus, aber auch dann sollte der Client nur die Infos bekommen die er bei der Zentrale anfordert, mehr braucht er nicht bzw. belastet ihn nur unnötig.

Zitat

---

Das Argument mit "wie oft kommt das vor" zählt in meinen Augen als Software Ingenieur nicht. Zumindest nicht bei professionellen Produkten. Auch in seltenen Fällen sollte ein System stabil laufen und kein undefiniertes Verhalten zeigen. Bei Basteleien im eigenen Keller kan nman natürlich seltene Fälle ausklammern, wenn man mit den Folgen leben kann.

---

Genau so sehe ich das auch - und wohl auch alle (großen) kommerziellen Hersteller. Es würde mich trotzdem mal interessieren wie die Z21 z.B. funzt wenn man sie mit 99 Loks kurz unterhalb ihres theoretischen Limits bringt ... wobei:

Zitat

---

Wir haben z.B. beim Mist61 bei den Fahrtagen mit Benutzung der Handy App für die Ecos das Problem, daß manchmal die Lok nicht auf den Befehl der Handy App reagiert, aber manchmal eine Lok Fahrbefehle bekommt, die wohl keiner abgesetzt hat. Das ist eigentlich ein No-Go für Fahrtage, da möglicherweise dann auch Auffahrunfälle passieren können. Ich werden am nächsten Wochenende mal einen Netzwertrace ziehen und schauen, ob etwas auffällt. Z.B. Bursts an Paketen, die dann möglicherweise die Ecos überlasten, Zusammenfassung von Fahrbefehlen bei TCP die die Ecos nicht richtig auswertet, ...

---

da haben wir IMHO genau das Szenario: Treffen von soviel Leuten dass die Ecos an ihr Limit kommt - weit bevor das WLAN in die Knie geht. Natürich kann man den Leuten bei ESU (und Roco und Märtklin und...) keinen Vorwurf machen, die müssen ja auch nach wirtschaftlichen Gründen entwickeln und der Standardfall ist halt nun mal zu 95% der Keller mit max 20 Loks, wobei nur 3-5 gleichzeitig fahren. Was bei euch passiert? Meine Idee: der Netzwerkstack (oder irgendein Puffer zwischen Netzwerk-iN und Booster-Out) der ECOS läuft voll. Und wenn ein Empfänger nicht mehr empfangen kann legen die Switches vielleicht die Datenpakete auf Eis und senden sie später nochmal oder sie versuchen einen andern Weg, was auch Zeit kostet. So kommen die tcp-Pakete zwar irgendwann mal an, aber dann sind sie natürlich viel zu spät dran und schon längst überholt - Sequenznummern und Zeitstempel könnten sowas verhindern, reines UDP mit seiner "wir garantieren gar nichts"-Garantie des Ankommens aber auch nicht. Und auch ganz wichtig: die Rückmeldung der Zentrale an die Clients. Damit ich sehen kann ob meine Aktion irgendwas bewirkt hat.
Die ECOS(2) ist jetzt ja auch schon mindestens 10 Jahre alt, hat "nur" ein 100MBit Interface und wahnsinnige 64MByte RAM und einen 19 Jahre alten Prozessor und der muss auch noch alles bedienen - Booster, Sniffer, Railcom, Display, Regler, Touchscreen, einiges zeitkritischer als der Netzwerkverkehr...wow. Schnelles Googeln hat auch hier nichts erbracht in Hinblick darauf wie viele Loks die ECOS theoretisch gleichzeitg bedienen könnte. Weiss da jemand mehr? Wie viele Loks/Regler hattet ihr bei eurem Fahrtag wo die Probleme auftraten? Benutzt ihr dabei keine Software als Zwischenhändler sondern klinkt euch direkt in die ECOS ein? Vielleicht sollte die gängigen Übersichten über die Digitalzentralen (z.B. hier https://modellbahn.mahrer.net/technisches/zentralen/) auch eine Spalte aufnehmen mit der theoretisch maximalen Zahl von gleichzeitg fahrenden Loks.

Mann, da will man nur einen kleinen schnukeligen Handregler bauen und muss sich dann auf einmal mit tiefgehenden philosophischen Fragen rumschlagen.
Da geh ich mal lieber in den Keller und heul mich vor meinen paar Loks aus, die verstehen wenigstens (meistens) was ich will

Grüße
Bernd

[st-oldie]

Hallo Bernd,

schön, daß wir gar nicht soweit auseinander sind.

Zitat

---

Zitat

---

Ich kenne die z21 Spec nicht gut genug. Aber Clients sollten schon über alle Lok- und Magnetartikeländerungen informiert werden. Ich würde schon erwarten, daß zumindest diese Infos an alle Clients geschickt werden.

---

Nein, da stimme ich nicht zu. Was juckt den einen Regler wenn eine Lok oder Weiche, mit der er im Moment nichts zu tun hat, geändert wird.

---

Ich stimme dir da nicht zu. Denn ein Netzwerkclient kann auch eine Steuerungssoftware auf einem PC sein. Und z.B. sollte das Gleisbildstellwerk dort schon den aktuellen Status aller Magnetartikel anzeigen. Ein Netzwerkclient muß ja nicht zwingend ein Handregler für eine Lok sein.

Zitat

---

Wir haben z.B. beim Mist61 bei den Fahrtagen mit Benutzung der Handy App für die Ecos das Problem, daß manchmal die Lok nicht auf den Befehl der Handy App reagiert, aber manchmal eine Lok Fahrbefehle bekommt, die wohl keiner abgesetzt hat. ...

---

da haben wir IMHO genau das Szenario: Treffen von soviel Leuten dass die Ecos an ihr Limit kommt - weit bevor das WLAN in die Knie geht.
...[/quote]

Ich hab am Samstag mal einen Trace auf dem Netzwerk gemacht. Und ich habe keinen Kapazitätsengpaß gesehen. Die Loks, die unmotiviert gefahren sind, wurden vom der Handyapp angehalten, was auch die ECOS bestätigt hat. Allerdings gibt es manchmal Timeouts, wo die ECOS die Netzwerkverbindung schließt. Ich weiß aber nicht, ob das jetzt Timeouts auf der Protokollebene der ECOS sind. Das muß ich mal bei Gelegenheit untersuchen.

Da es nach den Beobachtungen wohl nur mfx Loks betrifft, also damit einen Decodertyp, hab ich eine andere Theorie. Ich vermute, daß die Gleisspannung eher an der unteren Grenze dessen ist, was der mfx Decoder als Digitalspannung erkennt. Es sind 18V, wobei unter der Last ja die Spanung auf etwas unter 18V absinkt. Ich hab aber Infos gefunden, daß das Gleisignal ein Rechtecksinglan zwischen +22V und -22V ist. Analog hat man maximal 16V. Das müssen wir dann aber beim nächsten Fahrtag noch testen.

Tschüß
Michael

[Johann]

Zitat von DrachenBernd im Beitrag #15

---

Willkommen im neuen Jahr.

Bevor es mit anderer/besserer Hardware weitergeht hier ein kurzer Zwischenstand: den mechanischen 1-Euro-Drehregler habe ich durch einen optischen ersetzt, jetzt verliert auch das Raspi-Python-Gespann nicht mehr den Überblick in welche Richtung es geht und so (auch meine Versuche mit einer elektrischen Entprellung waren nicht von Erfolg gekrönt). War ich zu schnell unterwegs hat das Prellen der Taster mehr vorgetäuscht als eigentlich gedreht wurde, war ich zu langsam hat die Software gedacht es geht schon wieder rückwärts. Ein guter Mittelwert war nicht zu finden der die Kiste nicht allzusehr belastet aber auch bei schnellem Drehen alles korrekt mitbekommt.
Positiver Nebeneffekt des Neuen: das Teil hat 32 statt der bisher 20 Halbschritte. Ein Dreh und man ist am Anschlag bei 28 Fahrstufen.

---

Moin.

Ich grab den alten Thread mal aus, weil ich mich gerade ein wenig mit Plaenen zum Selbstbau von Zentrale und Regler plage.
Nachdem hier optische Drehgeber erwaehnt wurden, habe ich mal nachgeschaut: Uiuiui, das sind ja ganz schoen happige Preise, die da aufgerufen werden, deutlich im zweistelligen Bereich.

Zum Entprellen der 'normalen' mechanischen Regler:
Was hast Du denn da versucht?
Nachdem ich mal mit so einem Regler herumgespielt habe, sah ich schnell, dass das Ding prellt wie Sau.
Und weil eine Entprellung in Software ein Wuergaround ist, kam nur eine Loesung in Hardware in Frage:

Im wesentlichen bin ich auf anderen Wegen zu dieser Loesung, wie hier (>https://www.youtube.com/watch?v=b2uUYiGrS5Y) beschrieben gekommen.
Zunaechst wie hier (>https://www.digikey.com/en/articles/how-to-implement-hardware-debounce-for-switches-and-relays) beschrieben RC-Glieder an die Encoderpins gehaengt, das besserte es schon sehr, war aber noch nicht perfekt.
Da Digikey auch sagt, dass der Ausgang des RC-Glieds noch durch einen Schmitt-Trigger geschickt werden soll, kam dafuer ein LM393/LM339 sowie die notwendigen Widerstaende (>https://www.random-science-tools.com/electronics/inverting-schmitt-trigger-calculator.htm) zum Setzen der Schaltschwellen zur Schaltung hinzu, dann war es perfekt.
Da prellt nix mehr, Drehrichtung wird sauber erkannt, Geschwindigkeitsmaessig erkenne ich keine Auffaelligkeiten.

Gruesse
Jo

[RaSt]

Hallo Bernd, hallo Jo

Zitat von DrachenBernd im Beitrag #41

---

Mann, da will man nur einen kleinen schnukeligen Handregler bauen und muss sich dann auf einmal mit tiefgehenden philosophischen Fragen rumschlagen.
Da geh ich mal lieber in den Keller und heul mich vor meinen paar Loks aus, die verstehen wenigstens (meistens) was ich will :

---

Ich klopfe mal vorsichtig an...
Bei meiner Suche nach einem "Funk-Handregler" bin ich auf diesen hier beschriebenen WLan-Handregler gestoßen.
Wenn ich nicht doch etwas übersehen habe, war es wichtig einen Handregler zu haben der einen großen Drehknopf hat und über möglichst viele Funktionstasten verfügt.
Weichen oder Magnetartikel sollen nicht geschaltet werden können.
Genau so einen Handregler suche ich!!
Wenn dann auch noch die Möglichkeit besteht, die Tasten frei zu belegen, wäre das noch besser!

Dann sehe ich, das in diesem Thread schon längere Zeit nicht mehr geschrieben wurde... Nun meine Frage(n):

Ist das Projekt eingeschlafen und wird nicht weiter verfolgt?
Wenn nicht, besteht die Möglichkeit die nötige Software zu bekommen?
Könnte hier nochmals aufgelistet werden, welche Komponenten final verwendet wurden?

Gespannte Grüße,
Ralf