Ich hab hier zwischen einem Display und einem Controller folgendes digitales Signal mit einem unbekannten Protokoll entdeckt, dass vom Leitungscode her mit keinem mir bekannten Protokoll übereinstimmt. Erstmal geht es mir um den Leitungscode und wie man ihn nennt. Dann könnte ich nach einer Arduino-Library Ausschau halten mit dem ich das Signal in UART konvertieren kann, um das Signal zu analysieren. Die Infos, die ich über das Datensignal habe: -Es findet über nur über eine Ader Kommunikation in eine Richtung statt. -Pegel ist Low: 0V, High 3,3V -High und Low entspricht nicht direkt einer logischen 1 oder 0. -Ein Symbol ist 1ms lang, ein Bit ist immer 3ms lang -Ein Bit besteht vermutlich aus einem anfänglichen "High" (1ms) und dann entweder a) "Low" für 2ms = logische "0" oder b) "Low" für 1ms + "High" für 1ms = logische "1" also immer insgesamt 3ms pro Bit -Keine Start/Stoppbits/Paritybits wie bei UART, sondern hinter einer logischen "1" z.b. geht es gleich mit "High" für das nächste Bit weiter, so dass in diesem Fall das Signal 2ms lang "High" ist (Ende vom letzten High-Bit + Anfang von neuem Bit (egal ob 1 oder 0)) -Eine Botschaft besteht aus 288 Bit = 12 Byte und wird periodisch mit 2Hz wiederholt. Es ähnelt sehr OneWire (ist aber deutlich langsamer) oder IR-Protokollen (auch hier deutlich langsamer), aber wie nennt man den Leitungscode, wo über 3 Symbole 1 Bit repräsentiert wird und wo die Bits immer gleiche Dauer haben (3ms).
Angehängte Dateien:
-
Signal_Bitdauer.png
48 KB -
Botschaftsdauer.png
41 KB -
Periode_Botschaften.png
40 KB
Timo N. schrieb: > zwischen einem Display Steht im DaBla des Displays nichts über dessen Anforderungen?
Dann würde nach logisch "high", welches mit einem physischen Highbit endet, das nächste logische "Bit" ebenfalls mit einem physischen Highbit beginnen, das wäre dann zusammen ein physisches Highbit mit 2ms Länge. Vielleicht irgendeine Biphase-Codierung? Manchester-Code? Blackbird
Rein aus dem ersten Bild heraus könnte es eine einfache PWM mit 001 und 011 sein.
S. Z. schrieb: > Steht im DaBla des Displays nichts über dessen Anforderungen? Gibts nicht. Ist Herstellergeheimnis. China. Lothar J. schrieb: > Dann würde nach logisch "high", welches mit einem physischen Highbit > endet, das nächste logische "Bit" ebenfalls mit einem physischen Highbit > beginnen, das wäre dann zusammen ein physisches Highbit mit 2ms Länge. > > Vielleicht irgendeine Biphase-Codierung? Manchester-Code? Zu 1) Ja, das habe ich genauso ja auch beschrieben. Es gibt da keine Abgrenzung der beiden Bits durch Pegelwechsel. Bei logisch 0 nach logisch 0 und logisch 0 nach logisch 1 schon. Zu 2): Machnester dachte ich zuerst. Ist aber etwas anders, da es im Grunde aus 3 Einzelsymbolen aufgebaut ist. (prx) A. K. schrieb: > Rein aus dem ersten Bild heraus könnte es eine einfache PWM mit 001 und > 011 sein. PWM direkt ist es ja nicht. Außer der Symbollänge 1ms gibt es auch keine anderen Symbollängen. Man könnte höchstens sagen, dass es noch 2ms gibt (für das "Low" bei einer logischen 0.
> Biphase-Codierung? Manchester-Code? Wie man sieht, ist der verwendete Code nicht gleichspannungsfrei. Also eher nicht. > könnte es eine einfache PWM mit 001 und 011 sein. Wenn der Autor dieses "Codes" die Einfachheit der Dekodierung von Diphase-Codierungen gekannt haette, waere wohl nicht dieser Murks dabei herausgekommen. Frohes Suchen und Probieren!
Timo N. schrieb: > PWM direkt ist es ja nicht. Außer der Symbollänge 1ms gibt es auch keine > anderen Symbollängen. Man könnte höchstens sagen, dass es noch 2ms gibt > (für das "Low" bei einer logischen 0. Betrachte es als PWM mit 3ms Periode. Die fallende Flanke scheint jeweils der Start zu sein, Pegelfolge 001 wird z.B. für ein Low-Bit übertragen, 011 für ein High-Bit. In Botschaftsdauer.png reicht die Zeitauflösung leider nicht, um da vernünftig etwas zu lesen. Hast du keinen LA, um das Signal über eine ganze Botschaft mit vernünftig Zeitauflösung aufzuzeichnen?
Display und Controller Datenblatt anschauen, da steht dann wohl drinnen welcher Pin das ist, ergo weis man danach im Datenblatt um welche Leitung es sich handelt. ...wer viel mist mist Mist... ...oder mal das Typenschild posten... Display oder Controller hier posten... Alles andere ist in meinen Augen erstmal die Cristalkugel die ich gerade nicht zur Hand habe.
Rainer W. schrieb: > Betrachte es als PWM mit 3ms Periode. Die fallende Flanke scheint > jeweils der Start zu sein, Pegelfolge 001 wird z.B. für ein Low-Bit > übertragen, 011 für ein High-Bit. In Botschaftsdauer.png reicht die > Zeitauflösung leider nicht, um da vernünftig etwas zu lesen. Hast du > keinen LA, um das Signal über eine ganze Botschaft mit vernünftig > Zeitauflösung aufzuzeichnen? Ja es hat 3ms. Ich wollte wissen ob dieser Leitungscode irgendein Standard ist, der der bei irgendwelchen Protokollen eingesetzt wird. Die mir bekannten Protokolle verwenden so etwas nicht. Die steigende Flanke ist nur der Start eines neuen Bits bei einer neuen Botschaft, da die Pegelfolge High, Low Low oder High, Low, High ist. Das weiß ich schon. Auf die steigende/oder fallende Flanke kann man aber für ein Bit nicht triggern, da innerhalb einer Botschaft auf eine logische 1 (High, Low, High) eben auch wieder direkt das nächste Bit folgt mit dem ersten Symbol = High. Sprich es findet kein Bitwechsel statt. Rainer W. schrieb: > Hast du > keinen LA, um das Signal über eine ganze Botschaft mit vernünftig > Zeitauflösung aufzuzeichnen? Ich habe einen billigen LA und hab mit Logic 2 von Saleae mal ein paar Botschaften mitgeloggt. Kann man sich in die kostenlose Software von Salae reinladen (https://www.saleae.com/de/downloads/), wenn man will. Anbei der Log auf CH0. Bei der Botschaft nach 6 Sekunden hab ich Marker je nach 8 Bits gesetzt. Ich hab die Botschaften schon dekodiert. Also was ein Bit ist (High, Low, High) oder (High, Low, Low) ist schon jetzt klar. Mir geht es darum, was für ein Protokoll es ist bzw wenn das ganze Protokoll unbekannt ist, wa für ein Leitungscode.
Sven B. schrieb: > Display und Controller Datenblatt anschauen, da steht dann wohl drinnen > welcher Pin das ist, ergo weis man danach im Datenblatt um welche > Leitung es sich handelt. Alles lesen und verstehen gehört scheinbar nicht zu Deinen Stärken: Timo N. schrieb: > S. Z. schrieb: >> Steht im DaBla des Displays nichts über dessen Anforderungen? > > Gibts nicht. Ist Herstellergeheimnis. China.
Rainer W. schrieb: > Betrachte es als PWM mit 3ms Periode. Die fallende Flanke scheint > jeweils der Start zu sein, Pegelfolge 001 wird z.B. für ein Low-Bit > übertragen, 011 für ein High-Bit. Würde ich auch sagen. Ist übrigens prinzipiell ähnlich dem bei den WS281x verwendeten Protokoll, nur die genauen Zeiten sind natürlich anders und die Polarität ist genau umgekehrt. > Hast du > keinen LA, um das Signal über eine ganze Botschaft mit vernünftig > Zeitauflösung aufzuzeichnen? Das Signal kann man sicher sicher völlig problemlos mit so ziemlich jeder µC-UART erfassen. 7N1 und knapp unter 27kBit/s einstellen. Jedes empfangene 7Bit-Datenwort steht dann für ein Bit des Payloads und hat das Format b1xxxxx0, wobei in den fünf mit x gekennzeichneten Bits die eigentliche Nutzinformation steckt und durch Mehrheitsentscheidung extrahiert werden kann. Ob dann allerdings eine Mehrheit von 1-Bits auch tatsächlich Eins und eine Mehrheit von 0-Bit Null bedeutet oder ob es genau ungekehrt ist, das läßt sich nicht ermitteln, ohne etwas über den Inhalt der Nachrichten zu wissen.
Timo N. schrieb: > > Die steigende Flanke ist nur der Start eines neuen Bits bei einer neuen > Botschaft, da die Pegelfolge High, Low Low oder High, Low, High ist. Das > weiß ich schon. > Auf die steigende/oder fallende Flanke kann man aber für ein Bit nicht > triggern, da innerhalb einer Botschaft auf eine logische 1 (High, Low, > High) eben auch wieder direkt das nächste Bit folgt mit dem ersten > Symbol = High. > Sprich es findet kein Bitwechsel statt. > Deshalb würde ich die fallende Flanke als Start einer neuen Botschaft sehen (entweder 001 oder 011), abgetastet wird dann nach 1,5ms. Fertsch.
C-hater schrieb: > Das Signal kann man sicher sicher völlig problemlos mit so ziemlich > jeder µC-UART erfassen. Oder natürlich auch mit an einen PC angeschlossenen USB-Seriell-Wandlern mit LogicLevel-Interface. 7N1 und 27kBit/s stellt auch die nicht vor Probleme.
Moin, das "Basisband" von DiSEqC sieht so aehnlich aus. In der Spec wird das als "one third bit PWK (Pulse width keying)" bezeichnet. Gruss WK
Na ja, man kann sich ja die Chips auf den Display oder Controller mal
anscheuen. Steht da gar nichts drauf!
> Gibts nicht. Ist Herstellergeheimnis. China.
Dann las ich das mal so stehen...
Auch das Gerät scheint wohl unbekannt zu sein, keine
Funktionsangabe...um was es sich handelt...
Das ist schon sehr komisch...
Klaus schrieb: > Deshalb würde ich die fallende Flanke als Start einer neuen Botschaft > sehen (entweder 001 oder 011), abgetastet wird dann nach 1,5ms. Fertsch. Pardon. Du hast Recht. Also quasi das erste "High" eines Bits ignorieren bzw. auf dessen fallende Flanke triggern und dann entweder Low Low oder Low High überprüfen. Dann wieder auf fallende Flanke warten. Dann wäre alles um 1 Symbol verschoben aber immer noch korrekt, da die ganze Botschaft mit einem High aufhört. C-hater schrieb: > Das Signal kann man sicher sicher völlig problemlos mit so ziemlich > jeder µC-UART erfassen. 7N1 und knapp unter 27kBit/s einstellen. Jedes > empfangene 7Bit-Datenwort steht dann für ein Bit des Payloads und hat > das Format b1xxxxx0, wobei in den fünf mit x gekennzeichneten Bits die > eigentliche Nutzinformation steckt und durch Mehrheitsentscheidung > extrahiert werden kann. Ob dann allerdings eine Mehrheit von 1-Bits auch > tatsächlich Eins und eine Mehrheit von 0-Bit Null bedeutet oder ob es > genau ungekehrt ist, das läßt sich nicht ermitteln, ohne etwas über den > Inhalt der Nachrichten zu wissen. Das Start-Bit bei TTL-Uart ist ja ein Low. Wenn das fehlt, wird er die Daten nicht richtig interpretieren. Es würde vermutlich gehen, wenn das Startbit High wäre. Weiß gerade nicht, ob man das einstellen kann. Dergute W. schrieb: > das "Basisband" von DiSEqC sieht so aehnlich aus. In der Spec wird das > als "one third bit PWK (Pulse width keying)" bezeichnet. Danke. Finde aber wenig dazu. Sven B. schrieb: > Na ja, man kann sich ja die Chips auf den Display oder Controller mal > anscheuen. Steht da gar nichts drauf! Es ist egal was für ein Chip da drauf ist. Das wird von einem x-beliebigen Mikrocontroller interpretiert. Die Infos zum Chip bringen mich da nicht weiter, weil es dafür keinen extra Treiberchip braucht (da sowieso schon 3,3V TTL) und auch das Protokoll so langsam ist, dass jeder beliebige Mikrocontroller mit 100khz Taktfrequenz das Signal locker verarbeiten kann. Zudem wurden von allen ICs die Markings entfernt. Ich weiß, dass dich die Anwendung interessiert, aber mehr Informationen kann ich leider nicht mitteilen, da ich gerade die Komponenten nicht hier habe.
Timo N. schrieb: > Das Start-Bit bei TTL-Uart ist ja ein Low. Wenn das fehlt Das fehlt ja gerade nicht, weil jedes Symbol mit einer fallenden Flanke beginnt und mit Highpegel endet (Stop-Bit, idle). Man beachte die Überabtastung!
Timo N. schrieb: > Das Start-Bit bei TTL-Uart ist ja ein Low. Genau. Und genau das ist bei dem Signal ja offensichtlich auch der Fall. Das ist entweder 001 oder 011. Beides fängt mit 0-Bit an und hört mit 1-Bit auf, also ideale Voraussetzungen für LogicLevel-USB-Seriell-Wandler. Dein geistige Verklemmung resultiert allein daraus, dass du die steigende Flanke für den Beginn eines Codeworts hältst. Ist es aber mit an Sicherheit grenzender Wahrscheinlichkeit nicht, sondern im Gegenteil die fallende. Die steigende Flanke scheint allerdings der Anfang eines Pakets zu sein. Wie genau der Paket-Sync funktioniert, könnte man herausbekommen, wenn du ein zeitlich besser aufgelöstes Oszillogramm eines Paketbeginns geliefert hättest. Aber nach guter alter Salamischeiben-Strategie hast du genau das nicht getan. Warum eigentlich? Ich vermute mal, dass an dieser Stelle der Break-Mechanismus von UARTs zum Einsatz kommt. Siehe auch z.B.: DMX-Protokoll.
Klaus schrieb: > Das fehlt ja gerade nicht, weil jedes Symbol mit einer fallenden Flanke > beginnt und mit Highpegel endet (Stop-Bit, idle). > Man beachte die Überabtastung! Ok, man nimmt dann an, dass nach dem initialen High immer ein Low kommt und verwendet dieses Low als Startbit. Die eigentlichen Datenbits enthalten dann nur die Dauer des Low. Da danach wieder ein High kommt, wird dieses auch als Stoppbit angesehen. Wie passen da nun die 27 kBit/s rein? Bei 27 kBit/s wäre ich doch bei 27 000 Hz / 9 (1 Startbit, 7 Datenbit, 1 Stoppbit) = 3000 Hz = 333,3 µs pro UART-Abtastung. Ein Symbol dauert aber schon 1ms, also deutlich länger. Ich müsste die Frequenz so bestimmen, dass das Startbit + 7 Datenbits 2 Symbole abtasten. Nämlich erstes Low + zweites Low oder erstes Low + erstes High. Bei 8 Bits auf 2ms bekomme ich 4000 Bit/s. Dann hätte eine logische 0 den Wert b00000000 = 0x00 Eine logische 1 hätte einen von 0 abweichenden Wert. vermutlich b1110000 oder b1111000 je nachdem ob das vierte Bit noch als high oder low abgetastet wird. Dann wird bei botschaftsinterenem idle (high) wieder auf die nächste fallende Flanke gewartet. Nur die letzte Botschaft müsste dann verworfen werden, da diese nicht gültig ist, weil der echte Idle (wenn keine Botschaft übertragen wird) ja low ist (0v). Aber die länge von 12 Bytes steht sowieso fest. Verstehe. Es soll praktische das erste Low (das bei Logisch 0 und Logisch 1 immer vorkommt) als Start-Bit gesehen werden. Dann dauert eine UART-Nachricht 2ms. In diesen 2ms steckt das Start-Bit drin. Das Stoppbit wäre dann das erste Symbol des nächsten Bits, dass immer High ist. Von der UART-Datenrate dann einfach 1Startbit+7Datenbit = 8Bit so anpassen, dass 8 Bit in die 2ms passen. Sprich
Angehängte Dateien:
-
Paketanfang.png
2 KB
C-hater schrieb: > Die steigende Flanke scheint allerdings der Anfang eines Pakets zu sein. Wie auch sonst, wenn das Signal zwischen den Paketen offensichtlich Low ist. > Wie genau der Paket-Sync funktioniert, könnte man herausbekommen, wenn > du ein zeitlich besser aufgelöstes Oszillogramm eines Paketbeginns > geliefert hättest. > > Aber nach guter alter Salamischeiben-Strategie hast du genau das nicht > getan. Warum eigentlich? Es steht dir frei, die Salamischeibe selbst abzuschneiden - einfach lesen. Timo N. schrieb: > Signal_Unbekanntes_Protokoll.sal (193 KB) Das sind gut 130 Pakete von 289ms Dauer im Abstand von 500ms.
C-hater schrieb: > Das ist entweder 001 oder 011. Beides fängt mit 0-Bit an und hört mit > 1-Bit auf, also ideale Voraussetzungen für > LogicLevel-USB-Seriell-Wandler. > > Dein geistige Verklemmung resultiert allein daraus, dass du die > steigende Flanke für den Beginn eines Codeworts hältst. Ist es aber mit > an Sicherheit grenzender Wahrscheinlichkeit nicht, sondern im Gegenteil > die fallende. > > Die steigende Flanke scheint allerdings der Anfang eines Pakets zu sein. > Wie genau der Paket-Sync funktioniert, könnte man herausbekommen, wenn > du ein zeitlich besser aufgelöstes Oszillogramm eines Paketbeginns > geliefert hättest. > > Aber nach guter alter Salamischeiben-Strategie hast du genau das nicht > getan. Warum eigentlich? Ja ist ja gut. Ich habs kapiert. Man kann alles um 1ms verschieben und interpretiert 001 oder 011 als logische 0 und logische 1. Da die Botschaft mit seinen 288ms auf ein Überbleibsel-High endet, passt das auch. Der Puls am Anfang eines Pakets (damit meinst du ja eine Botschaft mit seinen 288ms?) ist eben auch genau 1ms und nicht länger. Da hab ich nur kein Screenshot von gemacht. Es ist eben halt kein Laboraufbau, wo ich kurz mal hingehen könnte um das nachzuliefern. Ich liefere nicht mit Absicht Salamischeiben. Wenn du das meintest. Ich dachte eben, dass man mit den gegebenen Informationen schon genug anfangen kann. Ich wollte zuerst ja auch mal wissen, ob da ein bekanntes Protokoll / ein bekannter Leitungscode ist. Scheint es aber nicht zu sein.
Rainer W. schrieb: > Wie auch sonst, wenn das Signal zwischen den Paketen offensichtlich Low > ist. Eben. > Es steht dir frei, die Salamischeibe selbst abzuschneiden - einfach > lesen. Nix mit einfach lesen oder anschauen. > Timo N. schrieb: >> Signal_Unbekanntes_Protokoll.sal (193 KB) *.sal kann ich nicht. Was ist das? Wer braucht das? Das eine gezeigte Beispiel läßt nur Vermutungen über den Paket-Sync zu. Vermutlich wird es bezüglich der Verwendung einer UART als Empfänger darauf hinaus laufen: Break-Condition, dann n Payload-Bits "wegwerfen" (oder auf eben das hier Erwartete kontrollieren), dann beginnt der tatsächliche Payload. Die UART ist jedenfalls ab dem dritten Pegelwechsel "synchron".
Timo N. schrieb: > Das wird von einem x-beliebigen Mikrocontroller interpretiert Das könnte man sogar mit einem Schieberegister und zwei Monoflops auswerten.
Moin, Timo N. schrieb: > Danke. Finde aber wenig dazu. Hier gibts noch alles tutto completto im Karton: https://www.eutelsat.com/files/PDF/DiSEqC-documentation.zip (Obwohl ich schon glaube, dass du da eine komplett andere Baustelle hast). Gruss WK
C-hater schrieb: > *.sal kann ich nicht. Was ist das? Sag ich doch - einfach lesen und deine Bockigkeit mal hintenan stellen. Timo N. schrieb: > Kann man sich in die kostenlose Software von Salae reinladen > (https://www.saleae.com/de/downloads/), wenn man will.
Rainer W. schrieb: >> Kann man sich in die kostenlose Software von Salae reinladen >> (https://www.saleae.com/de/downloads/), wenn man will. Ich will das halt nicht. Diese Software ist alles andere als "kostenlos". Sie kostet nur kein Bargeld...
C-hater schrieb: > Ich will das halt nicht. Diese Software ist alles andere als > "kostenlos". Sie kostet nur kein Bargeld... Das klingt ja ominös. Ich benutze diese Software auch dauernd. Ich habe allerdings irgendwann dann einen Pro 16 von Saleae gekauft, und insofern die Software mit Bargeld (oder wars Paypal?) bezahlt. Oder was meinst du? LG, Sebastian
Timo N. schrieb: > Angehängte Dateien: > Signal_Unbekanntes_Protokoll.sal (193 KB) Mit "100" als 0 und "101" als 1 interpretiert, wird als erstes Byte immer 0x10 gefolgt von einem Paketzähler (2 Byte, Low-Byte first) übertragen. Das Paket bei 33,05s hat die Nummer 0x6000. Das siebte Byte ist in den aufgezeichneten Daten immer 0x00. Insgesamt besteht jedes Paket aus 12 Byte. Ohne weitere Info zum Dateninhalt - viel Spaß
Rainer W. schrieb: > Mit "100" als 0 und "101" als 1 interpretiert, wird als erstes Byte > immer 0x10 gefolgt von einem Paketzähler (2 Byte, Low-Byte first) > übertragen. Das Paket bei 33,05s hat die Nummer 0x6000. Das siebte Byte > ist in den aufgezeichneten Daten immer 0x00. Insgesamt besteht jedes > Paket aus 12 Byte. > > Ohne weitere Info zum Dateninhalt - viel Spaß Oh danke. Das hab ich schon gewusst. Aber trotzdem Danke fürs Engagement.
Das letzte Byte der 12 Byte langen Pakete ist eine CRC (Polynom 0x01, etwas ungewöhnlich) über die 11 Byte davor. Nachtrag: oder anders ausgedrückt, einfach das XOR über die 11 Bytes ;-)
Sven B. schrieb: > ...wer viel mist mist Mist... das reimt sich zwar irgendwie, ergibt aber überhaupt keinen Sinn!
Martin S. schrieb: > das reimt sich zwar irgendwie, ergibt aber überhaupt keinen Sinn! Mit der Rechtschreibung hat dieser Forenfreund das nicht so - Hauptsache Sprüche klopfen ... 🤔
Martin S. schrieb: > Sven B. schrieb: >> ...wer viel mist mist Mist... > > das reimt sich zwar irgendwie, ergibt aber überhaupt keinen Sinn! Klar gibt das Sinn: ... wer viel mist mist Mist MIST ICH WEIß NICHT MEHR WIE DER SPRUCH GING! LG, Sebastian
Thread beobachten
Seitenaufteilung abschaltenBitte 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.