A Self-Configurable IoT Gateway Using Cellular Module Without Native Library Support: Web-Based Integration of SMS, GPS, and Cloud Data Acquisition

Imagine a world where your toaster, your garden hose, and even your remote mountain cabin can talk to each other. This is the Internet of Things (IoT), a massive network of everyday objects that have been given a voice. Usually, these gadgets chat over Wi-Fi, but what happens when you are in the middle of a desert, a deep forest, or a farm where Wi-Fi doesn't exist? That's where cellular networks come in, acting like a giant, invisible telephone wire stretching across the entire planet. But here's the catch: teaching a tiny, cheap computer how to use a cellular phone is like trying to teach a toddler to drive a race car. The instructions (called "AT commands") are complex, and the car (the cellular module) often doesn't speak the same language as the driver (the computer). Without a translator, developers have to write thousands of lines of code just to make a simple connection, which is slow, difficult, and prone to breaking.

This is the problem Lucas Lima Freitag tackled in a new research paper. He built a smart "gateway"—a bridge between the physical world and the cloud—that doesn't rely on pre-made translators or complicated libraries. Instead, it speaks directly to the cellular module using raw instructions, giving it total control. The result is a system that can automatically switch between different generations of cell networks (from old 2G to modern 4G), track your location, send text alerts, and upload data to the cloud, all while being controlled through a simple web page you can open on your phone. It's a self-configuring robot that knows how to find a signal even when the network is tricky, making it possible to monitor remote places without needing a team of engineers to set it up.

The Self-Driving Cellular Gateway

Think of the device described in this paper as a tiny, super-smart robot that lives inside a box. Its job is to gather information (like temperature or humidity) and send it to a giant digital notebook in the sky (the cloud). But this robot has a special superpower: it doesn't need a manual or a pre-installed app to figure out how to talk to the cell tower.

Most people who build these devices use "libraries," which are like pre-written instruction books that tell the computer how to talk to the cellular module. But for the specific modules used in this project (the SIM7600 and A7670SA), those instruction books didn't exist. So, the author had to write the instructions from scratch, speaking directly to the module using "AT commands." Imagine trying to order a pizza by speaking directly to the chef in a language you've never heard before, rather than using a menu. That's what this system does. It sends raw commands like "Hello, connect to the network" or "Send this data," and listens carefully to the answers.

The Two-Brain System

One of the coolest tricks this device uses is a "dual-core" design. Imagine a human with two brains. One brain (Core 0) is obsessed with the phone call. It handles all the talking to the cell tower, waiting for signals, and sending data. The other brain (Core 1) is the social butterfly. It runs a web server, which is like a mini-website hosted right on the device.

Why is this important? Usually, if a computer is busy talking to a cell tower, it freezes up and can't respond to your mouse clicks or touch screen. But because this device has two brains, you can open a web browser on your phone, type in a password, or change settings, and the "social brain" will handle it instantly, even while the "phone brain" is in the middle of a long, complicated connection process. They talk to each other through a synchronized queue, like passing notes in a classroom, ensuring nothing gets lost.

The Shape-Shifting Network

The most impressive feature is how the device finds a signal. In the real world, cell coverage is messy. Sometimes 4G is fast but hard to connect to; sometimes 2G is slow but available everywhere. This device has a "fallback" strategy, which is like a traveler who tries the fastest train first, but if it's full, they immediately try the bus, then a taxi, and finally a bicycle.

The system automatically tests 5G, 4G, 3G, and 2G networks in order. It doesn't just guess; it actually tries to register on each one. The research found something surprising: while 4G is great for sending lots of data quickly, it takes a long time to start the connection (about 11.8 seconds). In contrast, the older 2G network is much faster to connect (only 3.4 seconds), even though it sends data more slowly. This means for devices that just need to send a small message occasionally, the "slow" 2G network is actually the most efficient choice because it wakes up and connects almost instantly. The device figures this out on its own and picks the best option for the job.

The "Batch" Delivery System

Sending data over a cellular network is expensive and slow because every time you send a message, you have to pay a "connection fee" in time and energy. Imagine if you had to walk to the post office, buy a stamp, mail a letter, walk back, and repeat that 30 times just to send 30 photos. That's how most IoT devices work.

This new system uses a "buffered" approach. Instead of sending one message at a time, it waits and collects 10 readings (like 10 temperature checks) and packs them all into a single JSON file. Then, it sends them all at once in one big HTTP request. The paper shows this reduces the network overhead by about 95%. It's like filling a single large truck with 30 packages instead of sending 30 separate bicycles. This saves a massive amount of battery power and data.

The Web-Based Control Center

Perhaps the most user-friendly part of this project is the interface. You don't need to plug the device into a computer or write code to set it up. The device creates its own Wi-Fi hotspot. You walk up to it with your phone, connect to it, and open a web page. This page has tabs for everything:

• WiFi: To tell the device which local network to join.
• Cloud: To enter your secret keys for the TagoIO cloud platform.
• Network: To choose your phone carrier and APN settings.
• GPS: To see a live map of where the device is.
• SMS: To send text messages or set up alerts if something goes wrong.

This turns a complex engineering project into something anyone can configure with a browser, making it accessible for farmers, researchers, or hobbyists who want to monitor remote areas without being coding experts.

What the Numbers Say

The author tested this system rigorously in an urban area in Natal, Brazil. The results were clear:

• Connection Speed: 2G connected in an average of 3.4 seconds, while 4G took 11.8 seconds.
• Data Speed: Once connected, 4G was much faster at moving data, but the total time to send a message was often better on 2G for small packets because the connection started so quickly.
• GPS: The device could find its location using satellites in about 35 to 42 seconds on a cold start, and if satellites were blocked, it could estimate its location using cell tower triangulation.
• Power: The device draws about 80 mA when idle, but spikes to 1.2 A (1200 mA) when sending data over 4G. This is why the design uses a separate, powerful power supply; the tiny computer chip inside couldn't handle the surge on its own.

The Bottom Line

This paper proves that you don't need fancy, pre-made software libraries to build a powerful IoT gateway. By speaking directly to the hardware and using a smart, two-brain architecture, you can create a device that is flexible, efficient, and easy to set up. It suggests that for remote monitoring, especially in areas where signals are weak or data is sent infrequently, the "old" 2G network might actually be the hero, offering the fastest connection times. While the system currently uses unencrypted HTTP (which is less secure) and relies on simulated data for testing, the open-source code is available for anyone to download, improve, and adapt for real-world use. It's a reminder that sometimes, the simplest way to solve a complex problem is to stop relying on shortcuts and just talk directly to the machine.