ANTARES IoT Platform & LoRAWAN Connectivity Deployment

MY CONTRIBUTION

During my year-long internship, I worked across several layers of Telkom Indonesia’s IoT ecosystem rather than staying inside one narrow engineering scope. My contribution ranged from hardware prototyping—such as PCB design, enclosure development, and antenna experiments—to LoRaWAN gateway setup and field testing. I also supported QA activities and worked with ANTARES on the platform side, including technical documentation and tutorials intended for developers using the platform. What made the experience valuable was the combination of those layers. I could start with a physical device, think about how it communicated over LoRaWAN, understand where the data went once it reached the platform, and then document that flow clearly enough for someone else to reproduce it. At the time, I didn’t think of that as systems thinking. I was simply learning how each piece worked. Looking back, that was exactly what was happening.

PROBLEM

IoT sounds simple when described at a high level: collect data from a device and send it somewhere useful. In practice, every layer introduces its own constraints. The device has to work physically. The antenna has to behave as expected. LoRaWAN coverage depends on gateway placement and the actual environment. Data still needs to reach the platform correctly. And even when the system works technically, it still needs to be understandable enough for another developer to use. The difficult part was rarely one component in isolation. The problem usually appeared in the connection between layers. A device could work while connectivity failed. A network could work while the platform integration was wrong. A platform could work while the documentation made it difficult for anyone else to reproduce the setup. That was the first time I really saw that a system can fail even when many of its individual components are technically fine.

OUTCOME

By the end of the internship, I had gained hands-on exposure across a surprisingly broad part of an IoT system: physical hardware, RF, LoRaWAN connectivity, network testing, IoT platforms, QA, and developer documentation. The immediate impact was technical. My university projects became much more mature because I could move beyond development boards and temporary wiring into proper PCB design, physical enclosures, antenna work, and more deliberate system integration. That technical foundation later helped me move into an IoT System Analyst role after graduation. But the more lasting outcome was not a specific technology. It was learning to see how data moves through a system from the physical world to an application—and how much can go wrong in between.

IMPACT

The biggest impact of this experience was technical literacy. Not technical depth for the sake of becoming the strongest engineer in the room, but enough understanding to see how different layers depend on each other and ask better questions when something goes wrong. That became surprisingly useful after I moved into Product Management. When engineers later talked about APIs, data flows, network constraints, integrations, or application behavior, those conversations did not feel like complete black boxes. I could usually build a mental model of where the information came from, what it passed through, and where a problem might actually be happening. The documentation work also stayed with me. Writing technical tutorials taught me that understanding something and explaining it are two different skills. Years later, the same habit became useful when writing product requirements: if engineers and QA cannot understand the context, expected behavior, and constraints without repeatedly asking what I meant, then the communication is still incomplete. The tools changed. The underlying skill did not.