Übertragungsprobleme beim VT520

Ich habe mein VT520 per USB-Adapter an ein Linux angeschlossen.

Bleibe ich bei 9600bit/s bleibt die Verbindung stabil. Stelle ich eine höhere Geschwindigkeit ein, bekomme ich immer Datensalat auf den Schirm, bei längeren Texten.

Beim Handshake habe ich sowohl Xon/Xoff, als auch DSR/DTR probiert. Jedoch hatten beide Optionen keine Veränderungen gebracht.

Als Kabel habe ich folgende Leitungen belegt...

            |  HP       | Conrad    |
Pin Adapter | Nullmodem | Nullmodem |
     09  25 |  09 Pin   |  09 Pin   |
------------+-----------+------------
GND  --  01 |  --  --   | --     -- |
RLSD 01  08 |  01  01   | 01,06  04 |
RXD  02  03 |  02  03   | 02     03 |
TXD  03  02 |  03  02   | 03     02 |
DTR  04  20 |  04  06   | 04  01,06 |
SGND 05  07 |  05  05   | 05     05 |
DSR  06  06 |  06  04   | 01,06  04 |
RTS  07  04 |  07  08   | 07     08 |
CTS  08  05 |  08  07   | 08     07 |
RI   09  22 |  09  09   | --    --  |
SPDI --  12 |  --  --   | --    --  |
SPD  --  23 |  --  --   | --    --  |

Im Internet fand ich noch eine weitere Möglichkeit hier (Variante 3)

Dort unterschied sich mein HP Kabel mit der Variante 02 am Pin 01, welcher dort nicht belegt war.

Ich hab jetzt auch zwei unterschiedliche USB-Adapter Probiert. Auch hier änderte sich nichts am Verhalten.

Hat vielleicht jemand eine schnellere Verbindungen als mit 9600bit/s mit einem Linux hinbekommen?

Zitat von Manawyrm

Zitat von echo

sowohl Xon/Xoff, als auch DSR/DTR

Wuerde ja eher klassisches CTS / RTS erwarten?

Das Terminal hat nur das was es hat. CTS/RTS hat es nicht

Zitat von Manawyrm

Ich mag unter Linux das Programm HTerm ganz gerne, ist leider Binaersoftware, aber erlaubt ziemlich gut, die ganzen Handshake-Leitungen und Parameter zu betueddeln und kann mit dem "Send File" auch ziemlich flott grosse Datenmengen uebertragen.

Vielleicht findest du damit eine funktionierende Konfig mit Flowcontrol?

Öh, wie installiere ich das auf mein Terminal?

Nein Spaß bei Seite. Danke, aber ich will ja das VT520 (echte Hardware) nutzen. Software-Emulationen hab ich, danke

Zitat von Manawyrm

HTerm ist kein Software-Terminal-Emulator, sondern eine Software zum Pruefen/Sprechen mit seriellen Schnittstellen.

Ich wollte hier vorgeschlagen, dass du die getty/agetty, etc. auf deinem Linux mal abschaltest und mittels HTerm direkt mit dem VT520 sprichst.

Wenn du die Flusskontrolle zwischen HTerm und dem VT520 dann am laufen hast, kannst du die getty/agetty, etc. Einstellungen dann entsprechend wie in HTerm hinterlegen.

Oh, dann hab ich nicht richtig gelesen. Sorry. Beihalt ich mal im Hinterkopf und schau mir das an, wenn sonst nichts an Vorschlägen kommt.

Danke.

Zitat von Manawyrm

Habe das gerade mal nachgelesen -- anscheinend wurde das erst in einer neueren Firmware-Version vom VT520 nachgeruestet.

Dein Linux erwartet mit ziemlicher Sicherheit aber CTS/RTS...

Also: Entweder besorgst du dir ne neuere Firmware fuer dein VT520 oder du stellst dein Linux/getty/etc. auf DSR/DTR.

Oh, es gibt Updates für das VT520?
Wo kann ich die herbekommen???

Aktuell ist Version 2.1 drauf.

PS:

ich fand folgede interessante Seite VT420/520 shell-scripts und Anweisungen

Zitat von JenGun

Zitat von echo

Hat vielleicht jemand eine schnellere Verbindungen als mit 9600bit/s mit einem Linux hinbekommen?

Hier VT520 an Linux-PC mit 38400 (allerdings mit "herkömmlichen" Kabel):

Code

Word Size: 8 bits
Parity: None
Stop Bits: 1
Transmit/Receive speed: 38.4K baud
Transmit/Receive flow control: both
Flow control threshold: Low (64)
Transmit rate limit: None
Fkey rate limit: 30 cps

Gleiche Einstellungen hier und es geht nicht.

Als Getty habe ich folgendes eingegeben:

/sbin/agetty -hL ttyUSB0 38400 vt520

Was sind den Herkömmliche Kabel für dich? Könntest du das mal durchklingeln? Hier könnte Tatsächlich der Hund begraben liegen.

hm, ich hätte schwören können, dass ich das auch ohne das "-h" probiert habe. Aber womöglich hat ich da kein Xon/Xoff an.

Aktuell gehts. Danke

Über einen Link zu nem Firmware-Update würde ich mich freuen.

Zitat von Manawyrm

Hier berichtet jemand darüber und schreibt auch von den Problemen mit der Flusskontrolle:
https://github.com/stylewarnin…ons/blob/master/dec-vt.md

Aus den Infos habe ich mal versucht die Kabelbelegung zu erstellen und so DSR/DTR als Flusskontrolle nutzen zu können:

      |  DEC    | 
      |Nullmodem|
      | 09 Pin  |
 -----+---------+-----
 GND  | --  --  | GND
 RLSD | 01  01  | RLSD
 RXD  | 02  03  | TXD
 TXD  | 03  02  | RXD
 DTR  | 04  07  | RTS
 SGND | 05  05  | SGND
 DSR  | 06  08  | CTS
 RTS  | 07  04  | DTR
 CTS  | 08  06  | DSR
 RI   | 09  09  | RI
 SPDI | --  --  | SPDI
 SPD  | --  --  | SPD

vielleicht kann jemand diese Leitungen kommentieren?

Vielleicht sind auch einige Leitungen unnötig?

PS:

Leitung 09 scheint unnötig zu sein. Laut Programmer Information (PDF) Seite 420 ist Pin 09 (Pin 22 auf nem 25er Buchse) nicht verbunden.

Hat Jemand über den MMJ Stecker eine Verbindung zu einem Linux aufbauen können?

Ich bin mir bei der Belegung unsicher...

    DEC
  Nullmodem
09pin   MMJ
---------------
RXD 02  02 TXD
TXD 03  05 RXD
GND 05  03 TXD-
GND 05  04 RXD-
RTS 07  01 DTR
CTS 08  06 DSR

Danke für die Zahlreichen Antworten.

Aber aktuell bin ich erst mal mit dem Ergebnis zufrieden. Sollte mich es nochmal Jucken würde ich mich mit dem MMJ Stecker beschäftigen, aber aktuell hab ich keinen RJ6 Stecker zur Hand und es läuft ja mit dem normalen.

Eigentlich hatte ich gedacht, dass ich ein RJ6 Kabel noch zuhause habe. Aber es stellte sich heraus, dass es ein RJ8 Stecker für Cisco-Switche ist...

Falls aber jemand eine VT520 mit Firmware größer als V2.1 hat, daran wäre ich interessiert. Wobei man hier erst mal herausfinden müsste, wie man dieses Extrahiert und in meines hochlädt. Aber ein Schritt nach dem Anderem.

Nochmals Danke für die vielen Meldungen!

Ich hab noch dieses Foto im Netz gefunden ...

https://i.ebayimg.com/images/g/YsQAAOSwUyZj7kJg/s-l1600.png

Dort ist die Beschriftung etwas schärfer und besser zu lesen.

Wäre echt toll, wenn man das Image auslesen könnte

Hat die Firmware 2.2A den die CTS/RTS Handshake-Option?

Ich wollte mal meine Fortschritte hier dokumentieren.

Ich habe eine Stabile Verbindung mit 38400 bits/s vom VT520 zu den Raspberry Pi Pinouts aufbauen können. Dazu muss die

"/boot/cmdline.txt"

console=serial0,38400 console=tty1 root=PARTUUID=edeab335-02 rootfstype=ext4 fsck.repair=yes rootwait

angepasst werden. Wichtig ist hierbei die "console=serial0,38400". Der Rest sollte schon drinnen stehen.

Hierdurch kann der Kernel Meldungen auf die Konsole ausgeben. Wer das nicht will, kann diese Änderung natürlich weg lassen.

Als nächstes wird in dem Ordner "/etc/systemd/system/serial-getty@ttyAMA0.service.d" die Datei "autologin.conf" mit den Werten Angelegt:

[Service]
ExecStart=
ExecStart=-/sbin/agetty --autologin <USER> --keep-baud 38400 %I vt520

Die erste Zeile "ExecStart=" ist wichtig, da sie die Defaults zurücksetzt. In meinem Falle habe ich ein Autologin eingebaut für einen user.

Bei Bedarf kann man noch die Datei "noclear.conf" mit diesem Inhalt anlegen:

[Service]
TTYVTDisallocate=no

so wird der Text beim Ausloggen nicht gelöscht. Da ich den Autologin habe ist dies glaub ich nicht so wichtig.

Anschließend habe ich noch unter dem Ordner "/etc/systemd/system/serial-getty.target.wants" einen Symbolischen Link erstellt

ls -al serial-getty@ttyAMA0.service 
lrwxrwxrwx 1 root root 41 Aug 16 20:19 serial-getty@ttyAMA0.service -> /lib/systemd/system/serial-getty@.service

Ob dieser nötig ist, weiß ich nicht. Systemd ist für mich eine Hassliebe. Sorry.

Was mich sehr lange aufgehalten hat, war, dass ich den Eintrag in der "/boot/cmdline.txt" nicht mit der "autologin.conf" abgeglichen hatte. Beide bit/s waren unterschiedlich, was mal lief und mal nicht und immer wieder für unschöne Fehler sorgte. Erst als ich an beiden Stellen den gleichen Wert hatte, liefs immer ohne Ärger.

Als nächstes Stellt man die Konsole auf die üblichen Werte ein

• Wortgröße: 8Bit
• Parität: Keine
• Stopbit: 1 Bit
• Sendegeschwindigkeit: 38400
• Empfangsgeschwindigkeit: Sendegeschwindigkeit
• Sendeflußsteuerung: Xon/Xoff
• Empf.-Flußsteuerung: Xon/Xoff oder Xpc
• Flußsteuer.-Schwellwert: Hoch (768)
• Übertragunsbegrenzung: keine
• F-Tastenbegrenzung: keine

Der Rest im Kommunikations-Menü ist bei mir ausgeschaltet.

Weitere Optionen dienen der Schönheit, wie den Rahmen ausblenden oder eine ESC-Taste emulieren.

Womit ich lange Probleme hatte, waren die Cursor-Tasten.

In der Bash habe ich sie zum laufen bekommen. Hierzu in der Datei ".inputrc" (alternativ /etc/inputrc) die folgenden Werte eintragen:

# with ctrl-v and cursor key
"<9b>A": previous-history
"<9b>B": next-history
"<9b>D": backward-char
"<9b>C": forward-char

Man kann hier auch mit if-Bedingungen arbeiten. Ich hab mich erst mal dagegen entschieden und auf später verschoben.

Wie in meinem Kommentar angedeutet wird, kann man mittels der Tasten CTRL und v, sowie anschließendes drücken der Cursor-Taste den Steuer-Code anzeigen. Der sehr häufig im Internet anzutreffende Befehl "showkey -a" zeigte bei mir entweder nur Hex-Code oder aber die dortigen Codes waren nicht für die inputrc nutzbar. Kein Plan warum das so gar nicht ging.

Was ich bis jetzt nicht geschafft habe ist die Cursor oder F-Tasten für den Vim nutzbar zu machen. Vimrc scheint da irgendwie damit nicht zurecht zu kommen. Vielleicht weiß hier jemand Rat?

Ein weiteres Problem ist wohl die TERM-Variable. Jedes mal, wenn ich die auf "export TERM=vt520" setzte und vim aufrufe, schreibt er mir Steuerzeichen in den Text. Setze ich hingegen "export TERM=vt100" bleiben diese komplett aus. So richtig schlau bin ich an dieser Stelle noch nicht.

Ich schmeiße in der Regel das Vim-Tiny Teil gleich runter und installiere dann das große Paket. Aber um sicher zu sein, hab ich gleich mal nachgeschaut ...

$ apt search vim | grep ^vim | grep -e residual-config -e installed

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

vim/stable,now 2:8.2.2434-3+deb11u1 armhf [installed]
vim-addon-manager/stable,now 0.5.10 all [installed,automatic]
vim-airline/stable,now 0.11-1 all [installed]
vim-airline-themes/stable,now 0+git.20180730-6e798f9-1.1 all [installed,automatic]
vim-common/stable,now 2:8.2.2434-3+deb11u1 all [installed]
vim-runtime/stable,now 2:8.2.2434-3+deb11u1 all [installed,automatic]
vim-tiny/stable,now 2:8.2.2434-3+deb11u1 armhf [residual-config]
$

Von Daher, daran scheint es nicht zu liegen.

Wenn ich vim öffne wird sofort in den insert mode gewechselt und ersetzt in der ersten Zeile die Zeichen durch:

<9b>3;1R

der Anfang ist mit dem Steuerzeichen für delete key identisch („<9b>3~“).

Die set Anweisungen ändern leider nichts. Schade

Treffer!!!

Danke

Zitat von JenGun

Zitat von echo

Wenn ich vim öffne wird sofort in den insert mode gewechselt und ersetzt in der ersten Zeile die Zeichen durch:

Code

<9b>3;1R

Sieht nach "Request Cursor Position" aus: set t_u7= mal probiert?

Was bedeutet das genau?

Weiß eigentlich jemand, ob man den Tasten in der VT520-Terminal andere Steuerzeichen erstellen kann? Für die Cursor-Tasten würde ich das gerne ausprobieren. Nur, da das zurücksetzten immer alles zurücksetzt und nicht nur die einzelne Taste ist das etwas mühsam.

Unter Linux sind die Pfeiltasten wie folgt zugeordnet:

Oben: ^[[A

Rechts: ^[[C

Unten: ^[[B

Links: ^[[D

Wenn das VT520 diese senden würde, müssten alle Applikationen das dann sofort verstehen, so meine Hoffnung.

PS:

ok im Netz finde ich "set t_u7= will disable requesting cursor position".

Anbei mein Teilauszug aus der .vimrc:

if $TERM == 'vt520'
    "set encoding=iso-8859-15
    "set fileencoding=iso-8859-15
    set t_u7=   "disable requesting cursor position
    "arrow up
    nmap <9b>A k
    imap <9b>A <esc>ka
    "arrow down
    nmap <9b>B j
    imap <9b>B <esc>ja
    "arrow right
    nmap <9b>C l
    imap <9b>C <esc>la
    "arrow left
    nmap <9b>D h
    imap <9b>D <esc>ha
    nmap <9b>5~ 25k         "pg up
    nmap <9b>6~ 25j         "pg down
    nmap <9b>2~ i           "insert key
    nmap <9b>3~ x           "delete key
    imap <9b>3~ <esc>xi     "delete key
"    imap <9b>3~ ^[xi        "delete key
endif

Damit funktionieren die Cursor-Tasten und teile des Block da drüber.

Der "<9b>" Teil scheint eine Interpretation vom Vim zu sein. Tippe ich das so ein, funktioniert es nicht. Mache ich hingengen eine "echo "<ctrl>+v<curor-key>">> .vimrc" und bearbeite den hinteren Teil, dann läuft.

das bringt leider nichts.

Denke ich bleib erst mal bei dem was ich habe, das scheint zumindest zu funktionieren.

Wenn ich das im Netz richtig verstanden habe, dann bringt der Flag "set nocompatible" nur, dass er die ".exrc" ignoriert, die ja für den originalen vi die Einstellungen trifft. Und wenn man die ".vimrc" gepflegt hat, wird das sowieso schon gemacht.

Ein Problem habe ich noch. Beim Aufrufen von "raspi-config" kann ich die Steuertasten nicht nutzen. So wie es aussieht ist das ein einfaches Bash-Script, in dem "whiptail" für die Gui genutzt wird. Jemand ne Idee wie ich die Curser-Tasten dort nutzen kann? Oder gibts irgendeine alternative?

PS:

hab eine Lösung für whiptail (raspi-config).

ctrl+p => ist hoch

ctrl+n => ist runter

ctrl+f => ist rechts

ctrl+h => ist links