TinyGSM
v0.12.0
A small Arduino library for GSM modules, that just works.
If you like TinyGSM - give it a star, or fork it and contribute!
You can also join our chat:
This library is easy to integrate with lots of sketches which use Ethernet or WiFi. PubSubClient (MQTT), Blynk, HTTP Client and File Download examples are provided.
The complete WebClient example for Arduino Uno (via Software Serial) takes little resources:
Sketch uses 15022 bytes (46%) of program storage space. Maximum is 32256 bytes.
Global variables use 574 bytes (28%) of dynamic memory, leaving 1474 bytes for local variables. Maximum is 2048 bytes.
Arduino GSM library uses 15868 bytes (49%) of Flash and 1113 bytes (54%) of RAM in a similar scenario. TinyGSM also pulls data gently from the modem (whenever possible), so it can operate on very little RAM. Now, you have more space for your experiments.
Watch this repo for new updates! And of course, contributions are welcome ;)
Data connections
USSD
SMS
Voice Calls
Location
Credits
AT command using this sketchThe general flow of your code should be:
#define TINY_GSM_MODEM_SIM800#include TinyGsm modem(SerialAT);TinyGsmClient client(modem);
or
TinyGsmClientSecure client(modem); (on supported modules)TinyGsmClient clientX(modem, 0);, TinyGsmClient clientY(modem, 1);, etc
orTinyGsmClientSecure clientX(modem, 0);, TinyGsmClientSecure clientY(modem, 1);, etcmodem.init() or modem.restart()modem.simUnlock(GSM_PIN)modem.networkConnect(wifiSSID, wifiPass)modem.waitForNetwork(600000L)modem.gprsConnect(apn, gprsUser, gprsPass) (or simply modem.gprsConnect(apn))client.connect(server, port)Many GSM modems, WiFi and radio modules can be controlled by sending AT commands over Serial. TinyGSM knows which commands to send, and how to handle AT responses, and wraps that into standard Arduino Client interface.
This library is "blocking" in all of its communication.
Depending on the function, your code may be blocked for a long time waiting for the module responses.
Apart from the obvious (ie, waitForNetwork()) several other functions may block your code for up to several minutes.
The gprsConnect() and client.connect() functions commonly block the longest, especially in poorer service regions.
The module shutdown and restart may also be quite slow.
This libary does not support any sort of "hardware" or pin level controls for the modules. If you need to turn your module on or reset it using some sort of High/Low/High pin sequence, you must write those functions yourself.
For GPRS data streams, this library provides the standard Arduino Client interface. For additional functions, please refer to this example sketch
Most modules require as much as 2A to properly connect to the network. This is 4x what a "standard" USB will supply! Improving the power supply actually solves stability problems in many cases!
Most modules support some sort of "auto-bauding" feature where the module will attempt to adjust it's baud rate to match what it is receiving.
TinyGSM also implements its own auto bauding function (TinyGsmAutoBaud(SerialAT, GSM_AUTOBAUD_MIN, GSM_AUTOBAUD_MAX);).
While very useful when initially connecting to a module and doing tests, these should NOT be used in any sort of production code.
Once you've established communication with the module, set the baud rate using the setBaud(#) function and stick with that rate.
Sometimes (especially if you played with AT commands), your module configuration may become invalid. This may result in problems such as:
To return module to Factory Defaults, use this sketch: File -> Examples -> TinyGSM -> tools -> FactoryReset
In some cases, you may need to set an initial APN to connect to the cellular network.
Try using the gprsConnect(APN) function to set an initial APN if you are unable to register on the network.
You may need set the APN again after registering.
(In most cases, you should set the APN after registration.)
The first connection with a new SIM card, a new module, or at a new location/tower may take a LONG time - up to 15 minutes or even more, especially if the signal quality isn't excellent. If it is your first connection, you may need to adjust your wait times and possibly go to lunch while you're waiting.
If you are able to open a TCP connection but have the connection close before receiving data, try adding a keep-alive header to your request. Some modules (ie, the SIM7000 in SSL mode) will immediately throw away any un-read data when the remote server closes the connection - sometimes without even giving a notification that data arrived in the first place. When using MQTT, to keep a continuous connection you may need to reduce your keep-alive interval (PINGREQ/PINGRESP).
Use this sketch to help diagnose SIM card and GPRS connection issues: File -> Examples -> TinyGSM -> tools -> Diagnostics
If the diagnostics fail, uncomment this line to output some debugging comments from the library:
#define TINY_GSM_DEBUG SerialMonIn any custom code, TINY_GSM_DEBUG must be defined before including the TinyGSM library.
If you are unable to see any obvious errors in the library debugging, use StreamDebugger to copy the entire AT command sequence to the main serial port. In the diagnostics example, simply uncomment the line:
#define DUMP_AT_COMMANDSIn custom code, you can add this snippit:
#ifdef DUMP_AT_COMMANDS
#include <StreamDebugger.h>
StreamDebugger debugger(SerialAT, SerialMon);
TinyGsm modem(debugger);
#else
TinyGsm modem(SerialAT);
#endifThis library opens a TCP (or SSL) connection to a server. In the OSI model, that's layer 4 (or 5 for SSL). HTTP (GET/POST), MQTT, and most of the other functions you probably want to use live up at layer 7. This means that you need to either manually code the top layer or use another library (like HTTPClient or PubSubClient) to do it for you. Tools like PostMan also show layer 7, not layer 4/5 like TinyGSM. If you are successfully connecting to a server, but getting responses of "bad request" (or no response), the issue is probably your formatting. Here are some tips for writing layer 7 (particularly HTTP request) manually:
client.print("..."), or client.write(buf, #), or even client.write(String("...")), not client.write("...") to help prevent text being sent out one character at a time (typewriter style)client.print(String("GET ") + resource + " HTTP/1.1rn");client.print("GET ");
client.print(resource);
client.println(" HTTP/1.1")client.print("....rnrn") or put in an extra client.println()When using SoftwareSerial (on Uno, Nano, etc), the speed 115200 may not work.
Try selecting 57600, 38400, or even lower - the one that works best for you.
In some cases 9600 is unstable, but using 38400 helps, etc.
Be sure to set correct TX/RX pins in the sketch. Please note that not every Arduino pin can serve as TX or RX pin.
Read more about SoftSerial options and configuration here and here.
When using ESP32 HardwareSerial, you may need to specify additional parameters to the .begin() call.
Please refer to this comment.
You will not be able to compile the HttpClient or HttpsClient examples with ESP32 core 1.0.2. Upgrade to 1.0.3, downgrade to version 1.0.1 or use the WebClient example.
When using SAMD21-based boards, you may need to use a sercom uart port instead of Serial1.
Please refer to this comment.
It turns out that Goouuu Tech IOT-GA6 is not the same as AI-Thinker A6. Unfortunately IOT-GA6 is not supported out of the box yet. There are some hints that IOT-GA6 firmware may be updated to match A6... See this topic.
Some, but not all, versions of the SIM800 support SSL. Having SSL support depends on the firmware version and the individual module. Users have had varying levels of success in using SSL on the SIM800 even with apparently identical firmware. If you need SSL and it does not appear to be working on your SIM800, try a different module or try using a secondary SSL library.
There are two versions of the SIM7000 code, one using TINY_GSM_MODEM_SIM7000 and another with TINY_GSM_MODEM_SIM7000SSL.
The TINY_GSM_MODEM_SIM7000 version does not support SSL but supports up to 8 simultaneous connections.
The TINY_GSM_MODEM_SIM7000SSL version supports both SSL and unsecured connections with up to 2 simultaneous connections.
So why are there two versions?
The "SSL" version uses the SIM7000's "application" commands while the other uses the "TCP-IP toolkit".
Depending on your region/firmware, one or the other may not work for you.
Try both and use whichever is more stable.
If you do not need SSL, I recommend starting with TINY_GSM_MODEM_SIM7000.
This project is released under The GNU Lesser General Public License (LGPL-3.0)
