[BETA] OpenKNX Dali Gateway - powered by REG1

[MCR007]

Hallo Mike,


beim weiteren testen der Ver.0.6 ist mir noch folgendes aufgefallen.


Bei den DT8 bekomme Ich keine Status Rückmeldung der Farbe wenn Ansteuerung per xy.
Auch nicht bei Leseanforderung.
image.png
egal ob mit oder ohne Helligkeit.
Bei TW und RBG klappt alles.
EVGs steuern auch bei allen Modis die richtigen Werte an.


Dann habe Ich ein bisschen mit HCL gespielt.
Wenn Ich den Mode aktiviere funktioniert das soweit wie in den neuen Parametern eingestellt.

Es gibt allerdings eine neue GA "HCL Kurve" 8Bit vorzeichenlos.
Damit kann ich noch nichts anfangen.
Wenn ich versuche die zu schreiben bekomme Ich in der Konsole nur die Meldung: WARNING: You used and invalid Dpt *.0

Wenn Ich eine DT8 über xy betreibe und dann HCL starte klappt das soweit.
nur der Status xy wird dann mit TW beschrieben. hier hier 2400k
image.png


Grüße Markus

[derneugierige]

Wenn du da besser Ideen hast gerne her damit

Für Ideen braucht es erst einmal eine Problemstellung.

Gibt es ein Problem mit der aktuellen Schaltung? Wenn ja: welches? Wenn nein: warum soll die geändert werden?

Soweit ich erkennen kann ist diese Schaltung deutlich besser als die aus der App-Note.
+ Zieht aus dem Bus konstant 1.7mA, unabhängig von der Bus-Spannung
+ Dadurch keine asymmetrische Verschiebung der Flanken bei Bus-Spannungsschwankungen
+ Stirbt nicht wenn man versehentlich 230V dranklemmt

Können dich auch gerne mal in unseren Support Slack vorerst einladen oder auch privat wo, da lässt sich sowas besser besprechen als hier.

Slack kenne ich (noch) nicht. Ist das sowas wie Teams?

Der ESP bietet uns halt viel Flexibilität in Sachen Netzwerk, die wir mit dem rp2040 niemals bekommen würden. Auch die Kompatibilität von den Netzwerkabhängigen Libraries ist unter esp deutlich besser.

Ja, die Vorteile der ESP sehe ich durchaus. Die Suche nach den Sourcen für die ESP-Toolchain und das Bauen der Toolchain steht allerdings irgendwo an Position 327 der ToDo-Liste... =:-O

[jeff25]

Viel suchen muss man da ja nicht.... GitHub - espressif/esp-idf: Espressif IoT Development Framework. Official development framework for Espressif SoCs.

[derneugierige]

Viel suchen muss man da ja nicht.... GitHub - espressif/esp-idf: Espressif IoT Development Framework. Official development framework for Espressif SoCs.

Soweit ich erkennen kann, wird hier die Toolchain nicht compiliert, sondern bereits compilierte Toolchain-Binaries runtergeladen.

[jeff25]

keine Ahnung über sowas mach ich mir keine Gedanken.

[thewhobox]

Wir haben keinen Anspruch die Tool chain selbst zu kompilieren. Wenn du da andere Anforderungen hast ok.

Es gibt immer Potential Schaltungen zu verbessern. Dafür müssen nicht immer Probleme da sein.
Wir können es auch nicht eingrenzen, aber es kommt bei einigen vor, dass unsere Schaltung Telegramme nicht korrekt empfängt. Um das warum zu klären, fehlt uns einfach das tiefere Wissen.

Mit der Schaltung die neu kommt, kommt von einem Hersteller. Diese ist bereits erpropt und hat auch bei ersten Test deutlich bessere Kommunikation gezeigt.
Deswegen der Umschwung.

[traxanos]

bereits compilierte Toolchain-Binaries

na und? wenn ich auf sowas wert lege muss ich auch echte open hardware nutzen. also runter bis aufs chiplayout. denn anspruch hat von uns keiner. somit juckt das keinen. ich sehe die toolchain als teil der hardware an. so wie ich auf einem pc opensource nutze obwohl das efi das sicher auch nicht ist.

ich denke du hast einfach andere ansprüche. wir wollen einfach nur smarthouse lösungen für knx bauen.

EDIT: hab einen satz korrigiert und das "KEINE" entfernt was du einem falschen inhat geführt hat .

[thewhobox]

MCR007
Vielen Dank für die Rückmeldung.
Mit Xy hab ich ehrlich gesagt noch nicht viel gemacht. Kann gut sein, dass der Status einfach noch nicht implementiert wurde.
Funktioniert denn die Ansteuerung korrekt mit Xy?

Das neue KO für die Hcl Kurve gibt die aktuelle Temperatur nach der Kurve aus, damit diese evtl auch außerhalb des GW verwendet werden kann.
Das KO ist nicht zum Schreiben gedacht.

[MCR007]

thewhobox

Hallo Mike,

das ansteuern über xY funktioniert.

Ich meine nicht die GA unter dem Reiter HCL Kurven, die funktioniert.
Ich meine die unter Einzeladressen bzw. Gruppen.
image.png
Gruß Markus

[thewhobox]

Also GA ist es schon mal gar nicht^^
GA ist die Gruppenadressen (4/2/3), welche mit KOs (Kommunikationsobjekten 129) verbunden wird.
Was du im Screenshot siehst ist ein Parameter um Hcl für dieses EVG/Gruppe zu aktivieren. Im den Hcl Eigenschaften dann (links am evg auf das +) kannst du ja dann nur auswählen, welche Kurve.
Das KO was dann auftaucht kann die Hcl Kurve auch nachträglich noch ändern.
Praktisch, wenn man zwei Kurven hat (Sommer/Winter), kann man da umschalten.

Waruk dann allerdings die Fehlermeldung mit dem DPT kommt werde ich mir anschauen.

[derneugierige]

Wir haben keinen Anspruch die Tool chain selbst zu kompilieren. Wenn du da andere Anforderungen hast ok.

Wie gesagt, sehe ich das bei chinesischem Ursprung kritisch.

Es gibt immer Potential Schaltungen zu verbessern. Dafür müssen nicht immer Probleme da sein.

Ja, verbessern. AFAICS ist aber die aktuelle Schaltung besser als die neue. Siehe oben.

Wir können es auch nicht eingrenzen, aber es kommt bei einigen vor, dass unsere Schaltung Telegramme nicht korrekt empfängt.

Dann wäre aber doch der richtige Schritt nicht der auf eine Schaltung zu gehen die offensichtlich minderwertiger ist und noch nicht einmal der Spec entspricht sondern der, das Problem näher einzukreisen?

Dass Telegramme nicht korrekt empfangen werden könnte doch auch ein Problem in der Firmware sein?

Interessant wäre, ob bzw inwiefern die Flanken evtl asymmetrisch verschoben werden. Kann vielleicht jemand eine Oszi-Aufzeichnung am Ausgang von U1 einstellen wenn man am DALI-Stecker ein 16V-Rechteck mit 1200Hz einspeist zusammen mit dem Rechteck? Evtl auch mit 9.5V sowie 22.5V?

Mit der Schaltung die neu kommt, kommt von einem Hersteller. Diese ist bereits erpropt und hat auch bei ersten Test deutlich bessere Kommunikation gezeigt.
Deswegen der Umschwung.

??? Es ist also nicht die Schaltung aus der AN, wie @Ing-Dom oben schrub?

[thewhobox]

Toolchain: Wie gesagt, für uns nicht.

Wenn das für dich offensichtlich ist. Okay, wie wiederholt gesagt, ist es das für uns nicht, da einfach keine erfahrung damit.

Es wurde die selbe Software mit zwei Hardware getestet. Unsere und die von Micro Chip.
Die von MC hat besser funktioniert.
Ich gehe also nicht von der SW aus.
Das Senden ist auch eig gar nicht das Problem sondern eher das Empfangen.
https://www.microchip.com/content/da...tes/01465A.pdf

Soweit ich weiß ist das nun 1:1 die Schaltung der neuen PCB,welche kommen wird.


P. S. Problem ond der Aktuellen Schaltung ist auch, daß sich der Mosfet vom Senden aufhängen kann, zu heiß wird und dann abfackelt.

[derneugierige]

Es wurde die selbe Software mit zwei Hardware getestet. Unsere und die von Micro Chip.

Auch mit unterschiedlichen Bus-Spannungen?

Das Senden ist auch eig gar nicht das Problem sondern eher das Empfangen.

Ich rede ja auch die ganze Zeit vom Empfangen und nicht vom Senden.

Wie oben geschrieben, hat die Schaltung aus der MC-App-Note auf der Empfangs-Seite IMHO folgende Probleme:

1. Der aus dem Bus bezogene Strom ist stark abhängig von der Bus-Spannung: I=(Ubus−1,4V−1,25V−4,8V)÷2200Ohm. Das sind 0.93mA an der Untergrenze von Ubus=9.5V bzw 6.8mA an der Obergrenze von 22.5V. Bei der typischen Bus-Spannung von 16V ist der bezogene Strom mit 3.8mA fast doppelt so gross als die laut DALI-Spec zulässigen 2mA.
2. Die Transfer-Eigenschaften von Optokopplern sind stark abhängig vom Vorwärtsstrom der internen LED und damit bei der MC-Schaltung auch von der Bus-Spannug. Dabei wird das Zeitverhalten der fallenden Flanke anders beeinflusst als das der steigenden Flanke. Das bedeutet, dass abhängig von der Bus-Spannung das Zeitverhalten auf der TTL-Seite vollkommen unterschiedlich verfälscht wird.
3. Generell haben Optokoppler Probleme bei höheren Frequenzen und geringen Strömen. Hier wirken sich Chargen-Streuungen um so mehr aus.

Die ersten zwei Probleme hat die ursprüngliche Schaltung nicht: Hier sorgt die Konstanstromquelle dafür, dass der Vorwärtsstrom unabhängig von der Bus-Spannung immer (nahezu) gleich ist. Damit wird das Signal nur noch durch die Chargen-Streuung der Optokoppler verfälscht. Hier müsste man evtl ein bisschen nachjustieren, um die Verzerrung der Flanken so geraderücken, dass sowohl steigende als auch fallende Flanken gleich stark verzögert werden. Alternativ könnte man in der FW grössere Toleranzen zulassen bzw an die unterschiedlichen Verzögerungen anpassen.

Um das genauer beurteilen zu können hatte ich ja nach einem Oszi-Bild gefragt.

P. S. Problem ond der Aktuellen Schaltung ist auch, daß sich der Mosfet vom Senden aufhängen kann, zu heiß wird und dann abfackelt.

Uh? Also hier wäre mein Verdacht eher, dass die FW "vergisst" D_TX auf Low zu setzen. Dann würde genau dieses passieren. Hier könnte ein passend dimensionierter Kondensator (in der Grössenordnung von 1nF..10nF oder so) in Reihe zwischen R10 und U2 mit einer Entlade-Diode eine Lebensversicherung für den Transistor darstellen. BTW: die Zeitkonstante von R7*C1 scheint mir für 1200Hz etwas zu grosszügig zu sein.

Auch hier wären ein paar Oszi-Bilder eines 1200Hz-Rechtecksignals interessant.

Die Dimensionierung mag an einigen Stellen evtl ungünstig sein. Das grundsätzliche Design ist aber deutlich besser als das aus der MC-App-Note, IMHO.

[IOException]

Hey 👋 erst einmal vielen Dank für so ein cooles Projekt!
Ich habe ganz frisch ein OpenKNX-DALI-Gateway, zusammengebaut und mit der Applikationsversion 0.6 versehen.
Auf dem Broadcast Schalten funktioniert auch schon perfekt 🤩
Leider habe ich, wie auch schon jemand vor mir in dem Thread das Problem mit dem Scannen nach Adressen.
Hier kommt bei mir auch in der ETS (5.7) die Fehlermeldung:

Parameterscript: Fehlgeschlagen
Das Gerät antwortet nicht.
Verbindung: MDT KNX IP Interface (10.10.50.8:3671)

Hat jemand da für mich ein Hinweis?
Ansonsten kann ich gerne auch beim debuggen helfen (Programmierkenntnisse sind vorhanden 😋)
Vielen Dank schon einmal

[thewhobox]

IOException
Wenn das Gerät nicht antwortet kann das viele Fehlerursachen sein.
- Routing und physikalische Telegramme werden gefiltert (sehe aber du verwendest Tunneling)
- Tunneling zur falschen Linie
- Gerät hat eine andere PA (evtl nach Update oder Reset)
- Gerät hat sich aufgehangen und antwortet wirklich nicht mehr.

Funktioniert denn der Programmierknopf noch, also das Gerät ansprechbar?
Kannst du die GeräteInfo auslesen?

Für die Kommunikation zum Gerät ist die ETS verantwortlich.
Sprich es wird die Verbindung gewählt, die oben Rechts in der Auswahl ausgewählt ist.
Wenn du mehrere hast und es noch auf Automatisch steht, könnte die falsche genommen werden.

Gruß Mike