Send SMS with Arduino UNO and SIM900D using AT Commands

Hello friends! Today, we will send an SMS with an Arduino UNO and a SIM900D GSM module using AT commands. We will start with the connections, check that the modem can communicate with the mobile network, and then let the Arduino submit one message. You will also learn how to tell the difference between a successful command and a message that has actually reached its recipient.

The SIM900D handles the radio connection and SMS service. The Arduino sends instructions through a serial connection and reads the modem's replies. We do not need a separate GSM control library for this example; we will use the Arduino serial facilities and send the commands ourselves. This makes the exchange easier to follow when something goes wrong.

This tutorial concerns a legacy 2G modem. Before building the circuit, confirm that a compatible 2G network and SMS service are available from your operator at the installation location. A SIM card that works in a modern phone does not establish that this modem can register. Network retirement is an important consideration for an existing SIM900D project, as discussed in the GSMA network sunset guidance.

What We Need for the SMS Project

For a first experiment, use a documented SIM900D carrier board rather than attempting to power and connect the surface-mount modem directly. Carrier boards differ in their regulators, serial interfaces and power buttons. Identify your board before applying power; two boards carrying the same modem can require different external connections.

The original article included the following vendor links for the UNO and modem. They are retained as historical references, rather than a current price comparison. Check the actual product description and interface requirements before choosing a board.

Understand the Power and Serial Connections

According to the SIMCom SIM900D hardware design guide, the bare module uses a 3.2–4.8 V supply and can demand approximately 2 A during transmit bursts. Those are module requirements, not a universal specification for the power connector on every carrier board. Follow the carrier schematic for its external input.

Do not treat the UNO's small auxiliary power output as a modem supply. The circuit may answer AT commands while idle and reset as soon as the transmitter becomes active. That failure can look like a software timeout even though the cause is a voltage dip. Use a supply and wiring arrangement intended for the modem's load.

Here is a useful wiring calculation. If the combined resistance of the supply and return leads is 0.20 ohm, a 2 A burst produces a voltage drop of V = I × R = 0.40 V. Starting with a nominal voltage that seems adequate does not eliminate that drop. Measure at the modem supply pins, and use an oscilloscope when a brief reset cannot be explained by a steady multimeter reading.

The bare modem's UART is not an RS-232 port and must not receive RS-232 positive and negative voltages. It also must not be assumed tolerant of the UNO's 5 V transmit signal. Use the level interface recommended by the module or carrier documentation. A board marked TX and RX may expose either translated signals or the modem's native logic signals.

Keep the USB Debugging Port Separate

The original circuit used UNO pins 0 and 1. Those pins are also involved in the UNO's USB serial connection, so an attached modem can interfere with uploading or with messages sent from the computer. In the revised example, we use pins 7 and 8 for the modem and reserve the hardware serial port for debugging.

The photograph above identifies the connections on the board used in the original project. Use it to understand the arrangement, but confirm labels against your own hardware. In particular, the earlier instruction to leave PWRKEY grounded should not be followed as a general rule. SIMCom specifies a low pulse of at least one second for powering on the bare module, followed by release. A carrier may implement that action with a push button or other circuitry.

Check the Modem Before Sending an SMS

First establish a serial conversation. We will use 9600 baud in the example, but the modem must also be operating at that rate or successfully synchronize through its supported autobaud behavior. Random characters usually indicate a baud or electrical problem; changing the SMS text will not help.

A temporary serial bridge lets you type commands into the Arduino Serial Monitor and see the replies. Upload this small sketch first, select 9600 baud, and configure the monitor to send a carriage return after each command. Leave the modem disconnected from UNO pins 0 and 1.

#include <SoftwareSerial.h>
SoftwareSerial modem(7, 8); // RX, TX

void setup() {
  Serial.begin(9600);
  modem.begin(9600);
}

void loop() {
  if (modem.available()) Serial.write(modem.read());
  if (Serial.available()) modem.write(Serial.read());
}

Use the following sequence, reading the complete reply after each command. These are SIM900-family commands documented in the SIMCom AT command manual. An echoed copy of your command is not confirmation that the command succeeded.

If the SIM requests a PIN, resolve that deliberately before continuing. Do not repeatedly guess a PIN in an automated loop. If registration fails, investigate the antenna, operator support, SIM provisioning and power supply. A blinking status LED can help, but the meaning of its pattern belongs to the particular board documentation.

How the SMS Command Exchange Works

Sending the destination and sending the message are separate steps. After selecting text mode, the Arduino sends AT+CMGS="recipient" followed by a carriage return. It waits for the modem's > prompt before sending the body. The byte 0x1A, equivalent to Ctrl+Z, ends the body and requests submission.

The modem then performs network work. A successful submission produces a +CMGS: message reference and a final OK; an error may produce +CMS ERROR:. A timeout means our program did not observe a conclusive result. It does not prove that the network never accepted the message. This distinction matters because automatically retrying an uncertain submission can send duplicates.

For a first test, choose a short plain-text message and a recipient you control. Keep the message simple while establishing the hardware and protocol. Longer text, non-Latin characters and multipart messages introduce encoding and billing considerations that deserve a separate implementation.

Arduino Sketch for One Deliberate SMS Attempt

The following example prints the modem conversation to the Serial Monitor. Replace the destination placeholder, complete the readiness checks above, and type an uppercase S to request one attempt. The program locks that attempt until the Arduino is reset. It does not repeatedly send messages from loop().

The receive function recognizes complete result lines, detects explicit errors, and has a timeout. Its fixed-size line buffer also prevents an unexpectedly long reply from overwriting memory. This is a teaching example with blocking waits; a controller that must perform other time-sensitive tasks should use a nonblocking state machine and a suitable hardware UART.

#include <SoftwareSerial.h>
#include <string.h>

SoftwareSerial modem(7, 8);
const char destination[] = "+REPLACE_ME";
bool attempted = false;

// mode 0: final OK; mode 1: SMS prompt; mode 2: +CMGS then OK
bool waitReply(byte mode, unsigned long timeoutMs) {
  char line[96];
  byte used = 0;
  bool overflow = false;
  bool referenceSeen = false;
  unsigned long started = millis();
  while (millis() - started < timeoutMs) {
    if (!modem.available()) continue;
    char c = modem.read();
    Serial.write(c);
    if (mode == 1 && c == '>') return true;
    if (c == '\r') continue;
    if (c != '\n') {
      if (used < sizeof(line) - 1) line[used++] = c;
      else overflow = true;
      continue;
    }
    line[used] = '\0';
    if (overflow) return false;
    if (strcmp(line, "ERROR") == 0 ||
        strncmp(line, "+CMS ERROR", 10) == 0 ||
        strncmp(line, "+CME ERROR", 10) == 0) return false;
    if (strncmp(line, "+CMGS:", 6) == 0) referenceSeen = true;
    if (strcmp(line, "OK") == 0 &&
        (mode == 0 || (mode == 2 && referenceSeen))) return true;
    used = 0;
  }
  return false;
}

bool command(const char *text) {
  modem.print(text);
  modem.write('\r');
  return waitReply(0, 3000);
}

bool configuredNumber() {
  if (destination[0] != '+') return false;
  size_t length = strlen(destination);
  if (length < 8 || length > 16) return false;
  for (size_t i = 1; i < length; ++i)
    if (destination[i] < '0' || destination[i] > '9') return false;
  return true;
}

void sendOneMessage() {
  if (!command("AT") || !command("ATE0") || !command("AT+CMGF=1")) {
    Serial.println(F("Setup failed. Check the printed modem reply."));
    return;
  }
  modem.print(F("AT+CMGS=\""));
  modem.print(destination);
  modem.print(F("\"\r"));
  if (!waitReply(1, 10000)) {
    modem.write(0x1B); // Escape any incomplete text-entry operation
    Serial.println(F("No SMS prompt. No message body was submitted."));
    return;
  }
  modem.print(F("Hello from the Arduino UNO SMS project."));
  modem.write(0x1A);
  if (waitReply(2, 60000))
    Serial.println(F("Submission accepted. Check the receiving phone."));
  else
    Serial.println(F("Submission unconfirmed or rejected. Do not retry blindly."));
}

void setup() {
  Serial.begin(9600);
  modem.begin(9600);
  Serial.println(F("Complete SIM/network checks first. Type S for one attempt."));
}

void loop() {
  while (modem.available()) Serial.write(modem.read());
  if (!Serial.available()) return;
  char key = Serial.read();
  if (key != 'S' || attempted) return;
  if (!configuredNumber()) {
    Serial.println(F("Set destination to your international-format number."));
    return;
  }
  attempted = true;
  sendOneMessage();
}

Upload and Run the Example

1. Power down before changing connections, and confirm that the UART interface matches both devices.
2. Upload the sketch with your destination number in international format.
3. Start the modem using its documented procedure and allow it to register.
4. Open the Serial Monitor at 9600 baud. Confirm that the SIM and registration checks were successful using the bridge sketch before relying on this example.
5. Type S once. Read the complete conversation rather than judging success from the first received character.
6. Check the receiving phone and retain the result printed by the modem.

Opening the Serial Monitor can reset an UNO. The explicit S trigger prevents that reset alone from immediately sending another message. Resetting does clear the attempt lock, however, so this sketch is not a durable duplicate-prevention system. A deployed alarm needs persistent event identifiers and an intentional retry policy.

Troubleshooting the First Message

Change one variable at a time. For example, do not simultaneously replace the supply, change baud rate and rewrite the receive routine. A short log containing the command, reply and observed power behavior makes the next decision much easier. Remove personal numbers from a log before sharing it publicly.

Timing and Message-State Decisions

The serial link and the cellular network operate on different timescales. With an ordinary 8N1 serial frame, each character uses one start bit, eight data bits and one stop bit. At 9600 baud, a 40-character command takes approximately 40 × 10 / 9600 = 0.0417 seconds to leave the UART. This calculation describes transmission to the modem, not the time needed for the modem to finish the requested operation.

That is why a delay chosen from the command's character count cannot predict SMS completion. The example gives basic commands three seconds and allows a longer interval after submission. These are example application timeouts, not a promise that every network will respond within them. Record the actual result and choose timeout behavior appropriate to the application.

A useful application model has five states: idle, preparing, waiting for the text prompt, waiting for submission result, and finished. Each transition needs an observable reason. An OK completes a preparation command, the prompt permits the body, and the combined message reference and final OK establish accepted submission. An error or timeout enters a separate failure or uncertain-result path.

Keep incoming unsolicited messages separate from command responses in a production driver. A modem can report a network change or an incoming SMS while the application is waiting for another result. Our example prints those lines for inspection, but it does not implement an incoming-message service. A larger program needs to dispatch such notifications without confusing them with the reply to the command currently in progress.

A Small, Controlled Test Record

Before connecting an alarm input, carry out a few deliberate tests with the recipient's agreement. Start with one normal submission and record the modem result, whether the phone received it, and the approximate delay. Next, test the program with the destination placeholder still present; it should refuse to start. Finally, disconnect the modem's serial connection while powered down and confirm that the program reports a communication failure after reconnecting power, rather than reporting a successful message.

These tests answer different questions. The normal case checks the complete path. The placeholder case checks a local configuration guard. The missing-modem case checks that absence of a reply is handled. None of them establishes long-term coverage or proves that a recipient will always receive an alert. Keep that distinction in the project notes so a successful bench demonstration is not mistaken for a reliability guarantee.

Also decide what should happen after power returns. Sending an alert immediately on every restart may produce repeated messages during an unstable supply condition. Conversely, forgetting an unsent event can hide a genuine alarm. Store enough event state to implement the behavior you intend, and make that behavior explicit before adding automatic retries.

Review of the AT-Command Approach

Direct AT commands are useful because we can inspect every step. We know whether the problem happened before the modem responded, during network registration, before text entry or after submission. The tradeoff is that our program must handle those states correctly. A received byte, a fixed delay or an echoed command cannot replace a parsed result.

For a larger project, separate the application event from the modem driver. A temperature alarm should create one pending alert when its threshold condition begins, rather than sending on every loop while the temperature remains high. Add hysteresis, a clear rearming condition and a record of the last submission. This keeps application behavior understandable even when the mobile network is slow.

You can continue with receiving SMS with SIM900 and Arduino, or adapt the same command exchange to a PIC microcontroller SMS project. Our GSM Library for Proteus and SIM900D SMS simulation are useful for studying program flow. A simulation does not establish real network coverage, RF performance or power-supply reliability.

Frequently Asked Questions

Can I use a SIM900 or SIM900A board instead?

Many basic SMS commands are shared across the family, but verify the exact modem manual, frequency bands, power connector and UART interface. The similarity of command names does not make all carrier boards electrically interchangeable.

Does this require an internet connection or an APN?

This example uses SMS rather than an internet data session. It needs usable cellular SMS service. Do not add HTTP or GPRS configuration to solve a basic serial communication problem; establish the SIM and registration state first.

Why do we wait for the greater-than prompt?

The prompt tells us that the modem has entered message-body input. Sending the body earlier can cause it to be interpreted in the wrong command state. The example sends Ctrl+Z only after receiving that prompt.

Does OK mean that the recipient read the message?

No. Even a completed submission is different from delivery to the handset, and delivery is different from a person reading the text. Implement and interpret delivery reports separately if the application requires them.

Can I use this sketch unchanged as a remote alarm?

Use it as a starting point. A remote system needs event handling, a recovery strategy, power monitoring and a supported communications service. First make the single-message exchange reliable and understandable, then add those requirements deliberately.