Hallo Ich versuche mich derzeit mit dem steuern von Funk Steckdosen mittels uC. Ich möchte dafür einen ESP8266 verwenden. Derzeit hänge ich jedoch mit dem "verstehen" des Protokolls fest. Im Internet habe ich bereits viele Beiträge gefunden mit selbigen/ähnlichen Projekten. Die da gezeigten Protokolle unterscheiden sich jedoch stark von dem, was ich hier vorfinde. Ich habe Brennenstuhl Funksteckdosen vom Typ "FE433". Die Fernbedienung ist vom Typ "HS433". Zusätzlich habe ich noch ältere Kertesz Funksteckdosen vom Typ "RC402". Diese lassen sich mit der Brennenstuhl Fernbedienung steuern. Das "Pairen" zwischen Fernbedienung und Funksteckdose funktioniert automatisch. In der Fenbedienung ist auch ein Knopf mit welchem man die ID der Fernbedienung setzen kann. Vermutlich rechnet der sich eine Zahl je nach dem wie lange man den Knopf drückt. Die Daten Telegramme schauen auch anders aus nachdem man den Knopf gedrückt hat. Auf den Funksteckdosen ist dann auch entsprechend ein Knopf mit dem man die Funksteckdose neu der Fernbedienung anlernen kann. Nun zum eigentlichen Problem: Ich habe bereits versucht das Protokoll (siehe Anhang) mit meinem ESP zu generieren. Dafür habe ich das entsprechende Digital Signal in den Sender der Fernbedienung eingespiesen. Ich habe dann entsprechend via RF das Signal moduliert erhalten. Die Funksteckdosen reagieren jedoch (natürlich) nicht. Ich vermute das Problem darin, dass die Zeiten zwischen den Signalen im originalen Protokoll wild verschieden zu sein scheinen. Das ist auch der Punkt welcher ich nicht verstehe. Weiss da allenfalls jemand mehr? Was ich bislang angenommen habe: Ein kurzer "Burst" ist eine 1, ein langer "Burst" eine 0. Ich komme dabei im Protokoll im Anhang auf folgenden Datenwert: 0b101111101111000000000 Im Programm habe ich eine 1 so realisiert, das ich 600us sende und 600us warte. Bei einer 0 sende ich 1300us und warte 1300us. Genau da vermute ich das noch viel mehr dahinter hockt.. Benjamin
Benjamin M. schrieb: > Im Programm habe ich eine 1 so realisiert, das ich 600us sende und 600us > warte. > Bei einer 0 sende ich 1300us und warte 1300us. > Genau da vermute ich das noch viel mehr dahinter hockt.. Das ganze ist eher so: * Langer Pause, kurzer Burst = 0 * kurze Pause, langer Burst = 1 wobei die Definition, was eine Null und was eine Eins ist, auch umgekehrt sein kann. Wie man auch auf dem Oszillogram sieht, ist die Gesamtdauer immer etwa gleich, also etwa 1/3 zu 2/3 bzw. umgekehrt. Das kommt also etwa hin mit 600µs zu 1300µs und 1300µs zu 600µs. Oft ist übrigens die Präambel, also das was vor den Daten kommt, recht wichtig, um die Empfänger scharf zu schalten.
:
Bearbeitet durch User
hmm, deine Ansichtsweise scheint auf den ersten Blick zu passen. Ich versuch das ganze mal zu realisieren und berichte mit dem Ergebnis!
Hallo Benjamin, zeichne doch mal auf was vor dem oben gesehenen noch passiert. Wie Matthias schon schrieb haben eigentlich alle derartigen Protokolle vor den eigentlichen Daten noch eine Präambel mit Bitzeiten die in den Datenbits nicht vorkommen. Wo hast du das obige Signal abgegriffen? Zeichne doch von dort auf wo du auch einspeisen willst, dann hast du ein unmoduliertes Signal das nicht durch den Funkweg verändert ist. Sascha
:
Bearbeitet durch User
Das ganze funktioniert nun. Das Problem war definitiv mein falsches Verständnis, ich habe das ganze immer so betrachtet das ein Burst und dann eine Pause kommt. Daher gings auch nicht auf. Die richtige Betrachtungsweise ist zuerst Pause, dann Burst. Die einzige "präambel" scheint zu sein, dass das erste Bit immer das mit dem kurzen Burst ist. Sonst kommt da definitiv nichts. Ich hab im Anhang noch ein Screenshot wo man die 4 Pakete sieht (Er sendet immer 4 Pakete die gleich sind).
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.