Vorlage:Warnung/Doku

2012-05-17T08:23:39Z

Die Seite wurde neu angelegt: „<pre><nowiki> {{Warnung| }} </nowiki></pre> = Beispiel = <pre><nowiki> {{Warnung|Das ist eine Warnung! }} </nowiki></pre> {{Warnung|Das ist eine Warnung! }}“

Neue Seite

<pre><nowiki>
{{Warnung|
}}
</nowiki></pre>

= Beispiel =

<pre><nowiki>
{{Warnung|Das ist eine Warnung!
}}
</nowiki></pre>

{{Warnung|Das ist eine Warnung!
}}

Vorlage:Warnung

2012-05-17T08:20:03Z

Die Seite wurde neu angelegt: „{{Dokumentation}}<onlyinclude><div style="border:2px solid #ff0000; padding: 10px;"> {{{1|}}} </div> </onlyinclude>“

Neue Seite

{{Dokumentation}}<onlyinclude><div style="border:2px solid #ff0000; padding: 10px;">

{{{1|}}}
</div>
</onlyinclude>

Tchibo Wetterstation

2012-05-12T15:34:07Z

Zusammenfassung

← Nächstältere Version		Version vom 12. Mai 2012, 15:34 Uhr
(2 dazwischenliegende Versionen von einem Benutzer werden nicht angezeigt)
Zeile 157:		Zeile 157:

	Wendet man wieder die Excel-Formel von oben an, kommt man in vielen Fällen auf die richtige Nachkommastelle.		Wendet man wieder die Excel-Formel von oben an, kommt man in vielen Fällen auf die richtige Nachkommastelle.
		+
		+	Für eine vollständige Temperatur ist das natürlich noch nicht genug. Wandelt man Nibble 4 auf die gleiche Weise um, und addiert es um 4 Bit verschoben (bzw. mit 16 multipliziert) mit Nibble 3, hat man einen Temperaturbereich von 25,5°C eingeschlossen. Mit Nibble 5 Wächst der Informationsgehalt auf 12 Bit, also auf 2<sup>12</sup>=4096, was 409,5°C (unter Beachtung von 0°C) entsprechen würde. Das ist natürlich Blödsinn - eher schmilzt der Sensor ;-)
		+
		+	Der Grund hierfür ist bei den negativen Temperaturen zu finden (die die Anzahl der Bits nochmals bestätigen), die im [[wpde:Zweierkomplement\|Zweierkomplement]] übertragen werden. Dadurch verliert man ein Bit an das Vorzeichen, was immerhin noch Temperaturen von -104,8 bis 204,7°C ermöglichen würde. Der Grund für diesen weiten Anzeigebereich dürfte sein, dass das Rechnen mit 4 Bit einfacher ist, als etwas krummes zu verwenden (aber nur eine Annahme).
		+
		+	==Schalter==
		+	Der Sender hat, wie oben im Bild gezeigt, einen Kanalwahlschalter. Dieser Kanal müsste also auch bei der Übertragung mitgesendet werden.
		+
		+	Hier ist die Ermittlung denkbar einfach: Umschalten und warten, bis Pakete eintreffen.
		+	Diese Information ist in den niederwertigsten zwei Bits (bei Beachtung des "Bitreversals") von Nibble 2. Etwas verwirrend ist hierbei, dass die Bits widerum vertauscht sind.
		+	==Synchronisierung==
		+	Beim Herumspielen ist mir aufgefallen, dass das manuelle Synchronisieren von Sender und Empfänger zu einem Piepsen der Wetterstation führt. Also muss dies auch übertragen werden.
		+
		+	Gleiches wie bei der Schalterstellung: Daten einfangen und vergleichen. Die Information steckt im 3. Bit von Nibble 2 (ebenfalls nach Bitreversal).
		+	==Low Battery==
		+	Wenn man schräg auf das Display der Wetterstation schaut, sieht man ein Low-Battery-Symbol neben der Anzeige der Außentemperatur.
		+
		+	Auch diesen Zustand kann man sehr einfach erreichen, indem man die Batterien durch ein Labornetzteil ersetzt. Nach Herunterdrehen des Potis erschien tatsächlich das Symbol im Display. Der Logic Analyzer sagt: Nibble 3, niederwertigstes Bit (muss ich Bitreversal noch erwähnen?).
		+
		+	==Rest==
		+	Damit wären eigentlich alle nötigen Informationen entschlüsselt. Es bleiben "nur noch" 12 Bit übrig. Wegen der Anordnung vermute ich hinter dem letzten Nibble eine Prüfsumme. Da sich das erste Nibble nur nach Batteriewechsel änderte, gehe ich davon aus, dass es sich um eine Zufällige Bitfolge zur Erweiterung des Addressraum handelt. Die restlichen 4 Bit sind mir bis dato noch gänzlich unbekannt.
		+
		+	==Prüfsumme==
		+	Ich mag sie (zumindest bei Reverse Engineering) einfach nicht. Hauptgrund ist, dass es schlichtweg beliebig viele Verfahren gibt, diese zu berechnen. Egal ob CRC, XOR oder eine einfache Summe wie beim [[ECL-Bus-Decoder]] - es ist einfach undankbar, diese zu rekonstruieren.
		+
		+	Aber genug gejammert, Sicherheit kostet nunmal Aufwand.
		+
		+	Am Anfang habe ich noch per Bruteforce versucht, die Prüfsumme zu ermitteln, indem ich einfach alle Werte ver-CRC-t, mit XOR verprügelt und addiert habe. Das führte nicht unbedingt zum erwünschten Erfolg - wobei ich dazu sagen muss, dass ich dort auch noch mit der Datenfolge in Reinform (also ohne das umdrehen der 4-Bit-Gruppen) gearbeitet habe.
		+
		+	Im zweiten Versuch ging ich wieder über Excel (diese Programm wird man einfach nicht los) - dieses mal mit umgedrehten 4er-Gruppen. Dieses Mal war auch der Ansatz etwas anders: ich suchte mir die Datenpakete mit dem geringsten [[wpde:Hammingabstand\|Hammingabstand]] - also jene Datenpakete, die möglichst wenige unterschiedliche Bits haben - heraus, was mehr Erfolg versprach.
		+
		+	In der Excel-Datei (Name) habe ich meine "Forschungsergebnisse" zusammengefasst. Es handelt sich tatsächlich nur um eine Quersumme der Nibbles 0 bis 7, die im Modulo 16 mit Nibble 8 ver-XOR-t werden. Kommt 15 heraus, ist alles ok, bei jedem anderen Wert hat das Paket was abbekommen.
		+
		+	Mit vorletztem Satz ist der Pseudo-Code
		+
		+	<pre>
		+	summe := Summe(nibble[0 .. 7]) Binär_AND 0x0F
		+	WENN (summe Binär_XOR nibble[8]) = 0x0F
		+	DANN
		+	"Paket ok"
		+	ANDERNFALLS
		+	"Paket nicht ok"
		+	ENDE WENN
		+	</pre>
		+
		+	gemeint, falls das besser verständlich ist.
		+	==Zusammenfassung==
		+	{\| class="wikitable"
		+	\| '''Nibbles'''
		+	\| colspan="4" align="center" \| Nibble 0
		+	\| colspan="4" align="center" \| Nibble 1
		+	\| colspan="4" align="center" \| Nibble 2
		+	\| colspan="4" align="center" \| Nibble 3
		+	\| colspan="4" align="center" \| Nibble 4
		+	\| colspan="4" align="center" \| Nibble 5
		+	\| colspan="4" align="center" \| Nibble 6
		+	\| colspan="4" align="center" \| Nibble 7
		+	\| colspan="4" align="center" \| Nibble 8
		+	\|-
		+	\| '''Empfangen'''
		+	\| 0 \|\| 0 \|\| 0 \|\| 0 \|\| 0 \|\| 1 \|\| 0 \|\| 1 \|\| 0 \|\| 1 \|\| 0 \|\| 0 \|\| 1 \|\| 1 \|\| 0 \|\| 0 \|\| 1 \|\| 1 \|\| 1 \|\| 1 \|\| 0 \|\| 0 \|\| 0 \|\| 0 \|\| 0 \|\| 0 \|\| 1 \|\| 0 \|\| 1 \|\| 0 \|\| 1 \|\| 0 \|\| 0 \|\| 0 \|\| 0 \|\| 1
		+	\|-
		+	\| '''Bit-Reversal'''
		+	\| 0 \|\| 0 \|\| 0 \|\| 0 \|\| 1 \|\| 0 \|\| 1 \|\| 0 \|\| 0 \|\| 0 \|\| 1 \|\| 0 \|\| 0 \|\| 0 \|\| 1 \|\| 1 \|\| 1 \|\| 1 \|\| 1 \|\| 1 \|\| 0 \|\| 0 \|\| 0 \|\| 0 \|\| 0 \|\| 1 \|\| 0 \|\| 0 \|\| 0 \|\| 1 \|\| 0 \|\| 1 \|\| 1 \|\| 0 \|\| 0 \|\| 0
		+	\|-
		+	\| '''Bezeichnung'''
		+	\| colspan="4" align="center" \| Adresse
		+	\| ?
		+	\| Sync
		+	\| colspan="2" align="center" \| Schalter
		+	\| ?
		+	\| ?
		+	\| ?
		+	\| Low Bat
		+	\| colspan="4" align="center" \| Temp 0
		+	\| colspan="4" align="center" \| Temp 1
		+	\| colspan="4" align="center" \| Temp 2
		+	\| colspan="4" align="center" \| Hygro 0
		+	\| colspan="4" align="center" \| Hygro 1
		+	\| colspan="4" align="center" \| Prüfsumme
		+	\|-
		+	\| '''Bedeutung'''
		+	\| colspan="4" align="center" \| 0
		+	\| ?
		+	\| nein
		+	\| colspan="2" align="center" \| 1
		+	\| ?
		+	\| ?
		+	\| ?
		+	\| nein
		+	\| colspan="4" align="center" \| 3
		+	\| colspan="4" align="center" \| 15
		+	\| colspan="4" align="center" \| 0
		+	\| colspan="4" align="center" \| 4
		+	\| colspan="4" align="center" \| 5
		+	\| colspan="4" align="center" \| 8
		+	\|}
		+
		+	Die Temperatur lässt sich mit (3 + 15 * 16 + 0 * 256)/10 = 24,3 berechnen. Die Luftfeuchte entspricht 54%
		+
		+	Die Prüfsumme hier ist 8, also müssen die restlichen Bytes 7 entsprechen:
		+
		+	(0 + 10 + 2 + 3 + 15 + 0 + 4 + 5) AND 15 = 39 AND 15 = 7
		+
		+	7 XOR 8 = 15 => korrekt.
		+
		+	=Software=
		+	Um weder Logic-Analyzer noch PC für die Erfassung der Außentemperatur und Luftfeuchte zu bemühen, soll der Code wieder auf einen Mikrocontroller. Aus gewohnheit kommt wieder ein AVR ATmega8 zum Einsatz. Zur bequemen Auswertung habe ich dieses mal den ICP (Input Compare Pin) bemüht. Da ich bis jetzt keine größere Erfahrung mit dem Komparator hatte, inspirierte ich mich ein wenig an der Atmel AppNote [http://www.atmel.com/Images/doc8014.pdf AVR135]. Diese beschreibt die Auswertung des Duty-Cylces eines PWM-Signals, also genau das, was man für den Empfänger braucht.=
		+
		+	Um einen ungefähren Ausgangswert zu haben, eine kleine Rechnung: das kürzeste Signal hat eine Pulsweite von etwa 2ms, das längste 9ms. Diese müssen also zuverlässig erkannt werden. Der AVR läuft mit 12MHz (der Quarz steckt noch vom [[EMR7370]] im Breadboard), wodurch der AVR eine Zyklusdauer von 83,33ns entspricht. 8ms enstprechen genau 96000 Taktzyklen - etwas viel für den 16-Bit-Timer. Mit dem großzügigen Vorteiler 1024 kommt man auf knapp 94. Bleib noch die Frage, ob die 2 und 4ms sauber unterschieden werden können. 2ms entspricht 23 Timerzyklen, 4ms 47 - also durchaus brauchbare Werte.
		+
		+	Zur Bestätigung dieser Theorie baute ich die AppNote so um, dass sie mir die Zählerstände für die jeweiligen High-Zyklen ausgab - mit durchschlagendem Erfolg. Zwar wackelten die Werte ein wenig, das aber im mehr als vertretbaren Rahmen.
		+
		+	Zur Auswertung wird eine kleine Statemachine verwendet, was sich schlimmer anhört, als es eigentlich ist. In einer Variable wird der Zustand des Empfangs geschrieben: Warten auf Paket, Synchronisiert + Datenempfang, Fertig. Wird ein Paket empfangen, werden die Bits in ein Array geschrieben und ein Zähler hochgezählt. Ist dieser bei 36 (der Anzahl der Bits) angelangt, geht der Empfänger in den Zustand Fertig über und keine weiteren Bits werden eingelesen. Ist die Auswertung abgeschlossen, geht der Zustand in "Warten" zurück. Wird eine Pulslänge empfangen, die weder einer 1, 0 noch Sync entspricht, wird der Automat ebenfalls in Warten zurückgesetzt, wodurch die zuletzt empfangenen Bits verworfen werden.
		+
		+	==Der Trick mit den Bits==
		+	Zunächst habe ich Bits einfach wie sie gekommen sind in den Array geschrieben und erst zur Auswertung in die richtige Reihenfolge gebracht. Das kostet Zeit und Speicher, was sich durch geschickten Code minimieren lässt.
		+
		+	Schaut man sich das Nibble-weise Bitreversal genauer an,
		+
		+	{\| class="wikitable"
		+	\|-
		+	! Bit mit Nr. !! (Binär) !! soll in Spalte !! (Binär)
		+	\|-
		+	\| 0 \|\| 0000 \|\| 4 \|\| 0100
		+	\|-
		+	\| 1 \|\| 0001 \|\| 5 \|\| 0101
		+	\|-
		+	\| 2 \|\| 0010 \|\| 6 \|\| 0110
		+	\|-
		+	\| 3 \|\| 0011 \|\| 7 \|\| 0111
		+	\|-
		+	\| 4 \|\| 0100 \|\| 0 \|\| 0000
		+	\|-
		+	\| 5 \|\| 0101 \|\| 1 \|\| 0001
		+	\|-
		+	\| 6 \|\| 0110 \|\| 2 \|\| 0010
		+	\|-
		+	\| 7 \|\| 0111 \|\| 3 \|\| 0011
		+	\|}
		+
		+	sieht man, dass man für die Zuordnung eigentlich nur Bit 3 kippen muss. Alle Bits ab Bit 4 kann man für die Zuordnung der Bytes verwenden, was im Quellcode wie folgt aussieht:
		+
		+	<source lang="c">
		+	if(bit == TCM_BIT_1) {
		+	uint8_t bytepos = tcm_pos >> 3;
		+	uint8_t bitpos = (tcm_pos ^ 4) & 7;
		+	tcm_bits[bytepos] \|= 1<<bitpos;
		+	}
		+	</source>
		+
		+	Das spart wenn ich mich recht erinnere knapp 40 Byte und wahrscheinlich einige Zyklen in der CPU.

Hobbyelektronik.org - Letzte Änderungen [de]

Vorlage:Warnung/Doku

Vorlage:Warnung

Tchibo Wetterstation