Hallo, ich hätte eine Frage zum Datenstrom eines Funksenders auf 433Mhz-Basis. Das gemessene Signal stammt von einem Handsender. Ich möchte den Empfänger mit einem µC via Funk ansteuern, dazu möchte ich den Signalverlauf mit dem µC nachbilden. Gibt es eine feste "Definition" des Signalverlaufes, also ist eine logische 1 -> 200us High und 600us low - Pegel - oder ist das eine logische 0? Danke!
Stefan schrieb: > Gibt es eine feste "Definition" des Signalverlaufes, also ist eine > logische 1 -> 200us High und 600us low - Pegel - oder ist das eine > logische 0? Das kannst du, genauso wie der Hersteller deines unbekannten Handsenders, machen wie die Witwe Bolte und die machte es, wie sie es wollte. Du könntest den Handsender aufmachen und mit etwas Glück die Bezeichnung von dem IC ablesen, dass für die Kodierung zuständig ist. Im Datenblatt findest du dann mehr. Oft sitzt ein SC5262 o.ä. drin, der mit seinen verschiedenen An-/Aus-Folgen drei Zustände ("0","1","F") übertragen kann. Dein Screen-Shot ist leider "etwas" zu kompakt, um da definitiv etwas rauszulesen.
Stefan schrieb: > Im Sender und Empfänger ist jeweils nur ein PIC verbaut... > leider.. Rolling Code?
In dem Datenstrom, also innerhalb den High-Pegeln, sind keine weiteren Daten sichtbar. Die Bildschirmkopie ist leider etwas unscharf, daher die Rippel auf den Pegeln.. Er werden lediglich 25Bits übertragen mit einer länge von 200/600ms oder 600/200ms. Ich denke der ganze Datenverkehr ist ganz einfach aufgebaut. Hab das Signal heute aufgenommen, werde morgen abend mal einen Attiny programmieren, damit der mir das Signal so erzeugt. die einzigen Angaben die ich hab sind, Funk: 433,92Mhz - Modulation AM (OOK) Entschlüsselung: Belehrungscode
Rolling Code dürfte ausscheiden, der Datenstrom ist immer der gleiche. Da gibt es keine Veränderungen.
Sieht wirklich sehr ähnlich dem Protokoll aus, das auch die billigen Funksteckdosen mit PT2262/SC5262 nutzen - nur dass die meist längere Pulsdauern als 200µs/600µs verwenden. Allerdings ist es nicht genau dieses Protokoll - es könnte aber das Protokoll sein, das die xx1527-ICs benutzen, und von dem das Billig-Funksteckdosen-Protokoll quasi eine Untermenge ist. Bei diesem Protokoll ist die Kodierung folgendermassen: Kurzer High-Pegel, gefolgt von (drei mal so) langem Low-Pegel = 0 Langer High-Pegel, gefolgt von (ein Drittel so) kurzem Low-Pegel = 1 https://github.com/sui77/rc-switch/wiki/KnowHow_LineCoding Interessant wäre, wie lange die Pause bzw. Low-Phase zwischen zwei Wiederholungen ist - wenn das Protokoll tatsächlich mit besagtem xx1527-Protokoll kompatibel ist, müsste diese Pause/low-Phase 6200µs=6.2ms lang sein. Falls es nicht dieses Protokoll ist, dann könnte die Bit-Kodierung/Zuordnung aber natürlich auch genau anders herum sein.
:
Bearbeitet durch User
ich glaub fast nicht dass es ein Tri-State Code ist, es schaut mir nur nach 0 und 1 aus. Es handelt sich um ein Funk-Armband (Vibrationsarmband), die Verschlüsselung ist glaub ich nicht all zu komplex..
Stefan schrieb: > die Pause beträgt 6,2ms! Sehr schön, dann kannst Du die oben genannte Kodierung wohl als einigermassen gesichert ansehen; der von Dir hochgeladene Signal-Screenshot würde demnach den Daten 011001100100001100000001 entsprechen. In diesem Fall gibt es auch nur 24 Daten-Bits - der letzte High-Pegel ist nicht Teil der Daten, sondern der Start der Synchronisations-Sequenz. Der Tri-State Code der PT2262/2272 etc. kann es in der Tat nicht sein, da hast Du völlig Recht - in dem von Dir hochgeladenen Signal gibt es nämlich Bitfolgen, die bei diesem Tri-State-Code nicht vorkommen können.
Stefan schrieb: > ... also ist eine logische 1 -> 200us High und 600us low - Pegel - > oder ist das eine logische 0? Was macht das für einen Unterschied, wenn du die Ursprungsnachricht nicht kennst?
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.