End-to-End IoT Soil Monitoring over LoRaWAN

02 / FIELD NOTES

What I Built

I ended up building the system across four layers.

Sensing & electronics

The prototype used an analog NPK soil probe connected through an LM393-based signal-conditioning circuit. I also designed a custom shield so the sensor, LCD, indicators, supporting components, and ESP32 could be connected more cleanly.

Embedded system

An ANTARES LR-ESP201 board based on ESP32 handled the sensor readings, converted them into NPK values, generated the outgoing payload, and drove the local LCD.

LoRaWAN connectivity

The device used an RFM96-class LoRa transceiver on the Indonesian AS920–923 MHz band. It operated as a LoRaWAN Class A end device and connected to the LoRa.id network through nearby gateways.

Cloud & application

Once a gateway received the packet, the data traveled through the network backend into ANTARES. I could inspect the incoming telemetry there and also expose it through a simple Android soil-monitoring application.

System Architecture

The complete flow looked like this:

Soil → NPK Sensor → Signal Conditioning → ESP32 → LoRa → LoRaWAN Gateway → Network → ANTARES → Android App

This architecture became one of the most useful parts of the project.

Each piece could work correctly on its own and the overall system could still fail.

A sensor could produce a reading, but the voltage might not be suitable for the ESP32. The ESP32 could generate the right payload, but the radio link might never reach a gateway. The gateway might hear the device while some of the packets were still lost.

The interesting problem was therefore not any single component. It was getting the complete chain to work together.

03 / LEARNING

By the end of the project, the prototype could complete the full sensing-to-cloud flow.

The electronic measurements showed more than 90% agreement with the analog NPK reference used in the experiment. For packets that successfully reached the platform, the values stored in ANTARES remained consistent with those transmitted by the device.

With a 2400 mAh lithium battery, the prototype ran for roughly five hours with the LCD active and around seven hours without it.

The LoRaWAN tests were probably the more important result.

Reaching a gateway 3.47 km away was impressive, but the test also showed the trade-off clearly: as distance increased and the radio environment became worse, RSSI and SNR degraded and packet loss increased significantly.

So the result was not simply “LoRa works from far away.”

It was a much more useful lesson: LoRaWAN can make long-range, low-bandwidth IoT possible, but coverage does not automatically mean reliable or real-time communication.

Experiment & Testing

Once the prototype worked on the desk, I took it outside.

For the sensing side, I compared readings from the electronic prototype against the analog NPK meter used as the reference in the experiment.

I also measured power consumption with different device configurations, particularly to see how much running the LCD affected battery life.

The more interesting part was the radio test.

I used existing LoRa gateways around Bandung Digital Valley and STO Cimahi and transmitted packets repeatedly from different locations.

Two of the main test distances were:

712 m from the gateway
Average RSSI: −96.9 dBm
Average SNR: 7.28 dB
Average delay: 0.012 s
Packet loss: 20%

3.47 km from the gateway
Average RSSI: −113.3 dBm
Average SNR: −9.69 dB
Average delay: 0.065 s
Packet loss: 61%

During the tests, the device transmitted data every 20 seconds for roughly 30 minutes.

At some indoor test points the connection disappeared completely, which made one thing very obvious: “long range” does not mean obstacles suddenly stop mattering.

04 / NEXT

What I Learned

Before this project, it was easy for me to describe IoT as a sensor connected to a microcontroller that somehow sends data to the internet.

Actually building one made that explanation feel incomplete.

Most of the interesting problems happened between the layers.

The sensor had its own electrical characteristics. The microcontroller expected something else. The radio introduced another set of constraints. Then came network coverage, gateways, packet loss, cloud ingestion, and finally the application consuming the data.

None of those layers existed in isolation.

That became one of the most valuable lessons I took from the project: understanding an IoT product means understanding how its parts influence each other end-to-end.

It was also a useful bridge between the things I had been exposed to during my IoT work and actually building a complete system of my own.

Limitations

Ini tetap skripsi S1 dan bentuknya prototipe, jadi gue juga nggak mau sekarang melihat semua angka di dalamnya seolah-olah itu sudah setara production-grade validation.

Contohnya di bagian sensor.

Waktu itu gue ngebandingin hasilnya dengan NPK meter analog komersial, bukan dengan analisis sampel tanah di laboratorium. Jadi angka >90% lebih tepat dibaca sebagai tingkat kesesuaian terhadap reference device yang gue gunakan, bukan sebagai klaim bahwa sensornya punya absolute accuracy di atas 90%.

Pengujian LoRaWAN-nya juga masih terbatas di beberapa lokasi, gateway, kondisi lingkungan, dan konfigurasi perangkat.

Kalau eksperimen ini dikerjakan lagi dengan standar yang lebih matang, gue bakal memperbanyak titik pengujian di area rural, suburban, dan urban; ngetes lebih banyak konfigurasi antena dan LoRaWAN; pakai beberapa gateway; dan ngumpulin jumlah paket yang jauh lebih besar.

Jadi value dari project ini bukan karena gue berhasil bikin sistem pertanian yang siap dipasang massal.

Value-nya justru ada di proses membuktikan arsitekturnya bisa jalan, lalu mencari tahu di bagian mana sistemnya mulai punya batasan.