Forum: HF, Funk und Felder Decodierung Funkprotokoll Rolladen mit URH


von Jan K. (drj)



Lesenswert?

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

von K. S. (the_yrr)


Lesenswert?

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?

von Georg A. (georga)


Lesenswert?

Mein (nur) vom Funk-Reverse-Engineering gestählter Bauch meint, dass das 
evtl. eine Manchester/Bi-Phase-Mark-Codierung sein könnte.

von Jan K. (drj)



Lesenswert?

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
von Jan K. (drj)


Angehängte Dateien:

Lesenswert?

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?

von Dominik (Gast)


Lesenswert?

hast du das problem schon lösen können?

habe ein ähnliches problem..

von Bernd (Gast)


Lesenswert?


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
Noch kein Account? Hier anmelden.