Inspiration

At a hackathon, there is nothing more painful than finding a great place to work, opening your laptop, and discovering that the Wi-Fi is unusable.

What makes it worse is that Wi-Fi quality can vary dramatically across the same building. Two seats that are only a few meters apart can have completely different latency, packet loss, and throughput.

We kept asking ourselves:

If I am already connected to a Wi-Fi network, why can't I just walk around and find the best place to use it?

There are speed tests everywhere, but most of them only answer one question:

"How fast is my internet right now?"

We wanted to answer a different question:

"Where should I physically go for the best connection to this network?"

That idea became our project.

What We Built

Our project is a personal Wi-Fi mapping tool that helps users find the best physical location for the Wi-Fi network they are currently connected to.

The user connects to a Wi-Fi network and starts a scan. As they move around a venue, the application periodically measures connection performance and records the result along with the user's location.

The application then turns those measurements into a visual map.

Instead of seeing:

Download: 144 Mbps
Ping: 44 ms

the user gets something much more actionable:
Best spot
    ↓
████████████
████████████  ← Sit here
████████████

Avoid
    ↓
░░░░░░░░░░░░
░░░░░░░░░░░░
```markdown
The goal is simple:

> **Find the strongest current connection, not just the fastest speed test.**

# How It Works

The application continuously collects network performance measurements while the user moves through a space.

Depending on the device and platform, these measurements can include:

- Latency
- Jitter
- Packet loss
- Download throughput
- Upload throughput
- Network information exposed by the operating system
- Location information

We combine these measurements into a connection quality score.

A simplified version of our scoring model is:

$$
Q = w_sS + w_lL + w_jJ + w_pP
$$

where:

- $S$ represents throughput
- $L$ represents latency
- $J$ represents jitter
- $P$ represents packet loss
- $w_i$ represents the importance assigned to each metric

The exact weighting can be adjusted depending on what the user wants to do.

For example, a video call should prioritize stability and latency, while downloading a large file should prioritize throughput.

This means that the "best Wi-Fi spot" is not necessarily the spot with the highest download speed.

# The Wi-Fi Map

As measurements are collected, we visualize them spatially.

A user can walk around a large space and gradually build a map of the network:

- Green areas represent consistently good connections
- Yellow areas represent mediocre connections
- Red areas represent poor or unstable connections

The map can reveal things that a traditional speed test cannot.

For example:

> "The connection is fast near the entrance, but latency becomes unstable near the back wall."

Or:

> "The northwest section has lower throughput but significantly more consistent latency, making it better for a video call."

This is especially useful in large spaces such as:

- Hackathons
- Conferences
- Universities
- Airports
- Libraries
- Coworking spaces
- Hotels
- Cafés
- Stadiums

# What Makes It Different

We did not want to build another speed test.

A speed test tells you how your connection performs at one moment.

Our application treats the environment itself as part of the problem.

The question is not:

> "Is this Wi-Fi good?"

It is:

> **"Where is this Wi-Fi good?"**

That distinction makes the data much more actionable.

# Technical Challenges

One of the biggest challenges was dealing with the limitations of network information exposed by different devices and platforms.

A native Android application can access more Wi-Fi information than a normal browser application. Browsers intentionally restrict access to information such as raw Wi-Fi signal strength.

Because of this, we designed the core system around measurements that can actually be observed by an application, such as latency, throughput, and connection stability.

This also made the project more interesting.

A weak signal does not always mean a bad user experience, and a strong signal does not guarantee a good internet connection.

The application therefore focuses on **actual connection performance** rather than treating signal strength as the entire story.

# Indoor Location

Indoor positioning was another challenge.

GPS can be inaccurate inside large buildings, so relying entirely on GPS would produce noisy maps.

Our approach allows measurements to be associated with a user's position while accounting for location uncertainty.

For controlled environments, the system can also work with a venue floor plan or manually defined areas.

This means the same concept can work at a hackathon without requiring the venue to install special hardware.

# What We Learned

We learned that Wi-Fi is much more complicated than a single "bars" indicator suggests.

Two connections with similar signal strength can perform completely differently because of congestion, interference, access point configuration, or network load.

We also learned that collecting data over space and time can reveal patterns that are impossible to see from a single measurement.

Most importantly, we learned that good software does not necessarily need to solve the entire underlying infrastructure problem.

Sometimes the most useful thing you can do is help people make better decisions with the infrastructure that already exists.

# Real World Applications

Although we built the project around the hackathon environment, the same system could be useful anywhere people depend on wireless connectivity.

A conference attendee could find the best place to take a video call.

A student could find the quietest part of a library with a stable connection.

A traveler could find the best table in a café for working remotely.

An IT team could walk through an office and identify areas where network performance consistently deteriorates.

Event organizers could use aggregated, privacy-preserving measurements to understand where their network performs poorly during an event.

The system could eventually build historical models of network performance as well.

For example:

> "This area normally performs well, but becomes congested between 1 PM and 3 PM."

That turns a simple diagnostic tool into a network observability system based on real user experience.

# What We Would Build Next

If we had more time, we would extend the project in several directions.

### Historical Network Maps

Save previous scans so users can compare network performance across different times and events.

### Network-Aware Recommendations

Allow users to specify what they are doing:

- Video call
- Gaming
- Uploading
- Downloading
- General browsing

The application could then recommend different locations depending on the task.

### Automatic Route Finding

Instead of simply showing the best spot, the application could calculate a route through the venue that maximizes connection quality.

In other words:

> **Follow the current.**

### Venue Network Analytics

With appropriate consent, venue operators could see anonymized aggregate data and identify persistent connectivity problems.

### More Intelligent Analysis

An AI agent could analyze measurements and explain likely causes of poor performance rather than simply reporting that the connection is bad.

Eventually, it could answer questions like:

> "Why does this part of the room have good download speed but terrible video calls?"

We started thinking of the measurements as little scouts swimming through the venue.

Each measurement is another little piece of information about the invisible network around us.

Put enough of them together and you get something resembling a map of an underwater current.

There may or may not be a small fish somewhere in the UI.

And if the connection gets really bad, you might encounter a crab.

# Conclusion

Wi-Fi is invisible, but its effects are not.

Our project turns those invisible effects into something people can see and use.

Instead of repeatedly asking:

> "Why is the Wi-Fi so bad here?"

we want users to be able to ask:

> **"Where is the best spot?"**

And then simply walk there.