RS232 - Maschine vs. Modem-Emulator - keine Reaktion auf Antwort des Modems

[atomical]

Servus,

folgender Aufbau:

Eine Maschine erwartet an ihrer seriellen Schnittstelle (RS232 nur RX/TX/GND) ein Modem (ist nicht zu ändern, analoges Modem, kein Handshake - DB9 Brücken 1+4+6 / 7+8) um sich nach draußen zu verbinden - sprich, es wird von der Maschine zunächst zyklisch ein Init (ATV0E0X0) gesendet - darauf wird die Antwort 0 (OK) erwartet, nach dem 0 bzw. OK auf den Init kommen bis zum Augenblick des Anrufs zyklisch (~60s) einfache AT - die wiederum mit 0 beantwortet werden müssen, sonst geht es wieder beim Init los.

Kommt auf den Init seitens des Modems keine rechtzeitige Antwort (Zeitfenster geschätzt 1s) kommt der Init nach ca. 2s erneut.


Die Kommunikation der beiden Geräte (Maschine & Modem) habe ich mit zwei alten Notebooks mit "echter" RS232 (je eins auf Rx in der Rx und Tx Leitung der Maschine) und einem entsprechend gebasteltem Adapter mitgeschnitten.


Nun gilt es, die Kommunikation von der Telefonie-Strecke auf IP umzustellen - und das bei Beibehaltung des Maschinenrechners - sprich es braucht eine Art Modem-Simulator.

Solche gibt es bereits - u.a. von einem C64-Enthusiasten - tcpser - http://www.jbrain.com/pub/linux/serial

Mit einem Linux-Notebook älterer Bauart (Toshiba Portege 3490CT) und eben der Software tcpser funktioniert das - die Maschine bekommt ihre Antworten - 0 bzw. OK im Normalbetrieb und auch die Wahl nach draußen klappt. Auf meinen beiden "Spionier-Notebooks" unterscheidet sich die Kommunikation nicht von der mit dem alten Hardware-Modem.

Mit einem Embedded-System, auf welchem auch tcpser läuft, klappt das ganze nicht - obwohl dieses immer die passende Antwort (0) auf den Init sendet (ich schneide die Kommunikation nach wie vor mit), sendet die Maschine durchgehend alle ~2s den Init erneut und sonst nichts - sprich sie scheint auf die Antwort 0 hier nicht zu reagieren.


Nun die Frage - woran könnte das liegen?

Gibt es bei RS232 ggf. Parameter, die "halbkritisch" sind und je nach Toleranz des Empfängers egal ob gesetzt oder nicht trotzdem eine lesbarer Kommunikation (Mitschnitt klappt ja lesbar) zulassen?

Könnte es ein Zeitproblem sein, sprich das die Antwort zu schnell (oder nach Beobachtung bisher eher unwahrscheinlich) zu langsam kommt?

Hat ggf. jemand andere Hinweise?


... ich glaub dafür bin ich zu jung :D

[Newbie314]

Evtl. ein Oszi ausleihen und die Signale zwischen den funktionierenden und den nicht funktionierenden Fällen vergleichen.

Kann an "steigender / fallender" Flanke liegen, Flankensteilheit, wie du sagtest am Timing... ich würde bei so einem alten Stück Hardware darauf tippen dass der Analoge Teil der Elektronik sich nicht mehr versteht.

Oder die Kiste schafft es nicht aufzusynchronisieren.. All das siehst du im Oszi.

[delix]

Könnte es ein Zeitproblem sein, sprich das die Antwort zu schnell (oder nach Beobachtung bisher eher unwahrscheinlich) zu langsam kommt?


da würde ich schon zuerst suchen.
Bei einem embedded system gibt es viel weniger "overhead" der bremst und die Hardwarekomponenten werden meist direkter angesprochen. An deiner Stelle würde ich den Code von TCPSER in der Nähe des Lesekommandos ansehen und versuchen, dort sowas wie ein sleep-Kommando einzubauen.

[atomical]

Das mit dem Oszi kam auch schon zur Sprache - mal sehen woher der kommt ... es muss ja einer sein, der schnell genug ist und speichert.

Am Quelltext kann ich leider so erst mal nichts ändern, weil ich dafür nicht genug Zugriff auf das Embedded-System habe, Kontakt mit dem Support dazu steht aber auch noch aus.

[delix]

Natürlich kannst Du mit dem Oszi das Problem wahrscheinlich recht gut orten. Damit ist es dann aber (noch ?) nicht gelöst.
Der Eingriff in die Software ist da eher sowas wie ein Schuß ins Blaue - mit entsprechenden Erfolgsaussichten. Aber dafür kann man das mit vertretbarem Zeitaufwand ausprobieren und bei Erfolg wäre das Problem dann sofort vom Tisch.

So aus dem Bauch raus würde ich sagen : wenn Du die Kommunikation mit den alten Notebooks hinbekommen kannst wäre es eventuell einfacher die Software vom Embedded System auf ein Notebooks zu übertragen oder das Notebook irgendwie dazwischen zu hängen. Manchmal ist eine funktionierende Quick-and-dirty- Lösung sinnvoller als eine zeitfressende "saubere" -- wobei die in deinem Fall ja auch ein ziemliches Gepfriemel werden kann.
Jedenfalls viel Erfolg.

[Newbie314]

Oszi: würde mal bei einem Amateurfunkclub nachfragen- die verstehen es auch wenn jemand so alte Hardware wiederbeleben will ;)

[E S]

Bei RS232 gibt es unterschiedliche Pegel.

Ursprünglich funktionierte das mit "echten" ±12V (Nur dafür ist die -12V Leitung bei XT/AT/ATX/BTX gedacht). Für Lange Leitungen wird aber alles ab 5V akzeptiert. Da es in den ersten Laptops und "Portablen" Computern keine negative Spannung gab und DC/DC Wandler damals noch recht klobig und teuer waren wurde "RS232-C" definiert. Und das wird leider heute noch bei Embedded Systemen gerne genutzt da man dafür nur 2 WIderstände braucht.

Normal bedeutet -12V eine "1", +12V eine "0". Bei RS232-C sind 0V dann die "1" und +5V die "0". Das funktioniert bei kurzen Leitungen eigentlich sehr gut. Ab 2m und hohen Baudraten versagt das aber ganz gerne. Und dann gibt es noch Geräte (nicht PCs oder normales Zubehör) wo Optokoppler verbaut sind. Die brauchen richtig Strom und oft auch Minus. RS232-C wird aber oft schwach ausgeführt, es gibt meistens einen Schutzwiderstand so dass kein richtiger Strom fließen kann. Und "Minus" gibt es sowiso nicht!

Heutzutage (aber auch schon seit Ende der 80er) benutzt man oft den MAX232 (o.ä.) als Pegelwandler für Notebooks und Embedded Systemen. Der kann zwar auch nicht ±12V herzaubern, aber die eingebauten Ladungspumpen können aus 5V immerhin etwa ±9V zerzegen. Das funktioniert normalerweise immer.

Ich würde vorschlagen, einfach einen MAX232 als "Pegelauffrischer" dazwischen zu schalten. Der MAX232 dient eigentlich nur dazu ±5..20V nach 5V TTL (invertierte Logik) und 5V TTL (invers) nach ±9V zu konvertieren. Man kann die TTL Seite ja Eingang und AUsgang zusammen schalten so dass der normale RS232 auf normale RS232 umwandelt. Und dazu braucht der nur ein bischen 5V die man aus einem USB Port oder per Handyladegerät beziehen kann. Da der MAX232 mit RS232-C gut klar kommt, dürfte das alle Pegelanpassprobleme auf jeden Fall beseitigen.
Da der MAX232 auch noch mal einen identischen Satz Treiber für den Handshake hat kann man so auch beide Richtungen (Rx/Tx) bedienen.

Dazu brauchst Du nur den MAX232 (gibt es in praktisch jedem Elektronikladen), die 4x 1µF (oder 4x 10µF) Kondensatoren und ggf 2 passende RS232 Stecker und ggf ein billiges USB Kabel zum zerschneiden. Das gibt es auch als fertiges Modul zu kaufen mit Schraubklemmen und RS232-Buchse. Das Modul muß man dann aber abändern da man ja 2 Stecker haben will. Das ganze passt schön in ein Dongelgehäuse, hier dann eine USB Buchse setzen oder ein "abgeschnittenes Mauskabel" als Stromversorgung dran machen.

Gruß
Elmar

[atomical]

Servus,

Danke erst mal - wir haben heute nochmal angegriffen, Oszi zur Pegelmessung griffbereit - soweit mussten wir jetzt doch nicht gehen.

Das Problem scheint gelöst - der Support des Embedded-Systems hat dein Update eingespielt.

Offensichtlich verhält sich der Modemsimulator tcpser in der Originalvariante nicht 100% korrekt bei der Initialisierung ATV0E0X0 - er antwortet darauf
<CR><LF>0<CR><LF>

Jetzt wird die korrekte Antwort gesendet und es funktioniert.


0<CR>


Merkwürdig ist, das es mit meinem Notebook trotz der ungenauen Antwort funktioniert, wenn ich tcpser auf der aktiven virtuellen Konsole (X ist da keins drauf) laufen habe - sobald ich bei laufendem tcpser auf eine andere virtuelle Konsole umschalte, klappt es auch mit dem Notebook nicht mehr bis ich wieder zurückschalte. In einer screen-Session funktioniert es gar nicht - egal ob "attached" oder "detached".

Scheinbar stört sich die Maschine nicht grundsätzlich an der Antwort sondern das das 0<CR> zu spät darin vorkommt. Unter gewissen Umständen (inaktive virtuelle Konsole oder gar keine virtuelle Konsole) scheint es dann wirklich zu lange zu dauern.


Das wäre jetzt nur noch zwecks Erkenntnisgewinn, wo da Unterschiede zwischen den Konsolen aktiv / inaktiv / keine sind.