You have a sensor working on the bench. Now you want to leave it at a field site and receive its readings without asking anyone for a Wi-Fi password. A cellular module looks like the missing piece: insert a SIM, connect a few wires, send the data.
The first test can mislead you. In a September 2026 r/arduino thread, a builder's SIM800L indicator seemed to show a network connection, yet the module would not answer AT commands or place a call. The cause was not settled, but it shows why a status light, a serial reply and a delivered message each need their own check.
On our bench we connected a GraftSense SIM800C board to a GraftPort-RP2040 and queried basic modem information. We did not complete a call, a text message or a data upload. This note covers what the test does show, and how to decide whether to keep debugging the bench setup or reconsider the cellular hardware before building more units.
Check the network before designing around the module
The SIM800C is a 2G GSM/GPRS module. SIMCom's product page lists four bands: 850, 900, 1800 and 1900 MHz. A newer SIM card does not add a 4G radio. Equally, a SIM sold for newer networks is not automatically unusable; the provider has to confirm which technologies and services the subscription allows.
For a product meant to stay in the field, ask both "can it connect here?" and "for how long?" VodafoneThree's March 2026 announcement sets the Vodafone UK 2G switch-off for spring 2030, with some local retirement possibly earlier. That is one operator's schedule, not a worldwide deadline. Confirm the deployment country, the underlying network and the service lifetime with your actual connectivity provider.
We stopped at information queries partly because of those retirement concerns. The test is a useful modem-control lesson, not a reason to choose 2G for a new field product. If the provider cannot support your deployment, choose the network technology first and test a suitable module next.
Separate the modem from the board that powers it
The metal-shielded SIM800C is one part of this assembly. The board adds a voltage regulator, SIM holder, separate GSM and Bluetooth antenna connectors, a power button and audio connections. Those make experimenting easier, and their ratings are not the modem's own.
SIMCom specifies 3.4 to 4.4 V at the modem's VBAT pins, and its hardware manual describes transmit bursts of up to 2 A. The practical question is whether the supply holds the required voltage at the modem during those bursts; a big current number on an adapter does not answer it.
Our own records disagreed on the input. Our setup notes called for a 6 V, 2 A supply, while the board's terminal is marked 5V/2A and the schematic labels the regulator input 5 V. Confirm the fitted board's input before powering it. Neither 5 V nor 6 V belongs directly on the bare modem's VBAT pins.
We powered the board from its separate supply terminal, with the serial cable carrying only control signals. That matters if you planned to run the whole assembly from a small development-board power pin. Keep the modem's supply path and the controller's signal reference clear.
Logic levels need the same care. A blanket claim that every expansion signal accepts 1.8 V, 3.3 V and 5 V is not a wiring rule. SIMCom's hardware manual shows level-matching circuits, and the board schematic has resistors on the UART lines. Check the specific connector and board revision instead of treating bare modem pins as general-purpose 5 V inputs.
The information query
We put a SIM in the holder on the back of the board and connected the controller's UART0 (GP16 transmit, GP17 receive) at 9600 baud. Power down before inserting or removing a SIM. The connector labels use the controller's point of view: MTX is the controller's transmit line, going to the modem's receive path, and MRX brings the modem's output back. Confirm that against your board's schematic and cable.
Our driver package's install notes named version 1.0.0, while the copy we actually used was 1.0.1, and its README showed a constructor that did not match the code. Record the exact package you run.
The program asked for the manufacturer string (AT+CGMI) and signal quality (AT+CSQ). An AT command is a text instruction sent over the serial link. The driver appends a carriage return, waits briefly and collects reply bytes for a bounded time. If a module stays silent, first establish that instructions and replies can travel between the two boards at all.
Two details in our first program are worth changing in yours. It printed "initialized successfully" before it had even created the UART object, and the driver sent its initialization commands without checking the replies. Treat a real, expected reply from the modem as the result, not a reassuring line printed by your own script.
Read the result before moving on
The terminal showed a manufacturer response and an RSSI of 0. In SIMCom's AT command manual, 0 means −115 dBm or less. A value of 99 means unknown or not detectable, which is not quite the same as "no signal." Either way, a signal report does not tell you whether the SIM is registered or whether a server got your data.
So the result is useful but limited: the setup exchanged enough to display modem responses. It does not establish a working remote sensor link, and we have no registration response or delivered-message record.
To extend the bench test, keep the checks separate:
| Check | What it establishes | What still needs checking |
|---|---|---|
AT returns OK |
The modem answers over serial | SIM readiness and service access |
AT+CPIN? reports READY |
The modem is not waiting for a SIM PIN | Network registration |
AT+CREG? reports registration |
GSM registration state | The required service and delivery |
AT+CGREG? reports registration |
GPRS registration state | Data-session setup and the receiving application |
| The receiving application logs a test message | That path delivered that message | Recovery, repeated operation, field conditions |
For SIM800 registration queries, status 1 means registered on the home network and 5 means roaming; 2 means searching and 3 means denied. In a reply such as +CREG: 0,1, the status is the second value. These meanings come from the SIM800 Series AT Command Manual V1.10, available through SIMCom's documentation portal. Other cellular families can use different commands and procedures.
Choose the next prototype around a real deployment
For a field sensor, describe the job before choosing the replacement radio: where it operates, whether it moves, how often and how much it sends, how it is powered, and what should happen when delivery fails. Ask the connectivity provider which technologies and modules fit that job, then test the module, SIM, firmware and destination service together.
Keep the next bench test small. Send one identifiable reading, confirm it at the receiving application, and record how long it took. Then interrupt the connection and check whether the device recovers and handles the pending reading in a way your application can tolerate. That tells you more about a first field trial than a terminal full of startup messages.
Only then make the enclosure part of the test: repeat the same task with the intended antenna position, power wiring and case, and leave room to reach the SIM, power and antenna connectors. A bench photo of a bare board says nothing about antenna performance inside a finished housing.