Hallo Zusammen, ich möchte ein 4G-Modem (u-blox sara-r4xx) in Betrieb nehmen. Das Target spielt eigentlich keine Rolle. Es geht um die Auswertung der Resultcodes auf eine AT-Kommando. Die Antwort auf eine AT-Kommando kann sehr unterschiedlich sein und nicht nur "OK"'CRLF'... Ich weis also nicht wenn der Resultcode "fertig" ist. Muss ich immer, Byte für Byte, parsen wenn ich den Resultcode empfange? Wäre es auch möglich, die Rückantwort pauschal in einen Timeout reinrauschen zu lassen und nach dem Timeout den Resultcode auszuwerten. Könnte die Performance etwas ausbremsen aber das ist an der Stelle nicht wichtig. Sorry für die triviale Frage aber AT-Befehle sind irgendwie etwas "Altwelt"... Grüße Runout
Thomas T. schrieb: > Wäre es auch möglich, die Rückantwort pauschal in einen > Timeout reinrauschen zu lassen und nach dem Timeout den Resultcode > auszuwerten. Diesen Holzhammer würde ich nur als Sicherungsleine verwenden. > Die Antwort auf eine AT-Kommando kann sehr unterschiedlich sein > und nicht nur "OK"'CRLF'... Aber der Anfang und der Abschluss ist immer CRLF. Siehe in den Versionen jeweils den Abschnitt 4.2: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1515 Ich würde also einen Ringpuffer füllen. Wenn ich dann bei einem LF 4 Bytes rückwärts schaue und da kein LF ist, dann habe ich das Ende einer Antwort bekommen.
:
Bearbeitet durch Moderator
Thomas T. schrieb: > Sorry für die triviale Frage aber AT-Befehle sind irgendwie > etwas "Altwelt"... Das hat überhaupt nichts mit Altwelt, Legacy, Vermächtnis oder was auch immer zu tun. Die AT-Befehle sind ein (oder quasi DER Standard) für die Kommunikation zwischen "Datenendgeräten" egal auf welcher Plattform. Zu deinem Problem. Schaue doch einfach in das Datenblatt vom Modem, da steht drin, wie die Daten übertragen werden. Entweder kommt zum Schluss ein CRLF, es sind definierte Paketlängen oder es wird bei Beginn der Übertragung mitgeteilt, wie viele Bytes übertragen werden. Ein Time-Out sollte immer Pflicht sein, um unterbrochene Übertragungen zu erkennen, aber nie als die Standardlösung zum Erkennen von EOT.
Thomas T. schrieb: > [...] > Es geht um die Auswertung der Resultcodes auf eine AT-Kommando. Mit welcher Absicht? Willst Du, wie Dein nachfolgender Text mir suggeriert, nur feststellen, ob die Antwort vollständig ist? > Die Antwort auf eine AT-Kommando kann sehr unterschiedlich sein > und nicht nur "OK"'CRLF'... > > Ich weis also nicht wenn der Resultcode "fertig" ist. Ich würde an Deiner Stelle, vollständig ermitteln, welches die möglichen Antworten sind. Das bedeutet nicht zwangsweise, dass Du sie vollständig parsen musst. Aber ich halte es für sinnvoll, alle Varianten wenigstens zu kennen. (Ich kann mich gerade nicht erinnern, aber ich meine am Ende kommt immer ein CR, LF, oder CR+LF). > Muss ich immer, Byte für Byte, parsen wenn ich den Resultcode empfange? Nein. > Wäre es auch möglich, die Rückantwort pauschal in einen > Timeout reinrauschen zu lassen und nach dem Timeout den Resultcode > auszuwerten. Letztlich ist das gehupft wie gesprungen. Wesentlich ist, dass Du das (bis auf pathologische Fälle) vollständig deterministische Verhalten nutzt, um eine vollständig deterministische Auswertung zu machen. > [...]
ich mache meine "Kommunikations-Funktion" immer so, dass sie ein Kommando sendet und dann auf ein bestimmtes Schlüsselwort mit Timeout wartet. Wenn das Schlüsselwort empfangen wurde, wird noch etwas länger empfangen, bis für eine gewisse Zeit (z.B 50ms) nichts mehr weiter kommt. Das Schlüsselwort ist meistens "OK" und als Timeout verwende ich einen zum Befehl passenden Wert. Manche brauchen ja länger als andere. So läuft die Kommunikation im guten Fall schnell ab und ist im Fehlerfall dennoch stabil.
Hallo Zusammen, Lothars-Vorschlag wird es werden... (+ Timeout obendrauf) Das CR/LF detektieren und dann "rückwärts schauen"... Die Resultcodes sind wie folgt definiert: "OK" 0 Final Command line successfully processed and the command is.. "CONNECT" 1 Intermediate Data connection established "RING" 2 Unsolicited Incoming call signal from the network "NO CARRIER" 3 Final Connection terminated from the remote part... "ERROR" 4 Final General failure.The AT + CMEE command.. "NO DIALTONE" 6 Final No dialtone detected "BUSY" 7 Final Engaged signal detected(the called number is busy) "NO ANSWER" 8 Final No hang up detected after a fixed network timeout "NOT SUPPORT" 10 Final Operation not supported "INVALID COMMAND LINE" 11 Final Invalid command line "CR" 12 Final Carriage return "SIM DROP" 13 Final SIM not inserted "Command aborted" 3000 Final Command execution aborted issuing a character.. "DISCONNECT" 14 Final Data connection disconnected Viele Grüße
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.