Building LOKA: From ESP32 Firmware to a Live Map That Tracks Animals in Real Time

A few months ago I set out to solve a very physical problem with software: how do you know where your animals are, right now? Herders and small farmers lose animals that wander past a safe boundary, and by the time anyone notices, the animal — and the money it represents — is long gone.

So I built LOKA: a full-stack IoT platform that puts a low-cost GPS tracker on an animal and turns it into a live dot on a map, with an alert the moment it strays outside a safe zone. It runs end to end — custom firmware on a microcontroller, a Node.js API, and a real-time web dashboard.

This is the story of how it works and, more usefully, the parts that broke and how I fixed them.

🌍 Live demo: https://loka-livetrack.vercel.app

The architecture

The whole system is three moving pieces:

[ ESP32-S3 tracker ]  --HTTP-->  [ Node.js / Express API ]  -->  [ React + Leaflet dashboard ]
  GPS + LoRa + WiFi              position history, alerts         live map, trail, battery

1. A Heltec ESP32-S3 on the animal reads GPS coordinates and POSTs them to a server every ~10 seconds.
2. A Node.js / Express API stores position history and works out whether a tracker is online or offline.
3. A React dashboard (Leaflet + OpenStreetMap) draws the live trail, battery, satellite count and accuracy, and fires geofence alerts.

Let me walk through each layer, then the debugging that actually took the most time.

1. The firmware

The tracker is an ESP32-S3 with an onboard GPS module. The firmware (C++, using TinyGPS++ and HTTPClient) does something conceptually simple:

• read a GPS fix,
• package lat/lng, battery, satellite count and HDOP as JSON,
• POST it to the backend over a phone hotspot.

Conceptually simple. In practice, "read a GPS fix" is where I spent most of my time — I'll come back to exactly why in the war-stories section, because that's the interesting part.

2. The backend

The API is deliberately boring, and that's the point. Express endpoints receive telemetry, validate the JSON shape, and append it to a per-device history. A small heartbeat check flips a device to "offline" if it hasn't reported in a while — that "last seen 3 minutes ago" is what actually matters to a herder.

I also built a separate geofencing simulator with PostgreSQL/PostGIS and Socket.IO so I could model many animals moving at once and test enter/exit-zone logic without a field full of hardware.

3. The dashboard

The front end is React with Leaflet over OpenStreetMap. It shows:

• the animal's live position and its recent trail,
• battery level, satellite count, and HDOP (a GPS accuracy metric),
• online / offline status,
• geofence alerts when an animal crosses a boundary.

It's multilingual too — English, French, and Arabic with proper RTL — because the people who'd actually use it don't all read English.

The debugging war stories (what this post is really about)

Anyone can wire up an HTTP POST. The real engineering was getting a reliable fix out of cheap hardware in an open field:

• The GNSS module wouldn't power on. The UC6580 GNSS chip needs a specific power-enable sequence through a VEXT GPIO. Until I got that right, I had a "GPS" that returned nothing but zeros.
• Wrong GPIO pin mapping. The ESP32-S3's pins aren't the same as older ESP32 boards, so a mismatched serial pin meant the microcontroller and the GPS were quietly talking past each other.
• ADC attenuation. Battery readings were nonsense until I set the correct ADC attenuation for the voltage range.
• WiFi instability on mobile hotspots. In the field there's no clean WiFi — just a phone. Hotspot connections drop, so the firmware needed retry logic that reconnects without losing data.

After all of that, I was getting a stable fix with 15–18 satellites and under 2 m accuracy outdoors — good enough to tell one animal from another in a field.

What I learned

• Hardware makes you honest. On the web you can retry a request. In a field, a dropped connection or a bad power sequence is just... silence. It forced me to design for failure instead of assuming the happy path.
• The boring backend is the reliable backend. Every time I made the API "clever," it got harder to trust. Simple validation + history + a heartbeat did the job.
• Ship the smallest thing that proves it. A single dot moving on a map convinced people faster than any pitch deck.

LOKA is now competing in the Qabilah Hackathon, and I'm still building on it.

• 🌍 Live demo: https://loka-livetrack.vercel.app
• 💻 Code: https://github.com/abdeldjaouadfarid

If you've built anything with an ESP32 and a flaky field connection, I'd love to hear how you handled the reconnection problem — that one nearly beat me.