433MHz sniffer

  • DIe Hauptroutine (main()) macht eigentlich nichts weiter als die Zeiten zwischen Pegelwechsel zu messen.

    Bei einem langen 1-Puls (>9000 Mikrosekunden kein Signal) wird synchronisiert. Wenn mehr als 10 Pegelwechsel (tcount) erkannt worden waren, dann wird das Timingmuster ausgegeben und decodiert. Glitches bzw.Prellen, oder auch Pulse kürzer als 5 Mikrosekunden werden ignoriert.


    Wenn also irgendwas sinnvolles erkannt wird, wird die Routine printout() aufgerufen. Ansonsten weiter empfangen.


    Printout analysiert dann nochmal die Zeiten zwischen den Pegelwechseln und versucht daraus zu erraten, welches Protokoll verwendet wurde, bzw. welche Protokoll-Klasse:

    timing[0] ist dabei die Länge des Sync-Pulses, den die meisten Sender als Beginn einer Nachricht senden. Hier konnte ich mal 4 verschiedene typische Längen ermitteln, je nach Sender. Aber da kann es natürlich noch mehr geben.Je nach Pulslänge wird dann die variable protocol gesetzt. und mint ist dabei glaube ich die Clock für das Protokoll, also das Raster in dem die Bits abgetastet werden. (in Mikrosekunden).

    Dann gibt es verschiedene Dekodsierungsmethoden: Länge der 1-Pegel, wobei jedes Bit mit einem 0->1 Wechsel anfängt, oder Wert in einem starren Raster, oder Manchester-decodierung (siehe Wikipedia). Mehr hatte ich glaube ich noch nicht implementiert.

  • Moin wend,

    Ja, das hatte ich mir nun gedacht mit dem mint. das scheint in der Tat die Pegellänge zu sein. Bei meinem Temperatursensor also ca 560 µs und bei meiner Fernbedienung 300 µs.

    Damit kann man ja schon gut was anfangen.

    Danke erstmal vielmals.

  • Moin moin,

    Dank der super Vorarbeit von wend hat es natürlich geklappt. Mit diesem programm könnt Ihr den 433Mhz Temperatur Sensor von Pearl NC7159 auch bekannt unter dem Namen Alecto WSD17 auslesen. Es gibt die Temperatur und und Luftfeuchte aus.

    Zusätzlich ließt er auch die Standard ELRO Funkfernbedienungen, die mit dem DIP Switch aus und gibt deren Wert zurück.

    Wenn es ein Funksignal nicht erkennt, aber ein ähnliches Timing hat wie entweder der Sender oder die Remotes, dann wird die Bitfolge ausgegeben.


    Die komplette Codierung von wend ist hier nicht enthalten. Das ist mit Absicht ein sehr schmales Programm. Hoffe, dass das irgendwer auch benötigt und danke nochmal an wend.

    ich hab das ganze einfach mal tsniffer genannt.

    Grüße fsg4u


    ps: das ganze läuft getestet auf einem Pi3 mit Rasbian stretch lite.


    Hier noch ein paar install hinweise:

    1.bcm2835-1.50 herunterladen und entpacken

    Code
    cd bcm2835-1.50
    sudo ./configure
    sudo make
    sudo make check
    sudo make install

    2.tsniffer herunterladen und entpacken

    Code
    cd tsniffer
    make
    sudo ./gpio_read

    Files

    • tsniffer.tar

      (8.19 kB, downloaded 209 times, last: )
  • Hallo fsg4u,

    ich habe versucht dein geändertes Skript von wend zum sniffen zu nutzen. Leider funktioniert es nicht (es kommt nichts an).


    Ich habe 3 Pins versucht:

    1. den GPIO27 mit #define PIN 27 /* GPIO 27 */ ;

    2. den #define PIN 18 /* GPIO 18 */ und

    3. den #define PIN 13 /* GPIO 13*/

    Jedes mal nach dem Ändern habe ich mit make neu kompiliert und bekomme folgende Fehlermeldungen:


    root@raspberrypi:/usr/bin/Programme_sascha# cd TSniffer

    root@raspberrypi:/usr/bin/Programme_sascha/TSniffer# make

    make: Warnung: Datei „gpio_read.c“ hat hat in der Zukunft liegende Änderungszeit 3537

    gcc -o gpio_read gpio_read.c timer.c -lbcm2835

    make: Warnung: Mit der Uhr stimmt etwas nicht.

    Der Bauauftrag könnte unvollständig sein.

    root@raspberrypi:/usr/bin/Programme_sascha/TSniffer# sudo ./gpio_read


    Meine Frage:

    Verstehe ich das mit dem Pin-definiere so richtig, dass direkt die GPIO-Nummern eingetragen werden oder müssen die Nummern der Hardwarebelegungen eingetragen werden (z.B. GPIO18-->define PIN 12)? Warum bekomme ich die Fehlermeldung mit der Änderungszeit? Hat das damit zu tun, dass ich garnichts empfange?


    Hardware:

    - Raspberry pi3

    - LowCost Empfänger (plus Sendemodul)

    - Temperaturstation - sendet auf 433MHz

    - 433MhZ Funktsteckdosenfernbedienung und Steckdose



  • Hallo zusammen.

    Danke, dass es Menschen wie Euch gibt, die Laien bzw. Anfänger mit solchen Hilfen unterstützen!!!! 😁

    Da ich mich bisher noch nicht in Foren bewegt habe, bitte ich meine evt. Fehler zu entschuldigen.


    Bei folgenden Projekt, bräuchte ich auch Eure Unterstützung!

    Ich habe ein Funkklingel (QUIGG MD 16179) für den Garten und einen me-Funk-Converter BELL 212 TX, der mit einem Rufanschaltrelais an der Hausklingel angeschlossen ist.

    Mein Wunsch ist es, dass wenn es klingelt, ich (z. b. über FHEM oder per Telegramm, o. ä) eine Meldung auf mein Handy bekomme. Diese Meldung sollte einen Zeitstempel haben und mir anzeigen, welche Klingel betätigt wurde.


    Dabei möchte ich gerne auf ein eigenes schlankes Tool zurück greifen, statt z. B. auf Pilight.

    Ich habe bereits viele Seiten gelesen. Über Funkklingel auslesen bin ich hier gelandet und denke, dass das der richtige Ansatz für mich ist.


    Ich habe wends unsniffer installiert und konnte die QUIGG-Funkklingel auslesen. 😃👍🏼


    Jetzt verstehe ich noch nicht, wie ich die Ergebnisse umsetzte.

    Wenn ich es richtig sehe, benötige ich:

    • einen sniffer, der den Code beider Klingeln empfängt
    • einen „Übersetzter“ ????, um "nur" noch das Bitmuster zu entschluesseln 😉
    • eine Datei, in der geschrieben wird, welche Klingel wann klingelt
    • eine klingel.py, die diese Information an mich schickt

    Ist der Gedanke schon mal richtig?


    Wäre schön, wenn mir bitte jemand helfen könnte!!!


    Vielen Dank schon mal!

  • Hier noch eine kleine Ergänzung für zukünftige Anwender der Skripte: Die Adresse des Timers muss an den Prozessor angepasst werden. Sonst kommt es zu keiner Erkennung uns auch keiner Ausgabe.


    In der Datei timer.c

    Für RPi 1

    #define ST_BASE (0x20003000)

    Für RPi 2 oder 3

    #define ST_BASE (0x3f003000)


    Für den gerade veröffentlichten RPi 4, hab ich keine Ahnung.

    Nach dem Download ist usniffer für RPi 1 voreingestellt tsniffer für RPi 2 +3


    Edit: Oh, nachdem ich das jetzt selbst herausgefunden habe, sehe ich auch, dass es weiter oben im Thread auch steht. Hätte mir natürlich Zeit erspart, aber wenn man die Lösung schon kennt, kann man das auch lesen.

    Edited once, last by tonklon: Angefügt, dass das Problem weiter oben schon gelöst war. ().

  • Hallo, wie sind denn die Ausgaben des Sniffers zu interpretieren?

    Auf Seite 1 findet man noch Angaben zu ein paar Zeichen, aber was ist mit dem Rest?


    Für mein Gerät bekomme ich Ausgaben wie:

    Code
    <14501> 345 380 345 377 347 379 345 378 346 379 345 379 345 380 344 379 345 378 345 378 346 381 343 3636 709 381 343 743 344 744 342 742 706 382 705 381 707 379 345 741 707 386 338 743 343 745 704 383 703 382 705 383 704 384 339 745 342 742 707 381 343 745 342 744 705 384 702 390 335 749 700 381 706 382 341 747 702 384 340 745 704 384 703 383 341 748 338 747 702 386 339 747 702 385 340 746 703 384 341 746 341 745 343 744 704 387 338 747 340 750 700 383 341 745 704 384 341 747 702 385 702 384 340 746 704 385 701 388 337 749 700 385 702 386 338 747 340 748 700 385 703 385 700 394 693 386 701 390 335 747 702 390 334 751 336 mint=334 
    xxxxxxxxxxx*XyyyXXXyXyyXXXXyyXyyXXyXXyXyXXyyXyXyXyyyXyyXyXyXXyXXyXXyyXXXXXyXyW 
      -2-> 0000000000000000000000000000000000000000000000000000000000000000000000000000 [76] $0 
      -3-> 000000000000e1010e0e10e0e011010e10e0e0e010e1010e10e0110e0110110e010e1011011010e0e1010e10110110e0110e0110e010e10e0e0e0e011010 [124] $ad6ad55a 
      -4-> 01010101010101010101010111011001110011011101100011001101100010011100100011011101110010011101110111011001110110001000100011011100100011011000110011001000100 [155] $e46c6644 

    Was hat es damit auf sich? Die Zeile beginnend mit x ist klar. Bei 2,3 und 4 scheint es sich um die verschiedenen Decodierungsversuche nach anderen Verfahren zu handeln. Wofür stehen die Zahlen in den Klammern? Wofür die Hex-Bytes hinter den Dollar-Zeichen?


    Beim Senden einer 1 mit 433Utils erhält man 4 Telegramme, da hätte ich eigentlich erwartet dass man über den Sniffen auch 4x das gleiche Telegramm erhält. Jedoch bei

    Code
    sudo ./codesend 1

    erhält man

    Kann jemand kurz erläutern wie die Telegramme zu lesen sind?


    Vielen Dank!