Scrocle

PwnLink · 2026

A phone app for a Pi in the field

In progressIndependent engineer

Running a Raspberry Pi in the field from a laptop is impractical. A generic Bluetooth terminal lacks location support, a versioned protocol, and a connection that survives the screen turning off.

The constraint

The phone and the Pi meet on a Bluetooth personal area network. There is no assumption of a stable internet path. Interface captures will be added once they exist.

Built with

  • Kotlin
  • Bluetooth
  • GPS

How it works

Phone and Raspberry Pi on a Bluetooth PAN. Versioned JSON over the link. GPS originates on the phone. A foreground service keeps the socket.

The calls that shaped it

Each decision with the pressure that forced it and the price it keeps costing.

  1. Bluetooth PAN on the local network

    The Pi runs where there is no wi-fi and often no mobile data. A relay through the internet assumes a path that is not there.

    The phone discovers the device from the incoming WebSocket address on the PAN. The path is local.

    The cost: Both ends have to sit on the same personal area network, so range is the limit.

  2. Versioned JSON both ways

    The app and the firmware ship separately. A protocol with no version on the wire cannot tell an old client from a new one, and a half-working mismatch is worse than a refusal.

    A custom protocol with a version on every message, so a firmware bump can fail closed.

    The cost: Every message carries version handling, and an incompatible bump fails closed.

  3. Foreground service

    A socket owned by an activity dies when the screen turns off, and in the field the screen is off most of the time.

    GPS can stream and the link stays up while the screen is off. A connection that drops when the device is locked is not usable in the field.

    The cost: A persistent notification while the service runs, and the host system can still reclaim the process.

A device without mobile data needs a protocol and a network you control. The app provides both.

Field hardware with no steady internet gets a phone companion on the same local network, a protocol that fails closed, and a connection that survives the screen being locked.

Where it stands

In progress. Field hardware work: Bluetooth PAN, versioned protocol, and a foreground service for a device with no steady internet.

  • The Android client and the Raspberry Pi meet on a Bluetooth personal area network with no internet path assumed.
  • Location streams from the phone into the same link.
  • A foreground service keeps the socket alive with the screen off.
  • In progress. Interface captures will be added once they exist.

What was handed over

  1. Protocol version notes
  2. How discovery is supposed to happen
  3. What the foreground service is allowed to do
Next project Ingestion Collecting web data without losing the failures