Stap 3: Exploitatie van de gegevens
OK, nu is wat we hebben een verzameling van gegevensbestanden met bits (eigenlijk tekens vertegenwoordigen binaire cijfers, die technisch verschilt).
Het gebruik van een bestand vergelijking programma zal helpen bij het identificeren welk deel wordt voor elke parameter gewijzigd.
Wat we zien is niet alleen een deel wijzigingen maar het laatste deel van het bericht ook. Over het algemeen wanneer communicatie gaat de juistheid van de gegevens is nooit en garanderen dus een checksum meestal gebruikt wordt om ervoor te zorgen dat er geen gegevens heeft beschadigd. De controlesom zullen later bestudeerd worden.
De opdrachten
ON/OFF:
Alleen een beetje wijzigingen, de eerste van de 6de byte (of de 40ste bit). Als dit 1 is de opdracht is ingeschakeld, als 0 is de opdracht OFF
AUTO/WARMTE/KOEL/DROOG
3 bits wijzigen: bits 45 tot 48 (zie foto)
0000 = AUTO 1100 = COOL 0100 = DRY 0010 = HEAT
Swing
bits 64 tot en met 67:
1111 = swing auto 1000 = swing lowest 0100 = swing low 1100 = swing high 0010 = swing higest
Ventilatorsnelheid
beetje 68 tot en met 72:
1100 = lowest 0010 = low 1010 = medium 0110 = high 1110 = highest 0101 = auto
Opties (Byte 13):
Powerful: 10000000 Quiet: 00000100 (and the Fan speed is set to minimum) None: 00000000
Temperatuur:
Het wordt hier een beetje lastiger omdat het zou leuk zijn om te begrijpen hoe de waarde is gecodeerd en scant niet alle mogelijkheden.
We hebben bemonsterd 16° C en 30° C, 21° C. Binair:
16 = 10000 22 = 10110 30 = 11110
De juiste zone voor de temperatuur is niet gevonden met behulp van deze waarden. Maar vaak hardware bits gebruiken in omgekeerde volgorde (meest significante Bit of minst significante Bit aan de linkerkant van het nummer, ook wel aangeduid als Little Endian of Big Endian). Als de omkering van de bits de verkregen waarden is:
16 = 00001 22 = 01101 30 = 01111
Dit geeft een match voor de 3 waarden bij bits 49 tot 53. Dit is nogal verwonderlijk als de waarde niet is afgestemd op een byte (dichtstbijzijnde zou 6 x 8 = 48e bits). Dit betekent dat wanneer het bouw van een bericht de code moet verschuiven van beet de temperatuur.
Dat bijgevolg valideert de eerste hypothese betreffende timing waarden gebruikt voor 0 en 1 :)
Timer A:
De tijdopnemers zijn gecodeerd in meerdere posities: eerste waarde wordt gebruikt om aan te geven dat de A-timer is op, dan een tweede wordt gebruikt om aan te geven van de waarde van de timer.
Timer actieve toestand kan worden gevonden op de dezelfde byte als ON_OFF (6de byte, ten tweede bits, dus vanaf het begin van de nettolading 41e bit).
Dus is de Timer A actief als de byte is dat de 6e byte eruit:
x010xxx, the first bit being the ON/OFF bit.
Voor de duur van de timer gebruiken dezelfde codering die met temperatuur en codering minuten en niet uren (als de externe beeldschermen), de waarde kan worden gevonden op de tweede helft van de 12e byte.
Timer B:
B de timer is actief als de 2de bit van de ON/OFF byte 1 is. Als de timer A brandt altijd bij het gebruik van de timer B, eruit de byte:
x110xxx, the first bit being the ON/OFF bit.
OK, moet hier ik toegeven dat ik niet de sleutel tot deze waarde vinden, misschien is het een delta tussen timer A en B, misschien een andere eenheid... Waarheid is: who cares over timers wanneer het doel is om het te controleren (automatisch) van een computer? :) Zelfs timer die a niet in het einde in mijn systeem gebruikt wordt, ik was gewoon blij te hebben gevonden.
Checksum:
Ah. Hier is een waarde die niet kan worden genegeerd. Het is van cruciaal belang om het te begrijpen.
Na een paar tests blijkt dat de controlesom voor de nettolading gedeeltelijk enige (niet inclusief de invoering), en is het resultaat van de eenvoudige som van alle bytes, slechts één byte van het resultaat (het negeren van overstorten) te houden. De truc is, natuurlijk, dat deze controlesom is gemaakt door een Big Endian systeem, zodat elke byte ongedaan worden gemaakt moet voordat het wordt opgeteld, dan het resultaat weer teruggedraaid.
