Radio / LoRa / May 2026

LoRa Hackathon: Two Projects, Two Problems

A November 2024 hackathon gave me two practical reasons to use LoRa: traffic counts from roadside cameras and telemetry from construction equipment.

The hackathon is where I actually got into LoRa.

This was in November 2024. I later built my own Meshtastic network, but these two prototypes came first.

Not as a hobby radio thing. As a link for two real problems. One was traffic. One was construction equipment. Both needed the same thing: cheap, low-power radios sending small amounts of data over long distances without a SIM card or a subscription.

Here's what we built.

Project one: AI on the edge for city traffic

The idea was simple. Cities already have cameras mounted on poles. Most of them record video. Almost none of them actually count anything.

So we built a small box that watches the camera feed, recognizes cars, and reports traffic density.

The 3D-printed TALON enclosure built for the traffic prototype.

The setup:

A fixed-mounted camera feeds video to an edge device
An ASIC-based USB AI accelerator does the detection — cheap, low power, and fast enough for vehicle recognition
The device classifies what it sees: cars, trucks, direction of travel, roughly how dense the traffic is
A LoRa module on a Raspberry Pi takes that count and sends it to a central server

The traffic prototype hardware inside the open enclosure.

The LoRa part was the important bit. You can't run Ethernet to every pole. You can't put a SIM and a data plan on hundreds of cameras. But you can put a small LoRa radio on each one, and it can send a few bytes of "lane 2 northbound, 40 vehicles in the last minute" back to a central point.

The central server aggregates the counts and produces a city-wide traffic density map. Which lanes are busy. Which direction is worse. Where the congestion is building.

The TALON traffic viewer beside the prototype enclosure and test street image.

None of this needs video to leave the pole. The AI runs on the edge, the video stays local, and only the number goes out over LoRa. That's the design that makes it cheap enough to deploy at scale.

Project two: OBD2 monitoring for construction equipment

The second project was about machines on a construction site. Excavators, trucks, and everything else.

The problem was visibility. When does a machine actually work? When is it idling? Is something starting to fail before the operator notices? The machines we targeted had OBD2 ports. Nobody was reading them.

So we built a small unit that plugs in and watches the data.

What it captures:

Engine hours and actual working time versus idle time
Fault codes and error logs as they appear
Telemetry that hints at preemptive maintenance — before the operator feels a problem
Location and usage patterns across the fleet

The OBD2 data is the "what." The LoRa side is the "how do we get it out of the site." Construction sites rarely have good networking. But a LoRa link between the machine and a site gateway gets the data out cheaply, and from there it reaches the server.

The value is that a maintenance issue stops being something the operator reports after the machine breaks. It becomes something the fleet manager sees before it does.

Same radio, completely different problem. That's what got me interested in LoRa in the first place — one cheap, low-power, long-range link that works when you can't run a cable or pay for a SIM on every device.