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:
[Blocked Image: http://abload.de/thumb/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:
[Blocked Image: http://abload.de/thumb/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

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

Neueinsteiger: Danke für die Links! Schaue ich mir mal an, wenn ich mehr Zeit habe. Mit der Methode Stift + Zettel komme ich momentan auch noch gut voran
jar: Ja, bin auch schon drauf und dran mir noch einen zu holen. Ich glaube fast, das mache ich auch bald...wenn man als Student nicht immer so knapp bei Kasse wäre

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:
[Blocked Image: http://abload.de/thumb/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€

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 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!