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...
Nein, nein, das Thema ist genau richtig. Welche Nachrichten muss man mit Retry ausfuehren und welche nicht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.