Hallo zusammen, Ich habe in meinem neuen Zuhause elektrische Rolladen der Firma Bubendorff (sind hier in Frankreich) mit Funkfernbedienung, etwa 10 Jahre alt. Leider gibt es keine Daten zum Protokoll und damit auch keinerlei Möglichkeit diese in die Hausautomatisierung zu integrieren. Habe mich mit SDR (Adalm-Pluto) und Universal Radio Hacker (URH) an die Arbeit gemacht das zu dekodieren, aber so recht gelingt es mir noch nicht. Folgende Daten des Senders sind bekannt: Fa. Bubendorff, ca. 2010 Basiert auf TDA5100 mit 6.788MHz Quarz (*128 = 868,864MHz), nur senden, kein Rückkanal. Der TDA5100 wird von einem PIC 12F508 angesteuert. Im Anhang finder ihr ein Bildschirmfoto von URH mit den Werten für die Bitlänge etc.. Ich habe auch angefangen das zu dekodieren und dazu einen 'edge-trigger' benutzt und eine Funktion die den Synchronisationblock (oder wofür sind die 10ms am Anfang gut?) entfernt, 'cut', siehe Bildschirmfotos. Im Anhang findet ihr auch das 'protocol-file' von URH (xml Format). Hat jemand sowas schon mal gesehen? Der 10ms Block am Anfang, ist der für die Synchronisation? Der Rest ist auch nicht wirklich verständlich, die Fernbedienung wiederholt jedes Telegramm, und bei jedem Tastendruck sind die ersten 6 bytes gleich, das verstehe ich noch. Danach wird es aber komisch, selbst die Telegrammlänge ist manchmal ein bit länger. Nach etwas googlen habe ich Keeloq von Microchip gesehen, kommt mir dann aber doch ein wenig übertrieben vor für Rollos... was meint ihr? Vielen Dank und viele Grüße, Jan
Jan K. schrieb: > Der 10ms Block am Anfang, ist der > für die Synchronisation? eventuell um den AGC des Empfängers einzustellen und/oder den RSSI auszuwerten und zu erkennen dass gleich Daten kommen Jan K. schrieb: > bei jedem Tastendruck > sind die ersten 6 bytes gleich das wird die Adresse sein, damit mehr als ein Gerät davon im selben Raum funktionieren kann. warum sind in Bild 2 die ersten 12 Byte? konstant? Jan K. schrieb: > selbst die Telegrammlänge ist manchmal ein bit länger in Bild 2 müssten das doch Byte sein, oder warum ist sind das Hex Zahlen? Jan K. schrieb: > Der Rest ist auch nicht wirklich verständlich, > die Fernbedienung wiederholt jedes Telegramm alles zweimal senden macht die Übertragung zuverlässiger - was für Tasten hat das überhaupt/wie viele - erzeugt jeder Tastendruck immer dasselbe Telegram? - wenn ja: - dann ist das eher nicht verschlüsselt - mach mal ne Liste mit Telegram/Taste zuordnung - wenn nein und nur einige bit anders, dann vllt. zum unterscheiden zwischen nochmal gesendet/ selbe taste nochmal gedrückt - wenn nein und es wirklich verschlüsselt ist, dann ersetz die taster durch transistoren und häng das an deine Hausautomatisierung - schon mal Manchester Encoding versucht? so wie es aussieht scheint es nur zwei verschieden lange high/low zu geben - was für ein Empfänger wird verwendet, ein TDA5200?
Mein (nur) vom Funk-Reverse-Engineering gestählter Bauch meint, dass das evtl. eine Manchester/Bi-Phase-Mark-Codierung sein könnte.
Hallo zusammen, @K.S.: Bild 2 zeigt anscheinen 'nibbles', also 4 bits, macht hier 12 nibbles = 6 bytes am Anfang des Telegramms die sich nicht mit jedem Tastendruck verändern. Es gibt mehrere Rollos, jede hat eine einzelne Fernbedienung, den Empfänger IC kenne ich nicht (möchte nicht die Wand aufstemmen...). Evtl. gibt es Kommandos für Gruppen aber sowas habe ich auch nicht. Bisher weiss ich folgendes: Bei jedem Tastendruck sendet die Fernbedienung ein Telegramm doppelt (siehe erstes Bild im ersten post). In jedem Doppeltelegramm sind die ersten 6 bytes identisch, der Rest verändert sich und ist manchmal sogar ein bit länger. Jetzt zur Dekodierung, denn wenn die nicht stimmt machen die Daten eh keinen Sinn: Wenn man sich die Pulsfolge anschaut, sieht man dass es ASK bzw OOK ist, d.h. der Träger (868MHz) wird ein/ausgetastet. Am Anfang sind 10.05ms konstant AN, danach ein Telegramm mit Pulsen AN/AUS von jeweils 415us oder 830us. Es gibt keine längeren Pulse! Das spricht sehr für Manchester Codierung wie Georg schon angedeutet hat. Das Telegramm ist etwa 110ms lang. Das Doppeltelegramm 226ms mit Pause zwischen den beiden. Daher habe ich versucht mit URH eine solche Dekodierung zu machen, siehe drittes Bild. Das Ergebnis seht ihr in Bild 2. Aber ob das jetzt korrekt ist? In Bild zwei ist jede Linie ein neuer Tastendruck, da sieht man was konstant bleibt und was sich verändert. Aber evtl. ist es nur falsch dekodiert? Anbei ein Beispiel eines Tastendrucks als sample Datei (also Rohdaten aus dem SDR). Samplerate ist 2.1Msps/s. Ist besser als Sudoku :-) Viele Grüße, Jan
:
Bearbeitet durch User
Ah, fast ganz vergessen: Die Fernbedienung hat ein Etikett auch der Platine, siehe Anhang. Da ist ein Produktionsdatum, eine Produktreferenz aber auch eine andere Zahl drauf, 100111245A05. Irgendwie muss es dem Herstellen ja möglich sein die Fernbedienung zu tauschen ohne die ganzen Rolladen zu demontieren. Kann das mit dem Code zusammen hängen? Müsste sich dann ja irgendwie im gesendeten Telegramm wiederfinden lassen, oder?
hast du das problem schon lösen können? habe ein ähnliches problem..
Hier hat das jemand für eine Wetterstation beschrieben: https://www.rtl-sdr.com/hacking-a-la-crosse-weather-station-with-an-rtl-sdr-plutosdr-and-universal-radio-hacker/
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.