Transit Sentinel

Solving DRT's blind spot: I built an edge-computing IoT system using passive Wi-Fi/BLE sensors to map anonymous passenger journeys and generate real-time Origin-Destination matrices.

Comment

Transit Sentinel

Check it out here

View the code on GitHub

Inspiration

Durham Region Transit currently uses PRESTO and Automated Passenger Counters (APCs) to measure bus volume, but these sensors have a major limitation: they only count how many people board, not where they actually go.

To solve:

  • Problem 9: Analyzing Route Efficiency
  • Problem 4: Identifying Service Gaps

Transit agencies require a true Origin-Destination (OD) matrix.

The goal of this project was to build a privacy-preserving IoT solution that maps the entire passenger journey without:

  • relying on expensive computer vision systems
  • forcing riders to manually tap off

What It Does

Transit Sentinel is a passive telemetry system that generates a real-time Origin-Destination matrix for transit fleets.

Two lightweight edge sensors are placed at the front and rear doors of the bus. These sensors capture anonymized:

  • Wi-Fi probe requests
  • Bluetooth Low Energy (BLE) probe requests

from passenger devices.

The backend processes these noisy radio signals, groups them by hashed device MAC addresses, and calculates passenger movement.

This telemetry is then synchronized with the DRT GTFS-Realtime feed to plot exact boarding and alighting GPS coordinates on a live dashboard.

This enables:

  • Problem 3: Predicting Bus Crowding
  • Route optimization
  • Accurate Origin-Destination analysis

Architecture

The system follows a Dumb Edge, Smart Core architecture.

Edge Layer

Two Raspberry Pi nodes (Front and Rear) run Python sniffer scripts using high-gain antennas.

Responsibilities:

  • Passively capture Wi-Fi and BLE probe requests
  • Filter signals strictly above -85 dBm
  • Batch telemetry into JSON payloads
  • Send data to the backend via a local hotspot

Core Backend

The backend is built with FastAPI and uses SQLite for storage.

Passenger movement is determined using the signal strength differential between the two sensors:

$$\Delta = RSSI_{\text{Front}} - RSSI_{\text{Rear}}$$

Where:

  • RSSI Front is the signal strength measured at the front sensor
  • RSSI Rear is the signal strength measured at the rear sensor

The differential helps estimate the relative position and movement direction of a passenger within the bus.

Transit Data Integration

An asynchronous background worker processes GTFS-Realtime Protocol Buffer feeds.

Every 15 seconds the system:

  1. Fetches the GTFS-RT feed
  2. Parses vehicle position updates
  3. Stores a historical GPS log of the active bus

This allows passenger telemetry to be aligned with precise bus location data.

Dashboard

The visualization layer is built with:

  • Vanilla JavaScript
  • Leaflet.js

The dashboard:

  • polls the backend API
  • dynamically draws Origin-Destination polylines
  • visualizes passenger journeys on a live map

Challenges

The "Time Travel Problem"

Radio frequency telemetry is extremely noisy.

To confirm that a passenger has exited the bus, the system uses:

  • a 15-second sliding time window
  • a 120-second inactivity timeout

However, this introduces a synchronization issue. If the backend queries the live GTFS feed after that 120-second timeout, the bus has already moved several blocks away. This causes the alighting event to be mapped to the wrong stop.

Solution: Flight Data Recorder

To solve this problem, a SQLite flight recorder continuously logs the bus GPS coordinates.

When a passenger journey completes, the backend queries the historical location database:

$$L_{\text{exit}} = L_{\text{bus}}(t - 120\text{s})$$

This retrieves the bus location two minutes in the past, ensuring the alighting event is mapped to the correct coordinates.

Accomplishments

One of the most rewarding parts of this project was moving from tabletop simulation to real-world validation.

The Raspberry Pi edge nodes were deployed on the DRT Route 915, where they successfully:

  • captured real passenger telemetry
  • transmitted data to the backend
  • synchronized telemetry with the live GTFS-RT feed

Seeing the entire pipeline work in a real transit environment was a major technical milestone.

What I Learned

This project strengthened my understanding of several engineering concepts.

Distributed Systems

Balancing edge computation versus centralized processing.

Transit Data Infrastructure

Parsing compact protobuf feeds used in enterprise transit APIs.

Time-Series Data Alignment

Handling noisy hardware signals and aligning them with real-world location data.

What's Next

Edge Deduplication

Implement device deduplication algorithms on the Raspberry Pi nodes to reduce cellular bandwidth usage during fleet-wide deployment.

Predictive Modeling

Combine Origin-Destination matrices with historical APC data to train machine learning models that can:

  • predict passenger demand
  • identify underserved areas
  • dispatch relief buses proactively

This could allow transit agencies to respond to crowding before it occurs, improving overall transit efficiency.

Built With

Share this project:

Updates