selfbus.org

Moin!

Im Rauchmelder-3.4 Thread ist das Thema "Stromversorgung" aufgetaucht (viewtopic.php?t=395, vor allem Seite 3). Da es aber mehr als nur den Rauchmelder betrifft, mache ich mal einen eigenen Thread dafür auf.

Ich glaube, die grundsätzliche Frage ist, was wir bei Abfall der Busspannung tun. Laut KNX Spezifikation müssen wir unterhalb von 20V schweigen, sollten tun, was auch immer wir als Shutdown tun müssen (ggf. Zustände speichern?), und wenn die Spannung so tief fällt, dass wir nicht mehr arbeiten können, müssen wir abschalten.

Wir haben die Hardware zur Überwachung der Busspannung auf unseren Platinen. Oder zumindest auf denen, die ich bisher angeschaut habe. Das heißt, wir sind im Prinzip in der Lage, die CPU sauber herunterzufahren.

Der 4TE-Controller und der Rauchmelder-3.4 haben einen Spannungsteiler am enable-Pin des Spannungswandlers, der irgendwo undefiniert unterhalb einer Busspannung von 22.3V den Spannungswandler und damit die CPU abschaltet (Details dazu siehe Rauchmelder-Thread). TS-ARM hat eine solche Vorrichtung nicht, sondern hängt den enable-Pin direkt an die Eingangsspannung. Das heißt, die CPU hat Strom, bis die Eingangsspannung am Regler auf 6V abgefallen ist. Andere Module habe ich mir noch nicht angesehen.

Ich habe mal mit der TS-ARM nachgemessen. Messung zwischen dem EIB+ Pad und GND, also die Spannung, die auch der uC als Busspannungsüberwachung sieht bzw. die am Eingang des Reglers liegt. Um einen Abfall der Busspannung zu simulieren, habe ich einfach die Klemme abgezogen. Schneller kann der Bus nicht abfallen.

Ab dem Zeitpunkt, an dem wir 19.3V messen (wegen der 1N4148 entspricht das 20V auf dem Bus, d.h. hier müssen wir aufhören zu senden), haben wir 300ms bis 7.5V. Nach rund 320ms sind wir bei 6V, der Regler geht aus und damit auch die CPU. Schön zu sehen im Bild, da wo der Spannungsabfall einen Knick hat.



Natürlich laufen hier keine LEDs und wir müssen keine Relais mit Strom versorgen. Aber in dieser Anwendung hätten wir komfortabel Zeit, noch unseren Zustand zu speichern, bevor das Licht ausgeht. Auf dem 4TE-Controller sitzen noch weitere Kondensatoren, und wenn wir dort Verbraucher wir LEDs und Relais sofort abschalten, müssten wir auch noch genügend Zeit für ein geordnetes Abschalten haben.

Ich denke, dass wir mit der Schaltung wie im TS-ARM (kein Spannungsteiler, Spannungswandler schaltet bei 6V ab) die KNX-Spezifikation ausreichend erfüllen, wenn wir die Busspannung überwachen und unterhalb von 20V schweigen. Daher würde ich dafür plädieren, die Spannungsteiler wegzulassen (oder auf vorhandenen Platinen entsprechend zu bestücken), und in der Bibliothek eine Busspannungsüberwachung einzubauen, die eine in der Applikation zu definierende Funktion aufruft, sobald die Spannung abfällt.

Was meint ihr?

Viele Grüße,

Hendrik

Ich glaube das Thema wurde schon besprochen. Evtl hat die Ts das dann schon so. Ich denke die RM Platine wurde nicht up tp date gemacht. Sollten wir nachholen. Ich denke du hast da Recht. Danke für die ausführliche Erklärung.

Ich habe mir eben noch einen 4TE-Controller (1.0 mit Quartz) mit Relaisplatine (8 monostabile Relais) und LED-Taster-Platine vorgenommen. Auf der Controllerplatine sind außer der Prog-LED keine weiteren LEDs bestückt. Software: out8-bcu1. Hier die Ergebnisse zum Archivieren:

1. Mit Spannungsteiler, alle Relais und LEDs aus. Spannungswandler schaltet bei EIB+ = 16.6V ab. Zeit zwischen 19.3V und Abschalten ungefähr 250ms.
   
2. Mit Spannungsteiler, alle Relais und LEDs an. Zeit zwischen 19.3V und Abschalten ungefähr 60ms.
   
3. Ohne Spannungsteiler, alle Relais und LEDs aus. Spannungswandler schaltet bei EIB+ = 6V ab. Zeit zwischen 19.3V und Abschalten ungefähr 1050ms.
   
4. Ohne Spannungsteiler, alle Relais und LEDs an. Zeit zwischen 19.3V und Abschalten ungefähr 300ms.
   

Die Spannungseinbrüche vor dem eigentlichen Busspannungsabfall in den beiden Bilder mit eingeschalteten Relais kommen vom Herausziehen des Kabels aus der Schraubklemme, was leider nicht so schön geht, wie eine Busklemme abzuziehen. Das kann also ignoriert werden.

Positive Erkenntnis für mich: Selbst mit maximalem Stromverbrauch haben wir ohne den Spannungsteiler noch recht viel Zeit, bevor der CPU das Licht ausgeht.

Hallo,
schaut doch mal in das Projekt Strommessender Schaltaktor.
Florian hat das dort m.E. sehr sauber gelöst. Da ist ein Spannungsteiler vorhanden(LPC1115_4TE_TOP V1.1.sch) der mit "Ein 13,2V/Aus 5,3V" beschriftet ist. In der Software gibt es eine "AppOperatingStateMachine" die die verschiedenen Zustände abbildet. Die Busspannung wird ausgewertet und die Systemzustände sogar mit unterschiedlichen Schaltschwellen(siehe config.h) für steigende und fallende Busspannung gesetzt. Ich denke dieser Code gehört unbedingt in die Lib.

Hallo Uwe,

uwe223 hat geschrieben: schaut doch mal in das Projekt Strommessender Schaltaktor.
Florian hat das dort m.E. sehr sauber gelöst. Da ist ein Spannungsteiler vorhanden(LPC1115_4TE_TOP V1.1.sch) der mit "Ein 13,2V/Aus 5,3V" beschriftet ist.

Die Beschriftung an dem Spannungsteiler heißt erstmal nur, dass man bei 13.2V an EIB+ 2V am enable-Pin hat und bei 5.3V an EIB+ sind 0.8V am enable-Pin. Das heißt nicht, dass der Schaltregler bei diesen Spannungen ein- bzw. ausschaltet. Das Exemplar, dass ich auf dem 4TE-Controller vermessen habe, hätte mit Florians Spannungsteiler beispielsweise bei 10.2V abgeschaltet. Und unterhalb von 6V läuft der Schaltregler eh nicht, egal was am enable-Pin passiert. Mir erschließt sich der Sinn des Spannungsteilers immer noch nicht, weil ich denke, dass man sich unnötig in seinem Handlungsspielraum einschränkt, aber vielleicht sagt Florian hier etwas dazu.

uwe223 hat geschrieben: In der Software gibt es eine "AppOperatingStateMachine" die die verschiedenen Zustände abbildet. Die Busspannung wird ausgewertet und die Systemzustände sogar mit unterschiedlichen Schaltschwellen(siehe config.h) für steigende und fallende Busspannung gesetzt. Ich denke dieser Code gehört unbedingt in die Lib.

Guter Hinweis, danke! Ich habe mir den Code noch nicht angeschaut, aber wenn es da schon etwas gibt, muss man das Rad nicht neu erfinden.

Viele Grüße,

Hendrik

Für's Archiv, falls hier mal jemand reinschaut, der ein neues Design macht:

• Wahl der Diode: MBRS1100 ist SMB, gibt's bei Reichelt, funktioniert. Achtung: TS-ARM hat dafür einen SMA-Footprint (passt an dieser Stelle trotzdem, sollte man sich aber nicht drauf verlassen). SOD123 ist zu klein.
• Kondensator am BD9G101 adj-Pin: Für einen adj-Spannungsteiler von 2k4:680R ist der rechnerische Wert 294nF. Bei Reichelt gibt es 270nF, das sollte man verwenden (statt der bisher in den Schaltplänen stehenden 220nF).

Ich sehe schon: Es rächt sich das ich bei meiner Entwicklung des lpc1115_4te_top keine vollständige Analyse des Schaltreglers gemacht habe, obwohl ich könnte

Hendrik hatte mir ein paar Fragen per Mail geschickt, ich antworte einfach mal hier:

Den Feed-Forward Kondensator von 220nF hatte ich einfach vom TS-ARM-Controller übernommen, da mein Stromversorgungssystem sehr ähnlich ist. Letztendlich müsste man es vermessen, denn was im Datenblatt nicht steht: Die optimale Auslegung des Feedback-Netzwerks ist auch von der Ausgangskapazität abhängig. Wenn der eine Controller nun einen 100uF Elko bestückt, der andere aber nur 22 uF keramisch - das macht einen Unterschied.

Bei der Diode des Schaltreglers ist es gut, wenn sie wenig Kapazität hat. Das steigert den Wirkungsgrad. Deshalb war ich auf die Suche nach Alternativen zur MBRS1100 gegangen. Die STPS1L60, die ich momentan einsetze, ist da schon ein Fortschritt. Gemessen habe ich die Unterschiede aber nicht. Die MBRS1100 wird aber auch ihren Dienst tun.

Zum Enable-Spannungsteiler: Hier hatte ich erst in der Entwicklung eine deutlich höhere Enable-Spannung angesetzt, um nahe bei der spezifizierten Mindestspannung des KNX-Bus zu sein. Aber letztendlich habe ich festgestellt, dass ich mehr Spielraum bei Verlust der Busspannung brauche. Mein Aktor muss die aktuellen Zustände noch schnell im Flash sichern können.

Hallo!

Florian hat geschrieben: Ich sehe schon: Es rächt sich das ich bei meiner Entwicklung des lpc1115_4te_top keine vollständige Analyse des Schaltreglers gemacht habe, obwohl ich könnte

Eine vollständige Analyse habe ich auch nicht gemacht, und Deine Hinweise hier sind hilfreich. Danke!

Florian hat geschrieben: Den Feed-Forward Kondensator von 220nF hatte ich einfach vom TS-ARM-Controller übernommen, da mein Stromversorgungssystem sehr ähnlich ist. Letztendlich müsste man es vermessen, denn was im Datenblatt nicht steht: Die optimale Auslegung des Feedback-Netzwerks ist auch von der Ausgangskapazität abhängig. Wenn der eine Controller nun einen 100uF Elko bestückt, der andere aber nur 22 uF keramisch - das macht einen Unterschied.

Klar, das macht einen Unterschied. Aber ich fürchte, jedes Gerät auf dieser Ebene zu tunen ist für Selfbus als Gesamtprojekt nicht realisierbar und meines Erachtens nach auch nicht nötig. Was mir vorschwebt ist, die verschiedenen Designs zu vereinheitlichen, nach bestem Wissen Probleme auszumerzen und dann "Bausteine" zur Verfügung zu haben, die man einfach in ein neues Gerät übernehmen kann. Am liebsten auch mit wirklich identischen Bauteilen und -größen. Und all die nervigen Fragen stelle ich, um zu verhindern, dass wir etwas übersehen (wie das Argument der Kapazität der Diode!).

Florian hat geschrieben: Zum Enable-Spannungsteiler: Hier hatte ich erst in der Entwicklung eine deutlich höhere Enable-Spannung angesetzt, um nahe bei der spezifizierten Mindestspannung des KNX-Bus zu sein. Aber letztendlich habe ich festgestellt, dass ich mehr Spielraum bei Verlust der Busspannung brauche. Mein Aktor muss die aktuellen Zustände noch schnell im Flash sichern können.

Dann spricht doch aber auch nichts dagegen, ganz auf ihn zu verzichten und stattdessen den enable-Pin an Vin zu ziehen, oder?

Florian hat geschrieben: Bei der Diode des Schaltreglers ist es gut, wenn sie wenig Kapazität hat. Das steigert den Wirkungsgrad. Deshalb war ich auf die Suche nach Alternativen zur MBRS1100 gegangen. Die STPS1L60, die ich momentan einsetze, ist da schon ein Fortschritt. Gemessen habe ich die Unterschiede aber nicht. Die MBRS1100 wird aber auch ihren Dienst tun.

Okay, guter Punkt. Aber dann lass uns doch bei Teilen bleiben, die man bei Reichelt bekommt. Du schlägst in einem Kommentar im Schaltplan selbst die MBRS140T3G vor: 40V, 1A, 22pF @ 30V (identisch STPS1L60), Vf=0.3V @ 20mA (STPS1L60: 0.35V), SMB. Wie wär's damit?

[hr]

Dein Kommentar hat übrigens meine Neugierde geweckt und mich veranlasst, mal zu messen. Mit Ergebnissen, die mich überrascht haben. Testaufbau: TS-ARM 3.07, bestückt mit MBRS1100. Ich messe die Spannung an der Diode (Strom geht leider nicht so leicht in einem fertigen Aufbau). Die meiste Zeit sehe ich das hier:



Unser 1.5MHz Schaltregler schaltet mit gemächlichen 75kHz und seiner minimalen Pulsdauer (100ns). Hoppla. Ein Blick ins Datenblatt verrät:

Datenblatt BD9G101G hat geschrieben: minimum on pulse

Minimum output voltage is limited by minimum on pulse (typ 100nsec).
Output voltage = frequency(typ 1.5MHz) × FET on time ×Vin
If output voltage is lower than this formula , Output ripple voltage is boosted by intermittent spring.

Bei Vin=27V ist die Mindestausgangsspannung also 4V. Soviel zum Thema "Analyse des Schaltreglers". Wir laufen hier also im "intermittent mode".

So sieht ein Schaltvorgang mit höherer zeitlicher Auflösung aus; in diesem Bild hat er tatsächlich zweimal hintereinander geschaltet, entsprechend den 1.5MHz, die der Schaltregler eigentlich hat:



Und schließlich nochmal mit der Spannung am ADJ-Pin. Sie bewegt sich hier zwischen ca. 0.745V und 0.760V:



Wenn ich die 3V3-Leitung mit 150ohm gegen GND belaste, macht der Regler etwas mehr. Aber nicht viel:
Alle 17.3uS ein Doppelpuls.



So, was lernen wir daraus? Ich denke, dass die Verluste an der Diode lange nicht so groß sind, wie man auf den ersten Blick vermuten würde. Sie schaltet 20x seltener, als ich gedacht hätte, und die Schaltzeiten sind kurz. Auch die Zeit, während der sie leitet, ist erstaunlich gering. Die meiste Zeit lebt das Gerät scheinbar aus dem, was im Kondensator gespeichert ist.

Nächste Stufe der Neugierde: Wie effizient ist denn unser Schaltregler? Dazu habe ich mir eine TS-ARM 3.06 ohne Mikrocontroller genommen (allerdings mit SK110 Diode, nicht MBRS1100 - hatte ich halt gerade da) und die 3V3-Leitung mit verschiedenen Widerständen belastet. Außerdem habe ich diese Platine sowie eine TS-ARM 3.07 mit laufendem LPC1115 über die 3V3-Leitung mit Strom versorgt, um den Eigenverbrauch der Schaltung zu messen. Ergebnis:



Das Datenblatt des BD9G101G hat leider nur einen Effizienzplot für 5V Ausgangsspannung. Der ist natürlich höher als das, was wir hier sehen. Aber ich denke, völlig aus der Welt ist diese Messung nicht.

Ich gehe davon aus, dass man durch Tausch der 1N4148 am Eingang gegen etwas mit niedriger Vorwärtsspannung einen halben Prozentpunkt gewinnt.

Viele Grüße,

Hendrik

Hallo zusammen,

ich hole mal diesen Thread raus, da ich gerade daran sitze die Busspannung auszuwerten.
Hier (Rauchmelder V2.4 auf ARM portiert) hatte Hendrik schon geschrieben, dass das Verhalten des Buck-Converters BD9G101 bei einer Spannung am Enable-Pin zwischen 0,8V und 2V mehr oder weniger undefiniert ist. Genau das kann ich bei zwei 4TE und zwei 2TE Controllern nachvollziehen.


Dieses undefinierte Verhalten führt zu Problemen bei der AD-Messung/Wandlung im ARM. Diese erfolgt relativ zu VDD (~3,4V). Wenn sich aber nun VDD verändert kann man das im Code nicht abfangen und es werden falsche AD-Werte/Spannungen berechnet.

Daher wäre mein Vorschlag genauso wie Hendrik schon hier (Edit vom Beitrag) geschrieben hatte, den Spannungs-Teiler am Enable-Pin anzupassen, oder den Enable-Pin direkt auf EIB_DC zu legen so wie beim TS_ARM.

Viele Grüße
Denis

Da bin ich auch dafür. Das setzt aber eine alternative Busspannungsüberwachung voraus.