• Du musst dich registrieren, bevor du Beiträge verfassen kannst. Klicke auf Jetzt registrieren!, um den Registrierungsprozess zu starten. Registrierte User surfen werbefrei, können Suchen durchführen und sehen die volle Darstellung des Forums mit vielen anderen Unterforen!!!

WLAN Maverick BBQ-Thermometer

Hallo Der_Gute,

Ich hab mir heute das 733 bestellt und wäre sehr interessiert an deinem RasPi Projekt. Sowohl am Aufbau als auch an der SW. Allgemein bin ich in Sachen Programmierung zwar einigermassen bewandert, beim Pi und mit Linux allerdings doch eher Neuling. Hast Du dir mal überlegt eine Art Anleitung zu schreiben?

LG,
Morgon
 
Morgon schrieb:
Hallo Der_Gute,

Ich hab mir heute das 733 bestellt und wäre sehr interessiert an deinem RasPi Projekt. Sowohl am Aufbau als auch an der SW. Allgemein bin ich in Sachen Programmierung zwar einigermassen bewandert, beim Pi und mit Linux allerdings doch eher Neuling. Hast Du dir mal überlegt eine Art Anleitung zu schreiben?

LG,
Morgon
Zum Vergrößern anklicken....

Hi Morgon,

ich werde eine Anleitung erstellen, mit der das Projekt nachgebastelt werden kann ;-).

Viele Grüße
 
Hallo, das ist ja top. Ich habe mal eine Frage die ich beim durchlesen nicht beantworten konnte. Es ist ja möglich einen Sensor für die Aussentemperatur anzuschließen.
Wäre es auch möglich einen 2en Fühler für die KT anzuschließen. was ja am Maverick nicht geht.

Grüße
Frank
 
Hallo, erstmal ein riesen Lob an Lateralus und die Unterstützer hier! Ihr seid der Hammer!

Leider bin ich elektrotechnisch null begabt und habe auch noch nie einen Lötkolben benutzt. Daher traue ich mich nicht selber an das Projekt ran. Beruflich bin ich zwar in der IT beschäftigt, aber verfüge hier nur über gute Kenntnisse im Bereich Netzwerk etc.

Wenn jemand bereit wäre, mir dieses einsatzfertig (am besten in einem Korpus) zur Verfügung zu stellen, würden wir uns bestimmt einig werden.

Bei Interesse bitte eine Unterhaltung starten oder eine Mail an geggeg(at)gmx.de.
 
Soo hier ein kleines Howto zum Einsatz mit dem Raspberry!
Vorab: Ich setze bei dem Howto eine gewisse Grundkenntnis voraus.
Folgende Themen werde ich in diesem Howto nicht behandeln: initiale Einrichtung das Raspberries, Einrichtung von wiringPI, GPIO PIN Verteilung.

1. Anschluss des 433 MHz Receivers
Zum Einsatz kommt dieser Receiver:
http://www.amazon.de/Aukru-Superreg...d=1427028249&sr=8-1&keywords=433+mhz+receiver

Damit der Receiver funktionieren kann, muss dieser zunächst an den RPi angeschlossen werden (am einfachsten geht es mit Breadboard jumper Kabeln). Dies erfolgt über 3 Kabel: VCC, GND, DATA.
VCC sollte an den 3.3V GPIO Port, GND an einen Ground Port, Data geht an einen offenen GPIO Port. In meinem Setup wurde der GPIO PIN 4(BCM Nummerierung) verwendet.
Auf dem Receiver sind die Eingänge beschriftet, sodass ziemlich schnell deutlich werden sollte wo was angeschlossen werden sollte.

1.1 Antenne
Hier kann eine Kuferdraht mit 17,3 cm länge (sollte eingehalten werden) an den ANT Anschluss gelötet werden. Bei mir hat dies die Entfernung auf 2 M erhöht.

2. Einrichtung des Programms
Zunächst muss die Datei aus dem Anhang (maverick.c) in ein Verzeichnis auf dem PI kopiert werden.
Befindet sich die Datei auf dem Pi, kann diese mithilfe eines Editor bearbeitet werden, um den GPIO Port (BCM Bezeichnung verwenden!) anzupassen an dem sich der DATA Pin des Empfängers befindet.
#define PIN 4

In dem Programm können weitere Parameter zum debuggen aktiviert werden, die zunächst aussen vor gelassen werden. Interessant ist es, wie das Programm in anderen Umgebungen läuft bzw. ob das Script so übernommen werden kann.

2.1 Kompilieren des Programms
Ist der GPIO Pin gesetzt, muss das Programm nun noch kompiliert werden.
Dies erfolgt mit gcc. Desweiteren muss wiringpi installiert sein, damit bestimmte Funktionen genutzt werden können.
http://wiringpi.com/download-and-install/

gcc lässt sich mit sudo apt-get install gcc installieren.

Dann in das Verzeichnis mit der Datei maverick.c wechseln und folgenden Befehl ausführen:
gcc maverick.c -o maverick -lwiringPi

Der Prozess sollte ohne Rückmeldung durchlaufen.
Anschließend befindet sich im Ordner eine ausführbare Datei maverick.
Diese Datei muss nun im Hintergrund ausgeführt werden und schreibt ein Logfile, aus dem man die Temperatur entnehmen kann:
sudo ./maverick > maverick.log 2>&1 &
Wird die Datei nicht im Hintergrund, sondern im Vordergrund ausgeführt, nimmt die Ausgabe des Programms eine zu hohe Auslastung an und sorgt dafür, dass das Programm nicht korrekt laufen kann.

In der Logdatei kann man nun die Temperatur sehen:
Preamble detected @5451565
Byte 1:0xAA @1156605436 (5451573)
Byte 2:0x99 @1156609507 (5451577)
Byte 3:0x95 @1156613468 (5451581)
Byte 4:0x59 @1156617447 (5451585)
Byte 5:0x95 @1156621421 (5451589)
Byte 6:0x99 @1156625398 (5451593)
Byte 7:0x59 @1156629384 (5451597)
Byte 8:0x59 @1156633342 (5451601)
Byte 9:0x95 @1156637322 (5451605)
Probe 1:20 Probe 2:20 @1156637338

An dieser Stelle lasse ich offen was man mit diesem Logfile alles anstellen kann :-). Wer sich maverick.c ein wenig genauer ansieht, wird sehen, dass es auch Parameter gibt, um die Werte in eine HTML Datei zu schreiben.

Bei Fragen einfach Fragen :-).

Viele Grüße
Der_Gute
 

Anhänge

  • maverick.zip
    2,3 KB · Aufrufe: 219
der_gute schrieb:
Interessant ist vor allem, dass deine Ranges sich stark von den Ranges im Raspberry unterscheiden(deine ist deutlich höher angesiedelt)!
Es scheint so, als würde die Lösung mit dem Flyport mehr Zeit benötigen um das Eingangssignal zu verarbeiten. Ich denke, dass eine Checksum nur bedingt nötig ist :-). Wir haben ja schließlich den Header, an dem man bereits erkennen kann, ob ein Paket zur Hälfte korrekt ist. Wie ich gesehen habe, besteht der komplette Bitstring nur aus A,9,5,6. Man könnte somit theoretisch noch prüfen, ob der Bitstring nur diesen Zeichenfolgen entspricht.
Zum Vergrößern anklicken....

Mein Timer läuft mit einer 0,5us Periode, vermutlich läuft deiner beim Raspberry nur jede 1us? Das würde erklären warum meine Werte ca. doppelt so groß sind ;)
meine Werte sind:
125us < ShortBit < 365us
390us < LongBit < 600us

Mit der Verarbeitungszeit hat das nichts zu tun. Mich wundert eigentlich dass es mit dem Raspberry funktioniert. Dort läuft ja (im Gegensatz zum Flyport) kein RealTime-OS, wie wird dort also garantiert dass der Timer-Interrupt exakt jede 1us aufgerufen wird? Was wenn ein anderer Task dazwischenkommt?
Oder kann man sich im Raspberry die Priorität einzelner Tasks aussuchen?
Wie du merkst, kenne ich mich mit dem Raspberry nicht wirklich aus :D

Den Header überprüfen ist imho nicht genug, deine Idee mit dem Einschränken auf A,9,5,6 finde ich sehr gut! Das werde ich mir auch überlegen


geola schrieb:
Das scheint was Proprietäres zu sein was dann wohl schwer zu knacken ist.
Ich werte auch in meinem AVR alle einkommenden Zeichen auf Sinnfälligkeit aus (A,9,5,6) - das filtert schon einige Fehler weg.
Zum Vergrößern anklicken....

Wie gesagt, eine sehr gute Idee!

der_gute schrieb:
Soo hier ein kleines Howto zum Einsatz mit dem Raspberry!
Zum Vergrößern anklicken....

Ich finde dein HowTo genial! Es ist aber imho einen eigenen Thread wert, sonst wird dein Beitrag hier schnell in diesem langen Thread untergehen, und das hat er nicht verdient.
 
Lateralus schrieb:
Mein Timer läuft mit einer 0,5us Periode, vermutlich läuft deiner beim Raspberry nur jede 1us? Das würde erklären warum meine Werte ca. doppelt so groß sind ;)
meine Werte sind:
125us < ShortBit < 365us
390us < LongBit < 600us

Mit der Verarbeitungszeit hat das nichts zu tun. Mich wundert eigentlich dass es mit dem Raspberry funktioniert. Dort läuft ja (im Gegensatz zum Flyport) kein RealTime-OS, wie wird dort also garantiert dass der Timer-Interrupt exakt jede 1us aufgerufen wird? Was wenn ein anderer Task dazwischenkommt?
Oder kann man sich im Raspberry die Priorität einzelner Tasks aussuchen?
Wie du merkst, kenne ich mich mit dem Raspberry nicht wirklich aus :D
Zum Vergrößern anklicken....
Oh ich hatte deine Ranges größer in Erinnerung :-)
Dann kommen wir uns ja doch sehr nah! Meine sind:
90us < ShortBit < 390us
390us < LongBit < 650us

Die Verarbeitungszeit ist beim rpi definitiv höher! Wie du schon sagtest gibt es andere Prozesse und es ist kein Echtzeitsystem.
Die Frequenz, wie häufig überprüft wird, ob sich am GPIO Pin etwas ändert, liegt wohl ohne Anpassungen zwischen 25 und 75us und lässt sich auf bis zu 10us heruntertweaken (indem man die Interrupts in den Kernel packt oder auch indem man den Prozess priorisiert). Man merkt auch, dass der raspberry damit gut zu tun hat, wenn man sich die CPU Auslastung ansieht. Ein Mediacenter parallel laufen zu lassen fällt eher raus :-).
Alles in einem denke ich, dass dies aber keine große Rolle spielt, weil das mit der Software und den Ranges aufgefangen wird (unbestritten ist ein dediziertes System a la Flyport vermutlich besser dafür geeignet :-))
https://sites.google.com/site/hamlinhomeprojects/projects/raspberry-pi-isr
Desweiteren gibt es eine alternative Library zu wiringpi, mit der wohl noch höhere Interruptfrequenzen möglich sind. Die Library pigpio ist zudem wirklich gut, weil man eine Art Logic Analyzer Tool damit laufen lassen kann (so konnte ich die Funksignale vom Maverick debuggen ;-)). Dort sollen die Frequenzen konfigurierbar sein und bis auf 1us runtergehen können. Den Interrupt mit dieser Library habe ich jedoch leider nicht zum Laufen gebracht.


Lateralus schrieb:
Den Header überprüfen ist IMHO nicht genug, deine Idee mit dem Einschränken auf A,9,5,6 finde ich sehr gut! Das werde ich mir auch überlegen
Zum Vergrößern anklicken....
Ich warte dann noch ein wenig. Müssen ja nicht alle das Rad neu erfinden :-)
Lateralus schrieb:
Ich finde dein HowTo genial! Es ist aber imho einen eigenen Thread wert, sonst wird dein Beitrag hier schnell in diesem langen Thread untergehen, und das hat er nicht verdient.
Zum Vergrößern anklicken....

Danke für die Blumen!
Gute Idee, dies werde ich gleich mal Umsetzen :-)
 
 
Hat jemand einen Tipp für mich, wo ich den AUREL-RX MID 3V Empfänger bekommen könnte? Farnell will mich nicht beliefern :-(

Danke und Grüße
 
Schande über mein Haupt - ich habe mir von ein paar jährchen den Weber style blue gekauft.
Lässt sich das ganze auch mit diesem Realisieren? weil das Gerät greift eigentl. nur den Funk vom Maverick ab. der Weber sollte ja auch funken oder :D ?
 
Ich habe versucht die Version nachzubauen in der die Funksignale vom Maverick auf Thinkspeak gepostet werden, bin aber schon beim Hardware bestellen gescheitert da die Links von 2013 zum Teil nichtmehr existieren und ich keine Ahnung habe durch was ich die beschriebenen Geräte ersetzen kann. Ich möchte eigentlich nur mein PP auch beim Nachbarn unter Kontrolle haben, und will mich eigentlich nicht in die gewaltige Himbeeren-Materie einlesen. Wäre toll wenn hier jemand eine anfänger gerechte zusammenfassung postet ;) ;P.
 
Bin mir sicher wenn man Source-Codes lesen kann, steht das da bestimmt drinnen. Ich arbeite an einem ähnlichen Projekt mit nem Arduino aber das coden der Berechnung scheint etwas verzwickter zusein als erwartet.
 
Zurück
Oben Unten