Hallo, ich habe ein Protokoll (Sony 9pin oder BVW75) : Communication Format The protocol is based on the EIA RS-422-A signal standard, usually at 38.4 kBit/s. The data are sent as 1 start bit + 8 data bits + 1 parity bit + 1 stop bit. Parity is odd: the bitwise sum of data bits 0 -7 and the parity bit is an odd number. Command Block Format The controlling device and the controlled device communicate through the interchange of command blocks. The bytes in each command block are assigned as follows: • CMD-1/DATA COUNT. CMD-1 is the upper 4 bits, DATA COUNT is the lower 4. • CMD-2. • DATA-1 up to DATA-N, where n is the value in data count • CHECKSUM CMD-1 Indicates the function and direction of the command, according to: 0 System control (Master->Slave) 1 Return for 0,2, or 4 of cmd-1 (Slave->Master) 2 Transport Control (Master->Slave) 4 Preset/Select control (Master->Slave) 6 Sense Request (Master->Slave) 7 Sense Return (Slave->Master) DATA COUNT Indicates the number of bytes ( max 15 ) inserted between CMD-2 and CHECKSUM CMD-2 Designates the command. Refer to the command table for definitions. Ex. CMD-1=0 and CMD-2=0C means LOCAL DISABLE. DATA-1 to DATA-N Data which correspond to those indicated by the command. Refer to the command table for data formats. CHECKSUM Lower eight bits of the sum of the bytes in the command block. Beispiele für Steuerbefehle gibts z.B. hier : https://www.drastic.tv/support-59/legacysoftwarehardware/72-miscellaneous-legacy/158-vvcr-422-serial-protocol Play wäre demnach hex 20 01 21 (21 ist checksum). Das ist aber nicht der ganze Befehl, es fehlt die Einleitung, also CMD-1. Und ich weiss nicht, wie ich das definiere. Vielen Dank (RS232 auf RS422 Umsetzung wird mit einem Startech Interface mit eigener Spannungsversorgung erledigt)
Zitat: "When the DATA COUNT is 0, no data is transmitted (the CMD1, CMD2 and checksum data bytes are still transmitted), ..." hex 20 01 21 ist demnach schon das komplette Kommando. Code ist 2 und Anzahl Datenbytes ist 0. Also nur CMD1, CMD2 und Checksumme. Sieht gut aus.
Wie kommst Du darauf, dass Du > Das ist aber nicht der ganze Befehl, es fehlt die Einleitung, > also CMD-1. Woraus leitest Du das ab?
Theor schrieb: > Zitat: "When the DATA COUNT is 0, no data is transmitted (the > CMD1, CMD2 > and checksum data bytes are still transmitted), ..." > > hex 20 01 21 ist demnach schon das komplette Kommando. Code ist 2 und > Anzahl Datenbytes ist 0. Also nur CMD1, CMD2 und Checksumme. > > Sieht gut aus. Aber 20 01 ist der eigentliche Befehl. Meiner Meinung fehlt da CMD-1 Und 20 01 21 hab ich schon zur Maschine gesendet, keine Reaktion. Was mich halt auch wundert, denn im Protokoll steht, dass auf einen gültigen Befehl ein ACK zurückgesendet wird. Ein ungültiger Befehl müsste ein NAK als Antwort haben. Der Receive Teil ist aber leer. Ich teste das mit hterm.
Kai L. schrieb: > Theor schrieb: >> Zitat: "When the DATA COUNT is 0, no data is transmitted (the >> CMD1, CMD2 >> and checksum data bytes are still transmitted), ..." >> >> hex 20 01 21 ist demnach schon das komplette Kommando. Code ist 2 und >> Anzahl Datenbytes ist 0. Also nur CMD1, CMD2 und Checksumme. >> >> Sieht gut aus. > > Aber 20 01 ist der eigentliche Befehl. > Meiner Meinung fehlt da CMD-1 > > [...] Ja. Schon. Lach. :-) Aber worauf gründet sich Deine Meinung? Das Dokument gibt das nicht her. Allein darauf, dass keine Reaktion erfolgt?
Es ist dann am besten erst mal die Übertragung zu prüfen und die Einstellungen von HTerm. Erst kürzlich hatte ich hier jemanden, der sich auch gewundert hat, das ihm die Gegenstelle nicht antwortet. Dabei war das Problem, dass er Hardware-Handshake eingestellt hatte.
Kai L. schrieb: > Theor schrieb: >> Zitat: "When the DATA COUNT is 0, no data is transmitted (the >> CMD1, CMD2 >> and checksum data bytes are still transmitted), ..." >> >> hex 20 01 21 ist demnach schon das komplette Kommando. Code ist 2 und >> Anzahl Datenbytes ist 0. Also nur CMD1, CMD2 und Checksumme. >> >> Sieht gut aus. > > Aber 20 01 ist der eigentliche Befehl. > Meiner Meinung fehlt da CMD-1 > > [...] Komisch irgendwie. Es scheint mir ganz klar zu sein: 20 ist CMD-1 - Commando ist '2' und Länge ist 0. 01 ist CMD-2 21 ist die Checksumme Das entspricht völlig der Beschreibung, oder?
Ach herrje, dann ist 01 das Play Kommando und 20 ist schon CMD-1. Verdammt. OK, dann muss der Fehler in der Config von hterm oder der Kabelbelegung liegen. Ich hab hterm nur gestartet, 38400 8N1 parity odd eingestellt und meine drei Hexzahlen weggeschickt.
Mach vielleicht ein Bildschirmfoto von HTerm. Dann können wir auch mal einen Blick darauf werfen.
Kai L. schrieb: > Ach herrje, dann ist 01 das Play Kommando und 20 ist schon CMD-1. > > Verdammt. > > [...] Lach. Naja. Deswegen habe ich insistiert, dass Du mal den Grund für Deine Vermutung schreibst. Wenn man das untersucht, kommt man meist auf den Denkfehler (den wir jetzt so auch nicht kennen). Aber die Vermutung, dass das schon das komplette Sequenz ist ist plausibel. Entweder Du hattest recht, dann wäre 20 01 21 aber nur ab CMD-2 (oder noch später) der Inhalt und 21 wäre nicht die Checksumme, weil man die ja noch nicht berechnen kann (oder auch nur wieder aufgrund von Vermutungen). Oder Du hattest unrecht, dann ist 20 01 21 völlig konsistent zur Beschreibung, weil die Checksumme stimmt und die Längenangabe in dem ersten Byte auch, falls es CMD-1 ist. Man muss nur (wenn Du mir diese zugegeben etwas überheblich klingende aber humorig gemeinte Bemerkung gestattest) mal logisch denken. :-)
Kai L. schrieb: > Ich hab hterm nur gestartet, 38400 8N1 parity odd eingestellt > und meine drei Hexzahlen weggeschickt. aber nicht dass Du 0x32 0x30 0x30 0x31 0x32 0x31 sendest, als '2'0'0'1'2'1'... Gelle?
fop schrieb: > Kai L. schrieb: >> 8N1 > > Moep - falsch > 8O1 ist gefordert Kai L. schrieb: > parity odd eingestellt
Leuchtungsgango B schrieb: > Kai L. schrieb: >> Ich hab hterm nur gestartet, 38400 8N1 parity odd eingestellt >> und meine drei Hexzahlen weggeschickt. > > aber nicht dass Du 0x32 0x30 0x30 0x31 0x32 0x31 sendest, als > '2'0'0'1'2'1'... > Gelle? Ich hab die Sendezeile in der Mitte von hterm auf hex umgestellt und dann 20 01 21 getippt. Sogar die Leerzeichen macht das Programm ja selbst. Das ist ok so, oder ?
Das heisst Du tippst die Zeichen manuell ein? Das kann von Sicht der Gegenstelle aus sehr sehr langsam sein. Wenn da mal nicht ein Timeout zuschlägt... schreib ein kleines DOS Programm, das die Zeichen programmatisch rüberschreibt, und nutze HTerm nur zum loggen.
Kai L. schrieb: > Ich hab die Sendezeile in der Mitte von hterm auf hex umgestellt und > dann 20 01 21 getippt. Hast Du bei "Send on Enter" auch "None" eingestellt? Sonst sendet HTerm noch zusätzliche Bytes. Eventuell solltest Du auch erstmal "00 11 11" (device type request) versuchen. RAc schrieb: > Das heisst Du tippst die Zeichen manuell ein? Das kann von Sicht der > Gegenstelle aus sehr sehr langsam sein. Wenn da mal nicht ein Timeout > zuschlägt... HTerm sendet erst, wenn man ihm sagt daß es das tun soll und dann die eingegebenen Zeichen/Bytes auch so schnell hintereinander wie es geht. Also wenn, dann ist das höchstens zu schnell.
Send on Enter steht auf None. Da hab ich auch schon mit CR und LF und CR/LF probiert. Ich hatte es auch mit Asend getestet und das Kommando 1, 5 und auch 10 mal gesendet. Kein Erfolg.
RAc schrieb: > Das heisst Du tippst die Zeichen manuell ein? Das kann von Sicht > der > Gegenstelle aus sehr sehr langsam sein. Wenn da mal nicht ein Timeout > zuschlägt... > > schreib ein kleines DOS Programm, das die Zeichen programmatisch > rüberschreibt, und nutze HTerm nur zum loggen. Dafür gäbe es ja eine Fehlermeldung, NAK Timeout oder so ähnlich. Ich hab aber bisher noch kein einziges Bit der Maschine empfangen. Nur als Gedankenmodell, wenn ich 8N1 anstatt 8O1 eingestellt hätte, würde das die Kommunikation komplett verhindern ?
Kai L. schrieb: > RAc schrieb: >> Das heisst Du tippst die Zeichen manuell ein? Das kann von Sicht >> der >> Gegenstelle aus sehr sehr langsam sein. Wenn da mal nicht ein Timeout >> zuschlägt... >> >> schreib ein kleines DOS Programm, das die Zeichen programmatisch >> rüberschreibt, und nutze HTerm nur zum loggen. > > Dafür gäbe es ja eine Fehlermeldung, NAK Timeout oder so ähnlich. > Ich hab aber bisher noch kein einziges Bit der Maschine empfangen. > Normalerweise nicht. Hängt natürlich vom Protokoll ab, aber Timeoutbestätigungen sind nicht die Regel, das würde auch die Kommunikation ziemlich durcheinanderwürfeln (auf seriellen Schnittstellen können immer mal wieder Zeichen verloren gehen, das wird normalerweise durch silen discarding und resync auf das nächste Paket gelöst). Oder sendest Du en bulk wie Kai es geschildert hat? > Nur als Gedankenmodell, wenn ich 8N1 anstatt 8O1 eingestellt hätte, > würde das die Kommunikation komplett verhindern ? Ja.
Angehängte Dateien:
-
20191104_233152.jpg
200 KB
So, weiter gehts. Hab jetzt so eine Betamax Maschine vor mir. Es wird ein Kabel verwendet, was mich verwirrt. Welche Leitungen braucht man bei RS422 ? Ich dachte beide Rx und beide Tx und GND. Das Kabel würde aber beide Rx, GND und RTS+ und CTS+ vom Interface nutzen. Beim Sony wirds noch übler, denn 5 ist ja beim Interface und beim Kabel GND, 5 ist aber beim Sony gar nicht genutzt.
> Hab jetzt so eine Betamax Maschine vor mir. Oh..backe..ne ich frag jetzt lieber nicht... > Das Kabel würde aber beide Rx, GND und RTS+ und CTS+ vom Interface > nutzen. Ist zwar sehr ungewoehnlich, aber ist ja auch Sony in ihrer besten Zeit. Und warum soll man nicht auch noch RTS und CTS nach 422 uebertragen. Dann brauchst du halt noch einen Pegelwandler mehr. > 5 ist aber beim Sony gar nicht genutzt. Irgendwo musst du aber GND haben, vielleicht der Kabelschirm? Die Information ist zwar in der differenziellen Uebertragung, aber GND ist notwendig damit deine Signale innerhalb des Bezugsfenster der Treiber bleiben. Olaf
GND bei der Sony Buchse ist ja im Foto zu sehen. Es gibt Common je Senderichtung und 1 und 9 sind Frame GND. Ich werd mir jetzt erstmal ein Kabel bauen, was nur Rx und Tx und GND berücksichtigt.
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.