Bei einem Hausbus sollte ich neben einer Datenleitung auch noch Strom
haben. Damit sollten die kleineren Verbraucher, Sensoren, Aktoren,
gespiesen werden koennen. Eine Wahl waere zB 24V ueberstrombegrenzt ab
einer Batterie. Jeder Ast haette eine bei der Verzweigung einstellbare
Strombegrenzung, da man ja nicht ein Batteriekabel durch's haus will.
Von 24V wuerde mit guenstigen Stromspaenden Switchern die benoetigte
Spannung erzeugt. Alternativ waere 48V denkbar. 48V kann nicht mehr
jeder Switcher, dafuer gibt es spezielle Wandler, zB als
Power-Over-Ethernet. Die Standbyverluste des Stromsystems sollten sehr
klein sein, sagen wir 50mW pro Knoten. Ein einzelner Knoten soll aber
schon mal 10W zur Verfuegung haben, daher faellt ein 12V System weg. Da
wuerde nichts mehr ankommen. Ein aktiver Knoten 10W, die anderen wuerden
nicht zur gleichen Zeit aktiv sein. Hab ich was uebersehen ?
Das Thema ist die effiziente Versorgung des Hausbusses. Wie welche Daten
rumgeschoben werden ist eine Sache. Die ist diesmal nicht interessant.
Vie versorgt man die Verbraucher, Sensoren, Aktoren. Ich tendiere zu
24V. Ein 24V zu 5V oder 3.3V Switcher zieht selbst weniger als 1mA. Das
waere dann gut. Zu einem Knoten kommt dann noch ein Controller, der auch
seine 3mA @5V zieht und gut ist. Alternativ koennte man ganzen Zweigen
den Saft wegnehmen und so strom sparen. Das waer dann abhaengig von den
aufgaben, die die Knoten haben. Muessen die Knoten ein Gedaechtnis
haben, zB um etwas zu regeln, oder kann ich die zum Messen alle minuten
oder so rasch einschalten.
24Volt dürften i.d.T der günstigste Kompromiss sein - wird auch von
etablierten Systemen verwendet.
Knoten(zweige) extern den Hahn abdrehen, würde bedingen, dass Ereignisse
vorhersehbar sind; für Lichttaster, Überwachungseinrichtung u.
Regelkreisen imho eher ungeeignet. Falls Du Daten (z.B. ATemp,
AHelligkeit) in grösserem Zeitraster (z.B. >15min) erfassen würdest,
könnte sich das vlt. lohnen.
Welchen Verbrauchern würdest Du temporär 10W zur Verfügung stellen
wollen? Einer Visu?
Nur ein Gedankansatz zu Taster - diese könntest Du von selbst schlafen
lassen und per Interupt (Tastendruck) aufwecken, je nach verwendetem
Controller.
jm2c
ich würde weniger in Richtung Lastbalance verfahren, sondern das System
mit fixen max.Verbräuchen/Knoten konzipieren und diese so weit wie
möglich zu verringern versuchen. Falls ein, vorher nicht vorgesehener,
Teilnehmer plötzlich Überwachungsfunktionen bereitstellen muss, hat man
nicht das Problem, dass evtl. Versorgungsabschaltunge
Probleme/Funktionsverlust/Fehlalarme auslösen.
GLT,
danke fuer den Input. Ja. sobald Taster dabei sind, kann man die
Versorgungsspannung nicht mehr wegnehmen. Jeder Knoten sollte daher auf
minimalen Stromverbrauch getimmt werden. Verbraucher, die 10W oder so
ziehen duerfen waeren zB Fenstermotoren, Rolladenmotoren,
Lueftungsklappen. Ohne ein solches Teil nachgemessen zu haben. Falls
mehr Strom benoetigt wird, muss dann ein zusaetzliches 1.5mm^2 @24V
parallel gezogen werden.
Aeh, ja. Sobald recht Strom fliesst wird sich der GND verschieben. Wenn
zB 1A fliesst und zB 1V auf der + sowie auf der - Leitung abfaellt,
sieht die Kommunikation dieses eine Volt als Gleichtakt auf dem Signal.
Das sollte fuer die ueblichen Differentialbusse kein Problem sein.
Die in Frage kommenden Lüftlungsklappen-Antriebe ohne Federrücklauf
(<10NM) ziehen je nach Hersteller ca 2-4 VA.
3P-Antriebe benötigen ohnehin nur Strom im Fahrbetrieb; eine separate
Abschaltung nicht nötig.
Für die Schaltaktoren empfehlen sich bistabile Relais; so benötigt dein
Bus nur Strom zum Status ändern ;-)
Das Abschalten von Zweigen halte ich für nicht ganz sinnvoll, besser,
die einzelnen Knoten auf geringen Stromverbrauch trimmen. Die geringe
Last, die durch auf Stromsparen optimierte Knoten entsteht, ist sicher
vernachlössigbar:
Wenn z.B. Dein Bus mit einem 60VA Netzteil betrieben wird, von denen der
Bus ohne aktive Verbraucher vielleicht 2W verbraucht, dann ist es
wesentlich wichtiger, ein Netzteil mit einem guten Wirkungsgrad im
Niedriglastbereich zu verwenden, als von den 2W nochmal einen Teil durch
Abschalten einzusparen.
Viele Grüße, Stefan
"Hefebrot",
siehe mein OpenHC Projekt, da verwende ich 24V Speisung und Schaltregler
in den Modulen. Mit MAX5033 habe ich gute Erfahrungen gemacht, hat
nierigen Ruhestrom, mittlerweile mag es noch bessere geben.
Für die Relais habe ich eine recht trickreiche Ansteuerung, so
verbraucht ein angezogenens 12A-Relais nur ca. 3 mA.
Danke Stefan, richtig, man sollte bei der Erzeugung der 24V ansetzen
bevor man den Leerlaufverbrauch des Busses von 2 auf 1W senkt.
Danke Joerg, fuer den Tip mit dem Max5033. Ich verwende bisher den
LT1777, der zieht gut das Doppelte, ist dafuer Lownoise. Ich werd mir
mal das OpenHC anschauen.
Ja, ich hab mit das OpenHC angeschaut. Im Vergleich zu dem moechte ich
- Zentralen selbstaendigen Mastercontroller, der kann mit einem PC
konfiguriert werden.
- PC Interface ist ein Webserver.
- keine automatschen Retries.
...
Hefebrot wrote:
> Ja, ich hab mit das OpenHC angeschaut.
Sicher, daß du es gründlich genug angeschaut hast? ;-)
> Im Vergleich zu dem moechte ich> - Zentralen selbstaendigen Mastercontroller, der kann mit einem PC> konfiguriert werden.
Genau das ist das Konzept. (Hat Vor- und Nachteile: komplexere Dinge
möglich, aber höhere Einstiegskosten und "single point of failure".)
> - keine automatschen Retries.
Aha, warum nicht? Dann hättest du keine sichere Übertragung mehr. Auf
einem gemeinsam per Multimaster genutzten Medium kann es immer zu
Kollisionen kommen. Oder möchtest du statt Multimaster einen
Polling-Betrieb realisieren? (ständiger Traffic, nicht so doll wegen
Latenz und auch Energiebedarf)
> ...
Was sagen uns die Pünktchen?
Ich hab mir den OpenHC nicht genuegend angeschaut. Die Puenktchen sagen
uns, dass ich noch am Vergleichen des OpenHC zu meinen Vorstellungen
bin. Mit den automatischen Retries muss man aufpassen. Ich kenn
mindestens ein Protokol, das sowas auf Treiberebene hat und das hat
seine Nachteile. Wenn zB ein Geraet fehlt, kommt immer noch ein Satz
Retries. Wenn ein Taster eine Statusaenderung sendet, und das Licht geht
nicht an, so druckt man eben besser nochmals als der Taster den Bus mit
endlosen Retries belegt. Nur weil mal ein Geraet fehlt darf nicht der
Rest sich gegenseitig mit Retries zumuellen. Da muss ein besseres
Konzept her.
So "dumm" wie beschrieben verhalten sich die Retries auch nicht... ;-)
In Verbindung mit mit dem Toggle-Bit und dem CRC wird eine sehr sichere
Datenübertragung auf Protokollebene ermöglicht, das funktioniert schon.
Mit ähnlicher Argumentation müsstest du TCP als Internetprotokoll
ablehnen und UDP bevorzugen. TCP hat Retries und sorgt für eine quasi
fehlerfreie Verbindung, UDP geht einfach kaputt.
(In der Netzwerktheorie lassen sich zwar Sättigungsszenarien
konstruieren, bei denen das Medium vollständig mit Retries zu ist und
der echte Traffic nicht mehr durchkommt. Dem begegnet man mit back-off
Intervallen und überdimensionierten Kapazitäten, habe ich mal gelernt.)
Wir schweifen vom Thema ab, merke ich gerade...
