Angkot is one of the oldest public transportation systems in Malang, one of the major cities in East Java, Indonesia. It can be traced back to 1931 for its appearance (Novrian, 2025), long before Indonesian independence. Even though the system might be different from what we’re seeing today, one thing remains, it’s cheap and affordable for people.
The Decline of Angkot
However, its popularity has been decreasing ever since. Several factors contribute to this decline—the rise of online transportation, an inadequate fleet, reckless driving, lack of real-time monitoring from the ministry, and long, uncertain waiting times, etc. Perhaps, at this point you’ll ask a few questions.
"Why bother? Why not just move on to the new technology?"
As of this moment when I’m writing this story, three thousand people are on the edge of unemployment (Midaada, 2024). When this condition doesn’t get better, three thousand families will have no chance to make a better future. Three thousand families whose only hope is that the system somehow improves. It’s also getting worse if we’re taking into account the fare of this transportation. It only costs about 5.000 IDR—about 30 cents USD for almost all routes with the longest route spanning for about 18km. You also only charged once, no matter how long the distance you took. Because of this, drivers sometimes overload the passenger, sacrificing other passenger comfort just to get more money, and it is totally understandable considering the very low cost fare. The ministry didn’t seem to pay much attention to them, whether they were overloading, driving recklessly, smoking while driving, or simply speeding.
Introducing Transpubin
And here I am-with two friends and our lecturer—determined to find a way technology can breathe new life into this old system. So what do we really want to propose here? Let us introduce Transpubin, a smart system that integrates real-time location tracking, passenger count, and smart payment, all in one small device powered by ESP32. This device, which we refer to as a node, will be installed in every vehicle. Each node will send its location to a centralized server using a lightweight protocol such as MQTT. Payment data, on the other hand, will use a request–response protocol such as HTTP or HTTPS to ensure reliable transaction handling.
"But why would we need all those sensors to solve these issues? How far could it actually help?"
To answer that, we need to go to the very beginning of this article. In an earlier section, I’m stating that Angkot’s popularity started to decrease dramatically since the appearance of online transportation, but why tho? Turns out, the reason behind it is simply that most of the problems we address in Angkot before are already answered by modern architecture of online transportation.
When using online transportation we don’t have to wait at the side of the road for hours with uncertainty. We just click order and wait for them to arrive with an estimated time of arrival and specified price. The drivers were also strictly monitored and regulated. They can’t speed because the automation detection system will send speed information to their system, thus adding a penalty to the driver, which can result in suspension. Customer complaints were also highly regarded, customer service often takes this matter seriously and didn’t hesitate to take necessary action against the driver. The rating system also makes the driver as kind as possible to increase customer satisfaction with the hope that customers will give them a high rate and avoid complaints. In essence, what online transportation offers isn’t a new kind of vehicle, it’s a new kind of information system. Transpubin aims to give Angkot that same backbone of digital intelligence—visibility, regulation, and trust.
How The System Works
The core idea is straightforward yet powerful. Each node integrates essential sensors, NEO6M for GPS, MFRC-522 for RFID, and an RGB LED indicator, under the control of an ESP32 microcontroller. Because most Angkot routes operate across wide and often infrastructure-limited areas, we opted for GSM modules such as the SIM800 series to send data over cellular networks to a centralized server. Using community-maintained Arduino libraries like TinyGSM and PubSubClient, we implemented both HTTP and MQTT protocols for data transmission with minimal overhead.
Each node publishes its location data to the MQTT broker (we use HiveMQ for this implementation). The backend subscribes to the relevant topics, processes incoming payloads, and rebroadcasts them to the frontend through Server-Sent Events (SSE), enabling real-time visualization as long as the nodes continue transmitting. SSE was chosen over WebSocket due to its lower complexity and native support for unidirectional, event-based updates from server to client. To a passenger, this just means one thing, they can finally see where their Angkot is, live, without waiting endlessly at the roadside.
Among the topics published, one specifically carries location data, providing the current coordinates of each Angkot. These coordinates can be leveraged for various features such as speed estimation, direction detection, and real-time tracking. Each node continuously emits these payloads to the HiveMQ broker, which are then consumed and processed by the backend. Those coordinate data can be utilized into many features, such as speed measure, direction detection, and real-time tracking. Each node will emit these payloads to the HiveMQ which is later consumed by the backend.
{
"vehicleId": "1234xxx",
"lat": "40.6892",
"long": "-74.0445",
"timestamp": 2025-10-15T23:43:14+00:00
}
We store latitude and longitude as strings rather than floating-point numbers to avoid rounding errors that can accumulate during serialization and parsing, especially when coordinates are transmitted frequently.
Based on those data, the backend can theoretically calculate vehicle speed by dividing the distance between two consecutive location points by the time interval between them. However, because the Earth is a sphere, computing distance directly from latitude and longitude requires a spherical geometry formula rather than simple Cartesian math. To address this, we use the Haversine formula, which estimates great-circle distance between two points on a sphere given their latitudes and longitudes.
r is the earth radius (approx. 6371km), phi is the latitude (in radians), and lambda is the longitude (in radians).
After successfully determining the distance between two points—or rather payloads, we can finally use a simple formula by dividing the distance we just calculate using the Haversine formula with the delta from timestamp embedded in each payload. By doing this, we can theoretically estimate each vehicle’s speed and present it to the user and stakeholders.
At first glance, the computation seems straightforward, it looked simple in theory, but real-world conditions reminded us that theory rarely survives the first field test. Just like that when we finally realized that inexpensive GPS modules often struggle under signal obstructions. We had another idea of using signal trilateration to obtain location. The concept itself is benefiting from the fact that the GSM module will get signals from multiple base stations. Each of those base stations will be received as different signal strength from the node. Based on those environmental noise, making distance estimation imprecise without extensive calibration.
Furthermore, our GSM module suffered a similar problem, it often failed to connect under certain conditions. It simply doesn’t get a signal from any provider, rendering the whole system unresponsive. If it is able to send data, it will be at a very slow rate. Well, no wonder why it happens, GSM which only uses 2G signals are often discarded by cellular providers and switched to the latest technology such as 3G, 4G, or even 5G. It is indeed a great idea to get newer models such as SIM7000 series, but our budget simply says no, it is extremely expensive compared to the GSM models.
There was also this one funny moment when I bought the wrong GSM modules. At first, I didn’t know much about the different types, and SIM800 and SIM900 were the ones that popped up in my Google search. Without doing any further research, my brain simply concluded that SIM900 had to be superior—after all, it had a bigger number. But I was completely wrong. The SIM800 was actually smaller, more compact, and supported more frequencies, making it far more reliable. In the end, I bought the newer models anyway, even though both still underperformed under certain conditions.
After numerous trials, we finally managed to get both the GPS and GSM modules working together. We began testing inside the building, on the 9th floor, but the GPS didn’t receive any data at all—it looked completely dead. At first, I thought I’d been scammed with defective units. We moved to the 4th-floor balcony, at least with some view of the sky, yet it still showed no signs of life. Even worse, the GSM module stopped working entirely.
Finally, as a last resort, we tested the system in an open field. To our surprise, it worked flawlessly. The node began receiving coordinates with an error range of about 5 to 10 meters—accurate enough for our needs at that time. We were thrilled; even the GSM module performed perfectly, successfully sending data to the MQTT broker. By then, we understood what we needed to do, mount both the GSM and GPS antennas above the vehicle to ensure a clear line of sight to the sky, even if it was just an interim solution. However, location tracking solved only half of our problem—the other half was determining who was actually inside the vehicle.
The RFID sensor is used to support the smart payment and passenger counting systems. Our first idea was to use a load cell sensor to detect the overall weight of the passenger and it seems promising at first glance. However, judging how crowded a vehicle could be only from its weight sometimes can’t be representative. Because of that, we decided to look the other way around, utilizing the same RFID sensor that was initially used for payment, to detect the number of passengers.
The concept is straightforward. Whenever a passenger boards the vehicle, they are required to tap their ID card on the RFID sensor. The system then registers the card ID to the server and increments the passenger counter for that specific vehicle. Similarly, when a passenger disembarks, they must tap their ID card again. Upon receiving an RFID tap, the system checks whether the corresponding ID already exists in the temporary database. If the ID is found, it can be inferred that the passenger is exiting the vehicle—the counter is decremented, and the ID is removed from the temporary list. Otherwise, if the ID is not found, the passenger is boarding, so the counter is incremented and the ID is added. The algorithm can be summarized in the following pseudocode.
if (card.isPresent()) {
if card.isInDatabase() {
card.remove();
counter--;
} else {
card.add();
counter++;
}
}
However, despite the simplicity of the initial concept, several unexpected challenges emerged. Our first approach was to use the national ID embedded in each citizen’s identification card as the user identifier. This method would have allowed passengers to use their existing ID cards without prior registration, while the server automatically created a new account based on the received ID.
In practice, however, this approach proved infeasible. When attempting to read the card data, the national ID field was found to be encrypted, and no accessible identifier could be retrieved. Due to these technical limitations, we were forced to revise our approach. The system was eventually adapted to rely on the card’s internal identifier, which required manual registration before use—introducing an additional layer of inconvenience compared to the original design. This challenge reminded us of the broader reality of working across multiple domains, where every improvement often reveals new constraints. It also shaped the next phase of our development.
Talking about Transpubin wouldn’t be complete without mentioning its application layer. Three of us come from a web development background—two, including myself, are backend developers with months (if not years) of experience, while the third specializes in machine learning and data engineering. None of us, however, are experts in IoT or embedded systems, which explains why our early prototypes were quite messy. Still, that made our direction clear, we would finish the IoT prototype together, then move swiftly into web development—if time allowed.
As shown earlier, the architecture is simple—a backend server acts as an intermediary between IoT nodes and the client, while also managing user data and payments in the database. Everything went smoothly until we realized one crucial gap—we didn’t have a UI/UX designer to handle the website’s front end. Because of that, we decided to postpone frontend development and focus on the core communication between the IoT node and the backend server. We experimented with various protocols, including REST API, MQTT, and Server-Sent Events (SSE). The biggest challenge came when configuring MQTT to run over WebSocket, since plain TCP connections aren’t well supported through proxies in the classic PubSubClient library. Fortunately, our broker (HiveMQ) natively supports MQTT over WebSocket, which saved us a lot of trouble.
Another major challenge came from the encrypted data inside national ID cards. Initially, we wanted to use this data to automatically fetch user accounts without requiring them to register through our website, which would’ve added an extra layer of complexity. As an interim solution, we simply “pretended” the detected ID from the RFID reader was identical to the user’s national ID. This let us focus on the system’s core functionality first and find a proper solution later as the project evolved.
Future Works
The successful implementation of our proof of concept has proven that the system can work in practice, and it opens a wide range of future research opportunities. The data collected from each node, such as vehicle position, speed, and even passenger count can serve as the foundation for developing more advanced applications and optimizations, such as
- dynamic traffic light control based on real-time traffic density and vehicle speed data collected across multiple nodes,
- public transportation route optimization using aggregated passenger tracking data to identify underused or overcrowded routes,
- passenger behavior analytics, to understand peak usage patterns and improve service planning through data-driven decisions,
- comparative study on quality of service (QoS) using different GSM modules for real-time location transmission, focusing on latency, connection stability, and data throughput under varying signal conditions, and others.
Conclusion
Technology isn’t something we can deny. A war against it can’t be won by any man—only by another technology. Perhaps the effort to revitalize Angkot through modern tools is the right kind of war—one fought not with destruction, but with hope. Transpubin might not solve everything, but it shows that innovation isn’t just about moving forward, sometimes, it’s about looking back and lifting what’s been left behind.
We know Transpubin is still far from perfect. There are many moving parts that require further attention, numerous stakeholders to consider, and countless details that need refinement. The modules fail under bad signal, the sensors sometimes misread, and many ideas remain only on paper. The current prototype, though functional, can also be greatly improved—most notably by replacing the messy wiring with a proper printed circuit board (PCB) design.
But even so, this project is our small attempt to ask a bigger question, can technology revive something that’s been left behind? Maybe the answer isn’t clear yet—but every working prototype, every line of code, every failed test moves us a step closer to understanding how the old and new can coexist.
This project was first conceived for the Gemastik 2025 Smart City Competition. We never made it to the finals—but ideas don’t need trophies to live. I decided to let this one live on, for anyone who still believes that even the most traditional systems can find new life through technology.
Last but not least, I would like to express my deepest gratitude to my friends who have kept this project alive for more than half a year, maintaining their commitment and passion even when things didn’t always go as planned. This project still needs a lot of refinement, but it has come this far because of their dedication. I also want to extend my sincere thanks to our lecturer, who has guided us throughout this journey. Without their support and encouragement, this project would never have become a reality.
If you’re interested in this project, feel free to visit our GitHub and build upon it.
References
Calculate distance between two latitude-longitude points? (Haversine formula). (2017, July 21). Stack Overflow. https://stackoverflow.com/a/27943
Knolleary. (n.d.). GitHub — knolleary/pubsubclient: A client library for the Arduino Ethernet Shield that provides support for MQTT. GitHub. https://github.com/knolleary/pubsubclient
Midaada, A. (2024, July 10). Angkot di Malang Banyak Tak Layak Jalan, Ribuan Sopir Terancam Nganggur. Okezone News. https://news.okezone.com/read/2024/07/10/519/3032457/angkot-di-malang-banyak-tak-layak-jalan-ribuan-sopir-terancam-nganggur
Novrian, A. (2025, August 21). Transformasi Angkot di Kota Malang dari Era Kolonial sampai Sekarang. Jawa Pos Radar Malang. https://radarmalang.jawapos.com/kota-malang/816462540/transformasi-angkot-di-kota-malang-dari-era-kolonial-sampai-sekarang
Vshymanskyy. (n.d.). GitHub — vshymanskyy/TinyGSM: A small Arduino library for GSM modules, that just works. GitHub. https://github.com/vshymanskyy/TinyGSM