Posts by SaschaMervelis

    Hast du mittlerweile eine Lösung gefunden? Ich habe seit einem halben Jahr das gleiche Problem. Nach unzähligen Versuchen aus verschieden Foren habe ich dann aufgegeben.


    Ursprünglich habe ich versucht, ein Intertechno Funktsteckdosenset (Fernbedienung ITLS-16 und ITLR-3500 Steckdosen) auszulesen - vergebens.

    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



    Wie wertest Du denn aus, ob Daten ankommen? RFSniffer z. B filtert auch schon. Man kann ja das Timing einstellen und die Code Folge muss höchstwahrscheinlich auch einem bestimmten Muster entsprechen...

    Aber zuerst mal checken ob Hardware richtig verdrahtet ist wie schnasseldag schrieb. Am besten mit 3,3V betreiben wegen des Pegels am GPIO des Pi.

    VeryPrivat, genau das vermute ich auch, dass der RFSniffer schon einiges wegfiltert. Kann man das einstellen, dass die Software erstmal alles durchlässt (Pulslänge...)? Ich habe den Empfänger am 3,3V dran. Der Aufbau folgt dieser Anweisung Felix: https://tutorials-raspberrypi.…unk-kommunizieren-lassen/ (Bis auf das statt 5V 3,3V anliegen).

    Eins vorweg:


    - Ich habe einen LowCost Empfänger (plus Sendemodul)

    - Unter anderem sollten folgende Geräte kontinuierlich Daten senden:

    1. Meine Temperaturstation sendet auf 433MHz (keine Ahnung ob kodiert oder nicht)
    2. Meine 433MhZ Funktsteckdosenfernbedienung und Steckdose sendet auf jedenfall generische Codes (000FF0F0FF oder 01010010101011101000000110010011), welche hier erklärt sind


    Leider empfange ich nichts. Normalerweise sollten ja auch bei rollenden oder generischen Codes Nullen oder Einsen ausgespuckt werden oder täusche ich mich da? Gibt es nachinstallierbare Treiber für solche Codes?

    Kennt jmd. ein Modul (gerne auch teurer als 1,63€), welches unabhängig von der Codierung Daten empfängt?



    :danke_ATDE:

    Eins vorweg:

    - Ich habe auch einen LowCost Empfänger (plus Sendemodul)

    - Meine Temperaturstation sendet auf 433MHz (keine Ahnung ob kodiert oder nicht)

    - Meine 433MhZ Funktsteckdosenfernbedienung und Steckdose sendet auf jedenfall generische Codes,welche hier erklärt sind


    Kennt jmd. ein Modul (gerne auch teurer als 1,63€), welches unabhängig von der Codierung Daten empfängt? Normalerweise sollten ja auch bei rollenden oder generischen Codes Nullen oder Einsen ausgespuckt werden oder täusche ich mich da? Gibt es nachinstallierbare Treiber für solche Codes?


    Zurück zur LED. Ich habe nochmal versucht das Ganze mit meinem Billigmultimeter durchzumessen. Alles zwischen 0 und 2V schwankend. Ich habe aber das dumpfe Gefühl, dass die LED und das Multimeter zu träge sind, um valide Aussagen übers Senden und Empfangen zu treffen.

    Hallo,

    mein Problem ist folgendes. Ich habe wiringPI und die 433Utils installiert (sowie den RFSniffer mit make kompiliert - make all hat leider nicht funktioniert, warum auch immer):


    root@raspberrypi:~/433Utils/RPi_utils# make g++ -DRPI -c -o ../rc-switch/RCSwitch.o ../rc-switch/RCSwitch.cpp

    g++ -DRPI -c -o send.o send.cpp g++ -DRPI ../rc-switch/RCSwitch.o send.o -o send -lwiringPi -lwiringPiDev -lcrypt

    g++ -DRPI -c -o codesend.o codesend.cpp g++ -DRPI ../rc-switch/RCSwitch.o codesend.o -o codesend -lwiringPi -lwiringPiDev -lcrypt

    g++ -DRPI -c -o RFSniffer.o RFSniffer.cpp g++ -DRPI ../rc-switch/RCSwitch.o RFSniffer.o -o RFSniffer -lwiringPi -lwiringPiDev -lcrypt


    Leider empfängt der Befehl sudo ./RFSniffer nichts. Zu empfangende Daten sind genug da (Temperaturstation, 433Mhz- Fernbedienung - wenn auch generischer Code). Ich habe an die Datenleitung am Empfänger (PIN vor GRND) eine LED angeschlossen und die blinkt wie wild. Deswegen gehe ich davon aus, dass der Empfänger "irgendwetwas" empfängt.

    Woran kann es liegen, dass Softwareseitig nichts ankommt?



    :danke_ATDE:


    Datenpin steckt in GPIO 27 bzw. Header13 (lt. WiringPi Version 2 - gehe davon aus, dass ich die habe, weil ich es ständig aktualisiere und neu probiere)

    VCC=5V

    Raspberry 3 mit GPIO Board