SIM800L Handling

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Pac-Man schrieb:

      Wie kann ich diese aus dem String entfernen?
      Ich würde nach dem [CRLF]OK[CRLF] suchen, dieses entfernen und dann auch noch verbleibende [CRLF] aus dem String entfernen.
      Das sollte insofern funktionieren, weil IMHO (soweit ich mich jetzt erinnere) im eigentlichen SMS kein [CRLF] vorkommen kann sondern ein allfälliger Zeilenumbruch dort als Einzelzeichen vorkommt (also entweder ein [CR] oder ein [LF]).
      Auch denke ich, dass du die Eventualität Zeilenumbruch im SMS-Text nicht einfach verwerfen solltest, denn so geheim kann deine Nummer gar nicht sein um dort dennoch auch SMS fremder Absender zu erhalten und sei es nur Erinnerungen oder Werbung des Providers.
      Und man muss ja immer das Ganze SMS übernehmen und kann es erst danach verarbeiten.

      Und entfernen müsste mit der MID-Anweisung (MID(var ,st [, l] ) = var1) möglich sein allerdings kann BasCom auch noch weitere String-Bearbeitungsfunktionen.
      Also z.B. DelChars was aber etwas Eindenken erfordert, weil das wohl zwar alle Zeichen eines Wertes aus dem String entfernen kann aber nicht zwei gleichzeitig.
      Da müsste man im eigentlichen SMS-Text zuerst mal die Zeilenumbrüche durch ein anderes Zeichen (z.B. [TAB]) ersetzen, und kann danach also [CR] und [LF] hintereinander entfernen und hat dann danach auch einen bereinigten String.
      Im SMS-Text wiederum muss man dann das zuvor umgewandelte [TAB] wieder umwandeln.
    • Pac-Man schrieb:

      Momentan ist es ja so dass jedes mal wenn CHR(13) empfangen wird ONRXD angesprungen wird
      Nich so ganz: die Onrxd wird nach jedem Empfangenen Zeichen angesprungen.

      Pac-Man schrieb:

      If N < 150 Then N = 0
      Ist das sinnvoll? mit If N > 150 Then decr N würde der Inhalt erhalten bleiben bis zum nächsten cr.
      Eine Freigabe zum Überschreiben könnte auch von der Main ausgehen. z.B.
      Flag_gefunden = 0 then
      Flag gefunden=1
      N = 0 : S = ""
      Endif
      Dann löscht die onrxd erst wenn die Main es abgearbeitet hat mit flag gefunden = 0.
      In dem Fall ist das Ok nicht mehr wichtig/muß es nicht bearbeitet werden.

      Pac-Man schrieb:

      Mit 19200 hab ich manchmal komische Zeichen drinnen.
      besser viel höher bis 168000 geht dannach sendet er nur noch $00.
    • Zitronenfalter schrieb:

      Auch denke ich, dass du die Eventualität Zeilenumbruch im SMS-Text nicht einfach verwerfen solltest,
      Die empfangene SMS dient nur zur Konfiguration des MC. Eine SMS die nicht das erwartete Format hat wird verworfen und eine Fehlermeldung geschickt.


      Zitronenfalter schrieb:

      und dann auch noch verbleibende [CRLF] aus dem String entfernen.
      Das habe ich vor, kriege es aber nicht hin mit Replacechars. Wenn ich rechts vom empfangenen String einfach zwei Zeichen abschneide funktioniert es.


      Pluto25 schrieb:

      Ist das sinnvoll? mit If N > 150 Then decr N würde der Inhalt erhalten bleiben bis zum nächsten cr.
      Hmmm, OK. Aber die Zeichen die ankommen sind ja trotzdem weg.


      Pluto25 schrieb:

      besser viel höher bis 168000
      mit 115200 klappt es. die nächste Baudrate von meinem Terminalprogramm ist 230400.
    • Pac-Man schrieb:

      Das habe ich vor, kriege es aber nicht hin mit Replacechars.
      Ich kann das jetzt nicht ausprobieren, aber ReplaceChars so angewandt

      BASCOM-Quellcode

      1. Replacechars SMS_TXT , "{013}" , ""
      2. Replacechars SMS_TXT , "{010}" , ""
      funktiomiert nicht?

      IMHO muss das für jedes Zeichen passieren weil soweit ich die Hilfe verstehe, diese Funktion nur ein Zeichen (das aber im gesamten String) ersetzen kann.

      Ich weiß jetzt auch nicht ob man damit auch ein Zeichen löschen kann, dann kann eventuell aber die Funktion DELCHARS helfen wo aber offenbar auch nur ein Zeichen genannt werden kann.
    • Zitronenfalter schrieb:

      funktiomiert nicht?
      In der Tat, braucht >500 Takte und tut was auch immer aber keine String Änderung ;(
      Auch mit Delchars nicht ?( So gehts :
      Delchars SMS_TXT , 10
      Es akzeptiert die 10 als Stringcode :?:
      Es frist aber mit fast 700 Takten (mal 2) ziemlich Zeit. Kommen mehrere SMS hintereinander ?
      Außerdem stellt sich die Frage ob es sinnvoll ist das CrLF in der Mitte zu töten?
      Die Auswertung kann es nutzen um dem Inhalt zu erkennen:
      If left(smstext,5) = "+CMGR: " then
      Nachrichtanfang = instr(smstext, "{010}") ' Hier muß es so aussehen da geht 10 nicht =O

      Ein CrLF am Anfang könnte die Onrxd herausfiltern
      if temp=13
      if n<2 then n=0 s="" else normal weiter

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Pluto25 ()

    • Pluto25 schrieb:

      Kommen mehrere SMS hintereinander ?
      Nein, aber eine Nachricht besteht aus mehreren Strings. Andere wiederum nur aus einem. Beispiel:

      CRLF+CMTI: "SM",1CRLF
      SMS wurde empfangen und auf Speicherplatz 1 abgelegt.

      CRLF+CMGR: "REC UNREAD","+49172xxxxxxx","","20/11/04,20:48:18+04"CRLFTestnachrichtCRLFCRLFOKCRLF
      SMS auf Speicherplatz 1 abrufen.

      Pluto25 schrieb:

      Die Auswertung kann es nutzen um dem Inhalt zu erkennen:
      If left(smstext,5) = "+CMGR: " then
      Dann kriege ich nur

      +CMGR: "REC UNREAD","+49172xxxxxxx","","20/11/04,20:48:18+04"

      Das

      CRLFTestnachrichtCRLFCRLFOKCRLF

      bekomme ich nicht mehr weil ja der String nicht mehr mit "+CMGR: " anfängt. Deswegen addiere ich die Strings bis Left(xxx) "OK" ist. Wenn ich allerdings die CRLF löschen könnte würde mein String so aussehnen

      +CMGR: "REC UNREAD","+49172xxxxxxx","","20/11/04,20:48:18+04"TestnachrichtOK

      Dann könnte ich Anfang und Ende checken.


      Wenn jetzt allerdings, so wie beim ersten, kein "OK" kommt erkenne ich den String nicht.


    • Ich weiß ja jetzt nicht ob du auch die Einzeldaten (Absender Datum, Zeit usw.) auch brauchst, aber wenn es nur um de reinen Text geht suche einfach das erste Auftreten von CRLF nach der Position von +CMGR und danach das nächste Auftreten von CRLF nach der ersten gefundenen Position. Dann hast du auch den reinen SMS-TEXT und es ist egal ob da noch ein OK kommt.
      Sollte es kein zweites CRLF geben wird ja auch kein OK kommen.
      Die SIM-Chips sind ja an sich auch in anderer Hardware verbaut und da funktioniert das SMS-Handling ja schon seit Jahren klaglos.
    • Zitronenfalter schrieb:

      suche einfach das erste Auftreten von CRLF nach der Position von +CMGR
      Genau das ist ja das Problem.

      die empfangenen Daten sehen so aus

      CRLF+CMGR: "REC UNREAD","+49172xxxxxxx","","20/11/04,20:48:18+04"
      CRLFTestnachricht
      CRLF
      CRLFOK
      CRLF

      nach dem +CMGR: kommt kein CRLF mehr. Das CRLF kommt wieder am Anfang der nächsten Nachricht.


      Quellcode

      1. If Left(empfangene_daten , 6) = "+CMGR:" Then Print#2, empfangene_daten
      ergibt nur das:

      +CMGR: "REC UNREAD","+49172xxxxxxx","","20/11/04,20:48:18+04"

      der Rest fehlt
    • weil die onrxd nach dem 13 neu beginnt. Würde sie weiter sammeln bis die Hauptroutine es ausgewertet hat wäre es vollständig. Es sei denn die Main war "zu schnell".
      In dem Fall stellt sich die Frage: Wartet die Main auf das nächste 13 oder bekommt die onrxd mehr intelligenz? Oder anders gefragt hat die Main viel anderes zu tun oder ist sie fast ausschließlich für die Empfangsauswertung da? Bzw hätte sie immer die Zeit sich sofort darum zu kümmern?
      Die "Case" weiß ja ob ein OK kommen sollte und könnte somit entscheiden ob darauf gewartet werden soll.(oder auf weitere 13).
      ein aktueller Code wäre schön, ich bin noch auf Stand #52
    • Michael schrieb:

      Es ist bisher noch nicht korrekt geklärt, welche Daten wirklich kommen.
      Also z.B. HIER wird das so erklärt.

      Und da ist kein führendes CRLF (und ich erinnere mich da jetzt auch an keines).
      Wenn das da wirklich ist, müsste das IMHO ein Überbleibsel aus einer vorangegangenen Übertragung sein.
      Ich würde da anders ansetzen.
      Es werden die empfangenen Daten eingelesen und zwar solange, bis endlich +CMGR: ankommt, dann erstmal weiter solange einlesen, bis ein [CRLF] ankommt.
      Dann hat man Kommasepariert und in Anführungszeichen die Sendedaten (aber noch ohne Text).
      Man kann den Parser natürlich auch anderweitig ergänzen indem man an der Stelle auf alle zu erwartenden Antworten prüft und entsprechend reagieren.
      Das Modul ist da sehr gesprächig und schreibt auch schon mal unaufgefordert (z.B. "RING" bei einem Anruf auf diese Nummer, aber durchaus auch andere Meldungen, es gibt es ja auch für inzwischen einlangende SMS eine Reaktion. Diese kleinen Chip sind ja sehr mächtig.
      Also hat man entweder einen einfachen Parser der nur auswertet was erwartet wird oder reagiert auch auf unerwartetes
      Dann weiter einlesen bis zum nächsten [CRLF[ was dann den SMS-Text ergibt. Was dann noch kommt ist egal und wird beim nächsten Einlesen einfach überlesen.
      Alternativ kann man aber auch noch bis zum OK[CRLF] weiter lesen, dann ist der Buffer auch soweit bereinigt.

      Aber wie Michael schon schrieb, müsste mal mit einem Terminalprogramm kontrolliert werden, was da wirklich kommt.
      Ich denke nämlich, dass das Modul schon korrekt arbeitet, du aber beim Einlesen der so empfangenen Daten eben nicht korrekt agieren wirst.

      Pac-Man schrieb:

      ergibt nur das:

      +CMGR: "REC UNREAD","+49172xxxxxxx","","20/11/04,20:48:18+04"

      der Rest fehlt
      Na ja, das wird IMHO in deiner Auswerteroutine begründet sein, du hörst wohl erstmal auf zu lesen weil ein [CRLF] empfangen wurde.
      Dann beginnst du wohl wieder von vorne nur kommt da kein +CMGR mehr und überliest den eigentlichen SMS-Text der da jetzt ansteht.
      Aber die gesamte Nachricht besteht eben aus zwei Blöcken der erste ist Kommasepariert und enthält die Absenderdaten in Anführungszeichen und der zweite ist eben der eigentliche Text (der wiederum Zeilenumbrüche (als eines der Zeichen [CR] oder [LF] dargestellt) enthalten kann).
      Hinzu kommt ja noch, dass der reine SMS-Text IMHO nur ein 7-Bit Code ist und somit Sonderzeichen auch noch anders darstellt
      Im Prinzip sieht das so aus +CMGR "1","2","3","4"[CRLF]SMS-Text[CRLF] wobei das Datenfeld Datum und Uhrzeit seinerseits noch in sich Komma-Separiert ist.
      Also ein verschachtelter Datensatz der im Prinzip aus zwei [CRLF] separierten Datenfeldern besteht.
      Das bedeutet aber, dass du nicht beim ersten Einlangen eines [CRLF] zum einlesen aufhören darfst sondern erst wenn entweder nichts mehr kommt (da sollte ein Timeout vorgesehen werden damit sich da nichts hinhängt) oder das eigentlich zu erwartende OK[CRLF].
    • Zitronenfalter schrieb:

      Es werden die empfangenen Daten eingelesen und zwar solange, bis endlich +CMGR: ankommt, dann erstmal weiter solange einlesen, bis ein [CRLF] ankommt.
      Genau da ist ja mein Problem. Nach +CMGR: "REC UNREAD","+49172xxxxxxx","","20/11/04,20:48:18+04" kommt ein CRLF und die neuen Daten enthalten die Nachricht. Diese wird natürlich mit If Left(empfangene_daten , 6) = "+CMGR:" Then übersprungen.

      Ich hab das jetzt mal so gelöst:

      Quellcode

      1. Do
      2. Debounce Handlebar_1 , 1 , Taster_1 , Sub
      3. If Flag_gefunden = 1 Then
      4. If Left(empfangene_daten , 6) = "+CMGR:" Then
      5. 'Empfangene_daten = ""
      6. Dummy = "" : Sekunden = 0
      7. Do
      8. If Flag_gefunden = 1 Then
      9. Flag_gefunden = 0
      10. If Left(empfangene_daten , 2) = "OK" Then Exit Do 'Nachricht mit OK abgeschlossen
      11. Dummy = Dummy + Empfangene_daten
      12. If Sekunden > 2 Then
      13. Flag_gefunden = 0
      14. Flag_fehler_aufgetreten = 1
      15. 'Print#2 , "Fehler"
      16. Call Sms_auswerten(empfangene_daten )
      17. Exit Do
      18. End If
      19. End If
      20. Loop
      21. Empfangene_daten = "" 'Until Left(empfangene_daten , 2) = "OK"
      22. 'Print#2 , "x" ; Dummy ; "x";
      23. Call Sms_auswerten(dummy )
      24. End If
      25. End If
      26. Loop
      Alles anzeigen
      wenn "+CMGR:" gefunden wird springe ich in eine Do/Loop. Dort addiere ich alle eingehenden Nachrichten und springe raus wenn "OK" gefunden wurde. Falls kein "OK" kommt springe ich nach einem Timeout raus. Jetzt kriege ich

      +CMGR: "REC UNREAD","+49172xxxxxxx","","20/11/04,20:48:18+04"(CRLF)Nachricht(CRLF)(CRLF)

      Ich meine somit bei CMGR auch die Nachrichten zu bekommen die nicht mit OK enden wie zum Beispiel diese hier

      +CMGR: "REC UNREAD","+491722270333","","20/10/31,08:38:04+04"(CRLF)Nachricht für +49172xxxxxxx vom 31.10.20 08:38:04 ist am 31.10.20 um 08:38:05 ausgeliefert worden.



      Pluto25 schrieb:

      weil die onrxd nach dem 13 neu beginnt. Würde sie weiter sammeln bis die Hauptroutine es ausgewertet hat wäre es vollständig.
      Genau!

      Pluto25 schrieb:

      In dem Fall stellt sich die Frage: Wartet die Main auf das nächste 13 oder bekommt die onrxd mehr intelligenz?
      Ich lasse jetzt die Main warten. Die Main hat momentan nicht allzu viel zu tun. Momentan funktioniert es aber ist es auch richtig so?

      Anbei noch die Datei.

      Gruß, Martin
      Dateien
      • noname5.bas

        (9,62 kB, 9 mal heruntergeladen, zuletzt: )
    • Pac-Man schrieb:

      If Left(empfangene_daten , 2) = "OK" Then Exit Do 'Nachricht mit OK abgeschlossen
      Das wäre mir auch zu unsicher weil es zumindest möglich ist, dass der SMS-Text diese Zeichenkette ebenfalls enthalten könnte.
      Selbst wenn das aktuell vielleicht ausgeschlossen werden könnte, kann das ja in der Zukunft so sein und du fängst wieder zum Suchen an.
      Daher wäre es IMHO sicherer, auf OK[CRLF] (also Left(empfangene_daten , 4)) zu prüfen.
      Ich gehe eigentlich davon aus, wenn das Modul das OK sendet dieses auch immer mit [CRLF] abschließen wird.
    • Zitronenfalter schrieb:

      Das wäre mir auch zu unsicher weil es zumindest möglich ist, dass der SMS-Text diese Zeichenkette ebenfalls enthalten könnte.
      Stimmt, geht natürlich auch in die Hose...


      Zitronenfalter schrieb:

      Ich gehe eigentlich davon aus, wenn das Modul das OK sendet dieses auch immer mit [CRLF] abschließen wird.
      Richtig. Der SMS Inhalt wird aber auch mit (CRLF) abgeschlossen. Ich gucke mal weiter.
    • Kann ein denn CrLf innerhalb einer SMS vorkommen? Oder ist es dort nur ein lf?
      Andererseit werden die Steuerbefehle doch nicht mit OKCrLfBefehl gesendet.
      Wird es denn eine Foge von Befehlen ineiner SMS geben die mit CrLf abgestuft sind?
      Der MC muß letzlich nur seine Anweisungen verstehen, alles andere kann ihm egal sein.
      Dann wäre auch evt das Warten aufs OK unnötig. (Beim Nachrichten lesen)
    • In einer meiner Anwendungen zerlege ich eine SMS folgendermaßen.

      Die Funktion GetSMS holt die geforderte SMS pPos vom Speicher (bei mir die SIM-Karte, daher zwischen 1 und 20).
      iTimerCom wird im IRQ hochgezählt um einen Deadlock zu vermeiden und das ganze auch gezielt abbrechen zu können.

      Das funktioniert eigentlich einwandfrei.

      BASCOM-Quellcode

      1. Const SMS_Data_Status = 0
      2. Const SMS_Data_SenderNumber = 1
      3. Const SMS_Data_SenderName = 2
      4. Const SMS_Data_Date = 3
      5. Const SMS_Data_Time = 4
      6. Const SMS_Data_Date_Year = 0
      7. Const SMS_Data_Date_Month = 1
      8. Const SMS_Data_Date_Day = 2
      9. Dim fMenuText(15) As String * 21
      10. Dim fHelpText(15) As String * 32
      11. Dim cREC As String * 254
      12. Dim SMS_Status As String * 16
      13. Dim SMS_Sender As String * 20
      14. Dim SMS_SenderTxt As String * 30
      15. Dim SMS_Date As String * 8
      16. Dim SMS_Time As String * 12
      17. Dim SMS_Text As String * 170
      18. Dim SMS_Pos1 As Byte
      19. Dim SMS_Pos2 As Byte
      20. Dim SMS_Read(15) As String * 20
      21. '(
      22. ##############################################################################
      23. #
      24. # GetSMS
      25. #
      26. # Holt die angegebene SMS aus dem Speicher und belegt die entsprechenden
      27. # globalen Variablen
      28. #
      29. # Parameter:
      30. # pPos Die Speicherposition
      31. #
      32. # Rueckgabe: KEINE
      33. #
      34. ##############################################################################
      35. ')
      36. Sub GetSMS(ByVal pPos As Byte)
      37. Local fX As Byte
      38. Local fP0 As Byte
      39. Local fP1 As Byte
      40. Local fP2 As Byte
      41. Local fS_Data As String * 100
      42. cCMD = "+CMGR=" + Str(pPos)
      43. GSM_Send 0 , 0
      44. iTimerCom = 0
      45. fX = 0
      46. cREC = ""
      47. Do
      48. If IsCharWaiting() = 1 Then
      49. fX = Waitkey()
      50. cREC = cREC + Chr(fX)
      51. iTimerCom = 0
      52. End If
      53. Loop Until iTimerCom > MS_200
      54. fS_Data = ""
      55. SMS_Text = ""
      56. SMS_Status = ""
      57. SMS_Date = ""
      58. SMS_Sender = ""
      59. SMS_SenderTxt = ""
      60. SMS_Time = ""
      61. If cREC = "OK{013}{010}" Then ' Speicherplatz leer
      62. Else
      63. fP1 = Instr(cREC , "+CMGR: ")
      64. If fP1 <> 0 Then ' Ist ein SMS-String
      65. fP2 = Instr(fP1 , cREC , CRLF) ' Trenner Data/Text
      66. If fP2 <> 0 Then
      67. fP1 = fP1 + 6
      68. fP0 = fP2 - fP1
      69. fS_Data = Mid(cREC , fP1 , fP0)
      70. fP2 = fP2 + 2
      71. fP1 = Instr(fP2 , cREC , CRLF)
      72. fP0 = fP1 - fP2
      73. Incr fP0
      74. SMS_Text = Mid(cREC , fP2 , fP0)
      75. End If
      76. DelChars fS_Data , 34
      77. fS_Data = Ltrim(fS_Data)
      78. fP0 = Split(fS_Data , fHelpText(0) , ",")
      79. If fP0 >= 5 Then ' Daten korrekt vorhanden
      80. SMS_Status = fHelpText(SMS_Data_Status)
      81. SMS_Status = Ucase(SMS_Status)
      82. Select Case fHelpText(SMS_Data_Status)
      83. Case "REC READ"
      84. SMS_Status = "gelesen"
      85. Case "REC UNREAD"
      86. SMS_Status = "ungelesen"
      87. Case "STO UNSENT"
      88. SMS_Status = "nicht gesendet"
      89. Case "STO SENT"
      90. SMS_Status = "gesendet"
      91. Case "ALL"
      92. SMS_Status = "alle"
      93. Case Else
      94. SMS_Status = "unbek. Status"
      95. End Select
      96. fP1 = Split(fHelpText(SMS_Data_Date) , fMenuText(0) , "/")
      97. If fP1 <> 3 Then
      98. SMS_Date = "Datum !?"
      99. Else
      100. SMS_Date = fMenuText(SMS_Data_Date_Day) + "."
      101. SMS_Date = SMS_Date + fMenuText(SMS_Data_Date_Month) + "."
      102. SMS_Date = SMS_Date + Right(fMenuText(SMS_Data_Date_Year) , 2)
      103. End If
      104. SMS_Time = fHelpText(SMS_Data_Time)
      105. SMS_Sender = fHelpText(SMS_Data_SenderNumber)
      106. SMS_SenderTxt = fHelpText(SMS_Data_SenderName)
      107. End If
      108. End If
      109. End If
      110. End Sub
      111. '(
      112. ##############################################################################
      113. #
      114. # GSM_Send
      115. #
      116. # Sendet einen Befehl zum GSM-Modul
      117. #
      118. # Parameter:
      119. # pCommand Der entsprechende Befehl laut Liste
      120. # Bei = 0 steht der Befehlsstring(OHNE "AT") in cCMD
      121. #
      122. # pClrBuffer =1 loescht den Eingangsbuffer incl. cREC
      123. #
      124. # Rueckgabe: KEINE
      125. #
      126. ##############################################################################
      127. ')
      128. Sub GSM_Send(ByVal pCommand As Byte , ByVal pClrBuffer As Byte)
      129. If pCommand <> 0 Then
      130. cCMD = LookupStr(pCommand , GSM_Commands)
      131. End If
      132. If pClrBuffer = 1 Then
      133. cREC = ""
      134. CLEAR SERIALIN
      135. End If
      136. Print "AT" ; cCMD ; "{013}";
      137. End Sub
      Alles anzeigen
    • Pluto25 schrieb:

      Kann ein denn CrLf innerhalb einer SMS vorkommen?
      Naja, innerhalb des SMS-Textes an sich nicht, da ist ein Zeilenvorschub nur ein Zeichen (entweder CD oder LF, da erinnere ich mich jetzt nicht.
      Aber innerhalb der Antwort des Moduls nach der Abfrage sehr wohl, die Antwort sieht dann in etwa so aus:
      +CMGR "1","2","3","4"[CRLF]SMS-Text[CRLF]OK[CRLF]
      Die Parameter in Anführungszeichen beziehen sich im wesentlichen auf Status, Absenderdaten und Sendezeit.
      Ich habs nochmal als Zitat eingefügt

      Zitronenfalter schrieb:

      Aber die gesamte Nachricht besteht eben aus zwei Blöcken der erste ist Kommasepariert und enthält die Absenderdaten in Anführungszeichen und der zweite ist eben der eigentliche Text (der wiederum Zeilenumbrüche (als eines der Zeichen [CR] oder [LF] dargestellt) enthalten kann).
      Hinzu kommt ja noch, dass der reine SMS-Text IMHO nur ein 7-Bit Code ist und somit Sonderzeichen auch noch anders darstellt
      Im Prinzip sieht das so aus +CMGR "1","2","3","4"[CRLF]SMS-Text[CRLF] wobei das Datenfeld Datum und Uhrzeit seinerseits noch in sich Komma-Separiert ist.
      Also ein verschachtelter Datensatz der im Prinzip aus zwei [CRLF] separierten Datenfeldern besteht.
    • Zitronenfalter schrieb:

      (entweder CD oder LF,
      Das wäre wichtig zu wissen oder sie einfach nicht in den Anweisungen zu verwenden. Dann würden schon automatisch diese (falsch empfangenen) verworfen.
      @Pac-Man Wieviele Anweisungen wird es benötigen ? Soll es antworten/Statusmeldungen absetzen?
      Passiert das Left(empfangene_daten , 2) = "OK" überhaupt irgendwann? Würde da nicht <Lf>OK stehen?

      PS Das 'If N < 2 müsste 'If N < 3 da das incr n ganz oben steht. Es gibt so kein Zeichen bei n=0