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).
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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!
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.
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
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.
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.
*.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".
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?
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.
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.
Signal_Bitdauer.png
(48 KB)
Botschaftsdauer.png
(41 KB)
Periode_Botschaften.png
(40 KB)
