Hallo Problem: Die daten in einer UART Kommunikation ergeben keinen sinn. Genauer: Ein Win Programm spricht mit einem Mikrocontroller, dieser schaltet dann die Uhrzeit auf einer Tafel. PC und Kontroller sind über USB verbunden. Auf die Original Platine besteht kein zugriff. Als Gegenstück für den Datenverkehr wird ein FT232RL verwendet. Das Auslesen übernimmt dann Saleae Logic 8. Übergeben wird ein 30 Byte Wort. Bei einer Änderung der Minuten verändern sich byte 23 & 24, bei einer Änderung der stunden Byte 18,19,23,24 Um eine bessere Übersicht über die Bytes zu haben, Stellt ein Python Programm die Byte Worte in eine Zeile da. Den Input bekommt sie dabei aus einer CSV Datei die von V exportiert werden kann. Kann mir jemand sagen ob ich einen felher beim Auslesen gemacht habe oder sollen die daten für Menschen nicht lesbar sein? Tafel: -Aufbau unbekannt -vom Kontroller zur tafel gehen 2 Adern Platine: -FT232BL -M430F149 Aufbaue: PC--> USB-Kabel -> FT232RL -> Saleae Logic 8
Das sieht irgendwie nach DCF aus.
Mathias B. schrieb: > Um eine bessere Übersicht über die Bytes zu haben, Stellt ein Python > Programm die Byte Worte in eine Zeile da. Übersichtlicher wäre hier eine Hex-Darstellung. Eine Suche in dieser 0-1-Zahlenwüste ist ja umständlicher als die Nadel im Heuhaufen zu finden... > Kann mir jemand sagen ob ich einen felher beim Auslesen gemacht habe > oder sollen die daten für Menschen nicht lesbar sein? Warum sollten sie für den Menschen lesbar sein? Eine naheliegende Möglichkeit zum Schutz vor einem Nachbau ist das "Verschlüsseln" der Kommunikation. > Kann mir jemand sagen ob ich einen felher beim Auslesen gemacht habe Hast du dir das Timing der Bits und Worte mal auf dem Oszilloskop angeschaut? Nur, um sicher zu sein, dass die Baudrate passt... > Bei einer Änderung der Minuten verändern sich byte 23 & 24, > bei einer Änderung der stunden Byte 18,19,23,24 Irgenwie logisch, weil bei einer Stundenänderung ja auch die Minuten von 59 auf 00 springen. Kannst du auch sagen, welche Uhrzeit zu welchem Telegramm gehört? Und wie oft solche Telegramme gesendet werden?
Lothar M. schrieb: > Übersichtlicher wäre hier eine Hex-Darstellung. Eine Suche in dieser > 0-1-Zahlenwüste ist ja umständlicher als die Nadel im Heuhaufen zu > finden... Orginal export aus Saleae : 1325_1330_bin.csv 1325_1330_hex.csv vieleicht etwas übersichtlichere darstellung: 1325_1330_predit Session_c1.sal : Session aus dem Programm, lest sich damit wider herstellen. Lothar M. schrieb: > Hast du dir das Timing der Bits und Worte mal auf dem Oszilloskop > angeschaut? Nur, um sicher zu sein, dass die Baudrate passt... Bautrate ist in einer txt Datei im Programmordner hinterlegt (siehe anhang "Settings-COM4"). Die in dieser Antwort, angehängten Protokolle worden von 13:25 Uhr-13:30 Uhr erstellt.
Mathias B. schrieb: > vieleicht etwas übersichtlichere darstellung: > 1325_1330_predit Und die muss jetzt noch übersichtlicher werden. Alles, was konstant ist, muss erstmal weg. Und dann muss die korrelierende Uhrzeit dazu, damit man erkennt, wann da was passiert:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
In dieser reduzierten Form sieht man, dass da mehr als nur die 6 Minuten von 13:25 bis 13:30 drin sind und sich offenbar auch mitten in der Stunde überall was tut. Und das musst du jetzt mal für ein paar Stunden machen. Und mal schauen, ob das jede halbe Stunde passiert bzw. ob sich da ein Muster jede Stunde wiederholt. Und am besten einen Tag später für die selbe Uhrzeit, damit du siehst, ob sich da am nächsten Tag nochmal was ändert. Also einfach mal Puzzleteile sammeln, hin- und hersortieren und auf dich wirken lassen. Irgendwann gibt es ein Bild... ;-) So wie ich das sehe, wird es später auch nötig sein, auf die binäre Darstellung zurückzugehen. BTW: was ist übrigens dein Ziel, wenn du den Code entschlüsselt hast?
Lothar M. schrieb: > BTW: was ist übrigens dein Ziel, wenn du den Code entschlüsselt hast? Die Sachen wurden vor Jahren mal von einem Bastler erstellt, der nun verstorben ist. Wenn nun eines der Teile kaputt geht, gibt es keinen Ersatz. Ziel = Ersatzteile Vielen Dank, das du dir die Zeit genommen hast mir zu helfen.
Gast
#6454445
Mathias B. schrieb: > Problem: > Die daten in einer UART Kommunikation ergeben keinen sinn. > > Genauer: > Ein Win Programm spricht mit einem Mikrocontroller, dieser schaltet dann > die Uhrzeit auf einer Tafel. Also NOCH GENAUER: Da es sich um ein offenbar funktionsfähiges Konstrukt handelt, ist ein Sinn drin. Du hast den Sinn noch nicht erfasst. Der Betreff ist also irreführend und falsch. Gruss
Ich wollte mir nicht extra ein Programm installieren, habe deswegen mit der .txt aus dem Eröffnungspost ein wenig in Word herumgespielt. Das Protokoll scheint aus jeweils 6 Blöcken mit je 5 Byte zu bestehen. Block 1 und 2 definieren Start sowie Ende, Block 2,3,4,5 die jeweiligen Daten für die einzelnen Segmente. Block 2 z.B. Byte 1 Startbyte, Byte 2+3 Kennung, Byte 4+5 Zeitangaben Block 1 Start 0s00000000, 0b00001001, 0b01001100, 0b10000110, 0b00000110 Block 2 Daten Stunde einer Stelle Block 3 Daten Stunde zehner Stelle Block 4 Daten Minuten einer Stelle Block 5 Daten Minuten sehner Stelle Block 6 Ende 0b00000000, 0b00001010, 0b01010110, 0b11111111, 0b00000110 Vielleicht hilft es ja.
Holger L. schrieb: > Block 2 Daten Stunde einer Stelle > Block 3 Daten Stunde zehner Stelle Das passt dann aber nicht dazu, dass sich die "Stundensegmente" augenscheinlich zur halben Stunde auch ändern... Wie gesagt: da braucht es noch Informationen. Wichtig ist, Wiederholungen zu finden. Blöd wäre, wenn es keine solchen stündlichen oder täglichen Wiederholungen gäbe. Was ich noch testen würde: Was passiert, wenn du genau so ein beliebiges mitgeschnittenes Datenpaket von deinem "Trace-PC" an die Anzeige schickst? Zeigt sie dann die Zeit an, zu der dieses Datenpaket mitgeschnitten wurde?
Gast
#6454559
Hallo, ich habe mich erinnert so was schon mal gesehen zu haben! Du musst die Daten in deinem File „1325_1330_predit“ in 5er Gruppen zerlegen! Man erhält insgesamt 13 verschiedene 5er Gruppen: Das sind: 0x0, 0x9, 0x4c, 0x86, 0x06, 0x0, 0x9, 0x52, 0xcf, 0x7f, 0x0, 0x9, 0x56, 0xff, 0xbb, 0x0, 0xa, 0x4c, 0xcf, 0x43, 0x0, 0xa, 0x4c, 0xdb, 0x2f, 0x0, 0xa, 0x52, 0x86, 0x3a, 0x0, 0xa, 0x52, 0x87, 0x3d, 0x0, 0xa, 0x52, 0xbf, 0x95, 0x0, 0xa, 0x52, 0xed, 0x2c, 0x0, 0xa, 0x52, 0xef, 0x22, 0x0, 0xa, 0x52, 0xfd, 0x5c, 0x0, 0xa, 0x52, 0xff, 0x52, 0x0, 0xa, 0x56, 0xff, 0x06, Das letzte Byte in jeder Gruppe ist die 8Bit-CRC jeder Gruppe berechnet über die ersten 4-Byte nach dem sogenannten „CRC8 (ITU-T)-Polynom“ (x8+x2+x+1). Habs extra für alle 13 nachgerechnet! Den Inhalt (d.h. die Bedeutung) der ersten 4 Byte musst du selber herausfinden. Gruss
Gast
#6454582
Hallo, kurzer Nachtrag: da der Startwert der CRC-Berechnung 0x00 ist spielt das erste byte in jeder Gruppe mit ebenfalls 0x00 keine Rolle. D.h die Berechnung der CRC kann auch nur über Byte 2,3,4 erfolgen. Gruss
Lothar M. schrieb: > damit man erkennt, wann da was passiert: > 13:25 0xdb, 0x2f 0xed, 0x2c > 13:26 0xdb, 0x2f 0xfd, 0x5c > 13:27 0xdb, 0x2f 0x87, 0x3d > 13:28 0xdb, 0x2f 0xff, 0x52 > 13:29 0xdb, 0x2f 0xef, 0x22 > 13:30 0xcf, 0x43 0xbf, 0x95 > 13:31 0xcf, 0x43 0x86, 0x3a Die Minuten-Einer und die Bytes in der dritten Spalte sehen aus wie Siebensegmentcodes mit gesetztem Bit 7.
Gast
#6454692
Mathias B. schrieb: > Das Auslesen übernimmt dann Saleae Logic 8. > > Übergeben wird ein 30 Byte Wort. Bei einer Änderung der Minuten > verändern sich byte 23 & 24, bei einer Änderung der stunden Byte > 18,19,23,24 Dann häng doch mal statt irgendwelchen rumkonvertieren Texten eine .logicdata Datei an, die ein paar Minuten mindestens über einen Stundenwechsel (mit Angabe der Uhrzeit) enthält.
Schön wäre auch mal ein gutes Foto des ganzen Aufbaus, damit man eine Vorstellung bekommt, über was hier gerätselt wird.
Gast
#6454934
Es werden Pakete mit je 30 Byte übertragen, das ergibt sechs 5-er Gruppen: 1. Gruppe enthält in 4.Byte die 7-Segment-Daten Stunden zehner Stelle 2. Gruppe Stunden einer Stelle 3. Gruppe ?? 4. Gruppe Minuten zehner Stelle 5. Gruppe Minuten einer Stelle 6. Gruppe ?? Die Bytes 1 bis 3 in jeder Gruppe könnten Adresse sein und Byte 5 ist CRC Gruß Viktor
Gast
#6454950
Beispiel für 7-Segment Zuordnung:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
Nochmal kurz draufgeschaut... ;-)
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
Und das jetzt zum Gegenchecken noch über einen Stundenwechsel und einen Zehnstundenwechsel und du hast das Protokoll in der Tasche. Viktor K. schrieb: > Die Bytes 1 bis 3 in jeder Gruppe könnten Adresse sein Da wäre jetzt interessant, zu wissen, wie die Anzeige aufgebaut ist. Vielleicht gibt es dort tastäschlich Jumper oder Schalter, in denen sich diese Bits wiederfinden...
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.