WMOD2 Modem (Wavecom) mir Arduino oder ESP8266 betreiben

Hallo,
ich habe ein Problem, was ich zur Zeit nicht lösen kann und bitte um Unterstützung.

Ich habe einen Arduino Nano über einen Wandler RS232-TTL von Pollin mit dem WMOD2 verbunden, um Statusmeldungen mit AT-Befehlen per SMS zu übermitteln, was so nicht klappt. Verbinde ich das Modem über einen "RS232 to USB Wandler" mit dem Laptop, so kann ich alles manuell bedienen.
Eine Vertauschung der Sende- bzw. Empfangsleitungen möchte ich ausschliessen, da ich diese mit dem Oskar getestet habe, auch die Pausen im Script sind eingehalten und es werden definitiv Daten am richtigen Pin vom Modem mit 9600 Bd versendet.
Das Modem wurde zuvor in Textmode versetzt "gsm.println("AT+CMGF=1");"
Auch das ASCII Equivalent von Ctrl-Z am Ende des Textes wurde nicht vergessen "gsm.write((byte)26);"

Das ist eine ganz bescheidene Situation, wo man einfach keinen Plan mehr hat. Vielleicht ist es ja nur eine "Kleinigkeit" mit großen Auswirkungen und jemand kann mir den Weg weisen :-))

Danke für euere Unterstützung.

Da ist zunächst mal Fehlereingrenzung gefragt, würde ich sagen.

Funktioniert der RS232-TTL-Wandler?
Wenn ja, funktioniert der Arduino-Sketch?

Um den RS232-TTL-Wandler zu überprüfen könntest du ja mal eine manuelle Bedienung über den Arduino machen.
Weil 9600 Baud langsam genug sind funktioniert Softwareserial da auch noch recht gut.

Du könntest ja dein Modem mit TTL-Wandler an D2 und D3 anschließen und folgenden Sketch probieren:

/* *******************************************************
 *      Serielle Weiterleitung
 *      leitet alles, was über USB/Serial (D0/D1) kommt
 *      weiter an (Software)Serial an D2/D3
 *      und umgekehrt.
  * ********************************************************
 */

#include <SoftwareSerial.h>
SoftwareSerial mySerial(2, 3);    // rxPin, txPin

void setup()  
{    Serial.begin(9600);
     mySerial.begin(9600);
}

void loop()
{    if (mySerial.available()) {
         Serial.write(mySerial.read());
     } 
     if (Serial.available()) {
         mySerial.write(Serial.read());
     }
}

Und dann über den seriellen Monitor am PC versuchen mit dem Modem zu "sprechen".
Falls das funktioniert, dann liegt es wohl am Sketch.

Hallo UXOMM,
danke für die schnelle Benachrichtigung. Das Ganze macht mich nachdenklich. Ich hatte ja geschrieben, dass ich die Signale mit dem Oskar überprüft habe. Jetzt, wo du mir das Testprogramm geschickt hast, ist da ein Punkt, den ich zuvor keine Bedeutung geschickt habe.
Es kommt keine Rückantwort von deinem Sketch. Was soll denn bei angeschlossenem Wandler mit Modem zurück kommen ?
Ich habe in meinem Sketch auch die Abfrage drin.

gsm.println("AT");
while(gsm.available())
Serial.write((byte)gsm.read());
delay(500);

Es müsste dann doch das OK vom Modem kommen, oder?
Was habe ich falsch gemacht, oder wie kann ich den Fehler beheben?

Gruß

COOL:
Ich hatte ja geschrieben, dass ich die Signale mit dem Oskar überprüft habe.

Sorry, ich habe keine Ahnung was du damit meinst.
Mag sein, dass das damit zu tun hat, dass ich weit, weit im Osten wohne (Wien) :slight_smile:
Meinst du ein Oszilloskop?

Ich kenne deine Hardware (WMOD2 Modem) leider nur aus dem kurzen Überfliegen des Manuals.
Aber es sieht so aus, als wäre das Modem recht geschwätzig und antwortet meist durchaus ausführlich.
Also ein bestätigendes OK sollte mindestens drinnen sein.

Wenn du das Ganze zu Testzwecken so verbindest...
modem_arduino_pc.png
... dann solltest du mit dem Sketch aus #1 das Modem über den PC ansprechen können und auch die Rückmeldungen vom Modem dort sehen. Der Arduino leitet alles was über USB/Serial kommt zum Konverter weiter und alles was vom Konverter kommt an USB/Serial.
Falls nichts kommt, das Modem also nicht antwortet, ist was faul.
Vielleicht ein Kabel falsch angeschlossen?

Danke, dass du dir soviel Zeit mit mir nimmst. Ja, ich meine ein Oszilloskop. Genau, wie deine Skizze ist, habe ich es auch aufgebaut. Was ich eben nicht verstehe, ist, dass ich am RX-Eingang vom Modem die Signale messen konnte, jedoch keine Bestätigung, also das "OK", was kommen sollte, wenn man nur "AT" sendet, bekommen habe. Ich habe sogar das Modem gegen einen PC getauscht und konnte die gesendeten AT-Befehle mitlesen, die alle korrekt waren. Weil das so unwahrscheinlich war, habe ich darauf hin RX und TX getauscht - wie zu erwarten - kein Erfolg. Dass ich mit einem MAC das Ganze mache, hat doch wohl nichts damit zu tun, oder sollte ich meinen alten Windows-Rechner dazu bemühen. Wie schon anfangs erwähnt, klappt alles, wenn ich über einen USB-TTL-Wandler das Modem lokal ansteuere.

Irgendwie verstehe ich das ganze nicht. Wenn das Modem am ttl-usb läuft, warum willst du zum Arduino dann noch einen Rs232-ttl Wandler reinmachen?

Auf der Skizze sind übrigens beides Mal rxtx vertauscht

Dann fällt mir noch das Stichwort "Hareware-Handshake" ein.
Also: welchen Pegel müssen diese Anschlüsse wann haben bzw. haben sie den auch - zum richtigen Zeitpunkt.

PIN
 8 - DTR - Data Terminal Ready 
 9 - DSR - Data Set Ready
11 - CTS - Clear to send
12 - RTS - Request to send

Edit:
Stellt der Wandler (RS232 auf TTL) diese Anschlüsse zur Verfügung?

Bin da nicht so der Experte - aber schau mal hier: Datenflusssteuerung – Wikipedia

ElEspanol:
Irgendwie verstehe ich das ganze nicht. Wenn das Modem am ttl-usb läuft, warum willst du zum Arduino dann noch einen Rs232-ttl Wandler reinmachen?

Auf der Skizze sind übrigens beides Mal rxtx vertauscht

Es soll ja am Ende das Modem über den RS232-zu-TTL-Wandler mit dem Arduino zusammenarbeiten (ganz ohne PC). Aber das funktioniert anscheinend nicht.
Es geht also zuerst mal nur um Fehlersuche: "Spricht" das Modem überhaupt mit dem Arduino? Und so wie es zur Zeit aussieht, tut es das nicht. Warum?

Wieso ist da rx/tx vertauscht? Wo?
Also ich verbinde immer rx mit tx und fahre damit ganz gut :slight_smile:

COOL:
Wie schon anfangs erwähnt, klappt alles, wenn ich über einen USB-TTL-Wandler das Modem lokal ansteuere.

Das nun mit oder ohne rs232-ttl Wandler?

Hallo, die zusätzlichen Handshake-Leitungen sind nicht erforderlich, weil ich das Modem vom PC aus auch nur mit RX-TX und GND bedient habe.
Ich habe jetzt noch einmal einen Testaufbau gestartet. Dazu habe ich den Arduino mit dem USB-Kabel am MAC angeschlossen. Der Arduino hat an 2+3 einen RS323-TTL von Pollin verpasst bekommen. An der SUB 9 female Buchse habe ich einen USB-Serial-Wandler angesteckt, der zum 2. USB-Anschluss vom MAC geht. Und wieder muss ich mich wundern - es scheint alles zu laufen (siehe Screencopy). Ich werde jetzt mal die Pollin-Schnittstelle untersuchen, irgend etwas ist hier falsch.

GESCHAFFT - Es läuft, jedoch ist es mir nicht eindeutig klar.
Erklärung: in meinem Sketch heisst es

const int rxpin = 2; // pin 2 Receive D2 Nano
const int txpin = 3; // pin 3 Transmit D3 Nano
SoftwareSerial gsm(rxpin, txpin);

Ich bin davon ausgegangen, dass Pin2 der Receive-Pin ist und habe diesen mit Klemmschraube TX (Pollin-Wandler) verbunden und Pin3 Arduino folglich mit Klemmschraube RX. Bei Betrachtung der Schaltung hat der MAX232 aber die Ein- und Ausgänge umgekehrt.
Bei den Experimenten konnte es nicht auffallen, da der USB-Wandler die "Drehung" vornahm.
Ist schon verflixt mit den Bezeichnungen, man muss hier höllisch aufpassen.

Ich möchte mich bei euch über eure Hilfe und Ausdauer herzlich bedanken.

Super, dass es geklappt hat!

Ja, mit der Pin-Beschriftung ist das so eine Sache.
Da gibt es ja (mindestens) 2 Konzepte.
A) Beschriftung nach Funktion
B) Beschriftung danach, was "daran angesteckt gehört"
Und damit fangen die Schwierigkeiten an.

An meinen USB-TTL-Wandlern verbinde ich immer RX mit TX am Mikrocontroller und umgekehrt.
Das hatte bei mehreren FTDI-Wandlern immer super funktioniert.
Dann hab ich zum ersten mal ein "Noname"-Billigteil benutzt, da hat das nicht funktioniert und ich dacht, dass das Ding kaputt ist ("kein Wunder ist eben Billigschrott"). Wollte es schon wegwerfen (€ 3), dachte mir aber dann "jetzt probier ich noch was - ist zwar unwahrscheinlich aber..." und hab dann TX (am Wandler) mit TX (am Mikrocontroller) und RX mit RX verbunden und es lief wunderbar...
Ich mag dieses Beschriftungskonzept trotzdem nicht :slight_smile:

Weil das schon ein altbekanntes Problem ist, gibt es dann ja auch Namen, die versuchen eindeutiger zu sein. Zum Beispiel MOSI und MISO.
MOSI bedeutet ja "Master Out Slave IN".
Sofern man also weiß wer der Master und wer der Slave ist, ist die Wahrscheinlichkeit etwas geringer da die falschen Pins miteinander zu verbinden.

Nochmals danke für deine Unterstützung.

Bei den USB-seriell Konvertern kann man zum testen, ob treiber und Hardware laufen, einfach rx und tx zusammenklemmen als loopback. Wenn man also sieht, was man tippt, geht alles. Dann einen loopbacksketck in den Arduino und man kann ausprobieren, wie rum die Leitungen dran müssen.

Den Tipp für alle diejenigen, die keinen Logikanalyzer haben.