Passender 868MHz-Receiver für Funkthermomter gesucht

  • Hallo zusammen!

    Ich bin gerade dabei ein Funk-Thermometer zu decodieren. Dieses sendet auf 868MHz, die Decodierung der Temperatur und Luftfeuchtigkeit ist mit dank SDR am PC bereits geglückt. Als nächstes möchte ich natürlich meinen Pi mit einem 868MHz-Receiver ausstatten, um die Werte dort zu decodieren und zu speichern. Aber hier fängt das Problem an - welchen Receiver nehmen?
    Hier mal das Signal:
    signal_temp9osuc.png
    Es wurde wie gesagt mittels SDR abgegriffen, Modulation war auf AM eingestellt. Zur Decodierung habe ich es horizontal gespiegelt; die letzten beiden Bytes sind Temperatur (hier: oben 217 [= 21,7 Grad]; unten 199 für 19,9 Grad) und Luftfeuchtigkeit (oben 46; unten 42 [jew. Prozent-Werte]). Die restlichen Werte konnte ich noch nicht eindeutig bestimmen (der Channel, den ich am Sensor eingestllt habe, wird wohl auch mitgesendet und evtl. der Batteriestand; an den Rest mache ich mich dann demnächst).

    Das "Innenleben" des Sensors sieht so aus:
    thermometer7psls.jpg
    Nach etwas Googlen bin ich zu dem Ergebnis gekommen, dass es sich wahrscheinlich um ein RFM02-Sendemodul handelt (bitte berichtigt mich, falls dem nicht so ist! ;)).
    Passendes Empfangsmodul wäre folglich ein RFM01, richtig? Es gibt aber auch noch den RFM12b (Sender + Empfänger), für den ich ein Kernelmodul gefunden habe, das auch auf dem Raspberry laufen soll. Kann ich dieses ebenso verwenden?
    Falls schon mal jemand hier etwas ähnliches gemacht hat: Welches Modul würdet ihr empfehlen?

    Vielen Dank schon mal!
    Falls ihr noch weitere Angaben benötigt, immer her damit!

    freibeuter

  • Passender 868MHz-Receiver für Funkthermomter gesucht? Schau mal ob du hier fündig wirst!

  • schwer zu sagen, weil jeder ander Protokolle fährt

    ich weiss das RFM12(b) funktioniert für ETH comfort 100 und 200

    http://www.mikrocontroller.net/topic/172034

    es gibt dafür auch Wandthermostaten mit Funksender Aussentemperatur

    Amazon:
    Xavax Funk-Wandthermostat

    ob das mit jeder ander Funke auf 866 MHz funktioniert glaube ich kaum ohne den Code zu knacken....

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Hi jar,
    danke für die schnelle Antwort!
    Das mit dem Protokoll dürfte nicht das Problem sein - ich habe ja bereits Temperatur und Luftfeuchtigkeit erfolgreich decodiert. Auch für den Channel habe ich bereits eine Idee, die sich mit den 4 aufgenommenen Werten deckt (das hier verlinkte Bild zeigt nur die 2 Werte, die ich für Channel 1 aufgenommen habe).
    Die Frage ist meiner Meinung nach viel mehr das eingesetzte Modulationsverfahren und die Datenrate, die beim Empfänger übereinstimmen sollten. Soweit ich das sehe nutzt der RFM01 FSK, was auch der RFM02 bzw. RFM12b demodulieren kann.
    Was ich bräuchte, wäre die Möglichkeit, die gesendeten Bits des Funkthermometers auf dem Pi zu empfangen (wozu das eingesetzte Protokoll ja erst einmal zweitrangig ist - wenn ich das richtig verstehe ;)).
    Am PC könnte ich auch mit dem SDR arbeiten und die Signale darüber auslesen und decodieren lassen - ich fürchte nur, der Pi wäre nicht leistungsstark genug, die .wav-Dateien performant aufzunehmen und über ein Python-Script zu decodieren. In einem franz. Blog (ich spreche kein französisch) habe ich bereits gelesen, dass es jemand in dieser Art macht (also über SDR und ein Python-Script laufend decodieren [z.B. über "rtl_fm ‑M ‑f 868.4M ‑s 160k ‑ | python decode_tfa.py ‑‑raw ‑ ‑‑bitrate 9600 ‑‑synclen 24" vom SDR an das Python-Script übergeben und decodieren]).
    Ich denke aber mal, dass ein 868MHz für den Pi vll. doch die bessere Lösung ist. Ich möchte es gerade ungern an meinem testen, da dieser als Server für verschiedene Dienste läuft und ich ihn ungern ggf. zum Absturz bringen möchte ;)

    Einmal editiert, zuletzt von freibeuter (7. März 2014 um 11:46)


  • .....Ich möchte es gerade ungern an meinem testen, da dieser als Server für verschiedene Dienste läuft und ich ihn ungern ggf. zum Absturz bringen möchte ;)

    na nun rate mal warum ich einen dritten gekauft habe (bastelPI) :lol:

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)


  • @jar:...wenn man als Student nicht immer so knapp bei Kasse wäre :D

    komisch war ich als Student weniger, keine Steuern, geringe Ansprüche und die Frau zahlte :lol:

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Die RFMxx Module kannst du ziemlich flexibel über SPI konfigurieren (entweder direkt oder über nen AVR)

    Es gibt aber nicht nur die RFM01 , RFM02 , RFM12 Module sondern auch RFM22 , RFM23 usw wobei jeder seine Vor- und Nachteile hat. Einen Vergleich findest du hier: http://blog.strobotics.com.au/2009/07/30/int…-to-the-rfm12b/
    (es gibt aber auch noch RFM69 usw)

    Allerdings meine ich irgendwo gelesen zu haben das auch RFM12B die OOK Modulation kann sofern dies eben von einem Steuerchip übernommen wird

    Und hier noch mehr Informationen um dich zu erschlagen :D -> http://www.mikrocontroller.net/articles/RFM12_Protokoll_Stack

  • So....habe mich mal etwas an diese Geschichte mit dem Python-Script derweil gemacht. Hier hat jemand echt schon gute Arbeit geleistet. Ausgangspunkt waren pydemod sowie meine aufgenommene wav-Datei aus dem SDR. Hab diese mal von Hand gespiegelt (wg. Endianess) in Avidemux und die fertige .wav auf den Pi geladen. Anschließend noch an pydemod rumgebastelt, damit auch mein Temperatursensor unterstützt wird.
    Hier das Zwischenergebnis aus dem Terminal:
    ausgabeleue6.png

    Also das würde schon mal klappen. Nächste Schritte:
    - Endianess im Python-Script ändern, damit ich die .wav`s nicht immer von Hand über die Audacity-Effekte invertieren muss (war wohl der aufwendigste Schritt, bis ich den Effekt entdeckt habe :D)
    - restliche .wav`s testen und schauen, ob es immer problemlos klappt
    - DVB-T-Stick an den Pi und Gnuradio/RTL-SDR installieren
    - schauen, ob die Ausgaben über den "raw"-Input auch funktionieren und der Pi dafür performant genug ist

    Wenn das klappt, kauf ich mir für den PC einfach noch einmal diesen Stick und hänge den vorhandenen an den Pi - kommt billiger.
    Wobei: Hab für den Stick damals 12€ gezahlt, nun ist er auf 112,98€ :lol:

  • Kleines Update: Hatte heute wieder etwas Zeit und hab das Script umgeschrieben, dass es direkt über den raw-input von rtl-sdr funktioniert. Läuft momentan auf meinem PC und speichert die Werte in eine csv.
    Leider liegt der CPU-Verbrauch von Python damit noch ziemlich hoch (15-18%) selbst bei meinem Phenom II während rtl_fm sich mit 1% genügt.
    Ich werde die Sache also nochmal überarbeiten und mich mit numpy etwas beschäftigen, da ich damit keine Erfahrungen habe und nur mit normalen Listen etc. gearbeitet habe. Denke, damit lässt sich der Ressourcenverbrauch noch einschränken.

    Btw: Falls zufällig noch wer einen gebrauchten Pi günstig abzugeben hat, kann der/diejenige mich gern per PN kontaktieren ;)

  • So, das Python-Script zur Decodierung habe ich nun fertig (Temperatur, Luftfeuchtigkeit und Kanal werden ausgelesen; wegen fehlender Minus-Temperaturen wird die Sache mit dem Vorzeichen noch ergänzt [vermutlich das Byte/teil des Bytes vor der Temperatur, da in meinen Fällen immer 00000000]; OT: Warum um alles in der Welt nutzt man 3 Bits für den Kanal, kann aber nur 5 Kanäle einstellen? Das Display würde auch mehr hergeben :s, egal...), der 2te Pi ist da und ich habe die Geschichte mal daran getestet.
    Leider mag mein rtl_fm hier nicht so recht laufen, es stottert und stockt. Wenn ich FM-Radio über aplay ausgebe gibt es ständig underruns. Somit kann ich das Script dann auch nicht sinnvoll am Pi nutzen, wenn schon der Eingangsdatenstrom ständig abreißt :wallbash: Ich scheine nicht der einzige mit dem Problem zu sein, allerdings hat noch niemand eine Lösung dazu gefunden.

    Also muss wohl doch ein 868MHz-Receiver her, den ich an die GPIOs des Pi klemme. Habe mich jetzt schon etwas umgesehen, wie @meigrafd schon geschrieben ließe sich der RFM12b auch für OOK nutzen, allerdings soll der RFM01 das auch können und besser arbeiten (Blog-Artikel dazu).

    Hat schon wer hier einen RFM01 für 868MHz im Einsatz und kann sagen, ob es wie in dem Blogartikel beschrieben (leider wurde hier mit 433MHz gearbeitet) möglich ist, die Pakete als Hex-Strings auszugeben? Das würde mir schon extrem weiterhelfen.
    Danke schon mal!

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!