LÖSUNG:Dekodieren Temperatur Feuchte T/H sensor von PEARL NC7427(NC7415) 433MHz

Begonnen von maxtox, 25 September 2016, 19:37:33

Vorheriges Thema - Nächstes Thema

FHEm2005

Hallo Jürgen,

so geht es auch nicht.
Mein Beispiel:
Datentelegramm: 19C6CDA08040
Enthaltene Nibble-Werte: ( 6+7+1+11+3+6+8+2) & F = 44 &F= 0010 1100 &F = C .  Soll war leider "1".  Ergo => So nicht!  :(

2. Versuch mit 2er Gruppen: geht aus nicht.  >:(
3. Versuch mit negierten Nibbel-Werten: (9+8+14+4+12+9+7+13) & F = 76 & F = 0100 1100 &F = C . So auch nicht  :'(


Ich werde Weiters versuchen und hier notfalls ergänzen.

Gruß Eberhard

Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM

JoWiemann

Ich habe das hier gefunden: http://forum.iobroker.net/viewtopic.php?t=3818

HIER DIE LÖSUNG!

z.B.: 782°F 75%

00 10101000 0 1 10 0010 1001 0110 1011 0100 00010000
aa I______I B B KK TTTT TTTT TTTT HHHH HHHH chksum

aa= Präạmbel
I_I = Sensor ID, ändert sich jedes Mal, wenn man die Batterie wechselt (Stromlos macht)
B = Trend für Temperatur/ Humidity (00=bei dem ersten Wert nach dem Batt. wechsel)
KK= Kanal 1=00, 2=01, 3=10
TTTT=Binär in Dez., Dez als HEX, HEX in Dez umwandeln (z.B. 0010=2Dez, 2Dez=2 Hex) 0010=2 1001=9 0110=6 => 692HEX = 1682Dez = >1+6=7 UND 82 = 782°F
HH=(wie oben)Binär in Dez., Dez als HEX, HEX in Dez umwandeln (z.B. 1011=11Dez, Dez=B Hex / 0100=4Dez=4HEX => (von hinten lesen)4BHEX (von hinten lesen)=75 Dez.)
chksum= Prüfsumme

das war's !!!
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

FHEm2005

Hallo JoWiemann,

hast Du mal 732°F in Celsius umgerechnet? Das sind schlappe 388,9° in Celsius.  ;) Nehmen wir mal an, es wären 73,2°F dann liegen wir bei 23,9 ziemlich gut!

Das B ist und bleibt m.E. ein Batteriestatus. Der wechselt nämlich nicht, egal welche Historie die Temperaturen hinter sich haben.

Die Decodierung ist ja schon abgeschlossen. Dass unsere momentane Interpretation stimmt, kann ich bei mir am Schreibtisch ablesen, das stehen zwei Thermometer/Feuchtigkeitsmesser dieses Types rum. Wir hängen momentan "nur" noch noch an der Prüfsumme.  Hast Du da weitere Informationen und Tipps bzgl der Prüfsumme?

Gruß
Eberhard
Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM

juergs

Hallo,

ich glaube wir müssen wieder "back to the roots":

boolean crcValid(unsigned long value, byte checksum)
// check if received crc is correct for received value
{
  byte calculatedChecksum = 0;
  for (int i = 0 ; i < 8 ; i++)
  {
        calculatedChecksum +=(byte)(value >> (i*4));
  }

  calculatedChecksum &= 0xF;

  return calculatedChecksum == checksum;
}


laut hier wird nur das Ergebnis mit 0x0F ge-AND-det.
Dann kommt es nur auf die Bitwerte an, ob nibble gedreht oder nicht gedreht sind
oder nur auf die Rohdaten ...

Zitatif (bitsCounted>=KW9010_MESSAGELEN) // all bits received
    {
      if (crcValid(rxBits,crcBits)) fifoWrite(rxBits); // write valid value to FIFO buffer
      else fifoWrite(0);  // write 0 to FIFO buffer (0 = invalid value received)
      rxBits=0;
      crcBits=0;
      bitsCounted=0;
    }

static unsigned long rxBits=0;

ist also ein LONG mit 4 Bytes! Nachdem das volle Telegramm eingelesen wurde.

Hier werden die "1" Bits gesetzt und je nach Position in Daten und CRC getrennt:

Zitatelse if (LowVal>KW9010_ONE-KW9010_GLITCH && LowVal<KW9010_ONE+KW9010_GLITCH)
    { // set the one bits
      if (bitsCounted<32)
        bitSet(rxBits,bitsCounted);
      else 
        bitSet(crcBits,bitsCounted-32);
      bitsCounted++;
    }

D.h. der CRC wir nur über die Rohdaten gebildet, also ohne Nibble-Tauschen.

Zitat
_________8__2__2___4____4___4_______8   = 32 Bit = LONG
__ 12345678 9 0 12 3456 7890 1234 5678 9012
12 34567890 1 2 34 5678 9012 3456 7890 1234 56789012
00 10101000 0 1 10 0010 1001 0110 1011 0100 00010000
aa I______I B B KK TTTT TTTT TTTT HHHH HHHH chksum
Prämbel bliebe mal außen vor, da sowieso immer 0.
Also wird gebildet:
(ID + Bat mit Kan (nibble oder einzeln? eher nibble) + temp + hum) AND 0xF = CRC

Probiere ich morgen noch aus ...

Grüße,
Jürgen



FHEm2005

Hallo Jürgen,
habe  (ID + Bat mit Kan (nibble oder einzeln? eher nibble) + temp + hum) AND 0xF = CRC mal in beiden Versionen getestet.

Telegramm: 1C23B96C8300, CRC:12,
Art: Bat und Kanal getrennt(einzeln),
CRC (dez): 4105,
CRC(binär):1 0000 0011 0110,
ge-UND-et: 0110
CRC (ist): 6 

Telegramm: 1C23B96C8300, CRC:12,
Art: Bat und Kanal gemeinsam (nibble),
CRC (dez): 4111,
CRC(binär):1000000001111,
ge-UND-et: 1111
CRC (ist): 15 

So geht es auch nicht! :( :(

Gruß Eberhard
Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM

FHEm2005

weitere Versuche mit:

- (Bat mit Kan (nibble) + temp + hum) AND 0xF = CRC   Ergebnis: CRC(ist) = 15
- (temp + hum) AND 0xF = CRC   Ergebnis:  CRC(ist) = 7

waren erfolglos.

Gruß Eberhard
Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM

juergs

Hallo Eberhard,

Zitat
2017-02-05 10:20:42 CUL_TCM97001 Unknown Code: 31080DA0B140
2017-02-05 10:21:34 CUL_TCM97001 Unknown Code: 31090DA481C0
2017-02-05 10:23:25 CUL_TCM97001 Unknown Code: 310ACDA08180

HEX: 31080DA0B140
00000000010000000002000000000300000000040000000005
12345678901234567890123456789012345678901234567890
1100010000100000001101101000001011000101000000


HEX: 31090DA481C0
00000000010000000002000000000300000000040000000005
12345678901234567890123456789012345678901234567890
1100010000100100001101101001001000000111000000

HEX: 310ACDA08180
00000000010000000002000000000300000000040000000005
12345678901234567890123456789012345678901234567890
1100010000101011001101101000001000000110000000


Zum Vergleich mit Rohdaten:
 
Zitat

[1]:
------------------------------------------------------------
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
0 0 1 0 1 1 1 1 1 1 0 0 0 1 0 1 0 0 0 1 0 0 0 1 1 0 0 0 1 0 0 0 1 0 0 0 0 0 1 1 0 0
---------------------------------------------------------------------------------------
LD: 00 |ID: 10111111 |BAT: 00 |CH: 01 |TEMP: 010001000110 |HUM: 00100010 |CRC: 00001100
---------------------------------------------------------------------------------------
[ 2] ID:          1 - 1   
[ 3] ID:          1 - 0   
[ 4] ID:          3 - 1   
[ 5] ID:          7 - 1   
[ 6] ID:         15 - 1   
[ 7] ID:         31 - 1   
[ 8] ID:         63 - 1   
[ 9] ID:        127 - 1   
------------------------------------------------------------
ld:   0
id:   127
bat:   0
ch:   2
temp:   785
hum:   34
crc:   34
Raw:   1739006387398115328

Ein paar empfangene Sensordaten.

Im Moment sehe ich nur, dass der von FHEM gelieferte HEX-Wert nicht zum 42Bit-Protokoll passt.
Hinten hängen ein paar "0" zuviel dran ...


juergs

Nehmen wir das als Beispiel:

ZitatHEX: 310ACDA08180
00000000010000000002000000000300000000040000000005
12345678901234567890123456789012345678901234567890
1100010000101011001101101000001000000110000000

und fügen erst mal die Leads hinzu:
123456789012345678901234567890123456789012 > 42 entfällt.
001100010000101011001101101000001000000110 000000

bleibt als Rohdaten:
001100010000101011001101101000001000000110

aufgedröselt:
LL_ID______BB_CC__TEMP______HUM_____CRC
00 11000100 00 10 101100110110 10000010 00000110
ID___ 0xC4=196
CH______________2
TEMP________________ 1011.0011.0110 = 2870 oder 0x0B =11 | 0x03 | 0x06
HUM_____________________________10000010 = 0x82 = 130
______________________________________00000110 = 0x6



1. 196+2+11+3+6+130 == 6?  => 344   AND 0x0F = 8
2. 196+2+2870+130      == 6?   => 3198 AND 0x0F = 14


Muß dazu sagen, dass bei mir in der Gegend große Sensor-Betriebsamkeit herrscht ...
D.h. es könnten auch "falsche" Protokolle sein, die in die CUL-Erfassung rutschen.

Denkfehler (?) und weiter knobeln ... :o

/edit: Hmmmm, ließe man den Kanal weg:  342 & 0x0F = 6 (!?)

Grüße,
Jürgen


juergs

Nach einem FHEM-Update kommen jetzt wieder die Repetitions durch  :)

Zitat
2017-02-05 11:12:52 CUL_TCM97001 Unknown Code: 28439D988000
2017-02-05 11:12:52 CUL_TCM97001 Unknown Code: 28439D988000
2017-02-05 11:12:52 CUL_TCM97001 Unknown Code: 28439D988000
2017-02-05 11:12:52 CUL_TCM97001 Unknown Code: 28439D988000
2017-02-05 11:12:52 CUL_TCM97001 Unknown Code: 28439D988000
2017-02-05 11:12:53 CUL_TCM97001 Unknown Code: 310A11A084C0
2017-02-05 11:12:53 CUL_TCM97001 Unknown Code: 310A11A084C0
2017-02-05 11:12:53 CUL_TCM97001 Unknown Code: 310A11A084C0
2017-02-05 11:12:53 CUL_TCM97001 Unknown Code: 310A11A084C0
2017-02-05 11:12:54 CUL_TCM97001 Unknown Code: 310A11A084C0

Gegencheck:

2017-02-05 11:12:52 CUL_TCM97001 Unknown Code: 28439D988000

HEX: 28439D988000
BIN: 1010000100001110011101100110001000000000000000

00000000010000000002000000000300000000040000000005
12345678901234567890123456789012345678901234567890
001010000100001110011101100110001000000000000000
00.10100001.00.00.111001110110.01100010.00000000
ID: 10100001 = 0xA1 = 161
BAT: 0
CH:  0
TEMP: 111001110110  = 0xE76  = 3702
HUM:  0110001  = 0x31 = 49
CRC:  00000000   = 0
161+3702+49 = 3912 & 0x0F = 8 NO!





2017-02-05 11:12:53 CUL_TCM97001 Unknown Code: 310A11A084C0

HEX: 310A11A084C0
BIN: 1100010000101000010001101000001000010011000000

00000000010000000002000000000300000000040000000005
12345678901234567890123456789012345678901234567890
001100010000101000010001101000001000010011000000
1100010000101000010001101000001000010011000000

00.11000100.00.10.100001000110.10000010.00010011

ID:  0xC4 = 196
BAT: 0 = 0
CH:  10 = 2
TEMP: 0x846 = 2118
HUM:  0x82 = 130
CRC:  0x13      = 19

196+2+2118+130 = 2446 & 0x0F = 14
196+2118+130   = 2444 & 0x0F = 12


Dicht daneben ist auch vorbei ...

Am besten noch mal mit empfangen Rohdaten (also ohne FHEM) checken...

Werde auch nochmal versuchen nur den Kanal zu ändern, das sind ja 3 Werte die sich nur in einer Stelle ändern.
Vielleicht zeigt dann die Veränderung des CRCs ein Hinweis....

FHEm2005

Hallo Jürgen,

ich weiß zwar nicht ob sich etwas an Deiner Berechnung ändert, aber:
ZitatID:  0xC4       = 196
BAT: 0         = 0
CH:  10         = 2
CH:10 ist zwar 2d aber der Kanal 3! Nicht, dass das irgendwo falsch aufgefasst wird.

Ich habe bemerkt, dass die beiden ersten Bits im CRC ein Trailer für die CRC sein könnten, sie sind bei mir immer "00". Ich versuche mal dafür ein binäres Logging  aufzusetzen. Vielleicht sind die letzten sechs Bits auch immer "00 00 00" ? Ich habe darin bisher noch keine "1" gesehen. mal sehen was das Log bis heute abend zeigt.

Gruß Eberhard
Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM

juergs

ZitatCH:10 ist zwar 2d aber der Kanal 3! Nicht, dass das irgendwo falsch aufgefasst wird.
Ja, korrekt. Hatte zwar auch schon mal das Batterie-Flag gesetzt gesehen, aber im Gut-Zustand auch "00".

Zum Beispiel ist:

28439D988000 = 001010000100001110011101100110001000000000000000
A10E766200     = __1010000100001110011101100110001000000000

Da ja ein AND mit 0x0F gemacht wird, bleiben 4 Bits des CRCs eigentlich immer 0 (?)

Wie wichtig der CRC ist, zeigt mal ein Mitschnitt:

Zitat
*** go! **
/001100010000100111001001100111001000001100*/ID: 196 / 1830
/001100010000100111001001100111001000001100*/ID: 196 / 1830
/001100010000100111001001100111001000001100*/ID: 196 / 1830
/001100010000100111001001100111001000001100*/ID: 196 / 1830
/001100010000100111001001100111001000001100*/ID: 196 / 1830
/001100010000100111001001110111001000001100*/ID: 196 / 1831
/000000000000000000000000000000000000000000*/ID: 0 / 0
/110000000000000000000000000000000000000000*/ID: 0 / 0
/100000000000000000000000000000000000000000*/ID: 0 / 0
/001111011111110011100000000000100000000000*/ID: 247 / 896
/111100010000000000000000000000000000000000*/ID: 196 / 0
/000000000000000000000000000000000000000001*/ID: 0 / 0
/100000000000000000000000000000000000000000*/ID: 0 / 0
/001010000100000111001001101000001000001010*/ID: 161 / 1830
/001010000100000111001001101000001000001010*/ID: 161 / 1830
/001010000100000111001001101000001000001010*/ID: 161 / 1830
/001010000100000111001001101000001000001010*/ID: 161 / 1830
/001010000100000111001001101000001000001010*/ID: 161 / 1830
/001010000100000111001001101000001000001110*/ID: 161 / 1830
/101100000000000000000000000000000000000000*/ID: 192 / 0
/000000000000000000000000000000000000000000*/ID: 0 / 0
/110000000000000000000000000000000000000000*/ID: 0 / 0
/001100010000101000001001100111001000001000*/ID: 196 / 2086
/001100010000101000001001100111001000001000*/ID: 196 / 2086
/001100010000101000001001100111001000001000*/ID: 196 / 2086
/001100010000101000001001100111001000001000*/ID: 196 / 2086
/001100010000101000001001100111001000001000*/ID: 196 / 2086
/000000000000000000000000000000000000000000*/ID: 0 / 0

Die ungültigen Protokolle müssen verworfen werden.
Die Sensoren senden 6 Repetitions, manchmal wird einer überlagert ...

Ohne CRC-Prüfung kommt zu viel Spam durch.

FHEm2005

Hallo Jürgen,

Ich habe jetzt endlich das Logging aufsetzen können. Mal sehen was morgen "im Kasten" ist. Ich lasse es mal die Nacht über laufen.
ZitatIch habe bemerkt, dass die beiden ersten Bits im CRC ein Trailer für die CRC sein könnten, sie sind bei mir immer "00".
Nach den bisherigen Aufzeichnungen scheint das der Fall zu sein.
2017-02-05_18:27:34 Unknown2 Logfile: ID: 103, CRC(d): 34, CRC(b): 00|1000100|00000
2017-02-05_18:27:34 Unknown2 Logfile: ID: 103, CRC(d): 34, CRC(b): 00|1000100|00000
2017-02-05_18:27:34 Unknown2 Logfile: ID: 103, CRC(d): 34, CRC(b): 00|1000100|00000
2017-02-05_18:28:22 Unknown2 Logfile: ID: 185, CRC(d): 38, CRC(b): 00|1001100|00000
2017-02-05_18:28:22 Unknown2 Logfile: ID: 185, CRC(d): 38, CRC(b): 00|1001100|00000
2017-02-05_18:28:22 Unknown2 Logfile: ID: 185, CRC(d): 38, CRC(b): 00|1001100|00000
2017-02-05_18:28:22 Unknown2 Logfile: ID: 185, CRC(d): 38, CRC(b): 00|1001100|00000
2017-02-05_18:28:23 Unknown2 Logfile: ID: 185, CRC(d): 38, CRC(b): 00|1001100|00000
2017-02-05_18:28:27 Unknown2 Logfile: ID: 103, CRC(d): 38, CRC(b): 00|1001100|00000
2017-02-05_18:28:27 Unknown2 Logfile: ID: 103, CRC(d): 38, CRC(b): 00|1001100|00000
2017-02-05_18:28:27 Unknown2 Logfile: ID: 103, CRC(d): 38, CRC(b): 00|1001100|00000
2017-02-05_18:28:27 Unknown2 Logfile: ID: 103, CRC(d): 38, CRC(b): 00|1001100|00000
2017-02-05_18:28:27 Unknown2 Logfile: ID: 103, CRC(d): 38, CRC(b): 00|1001100|00000


Auch scheinen die letzten 7 Bit einen dauerhaften Zustand "0" zu haben. Mal abwarten bis morgen. Der CRC(d) ist der berechnete Wert nach bisheriger Lesart - in Bit 34 bis Bit 41 ist die CRC enthalten. In CRC(b) sind die 14 Bits des CRC. Die "|" sind nur zur Orientierung gedacht.

Gruß Eberhard
Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM

FHEm2005

Hallo Jürgen,

ich habe in der letzten Nacht, ca. 10.000 Messwerte von zwei Sensoren erhalten. Ich spare mir diese komplett als Anlage anzuhägen. Alle Werte sehen im Prinzip  so aus:

2017-02-05_21:17:10 Unknown2 Logfile: ID: 103, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:17:10 Unknown2 Logfile: ID: 103, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:17:10 Unknown2 Logfile: ID: 103, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:17:10 Unknown2 Logfile: ID: 103, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:17:11 Unknown2 Logfile: ID: 103, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:17:32 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:17:32 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:17:33 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:17:33 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:17:33 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:18:03 Unknown2 Logfile: ID: 103, CRC(d): 8, CRC(b): 00|001000|000000
2017-02-05_21:18:03 Unknown2 Logfile: ID: 103, CRC(d): 8, CRC(b): 00|001000|000000
2017-02-05_21:18:03 Unknown2 Logfile: ID: 103, CRC(d): 8, CRC(b): 00|001000|000000
2017-02-05_21:18:03 Unknown2 Logfile: ID: 103, CRC(d): 8, CRC(b): 00|001000|000000
2017-02-05_21:18:04 Unknown2 Logfile: ID: 103, CRC(d): 8, CRC(b): 00|001000|000000
2017-02-05_21:18:22 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:18:22 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:18:23 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:18:23 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000
2017-02-05_21:18:23 Unknown2 Logfile: ID: 185, CRC(d): 2, CRC(b): 00|000010|000000


Die Telegramme werden jeweils 5x gesendet. Der Bereich der Prüfsumme reichte von 0d - 47d ( = 0x000000 - 0x101111). Werte über 47d gibt es nicht. Bei beiden Geräten (103 und 185) wurde der komplette Bereich ( 0d - 47d) gefunden

Bisher sind wir davon ausgegangen, dass in 8Bits der CRC-Wert steckt. In Wirklichkeit sind es nur sechs.

Entgegen meiner Vermutung von gestern werden die letzten sechs (nicht fünf) Bits immer auf "0" gesetzt.Leider ändern sich damit nicht die bisherigen CRC-Werte, weil die beiden ersten Bits ohnehin nur "00" sind.
Bisher: CCCCCCCCTTTTTT, jetzt: TTCCCCCCTTTTTT (T = konstante Bits, C=zum CRC-Check gehörend).

Damit sind wir nicht wirklich weiter. Schade.

Gruß Eberhard


Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM

juergs

Hallo Eberhard,

wieder mal ein Beispiel dafür, das man nicht alles per Copy&Paste übernehmen kann.

Zitat... wie schon gesagt, die CRC Funktion oben passt nicht zum Pearl Sensor.
https://forum.arduino.cc/index.php?topic=425908.15
Dort ist das Problem ebenfalls bekannt... (;-)

Dann bin ich auf die Suche gegangen:

ZitatThe CRC mechanisms being used can be reverse engineered using CRC RevEng by just feeding the tool with some recorded samples.
https://fetzerch.github.io/2014/11/15/reveng433/
Ein Tool?

CRC-Explained:
https://barrgroup.com/Embedded-Systems/How-To/CRC-Calculation-C-Code
https://barrgroup.com/Embedded-Systems/How-To/CRC-Math-Theory
https://barrgroup.com/Embedded-Systems/How-To/Additive-Checksums

CRC8/Maxxim reversed
https://github.com/UlrikHjort/CRC8
https://github.com/zhoulihe/crc8/blob/master/CRC8-16-32-64/CRC16-32-64/crc8.cpp

Helpers
https://github.com/fetzerch/atMETEO/blob/master/lib/utils.h

Repeater
http://www.thice.nl/convert-cheap-433mhz-sensors-to-kakucoco-with-an-arduino-convertor/

Analyzer
http://wiki.nethome.nu/doku.php/analyzer/start
http://zorc.breitbandkatze.de/crctester.c

https://www.mikrocontroller.net/topic/211884
http://zorc.breitbandkatze.de/crc.html mit Links zu weiteren CRCs.

Zitat..Kopfzerbrechen bereitet mir noch die Prüfsumme, in die definitiv
die Telegramm-Nummer (0..2 oder 1..3) eingeht:
http://www.fernando-heitor.de/index.php?topic=3699.0

Allgemein, interessante Seite mit "Wireless Automation Analyzer":
http://scheidig.de/Deutsch/scheidig_start_WirelessAutomation.htm


Last but not least:
https://fetzerch.github.io/2014/11/15/reveng433/
https://sourceforge.net/projects/reveng/
Details in der Readme-Datei.

reveng.exe -h | clip
CRC RevEng: arbitrary-precision CRC calculator and algorithm finder
Usage:  reveng.exe      -cdDesvhu? [-bBfFlLMrStVXyz]
                [-a BITS] [-A OBITS] [-i INIT] [-k KPOLY] [-m MODEL]
                [-p POLY] [-P RPOLY] [-q QPOLY] [-w WIDTH] [-x XOROUT]
                [STRING...]
Options:
        -a BITS         bits per character (1 to 32)
        -A OBITS        bits per output character (1 to 32)
        -i INIT         initial register value
        -k KPOLY        generator in Koopman notation (implies WIDTH)
        -m MODEL        preset CRC algorithm
        -p POLY         generator or search range start polynomial
        -P RPOLY        reversed generator polynomial (implies WIDTH)
        -q QPOLY        search range end polynomial
        -w WIDTH        register size, in bits
        -x XOROUT       final register XOR value
Modifier switches:
        -b big-endian CRC               -B big-endian CRC output
        -f read files named in STRINGs  -F find presets less quickly
        -l little-endian CRC            -L little-endian CRC output
        -M non-augmenting algorithm     -r right-justified output
        -S print spaces between chars   -t left-justified output
        -V reverse algorithm only       -X print uppercase hex
        -y low bytes first in files     -z raw binary STRINGs
Mode switches:
        -c calculate CRCs               -d dump algorithm parameters
        -D list preset algorithms       -e echo (and reformat) input
        -s search for algorithm         -v calculate reversed CRCs
        -h | -u | -? show this help


Genügend Stoff ....  ;)


juergs

'This code provided by Weber from osngr.net
crc2calc:
'BASIC code to compute a CCITT-8 CRC checksum for a nibble-based message

crc = 0
crc = crcnibble(crc, sensorid1)
crc = crcnibble(crc, sensorid2)
crc = crcnibble(crc, sensorid3)
crc = crcnibble(crc, sensorid4)
crc = crcnibble(crc, channel)
crc = crcnibble(crc, rollingcode1)
crc = crcnibble(crc, rollingcode2)
crc = crcnibble(crc, battflag)
crc = crcnibble(crc, temp1)
crc = crcnibble(crc, temp2)
crc = crcnibble(crc, temp3)
crc = crcnibble(crc, tempsign)
crc = crcnibble(crc, humidity1)
crc = crcnibble(crc, humidity2)
crc = crcnibble(crc, unknown)

'at the end, need to run 8 zero bits through to finish the calculation

crc = crcnibble(crc, 0)
crc = crcnibble(crc, 0)

crcnib1 = crc And 15
crcnib2 = ShiftRight(crc, 4)

'now, "encode" these two nibbles after your crc1, crc2 checksum nibbles

Return                                           

'this function adds one more nibble to the crc calculation

Function crcnibble(crc As Byte, nibble As Byte) As Byte
For bitno = 0 To 3
If crc.7 = 1 Then  'does this return "1" or "8" ? might need "if crc.7 = 8" instead...
'note: I assume that nibble.3 returns either "0" or "1"
'if it returns "0" or "8" instead then this code is not correct
'and you would need another IF statement here to OR a "1" into
'the left - shifted crc If Bit 3 of nibble is a one
crc = ShiftLeft(crc, 1)
If nibble.3 = 1 Then crc = crc Or 1
If nibble.3 = 0 Then crc = crc Or 0
crc = crc Xor crcpoly
Else
'same comment as above -- depending on what "nibble.3" returns
crc = ShiftLeft(crc, 1)
If nibble.3 = 1 Then crc = crc Or 1
If nibble.3 = 0 Then crc = crc Or 0
Endif
nibble = ShiftLeft(nibble, 1)
Next bitno
crcnibble = crc
End Function   
                                   
calc_crc1:  'Calculate the first crc, simply the modulo8 sum of all the data variables.
crc1calc = sensorid1 + sensorid2 + sensorid3 + sensorid4 + channel + rollingcode1 + rollingcode2 + battflag
crc1calc = crc1calc + temp1 + temp2 + temp3 + tempsign + humidity1 + humidity2 + unknown
crc1nib1 = crc1calc And 15  'Convert single byte into 2 nibbles.
crc1nib2 = ShiftRight(crc1calc, 4)
Return