433 Hz Rolladen-Sender decodieren

  • Hallo liebe Pi Freunde,


    ich versuche seit Tagen das Signal einer Rolladenschaltung ( Jarolift TDRR 01W ) zu decodieren.


    Das Signal habe ich via Oszilloskop aufgenommen und in Audacity analysiert.
    Es sind eindeutige Muster zu erkennen und ich konnte den code decodieren.


    Man sieht, dass ein Zyklus aus 57 Samples -> 1292,5 µs besteht.


    Für eine 0:
    19 Samples -> 430,8 µs an &
    57 - 19 Samples -> 861,6 µs aus


    Für eine 1:
    38 Samples -> 861,6 µs an &
    57 - 38 Samples -> 430,8 µs aus



    Mir ist jedoch unklar, wofür die 740 Samples -> 16780 µs und die 186 Samples -> 4217.6 µs sind.
    Ist dies die Synchronisation?


    Wie kann ich die "Flankenzeiten" in einem Code genau steuern und kann ich einfach eine genaue Kopie dieses Signal senden um die Rollladen zu schalten?
    Habt Ihr eine Idee wie ich die Flanken in µs per Code senden kann?


    Vielen Dank im Voraus


    [Blocked Image: http://fs5.directupload.net/images/151205/8knsmmrd.jpg]
    [Blocked Image: http://fs5.directupload.net/images/151205/i7nn43jx.jpg]

    Edited once, last by bulior ().

  • ich habe meine Empfänger von Intertechno gekauft und steuere mit Arrduino, am PI komme ich weniger klar

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Hallo,


    bevor Du dich verausgabst - bist Du sicher, dass der Funk nicht mit einem Rolling Code verschlüsselt ist?


    http://jarodo.de/jarolift-funk-handsender-tdrct-04
    => Funkcodierung: Rolling Code


    Ich hab versucht, meine Somfy Markise anzusteuern und mich immer wieder gewundert, dass sich das Signal geändert hat ...

  • Hallo Bulior,


    mal davon abgesehen, ob - wie WernerPi andeutet - ein Rolling-Code in Unkenntnis des genauen Algorithmus jede DEcodierung erst einmal verhindern wird, würde ich den Inhalt Deines Beitrag folgendermaßen deuten (auch in Anlehnung an andere Protokolle):


    - Eine Zeiteinheit beträgt 430,8 µs.
    - Ein Bit benötigt zur Übertragung 3 Zeiteinheiten.
    - Ein gesetztes Bit "1" Pegelwechsel nach 2 Zeiteinheiten
    - Ein ungesetzte Bit "0" Pegelwechsel nach 1 Zeiteinheit
    - Nach 8Bit (1 Byte) kommt ein Pegelwechsel, der 39 Zeiteinheiten dauert


    Ich vermute, dass mit diesen 8 Bits eine gemeinsame Zeitbasis kommuniziert wird.


    Vielleicht wird aber mit diesen 8Bits auch eine Art Schlüssel übertragen, der zur Interpretation des nachfolgenden Codes herangezogen wird.


    Denn die Daten, die nach den 39 Zeiteinheiten kommen, zeigen ein anderes Muster - nicht mehr Signale im Verhältnis 1:2 oder 2:1. Hier scheinen also Informationen / Steuersignale etc. enthalten zu sein.


    Dieser Block an Informationen wird dann wieder mit dem Pegelwechsel von 39 Zeiteinheiten abgeschlossen.


    Programmieren kann man dieses Muster recht leicht - nur sollte vorher geklärt werden, ob hier ein Rolling-Code eingebaut ist oder nicht. Denn dann wird's mächtig komplizierter. Und dann wäre ich auch mit dem dafür erforderlichen Code sehr zurückhaltend, da dieser dann auch für ähnliche Zwecke missbraucht werden kann.


    Und bei illegalen Aktionen wirst Du in diesem Forum keinerlei Unterstützung bekommen.


    Beste Grüße


    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    • Icon-Tutorials (IDE: Geany) - GPIO-Library - µController-Programmierung in Icon! - ser. Devices - kein Support per PM / Konversation

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Hallo Andreas & WernerPi,


    der Code bleibt immer gleich.
    Es wird 4 mal die Sequenz geschickt und auch bei mehr als einmal drücken, erhalte ich immer wieder die gleichen Sequenzen.
    Somit zum Glück kein Rolling Code :thumbs1:


    Nach den ersten 8 Bit bleibt auch die Sequenz immer gleich.


    Deine Logik mit den 8 Bit, hat mir schon sehr viel weiter geholfen.


    Ich begib mich mal an den Code.
    Vielen dank schonmal
    Automatisch zusammengefügt:[hr]
    Eine Frage noch:
    Gibt es billige Rolladen Empfänger, die ich selber schnell anlernen kann bzw. wo sich jemand schon die mühe gemacht hat und diese decodiert hat ?

    Edited once, last by bulior ().

  • Ich habe ein Frage zum Code,


    und zwar wenn ich wie unten beschrieben 500 [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]µs den Pin HIGH setze und dann 250[font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"] µs LOW, sind es in echt 540 [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]µ[/font][font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]s und 350 [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]µ[/font][font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]s[/font][/font][/font][/font]
    Gibt es einen interne Zeitabstimmung?


    Edited once, last by bulior ().

  • Naja, die Befehle zum Ein/Ausschalten brauchen selber ja auch "Zeit". Je kleiner die Schalt-Zeiten sind, desto "größer" der Fehler.


    Einfach die entsprechenden Delays anpassen... Ggf. kannst Du auch mal pigpio anschauen. Diese Lib soll "Leistungsfähiger" sein ...

    Edited once, last by WernerPI ().

  • Hi,
    naja ... sagen wir mal so: die pigpio-Lib ist scheinbar mal zum Favoriten von den C-Softies hier geworden.
    Das Problem bei den Zeiten sind die Latenzzeiten, die sich zwangsläufig ergeben.
    Schnasseldag hatte, als ich das EMLID-RTOS ausprobiert habe, auch mal ein paar Messungen gemacht.
    Du kommst halt mit dem "normalen" Linux durchaus mal auf 1ms Latenz ... ist halt leider so ...


    cu,
    -ds-


  • Eine Frage noch:
    Gibt es billige Rolladen Empfänger, die ich selber schnell anlernen kann bzw. wo sich jemand schon die mühe gemacht hat und diese decodiert hat ?


    ja intertechno, LIBs -> RCswitch für Arduino offen, kann Intertechno und andere Baumarktfunksteckdosen.


    für unter 10,-€ alles zusammen:
    Arduino nano328p + Nokia 5110 LCD + RTC DS3231 + 433 MHz Sender


    kann man Nachbarn ärgern mit brute force oder seine Rolladen nach Zeit fahren lassen.
    Automatisch zusammengefügt:[hr]
    Bild vergessen

    Images

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

    Edited once, last by jar ().

  • Hallo Bulior,


    ich habe ähnliche Jalousieempfänger (rohrmotor24.de) und würde sie auch gerne mit dem Raspi über openhab steuern.
    Sender- Hardware ist vorhanden, Auswertungen mit Audacity habe ich auch schon gemacht und ein paar Programmierkenntnisse sind auch
    vorhanden.
    Vielleicht können wir ja unsere Erkenntnisse austauschen und das Projekt gemeinsam angehen ..!?


    VG
    Schnarchnase

  • Servus,


    ich habe soweit eine Echtzeitabstimmung hin bekommen und schaffe es ein genaues Abbild zu senden.
    Um es mir leichter zu machen, habe ich zunächst erst einmal eine Funksteckdose von ELRO versucht zu steuern.


    Im unteren Bild seht ihr oben die Original aufgenommene Kurve am Empfänger gesendet von der Fernbedienung.
    Mit den unteren Kurven habe ich mich langsam der originalen kurve genährt und finde das Signal 1189 ist ein gutes Abbild geworden.
    Nichts desto trotz schaltet die Steckdose nicht ...


    Kann es sein, dass sich der Sender zunächst anmeldet und dann den Schaltbefehl sendet?
    Das untere Signal ändert sich aber nicht


    Muster im Sendsignal der Fernbedienung:
    Taste 1 AN: 00000 10000 01000 10001 01010
    Taste 1 AUS: 00000 10000 01000 10001 01000
    Taste 2 AN: 00000 10000 01010 00001 01010
    Taste 2 AUS: 00000 10000 01010 00001 01000


    Mich verwirrt noch die 5 Bit Struktur...
    Der hintere Block steht für AN: 01010 und AUS: 01000 und
    der 3&4 Block für Taste 1: 01000 10001 oder Taste 2: 01010 00001


    [Blocked Image: http://fs5.directupload.net/images/151206/u7nqku5q.jpg]

  • Hallo bulior,


    mir fehlt in deinen Aufzeichnungen am Anfang so eine Art Syncsignal , welches sich zeitlich meist deutlich von den Nullen und Einsen unterscheidet.
    Oftmals ist es auch so, dass das Signal mehrfach hintereinander mit einer definierten Pause dazwischen gesendet werden muss, damit es akzeptiert wird.


    Wie hast du denn jetzt die Echtzeitabstimmung programmtechnisch realisiert ?

  • Es ist einfach kein Sync Signal vorhanden ....


    Mir ist aufgefallen, dass ich ein delta T von 480 µs habe.
    Meinst du, dass kann etwas ausmachen ?
    Im Signal selbst, habe ich keine Verzögerung.


    [Blocked Image: http://fs5.directupload.net/images/151206/mfnol8q9.jpg]


    Zu deiner Frage.
    delay() oder microseconds() ist einfach zu ungenau, daher habe ich folgend Methode verwendet:


  • Hallo Bulior,


    da hat Scharchnase einen ganz hellen Moment (sorry, Dein Username und Deine Beobachtung provoziert gerade zu solcher Äußerung) gehabt.


    In Beitrag 1 hattest Du vor den "8 Bits" noch ein Signal von 39 Zeiteinheiten (á 19 Samples), das als Art Synchronisierung oder Trigger-Signal betrachtet werden kann. Flapsig formuliert: Wenn nach 740 µs ein Pegelwechsel kommt, dann sind nach einer weiteren Wartezeit 8 Bits zu empfangen.


    Bei Deiner Simulation vermisse ich diesen 740 µs-Pegel, die Wartezeit, die "8Bits", den Pegelwechsel von 186 µs Dauer.


    Wenn diese Signal-Abfolge eine Bedeutung hat, dann hast Du diese so nicht erzeugt - und die Steuerung hat es verständlicherweise nicht erkannt - und nicht reagiert.


    Beste Grüße


    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    • Icon-Tutorials (IDE: Geany) - GPIO-Library - µController-Programmierung in Icon! - ser. Devices - kein Support per PM / Konversation

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Schau bitte nochmal genau nach, ob du vor dem ersten Datensatz wirklich keinen Sync findest.
    Ich habe nunmehr 4 verschiedene Fernbedienungen von unterschiedlichen Herstellern dekodiert und auch funktionsfähig seit Monaten durch meinen Raspberry ersetzt.
    Bei allen fand ich einen Sync vor dem ersten Datensatz- meistens ein langes HIGH gefolgt von einem sehr kurzen LOW ( SYNC- Beispiel: 4100us:1000us)
    Eine Eins besteht bei meinen Intertechnos aus ON:OFF = 1080us:360us und eine Null genau umgekehrt, also 360us:1080us.


    Das vorhandene Delta T würde mich nicht beunruhigen, das alle o.g. Empfänger bei mir sehr tolerant sind.


    Alle FBs senden bei mir im folgenden Zyklus: SYNC - DATA- PAUSE- DATA- PAUSE- DATA- PAUSE- DATA....


    Ein Intertechno FB - DATA- Zyklus setzt sich bei mir wie folgt zusammen: 9bit GRUPPENCODE- 10bit CHANNEL- 6bit ON/OFF


    Deine programmtechnische Lösung gefällt mir sehr gut, da fehlt es mir noch etwas... ich arbeite mit delayMicroseconds() und das funktioniert soweit sehr gut.

  • Hallo Andreas,


    du vermisst die Daten, da ich im ersten Beitrag die Rolladenschaltung codieren wollte und momentan zur Übung vorher meine Funksteckdosen von ELRO entschlüsseln will.


    @Schnarchnase
    Leider ist kein langes High, gefolgt von den Daten wie im ersten Beitrag des Signals der Rolladen Fernbedienung vorhanden.


    "9bit GRUPPENCODE- 10bit CHANNEL- 6bit ON/OFF"
    Ich werde auch noch mal die anderen 3 Tasten aufnehmen, dann kann man vllt. eine genaue Struktur erkennen.
    Sehr gut zu wissen, dass bei dir auch 25 Bit´s übertragen werden.


    "Deine programmtechnische Lösung gefällt mir sehr gut..."
    Wenn ich Erfolg habe, hast du als erster eine PN ;)


    Ich werde morgen nochmal das Signal von Anfang an triggern und komplett hier publizieren, soweit schon einmal vielen Dank an euch!

  • Servus,


    Ich habe die Tage noch einmal die Rolladenschaltung gemessenen und bemerkt dass es sich dabei doch um einen Rolling Code handelt.


    Bild folgt


    Zudem weichen die empfangen gegenüber den gesendeten Daten von der Qualität sehr stark ab.


    Das größte Problem ist jedoch, dass ich sehr viele umgebungstrahlung erhalte und somit die Sync Zeit der Funksteckdosen sehr undcharf ist und ab der vermehrten Datensendung eine klare Struktur zu sehen ist.


    Gibt es eine Möglichkeit, den Empfänger etwas zu filtern?

  • Hallo,


    nachdem ich das oben beschrieben Rauschen nicht ausfiltern konnte, habe ich jetzt direkt auf der Platine gemessen.


    Mir ist aufgefallen, dass es bei den Funksteckdosen 4 verschiedne Codes für Dose 1 AN und Dose 1 AUS gibt. Somit auch Hopping Code


    Sofern ich nun die 4 erschienen Codes für AUS sende, passiert jedoch nichts.
    Kann es sein, dass die Steckdose nicht schaltet da ich nur (Sync + 7 x CODE...) sende und den hinteren Rest (siehe Bild) nicht mit sende?


    [Blocked Image: http://fs5.directupload.net/images/151214/xlljfmxk.jpg]
    http://fs5.directupload.net/images/151214/xlljfmxk.jpg


    Die Struktur des Codes bleibt immer gleich:
    1. Segment: 1 Sync. -> 7 x Code
    2. Segment: 3 x Code
    3. Segment: 1 Sync. -> 3 x Code
    4. Segment: 5 x Code


    Im ersten Segment ändert sich der Code zu jeder ungeraden zahl und erneut nach 10 Zyklen -> 4 Codes (abcd) ababababab ababababab cdcdcdcdcd cdcdcdcdcd ab.... (a, c -> AN)(b, d -> AUS)


    Im Segment 2 - 4 ist mir leider keine Änderung bekannt.

    Edited once, last by bulior ().