Forum: Mikrocontroller und Digitale Elektronik Unbekanntes Bus System entschlüsseln


von Daniel (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

ich versuche gerade eine Motorsteuerung, die noch in einem laufenden 
System hängt, anzusteuern. Leider gibt es keine Doku dafür.
Auf der Platine befinden sich ein PIC16F1619 und ein CAN-Transceiver vom 
Typ MCP2561.

Mein erster Gedanke war daher gleich CAN-Bus. Mit einem CAN-Hat (MCP2515 
CAN-SPI Receiver) an einem Raspberry habe ich leider keinen Teilnehmer 
gefunden.

Also habe ich den MCP2515 ausgelötet und einen Logikanalyzer angesteckt. 
Was mir folgendem Daten geliefert hat:

-> 1 Bit = 52µs => Baud-Rate 19200
-> 97 Bit lang
-> zyklisch gesendet alle 20ms
-> Daten: 0000 0100 0111 0100 0000 0011 0101 0000 0011 0000 0000 0011 
0011 0100 0011 1111 0000 0000 0011 0000 0000 0110 0000 0000 0

Von der Länge her könnte es ein CAN-Bus sein, jedoch ist die 
Geschwindigkeit sehr gering und bei weiterer Analyse der Platine habe 
ich entdeckt, dass RX/TX auf Pin 4 und 5 vom PIC hängen. Das sind beim 
PIC16F1619 lediglich Timer-Eingänge. Der PIC hat keinen CAN Receiver und 
daher muss das Protokoll softwareseitig realisiert sein.


Ich werde nun einen Analyzer programmieren, welcher die übertragenen 
Daten vergleicht und beim ersten Auftreten ausgibt. Dadurch kann ich die 
gesendeten Kommandos in der Steuerung detektieren und eventuell eine 
Struktur erkennen.

von minifloat (Gast)


Lesenswert?

Daniel schrieb:
> 0000 0100 0111 0100 0000 0011 0101 0000 0011 0000 0000 0011 0011 0100
> 0011 1111 0000 0000 0011 0000 0000 0110 0000 0000 0

Aus dem Oszi-Screenshot meine ich UART-Frames zu erkennen. Mal 
8n2-Format angenommen, wären das 11 Bit-Zeiten pro UART-Frame. Dazu 
müsste auf die Stopbits gleich das Startbit folgen. Du hast da 97 Bits 
aufgelistet. Wenn ich mir am Ende zwei Stopbits hinzu denke, komme ich 
auf 99 Bits. Kommt da was sinnvolles bei raus?

mfg mf

von minifloat (Gast)


Lesenswert?

PS. Kannst du gesampelte Rohdaten von busanalyse.png posten? vcf- oder 
sonstiges ASCII-Format?

von GL (Gast)


Lesenswert?

Könnte das auch LIN sein?

von Photo (Gast)


Lesenswert?

LIN hätte ein Break (lange LOW) und dann ein Synch 01010101

von my2ct (Gast)


Lesenswert?

Wenn das Signal wirklich vernünftig verschlüsselt ist, hast du ohne 
Kenntnis des Schlüssels und des Schlüsselverfahrens keine realistische 
Chance. Du kannst allenfalls die physikalische Übertragung (OSI Layer 1) 
raustüfteln, also die übertragenen Rohdaten gewinnen, kommst aber nicht 
an den Dateninhalt, i.e. die (entschlüsselte) Bedeutung ran.

von my2ct (Gast)


Lesenswert?

p.s.
Aber mal ehrlich: Warum vermutest du, dass die Daten verschlüsselt sind?

Solange das Steuergerät in einer abgeschlossenen Anlage sitzt und damit 
nicht eine Ultrazentrifuge für Uran-Anreicherung betrieben wird, kommt 
doch kaum jemand auf die Idee, soetwas kryptographisch abzusichern.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Das könnte ein asynchrones serielles Protokoll mit 1 Startbit, 9
Datenbits, und 1 Stopbit sein. Die Pausen zwischen den einzelnen Frames
haben eine variable Länge, was aber bei asynchroner Übertragung ja legal
ist. Im Beispiel schwanken die PÜausen zwischen 0,5 und 4,5 Bit-Zeiten:

1
Start    Daten    Stop  Pause
2
—————————————————————————————
3
  0    000010001   1     1,0 
4
  0    100000000   1     1,0 
5
  0    101000000   1     1,0 
6
  0    000000000   1     1,0 
7
  0    011010000   1     4,5 
8
  0    000000000   1     1,0 
9
  0    000000001   1     0,5 
10
  0    000000000   1     4,0+
11
—————————————————————————————

Das 9. Bit ist kein Parity-Bit, da die Anzahl der 1-Bits im Beispiel
teilweise gerade, teilweise aber auch ungerade ist.

von Rudolph R. (rudolph)


Lesenswert?

Daniel schrieb:
> ich entdeckt, dass RX/TX auf Pin 4 und 5 vom PIC hängen. Das sind beim
> PIC16F1619 lediglich Timer-Eingänge. Der PIC hat keinen CAN Receiver und
> daher muss das Protokoll softwareseitig realisiert sein.

Ich habe zwar jetzt das erste Mal in das Datenblatt von dem PIC 
geschaut, aber für mich sieht das so aus als ob Pin 5 RX vom EUSART ist 
und TX auf fast jeden Pin gelegt werden kann.
Mich wundert nur, dass Pin 4 auch noch der Reset Pin ist.

Edit: wie man auf dem Bild erkennen kann hängt der Transceiver auf Pin 5 
und 6 mit RXD und TXD.

Edit2: ich habe den 14 Pinner genommen, das macht aber nichts, RX und TX 
können wohl frei verschoben werden, Pin 12 ist nur default für RX vom 20 
Pinner.

: Bearbeitet durch User
von Daniel A. (daniel_a32)



Lesenswert?

Rudolph R. schrieb:
> Daniel schrieb:
>> ich entdeckt, dass RX/TX auf Pin 4 und 5 vom PIC hängen. Das sind beim
>> PIC16F1619 lediglich Timer-Eingänge. Der PIC hat keinen CAN Receiver und
>> daher muss das Protokoll softwareseitig realisiert sein.
>
> Ich habe zwar jetzt das erste Mal in das Datenblatt von dem PIC
> geschaut, aber für mich sieht das so aus als ob Pin 5 RX vom EUSART ist
> und TX auf fast jeden Pin gelegt werden kann.
> Mich wundert nur, dass Pin 4 auch noch der Reset Pin ist.
>
> Edit: wie man auf dem Bild erkennen kann hängt der Transceiver auf Pin 5
> und 6 mit RXD und TXD.
>
> Edit2: ich habe den 14 Pinner genommen, das macht aber nichts, RX und TX
> können wohl frei verschoben werden, Pin 12 ist nur default für RX vom 20
> Pinner.

War ein Fehler vom mir, meinte RC4 und RC5 statt Pin4 und Pin5. Du hast 
aber recht, EUSART RT/TX kann an jeden Pin gemapped werden (habe ich im 
Datenblatt übersehen). Somit könnte es wirklich über die USART 
Schnittstelle ausgewertet werden.
Meine Analyse mit einen RS232-USB Kabel und IO Ninja hat jedoch nichts 
brauchbare ergeben. Mit 19,2k Baud und unterschiedlichen Konfigs für 
Datenbreite, Stoppbits und Parity kamen keine konstanten Daten. Kann 
leider keine 9Bit einstellen.

Etwas interessantes hat sich jedoch ergeben, als ich den Motortreiber 
vom Bus getrennt habe:
- Das erste High Signal ist nur noch Halb so lang => 24µs = 1Bit
- Ein Response kommt vom Motortreiber unmittelbar auf den Request

Leider kann ich die gezielt getriggerte Aktionen mit meinem Logik 
Analyzer nicht aus dem Datenstream herausfiltern, dafür baue ich gerade 
ein Analysetool mit einem STM32. Kämpfe aber gerade noch mit einem 
Timer-Interrupt, der nicht wie gewünscht funktioniert.

von minifloat (Gast)


Lesenswert?

minifloat schrieb:
> PS. Kannst du gesampelte Rohdaten von busanalyse.png posten? vcf- oder
> sonstiges ASCII-Format?

Immer noch aktuell. Kann dein PC-Pszilloskop da ungefähr sowas hier 
exportieren??
1
Timestamp Ch0 Ch1
2
0.000000  0   0 
3
0.000001  1   0
4
0.000002  1   1
5
0.000003  0   0

Leute aus dem Forum versuchen den Kram dann auch auszuwerten. Mit den 
Bildern kann man kaum was anfangen.

mfg mf

von Daniel A. (daniel_a32)


Angehängte Dateien:

Lesenswert?

minifloat schrieb:
> minifloat schrieb:
>> PS. Kannst du gesampelte Rohdaten von busanalyse.png posten? vcf- oder
>> sonstiges ASCII-Format?
>
> Immer noch aktuell. Kann dein PC-Pszilloskop da ungefähr sowas hier
> exportieren??
>
1
> Timestamp Ch0 Ch1
2
> 0.000000  0   0
3
> 0.000001  1   0
4
> 0.000002  1   1
5
> 0.000003  0   0
6
>
>
> Leute aus dem Forum versuchen den Kram dann auch auszuwerten. Mit den
> Bildern kann man kaum was anfangen.
>
> mfg mf

Ich kann eine CSV-Datei und eine MSD-Datei anbieten.
Auf der Hersteller-Seite kann man das Programm herunterladen und dann 
die MSD Datei öffnen.
https://www.linkinstruments.com/mso28_setup_web_64bit.exe

von Yalu X. (yalu) (Moderator)


Lesenswert?

Daniel A. schrieb:
> Etwas interessantes hat sich jedoch ergeben, als ich den Motortreiber
> vom Bus getrennt habe:
> - Das erste High Signal ist nur noch Halb so lang => 24µs = 1Bit

Die verkürzten High-Phasen könnten daher kommen, dass du mit dem
Motortreiber auch gleich den Busabschluss (der evtl. im Motortreiber
integriert ist) entfernt hast. Ohne Busabschluss wird zwar schnell von
rezessiv nach dominant (high->low) geschaltet, aber nur sehr langsam
von dominant nach rezessiv (low->high), abhängig von parasitären
Kapazitäten und Kriechströmen. Das führt zu verlängerten Dominant-
bzw. Low-Phasen und damit zu verkürzten Rezessiv- bzw. High-Phasen.

Du kannst das nachprüfen, indem du dir mit deinem MSO-28 im Oszimodus
die Differenz zwischen CAN-H und CAN-L anschaust.

von sid (Gast)


Lesenswert?

Verzeiht meine Laienhafte Frage,
aber wäre es nicht einfacher zu sehen ob man eine
ähnliche ggf besser dokumentierte Motorsteuerkarte findet gleichen 
Herstellers, in der Hoffnung sie benutzt kompatible Formen der 
Kommunikation?

Oder man meisselt den PIC auf und liesst sich durch was der Hersteller 
da reingeschrieben hat, bildlich gesprochen.

von sid (Gast)


Lesenswert?

..nachtrag
was haltet Ihr denn von dem layout?
1
6bit   8bit                 8bit
2
000001 00011101             0000 0000
3
1      29                   0
4
5
110101 00000011             0000 0000
6
53     3                    0
7
8
001100 11010000 11111100    0000 0000
9
12     208      252         0
10
11
110000 00000110             0000 0000  0
12
48     6                    0           parity
mal wild geraten..
6 controlbits,  8 datenbits(oder vielfaches) und 8 stopbits (0x00)
und ein paritybit am Ende
klingt doch garnicht sooo an den Haaren herbeigezogen, oder?

Zufällig ...
0x01 (ersten 6 Controlbit) Start of Heading
0x1D (folgenden 8 Datenbit) Group Separator
0x06 (letzten 8 Datenbit) Acknowledge

von Daniel A. (daniel_a32)


Lesenswert?

sid schrieb:
> Verzeiht meine Laienhafte Frage,
> aber wäre es nicht einfacher zu sehen ob man eine
> ähnliche ggf besser dokumentierte Motorsteuerkarte findet gleichen
> Herstellers, in der Hoffnung sie benutzt kompatible Formen der
> Kommunikation?
>
> Oder man meisselt den PIC auf und liesst sich durch was der Hersteller
> da reingeschrieben hat, bildlich gesprochen.

Ja natürlich wäre es einfacher, wenn es ein Standardprodukt am Markt 
geben würde, dann hätte ich es schon gekauft. Leider ist dem nicht so. 
Es ist eine spezielle Anwendung mit über 60 Stk 12W Motoren.

Ich habe schon eine neue Platine auf STM32 Basis entwickelt mit ein paar 
Zusatzfeatures, das dauert aber wieder 1-2 Wochen bis alles bei mir 
ist... Bin aber unter Zugzwang und muss das Teil schnellstmöglich zum 
Laufen bekommen.

Hätte auch schon überlegt den PIC mit neuer Software zu flashen. 
Auslesen wird nicht möglich sein, da bestimmt das Lock-Bit gesetzt ist.
Ich probiere es aber trotzdem, sag niemals nie :-P
Mit etwas Glück kann ich ihm die Konfig-Bytes für die Schnittstelle 
entlocken.

Yalu X. schrieb:
> Die verkürzten High-Phasen könnten daher kommen, dass du mit dem
> Motortreiber auch gleich den Busabschluss (der evtl. im Motortreiber
> integriert ist) entfernt hast. Ohne Busabschluss wird zwar schnell von...

Das könnte eine Erklärung sein, denn der Bus-Abschluss war wirklich 
nicht gesetzt, habe vergessen den Jumper am CAN-Board zu setzen.
Ich hätte vermutet, dass der Client den Bus auf Low zieht um seine 
Anwesenheit zu Bestätigen. Bei weiterer Überlegung macht es aber keinen 
Sinn, da der Signalverlauf danach gleich aussieht. Bin daher deiner 
Meinung.

Vllt. hilft die Funktionsbeschreibung ein wenig bei der Auflösung:
- 8 High Side Treiber
- 10 Low Side Treiber
- 2 digitale Eingänge für Lichtschranke (Signal, Error)
- 2 Analogeingänge
- laut Beschreibung 2x RS485 Schnittstelle (jedoch mehrere Abweichungen 
bei der Pin Belegung im Schaltplan, also nicht glaubwürdig)

Das Board dient zum Ansteuerung von bis zu 80 Motoren in 
Matrix-Verkabelung (oder wie man das nennt).

Der Drehgeber ist sehr interessant realisiert. Es wird mit einem 
Mikroschalter pro Umdrehung 2 Mal eine kurze Unterbrechung im Stromkreis 
erzeugt. Der Mikroschalter ist nämlich am Öffner und Schließer Kontakt 
kurzgeschlossen, sodass beide Schaltzustände den Motor laufen lassen. 
Lediglich die kurze Unterbrechung von Offen auf Geschlossen wird im 
Stromkreis eine Spitze verursachen, die der PIC sehr wahrscheinlich 
misst. Eine Kreisförmige Nocke mit Flachstelle verursacht auf ca. 1/3 
des Umfangs einen Offen-Zustand.

Jeder Motor soll genau eine Umdrehung machen. Daher denke ich, dass der 
PIC nur die Position des Motors in der Matrix erhält und daraufhin die 
Reihen und Spalte entsprechend ansteuert werden. Beim Zweiten Impuls 
stoppt der Motor dann.

Aufgrund der bereits implementierten Funktion wäre es wünschenswert, 
wenn ich das Teil ansteuern könnte.

Yalu X. schrieb:
> Das könnte ein asynchrones serielles Protokoll mit 1 Startbit, 9
> Datenbits, und 1 Stopbit sein.

Das habe ich mittlerweile auch rausgemessen und könnte wirklich die 
Lösung sein.
Mein nächster Versuch vor dem Neubau wird also noch sein, das Teil mit 
einem anderen Controller auszulesen. Mit einem FDTI-RS232-5V Kabel hatte 
ich leider keine Chance, da es keine 9 Bit Datenlänge unterstützt.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Daniel A. schrieb:
> Mein nächster Versuch vor dem Neubau wird also noch sein, das Teil mit
> einem anderen Controller auszulesen. Mit einem FDTI-RS232-5V Kabel hatte
> ich leider keine Chance, da es keine 9 Bit Datenlänge unterstützt.

Ja, aber die meisten µC (AV PIC, STM32 usw.) mit eingebautem UART können
das. Ansonsten kannst du ja immer noch einen Software-UART verwenden.

von K. S. (the_yrr)


Angehängte Dateien:

Lesenswert?

Daniel A. schrieb:
> Yalu X. schrieb:
>> Das könnte ein asynchrones serielles Protokoll mit 1 Startbit, 9
>> Datenbits, und 1 Stopbit sein.
>
> Das habe ich mittlerweile auch rausgemessen und könnte wirklich die
> Lösung sein.

ich denke es sind mindestens 10 bit und/oder variierend.

bei 151.5ms geht der Bus low als Start bit, high geht er erst bei 157ms. 
das sind 11 Bitlängen, also 10 bit Information.

Weitere Frame Errors mit nur 9 bit bei 193ms, 276ms und 442ms (jeweils 
start bit).

Da ich mit diesem recht komischen CSV nichts anfangen konnte hab ich mal 
ein Script geschrieben um ein VCD für einen Kanal daraus zu machen.
Alle 1000 Samples sind binär entweder 11110110 oder 11110111, daher 
enthält nur ein Kanal Informationen.

EDIT:
die MSD Datei hat als Zeitbasis 50µs, die CSV 500µs. Dementsprechend 
sind alle Zeitangaben oben um den Faktor 10 zu groß. Wie auch immer wäre 
eine etwas kleiner Zeitbasis besser bei deinen kurzen Pulslängen, so ca. 
10µs oder weniger wären gut.

MSD:
0,      0us,0,-16.876,245,11110101,0,1500,0,00000000,
1, 50.000us,0,-21.3374000000001,245,11110101,0,1500,0,00000000,
2,100.000us,0,-21.3374000000001,245,11110101,0,1500,0,00000000,

CSV:
0,      0us,-44.174,-21.3374000000001,247,11110111,0,1500,0,00000000,
1,500.000us,-44.174,-25.7988,247,11110111,0,1500,0,00000000,
2,  1.000ms,-44.174,-21.3374000000001,247,11110111,0,1500,0,00000000,

: Bearbeitet durch User
von Daniel A. (daniel_a32)


Lesenswert?

K. S. schrieb:
> Da ich mit diesem recht komischen CSV nichts anfangen konnte hab ich mal
> ein Script geschrieben um ein VCD für einen Kanal daraus zu machen.
> Alle 1000 Samples sind binär entweder 11110110 oder 11110111, daher
> enthält nur ein Kanal Informationen.

Bit 0 ist Kanal 1 und dieser hing am Bus. Alle anderen Kanäle sind 
random. Konnte es leider nicht anders exportieren..

Ich habe den Oszi Screenshot ausgedruckt und mit dem Messschieber

1 Startbit (LOW) | 9 Datenbits | 1 Stoppbit (HIGH)

gemessen. Denke also, dass das funktionieren würde.

Inzwischen hingen schon mehrere Arduinos am Bus, jedoch habe ich es noch 
nicht geschafft 9 Bit über Softserial zu bekommen. Dazu wäre ein Hack in 
der Library nötig und auf meinem MacOs finde ich die Libraries nicht :-(

Versuche daher gerade mit einem STM32-NUCLEO Board die Daten auszulesen.
Die Baudrate ist nebenbei bemerkt 9600. Habe einen 8N1 Stream ausgeben 
und verglichen, sah ziemlich ähnlich aus.

von K. S. (the_yrr)


Angehängte Dateien:

Lesenswert?

Dann ist irgendetwas mit deinen exportierten Daten sehr sehr falsch.

die CSV enthält völlig andere Daten als die MSD, in der CSV ist ein 10 
bit UART drin mit der Zeitbasis 500µs und einzelnen Datenpaketen. In der 
MSD sind es 50µs Zeitbasis, ergibt immer noch nicht die 9600 Baud, aber 
zumindest sieht das Signal in etwa aus wie auf den Bildern.

Mach das Bitte nochmal ordentlich bzw. überprüfe ob das mit der 
Zeitbasis so stimmt. Selbst in der MSD ist ein Bit 50µs lang, das sind 
immerhin 20k Baud. entweder ist da auch nur Müll drin oder beim Export 
wird die Zeitbasis auf Müll gesetzt.

MSD:
                                           HIER:  v
58,  2.900ms,0,-21.3374000000001,      244,11110100,0,1500,0,00000000,
59,  2.950ms,0,-16.876,                245,11110101,0,1500,0,00000000,
60,  3.000ms,-44.174,-21.3374000000001,244,11110100,0,1500,0,00000000,
Wie man deutlich sieht ändert sich Kanal 1/ Bit 0 alle 50µs

In der MSD bekomm ich sowohl mit 9 als auch mit 10 bit Frame error, 
irgend etwas stimmt da nicht.

Bis du ordentliche Daten lieferst bin ich hier raus.
Mein Python Script spuckt jetzt auch die UART Daten als Hex aus, aber 
dafür brauch ich ordentliches Ausgangsmaterial, entweder als CSV oder 
MSD, beides geht.

: Bearbeitet durch User
von Daniel A. (daniel_a32)


Angehängte Dateien:

Lesenswert?

K. S. schrieb:
> Dann ist irgendetwas mit deinen exportierten Daten sehr sehr falsch.

Das kann leicht sein. Das Programm für den Analyzer ist wirklich 
schlecht und ich muss dafür sogar einen Windows PC laufen lassen.

Ich habe mehrmals gemessen und ein Bit ist 52-54µs lang. Baudrate von 
19200 sieht jetzt besser aus.

Mein STM32 kann die Daten schon mal lesen und schreibt mir schon mal 
Daten raus. Aber ich glaube da ist noch ein Fehler drin.

von K. S. (the_yrr)


Lesenswert?

Daniel A. schrieb:
> Ich habe mehrmals gemessen und ein Bit ist 52-54µs lang. Baudrate von
> 19200 sieht jetzt besser aus.
19.2kBaud mit 20kHz Samplerate die du uns zur Verfügung stellst, fällt 
dir was auf?

> Aber ich glaube da ist noch ein Fehler drin.
So wie es aussieht ist es eher 9N1 als 8N1. Auch hast du eine 
Wiederholung alle 6 Byte, in der MSD Datei sind eher 8 Byte/ 
Übertragungen ein Paket.

Daniel A. schrieb:
> Bin aber unter Zugzwang und muss das Teil schnellstmöglich zum
> Laufen bekommen.
Im  Hinblick darauf würde ich sagen poste schnellstmöglich vernünftige 
und richtige Daten, alle die dir bis jetzt helfen wollen arbeiten mit 
fehlerhaften Ausgangsdaten. Das heißt bei 19.2kBaud mindestents 100kS/s, 
eher mehr. Und dann sollte man auch erwarten können dass wenn du schon 
zwei verschiedene Dateiformate hochlädst beide denselben Inhalt haben 
und nicht zwei völlig verschiedene Messungen enthalten.

von Daniel A. (daniel_a32)


Lesenswert?

K. S. schrieb:
> 19.2kBaud mit 20kHz Samplerate die du uns zur Verfügung stellst, fällt
> dir was auf?

Du kannst dir die Software MSO-28 herunterladen und den Datenstream 
selbst exportieren und auch die Zeitbasis ändern. Ich denke, es ist ein 
Fehler in der CSV-Export Funktion. Gemessen wurde mit 1ms/div bzw. 
100kS, sieht man auch im Bild vom ersten Post. Die Daten stammen davon.

K. S. schrieb:
> So wie es aussieht ist es eher 9N1 als 8N1. Auch hast du eine
> Wiederholung alle 6 Byte, in der MSD Datei sind eher 8 Byte/
> Übertragungen ein Paket.

Das hast du falsch verstanden. Ich lese den 9N1 Wert vom Bus, 
konvertiere ihn im STM32 in 8N1 und gebe ihn über die zweite USART 
Schnittstelle aus. Beide Signale habe ich mir am Oszi angesehen und bei 
19,2kBaud stimmen die Länge für 1 Bit überein.

Ich habe mir den Signalverlauf ausgedruckt, mit dem Messschieber 11 Bit 
eingestellt und überprüft wo es reinpasst. Könnten auch 9N2 sein, dann 
wäre aber keine Pause zwischen den Daten.

K. S. schrieb:
> Im  Hinblick darauf würde ich sagen poste schnellstmöglich vernünftige
> und richtige Daten, alle die dir bis jetzt helfen wollen arbeiten mit
> fehlerhaften Ausgangsdaten. Das heißt bei 19.2kBaud mindestents 100kS/s,
> eher mehr. Und dann sollte man auch erwarten können dass wenn du schon
> zwei verschiedene Dateiformate hochlädst beide denselben Inhalt haben
> und nicht zwei völlig verschiedene Messungen enthalten.

Beide Datensätze haben die selbe Ausgangsbasis. Am besten selbst mit dem 
Oszi-Programm öffnen, geht auch ohne MSO-28. 100kS/s waren die 
Messparameter.
Ich kann erst in einigen Stunden wieder an den Windows PC, versuche es 
dann selbst nochmal zu konvertieren.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Daniel A. schrieb:
> 100kS/s waren die Messparameter.

... von denen aber nur 20kS/s in der MSD- und 2kS/s in der CSV-Datei
angekommen sind. Nur in deinen Screenshots sind die vollen 100kS/s
erkennbar.

von K. S. (the_yrr)


Angehängte Dateien:

Lesenswert?

Daniel A. schrieb:
> Beide Datensätze haben die selbe Ausgangsbasis. Am besten selbst mit dem
> Oszi-Programm öffnen, geht auch ohne MSO-28. 100kS/s waren die
> Messparameter.
Guck doch einfach mal auf die Bilder vom mir fünf Posts weiter oben. das 
sind die Daten aus der CSV und MSD unverändert. willst du mir ernsthaft 
erzählen dass das Daten von derselben Messung sind? Dann bleibt noch das 
Problem, dass dort halt nur 20kSa drin sind und nicht die 100kSa, da 
kann ich mit keiner Software der Welt was dran ändern. Du schon, wenn du 
die Export Optionen richtig setzt.

> versuche es dann selbst nochmal zu konvertieren.
Das muss nicht sein, ich kann beide benutzen und dann eine ordentliche 
Version hochladen. Die MSD ist nur eine CSV mit anderem Header, der 
Inhalt ist gleich aufgebaut. Dass es trotzdem ein völlig anderer Inhalt 
ist verwirrt schon etwas.

Daniel A. schrieb:
> Das hast du falsch verstanden.
kann gut sein. in deinem Screenshot wiederholen sich Gruppen von 6 byte, 
in der MSD Datei bilden 8 9N1 Übertragungen eine Gruppe. Entweder zeigt 
dein Screenshot eine andere Messung, oder es fehlen Daten, oder ich habe 
das falsch verstanden und der Screenshot enthält nicht die Daten die ich 
denke.

Yalu X. schrieb:
> und 2kS/s in der CSV-Datei
die enthält trotzdem einen gültigen UART mit 9N1 oder 10N1 und 1.92 
kBaud (nicht 19.2k). Das ist aber schon alles, mehr hat der Inhalt nicht 
mit dem Rest zu tun.

EDIT:
mein aktuelles Script im Anhang, es nimmt als Parameter ein oder mehrere 
Dateinamen mit Endung (CSV oder MSD) und gibt ein VCD Datei (Value 
change dump, nur Kanal 0, für mich zur Anzeige) und eine TXT Datei mit 
den UART Daten aus. Konfiguration der Parameter findet noch im Script 
selber statt, beim Testen war das einfacher.

: Bearbeitet durch User
von Daniel A. (daniel_a32)


Angehängte Dateien:

Lesenswert?

K. S. schrieb:
> Guck doch einfach mal auf die Bilder vom mir fünf Posts weiter oben. das
> sind die Daten aus der CSV und MSD unverändert. willst du mir ernsthaft
> erzählen dass das Daten von derselben Messung sind? Dann bleibt noch das
> Problem, dass dort halt nur 20kSa drin sind und nicht die 100kSa, da
> kann ich mit keiner Software der Welt was dran ändern. Du schon, wenn du
> die Export Optionen richtig setzt.
>
>> versuche es dann selbst nochmal zu konvertieren.
> Das muss nicht sein, ich kann beide benutzen und dann eine ordentliche
> Version hochladen. Die MSD ist nur eine CSV mit anderem Header, der
> Inhalt ist gleich aufgebaut. Dass es trotzdem ein völlig anderer Inhalt
> ist verwirrt schon etwas.

Es stimmt, dass die CSV und MSD unterschiedlich sind. Woran das liegt 
kann ich dir leider nicht sagen. In kürze kann ich wieder an den 
Logik-Analyzer und dann checke ich die Daten bevor ich sie hoch lade.

Im Anhang findest du nun ein Bild von einem Low-Bit mit einem anderen 
Oszi dem ich mehr vertraue.

Bit-Low Zeit: 52µs
Frequenz

Ich denke also, dass es 19200 Baud sind. Korrigiert mich bitte wenn ich 
falsch liege.

K. S. schrieb:
> mein aktuelles Script im Anhang, es nimmt als Parameter ein oder mehrere
> Dateinamen mit Endung (CSV oder MSD) und gibt ein VCD Datei (Value
> change dump, nur Kanal 0, für mich zur Anzeige) und eine TXT Datei mit
> den UART Daten aus. Konfiguration der Parameter findet noch im Script
> selber statt, beim Testen war das einfacher.

Welches Programm nutzt du zum weiteren Analysieren der Daten? Sieht ein 
bisschen einfacher aus als das was ich gerade probiere.

von Daniel A. (daniel_a32)


Angehängte Dateien:

Lesenswert?

Daten sind nun neu aufgenommen und ohne Änderung am Programm als MSD und 
CSV Datei gespeichert worden.
Samplerate war 100kS/s, 1mS/div

von K. S. (the_yrr)


Angehängte Dateien:

Lesenswert?

Wunderbar, jetzt kann man was erkennen.


Daniel A. schrieb:
> Welches Programm nutzt du zum weiteren Analysieren der Daten? Sieht ein
> bisschen einfacher aus als das was ich gerade probiere.
zum Anzeigen/ testen benutze ich Pulseview, ist open source, kann aber 
mit den etwas kompliziert aufgebauten MSD/CSV nichts anfangen, daher 
konvertier ich nach VCD.

Dasselbe Script kann mit den richtigen Einstellungen (L15: timescale = 
10, L29: UART_bit_cnt = 9 und L31: UART_baud = 5.2) auch direkt UART 
Daten als Hex ausgeben. Frame Error (Stop bit = low) gibt es auch aus. 
Hier mal die Ausgabe von deinem Teil Daten, hat mit runterladen ca. 30 
Sekunden gedauert:

time:   , MSB, LSB first
 1.000ms, 011, 110
 1.630ms, 100, 001
 2.250ms, 140, 005
 2.880ms, 000, 000
 3.500ms, 0D0, 016
 4.300ms, 000, 000
 4.920ms, 001, 100
 5.480ms, 000, 000

Jetzt zum eigentlichen Problem, um da irgendeine Chance zu haben etwas 
zu entschlüsseln bräuchte man mehr Daten von bekannten Zuständen, am 
Besten jeweils nur einen oder alle Motoren gleichzeitig ändern. Außerdem 
wäre es gut wenn du die Initialisierung mitschneiden könntest, die 
könnte auch wichtig sein für die Funktion.

Die alte MSD enthält drei mal dieselben Daten wie die Neue, alle 20ms 
wiederholt.

Da das ganze Paket nur 72 Bit enthält wird es schwierig für über 60 
Motoren (wie viele sind es denn genau?) mehr als an/aus zu übertragen. 
Interessant wäre wie viele Zustände/Geschwindigkeiten man denn 
einstellen kann, oder wird nur eine Sollposition vorgegeben und den Rest 
macht der Treiber?


kannst du nochmals 1-2 Bilder von der Platine machen, aber diesmal bitte 
so scharf dass man auch was lesen kann. bis jetzt sehe ich den Pic, 
mcp256, 3 Shift register und 4 ULN2003A. das macht ohne Multiplexing 
aber beim besten willen nur 32 Motoren und auch nur unidirektional, eher 
24 da zwei ULN nur 4 Ausgänge sichtbar belegt haben und es nur 3 Shift 
register gibt. Und Multiplexing ist mit ULN's auch nicht drin. schreib 
mal so viel dazu was das Teil kann wie du weißt, das hat erheblichen 
Einfluss auf die Menge der Übertragenen Daten udn damit auch auf das 
Format.

: Bearbeitet durch User
von Daniel A. (daniel_a32)


Angehängte Dateien:

Lesenswert?

K. S. schrieb:
> Dasselbe Script kann mit den richtigen Einstellungen (L15: timescale =
> 10, L29: UART_bit_cnt = 9 und L31: UART_baud = 5.2) auch direkt UART
> Daten als Hex ausgeben. Frame Error (Stop bit = low) gibt es auch aus.
> Hier mal die Ausgabe von deinem Teil Daten, hat mit runterladen ca. 30
> Sekunden gedauert:
>
> time:   , MSB, LSB first
>  1.000ms, 011, 110
>  1.630ms, 100, 001
>  2.250ms, 140, 005
>  2.880ms, 000, 000
>  3.500ms, 0D0, 016
>  4.300ms, 000, 000
>  4.920ms, 001, 100
>  5.480ms, 000, 000

Vielen Dank. Das hilft mir zumindest schon mal die Daten auf dem STM32 
zu verifizieren.
Bin gerade dabei ein UART Interface über DMA zu programmieren, damit ich 
einen Analyzer in Python schreiben kann.
Mein nächstes Ziel wird es sein alle unterschiedlichen Codes 
rauszufinden, indem ich die Funktion triggere und das Kommando somit 
zuweisen kann.
Mit dem Datenstream im 50Hz Takt tue ich mir mit den jetzigen Werkzeugen 
sehr schwer.

K. S. schrieb:
> Da das ganze Paket nur 72 Bit enthält wird es schwierig für über 60
> Motoren (wie viele sind es denn genau?) mehr als an/aus zu übertragen.
> Interessant wäre wie viele Zustände/Geschwindigkeiten man denn
> einstellen kann, oder wird nur eine Sollposition vorgegeben und den Rest
> macht der Treiber?

Die Funktionsweise und den Aufbau hab ich weiter oben schon beschrieben. 
Neues Frontalbild ist im Anhang. Hab leider von der Rückseite gerade 
kein Foto, das ausbauen ist nicht so einfach...
Daniel A. schrieb:
> Vllt. hilft die Funktionsbeschreibung ein wenig bei der Auflösung:
> - 8 High Side Treiber
> - 10 Low Side Treiber
> - 2 digitale Eingänge für Lichtschranke (Signal, Error)
> - 2 Analogeingänge
> - laut Beschreibung 2x RS485 Schnittstelle (jedoch mehrere Abweichungen
> bei der Pin Belegung im Schaltplan, also nicht glaubwürdig)

Verbaut ist das Teil in einem Snackautomat, die Treiberkarte steuert 
einen 24VDC Motor mit max. 200mA. Da sich der Motor nur 1 runde Drehen 
darf, unterbricht ein Kontakt sehr kurz 2x pro Umdrehung den Stromkreis. 
Meine Vermutung ist, dass der PIC den Strom misst und somit den 
Schaltpunkt detektiert.

Unterschiedliche Motorströme kann ich mir aufgrund des elektrischen 
Aufbaus nicht vorstellen, da keine PWM-Nutzung ersichtlich ist. High und 
Low Side sind mit ULN2003 ausgeführt. Auf der High-Side Schalten 
Transistoren. Die Steuersignale kommen von 3 Stk. 8-Bit Shift Register.

Ich habe schon eine Ansteuerplatine eines anderen Herstellers mit 
parallel Bus (ähnlich SRAM) gehackt. Dort war es ähnlich aufgebaut, aber 
die Adressen und Funktionsweise konnte ich mir damals aus der 
Verschaltung rauslesen. Der PIC ist diesmal eine richtige Spaßbremse :-(

Meine Vermutung ist daher, dass entweder der Wert der anzusteuernden 
Position, oder die Reihe und Spalte übergeben werden.
Im Grunde ist es egal, es erzeugt beides ein eindeutige Bit-Muster das 
man der Position zuweisen kann.
Bei dieser Anlage kann auch immer nur eine Reihe aktiv sein, 
normalerweise aber mehrere Motoren pro Reihe.
Doppelspiralen, für die großen Produkte, sind bei diesem Gerät aber mit 
Zahnrädern mechanisch gekoppelt, sodass in diesem Fall nur 1 Motor 
verbaut ist.

Ich denke daher, dass sich der Wertebereich zwischen 1 und 80 bewegen 
wird, oder die Reihe als Wert von 1-8 (4 Bit) und die Spalte als Wert 
von 1-10 (4 Bit). Dies könnte daher in einem Byte abgebildet werden.

Die zyklische Kommunikation deute ich als Statusabfrage des 
Lichtgitters. Das hängt nämlich auch noch auf diesem Board.
Das Lichtgitter befindet sich im untersten Bereich der Fallöffnung um 
das Produkt zu detektieren. Bei anderen Geräten hat diese Aufgabe auch 
immer ein PIC übernommen, der den Zustand speichert, welcher vom Master 
wieder zurückgesetzt werden muss.

Der nötige Befehlssatz würde daher meiner Meinung nach lauten:

- Motor ansteuern -> mit Reihen und Spaltenanwahl (2x 4Bit) oder mit 
Motoranwahl (6 Bit)
- Abfrage Motorstatus (dreht, steht, Fehler, ...)
- Lichtschranke abfragen
- Lichtschranke zurücksetzen
- Statusabfrage der Treiberkarte (eventuell nur ein Live Bit)
- Abfragen der Analogeingänge

Da es elektrisch ein Multislave System ist, denke ich auch, dass eine 
Adressierung vorhanden ist.

von K. S. (the_yrr)


Lesenswert?

das hilft schon mal sehr viel weiter beim Verstehen. Und wobei benötigst 
du jetztt genau Hilfe?
kannst du z.b. 1-2 Sekunden lang Daten (mit dem Oszi/LA) aufnehmen und 
einige Datensätze + Ereignis hier teilen? sobald das ungefähre 
Datenformat entschlüsselt ist schreibt sich so ein Script zum Auswerten 
deutlich leichter.
Wie sieht es mit den Antworten von der Platine aus, sind die interessant 
bzw. kannst du die falls ja auch aufnehmen?

von Daniel A. (daniel_a32)


Lesenswert?

K. S. schrieb:
> kannst du z.b. 1-2 Sekunden lang Daten (mit dem Oszi/LA) aufnehmen und
> einige Datensätze + Ereignis hier teilen? sobald das ungefähre
> Datenformat entschlüsselt ist schreibt sich so ein Script zum Auswerten
> deutlich leichter.

Endlich habe ich es geschafft mit dem STM32 etwas zu empfangen:
Mit folgenden Einstellungen bekomme ich zyklische Daten:

19200 Baud
9 Bit
2 Stop Bit

Die Datenfolge lautet wie folgt und deckt sich mit der Analyse von dir:

0x110
0x001
0x005
0x000
0x016
0x000
0x100
0x000

Leider stoppt die Übertragung nach ca. 960 Bytes und startet nach einer 
undefinierbaren Zeit wieder. Ich lese es mit folgendem Code aus:
1
  while (1)
2
  {
3
    /* USER CODE END WHILE */
4
5
    /* USER CODE BEGIN 3 */
6
    uart1_status = HAL_UART_Receive(&huart1,(uint16_t*) &ringbuffer, 8, 1000);
7
8
    if(uart1_status == HAL_TIMEOUT){
9
     for(int i=0;i<8;i++){
10
       TX_Buffer[i]= ringbuffer[i] & 0xFF;
11
     }
12
     HAL_UART_Transmit(&huart3, (uint8_t *)&TX_Buffer, 10, 0xFFFF);
13
14
15
16
    }
17
  }

Es hat dabei keine Rolle gespielt ob ich 1 Byte oder 8 Byte auslese. Ich 
stricke daher gerade ein Programm mit DMA Zugriff.

von Daniel A. (daniel_a32)


Lesenswert?

Mittels eines Sniffer Programms habe ich es jetzt geschafft, die 
unnützen Statusabfragen zu filtern und nur die getriggerten Kommandos 
auszugeben.

Durch das ansteuern der Motoren konnte ich folgende Daten bekommen:
1
Motor #10: 0x110 0x83 0x01 0x00 0x04 0x60 0x50 0x48 0x100 
2
Motor #12: 0x110 0x83 0x01 0x00 0x10 0x60 0x50 0x54 0x100
3
Motor #14: 0x110 0x83 0x01 0x00 0x40 0x60 0x50 0x84 0x100
4
Motor #16: 0x110 0x83 0x01 0x00 0x01 0x50 0x50 0x35 0x100
5
Motor #18: 0x110 0x83 0x01 0x00 0x10 0x50 0x50 0x44 0x100
6
Motor #20: 0x110 0x83 0x01 0x00 0x40 0x50 0x50 0x74 0x100
7
Motor #22: 0x110 0x83 0x01 0x00 0x01 0x40 0x50 0x25 0x100
8
Motor #24: 0x110 0x83 0x01 0x00 0x04 0x40 0x50 0x28 0x100
9
Motor #26: 0x110 0x83 0x01 0x00 0x10 0x40 0x50 0x34 0x100
10
Motor #28: 0x110 0x83 0x01 0x00 0x40 0x40 0x50 0x64 0x100
11
Motor #30: 0x110 0x83 0x01 0x00 0x02 0x30 0x50 0x16 0x100
12
Motor #31: 0x110 0x83 0x01 0x00 0x10 0x30 0x50 0x24 0x100
13
Motor #32: 0x110 0x83 0x01 0x00 0x02 0x20 0x50 0x06 0x100
14
Motor #33: 0x110 0x83 0x01 0x00 0x04 0x20 0x50 0x08 0x100
15
Motor #34: 0x110 0x83 0x01 0x00 0x20 0x20 0x50 0x24 0x100
16
Motor #35: 0x110 0x83 0x01 0x00 0x40 0x20 0x50 0x44 0x100
17
Motor #36: 0x110 0x83 0x01 0x00 0x80 0x20 0x50 0x84 0x100
18
Motor #37: 0x110 0x83 0x01 0x00 0x01 0x10 0x50 0xf5 0x100
19
Motor #38: 0x110 0x83 0x01 0x00 0x02 0x10 0x50 0xf6 0x100
20
Motor #39: 0x110 0x83 0x01 0x00 0x80 0x10 0x50 0x74 0x100
21
22
Und bin zu folgender Schlussfolgerung gekommen:
23
24
          |START|Command & Addr| Col| Row| Stat|CRC| END |  
25
26
Byte 1: Start (0x110)
27
Byte 2: Schreiben oder Lesen (0x83 = Write, 0x01 = Read)
28
Byte 3: Eventuell Steuerbyte (0x01 = bei Motoren ansteuern, 0x05 bei Licht an, 0x04 bei Licht aus)
29
Byte 4: immer null bei Motoransteuerung
30
Byte 5: Spaltenanwahl (X)
31
Byte 6: Reihenanwahl (Y)
32
Byte 7: immer 0xx50 bei Motoransteuerug, eventuell bereits response des Motortreibers
33
Byte 8: CRC Prüfbyte
34
Byte 9: Ende, eventuell vom Master
Da ich in ein laufendes System sniffe, kann ich noch nicht genau sagen 
ob Byte 7 oder 8 das Ende der Master Nachricht ist

Die Ansteuerung der Reihen und Spalten kann man aber schön erkennen. Die 
Plätze sind wie erwartet binär Codiert entsprechend dem mechanischen 
Aufbau.

Nach jeder Nachricht kommt immer die selbe Nachricht, deren Bedeutung 
ist noch nicht kenne:
1
0x110 0x01 x0104 0x0 
2
0x110 0x01 
3
0x110 0x01
Danach oftmals noch diese Nachricht:
1
0x110 0x01 0x04 0x00 0x15 0x4 0x104 0x0
Wenn ich das Licht eingeschaltet ist dann sieht die Nachricht wie folgt 
aus:
1
0x110 0x01 0x05 0x00 0x15 0x4 0x104 0x0

Welcher Teilnehmer was sendet ist hier noch nicht geklärt, daher ist der 
Teil noch ein Rätsel für mich. Eventuell wird einer von euch daraus 
schlau.

Als ich versehentlich einen Einlernmodus gestartet habe wurde folgendes 
Kommando gesendet:
1
0x110 0x83 0x01 0x00 0x01 0x60 0x50 0x45 0x100

Danach kam sehr oft bis zum Ende des Einlernens folgende Folge:
1
0x110 0x01 
2
0x110 0x01
3
0x110 0x15 0x01 0x04 0x00 0x15 0x04 0x104 0x0

und 1x die gleiche Folge mit 0x105 statt 0x104 beim vorletzten Byte.

von K. S. (the_yrr)


Lesenswert?

Daniel A. schrieb:
> Welcher Teilnehmer was sendet ist hier noch nicht geklärt, daher ist der
> Teil noch ein Rätsel für mich.
wo misst du denn? ein CAN Bus hat einen Abschlusswiderstand,  wenn ich 
mich nicht täusche 120Ohm. Je nachdem ob/was für Abschlusswiderstände 
wirklich vorhanden sind und was für Pegel jetzt vorhanden sind kannst du 
auch einen kleinen Widerstand (evt. einige 10 Ohm) oder zwei 
antiparallele Dioden (schottky Diode wäre besser) in den Signalweg 
einschleifen, dann erkennt man mit einem Oszi anhand der Pegel wer 
sendet und wer empfängt.

Kannst du nicht auch die TX/RX Pins zum Pic messen, da sollte doch 
theoretisch dasselbe rauskommen?

EDIT:

ich hab noch ne gute Nachricht:
ich hab mal deine daten in "test_data.txt" gespeichert und folgendes 
gemacht:
1
with open("test_data.txt", "r") as f:
2
  for l in f:
3
    if "#END" in l:
4
      break
5
      #end here
6
    x = 0
7
    for i in l.split(" ")[3:-2]:
8
      if not i:
9
        continue
10
      else:
11
        x += int(i, 16)
12
    h = int(l.split(" ")[-2],16)
13
    print("{0:2X}, {1:2X}, diff: {2:2X}".format(((x+15) % 255), h, ((x+15) % 255 - h)), end='')
14
    # end for i in l
15
    print("\n", end='')
16
    #print(" ", end='')
17
  #end for l in f
18
#end with open

das Ergebnis (alle zahlen in hex, aber ohne 0x davor):
(berechnet, "CRC", differenz)
48, 48, diff:  0
54, 54, diff:  0
84, 84, diff:  0
35, 35, diff:  0
44, 44, diff:  0
74, 74, diff:  0
25, 25, diff:  0
28, 28, diff:  0
34, 34, diff:  0
64, 64, diff:  0
16, 16, diff:  0
24, 24, diff:  0
 6,  6, diff:  0
 8,  8, diff:  0
24, 24, diff:  0
44, 44, diff:  0
84, 84, diff:  0
F4, F5, diff: -1
F5, F6, diff: -1
74, 74, diff:  0

irgendwo ist noch ein kleiner Fehler im Code oder bei der Aufnahme der 
Daten passiert.

der "CRC" scheint eine Summe von 0x83 bis 0x50 jeweils inkl., dann +15, 
dann mod 255 zu sein.

wer sendet ist damit auch klar, außer den 0x00 müsste alles von dem 
kommen der auch die Checksumme berechnet. Natürlich könnte die 
Checksumme auch über empfangene Daten gehen, wäre aber etwas 
ungewöhnlich.

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Nun ja ein Byte mit 0x110 wäre aber schon etwas seltsam. Das wird wohl 
eher sowas sein:
0x01 <Len> <der Rest>

Thomas

von K. S. (the_yrr)


Lesenswert?

Daniel A. schrieb:
> Als ich versehentlich einen Einlernmodus gestartet habe wurde folgendes
> Kommando gesendet:
> 0x110 0x83 0x01 0x00 0x01 0x60 0x50 0x45 0x100
die 0x45 stimmen auch

Daniel A. schrieb:
> Danach kam sehr oft bis zum Ende des Einlernens folgende Folge:0x110
> 0x01
> 0x110 0x01
> 0x110 0x15 0x01 0x04 0x00 0x15 0x04 0x104 0x0
daraus kann ich noch keinen Sinn machen, da scheint keine erkennbare 
Checksum drin zu sein. Das passt auch nicht zu dem normalen "Muster"

Die idle Übertragung scheint auch keien Checksum zu haben, das Feld ist 
dort 0x00:
0x110 0x01 0x05 0x00 0x16 0x00 0x100 0x00

Obwohl das erste und letzte "Byte" 9Bit lang sind, scheint alles 
dazwischen inkl. der Checksumme nur 8 bit lang zu sein.

von Daniel A. (daniel_a32)


Lesenswert?

Thomas Z. schrieb:
> Nun ja ein Byte mit 0x110 wäre aber schon etwas seltsam. Das wird wohl
> eher sowas sein:
> 0x01 <Len> <der Rest>
>
> Thomas

Das System arbeitet mit 9 Bit und wird von einem STM32 in 8Bit 
konvertiert und als Zeichenfolge am PC ausgegeben.

0x110 ist somit richtig.

K. S. schrieb:
> wer sendet ist damit auch klar, außer den 0x00 müsste alles von dem
> kommen der auch die Checksumme berechnet. Natürlich könnte die
> Checksumme auch über empfangene Daten gehen, wäre aber etwas
> ungewöhnlich.

In der Tat ist das ganze ein bisschen ungewöhnlich aufgebaut, hab auch 
noch nie so ein "interessantes" Protokoll und Handshake gesehen.

Ich hab heute den schnellsten Weg gewählt und einfach den Client 
abgeschlossen und einen Abschlusswiderstand am CAN Sniffer aktiviert.

Überraschenderweise geht der Master-Request bis inkl. 0x50. Also wie 
folgt:
1
0x110 0x83 0x01 0x00 0x04 0x60 0x50

Die Antwort ist somit:
1
0x48 0x100

Es wird also wirklich der CRC im Client berechnet und zurückgeschickt. 
Scheint als Art Acknowledge zu dienen, denn das Kommando wird vom Master 
umgehend nochmal gesendet. Die Zeitverzögerung konnte ich mit dem 
jetzigen System noch nicht aufzeichnen. Ist aber denke ich nicht weiter 
von Belang.

K. S. schrieb:
> irgendwo ist noch ein kleiner Fehler im Code oder bei der Aufnahme der
> Daten passiert.

Das kann gut sein, bin noch bis 01:30 gesessen damit ich vernünftige 
Daten bekommen habe und hab sie dann von Hand übertragen. Das Hirn war 
willig doch die Augen schon schwach :-P

Zudem habe ich zwischenzeitlich keine Daten reinbekommen und sinnlos 
Fehler gesucht, bis ich darauf gekommen bin, dass im Wartungsmodus keine 
zyklische Übertragung stattfindet.

von Daniel A. (daniel_a32)


Lesenswert?

Mit abgestecktem Client bekomme ich nun folgende zyklische Nachricht:
1
0x110 0x01 0x05 0x00 0x16 0x110 0x01 0x110 0x00 0x01 0x05 0x0 0x16 0x110 0x16 0x110 0x01 0x05 0x00 ....
Die Checksum von 0x16 passt auf die ersten 4 Bytes. Danach kommt wieder 
nur wirres Zeug.

Könnten abgebrochene Requests sein, bin mir nicht 100% sicher, da ich 
dem STM32 auch nicht so recht vertraue. Könnte sein, dass das Schreiben 
das Einlesen zu lang blockiert und Bytes verloren gehen.

von K. S. (the_yrr)


Lesenswert?

Alternativ könnte auch alles 8N1 sein, nur die Datenpakete in der Mitte 
haben alle eine Zero Parity, das würde erklären warum die länger sind. 
Das würde auch erklären warum die Checksumme und Daten nur mit 8 bit 
laufen.

Aus den ersten  0x110 würden dann 0x10
Aus den letzten 0x100 würden dann 0x00
das höchste Bit wäre dann jeweils schon ein fehlinterpretiertes Stop 
Bit.

Wenn du die Zusatzfunktionen wie Anlernen oder Licht nicht brauchst ist 
das Problem jetzt gelößt. Falls doch müsstest auch da mal die Richtung 
rausfinden, denn die Pakete sind anders aufgebaut bzw. haben denke ich 
keine Checksumme.

von S. R. (svenska)


Lesenswert?

Ich tippe ja schlicht darauf, dass ein 8 Bit-Protokoll verwendet wird 
und das neunte Bit fürs Framing benutzt wird.

von Daniel A. (daniel_a32)


Lesenswert?

Der STM32 versteht nur 9N2, hab auch andere Varianten ausprobiert (8N1, 
8N2, 9N1, 9N1.5).

Alle 8 Bit Einstellungen haben garnicht funktioniert. Bei 9N hat alles 
ab 1 Stopp-Bit funktioniert. Am besten geht es mit 9N2. Die Daten sind 
konstant und man erkennt ein Muster bei den getriggerten Daten.

Dass die Checksumme nur mit 8 Bit läuft ist denke ich ist 
Softwareabhängig. Eventuell wollte sich der Programmierer nicht die 
Arbeit antuen und noch das 9.Bit aus einer 16 Bit Zahl zu extrahieren um 
es auf das USART Register zu schreiben. ;-)

S. R. schrieb:
> Ich tippe ja schlicht darauf, dass ein 8 Bit-Protokoll verwendet
> wird
> und das neunte Bit fürs Framing benutzt wird.

Das kann der PIC16F1619 nicht, zumindest habe ich nichts in diese 
Richtung im Datenblatt gefunden.

von S. R. (svenska)


Lesenswert?

Daniel A. schrieb:
> Das kann der PIC16F1619 nicht, zumindest habe ich nichts in diese
> Richtung im Datenblatt gefunden.

Wie das neunte Bit zu interpretieren ist, entscheidet die Software 
dadrin. Ich dachte an sowas wie eine Unterscheidung "Befehl/Daten" 
(sieht man an Displays öfter), oder ein Synchronisations-Flag (= 
Framing).

Wenn das so ist, dann trägt dieses Bit keine Daten im eigentlichen 
Sinne. Das wiederum deckt sich mit der sinnigen Annahme, dass die 
gesamte Verarbeitung nur 8-bittig ist, inklusive Checksum etc.

: Bearbeitet durch User
von K. S. (the_yrr)


Lesenswert?

S. R. schrieb:
> oder ein Synchronisations-Flag (=
> Framing).
würde von allem bisher noch am meisten Sinn ergeben, der Master beginnt 
mit einem 0x110 als Start, und der Slave endet mit einem 0x100, alle 
dazwischen haben das neunte bit nicht gesetzt.

> Das wiederum deckt sich mit der sinnigen Annahme, dass die
> gesamte Verarbeitung nur 8-bittig ist, inklusive Checksum etc.
das ist keine Annahme, das ist sehr sicher. Alle Nutzdaten die ich bis 
jetzt gesehen habe sind nur 8 bit, und auch die Checksumme funktioniert 
nur mit 8 bit, bei 9bit kommt nicht das Richtige raus.

Nur wie genau die berechnet wird weiß ich nicht:

Summe aller Daten + 0x0F mod 0xFF funktioniert.
aber auch alle Daten inkl. der 8bit von 0x110 (also 0x10) - 1 mod 0xFF 
funktioniert.

Hier passt was nicht:

Daniel A. schrieb:
> Mit abgestecktem Client bekomme ich nun folgende zyklische Nachricht:
> Die Checksum von 0x16 passt auf die ersten 4 Bytes
Daniel A. schrieb:
> Es wird also wirklich der CRC im Client berechnet und zurückgeschickt.
erstens müsste das 0x15 sein, und zweitens kann der Client keine 
Checksum zurücksenden wenn er abgesteckt ist. Das wird nur Zufall sein 
dass 0x16 fast passt.

Daniel A. schrieb:
> Mit abgestecktem Client bekomme ich nun folgende zyklische Nachricht:
> 0x110 0x01 0x05 0x00 0x16
das ist der Anfang der Idle Übertragung, danach würde vermutlich die 
Antwort vom Slave 0x00 0x100 0x00 sein, oder zumindest ein Teil davon.


Man sollte die Checksumme auch nicht CRC nennen, denn es ist ja wirklich 
nur eine Summe und nichts weiter. Ein CRC ist es auf jeden Fall nicht.

Was auch noch fehlt ist die Initialisierungs Sequenz, falls es eine 
gibt. Irgendwoher muss der Master ja die Adresse(n) herbekommen, wenn da 
wirklich wie behauptet ein Multi Slave System ist und die nicht alle 
hardcoded sind.

von Daniel A. (daniel_a32)


Angehängte Dateien:

Lesenswert?

Bin nun beim nächsten Schritt und sende ein paar Bytes in die 
Treiberkarte rein. Der echte Master wurde abgeklemmt und der 
Abschlusswiderstand auf meiner CAN Karte aktiviert.

Mit dem folgender Zeichenfolge hat es nicht funktioniert:
1
0x110 0x83 0x01 0x00 0x04 0x60 0x50

Das was am Bus rauskommt sieht am Oszi schon mal gut aus. Leider bewegt 
sich nichts und ich bekomme keine Rückantwort.

Also wieder zurück zum Analysieren
Habe nun einen kompletten Dump im Einrichtebetrieb gemacht und dabei die 
Motoren der ersten und zweiten Etage nach der Reihe angesteuert. Die 
fünfte Ansteuerung schlug fehl, weil kein Motor montiert war. Es sollte 
daher auch eine Fehlermeldung zurückkommen.

Die restlichen Ansteuerungen wurden erfolgreich abgeschlossen.

Der erste Wert in dump.txt ist der Timestamp (nach Einschalten) und 
danach kommt der Hex-Wert.

Bis zum Zeitpunkt 10010ms vermute ich einen Overflow Error beim USART. 
Der Timeout der Receive Funktion ist 1sec, danach wird bei TIMEOUT das 
Overflow Flag gelöscht und neu empfangen. Es dauert immer ein paar Bytes 
bis er wieder im Takt ist.

Ich lese sicherheitshalber 1kB in den RAM bevor ich sie übertrage.

von Daniel A. (daniel_a32)


Angehängte Dateien:

Lesenswert?

ES IST GESCHAFFT => Mein Controller kann nun einen Motor ansteuern

Es müssen alle 8 Byte gesendet werden. Von 0x110 bis zur Checksumme 
kommt alles vom Master. Der Client sendet nur 1 Byte zurück (0x110).

Jetzt muss ich nur noch die Bedeutung der Statusbits rausfinden.

: Bearbeitet durch User
von Daniel A. (daniel_a32)


Angehängte Dateien:

Lesenswert?

Nachdem ich die Spiralen ansteuern kann kümmere ich mich jetzt um den 
Lift. Dieser wird ebenfalls über einen seriellen Bus angesteuert.

Laut Anleitung ein I2C Bus. Ich hab die Platine dennoch demontiert und 
unter die Lupe genommen.

Werde dafür einen neuen Thread anfangen. Dieses Problem ist für mich zu 
95% gelöst. Nur das Diagnose Kommando habe ich noch nicht genauer 
analysiert und ich weis noch nicht ob es eine Funktion gibt, die ohne 
längere Motordrehung das Vorhandensein des Motors zurückgeben kann. Wäre 
ein nettes Feature zum Einlernen der Positionen.

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
Noch kein Account? Hier anmelden.