Beiträge von Vincent Hamp

v0.2.1 ist online

• Bugfix diverse kleine Fehler beim Controller
• Bugfix MN-Decoder wurden beim Update nicht erkannt
• Bugfix Bug LED leuchtet nun im Service Mode
• Bugfix RailCom Datagramme die ein ACK enthielten wurden verworfen (betrifft ESU Decoder)

Hab heute vergeblich versucht die "mDNS" Probleme unter Android und Windows zu beheben, leider ein unmögliches Unterfangen. Aus diesem Grund gibt es jetzt eine v0.2.0 bei der man sowohl im Captive Portal als auch in den normalen Optionen eine statische IP Adresse vergeben kann.

v0.0.9 ist online

• Neues Fahrpult (Beta)
  Das Fahrpult hat ein Update bekommen und fängt langsam an meinem optischen Anspruch gerecht zu werden. Eine der größten Änderungen ist dass sich das Fahrpult nun anders verhält, je nachdem ob man vor einem kleinen oder großen Display sitzt. Ist der Bildschirm groß genug (Desktop), dann bekommt man ein verschiebbares Fenster, ist der Bildschirm klein (Smartphone), dann füllt das Fahrpult ihn aus. Dieses Verhalten kann man übrigens auch direkt am PC testen, wenn man das Browser Fenster kleiner oder größer macht.
  Für Lokbilder gibt es nun bereits einen Platzhalter, RailCom Daten (Geschwindigkeit und Quality-of-Service) werden, sofern der Decoder diese Daten liefert, angezeigt. Das "Program" Fenster in der Mitte ist noch nicht funktionstüchtig, hier werde ich demnächst CV Programmierung für POM- und Service-Mode hinzufügen. Wie genau die Bedienung funktioniert (z.B. wie man etwa auf verschiedene "F-Ebenen" umschaltet) werde ich bald mal in einem Video erklären.

  
  

• Die "Bug" und "WiFi" LED ist nun per Einstellung dimmbar

• Beim schließen des Frontends kommt ein Bestätigungsdialog (wenn möglich, mobile Browser unterstützen dies teilweise nicht)

• Bugfix CV-Nack Meldungen wurden im

• Program Screen nicht richtig angezeigt

• Bugfixes WebSockets
  Die Batch-Größe der WebSocket Nachrichten wurde für alle Services (Updates, Soundladen, DCC, etc.) auf 32 festgelegt. Gleichzeitig wurde die Größe der internen "receive mail boxes" im ESP32 für TCPIP/TCP und UDP auf 64 angehoben. Alle Übertragungen laufen nun über Core0. Serverseitige Schließungen eines Sockets führen nun zu keinem Absturz des Frontends mehr sondern werden erkannt und entsprechend gemeldet.

Großartig die Fotos

v0.0.8 ist online

• Bugfix Speicherfehler beim Parsen des WebSocket Frames
• Bugfix mDNS am ESP32 unterstützt keine Subdomains (das heißt statt etwa my.remise.local muss man my-remise.local nutzen)

Zitat von Vincent Hamp

Kurze Warnung an dieser Stelle. Aktuell vermiest einem noch folgender Bug in Espressifs ESP-IDF Framework ein wenig den Spaß:
https://github.com/espressif/esp-idf/issues/15235

Dieser Fehler führt dazu dass WebSocket Übertragungen vom S3Main an den Browser zufällig serverseitig fehlschlagen können. Das gefällt dem in Flutter geschriebenen Frontend leider überhaupt nicht es kommt zu einem sofortigen Freeze der ganzen App. Ich kann leider schlecht vorhersagen wie oft der Fehler auftreten wird, da er stark von der Qualität des Netzwerks abhängt. Bei mir daheim hatte ich bei durchschnittlicher Netzwerkqualität noch nie ein Problem, heute im Büro hatte ich bei ~6h Betrieb einen so einen Freeze.

Ich habe diesen Fehler bereits am 20.01. bei Espressif gemeldet, aber er wurde leider bis jetzt nicht behoben.

Nachdem man sich bei Espressif auch nach 4 Monaten nicht bemüßigt fühlte das Problem zu beheben und mir die letzten 2 Wochen schlichtweg gar nicht mehr geantwortet hat hab ich das Problem jetzt selbst gefixt...

Tests laufen. Update gibts dann irgendwann im Laufe der nächsten Woche.

Und hier noch eine Idee fürs neue Fahrpult

controller.jpg

Bitte unbedingt vorbei bringen. Heiß werden sollte der Decoder auf gar keinen Fall, schon gar nicht nach ein paar cm Fahrt!

Ein sporadisch verschwindender Sound bei Erwärmung deutet wie bereits andere Nutzer angemerkt haben auf eine schlechte Lötstelle.

Kurze Warnung an dieser Stelle. Aktuell vermiest einem noch folgender Bug in Espressifs ESP-IDF Framework ein wenig den Spaß:

ESP32-S3 specific WS message lengths cause `WS frame is not properly masked` error (IDFGH-14461) · Issue #15235 · espressif/esp-idf

Answers checklist. I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there. I have updated my IDF branch (master or…

github.com

Dieser Fehler führt dazu dass WebSocket Übertragungen vom S3Main an den Browser zufällig serverseitig fehlschlagen können. Das gefällt dem in Flutter geschriebenen Frontend leider überhaupt nicht es kommt zu einem sofortigen Freeze der ganzen App. Ich kann leider schlecht vorhersagen wie oft der Fehler auftreten wird, da er stark von der Qualität des Netzwerks abhängt. Bei mir daheim hatte ich bei durchschnittlicher Netzwerkqualität noch nie ein Problem, heute im Büro hatte ich bei ~6h Betrieb einen so einen Freeze.

Ich habe diesen Fehler bereits am 20.01. bei Espressif gemeldet, aber er wurde leider bis jetzt nicht behoben.

Ich wurde vom PCB Dienstleister meiner Wahl grad eben verständigt dass ein paar Boards eingetrudelt sind.
Hab den Getting Started Bereich auf openremise.at mal geupdated.

Fahrplan für die nächste Zeit

• Erstes Video/Tutorial erstellen dass die Update-Funktionen vorstellt
• DCC Betrieb vervollständigen, sprich
  - 64 Funktionen bei Loks schaltbar machen
  - Einlesen und Anzeigen aller RailCom Daten
  - Zubehördecoder, sowohl in der Firmware als auch im Web-Interface
• Komplett neues Fahrpult
  - Einfachere Bedienung, CV Lesen/Schreiben direkt vom Fahrpult, MAN-Taste, Adresswechsel, usw.
  - Anzeigen von RailCom Daten
  - Verschiebbares Fenster bei Desktop / Tablet Anwendung
  - Eventuell Haptik ("Feedback") bei Betrieb auf Smartphone
  - Linkshänder Option?
• Kleine Testanlage bauen

Grüß euch

Ich möchte ein Projekt vorstellen an dem ich nun schon seit zu langer Zeit arbeite. Es handelt sich um eine kleine Open Source Zentrale mit Decoder Update Funktion und inkludiertem Web Server. Das Design wurde sehr stark von der Tams mc² geklaut inspiriert. Zwar arbeitete ich bereits davor an einem Testgerät für den Privatgebrauch, aber die Schlichtheit grundlegende Dinge wie z.B. einen Decoder zu programmieren ohne dafür die X-te App installieren zu müssen hatte mich einfach überzeugt.

Das Projekt hört auf den Namen

logo.png

und nähert sich sehr langsam einem Status in dem man damit etwas anfangen kann. Unter openremise.at gibts auch eine eigene Homepage auf der bestmöglich neue Infos, FAQ, Tutorials, usw. erscheinen. Ein Getting Started Guide etwa steht dort bereits zur Verfügung.

Hardware
Die OpenRemise Firmware läuft auf dedizierter Hardware. Die erste Platine hat den kreativen einfallslosen Namen S3Main und sieht folgendermaßen aus.
s3main_0.1.0_1.png
Das Board besitzt

• einen 10-22V DC Eingang
• einen Schienenausgang mit einstellbarer Strombegrenzung (0.5, 1.3, 2.7 and 4.1A)
• eine USB-C Buchse
• eine SUSI Buchse
• eine 40Pin IDC Buchse für Erweiterungen

Die Platine wird in Kürze im PCBWay Bazaar erhältlich sein, aber natürlich kann jeder das Projekt nehmen und bei einem PCB Dienstleister seiner Wahl bestellen.

Software
Ohne Software ist das S3Main natürlich nur ein hübscher blauer Briefbeschwerer, also was kann die aktuelle Software bereits?
Da der Fokus der Entwicklung in erster Linie auf Decoder Updates lag beherrscht die aktuelle Version

• Updaten von allen mobilen ZIMO MN-, MS- und MX Decodern
• Laden von Sound-Projekten (oder generellen Projekten) für alle ZIMO MN-, MS- und MX Deccodern
• DCC Betrieb von Lokdecodern
• Z21 Protokoll als lingua franca, sprich Z21 App, JMRI, Z2X-Programmer, ZCS und vermutlich viele mehr...

Wer sich ein Bild davon machen will wie die Bedingung übers Web Interface aussieht kann dies gerne tun, denn davon gibt es eine
>>> Demo <<<

M62

Aktuell nicht nein.

Ja definitiv, je nach Art des Sounds gibt es dafür auch X verschiedene Methoden. Sollte es sich um einen einfachen "Funktionssound" handeln, dann gibt es im ZSP eigene Häkchen dafür.

Screenshot_20250217_144121.png

Sollte es sich um ein bereits fertiges Projekt handeln, dann kann man via sogenanntem "Eingangs-Mapping" (CV400 und drüber) sehr einfach eine Richtungsabhängigkeit erzielen.

Oder via Schweizer Mapping... oder oder oder

Zitat von Huebsch

Wenn's bei der Kombi Decoder/Programmer zu Schwierigkeiten kommt willst Du dann als Kunde wirklich zwischen den beiden Herstellern sitzen und drüber diskutieren wer Dir weiter helfen soll?

Das Problem existiert halt jetzt in exakt dieser Form auch schon, etwa zw. Zentrale und Decoder, oder zw. Lok und Decoder. Meine Arbeit würde sich durch eine herstellerübergreifende Programmierschnittstelle nicht im Geringsten ändern, ich suche auch jetzt bereits Fehler in Geräten von Mitbewerbern und Mitbewerber Fehler in ZIMO Geräten...

Ich red auch nicht von MFX, sondern von DCC-A. Wir haben die (damalige) Norm-Implementierung live auf einer mc² vorgeführt. Von so Späßen wie FileTransfer red ich nicht, die halt ich ebenfalls für sinnlos.

/edit

Man kann von Hr. Ziegler halten was man will, wenigstens kommt er noch mit Ideen. Wann kam denn das letzte mal eine brauchbare Idee von irgendwo anders, außer vielleicht von der BiDiB Seite?

Wir hatten übrigens schon lange vor der aktuellen DCC-A Norm eine eigene Anmeldung implementiert. Die funktionierte ebenfalls. Dummerweise leidet ZIMO aber an Torschusspanik, sobald etwas irgendwann irgendwie ein einziges Mal funktioniert hat wird die Sache liegen gelassen und irgendwas anderes angerissen...

Zitat von Huebsch

Daran scheitert ZIMO faktisch immer, da werden schöne Dinge beschrieben, damit Normungen aufgehalten. Aber es wird einfach nie implementiert, daher auch nicht vorgeführt. Da braucht man nicht drüber jammern daß die Normung da nicht mitmacht.

Genau, und die Live Vorführung der Anmeldung an einer mc2 vor 2 Jahren haben wir natürlich gefaked, quasi die Mondlandung der MoBa Welt.

Zitat von Hombre

Ich lasse mich aber sehr gerne positiv überraschen vom ersten Hersteller, der sein Programmiertool für fremde Zentralen kompatibel macht. DAS wäre für mich ein echter Mehrwert.

Ich mache das gerne für alle Decoder Hersteller die ihre Schnittstellen offen legen. Hier ist eine extensive dieser Hersteller:

• ZIMO

Zitat von wissbegierig

Hi,

da könnten wir uns im BiDiB und Rocrail Forum treffen.

Die wollten dieses Thema auch schon angehen.

BidiB Forum ist eine Anmeldung erforderlich.

https://forum.opendcc.de/viewtopic.php?t=9804

Mfg

Didi L

Alles anzeigen

Dann sollten sie ihre Foren vielleicht auch frei zugänglich machen. Im BiDiB Forum braucht ma für jedes der "Entwicklungs" Subforen eigene Berechtigungen, das Rocrail Forum kann ich ohne Account nicht mal öffnen...

Zitat von 2102michael

Heute sollte sich das platzmäßig ausgehen. Dann könnte man auf CV pfeifen, jeder Hersteller sein proprietäres Software Interface bauen das dann selbst vom DAU zu bedienen wäre.

Ähnlich wie ein Booster könnte ein Stück HW das Signal der DCC Zentrale abgreifen und in WLAN Signale umwandeln und an die Dekoder senden.

Das heißt es wäre kein Problem für dich nur noch Decoder eines Herstellers zu verbauen? Vl. sind die Hornby Bluetooth Decoder was für dich.

Zitat von 2102michael

Die CV und Datenübertragung über die Gleise ist meiner Meinung nach Technologie der 1980er, vielleicht zeigen sich Hersteller mal innovativ und definieren einen Standard der 2020er Jahre.

Die RailCommunity ist leider völlig festgefahren. Ich glaube nicht dass irgendeine Innovation aus ihr hervorgehen kann. Man muss sich nur einmal ansehen was aus DCC-A (automatische Anmeldung) geworden ist.

Für mich als Entwickler heißt SUSI vor allem eins, ein Haufen inkompatibler Module auf Grund undokumentierten Erweiterungen einiger Hersteller sowie eine zu DCC widersprüchliche Norm bei der oft die wichtigsten Dinge wie etwa die Taktfrequenz nicht eingehalten werden.

Aktuell steht die Rückwärtskompatibilität mit den MX-Decodern an erster Stelle. Ein ESU Mapping entspricht nicht der ZIMO Philosophie, weil es ohne Programmer quasi nicht zu bedienen ist.