SIM800L Handling

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • SIM800L Handling

      Hallo,

      ich knabber seit geraumer Zeit an einem Problem mit einem SIM800L Modul. Es hängt an einem ATMEGA8 und am PC. Verschaltet hab ich es nach dem angehängten Plan. Kontrollieren tue ich es mit zwei Fenster von Termite 3.4. Mit dem einen Fenster protokolliere ich die Antworten des Moduls auf dem PC, mit dem Anderen protokolliere ich was der MC empfängt. Leider schickt mir der MC nicht das was das Modul an den PC sendet. Die Protokolle sind im zweiten Anhang.

      Ich denke ich hab irgendwas in meinem Programm nicht korrekt gemacht aber so kompliziert ist das ja wohl nicht. Trotzdem, ich habe eine geistige Blockade. Finde den Fehler einfach nicht.

      Source Code

      1. $regfile = "m8adef.dat" ' eingesetzter Mikrocontroller
      2. $crystal = 8000000 ' eingestellte Taktfrequenz
      3. $hwstack = 60
      4. $swstack = 40
      5. $framesize = 100
      6. 'Serielle Communication
      7. Config Serialin0 = Buffered , Size = 30 , Bytematch = 13 '13
      8. $baud = 9600 '19200
      9. Echo Off
      10. Declare Sub Betriebszustandsanzeige
      11. Declare Sub Taster_1()
      12. Declare Sub Taster_2()
      13. Declare Sub Taster_3()
      14. Handlebar_1 Alias Pinb.1 : Config Handlebar_1 = Input 'eingang mit pullup Portb.1 = 1
      15. Handlebar_2 Alias Pinb.2 : Config Handlebar_2 = Input
      16. Handlebar_3 Alias Pinb.3 : Config Handlebar_3 = Input
      17. 'Ports out
      18. Config Portc = Output 'gesamten Port c als Ausgabeport
      19. Led_4 Alias Portc.4
      20. Led_3 Alias Portc.3
      21. Led_2 Alias Portc.2
      22. Led_1 Alias Portc.1
      23. Led_0 Alias Portc.0
      24. 'Config Portd.7 = Output
      25. Open "comd.7:9600,8,N,1" For Output As #2
      26. 'Timer
      27. Config Timer1 = Timer , Prescale = 256
      28. Enable Timer1 'bei 8 Mhz
      29. Timer1 = 34286 '49111 '49111=1sec, 34286=2sec, 18661=3sec, 3036=4sec, 46005+prescale=256=5sec
      30. On Timer1 Anzeigen
      31. '################################################### Variablen ###############################################
      32. Dim Sekunden As Byte
      33. Led_0 = 1 : Led_1 = 0 : Led_2 = 0 : Led_3 = 0 : Led_4 = 0 : Waitms 300
      34. Led_0 = 0 : Led_1 = 1 : Led_2 = 0 : Led_3 = 0 : Led_4 = 0 : Waitms 300
      35. Led_0 = 0 : Led_1 = 0 : Led_2 = 1 : Led_3 = 0 : Led_4 = 0 : Waitms 300
      36. Led_0 = 0 : Led_1 = 0 : Led_2 = 0 : Led_3 = 1 : Led_4 = 0 : Waitms 300
      37. Led_0 = 0 : Led_1 = 0 : Led_2 = 0 : Led_3 = 0 : Led_4 = 1 : Waitms 300
      38. Led_0 = 0 : Led_1 = 0 : Led_2 = 0 : Led_3 = 0 : Led_4 = 0 : Waitms 500
      39. Enable Interrupts 'Interrupts zulassen
      40. '######################################## Hauptschleife #############################
      41. Do
      42. Debounce Handlebar_1 , 1 , Taster_1 , Sub
      43. Debounce Handlebar_2 , 1 , Taster_2 , Sub
      44. Debounce Handlebar_3 , 1 , Taster_3 , Sub
      45. Loop
      46. End
      47. '##################################### Ende Hauptschleife ####################################
      48. 'Timer
      49. Anzeigen: 'Betriebsanzeige
      50. Timer1 = 34286 '49111 'Timer auf 1 sekunde
      51. Incr Sekunden
      52. Gosub Betriebszustandsanzeige
      53. Return
      54. Sub Betriebszustandsanzeige
      55. Toggle Led_0
      56. 'Print #2 , "Hi"
      57. End Sub
      58. Sub Taster_1:
      59. Led_4 = 0
      60. While Handlebar_1 = 1
      61. Toggle Led_1 : Waitms 100
      62. Wend
      63. Led_1 = 0
      64. Print "AT" ; Chr(13) ;
      65. End Sub
      66. Sub Taster_2:
      67. Led_4 = 0
      68. While Handlebar_2 = 1
      69. Toggle Led_2 : Waitms 100
      70. Wend
      71. Led_2 = 0
      72. Print "at+cpin=1111" ; Chr(13) ;
      73. End Sub
      74. Sub Taster_3:
      75. Led_4 = 0
      76. While Handlebar_3 = 1
      77. Toggle Led_3 : Waitms 100
      78. Wend
      79. Led_3 = 0
      80. Print "atz" ; Chr(13) ;
      81. End Sub
      82. '##################################### Serielle Kommunikation ####################################
      83. 'Achtung!!!! Die Gegenseite darf nur CR anhängen!!!!!
      84. Serial0charmatch:
      85. Led_4 = 1
      86. Dim Incoming_data As String * 30
      87. Input Incoming_data Noecho 'Daten vom Buffer auslesen,
      88. Print #2 , Incoming_data
      89. Return
      Display All
      Files
      • SIM800L.jpg

        (34.24 kB, downloaded 25 times, last: )
      • Kommunikation.png

        (10.11 kB, downloaded 26 times, last: )
    • Michael wrote:

      Was empfangen denn die beiden, wenn sie nicht gleichzeitig auf der Leitung hängen?
      Sieht man in dem Bild Kommunikation.


      Michael wrote:

      Wie ist der MC an den PC angebunden
      Beide Seriellen vom MC sind über USB/Seriell Module am PC.

      Gedacht war das so:
      MC und PC kommunizieren beide mit dem SIM800 über die Dioden via HWserial.
      MC sendet das was er vom SIM800 empfangen hat via softserial an den PC.

      PC und MC dürfen so natürlich nicht gleichzeitig senden. Das tun sie auch nicht. PC sendet über Termite wenn ich was eingebe, MC sendet wenn ich eine der drei Tasten drücke.
    • Pac-Man wrote:

      Sieht man in dem Bild Kommunikation.
      Du schreibst ja im ersten Beitrag, dass sie nach der Schaltung wie im Bild angeschlossen sind.
      Mich interessierte aber das Ergebnis, wenn nur einer (MC oder PC) verdrahtet ist.


      Die Fehlersuche wäre einfacher, wenn du zuerst nur einfachste Befehle probierst, den Empfang eines OK auf ein AT zum Beispiel.

      Vielleicht kannst du hier noch ein paar Infos finden:
      g-heinrichs.de/attiny/module/SIM800L.pdf
    • Michael wrote:

      wenn nur einer (MC oder PC) verdrahtet ist.
      Ahh, sorry, missverstanden.

      Also wenn nur der PC dran ist empfängt der PC alles richtig. Macht er ja auch so.

      Wenn nur der MC angeschlossen ist bekomme ich über Softwareseriell auch Mist zurück.


      Michael wrote:

      Die Fehlersuche wäre einfacher, wenn du zuerst nur einfachste Befehle probierst, den Empfang eines OK auf ein AT zum Beispiel.
      Das mache ich ja. Ich sende per Tastendruck (1-3) vom MC Befehle an das SIM. Über softserial möchte ich sehen was der MC empfängt.


      Michael wrote:

      Vielleicht kannst du hier noch ein paar Infos finden:
      Kenne ich. Ist auch die Grundlage für meine Experimente.

      Allerdings macht er es über Onrxd: und ich möchte es gerne über Serial0charmatch: realisieren. Das sollte aber ja nicht das Problem sein. Die Kommunikation PC-MC über Serial0charmatch: funktioniert ja.
    • Pac-Man wrote:

      Das mache ich ja. Ich sende per Tastendruck (1-3) vom MC Befehle an das SIM. Über softserial möchte ich sehen was der MC empfängt.
      Aus deiner Grafik (warum eigentlich nicht als Text?) sehe ich wohl mehrere Befehle
      Ich sehe Hex-Werte und dann leere Stellen und dann Ascii Zeichen.
      Das kann doch nicht die Ausgabe sein, oder mischst du da beide Datenformate?
      Ein CR LF gibt doch einen Zeilenvorschub?

      Und die Ausgabe ist die Antwort auf welche Sendung?
    • Michael wrote:

      Und die Ausgabe ist die Antwort auf welche Sendung?
      Erstes OK ist die Antwort auf AT
      zweites OK ist die Antwort auf ATZ
      dritte Antwort ist die Antwort auf AT+CPIN=1111

      Ich mische nichts. Ein Bild ist wie es der PC empfängt und das Zweite ist was mir der MC an den PC schickt.

      Kann es sein dass der MC schon Müll empfängt weil ich Serial0charmatch: benutze und deswegen weiter sendet?
    • Pac-Man wrote:

      Erstes OK ist die Antwort auf AT
      zweites OK ist die Antwort auf ATZ
      dritte Antwort ist die Antwort auf AT+CPIN=1111
      Naja, irgendwas ist da, ähh, seltsam.
      Liegt vermutlich an deinem Terminalprogramm.
      Kannst du die Ausgabe nicht als Text hier posten?

      Pac-Man wrote:

      Ich mische nichts. Ein Bild ist wie es der PC empfängt und das Zweite ist was mir der MC an den PC schickt.
      Wie gesagt, hex und ascii nebeneinander und seltsame Abstände und Zeilenumbrüche, wo keine sein dürften.
      Kannst du nicht Hterm benutzen?

      Pac-Man wrote:

      Kann es sein dass der MC schon Müll empfängt weil ich Serial0charmatch: benutze und deswegen weiter sendet?
      Du wolltest ja unbedingt diese Konstruktion. a_27_b277ca12
      Möglicherweise musst du den Buffer leeren, wenn du was empfangen hast.
      Auch das Print #2 Incoming_data sendet an den PC mindestens ein CRLF, was ja so im Datenstrom nicht vorkommt. Das heißt, immer, wenn du ein CR empfängst, sendet der seriel0charmatch ein CRLF.
      Da ist es eben deutlich leichter, im seriellen Interrupt das UDR zu lesen und nur dieses Byte auf #2 zu verschicken (ohne CR/LF), dann kommt das 1:1 zum Debuggen an.
    • Michael wrote:

      Du wolltest ja unbedingt diese Konstruktion.
      Ja, weil die Kommunikation zum PC über Serial0charmatch: schon funktioniert. Der MC sollte natürlich von einem PCkonfiguriert werden. Serial0charmatch: und Onrxd: gleichzeitig geht nicht.


      Michael wrote:

      Wie gesagt, hex und ascii nebeneinander und seltsame Abstände und Zeilenumbrüche, wo keine sein dürften.
      at+cpin=1111

      ERROR

      empfängt der PC


      Ca
      [04]RROR
      [04]RROR

      empfängt der MC.
      Als Text.

      Sorry falls ich mich blöd anstelle. Bascom ist nicht die Sprache die mir sehr geläufig ist. Microkontroller sind auch nicht die Jungs die mit mir zusammen in den Sandkasten gepinkelt haben.
    • Pac-Man wrote:

      empfängt der MC.
      Das hast du abgetippt? Dein Bild zeigt was anderes.
      Ich meinte die Ausgabe des Terminalprogramms, die kann man ja speichern.
      Kommen da wirklich eckige Klammern im Text?
      Und welches Kommando hat der MC an das Modul dabei gesendet?

      Wie ich oben schon schrieb, veränderst du die Daten mit deinem Print #2, das willst du doch nicht?

      P.S.: Ähh, wieso sendest du eigentlich Kleinbuchstaben?
    • Michael wrote:

      Das hast du abgetippt? Dein Bild zeigt was anderes.
      Nein. C&P. Das Bild war von heute Vormittag. Das letzte war kurz bevor ich die Nachricht geschrieben hab.

      Michael wrote:

      Ich meinte die Ausgabe des Terminalprogramms, die kann man ja speichern.
      OK, muss ich mal schauen.


      Michael wrote:

      Kommen da wirklich eckige Klammern im Text?
      Siehe Bild.


      Michael wrote:

      Und welches Kommando hat der MC an das Modul dabei gesendet?
      AT+CPIN=1111

      als Antwort kam

      ERROR


      Michael wrote:

      Wie ich oben schon schrieb, veränderst du die Daten mit deinem Print #2, das willst du doch nicht?
      Natürlich nicht. Will einfach nur sehen was der MC empfängt um den String zu zerlegen.


      Michael wrote:

      P.S.: Ähh, wieso sendest du eigentlich Kleinbuchstaben?
      Ist Wurscht. Aus Faulheit? Das SIM800L Modul akzeptiert auch kleine.
      Files
    • Pac-Man wrote:

      Nein. C&P. Das Bild war von heute Vormittag. Das letzte war kurz bevor ich die Nachricht geschrieben hab.
      Also heute Vormittag hatte das kleine a noch einen Apostroph. Das wäre damit ein ganz anderes Zeichen.

      Pac-Man wrote:

      Siehe Bild.
      Das ist wohl dein seltenes Terminalprogramm.
      Das zeigt nicht, was da ist.
      Hol dir Hterm, wenn du sehen willst, was wirklich kommt.
      So kann man leider keine Ausgabe debuggen.

      Pac-Man wrote:

      Ist Wurscht. Aus Faulheit? Das SIM800L Modul akzeptiert auch kleine.
      Ist eben nicht Wurscht.
      Wenn du so nachlässig programmierst, wirst du noch viele Fragen in Foren stellen müssen. a_45_132ca9f5 a_27_b277ca12
    • Michael wrote:

      Hol dir Hterm, wenn du sehen willst, was wirklich kommt.
      OK, werd ich machen.


      Michael wrote:

      Ist eben nicht Wurscht.
      Wenn du so nachlässig programmierst, wirst du noch viele Fragen in Foren stellen müssen.
      OK, Werde mich daran halten die Befehle Groß zu schreiben auch wenn das Modul die Schreibweise mit kleinen Buschstaben akzeptiert. Ausschnitt aus Wikipedia...

      Der AT-Befehlssatz gliedert sich in vier Klassen:
      basic command setDieses Set enthält die grundlegenden Befehle, wie z. B. Hörer auflegen, Lautstärke einstellen. Die Befehle setzen sich aus der Zeichenfolge AT gefolgt von einem Buchstaben und evtl. nachfolgenden Ziffern zusammen. Groß/Kleinschreibung ist egal, da sich diese Zeichen im ASCII nur in einem Bit unterscheiden und dieses Bit ignoriert wird.


      zipp wrote:

      Oder willst vom PC auch senden?
      Ich prüfe den Schaltplan noch mal aber der Aufbau funktioniert in der Praxis. PC und MC sollen beide senden und empfangen können. Natürlich nicht gleichzeitig.
    • Das SIM800L mag jedenfalls max. 4.2V.
      IMHO gibt das sogar noch eine Fehlermeldung aus wenn UB überschritten wird und danach macht das Modul nichts mehr.
      Auch sind die I/O nicht TTL tolerant.
      Hast du das auch beachtet?
      Und meiner Meinung nach (ohne dein Terminalprogramm jetzt zu kennen) würde ich

      Pac-Man wrote:

      [04]RROR
      dahingehend interpretieren, dass da ein sogenanntes nicht druckbares Zeichen daherkommt und das Terminalprogramm das eventuell dann als HEX-Code in eckigen Klammern darstellt.
    • Zitronenfalter wrote:

      dahingehend interpretieren, dass da ein sogenanntes nicht druckbares Zeichen daherkommt und das Terminalprogramm das eventuell dann als HEX-Code in eckigen Klammern darstellt.
      sehe ich auch so, ich würde halt gern mal die ganze Kommunikation sehen (RAW)

      Hier treffen mehrere Fehlerquellen aufeinander:
      1. Hardware
      Verdrahtungsfehler, nicht aktive Pegel durch Dioden, Spannungslevel
      2. Sendung MC-SIM800
      Baudratenfehler, Protokoll, korrekte Zeichen
      3. Antwort SIM800-MC
      Baudratenfehler, Echo
      4. Empfang MC
      Interpretationsfehler durch serial0charmatch, Falsche Daten bei Print #2, Wartezeit in Interrupt durch Softserial(Verschluckte Zeichen)
      5. Sendung MC-PC
      Interpretationsfehler durch Terminalprogramm, Baudratenfehler

      Du siehst, da ist eine Menge Potential.
      Ich würde jetzt einfach mal bei Punkt 1 anfangen und die Hardware prüfen. Also Oszi raus, Kurven anschauen, Logikanalyzer raus und Protokoll checken.
      Das mit der korrekten Spannung hatte ich nicht auf dem Schirm, klar, das wäre Grundvorraussetzung.
    • Danke für Eure Mühe,


      Zitronenfalter wrote:

      Auch sind die I/O nicht TTL tolerant.
      Hast du das auch beachtet?
      Die Spannungsversorgung ist stabil und die I/O sind TTL tolerant. Das Modul läuft seit drei Wochen zuverlässig. Ich habe mit VB.NET damit rumexperimentiert. Niemals Probleme gehabt.


      Zitronenfalter wrote:

      das Terminalprogramm das eventuell dann als HEX-Code in eckigen Klammern darstellt.
      Ja, genau. Aber wo kommen diese Zeichen her?


      Michael wrote:

      4. Empfang MC
      Interpretationsfehler durch serial0charmatch, Falsche Daten bei Print #2, Wartezeit in Interrupt durch Softserial(Verschluckte Zeichen)
      Ich vermute dass hier der Fehler liegt. Was genau meinst Du mit "Interpretationsfehler durch serial0charmatch" ?