Hallo!
Ich versuche seit Tagen die Funkübertagung von meinen
Thermo-Hygro-Sensoren (TFA Dostmann TS33F) zu verstehen um es selber
generieren zu können. Ich habe viel gefunden zu anderen Sensoren, aber
meiner ist leider anders.
Einige Infos waren hilfreich um das Protokoll bis hier zu verstehen,
aber ich komme einfach nicht mit der Checksumme weiter! Hab schon so
viel gerechnet und probiert.. Ich vermute XOR-Verknüpfungen, aber wenn
ich glaube, es geschafft zu haben, klappt es bei dem nächsten Datensatz
nicht mehr :-(
Hier mein aktueller Wissensstand:
Codierung: Biphase-Mark-Code, lässt sich gut und einfach ablesen.
Gesamtumfang:11Byte (LSB-first)
in den ersten 4 Byte ist ID, Typ und Kanal codiert. Ändert sich nach
Reset!(siehe Protokolle). Letzes Bit enthält Vorzeichen der Temperatur.
Danach folgt die Temperatur in 3 Nibbles mit noch unbekannter Codierung,
aber das wäre nicht so schlimm. Ich vermute Faktor + Offset [muß ja auch
für Fahrenheit gehen].
Die nächsten beiden Nibbles waren bisher immer fix (evtl. Bat.low und
"Messbereich verlassen").
Danach 2 Nibbles mit Luftfeuchtigkeit, einfach BCD, zuerst 1%, dann 10%.
Das nächste Nibble habe ich noch nicht verstanden und wird fast immer
von '1111' gefolgt. den Zusammenhang vesteh ich nicht.
Ich vermute, dass hiernach die Checksumme kommt (siehe . Aber evtl. ist
auch der Taupunkt noch irgendwo enthalten - ich denke aber eher, dass
den die Wetterstation ausrechnen wird. Es soll aber wohl Sensoren geben,
die das auch übertragen.
Ich würde mich sehr freuen wenn jemand einen Verdacht hat! Ich komme wie
gesagt nicht weiter und hab wirklich schon viel ausprobiert.
Hier mal ein paar Datensätze:, wie gesagt, ich gehe davon aus, dass die
letzten 5 Nibbles zur Fehlererkennung vorgesehen sind. Teilweise
funktioniert XOR auf die Nutzdaten, dann aber wieder nicht. Es soll auch
Checksummen geben, bei denen von den Nutzdaten die Summe gebildet wird
und nur das untere Byte dann geschrieben wird, oder manche addieren
etwas zur Summe hinzu.. Ich komme momentan hier leider nicht weiter,
vielleicht übersehe ich auch nur irgendwas? Das darf doch nicht so
schwer sein, oder??
Der Grund für das ganze ist, dass ich eben an meine Wetterstation eigene
Sensoren anschließen möchte. Dafür muss ich natürlich die Checksumme
bilden können! Da bin ich natürlich nicht der erste, aber ich habe
keinen Hinweis für dieses Protokoll finden können! Hier sind viel mehr
Bits zur Fehlererkennung enthalten!
Vielen Dank schon einmal falls Euch etwas einfällt!
So ganz kann ich Deiner Tabelle nicht folgen:
Ich würde vermuten, dass die Sensor ID nicht wechselt, das tut sie in
Deinem Auszug oben aber.
Oder hast Du mehrere Sensoren dran und deswegen unterschiedliche IDs?
Für die Entschlüsseluung würde ich mir außerdem noch ein paar mehr
wirklich unterschiedliche Temperaturwerte wünschen.
Gruß, Ulrich
Dein Temperaturwert sollte wie folgt verschlüsselt sein, immer LSBit
first:
1
23.8°C;60%0110001110010->110001110010
2
??83??
3
23.3°C;61%0111100110000->111100110000
4
??33??
5
23.2°C;61%0110100110010->110100110010
6
??23??
7
23.5°C;61%0111010110000->111010110000
8
??53??
9
25,752%0111110101010->111110101010
10
??75??
Zugegeben, damit habe ich immer noch nicht die 10er Grad gefunden, aber
immerhin zeigt es auf, dass die vermuteten Nibble nicht unbedingt solche
sein müssen.
Es zeigt außerdem, dass es schwer ist, die Position einer Information zu
finden, wenn die Information nur wenig differiert. Mach doch noch mal so
einen Log und sorge dafür, dass der Temperaturbereich auch mal von
-4...+20 Grad abgedeckt wird, sonst wird das nix.
Gruß, Ulrich
Hi!
Also es ist das selbe Gerät. Die ID steht in den ersten 4 Nibbles. Im
oberen Log-Bereich habe ich immer Reset gemacht weil ich sonst zu lange
auf den nächsten Wert warten muss.
Da ich andere Messwerte in dieses Protokoll bringen muss, könnte ich die
genaue Aufschlüsselung der Temperatur auch experimentell danach
ermitteln.
Das größte Problem ist die Checksumme. Wenn ich die Umrechnung hierfür
nicht habe, dann klappt das leider nicht.
Ich leg das Ding aber gleich mal ins Eisfach. Der eigentliche Sensor ist
via I²C im Gerät angebunden - an den eigentlichen MEsswiderstand komme
ich nicht heran. Hatte schon überlegt den eigentlichen Sensor zu
simulieren, aber ich denke, dass der I²C-Code sicher auch etwas
kryptisch sein wird. Dann hätte man die Messwerte ja einfacher abändern
können, oder sogar erstmal die Messwerte meines zukünftigen Sensors
damit vererbeiten können, aber ich wollte eher einen ATmega an ein
433MHz-Modul setzen um die Werte zu übertragen - wesentlich billiger!
Also, ich lass den Sensor eben abkühlen.. Die Logs muss ich ja momentan
noch alle per Hand ablesen... das dauert dann etwas..
Ich denke aber,dass die Aufschlüsselung der Temperatur nicht so dringend
ist wie die Checksumme am Ende!
gznw
Ich widerspreche Dir ja garnicht, aber es ist einfacher etwas heraus zu
finden, wenn man möglichst viel kennt.
Am besten wäre es natürlich, wenn man automatisch die Daten von I2C und
Funkprotokoll loggen würde. Hilfreich wäre es auch gewesen, wenn Du das
mit dem Reset kenntlich gemacht hättest. Ein automatisches Loggen würde
natürlich auch über Nacht einfach durchlaufen.
Außerdem verwenden einige Funkprotokolle an verschiedenen Stellen ein
Toggle-Bit. Dieses schaltet bei jeder neuen Sendung einfach nur um.
Durch den Reset wird dieser Mechanismus vermutlich ausgehebelt.
Gruß, Ulrich
Hallo!
Ja, da geb ich Dir auf jeden Fall Recht! Ich habe auch eine ganze Weile
versucht das Ganze automatisch auszulesen, aber ich bekam immer irgendwo
einen Fehler hinterher und dann hab ich das erstmal alles per Hand
gemacht...
Ich hab noch einmal ein paar Werte.. Übrigens echt gut, dass ich
wirklich mal tiefe und hohe Werte genommen habe! Es ändert sich doch
schon einiges, von dem ich vorher angenommen habe, dass es fix wäre!
Zu dem Toggle-Bit: Oben im ersten Log habe ich immer ein Reset gemacht,
außer ab da wo ich geschrieben habe, daß die ID gleich bleibt, also die
letzten 3 sind aufeinander folgende Protokolle ohne Reset!
Bei den Werten ist mir aufgefallen, dass das vermutliche
"Vorzeichen"-Bits doch keins ist!
Und ganz wichtig!!! Wahrscheinlich sind vor allen Bits noch 2 Einsen!!!
Das wäre für die Checksumme natürlich extrem wichtig! aber 2 einzelne
Bit? Ich habe es eher dafür vermutet, dass der Sender einschwingen muss,
die sind nämlich nicht immer so sauber.
Ich habe die Aufteilung etwas angepasst, so wie ich es vermute.
So, hier noch ein log:
Da fällt mir gerade auf, dass das mit den zwei ersten Bit doch gut
hinkommen könnte, wenn man sich oben Deine Aufschlüsselung der
Temperatur anguckt! Dann würde sich alles etwas veschieben. Zwischen
Temperatur und Luftfeuchtigkeit müssten dann aber wieder zwei Bit
einzeln stehen, sonst kommt das mit der Luftfeuchtigkeit nicht mehr hin!
Also ich denke, dass es wirklich so ist mit der Temperatur wie Du oben
schon geschrieben hast! Ich kann die Logs leider nicht mehr ändern, da
habe ich scheinbar Zahlendreher drin! sehr schlecht! Ich mache es ja per
Hand.
Also es kommt sonst ja gut hin außer bei den 10ern. Im letzen Log mit
-2.5° Ist hoffentlich ein Fehler drin! Da käme es nämlich nicht hin.
Also wäre das hier dann mein aktueller Stand mit den beiden zusätzlichen
bits am Anfang.. Aber noch nichts weiter zur Checksumme :-(
Hallo!
Also das ganze scheint doch noch komplizierter zu sein!
Ich bin eigentlich davon ausgegangen, dass die Daten 3x direkt
hintereinander gesendet werden, also einfach 2x wiederholt werden, aber
ich habe gerade bemerkt, dass die Daten nicht genau gleich sind! Ich
gehe mal davon aus, daß da noch codiert ist, welche Nachricht das ist.
Hier noch ein Log von einer Sendung:
--------ID--------- --Typ, Kanal & Nummer?-- --Temperatur-- Feuchte -------Check-------
Da ja im Prinzip die Nutzdaten gleich sein werden, bis auf
"Sendungsnummer", würde ich sagen, dass "nur" die letzen 4 Nibbles zur
Kontrolle dienen!
Eine einfache XOR-Verknüpfung der einzelnen Nibbles kan ich mir nicht
vorstellen weil die Änderung der vorherigen Daten nur auf die letzten 3
Bit des einen Nibbles beschränkt ist und sich dabei auch nur die letzten
3 Bit bei XOR ja nur ändern dürften. Demnach müsste das Ergebnis-Nibble
am ersten Bit bei allen gleich sein. Solch ein Nibble taucht da aber
nicht auf.
Da kommt dann vielleicht noch das angesprochene Toggle-Bit dazu???
Hat da jemand eine Vermutung?
Also wie gesagt, ich muss unbedingt den Check-Bereich entschlüsseln
können!
Die Bits sind nicht unbedingt in feste nibble zusammen gepackt, sondern
kommen, wenn man sie in einen seriell-parallel Wandler schickt nachher
an einer Position aus, an der man einfach den Protokoll-Overhead
ausmaskiert und sinnvolle Ziffern erhält, am einfachsten BCD codiert.
So verwundert es mich nicht, dass sich das gesuchte Toggle-Bit mitten
zwischen den Celsius Einern und Zehnern versteckt. Aber ich glaube, Du
hast einen Tippfehler, es muss 69.3°C und -2.3°C heißen, oder?
Um einen weiteren Kandidaten zu finden, solltest Du den Sensor mal mit
einem Labornetzteil versorgen und sehen, ob du das so runter regeln
kannst, dass der Sensor in Low-Battery geht. Manche Sensoren gegen die
Batterispannung auch in mehreren Stufen an. Damit wäre dann ein weiteres
Bit oder sogar mehrere definiert.
Du hast auch recht, wenn Du sagst, dass einige Blöcke in dem Prokoll
vorhanden sind, die sich nie ändern. Die Kodierung erfordert, dass sich
der Empfänger synchronisiert.
Für ein Muster hinter der Prüfsumme müsste man nun noch zwei oder drei
Pakete haben, die identische Werte für Temperatur und Feuchte
übertragen...
Sportliche Aufgabe so ohne maschinelle Aufzeichnung...
Wie machst Du das überhaupt von Hand? Sitzt du am Scope auf
Single-Trigger und wartest auf ein Telegramm?
Gruß, Ulrich
Hier nur der Ausschnitt um die Temperatur herum. Das mit V
gekennzeichnete Bit ist das Vorzeichen von eben. Das neu mit P
gekennzeichnete Bit scheint die Anzahl der im davor stehenden T-Zehner
+Vorzeichen auf eine gerade Anzahl Bits aufzurunden, also even Parity.
Das zuerst vermutete Toggle Bit T macht vielleicht das selbe für T-Einer
und T-10tel.
Die drei noch nicht dekodierten Bits zwischen T-10er und Vorzeichen
könnten für die Batterie stehen.
Ach noch einer :) Auch das Bit hinter der Feuchte scheint Even-Parity
für eben Feuchte zu sein. Hab noch einmal ein paar Deiner Telegramme
zusammen kopiert und die Sachen entsprechend markiert.
Gruß und gute Nacht
Ulrich
Hi!
Mensch!! Da hast Du ja echt noch einiges herausgefunden!! Cool!
Also ich komme huete leider erst spät nach Hause, ahbe aber gerade eben
noch schnell ein paar Logs gemacht.
Ich habe leider nur ein analoges Oszilloskop, daher muss ich es mit der
"Soundkarten"-Variante machen.. Etwas unschön, aber erstaunlich gut
geeignet dafür :-)
Vor allem weil man über so langen Zeitraum aufzeichnen kann. Ich werde
mir aber evtl. doch noch einen Controller programmieren dafür.. Den
Fehler in meinem Programm hab ich gefunden.. Aber eigentlich geht es ja
auch so...
Also ich habe nur mal auf die Schnelle per Poti die Spannung stark
abgesenkt, da müsste auf jeden Fall jetzt ein Low-Bat drin sein. Die
Spannung war dann wohl auch so gering, dass der I²C-Sensor nicht mehr
richtig ging.. [na, ob das jetzt wirklich gut ist?] Auf jeden Fall
konnte ich so bei der Temperatur ein HH.H erreichen und auch die
Luftfeuchtigkeit hatte ihr Maximum von 99% erreicht. Also wäre das ganze
schon interessant. Ich nehm die Logs mal mit udn guck mir das unterwegs
an. Muß leider gleich wieder los.
ZU den Logs. Jedes Mal ein Reset - ich wollte gleiche Werte bekommen.
Dann 2x 2gleiche Werte.
//Edit: Ach ja, das sind wieder nur die Daten aus dem mittleren Block,
so wie am Anfang ;-) und die Reihnfolge der Logs ist auch etwas anders
als aufgezeichnet.
Bis später...
Hab ich schon gesehen :)
Das Batterie-Bit scheint das letzte in dem 3er-Pack zu sein, das hinter
den T-10er und vor dem Positiv Bit liegt. Habe es mal mit B
gekennzeichnet:
Ja,hab das da auch irgendwie so vermutet.. Zu dem Sensor kann ich gerade
von unterwegs nur das sagen was ich mal mit dem handy fotografiert habe.
HIDEKI
TS04-HUMIDITY
E-PC-TS04-2F0V0
050720 REV.0.1
Ich müsste mal gucken was der genau kann..das mit dem I2C hab ich mal
von den Anschlüssen abgeleitet: SCL & SDA, gnd und VCC
Hi!
Also ich habe leider über den Sensor nicht wirklich viel herausfinden
können!
Ich mache morgen Vormittag noch ein paar Logs und dann werde ich noch
einmal versuchen, etwas über die letzten 6 Nibble herausfinden zu
können.. Ich weiß leider nicht, welche Daten da noch drin enthalten sein
könnten... Taupunkt bestimmt nicht mehr.. Da bleiben ja auch nicht mehr
viele Bits übrig für Daten.
Ich habe mal alles bisher zusammengefasst, man kommt ja schnell
durcheinander..
S ------ID--------- Typ, Kanal Nr.? 0.1° 1° T 10° B V P 1% 10% P -------Check-------
Jetzt frag ich mich, wie es zu der Änderung na der ID kommt. Das werde
ich mal morgen mit ein paar Logs von den 3Paketen testen. Ich hoffe,
dass da immer diese Reihenfolge auftritt, dann wäre das gelöst!
Aber die restlichen Bits, können doch unmöglich alle nur zum Check sein,
oder? Zumal es ja schon Parity-Bits gibt. Also noch einmal Parity oder
ein XOR könnte ich mir vorstellen, wobei XOR auf unterschiedliche
Blöcke? - das wird ja auch nix.
Ich habe mal eine Version gehört mit Summe über alle Daten und dann die
unteren 2 Nibble weg oder nur die unteren 2 hinschreiben... Aber was
macht man mit den einzelnen? Das geht ja genauso wenig. Dann bleibt ja
nur Parity, oder was gibt es noch? Meinst Du, es gibt sowas wie "Kennung
der letzten oder nächsten Sendung"? - würde bei Temperatursensoren aber
auch wenig Sinn machen, oder?
Vielleciht sollte ich mal jetzt versuchen so einen 3er Block selber zu
erstellen und gucken was die Wetterstation dazu sagt, also ob die das
akzeptiert. Vielleicht wertet sie auch gar nicht alle Bits aus??
Ein Versuch wird es wert sein, denke ich.
So, bis später...
gznw
Hi!
Also es gibt durchaus Funkprotokolle bei diesen Baumarktsensoren, die
ein Paket drei mal hintereinander raus husten. Dabei sind natürlich alle
Sensor/ID/Messwert bezogenen Daten identisch, aber der Footer
unterschiedet sich, damit der Empfänger weiß, um welche der drei
Sendungen es sich handelt.
Es gibt auch Sensoren, die die Daten einmal normal und einmal invertiert
senden und auch sonst noch verschiedene bunte Dinge mit den Daten
veranstalten.
Um dem Geheimnis auf die Spur zu kommen, müsste man nun mal ein paar
Blöcke komplett haben, also 3 (Mehrfach-) Aussendungen mit identischem
Inhalt (gleiche Kennung, also ohne Reset und gleiche Messwerte) und das
dann noch 3x mit jeweils neuen Messwerten. Wichtig ist dabei, dass man
es wirklich ohne Reset durchzieht.
Es scheint in dem Protokoll aber deutliche Recovery-Segmente zu geben,
also Abfolgen von mehreren 1 und 0, die nur dazu dienen, den Empfänger
für das Biphase-Decoding zu synchronisieren. Diese Blöcke werden aus den
0111 oder 1110 Sequenzen zusammen gesetzt. Sie haben sich nämlich in
keinem der Telegramme jemals verändert.
Ach, nebenbei, was Du mit T kennzeichnest ist ein P, es ist das
Even-Parity über den ersten Teil der °C Daten.
Dann scheint es bestimmte Header zu geben, die die Datenblöcke
einleiten. So ist es egal, wie oft Du den Sensor resettest und neu
anmeldest, die ID wird immer mit 1110 010 eingeleitet. Dann folgen 8 bit
ID, dann ein Parity.
SYNC+HEAD --ID-----P Typ, Kanal Nr.?P 0.1° 1° P 10° B V P 1% 10% P ???? SYNC -------Check-------P 0
Hier habe ich noch mal alte und neue Telegramme zusammen kopiert und man
sieht deutlich die gleich bleibenden Teile trotz Reset und Neuanmeldung.
Beachtet man die Dichte mit der das Protokoll an den verschiedenen
Stellen Parities eingebaut hat, so kann man vermuten, dass auch hinter
der von dir als Nr? bezeichneten Stelle ein Parity sitzt. Ich vermute
noch ein weiteres im Typ/Kanal Block. Aber gehen wir davon aus, dass das
letzte Bit in Nr ein Parity ist, dann würde der Sensor immer die Abfolge
2,1,3 als Nummer schicken. Leider habe ich dazu nicht genug vollständige
Sequenzen.
(Löte doch an der Reset Taste mal einen Pin hoch, damit Du nicht in
Versuchung kommst:) )
Der noch unbekannte letzte Teil ist mir noch ein Rätsel. Normalerweise
hätte ich hier auch einen mehr oder weniger konstanten Header erwartet,
aber wie die ersten drei Telegramme zeigen, kann da auch in den ersten
Bits hinter den 10% schon alles Mögliche drin stehen kann. Es ist mit
Sicherheit irgend eine Checksumme, die da verborgen ist, eventuell sogar
drei oder vier, jeweils eine für einen der Datenblöcke im Telegramm.
Ich hatte mein ein Protokoll gesehen, da wurden auch die Telegramme
mehrfach gesendet und in einem der Telegramme wurde die Checksumme
invertiert.
Ach so, das letzte Bit scheint immer 0 zu sein.
Nachtrag:
Ich habe im Footer noch eine Sequenz als SYNC markiert, die an allen
bisher gezeigten Telegrammen 1111 war.
Noch ein Nachtrag:
das vorletzte Bit schein ein Parity über den kompletten Footer zu sein,
also die mit ????+SYNC+Unbekannt.
Gruß, Ulrich
Ich vermute mal, Du hast Dich beim abtippen der der Telegramme vertan
und die Nummer ist 001,010,011, also 1. und 2. Zeile vertauscht. Denn
alle anderen Telegramme hast Du ja per Reset provoziert und in diesen
ist immer 001 an der Position 'Nr.'.
Gruß und gute Nacht
Ulrich
Mensch, also wie Du das so siehst!! Klingt auf jeden Fall echt gut!
Ich habe gerade noch eine Dreiersendung geloggt.. Bzw. ich logge immer
noch und das hier ist das erste Dreierpaket:
Wenn man über so langen Zeitraum loggt, seh ich gerade mal einen
extremen Vorteil der primitiven "Soundkarten-Methode" gegenüber dem
Scope ;-)
Wieviele Pakete meinst Du, müsste man noch machen? Ich würde sonst noch
einmal alle 5 Kanäle durchschalten was mit einem RESET verbunden wäre
:-)
SYNC+HEAD --ID-----P Typ,Kanal P 1 TNR P 0.1° 1° P 10° B V P 1% 10% P ???? SYNC P -------Check------- P 0
So wird schon eher ein Schuh drauß. Es werden augenscheinlich immer zwei
Nibbels von einem Parity beendet, also 8-Bit + Even Parity. Nur bei der
Prüfsumme nicht. Was mich wundert ist, dass die Prüfsumme 16-Bit lang
ist und vor der Prüfsumme noch etwas steht, dass im high Nibble immer F
hat aber trotzdem ein Parity-Bit.
Trotzdem erhält das ganze so langsam ein Muster.
Gruß, Ulrich
Also zuerst noch mal die Frage, ob der Sensor immer n Pakete (3?)
hintereinander sendet, wenn er einen neuen Messwert schickt?
Dann lass bitte mal ein paar Minuten durchlaufen, um heraus zu finden,
ob der Sensor einen Messwert-Zähler hat, z.B. da hinten, wo noch ????
steht.
Dann wäre dieses Nibble, das immer auf F endet auch einer mehr oder
weniger sinnvollen Funktion zugeordnet.
Wenn die Pakete wirklich eine 16-Bit Prüfsumme haben, dann müsste man
sie mal gegen die verschiedenen CRC16 Verfahren laufen lassen und sehen,
welches da möglicherweise passt. Denn einfaches Aufaddieren scheint
nicht zu funktionieren. Dafür ist die Prüfsumme zu hoch.
Gruß, Ulrich
Ja, das mit dem Bett kenn ich ;-)
Und ich wollte eigentlich morgen erst wieder tippen :-) Aber wo ich
gesehen hab, dass Du schon so viel weiter bist...!
Ich muss mir die Pakete auch mal angucken.. momentan tipp ich nur rum
hier..
Was meinst Du zum Kanalwechsel? Meinst Du, die Pakete reichen so schon?
//Edit:
Also das hier sind alles aufeinander folgende Dreier-Pakete! Es kommen
grundsätzlich IMMER bei allen Sensoren hier auf dem Grundstück
3Sendungen in Folge. Und wie gesagt, das sind alles aufeinander folgende
Sendungen!
So und hier hab ich noch ein Paket:
Mal ne Frage zu den CRC-Methoden.. Wie addiert man denn die einzelnen
Bits zusammen wenn es keine wirklichen Nibbles sind?? oder einfach mit
Nullen auffüllen???
Also du hast mehrere dieser Sensoren.
Hast Du auch unterschiedliche Typen, oder haben die alle im 2. Block die
gleichen Kennung und unterscheiden sich nur in der ID?
Aber um das Prokoll zu finden:
Immer alle Dreier-Pakete zusammen loggen und natürlich auch mal ein paar
verschiedene Temperaturen loggen. Aber das hast Du ja schon getan.
Es ist jetzt schon klar, dass das einfach Ändern des Paketzählers (TNR)
bereits eine sehr große Änderung der Prüfsumme zur Folge hat. Wenn es
eine einfache Summe wäre, dann müsste diese sich proportional verändern,
je nachdem wie viele Bits die TNR ggf. verschoben einkalkuliert wird.
Aber die Differenz ist ungleichmäßig hoch. Das deutet auf einen CRC16
Algorithmus hin.
Weitere Resets brauchen wir nicht mehr, denn meine geratenen Parity-Bits
vorne im Telegramm stimmen augenscheinlich. Wenn Du aber noch
andersartige Sensoren hast, dann kannst Du ja mal schauen, ob auch
Typ/Kennung in Bezug auf Parity richtig sind. Die Wahrscheinlichkeit ist
aber sehr hoch.
Oh, das letzte Trippel hat es in sich. Die Messwerte sind identisch zum
Vorgänger Trippel und auch das Nibble an ???? stimmt überein. Aber die
Prüfsumme hat sich ordentlich verändert... eine CRC kann es damit schon
fast nicht mehr sein. Jedenfalls keine CRC16, denn die hätte auf das
gleiche Ergebnis kommen müssen. Es macht keinen Sinn bei einem
Funkprotokoll eine fortlaufende CRC zu verwenden, denn es besteht immer
die Gefahr, dass ein Telegramm verloren geht. Damit wären Sender und
Empfänger bei der CRC auseinander.
SYNC+HEAD --ID-----P Typ,Kanal P 1 TNR P 0.1° 1° P 10° B V P 1% 10% P ???? SYNC P -------Check------- P 0
Sieht eher so aus, als würde der Sensor in die Sequenz vor der Prüfsumme
mit Absicht irgendwas eintragen.
Also mal über Nacht laufen lassen, wenn Du das Logging automatisiert
hast. Und immer schön der Reihe nach nur von einem Sensor loggen oder
eben keinen Reset machen, dann müsste man ja die unterschiedlichen
Sensoren anhand ihrer ID filtern können.
So, jetzt wirklich gute Nacht :)
Ulrich
Ich speicher mal die restliche Aufzeichnung ab, falls wir noch welche
brauchen aus dieser Serie hier. Jetzt werd ich mal die Kanäle durchgehen
um zu gucken wo das Codiert ist.
//Edit: Nee, Du hast Dich bei der Feuchtigkeit vertan!! Oben 53%,
darunter aber 55%! Also doch nciht gleiche Werte!
ARC H. schrieb:> Mal ne Frage zu den CRC-Methoden.. Wie addiert man denn die einzelnen> Bits zusammen wenn es keine wirklichen Nibbles sind?? oder einfach mit> Nullen auffüllen???
Ist schon spät, wa?
Es sind immer Nibbels, also immer vier Bit. Zwei davon stehen immer
zusammen bevor ein Parity kommt, also steht da immer ein Byte.
Jetzt ist etwas Rätseln angesagt, da wir noch nicht wissen, was mit ????
ist und außerdem gibt es noch einige Varianten, wie man die einzelnen
Nibbles zusammen addieren könnte, wenn es doch nur eine Prüfsumme ist.
Also, gute Nacht für heute.
Ulrich
Schade, dass die "Edit"-Funktion hier zeitlich begrenzt ist...
Ich habe es immer noch ncith automatisiert :-( Bin bisher noch nicht
dazu gekommen.. aber stimmt, dann könnte man das über Nacht laufen
lassen..
Ich habe noch einen Regenmesser hier und einen Wind-Sensor mit
zusätzlicher Temperaturerfassung (Windchill).
en müsste ich über Funk auslesen, ich kann aber nicht genau sagen was
nun dann der Windmesser ist... Da fällt mir doch gerade was ein!!!
Wenn alle Sensortypen ihre Daten in das gleiche Protokoll setzen.. also
dann bleiben ja bei einigen Sensoren zwangsläufig Bits unbenutzt!!
Ich muss echt mal gucken, ob der Windmesser das gleiche Protokoll
verwendet.. gar nicht so einfach, weil ich hier insgesamt Neben Regen
und Wind noch 5 weitere Funkthermometer verwende... - ja, 433MHz ist
voll :-)
Nebenbei... 433,925 MHz - genau die selbe Frequenz wie die meisten
Funkfernsteuerungen der Zentralverriegelung und Funksteckdosen und und
und.. Ist echt interessant was da alles so los ist. Das wird auch der
Grund sein für die starke Kontrolle am Ende des Protokolls und sie viel
Parity mittendrin, oder? Also Störungen sind ja vorprogramiert.
Ich geh dann aber auch bald mal. Ich versuch mal den Windsensor zu
finden :-)
Bis dann,
gznw
Ok, falls Du noch weiter machen willst, ich hatte noch einen Bug in der
Bin-Hex Konvertierung, oder auch einfach im Kopf, weil ich das V Bit
vergessen habe, das gehört ja noch zum T-10 Nibble.
> Ist schon spät, wa?> Es sind immer Nibbels, also immer vier Bit. Zwei davon stehen immer> zusammen bevor ein Parity kommt, also steht da immer ein Byte.
peinlich.... Ja.
Hmm... Also ich hab mal ein paar Sachen ausprobiert...
guck mal diese beiden hier:
BA EC ED 42 2C 94 -> CF 8E 6D
BA EC ED 42 2C 84 -> CF 9E 55
Was sich da alles ändert nur wegen des einen Bit!
Oder mal so eine Gegenüberstellung:
BA EC ED 42 2C 84 -> CF 9E 55
BA EC ED 42 2C 94 -> CF 8E 6D
Differenzen
0x10 -> - 0xFE8
BA EC E9 42 2C 84 -> CF 9A 02
BA EC E9 42 2C 94 -> CF 8A 3A
Differenzen
0x10 -> - 0xFC8
BA EC E5 42 2C 84 -> CF 96 CB
BA EC E5 42 2C 94 -> CF 86 F3
Differenzen
0x10 -> - 0xFD8
Aber bei dem hier:
BA EC E5 52 2C 35 -> CF 07 A4
BA EC E5 52 2C 55 -> CF 67 FE
Differenzen
0x20 -> - 0x605A
BA EC E9 52 2C 35 -> CF 0B DF
BA EC E9 52 2C 55 -> CF 6B 37
Differenzen
0x20 -> - 0x5F58
BA EC ED 52 2C 35 -> CF 0F 88
BA EC ED 52 2C 55 -> CF 6F 60
Differenzen
0x20 -> - 0x5FD8
Da muss auf jeden Fall eine etwas komopliziertere Rechnung hinter
stecken fürchte ich... Gibt es irgendwie Programme, die sowas
herausknobeln können? Also müsste ja machbar sein mit einigen Blöcken,
oder?
So.. schon vieeel zu spät!!
Bis denn..
gznw
... dann fällt auf, dass sich das 2. Nibble der Prüfsumme um den
gleichen Wert ändert, wie sich die TNR ändert.
TNR 5->(+4)->9 ... SUM 6->(+4)->A
TNR 9->(+4)->D ... SUM A->(+4)->E
Vergleicht man die Summen über verschiedene Resets hinweg, dann sieht
man, dass sich der Erste Teil der Prüfsumme ändert, aber dann über alle
Telegramme dieses Senders hinweg gleich bleibt:
Zuerst hat der Sensor die ID 0x0A und der erste Teil der Summe ist 0x4F.
Nach reset hat der Sensor die ID 0xEC und die Summe ist 0xCF. Weiter
oben sieht man in den Logs, dass sich dieser erste Teil der Summer nur
dann ändert, wenn sich auch die ID ändert. Dann bleibt er immer gleich.
Allerdings gibt es in der ersten Zeile vermutlich einen Tipfehler oder
einen Übertragungsfehler, denn dort ändert sich die Prüfsumme nach dem
ersten der drei Telegramme. Das tut sie sonst nie. Aus 0x4F6 wird
plötzlich 0x4f2.
Also male ich mir jetzt mal die verschiedenen Varianten übereinander und
schaue was so raus kommt :)
Gruß, Ulrich
Hi!
Also ich habe mal einen anderen Sensor abgehört.. Ich geh davon aus, daß
es der Windmesser ist, aber ich bin mir nicht sicher! Ich wollte gucken
welche Teile gleich sind. Ist ganz interessant, aber auch etwas
frustrieren, da das Protokoll noch mal einige Bytes länger ist!
Der Start ist gleich und auch die "Paketnummern" sind in der gleichen
Reihenfolge!
Hatte leider nicht die aktuellen Wind-Werte hier, aber kurz danach stand
auf der Wetterstation Windchill: 1.9°C Was nun die ganzen Nullen solen
weiß ich nicht - ist ja aber gerade auch egal. Ich denke, daß der erste
Teil auch so aufgeteilt werden kann.. Also da auch noch jeweils ein
Parity, oder? Dann ergibt das oben nicht F4, sondern F9 und könnte für
die Checksummer eben schon ausschlaggebend sein!
gznw
Hallo...
Hab mal noch ne Verständnisfrage wegen des LSB-first..
Also wenn ich das alles hier rechne, oder in Online-CRC-Rechner
eingebe... also muss ich dann nicht die Nibbles auch umdrehen?...
SYNC+HEAD --ID-----P Typ,Kanal P 1 TNR P 9 1 P 0 B V P 9 1 P 0 C p 5 1 p 0 0 p 0 0 p ???? SYNC P -------Check------- P 0
Temperatur und Windmesser im Vergleich.
Ich halte es für möglich, dass die Platine im Windmesser eventuell in
unverändert in einem Combi-Sensor verwendet werden kann, also
Windmesser, Windmesser mit Windrichtung und eventuell auch
Windmesser+Windrichtung+Niederschlagsmenge oder noch mehr. Kann mich
erinnern mal solche 'alles an einem Stecken' Konstruktionen gesehen zu
haben. Oder hat der auch Windrichtung (510->15°)?
Merkwürdig, dass er die Windstärke zwei mal im Telegramm hat.
Das mit der 0xF4 in der Präambel kann schon sein. Ich hatte den Teil
ganz platt als SYNC abgetan. Dafür kommt der aber sehr regelmäßig und
man kann vielleicht davon ausgehen, dass der SYNC bereits gelaufen ist
und hier tatsächlich irgend eine ID steht. Also morgen noch mal alles
mit F9 statt F4 durchrechnen :)
Das 0xF9 könnte eine Art Hersteller ID sein. Danach kommt die Sensor ID.
Oh, der Windsensor zeigt, dass da, wo ich einem immer-1 vermutet habe,
auch eine 0 stehen kann. Das Ding vor der TNR. Also alles mal nach den
neuesten Erkenntnissen, eher Vermutungen, umgestellt:
JA, also der Windsensor hat Richtung, Windchill und Stärke, sowie Böen
drin! Deshalb gehe ich echt davon aus, daß es der Windsensor sein wird,
den ich da erwischt habe.
Zum Kanal habe ich nicht viel herausfinden könne bisher:
1
Ch.1
2
1111 1001 0 1011 0100
3
4
Ch.2
5
1111 1001 0 0011 1010
6
7
Ch.3
8
1111 1001 0 0010 1110
9
10
Ch.4
11
1111 1001 0 1101 0101
12
1111 1001 0 1011 1101
13
14
Ch.5
15
1111 1001 0 0100 1011
Ich vermute den Kanal eigentlich im zweiten Nibble von der Funk-ID und
dachte eigentlich, dass Kanal 4 immer 0101 wäre.. alle Logs vorher waren
von Kanal 4.. Vielleicht hat jeder Kanal auch mehrere Möglichkeiten und
keine ganz starre Kanal-ID.
Ich guck mir das nochmal an mit ein paar Logs..
Nach welchem Muster das erste Nibble abläuft weiß ich nicht - wird aber
eigetnlich auch nicht so wichtig sein, denke ich.
Ich bekomme beim Rechnen keine sinnvollen Sachen raus.. Gibt es Tools
für sowas? Also mehrere Eingangs- und Ausgangswerte eingeben und man
bekommt dann mögliche Rechnungen ausgespuckt, die man dann testen kann?
Bis denn...
gznw
Also überträgt der Windsensor eventuell ein paar Werte mehr wie aktuell,
gemittelt und letzter Höchstwert...
Das mit der Kanal-Nummer ist auch eine gute Idee. Ich hoffe, Du kannst
ausschließen, dass Dir da irgend ein Nachbar noch rein funkt.
Also ich habe bisher keine Tools dafür genutzt. Für CRC Berechnung nutze
ich ggf. den Tiny Hexer, der über Datenblöcke eine CRC berechnen kann.
Aber das Erkennen von den Mustern und Zusammenhängen mache ich einfach
auf einem Blat Papier, bzw. direkt in einem simplen Text Editor. Ich
sehe das mehr so als eine lustige und für Dich vielleicht hilfreiche
Alternative zu Sudoku :)
Ich habe hier noch ein paar Betty Funkfernbedienungen liegen. Hatte
schon mal daran gedacht eine davon zum Empfänger für solche Sensoren um
zu programmieren. Aber die laufen auf 434MHz und ich habe nur einen
Außensensor an einer einfachen Wetterstation und die läuft auf 868MHz...
Da wäre dann erst mal Löten angesagt.
So, ich mach mich jetzt mal ab in die Horizontale.
Gruß, Ulrich
Guten Morgen!
Ja, irgendwie macht das echt auch Spaß mit dem Rätseln,allerdings ist
das mit der CRC.Geschichte nun doch etwas kniffelig.. Ausschließen kann
ich Störungen vom Nachbar nicht,außer bei dem Funkthermometer, bei dem
ich bisher alle logs gemacht habe. Da greif ich das Signal direkt ab.
Ich hab auch schon überlegt,ob es vielleicht auch 2 unabhängige
checksummen sind. Also einmal für den Header und einmal für die Daten..
Guten Abend!
So, endlich macht n ATmega meinen Job :-)
Ist doch ein kleines bisschen einfacher so :-)
Ich lass das mal ne Weile laufen, dann sollte man ja genügend Pakete
bekommen...
Ich bin mir ziemlich sicher, dass bei Dir in der Nähe auch jemand solche
Sensoren hat, oder? Wobei es ja scheinbar sehr viele verschieden
Protokolle gibt. Dies hier scheint schon recht komplex zu sein.
Ach ja, bei Watterott gibt´s diese 433MHz- Sender und Empfänger richtig
günstig (Sender ca.3€ und Empfänger ca. 4€).
Bei meinem Funkthermometer sind Sensor, Controller und Sender richtig
deutlich voneinander getrennt. Daher kann man da einfach am
Sender-Eingang die Daten abgreifen. Wenn Dein Protokoll zufällig so ist
wie meins, dann kannst Du ja auch einen besseren Thermosensor verwenden
und deinen eigenen Sensor verwenden. ;-)
Ach ja, mit den 433MHz-Sender kann man echt richtig viel machen. Die
Funksteckdosen können auch perfekt gesteuert werden. Man muss nur
aufpassen, dass man das Band nicht zumüllt, sonst geht da nicht mehr
viel..
Naja, ich bin ansonsten mit der Berechnung leider noch nicht
weitergekommen. Aber ich habe trotzdem mal die Firma Ventus
angeschrieben, ob man nicht vielleicht einen Tipp bekommen kann. Ich
glaube da zwar nicht dran, aber ein Versuch ist es wert.
Guck mal.. das klappt echt gut so automatisiert. Nun sind die Werte viel
näher zusammen! SO wird das viel besser klappen!!
Ich lass mal über Nacht laufen und speicher das in ner .txt-Datei.
Ich kann die ja dann morgen hier als Anhang einfügen.
Bis denn,
gznw
Hi!
Das sieht doch schon richtig gut aus. Jetzt fehlt nur noch das decoding
der einzelnen nibbles hinter den Bit-Telegramm. Um zu sehen, ob die
Telegramme wenigstens vom Parity her stimmen, könnte man ggf. ein p oder
ein ! hinter ein HEX Nibble schreiben. Dieses Decoding kann man dann
Stück für Stück ausbauen. Wenn es komplett ist und alle Daten auch noch
mit der Prüfsumme übereinstimmen braucht man es nur rückwärts zu
benutzen und schon kann man eigene Telegramme senden :)
Du kannst aber die Decoder Software auch einfach mal anhängen, dann kann
ich da mit basteln.
Habe mir Watterot noch nicht angesehen. Aber ich hatte ja schon gesagt,
dass meine Station auf 868MHz sendet. Ich dachte Deine liegt auf 434MHz.
Das ist zwar unerheblich für das Protokoll, aber ich schau mal nach, was
so geht. Eventuell gibt es ja ein paar dieser Sender in meiner
Nachbarschaft. Das würde ja reichen :)
Gruß, Ulrich
Hi!
Ja, meiner liegt auf 433MHz. Aber Du kannst doch eigentlich bei Deinen
Funksteckdosen-Empfänger auch einfach das Signal abgreifen wenn Du hören
möchtest was bei DIr in der Nähe los ist...
Mein Code muss ich noch weiter bearbeiten.. Der ist echt gerade nicht
schön! Wenn man mit dem Programm noch mehr machen will, dann sollte ich
das wohl mal etwas besser schreiben.
Ich verwende einen ATmega48, gerade mit 18.432MHz.
Als ISR verwende ich (TIMER1_CAPT_vect). Hier muss ich leider jedes Mal
umschalten, ob fallende oder steigende Flanke erkannt werden soll.
BEides geht auf dem Eingang leider nicht. Oder ich nehm ne andere ISR.
Dann erfasse ich die Zeiten zwischen 200 Flanken und im Anschluss werden
daraus die Bits bestimmt und ausgegeben.
Ich werde es heute wohl nicht mehr schaffen, mal gucken...
bis später,
gznw
So, hier mein Code im Anhang. Wie gesagt, der war eigentlich nur dafür
da, dass es funktioniert. Es wird nur das erste Paket ausgewertet, somit
hat man viele Pakete untereinander, die nur wenig Abweichung haben. Ich
muss nun noch in die for-Schleife am Ende bei der Ausgabe eine
Berechnung für Parity und Hex-Wert schreiben.
Da sind bestimmt noch einige Sachen, die man besser machen sollte.
Ganz ganz seltsam ist das Problem an der Stelle wo der Controller warten
soll bis 200Flanken eingelesen wurden! Gefällt mir überhaupt nicht so:
1
while(flanken_index<200)uart_send_string("");
Kannst Du mir sagen warum es nur so klappt??? Anders hängt der
Controller an dieser Stelle! Ich vermute ein Problem zwischen dem Warten
an der Stelle und der ISR.
So!
Ich habe es jetzt mal in diese Form hier gebracht ;-)
Eigentlich kann ich es aber auch nur auf die hex-Werte minimieren, oder?
also z.B. nur:
F9 2A EC E5 22 2C 74 -> CF 06 48
Momentan bekomme ich folgende Ausgabe:
F 9 0 2 A 1 E C 1 E 5 1 2 2 0 2 C 1 7 4 0 C F 0 0 6 4 8
P.S.: Was machen wir eigentlich mit den letzten beiden Bits??? Ach.. das
letzte Parity-Bit wird noch berechnet... kommt noch.
Ansonsten stimme alle von dir vermuteten Parities!
gznw
Hi nochmal!
Also weil ich heute Abend nicht zu Hasue bin, lasse ich mir die Daten
auf einen Serevr laden - immer aktuell ;-)
http://nslu2.homeip.net/myweb/sensor.log
Klappt echt gut so.
Also da hast Du ja jetzt ganze Arbeit geleistet! Alle Achtung.
Da Du ja jetzt nur der erste der drei Pakete aufzeichnest, und das
zeitnah, kann man schön erkennen, dass bei gleichem Inhalt auch die
Prüfsumme immer identisch ausfällt.
Woher weißt Du eigentlich, dass ich Funksteckdosen habe? Hab ich das
irgendwo geschrieben, oder wohnst Du direkt neben mir?
Das Protokoll selbiger ist aber offen gelegt, wenn ich das richtig in
Erinnerung habe. Ist wohl HomeEasy.
Also die Prüfsumme ist nicht so durchsichtig, wie gedacht. Außerdem
scheint es in dem Log auf dem Server auch ein paar Probleme zu geben. Ob
das jetzt an der Software liegt, oder tatsächlich Empfangsprobleme sind,
kann ich nicht sagen. In einigen Fällen stimmen Daten und Prüfsumme
nicht überein, obwohl sie davor und danach korrekt sind. Natürlich meine
ich korrekt im Sinne von sie folgen dem Muster.
Deine Software habe ich mir auch gerade mal angesehen. Also das kann man
noch aufräumen, aber darum geht es nicht. Sie soll ja nur ein kleines
Helferlein sein, damit man mal fortlaufende und nachvollziehbare
Telegramme bekommt. Trotzdem ist es für den kleinen AVR natürlich eng,
wenn Du die 200 Zeiten des Decoders als int ablegst. Wäre vermutlich
besser, den Timer so zu drehen, dass er einen nachvollziehbaren Wert der
Pulsbreite in einem Bereich von <255 schafft. Dann würde das auch in ein
Byte passen. Oder aber DU dekodierst das Bit gleich im ISR und schreibst
nur das Bit raus.
Ach ja, bau doch mal eine kleine globale Variable in das ISR mit rein,
die nach dem 200ersten Flankenwechsel gesetzt wird und damit der
Mainloop signalisiert, dass es was zu holen gibt. Dann kann diese die
Daten auch in Ruhe entschlüsseln und darstellen. Dann setzt sie diese
Variable wieder zurück auf 0.
Das kann man dann ausbauen. Hat man aus der ISR gleich nur noch Bits,
dann passen auch mehrere Telegramme ins RAM und man kann eines
entschlüsseln und darstellen, während ein weiteres parallel dazu vom ISR
empfangen wird, in einen weiteren Puffer.
Gruß, Ulrich
Hallo,
kann es evtl. sein, daß Fehler im Datenstrom sind ?
Hab mal zufällig ein paar Werte incl. einem vom Windsensor?
herausgegriffen und interessanterweise passen einige zu einem
CRC Polynom, aber nicht alle ... das finde ich eher merkwürdig ...
(oder ich sollte anfangen Lotto zu spielen :-) )
Ohne Parity, in Bitreihenfolge
1111 1001 0 F9
1101 0101 1 D5
0111 0011 1 73
0111 1010 1 7A
1010 0110 0 A6
1000 0011 1 83
1010 0010 1 A2
1100 1111 0 CF
1001 0100 1011 1001 94B9
z.B also:
F9D5737AA683A2CF94B9
Parameters:
polynom : 0x8689
order : 16
crcinit : 0x28cd direct, 0xe30e nondirect
crcxor : 0xa766
refin : 1
refout : 1
Results:
crc bit by bit : 0xb994
crc bit by bit fast : 0xb994
F9D5737A2683A2CF1436
Parameters:
polynom : 0x8689
order : 16
crcinit : 0x28cd direct, 0xe30e nondirect
crcxor : 0xa766
refin : 1
refout : 1
Results:
crc bit by bit : 0x3614
crc bit by bit fast : 0x3614
F9296B3298039803A8000014CC50
Parameters:
polynom : 0x8689
order : 16
crcinit : 0x28cd direct, 0xe30e nondirect
crcxor : 0xa766
refin : 1
refout : 1
Results:
crc bit by bit : 0x50cc
crc bit by bit fast : 0x50cc
CU Dirk
HI!
Also Fehler im Datenstrom kann ich fast ausschließen,da ich den Sensor
direkt am ATmega, bzw. STK500 angeschlossen habe, ohne Empfänger,
einfach die Datenleitung abgegriffen.
wo meinst Du denn, sind Fehler im Log? Ich seh das gerade nicht... komme
allerdings auch gerade von der Arbeit...
Es kann evtl. sein, denn ab und zu wird wohl die allererste Flanke nicht
korrekt erfasst. Dann fehlt das erste Bit. Da habe ich extra eine
Überwachung geschrieben, die guckt, ob das 5.Bit eine 1 oder eine 0 ist.
Bei einer 0 werden alle einen nach rechts verschoben. Evtl. wäre da ein
denkfehler im Verschieben. Oder meinst Du den Dreierblock, den ich zum
Nibble geschoben habe?
Zu den Funksteckdosen... ich habe es so verstanden, als Du meintest,
dass Du solche Fernsteuerungen hast.. Meintest Du was anderes?
Das Protokoll von den Dinger ist richtig easy :-)
Hab mal ein Programm geschrieben, das alle Möglichen Geräte durchgeht
und alle einschaltet und danach wieder aus :-) Also so kann mna gucken
wo die Dinger benutzt werden. Ich wollte die eigentlich benutzen um
etwas von einem kleinen Server zu steuern. Bietet sich ja an.
das mit dem CRC muss ich mir anchher angucken.. aber ich kann mir nicht
vorstellen, daß da Fehler im Datenstrom sind.. Die Signale 1 und 0
unterscheiden sich deutlich voneinander. Oder meinst Du erst jetzt wo
ichd as mit dem Controller auslese?
So, muss erstmal ins Bett...
Bis später.
Also wenn der Log doch richtig ist, dann hätte es sich gelohnt, dass ich
das Fenster im Arbeitszimmer aufgelassen habe.. 15° sind es nun hier,
also wurde mal ein Bereich ganz langsam durchlaufen..
Ach ja, die Verbesserungsvorschläge im Programm werd ich noch
umsetzten.. Mit der Entschlüsselung der Bits in der ISR ist wirklich
besser - hab mich da schrittweise durchgearbeitet und es dann so
gelassen weil es ja ging... reine Faulheit.. aber sinnvoller ist Deins
auf jeden Fall. Man kann ja auch alle drei Pakete nebeneinander
schreiben, dann sind auch gleiche Pakete untereinander.
So, nu aber.. Bis denn...
gznw
Hi,
ich meinte keine Fehler in der Auslesung oder im Programm sondern
vom Sensor selbst. Schließe ich jetzt aber mal aus ... (hab jetzt
geschlafen ^_^)
Hab mal ein bisschen weiter getestet.
Wenn ich das Polynom fest lasse würde es auf alle Checksummen
passen, allerdings ändert sich der CRC-Initialwert...
Wenn ich Zeit hab, lasse es mal über alle bisherigen Ergebnisse
laufen; mal sehen ob sich was ergibt ...
CU Dirk
Das mit der CRC ist schon interessant!
Ich vermute jetzt einfach mal ganz dreist, dass der erste Schuss der
Software zur Entschlüsselung nicht 100% läuft. Ist nicht böse gemeint,
aber es gibt im Log auf dem Server einige Stellen, an denen die
Prüfsumme offensichtlich nicht ins Muster passt. Das Log zeigt ganz
klar, dass die Summe immer die gleiche ist, wenn sich in den Daten
nichts ändert. Und trotzdem ändert sie sich manchmal ganz deutlich.
Allerdings finde ich die Stelle, die mir da gestern ins Auge sprang,
jetzt nicht wieder, das Log ist schon recht lang geworden...
Ob das einfache Verschieben ausreicht um die Position zu korrigieren,
wage ich zu bezweifeln. Wenn also das CRC Polynom in 80% der Fälle
passt, haben wir schon einen guten Treffer gelandet.
Ich würde es einfach mal mit in die Software einbauen und nachsehen, ob
es funktioniert. Man kann ja eine kleine HTML sequenz in das printf
einfügen, dass die Zeilen, in denen es passt, farblich hervorhebt.
Man kann davon ausgehen, dass eine CRC nur dann Sinn macht, wenn es für
jede Zeile einen festen Startwert hat. Sonst würde ein gestörter Empfang
verhindern, dass weitere Telegramme decodiert werden können.
Die Daten werden aber, was im log noch nicht drin ist, als
dreier-Telegramme gesendet. Es kann gut sein, dass der init Wert für die
unterschiedlichen Telegramme eines Trippels unterschiedlich sind.
Gruß, Ulrich
Also dann muss ich mir das noch einmal angucken, ob das Problem mit der
ersten nicht erkannten Flanke sich evtl. auch auf andere Bits auswirkt.
Würde mal interessieren, welche Zeilen das waren.
Ich denke, ich sollte das Programm nun aber so ändern, dass jetzt nur
die Hex-Werte ausgegeben werden, oder?
Da die Daten dann ja sowieso schon auf einem kleinen Server liegen
(NSLU2), könnte der ja auch was rechnen.
Also ich müsste die Zeile mal suchen, die fehlerhaft ist. Ich denke,
dass es eigentlich nur eine Verschiebung sein kann. Interessant ist
aber, dass die Fehlerkennung des ersten Bits nicht verieinzet sonder
gehäuft auftritt. Eine richtige Erklärung habe ich dafür noch nicht
gfunden.
Ich muss dann mal gucken wie ich die CRC-Berechnung im µController
umsetze.
//Edit: Also ich hab mal die Daten durchgescrollt und mir ist
aufgefallen, dass
alle Daten wie folgt anfangen:
F9 BA EC E5
Somit kann man doch eigentlich ausschließen, dass es Fehler durch die
Fehlerekennung / Veschiebung auftreten. Verschoben wird ja schon ab dem
4.Bit! ;-)
Ahh, ja, ok.. hab da jetzt was falsches gefunden... ich guck mir das mal
an..
P.S.: Dass man die Beiträge nach 15 Minuten nciht mehr verändern kann
ist ja irgendwie doof :-(
Seltsam, seltsam!!
Guckt mal hier:
Die Parities stimmen aber... Für eine falsche Entschlüsselung wäre das
aber ein seltsamer Zufall, oder?
Da fällt mir gerade ein.. sowas wäre ja gut geeignet um die
Verschlüsselung vor dem "Entschlüsseln" zu sichern :-) Einfach falsche
Prüfsummen zwischendurch rauswerfen, dann fällt die Messung halt unter
den Tisch, aber das wird ja sicher nicht gemacht worden sein.. Aber wäre
ne nette Idee..
Ich muss dann wohl mal wieder mit der Hand parallel gucken was da los
ist.
So, ich denke, ich habe eine effektivere Idee... Man könnte sich ein
eigenes Protokoll zusammenstricken anhand der vermuteten Verschlüsselung
und gucken ob die Wetterstation das annimmt... wenn das der Fall ist,
dann ist das Problem gelöst ;-)
ich mach mich mal an das Programm ran...
Gruß
gznw
Grundsätzlich würde man bei einem Biphase Code so vorgehen:
Man setzt einen TimerIRQ auf, der sich durch die 1111 auf den
Flankenwechsel synchronisiert. Dieser IRQ füllt zudem einen Puffer mit
den empfangenen Bits. Nach der Synchronisation schaut er eigentlich nur
nach, ob innerhalb eines 2x 1-Timings ein Flankenwechsels stattgefunden
hat, dann ist es eine 1 sonst ist es eine 0. Oder man mittelt die
Bitzeit von 1111 aus und schaut nach, ob die später folgenden Flanken
etwa so lang sind oder doppelt so lang.
Das ganz kann man auch noch verriegeln, also man setzt sich tot-Zeiten
innerhalb der ein Flankenwechsel ignoriert wird um Störungen zu filtern.
Oder man macht das altbekannte Oversampling, man tastet eine 0-Zeit
x-mal ab und kann dann sagen, dass ca x/2 Samples mit gleicher Polarität
eine 1 sind, während ca x Samples gleicher Polarität eine 0 sind. Dabei
gilt halt der gemittelte Wert der Samples, so dass kurze Spikes durch
Störungen ignoriert werden.
Jedenfalls schiebt dieser IRQ die Daten in einen langen Bit-Speicher.
Eine andere Routine (muss nicht IRQ sein) wertet diesen Speicher aus in
dem sie nach einem bekannten Pattern sucht, also F9 BA EC E5 oder sie
ignoriert das F, weil dieses durch die Synchronisation verstümmelt sein
könnte.
Findet sie das Wort, so beginnt sie zu dekodieren. Da die Telegramme
unterschiedliche lang sein können, dekodiert sie entweder anhand einer
Tabelle die unterschiedlichen Längen aus, oder sie hat die Möglichkeit
ein weiteres Pattern zu erkennen, das z.B. Anzeigt, wann nun die CRC
erfolgt.
So wäre das ganze sehr dynamisch.
Natürlich ist Deine Analyse aber auch richtig. Wenn der Header F9 BA
EC... stimmt, durch die Bit-Verschiebung und dann auch noch alle
Parities in Ordnung sind, dann sollte alles Andere auch OK sein.
Allerdings kann ein Parity immer nur einen 1-Bit Fehler aufdecken.
Sobald zwei Bits kippen, ist Parity machtlos.
Zur CRC: Es kann durchaus sein, dass im Dreierpack die CRCs
unterschiedlich berechnet werden, oder die mittlere CRC z.B. invertiert
ist. Das kann möglich sein. Aber ich denke nicht, dass das
Hauptaugenmerk der Protokoll-Entwickler auf einer Verschlüsselung lag,
sondern darauf, die Daten auch halbwegs zuverlässig am Empfänger
ankommen zu lassen. Außerdem müssen sie darauf achten, dass nicht zu
viele gleiche Bits im Telegramm sind, denn sonst wäre die
Synchronisation problematisch.
Schließlich möchten die Hersteller solcher Billigwaren keine teuren
Quarze einsetzen, sondern billige aber temperaturanfällige
Keramik-Resonatoren.
Der Taktunterschied zwischen dem im Winter kalten Sensor draußen und dem
warmen Empfänger drinnen kann dann schon immens sein.
Gruß, Ulrich
Hi!
Na, da werd ich ja demnächst noch einmal eine vernünftige Auswertung
machen, die auch für mehrere Sensoren einsetzbar sein wird :-)
Ich habe jetzt einmal ein kurzes Programm geschrieben zum Senden. Mit
den geloggten Daten geht es auch wunderbar!
Jetzt muss ich nur mal ein paar Datensätze haben, die ich da mal in mein
Programm reinsetzen kann. Ich habe erst einmal nur drei Arrays gemacht,
in die ich die Pakete einfach reinkopiert habe:
Das klappt. Wenn die Check-Nibbles nicht stimmen, dann nicht.
Kennt Ihr online-Rechner, in die man einfach mal seine Sachen
reinkopieren kann und der rechnet das dann aus? Dann könnte ich das
testen. Das wäre dann die direkte Methode.
Später würde ich dann gezielt einzelne Bits entsprechend meiner
Messdaten abändern.
Also einen online CRC Generator kenne ich jetzt auswendig nicht.
Du kannst aber den Prozess schon mal teil-automatisieren. Du gibst die
Netto-Daten in hex vor und lässt die Software später die Parity-Bits
dazu berechnen. Die Nettodaten selber brauchen ja die Checksumme.
Das wiederum kannst Du z.B. mit Tiny Hexer (www.mirkes.de) machen. Den
verwende ich auch für sowas. Das Teil ist sehr gut.
Also pack Dir die Nettodaten in eine kleine Datei, importiere sie, lass
die CRC berechnen und dann schaust Du mal was raus kommt.
Dann fügst Du das in deine Software ein.
Oder Du suchst mal nach CRC16 und schaust, welche verschiedenen Polynome
da üblich sind. Dann lässt Du die auf die Netto-Daten los und schaust
was da raus kommt.
Das Üble ist ja, dass man zuerst mal die Parities entfernen, dann CRC
berechnen und anschließen die Parities wieder einfügen muss.
Ist was umständlich.
Aber oben hatte Dirk ja schon mit dem Polynom 0x8689 einen direkten
Treffer.
Zieh das mal durch und schaue was raus kommt.
Wie man eine CRC ini C berechnet hatte ich wohl mal in Nut/OS
(www.ethernut.de) hinzugefügt. Kannst Du Dir dort im Sourceforge
Repository einfach ansehen. Sonst hänge ich Dir da morgen was an diesen
Thread.
Gruß, Ulrich
Hmm.. Also ich hab mir jetzt den Tiny Hexer installiert und die Werte
F9D5737AA683A2CF in eine Datei geladen und dort importiert. Nun muss ich
nur noch gucken wo ich die Parameter für die CRC-Berechnung eingeben
kann.
Ich hab es auch mit mit dem hier versucht:
http://zorc.breitbandkatze.de/crc.html
Aber ich mach scheinbar irgendewtas falsch bei der Bedienung..?? ich
bekomme nicht ansatzweise etwas heraus, das passen könnte..
gznw
Hi,
ich hab mal nochmal viele CRC Sachen durchrechnen lassen.
Die 3 Werte die ich rausgegriffen hatte, waren wirklich Zufall..
hätte ich doch mal besser Lotto spielen sollen.
Sieht jetzt nicht mehr wie eine einfache CRC Checksumme aus.
Hab mir jetzt auch mal die Telegramme genauer angesehen ...
dabei sind mir 2 Werte mit gleicher Checksumme aufgefallen siehe unten:
1111 1001 0 1101 0101 1 0111 0011 1 0111 1010 1 0010 0000 1 0100 0011 1
0000 1010 0 1111 1111 0 0100 1010 1111 1000 0 0
F9 0 BA 1 EC 1 E5 1 40 1 2C 1 05 0 FF 0 25 F1 0
1111 1001 0 1101 0101 1 0111 0011 1 0111 1010 1 1100 1000 1 0100 0011 1
0110 0010 1 0111 1111 1 0100 1010 1111 1000 0 0
F9 0 BA 1 EC 1 E5 1 31 1 2C 1 64 1 EF 1 25 F1 0
Das würde entweder auf eine ganz andere, relativ schlechte,
Checksummenberechnung deuten oder auf eine zusäztliche "Verschlüsselung"
die aber zu Kollisionen führt.
Frage:
Kannst du den Sender eigene Werte senden lassen ?
Dann könnte man geziehlt Abhängigkeiten suchen ..
Oder hat der µC evtl. nützliche (Programmier-)Anschlüsse ?
CU Dirk
Hallo!
Bei den zuletzt geloggten Daten scheint es ja ein Problem gegeben zu
haben. Ich kann mir die Zeilen gerade nicht richtig angucken - bin
unterwegs und hab nur das Handy dabei...
Ich müsste den Datenstrom zwischen Sensor und Controller erstmal
untersuchen und eigene Werte übergeben zu können. Ansonsten hab ich da
nicht viel gesehen damals..das wäre das einzige was mir einfällt. Ich
guck mal.
Hmmm, ich hatte mal was gelesen, dass CRC Verfahren je sicherer werden,
je länger der Text ist, den sie sichern. Kann also vielleicht sein, dass
hier zwei unterschiedliche aber kurze Texte zur gleichen Summe führen?
Ulrich
Hi!
Also im Prinzip müsste ich jetzt wohl mal Schritt für Schritt beide
Messbereiche komplett von unten bis oben unabhängig durchlaufen
lassen... Nun fürchte ich aber, dass das zu heftig wird, nun noch das
Protokoll zwischen Sensor und Controller zu entschlüsseln und einen
Controller das beizubringen, sich so wie der Sensor zu verhalten...
Hab mal das die Daten angeguckt.. I²C ist es doch nicht :-(
Es ist nur ein Teil von dem Ganzen gesendeten...
Hallo!
Ich habe noch einmal etwas probiert! Wenn ich die Datenleitungen
kurzschließe, dann sind ja die gesendeten Messwerte immer gleich
(Fehler).
Alles was sich nun noch ändern kann, ist die Sensor-ID. Also habe ich
einige Resets gemacht und an 2.Stelle in der Checksumme steht immer die
gleiche Zahl! Wie ich festgestellt habe, hängt sie scheinbar nur vom
Kanal ab!
Außerdem ist das letzte Byte vor den Check-Bytes immer 00. Da dachte ich
ja bisher, dass es nur von der Sensor-ID, Sensor-Typ & Kanal abhängt!
Damit müsste man doch nun einen Schritt weiter sein, oder? Ich müsste
mir das mal ausdrucken, da sieht man ja so einiges besser.. Aber ein
Konstanter Wert innerhalb einer Checksumme kann ja schon ein Zeichen
sein...
Mir ist noch etwas aufgefallen,was allerdings wieder nicht so schön ist.
Also die Fälle, in denen die Checksumme trotz gleicher Daten
unterschiedlich waren, da wird wohl doch kein Fehler im Programm sein!
Ich habe das Programm etwas abgeändert und die Korrektur bei
fehlerhafter Erkennung des ersten Bits ausgeschaltet. Es kommt hin und
wieder vor, dass die Checksumme trotzdem verschieden ist! Und das Parity
kommt trotzdem hin! Zufall kann das doch nicht sein.
Da sind nun viele doppelte drin, aber daran kann man sehen, dass nur
eine geringe Anzahl an IDs verfügbar ist.
Hallo!!
So, ich heb noch einmal über Nacht das ganze laufen lassen mit leicht
geöffnetem Fenster -> langsames Durchlaufen der Temperaturen nach
unten..
Bei der Ansicht so mit den hex-Werten rechts, kann man beim
herunterscrollen schon etas mehr erkennen! Temperatur fällt und die
erste Ziffer fällt auch. Die zweite nur etwas.
Leider wird das letzte Byte vor dem Check-Bytes auch beeinflusst... Ich
bin ja wirklich davon ausgegangen, dass dies fix wäre für eine ID..
Naja, hat der Test gestern Abend ja eigentlich auch schon widerlegt..
Ich guck mal ob ich da etwas aus dem Log erkennen kann...Irgendwie sieht
es ja schon sehr wild aus...
Ach ja, hab ja zwei Firmen angeschrieben... Wäre ja möglich gewesen,dass
man wenigstens einen kleinen Tipp bekommt.. Aber leider nichts..
Freundlich waren sie beide, aber mir konnte leider keinerlei Information
gegeben werden, "da das Datenprotokoll als empfindliche, vertrauliche
Information des Unternehmens gesehen wird."
Na, irgendwo ja auch verständlich... Ein Versuch war es wert...
Zu dem Log... ich kann leider keine Fehler ausschließen,aber ich gehe
schon davon aus, dass die Werte stimmen. Die Fehlerkorrektur habe ich
ausgeschaltetund die Parities kommen auch schon hin...
//Edit: Ach ja, ich habe sonst noch einen anderen Snesor, der hat einen
Anschluss für einen externen Sensor. Da könnte ich ja egentlich ein Poti
anschließen.. Wolte ich bisher eigentlich nicht machen weil ich die
Messwerte von dem Sensor an der Stelle haben wollte, aber das wäre nun
eigentlich egal.
Sonst knöpf ich mir den noch einmal vor :-) Dummerweise dauert so ein
Log dann sehr lange wenn man nicht resettet.. Da müsste man ja
eigentlich einen Controller mit der Widerstandsänderung beauftragen und
das dann mal laufen lassen..
Hallo!
Ich habe heute noch etwas weiter loggen lassen...
Vielleicht kommt man dem Ganzen so auf die Schliche?
das '!!' steht an den Stellen, bei denen die Checksumme sich
entgegengesetzt der vorheigen Daten ändert. Ist schon interessant! Ich
habe die Daten so geordnet, dass der nächste Datensatz größer ist als
das vorherige. Hin und wieder wird die Checksumme kleiner!
Das sieht noch ganz schön wild aus. Aber ich muss irgendwie an die
Checksumme von einem anderen Funkthermometer-Protokoll denken, bei dem
einfach nur die unteren Bytes von der eigentlichen Checksumme angegeben
wurden und die vorherigen unter den Dich fallen.
Also z.B.:
1
D486
2
C499 d= - 0FED
3
4
>>>>
5
z.B.
6
...0D486
7
...1C499 d= F013
.. bringt mir aber gerade auch keine neuen Erkenntnisse..
Hier habe ich mal ein paar ausgewählte Datensätze verglichen. Immer so
angeordnet, dass sich immer nur eine Stelle ändert!
Hi noch einmal :-)
Sooo, ich hab was!!!!
Also ich habe mir noch einmal überlegt, ob es wirklich CRC sein wird...
Wäre der Rechenaufwand für so einen mickrigen Controller wie er da in
dem Ding ist nicht etwas hoch? bzw. mit Kanonen auf Spatzen??
Daher hab ich das mal auf logische Verknüpfungen untersucht:
erstes Ergebnis:
Ich habe drei weitere Stichproben gemacht und es kam da auch hin. Heißt
zwar noch nicht, dass es so schon stimmt, aber es sieht bisher schon gut
aus. Vielleicht iste s alles so nach dem Prinzip aufgebaut, vielleciht
noch andere Operationen mit einer Konstanten... Ich guck mal weiter...
//Edit: Es gibt leider Fälle, in denen es nicht hinkommt. Aber ich
vermute trotzdem soewtas in der Rcihtung. Vielleicht hat das letzte Byte
noch was zu tun damit.. oben ist das Nibble 1111 und da kommt es hin.
HIer nicht:
Sorry, dass ich so viel poste.. aber die Edit-Funktion geht leider nur
15Minuten :-(
Ich habe noch etwas herausgefunden: Das zweite Nibbel hat auch etwas
auffälliges! Allerdings nur wenn das Byte vor dem Check FF ist. so wie
vorhin:
Das sind nicht nur die Datensätze, bei denen es hinkam, das sind alle,
die ich probiert habe und die FF hinten haben!
Nun überleg ich einmal, wie das angesprochene Byte reingehen kann und da
es insgesamt im Nutzdatenbereich 8Parity-Bits gibt, bietet sich da doch
eigentlich acuh eine Operation an, oder? Ist allerdings bei dem langen
Protokoll vom Windsensor ja nicht zutreffend, also da gab es ja mehr
Parity-Bits, soweit ich weiß.. Auf jeden Fall bin ich sicher, dass dies
der richtige Weg hier ist!
Gruß gznw
Bin etwas müde, was ich so tagsüber mache ist in den letzten Wochen auch
nicht gerade ohne :)
Aber ich denke, jetzt sollte man das decodieren mal irgendwie
automatisieren. Eventuell ein kleines einfaches Progrämmelchen auf dem
Pc schreiben mit irgend einem einfachen Compiler.
Zeile einlesen, entschlüsseln und sehen was passiert. Das ist einfacher,
als es jedes mal erst flashen zu müssen.
Ich schau mal, was ich da auf die Schnelle machen kann. Unter Linux hab
ich schon mal was angefangen, ist aber noch nicht fertig und wird heute
auch nix mehr. Wenn Du nur Windows hast, dann einfach MingW oder
ähnliches installieren und den Quelltext durch jagen, sobald ich ihn Dir
schicke.
Gruß, Ulrich
Hi.. Also Linux wäre mir natürlich lieber... Ich hab hier 2 Nslu2,falls
du die kleinen Dinger kennst. Dazu noch eine Etrayz. Alle laufen mit
Linux und sind hier im Netzwerk verbunden. Ich könnte ja den Controller
direkt an die nslu anschließen und die befasst sich dann mit den Daten.
Ich könnte sonst noch einen alten Laptop nutzen,aber auf Dauer zieht der
ja schon etwas viel Strom..
Hallo Ihr Zwei, merke gerade, es ist schon fast zwei Jahre her... na
egal. Habe selbst einen solchen Thermo-Hygro-Sensor am Start. Ich habe
euren Thread interessiert gelesen. Gute Arbeit!
Meine bescheidene Frage an Euch, wo habe ich überlesen, warum Ihr den
Biphase-Mark-Code invertiert betrachtet. Oder steh ich schon
grundsätzlich im Verständnis des Codes auf der Leitung?
Viele Grüße und ein frohes Weihnachtsfest...
Daniel
Hallo,
ich weiß es jetzt auch gar nicht mehr so genau, aber das war eben der
Ansatz, den wir an der Stelle hatten. Es ist bis jetzt ja leider auch
nicht aufgelöst worden. Ich habe mich dann aber auch nicht mehr
großartig damit befasst. Vielleicht kümmer ich mich darum nochmal, wenn
ich demnächst etwas mehr Zeit habe, aber so einfach wird es ja leider
nicht sein. Wenn Du neue Ansätze oder Ideen hast, sag unbedingt mal
Bescheid!
gznw
Also ich habe mich um die geschichte aus zeitlichen gründen nicht mehr
kümmern können. Abgesehen davon, dass ich hier nur theoretisch mit
gemacht habe, weil ich solch ein Gerät garnicht besitze, ich hätte es
auch nicht geschafft, wenn ich eines hätte.
Aber wenn Ihr da weiter macht, dann schau ich einfach mal wieder vorbei.
Gruß
Ulrich
Also ich wäre auch wieder dabei. ;-)
Ich würde diesmal einen anderen Ansatz verfolgen wollen: die Sensorwerte
vorgeben und gucken was hinten rauskommt. Dafür müsste man den internen
Sensor wohl mal untersuchen. Bin leider diese Woche noch unterwegs, aber
ich schau mal. ich hatte die Bezeichnung hier bestimmt schon erwähnt und
tipp mal auf I2C-Schnittstelle.
gznw
Da hab ich ja die Threadväter wieder an den Tisch geholt :)
Also ich hab mal noch ein wenig mit der CRC-Geschichte getestet und bin
auch nicht weiter gekommen. Wenn es das ist, dann ist es eh nur Lotto
spielen. Ich glaub aber nicht mehr das es so kompliziert ist. Wir haben
ja schon die Sicherheiten des 3-maligen Sendens und der Parity-Bits. Vom
Prinzip her reichen mir auch die anderen Daten, da ich den Sensor für
meine eigene Wetterstation nutzen und nicht Daten zu einer bestehenden
Station senden will. Aber interessieren tut's mich natürlich schon, was
die letzten beiden Bytes nun genau sind. In Ulrich hatte ich da meine
Hoffnung gesetzt, dass er da zwischen den 1sen und Nullen das
CRC-Polynom entdeckt :)
Was mir aufgefallen war ist, dass der Bi-Phase-Mark-Code invertiert ist,
also das was Signalmäßig ne Eins sein sollte ist ne Null und umgekehrt.
Vielleicht hab ich aber auch bei grundlegenden Verständnis schon ein
Dreher... aber auch nebensächlich.
Zum Innenleben: Also die Sensorik ist einfachste Elektronik ->
Temperatur = temperaturabhängiger Widerstand und Luftfeuchte ein
billiger Flächenkondensator mit Spule(Schwingkreis). Erfasst wird das
ganze wohl vom allseits geliebten Klecks welcher dann auch die Signale
zum Senden herstellt. Also nix i2c.
Mir ist auch nicht so richtig klar, was vorgegebene Sensorwerte bringen
sollen, es geht ja immer noch um die ominöse Checksumme oder?
Grüße Daniel
Hallo,
ich habe hier mehrere dieser Sensor-Module und es gibt scheinbar zwei
verschiedene Varianten:
Eine verwendet die von Dir beschriebenen Sensoren und es gibt die
Module, die einen Sensor verbaut haben, der scheinbar per
I2C-Schnittstelle angebunden sind. Das habe ich vor ein paar Tagen
festgestellt, nachdem ich mir nochmal diesen Sensor anschauen wollte.
Meine Überlegung war, dass man gezielt einzelne Bits verändert und
darüber dann die Entschlüsselung herausbekommen kann, da man eben
einzelne Bits veränden kann und sich die Checksumme dann anschauen kann.
Im primitivsten Fall kann man dann ne Lookup-Tabelle machen, aber das
ist irgendwie nicht so hübsch.
Apropos.. Eine Verschlüsselung, die per Lookup-Tabelle funktioniert,
wäre eine, die wir hier nie entschlüsseln könnten, wenn man nicht alle
möglichen Kombinationen austesten würde! Aber ich glaube eher nicht,
dass das so implementiert wurde.
gznw
Thread beobachten
Seitenaufteilung abschalten