Mikrocontroller.net - Benutzerbeiträge [de]

1-wire als Hausbus

2006-02-06T10:51:32Z

84.57.168.23: /* Extern */

=Links=
==Intern==
*[[Temperatursensor#DS18S20]]

==Extern==
*http://www.maxim-ic.com/products/ibutton/

[[Kategorie:Hausbus]]

Hausbus

2006-02-06T10:50:50Z

84.57.168.23: /* Powerline */

=Anforderungen=
==Zentral/Dezentral==
Grundsätzlich kann so eine Steuerung zentral oder dezentral arbeiten (wobei natürlich auch Mischformen denkbar sind).
===Zentral===
Beim zentralen Ansatz gibt es einen Master, der zyklisch alle Sensoren (Thermometer, Lichtschalter, usw.) abfragt und dann die entsprechenden Aktionen auslöst.

+ wenig Intelligenz bei den Sensoren/Aktoren nötig
+ bei Konfigurationsänderungen keine Änderungen bei den Sensoren/Aktoren nötig.
+ keine Multimasterfähigkeit nötig
- je mehr Sensoren vorhanden sind, desto länger dauert ein Abfragezyklus.
Da so ein selbst gebauter Hausbus ja auch Raum für Erweiterungen bieten soll,
sollte man schon mit 100-200 Sensoren rechnen (Lichtschalter, Thermometer,
Glasbruchsensoren, Rauchmelder usw. usf)
- Wenn die Zentrale ausfällt, dann fällt die gesamte Steuerung auf einmal aus

Anmerkung: Falls, wie im dezentralen Fall die Sensoren von sich aus Zustandsänderungen melden, aber die Nachrichten nur an den Master schicken, entfällt der Nachteil durch das Polling.

===Dezentral===
Beim dezentralen Ansatz senden die Sensoren (z.B. Lichtschalter) Botschaften an die Aktoren (z.B. die Glühlampe).
+ Die Buslast hängt von der Anzahl Ereignisse ab und nicht von der Anzahl Sensoren.
Ein Glasbruchsensor der nie aktiv wird verursacht auch keine Buslast.
+ Keine Schaltzentrale nötig (also kein Single Point of Failure)
- Multimasterfähigkeit bei allen Sendern (also allen Sensoren) nötig.
- Konfigurationsänderungen müssen immer an den entsprechenden Aktoren/Sensoren gemacht
werden. Dazu muß man sie entweder fernkonfigurieren können oder mit dem Konfigurationsgerät
direkt an die jeweiligen Geräte.

==Geschwindigkeit==
Solange man nur ein einzelnes Wohnhaus (und nicht etwa eine Schule oder eine Fabrik) ausrüsten will und nur die üblichen Sensoren/Aktoren hat, ist praktisch jeder Bus schnell genug. Andererseits erlauben RS485 und der CAN-Bus bei den in einem Haus vorkommenden Kabellängen auch durchaus Geschwindigkeiten von 1 MBit/s, wodurch man auch andere Anwendungen damit realisieren könnte.

--> Hohe Geschwindigkeit heißt höherer Aufwand und höhere Kosten <---
Ein Hausbus sollte deshalb in der Geschwindigkeit auf die notwendigen Bedürfnisse abgestimmt sein. Folgende Rechnung läßt sich aufmachen:
Ein Frame mit einem einfachen Event z.B. "Taste 4 des Modul 0x2007 gedrückt" läßt sich mit allem Nötigen wie Priorität, Parity-Bits Anzahl Datenbytes und Checksumme in 6 "Byte" a 10Bit verpacken. Bei einer Geschwindigkeit von nur 10 KHz dauert die Übertragung ca. 6ms. Erlaubt man pro Frame max. 12 Datenbyte ergeben sich 18ms. Wobei 12 Datenbyte eigentlich nur zur Konfiguration der Knoten nötig sind. Uhrzeit, Datum, Temperaturen usw. kann man meistens mit 2 - 4 Datenbyte melden. Da mit der CAN-Topologie kollisionsfrei Daten übertragen werden und ein Hausbus im Allgemeinen keiner hohen Belastung unterliegt, ist es realistisch sonstige Verzögerungen zu vernachlässigen. Ich habe in meinem 5 Personenhaushalt den Bus nach "Bus-belegt-Verzögerungen" gescannt und in drei Monaten vier dieser Ereignisse festgestellt. Das bedeutete 12ms anstatt der erwähnten 6ms.
Warum sollte man schneller werden, wenn eine Verzögerung von 200ms in der Realität nicht fegestellt wird. Die Verzögerung einer Leuchtstofflampe empfinde ich da schon eher als störend.
Sollten wir eine Schule mit solch einem Bus betreiben und 166 Kinder stürmen in die Pause und betätigen dann alle einen Taster, verzögert sich das letzte Ereignis um nicht ganz eine Sekunde.

=Vergleich von Hausbussystemen=

==EIB==
+ nur 2 Leitungen für Daten, Power und GND
+ kein Abschluss-R nötig, alle Bustopologien
+ multimasterfähig
- Chips nur schwer erhältlich und teuer
- nur industrielle Module erhältlich, kein Selbstbau

==[[CAN-Bus]]==
+ Protokoll bereits im Chip
+ multimasterfähig
+ übertragunssicher (d.h. bei Übertragungsfehler werden Daten automatisch wiederholt)
+hohe Störsicherheit durch differentielle Übertragung
O Preis ist ausgewogen
- es werden 2 Leitungen Daten + Power + GND benötigt
- Abzweigungen vom Bus sind problematisch (max. 1m?)
- Abschluss-R notwendig

==RS485==
+ sehr günstig
+ Schnittstellenbausteine können direkt an den USART eines MCs angeschlossen werden
+ Buslänge von 1200 m möglich
- von Haus aus nicht multimasterfähig, muß per Software realisiert werden

==[[1-wire als Hausbus]]==
+/- zentrales System
+ sehr günstig
+ sehr einfache Verdrahtung
+ integrierte Peripheriebausteine erhältlich (Thermometer, I/O-Bausteine, etc.)
+ über einfaches Selbstbauinterface vom PC ansteuerbar
+ Bus kann mit Pullup-Widerstand direkt von einem bidirektionalen Microcontrollerpin angesteuert werden
+ professionelle Softwareinterface frei erhältlich (unterstützt bis zu acht Busleitungen)
+ mit einfachem Pullup-Widerstand maximal 200 m Buslänge zulässig
+ mit aufwendigerem aktiven Pullup maximal 500 m Buslänge zulässig
+ integrierte Interfaceschaltungen für I2C, USB und Serielle Schnittstelle erhältlich
+ ausführliche Darstellung zur Buslänge in Appnote 148 verfügbar
+ Peripherie ohne separate Spannungsversorgung möglich
+ umfangreiche Herstellerunterstützung durch technische Dokumente
- nicht multimasterfähig
- max. 75 Bausteinabfragen/sec.
- Peripherieschaltungen nur als integrierte Bausteine erhältlich
- in Software realisierte Peripherie verstößt gegen US-Patente
- keine differentielle Übertragung, dadurch deutlich störanfälliger

==[[I2C als Hausbus]]==
+ billig
+ multimasterfähig
+ viele direkt anschließbare Sensoren vorhanden
- keine differentielle Übertragung, dadurch deutlich störanfälliger
- ohne "größeren" Aufwand nur Kabellängen <10m möglich
- als "Inter-IC-Bus" zur Anwendung innerhalb von Geräten konzipiert

==Ethernet==
+ multimasterfähig
+ sehr schnell
+/- mit TP-Kabel (100 Base T) Sternstruktur, Leitungslänge bis 100 m
+/- mit Koaxkabel (10 Base 2) Busstruktur, Leitungslänge bis 185 m
- aufwendig anzusteuern (hohen Hardware- und Softwareaufwand)
- (teuer) d.h. für Selbstbau aufwendig

==Powerline==
+keine besondere Verdrahtung bzw. Installation erforderlich
+nutzt vorhandene Netzinstallation
-erzeugt ein breitbandiges Störspektrum, das über die Netzinstallation unkontrolliert abgestrahlt wird
-kann Funkbetrieb, insbesondere im Kurzwellenbereich, stören
-funktioniert ohne Phasenkoppler nur auf gleichen Phasen
-Netzteile mit vernünftigen EMI Filter filtern auch das PL Signal
-geringe Übertragungsrate
- Modems werden im Störungsfall vom RegTP außer Betrieb genommen und werden dadurch wertlos

=Links=
==Forum==

*[http://www.mikrocontroller.net/forum/list-11-1.html Hausbusforum]

*[http://www.mikrocontroller.net/forum/read-1-66019.html älterer Hausbusthread] Link tot?

*[http://www.mikrocontroller.net/forum/read-1-190530.html noch ein Haussteuerungs-Projekt]

==Allgemein==
*http://www.uni-weimar.de/~weiprech/hausbus/
*http://www.hausinformationssysteme.de

==CAN==
*[[CAN als Hausbus]]
*[[Hausbus Diskussion|Hausbus openscource projekt]]

==EIB==
*[http://www.opternus.de/opternus-components/Preisliste/EIB%20Preisliste%201.July%202005.pdf Chipsatz Preisliste]

==Ethernet==
*[http://www.ifas.htwk-leipzig.de/easytoweb/php/download/Verwendung%20eines%208-bit%20Microcontrollers%20zur%20Ethernet%20Vernetzung%20in%20der%20Hausautomation.pdf Diplomarbeit]

==Powerline==

* http://www.thelastinstance.de/elek/project03_4.phtml
* http://www.darc.de/aktuell/plc/index.html
* http://www.ulrichradig.de/index.html Projekte-pl-modem
[[Kategorie:Hausbus]]

CAN als Hausbus

2006-02-06T10:50:04Z

84.57.168.23:

[http://www.mikrocontroller.net/forum/list-11-1.html Forum ]
[[Category:Projekte]]
[[Category:AVR]]
[[Category:CAN]]
[[Kategorie:Hausbus]]
Das solle eine Übersichtseite werden die Projekte mit [[CAN-Bus]] als Grundlage für einen Hausbus vorstellt. Es sollen auch Informationen die Can insbesondere als [[Hausbus]] betreffen gesammelt werden.

=Infos=

Infos allgemein zu [[Hausbus]] .

==Verkabelung==
===Strang/Linie===
Laut offizieller Definition ist nur ein Strang und insgesamt Stichleitungen von 2m Länge erlaubt.
===Sternverkablung===
Von Bernhard:
Ich habe es in meinem Haus so
gemacht. An jedem Ende (20 Knoten) habe ich den Bus mit 12K
abgeschlossen.
Die ersten 12 Knoten (Erdgeschoss) laufen seit 13 Monaten ohne
Probleme. Bei der heute abgeschlossenen Erweiterung um 8 Knoten in
einem weiteren Geschoss hatte ich erst Probleme.
===Physikalisch Stern aber logisch Strang/Linie===
Beide Verkabelungarten lassen sich auch mischen, so daß beide Vorteile zum Tragen kommen. D.h. die Kabel werden sternförmig vom Sternmittelpunkt zu jedem Busteilnehmer gezogen. Beginnend von einem Teilnehmer (der als Busanfang festgelegt wird) wird das Buskabel über ein Adernpaar zum Teilnehmer hingeführt und über ein zweites Adernpaar wieder zurück zum Sternmittelpunkt. Von dort aus geht es genauso weiter bis zum letzten Teilnehmer. An dessen Rückleitung kann dann einfach am Sternmittelpunkt der Abschlusswiderstand angeschlossen werden.
Wenn man als Kabel sowieso Cat5-Leitung vorsieht, so sind von den 4 Adernpaaren durch diese Verkabelungsart 2 Paare belegt, 1-2 weitere Paare können dann für Versorgungsspannung oder ähnliches verwendet werden.
===Baumverkabelung===
Bei CAN per Spezifikation nicht erlaubt, da an den Stichleitungen Reflexionen zu Störungen führen.

=Projekte=
==[http://www.canathome.de/ canathome]==

Als Basis dienen AVR und Fujitsu MB90F497 und Freescale HCS12. Letzte Änderung: 2005-08-05

==[http://caraca.sourceforge.net/ caraca]==
==[[Hausbus Diskussion|Hausbus opensource projekt]]==
* am neues projekt hier auf der seite!!

Powerline mit AVR

2006-02-06T10:48:59Z

84.57.168.23: /* Vorschläge */

Hier soll ein Projekt zur Entwicklung eines einfachen, modularen Powerline-Moduls mit einem AVR entstehen.

Bisherige Diskussion siehe: [http://www.mikrocontroller.net/forum/read-11-281113.html]

== Hardware ==

=== Anforderungen ===
* Sollte für UP-Dose und Hutschiene geeignet sein
* Für UP-Dose kommt man vermutlich nicht um SMD Bauteile herum
* Modularer Aufbau: Einheitliches Basismodul durch Stapeln erweiterbar
* Überlastschutz (Temperaturüberwachung am Driac)
* Die Module arbeiten dezentral
* Die Abfrage und Steuerung der Module ist über ein Modem möglich

* Das Modul hat mehrere Funktionen die durch Software parametrierbar sind
* als Zeitschalter ( Einschaltverzögerung, Ausschaltverzögerung )
* als Ein/Ausschalter (schaltet im Nulldurchgang)
* Eingänge: Taster
* Ausgänge: 220V Schaltausgang

=== Mindestvorraussetzungen an den AVR ===
* UART
* 2 Externe Interrupts
* Analogkomparator
* PWM

In Frage kommen (nicht vollständig):

{|
!AVR!! Flash!!UART!!A-Comp!!ADC!!PWM!!INT
|-
|ATtiny2313|| 2k || 1 || 1 || - || 4 || 2
|-
|ATmega8|| 8k || 1 || 1 || 8 || 3 || 2
|-
|ATmega128|| 128k || 1 || 1 || 8 || 8 || 8
|}

[http://atmel.com/dyn/products/param_table.asp?family_id=607&OrderBy=1262&Direction=DESC# Übersicht AVR]

=== Funktionsweise (vgl TDA5051)===
* Modulation:
Der AVR moduliert auf die Netzspannung ein 140 KHz Signal. Die 140 KHz werden über den PWM-Ausgang erzeugt und anschließend verstärkt.
Der PWM-Ausgang wird mittels INT0 getaktet. Durch eine Verbindung mit TXD werden somit schon alle Daten der UART auf das Netz moduliert.
* Demodulation:
Über ein RC-Filter (neue Version: LC-Filter) wird die Netzspannung nach hochfrequenten Anteilen durchsucht.
Die Spannung wird von einem Transistor verstärkt und dann mit 2 Schottkydioden gleichgerichtet. Eine Siliziumdiode begrenzt das Signal noch auf ca. 0,5V.
Das Signal wird anschließend dem AVR-Komparator zugeführt (neue Version ADC-Konverter). Über einen (software)-PWM-Ausgang kann die Schaltschwelle eingestellt werden. Das dekodierte Signa liegt dann an PD4 an und geht in die UART
* Phasenanschnitt:
Über 2x1MOhm Widerstände wird mittels INT1 die Netzfrequenz abgetastet. Bei jedem Nulldurchgang wird ein Zähler auf 255 gesetzt. Dieser zählt mittels Timer (alle 64µS ) auf ca. 100 herunter. Stimmt der Zähler mit dem Ausgangswert des jeweiligen Kanals überein, so wird ein Zündimpuls zum Triac ausgegeben.
=== Module ===
[[Bild:Upmodul.png|thumb|none|Schaltplan mit funktionaler Gruppierung]]

==== Basismodul UP-Dose ====

Hier mal ein erster Vorschlag (noch nicht vollständig) für ein UP Basismodul mit SMD-Technik:

(''Kann mal jemand mit OP-Amp-Kenntnissen kontrollieren, ob die Sendeendstufe so funktioniert?'')

OP-Amp würd ich lieber einen Input per Spannungsteiler auf 2,5V legen. Bitte unbedingt auch mal den neuen Schaltplan im Downloadbereich meiner Projektseite ansehen (LC Input Filter)
http://www.k13zoo.de/vdr/homeautomation/download/

Anmerkung: Der OP vom Typ 741 kann nicht bis an die Versorungsspannung ausgesteuert werden. In diesem Fall wird der Ausgang den 0V Pegel nicht erreichen. Die minimale Spannung wird bei ca. 1,5 V liegen. Warum wurde die Transistorschaltung durch einen OP ersetzt. Welche Vorteile bringt dies ?
Im Eingangskreis halte ich eine OP-Schaltung für geeignet. Dort könnte mit dem OP-Schaltung die aufmodulierte Frequenz durch einen Bandpass gefiltert werden.
Gruß Reinhold

''Ja, hab ich grad selber gemerkt. Den LC-Filter habe ich eingebaut.''

Evtl kann man einen 2-Fach OP verwenden und den zweiten als Eingangsverstärker bzw. Gleichrichter verwenden.

''Dann müsste die Empfangsstufe aber auch die ungeregelte Eingangsspannung als Quelle für den OP verwenden.''

'''Update: Was haltet ihr von dem Board als Standard für UP-Dosen? Habe versucht es so zu designen, dass auch eine erweiterte Version mit ATmega8 möglich ist.'''

''Das Board halte ich für zu groß, da ich glaube, dass du keinen Platz mehr zum Anklemmen der Leitungen hast. Ich würd auf einen Atmega umsteigen, da dieser einen AD-Wandler hat, der dann evtl die Abtastung des Trägers übernimmt. ausserdem hat er mehr Speicher''

So besser?
Ich wollte eine Ultra-Low-Cost-Version mit ATtiny2313 (hat außerdem 4 PWM!) und eine mit ATmega8.
Mit Standard meine ich eigentlich die Abmessungen und Anschlussbelegung des Boards. Wenn es ausgereift ist könnte man größere Mengen herstellen lassen um Kosten zu sparen.

Ist es überhaupt nötig die Abtastung seperat zu machen? Der UART tastet doch auch schon 16 mal pro Bit ab. Man müsste dann nur den Offset einstellen können.

{|
| [[Bild:Up_basis_smd.png|thumb|none|Schaltplan]] [http://mythos.tru42.org/elektronik/UP_Basis_SMD.sch Eagle]
| [[Bild:Up_basis_smd_board.png|thumb|none|ATtiny2313 Board]] [http://mythos.tru42.org/elektronik/UP_Basis_SMD.brd Eagle]
| [[Bild:Up_basis_atmega8_smd_board.png|thumb|none|ATmega8 Board]]
|}

Part Value Device Package Library Reichelt

B1 B-DIL B-DIL rectifier B80C800DIP
C1 220µF CPOL-EUE5-10.5 E5-10,5 rcl RAD 220/25
C2 33nF 630V C-EU102-043X133 C102-043X133 rcl MKS-4-1000 33N
C3 33nF C-EUC1206 C1206 rcl X7R-G1206 33N
C5 100pF C-EUC1206 C1206 rcl NPO-G1206 100P
C6 10nF C-EUC1206 C1206 rcl X7R-G1206 10N
C7 1nF C-EUC1206 C1206 rcl NPO-G1206 1,0N
C8 22µF CPOL-EUE2-5 E2-5 rcl
C9, C10 100nF C-EUC1206 C1206 rcl X7R-G1206 100N
D1,D4 Schottky DIODE-D-2.5 D-2.5 diode
D3 1n4148 DIODE-D-2.5 D-2.5 diode 1N 4148
F1 SHK20L SHK20L fuse PL 120000
IC1 uA741D uA741D SO08 linear µA 741 SMD
IC2 78L05 78XXS 78XXS v-reg
IC3 ATTINY2313-20S ATTINY2313-20S SO20L avr
JP1 AVR-ISP-6 AVR-ISP-6 AVR-ISP-6 atmel
L1 47µH L-EU0207/2V 0207/2V rcl
L2 47µH L-EUL4532P L4532P rcl
LED1 LED3MM LED3MM led
Q1 4MHz CRYTALHC49S HC49/S crystal
R1,R17 10k R-EU_0207/2V 0207/2V rcl
R2 2k2 R-EU_0207/12 0207/12 rcl
R3 R-EU_R1206 R1206 rcl
R4,R7 10k R-EU_R1206 R1206 rcl
R6 470k R-EU_M1206 M1206 rcl
R8 1k R-EU_0207/5V 0207/5V rcl
R9 15k R-EU_R1206 R1206 rcl
R10 50k R-EU_R1206 R1206 rcl
R18 100k R-EU_0207/2V 0207/2V rcl
SV1,SV2 FE10-1 FE10 con-lsta
T4 BC847A-NPN-SOT23-BEC SOT23-BEC transistor
TR1 9V EE20-1 EE20-1 trafo EE 20/6,1 109
X1 AK500/3 AK500/3 con-ptr500

==== Phasenanschnitt UP-Dose ====

==== USB-Modul UP-Dose ====

==== Basismodul Hutschiene ====

== Software ==

=== Protokoll ===
Das Protokoll ist Multimasterfähig, jedes Paket muss quittiert werden. Kommt keine oder eine fehlerhafte Quittierung an, so wird ein paar mal versucht das Paket nochmal zu senden. Eine Sequenznummer garantiert die einmalige Verarbeitung, selbst wenn das Paket öfter empfangen wurde.
=== Protokollaufbau ===

{|
!Byte!! 7 !! 6 !! 5 !! 4 !! 3 !! 2 !! 1 !! 0 !! Funktion
|-
| 1 || 0 || 1 || 0 || 1 || 0 || 0 || 1 || 0 || Header: "R"
|-
| 2 || 0 || 1 || 0 || 1 || 0 || 0 || 0 || 0 || Header: "P"
|-
| 3 || C || C || C || C || L || L || L || L || C, wie oft das Paket wiederholt gesendet wurde (wegen ausbleibenden Ack). L: Länge der Payload bis zum CRC-Byte (also mindestens 3)
|-
| 4 || A || ID || ID || ID || ID || ID || ID || ID || Ack-Flag, Destination ID
|-
| 5 || 0 || ID || ID || ID || ID || ID || ID || ID || Source ID
|-
| 6 || x || x || x || x || x || x || x || x || Sequenznummer
|-
| L - 3 Bytes || x || x || x || x || x || x || x || x || Daten
|-
| L + 4 || x || x || x || x || x || x || x || x || CRC ab Byte 3
|}

Zuerst wird nach dem Header gescannt (bei manchestercodierung muss wahrscheinlich vom Header noch ein paar Dummy-Daten gesendet werden, damit sich die AGC einstellt)

Dann kommt die Länge und der wievielte Versuch dies ist, dieses Paket zu übertragen.

Die Moduladresse hat momentan 7 Bit (also 128 Module), ein Bit ist zur Signalisierung dass dies ein Ack-Paket ist. Das Gerät für welches das Ack-Paket bestimmt ist, löscht sein aktuell zu sendendes Paket aus dem Sendepuffer, da es weiß dass seine Daten erfolgreich angekommen sind. Bleibt das Ack-Paket aus, so wird nach einer (pseudo)zufälligen Zeit bis zu 8 x versucht, das Paket erneut loszuwerden.

Es kann jetzt passieren, dass der Empfänger das Paket 8 x korrekt empfängt und nur das Ack-Paket nicht korrekt zurück kommt. Die Sequenznummer (welche für das aktuellzu sendende Paket immer gleich ist) garantiert aber, dass das Paket nur 1x verarbeitet wird. Um ein Paket als gültig anzusehen muss entweder C = 0 sein (erster Versuch das Paket zu senden) oder die Sequenznummer sich von der des letzten Paketes unterscheiden. (hier kann es im Moment noch zu Problemen kommen wenn mehrere Module untereinander kommunizieren) Weiterhin muss natürlich die Destination ID übereinstimmen.

Der Teil Daten wird dann von der nächsten Protokollebene behandelt.

Das erste Byte ist der Befehl aus dem sich auch die Länge weiter Daten ableitet

Momentan gibt es erst 2 Befehle:

"s" <Speicherstelle> <wert> //speichert Wert in entsprechenden Konfig-Ram
Modul antwortet mit "!"

"q" <Speicherstelle> //Liest Wert aus Konfig-Ram
Modul antwortet mit "=" <Wert>

Im Konfig-Ram werden sowohl die Phasenanschnittwerte als auch die Tastzustände gehalten. Ein Überschreiben führt also sofort dazu, dass der entsprechende Ausgang den Wert ausgibt.

=== Vorschläge ===

* Wie soll die Adressierung aussehen?
:Jedes Modul eine Adresse mit 8Bit
:oder Jede Funktion eine Adresse mit 16Bit

* Broadcasts für z.B. Erkennung vorhandener Geräte

* Jedes Gerät sollte sich und seine Funktionen bekannt machen können

[[Kategorie:Projekte]]
[[Kategorie:Hausbus]]