AT-Befehle über COM-Port

Computer: Software & Programmierung Programmierung allgemein
#1

Sodele, schwierig dies in ein Themengebiet einzuordnen, deshalb kommts in einen „allgemeinen“ Bereich …

Ich habe folgendes Anliegen, nachdem ich mich entschieden hab für ein Testsystem ein GSM-Modem einzusetzen, arbeite ich daran dieses mittels AT-Befehle anzusteuern. Zur Hardware, es handelt sich um das CardPhone 2.0 von Nokia!

Mein Programm ist in C/C++ verfasst und ich benutze zum Teil diesen Source (http://winapi.net/index.php?inhalt=t3) um auf den seriellen Port zuzugreifen und die AT-Befehle dem Modem mitzuteilen. Dies funktioniert eigentlich auch ganz gut, aber nicht zu verlässig bei den erweiterten AT-Befehlen für GSM-Modems, sprich bei +CPIN, +CREG … erhalte ich in den meisten Fällen ERROR als Modemstatus! Merkwürdigerweise aber auch nicht immer, in seltenen Fällen komm ich auch mal ein Stückchen weiter bzw. bekomme ich mein OK zurück, aber mich lässt das Gefühl nicht los, dass dies nicht zwingend zu dem ausgeführten Befehl gehört …

Ich habe die Befehle auch mit einem COM-Port-Tool von Shamrock getestet und dort funktionieren sie mit verhältnismäßig hoher Zuverlässigkeit!!

Was sich mir jetzt an Fragen stellt, muss ich etwas beachten hinsichtlich der Initialisierung des Modems? Muss ich beim Absetzen der Befehle Pausen einbauen?

Schon mal vielen Dank im Voraus für Tipps und Anregungen …

Grüße

tobeit

#2

Hallo tobeit,

Was sich mir jetzt an Fragen stellt, muss ich etwas beachten
hinsichtlich der Initialisierung des Modems? Muss ich beim
Absetzen der Befehle Pausen einbauen?

Nach dem Absetzen EINES Befehls, musst du auf die Antwort („OK“ oder was auch immer) warten, BEVOR du den nächsten absetzen kannst.
Manche Befehle können da schon Sekunden benötigen bis sie ausgeführt sind und das Einwählen kann sogar Minuten benötigen (Nummer absetzen, warten bis es klingelt, dann warten bis die Gegenseite abhebt und dann müssen die beiden Modems sich noch auf einen gemeinsamen Übertragungsstandard einigen).

Wenn du einen neuen Befehl absetzt, während noch einer bearbeitet wird, wird der erste meist abgebrochen (dieses Verhalten ist besonders wichtig, wenn man die Einwahl abbrechen will!!).

MfG Peter(TOO)

#3

Hallo Peter,

Danke für die prompte Antwort …

Nach dem Absetzen EINES Befehls, musst du auf die Antwort
(„OK“ oder was auch immer) warten, BEVOR du den nächsten
absetzen kannst.

Das tue ich, ich schreib meinen Befehl auf den COM-Port raus und lese dann die Antwort zurück, welche ich wiederum in einer Schleife auswerte, bis ich mein OK darin finde. Erst dann wird der nächste Befehl geschrieben!! Wobei ich mich frage, ob es so „gesund“ is, sofort vom COM-Port zu lesen, wenn ich gerade erst den Befehl abgesetzt hab?!?

Manche Befehle können da schon Sekunden benötigen bis sie
ausgeführt sind und das Einwählen kann sogar Minuten benötigen …

Das hab ich auch schon gemerkt :smile: vor allem die PIN zu setzen kann Ewigkeiten dauern!!

Wenn du einen neuen Befehl absetzt, während noch einer
bearbeitet wird, wird der erste meist abgebrochen (dieses
Verhalten ist besonders wichtig, wenn man die Einwahl
abbrechen will!!).

Gut zu wissen …

Grüße und schon mal Danke

#4

Ich habe die Befehle auch mit einem COM-Port-Tool von Shamrock
getestet und dort funktionieren sie mit verhältnismäßig hoher
Zuverlässigkeit!!

Hallo,

du gehst mit den AT-Befehlen ja nicht über eine Post- oder Satellitenleitung, sondern nur über 1…5 m Kabel, wenn überhaupt. Ist das Modem ok und die Schnittstelle und die Software korrekt, so ist die Zuverlässigkeit sehr nahe an 100%. D.h. wenn du da nicht allzu dilletantisch was zusammengelötet hast, liegen Probleme mit Fehlern fast immer in der Software.

Das Problem bei professioneller Softwareentwicklung besteht eher darin, Fehler zu simulieren, weil sie im Laborbetrieb so gut wie nie vorkommen.

Es ist natürlich SEHR hilfreich, die Schnittstelle zu belauschen, aber dazu brauchst du einen extra PC mit 2 COM-Ports (wegen der beiden Richtungen) oder einen professionellen Protokoll-Analysator.

Gruss Reinhard

#5

Sei gegrüßt, noch so ein „Nachtarbeiter“ ^^

du gehst mit den AT-Befehlen ja nicht über eine Post- oder
Satellitenleitung, sondern nur über 1…5 m Kabel, wenn
überhaupt. Ist das Modem ok und die Schnittstelle und die
Software korrekt, so ist die Zuverlässigkeit sehr nahe an
100%. D.h. wenn du da nicht allzu dilletantisch was
zusammengelötet hast, liegen Probleme mit Fehlern fast immer
in der Software.

Nöö, gelötet is da nix, wie gesagt ich nutze ein CardPhone im PCMCIA-Slot meines Notebooks!!

Das Problem bei professioneller Softwareentwicklung besteht
eher darin, Fehler zu simulieren, weil sie im Laborbetrieb so
gut wie nie vorkommen.

Es ist natürlich SEHR hilfreich, die Schnittstelle zu
belauschen, aber dazu brauchst du einen extra PC mit 2
COM-Ports (wegen der beiden Richtungen) oder einen
professionellen Protokoll-Analysator.

So langsam denk ich das Problem eingegrenzt zu haben und zwar verhält sich das Modem ausschließlich bei AT-Befehlen merkwürdig, die direkt die PIN betreffen, sprich …

AT+CPIN? zum Abfragen ob eine PIN benötigt wird und …
AT+CPIN=„xxxx“ zum Setzen der PIN!!

Zuerst dacht ich, es läge am Escapen der Zeichen " und ? jedoch konnt ich dies mit Befehlen wie +CREG? wiederlegen!!

Jetzt is guter Rat teuer, was muss ich beim Umgang mit +CPIN beachten!?

Grüße

#6

Hallo Fragewurm,

AT+CPIN? zum Abfragen ob eine PIN benötigt wird und …
AT+CPIN=„xxxx“ zum Setzen der PIN!!

Zuerst dacht ich, es läge am Escapen der Zeichen " und ?
jedoch konnt ich dies mit Befehlen wie +CREG? wiederlegen!!

Jetzt is guter Rat teuer, was muss ich beim Umgang mit +CPIN
beachten!?

Entweder steht dazu etwas in der Beschreibung der Befehle oder du hast einen Firmwarebug gefunden.
Evtl. hilft eine Anfrage beim Hersteller weiter.
Oder du findest etwas dazu im Internet.

Desweiteren hat MS bis jetzt immer irgendwelche „Features“ bei der seriellen Schnittstelle eingebaut. Irgendetwas funktioniert da nie genau so wie in der Dokumentation beschrieben …
Auch bei XP hatte ich damit schon meine Probleme.

Am meisten machten mir zwei Probleme bei Win 3.xx zu schaffen:
Ich habe damals die Daten Blockweise mit fwrite() auf die COM-Schnittstelle geschrieben. Hat bei mir auch alles auf einem 80486 bestens funktioniert. Nur bei Kunden mit einem 80386 hat der PC gleich neu gebootet, wenn der Block grösser als etwa 16 Byte war :frowning:(
Das Ganze habe ich dann so geändert, dass ich den String in maximal 8 Byte-Blöcke zerstückelt habe und diese aber direkt nacheinander geschrieben habe.

Das andere war ein Fehler direkt im Treiber. CD hat nur die erste Aktivierung registriert, danach konnte das Modem mit CD machen was es wollte, der Treiber hat es immer als aktiv gemeldet. War etwas blöde, wenn man eine Modemverbindung steuern wollte.
MS hat dann einen Workaround veröffentlicht, bei dem man auf ein Byte hinter dem DCB zugreifen musste.
Ich habe mir dann den DeviceDriverKit besorgt. Im Assembler-Source fand ich dann zwei Tippfehler.
Und jetzt das ganz Tolle an der Geschichte:

  1. MS hat damals garantiert, dass der Zugriff hinter dem DCB auch in zukünftigen Windows funktionieren wird, was ich auch unter Win XP bestätigen kann.
  2. MS hat nie einen Fehlerfreien Treiber für Win 3.xx herausgegeben.

MfG Peter(TOO)

#7

Hmmmm …

ich kann mir fast nich vorstellen, dass es an einem fehlerhaften COM-Port liegt, dies würde ja sonst auch andere AT-Befehle betreffen und sogar das Echo des Befehls erfolgt korrekt!! Ich denke, dass ich wirklich irgendwie dem Modem eine Zeit einräumen muss, bis es den Befehl zum Abfragen der PIN verarbeitet hat, denn im Shamrock-Tool dauert es eine Weile bis das OK kommt, bei mir hingegen kommt sofort ein Error wenn ich unmittelbar danach den Status abfrag … was macht Shamrock nur anders?? Wie lass ich das Modem +CPIN abarbeiten?? Sleep scheint jedenfalls die falsche Strategie zu sein …

Grüße

#8

Hallo,

zusätzlich zu dem schon gesagten noch ein paar Tips.
Man kann noch soviel Erfahrungen mit solchen async.
Serialverbindungen haben, trotzdem kommt es fast jedesmal
zu neuen Effekten.

1) Ein Spion zum kontrollieren der Daten, die real über die 
 Leitungen gehen ist eigentlich unverzichtbar.
 Evtl. geht das sogar mit dem gleichen PC über 
 USB to Serial Konverter (solche habe ich schon vielfach genutzt).
 http://www.reichelt.de/?;ACTION=3;LA=2;GROUP=C6993;GROUPID=17;ARTICLE=27034;START=16;SORT=preis;OFFSET=16;SID=25IHnsLn8AAAIAACAu1lQ22342ec9a32f8dfbe36684b54fd37573

2) Man sollte auch mindestens einen Oszi zur Verfügung haben,
 um das Timing zu kontrollieren.
2) Überprüfe die Einstellungen für den Datenaustausch.
 Vor allem bidirektionale Verbindungen werden nicht von
 jeder Hardware unterstützt. Auch Bedingungen zu Paritätsprüfung
 und Stoppbits müssen natürlich stimmen.
3) Bei Problemen immer erstmal lange Timeouts festlegen.
 Erstmal niedrige Datenraten nutzen (z.B. 9,6kbaud) 
4) Auch Pausen zwischen Zeichen und Komandos erstmal lang machen.
5) Es kommt auch vor, daß bei längeren Datenpaketen im Windows 
 der Buffer überläuft, weil Windows evtl. zu lange 
 Zukluszeiten beim Multitasking hat. Das sollte zwar heutzutage
 mit aktuellen PC nicht mehr vorkommen, kommt aber auch auf 
 dein Interfacetool an (Interrupt oder Polling?). 
6) Manchmal sind aber auch irgendwelche Zeiten zu lang.
 Z.B. Modem hat zu kurze Timeouts, so daß Antworten nicht 
 fristgerecht kommen (BA zu Modem lesen!).
 Überhaupt sollte man bei Problemen nochmal ganz genau die 
 Beschreibung zum Interface studieren. Oft übersieht man 
 irgend eine wichtige Bedingung (z.B. Parameter im Modem). 
6) Wenn möglich erstmal originale COM-Interfaces benutzen und 
 nicht die USB-RS232 Adapter.
7) Oft genug narrt auch einfach fehlerhafte Hardware.
 Also mal Kabel tauschen und anderen PC probieren sowie
 auch zweites Modem testen.
8) Stromversorgung checken. Spannung muß stabil sein 
 -\> Oszi dranhängen

Gruß Uwi

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#9

Hallo,

das heisst deine TimeOut-Werte stimmen nicht. Ich kenne die Software, die du verwendest nicht, aber unter Windows kann man das ausreichend fein einstellen, gugel mal nach „SetCommTimeOuts“.

Gruss Reinhard

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#10

Sodele hier mein aktueller Statusreport, denn ich möchte meine lieben Helfer ungern im Unklaren lassen!!

Nun zum einen war in meinem Programm unschön, dass ich den COM-Port für jeden Befehl öffne und wieder schließe …

Dann zum einen gibt sich das Problem mit der PIN setzen mit ausreichender Wartezeit, tatsächlich rödelt wohl das Modem Ewigkeiten vor sich hin. Dies ist auch noch stark Provider abhängig und kann wie ich ärgerlichweise, nachdem ich am WE grundsätzlich erstmal mein Programm im Verdacht hatte, es später aber im Terminal auch nich tat, feststellen musste bis zu einer halben Minute dauern!!

Nun bleibt nur noch für mich eins zu klären, dies aber in einem anderen Thread …

Grüße und nochmal vielen lieben Dank für den Input, der mir zwar nich direkt geholfen, aber zum Nachdenken angeregt hat!!

#11

Hallo Fragewurm,

Nun zum einen war in meinem Programm unschön, dass ich den
COM-Port für jeden Befehl öffne und wieder schließe …

Gut, das ist klar ein Fehler.
Das Modem wertet auch die Statusleitungen aus und merkt dadurch, dass das Port geschlossen wird. Dadurch muss natürlich der Protokoll-Ablauf zurückgesetzt werden, damit sich das Modem nicht aufhängt. Zudem möchtest du auch nicht mit Statusmeldungen zugedeckt werden, wenn die Verbindung wieder hergestellt wird (COMM-Öffnen). Die Verbindung könnte z.B. durch herunterfahren des PCs zurückgesetzt worden sein, dann sollte das Modem aber die Verbindung zum Provider auch zurücksetzen, andernfalls gefällt dir deine Rechnung nicht so :wink:)

Dann zum einen gibt sich das Problem mit der PIN setzen mit
ausreichender Wartezeit, tatsächlich rödelt wohl das Modem
Ewigkeiten vor sich hin. Dies ist auch noch stark Provider
abhängig und kann wie ich ärgerlichweise, nachdem ich am WE
grundsätzlich erstmal mein Programm im Verdacht hatte, es
später aber im Terminal auch nich tat, feststellen musste bis
zu einer halben Minute dauern!!

Das Funkmodem muss sich beim Provider einloggen, das kann schon dauern. Dazu muss muss die ID und der PIN an den nächsten Sendemast übermittelt werden. Von dort geht es dann an eine Datenbank welche überprüft wird ob die Kombination überhaupt gültig ist. Wenn wir jetzt noch Roaming berücksichtigen …

MfG Peter(TOO)