PwnLink · 2026

Android companion for field hardware

In progress

Role
Independent engineer
Stack
Kotlin, Bluetooth, GPS
Status
In progress

Problem

A Raspberry Pi in the field is awkward to operate from a laptop, and a generic Bluetooth serial terminal does not carry GPS, a versioned protocol, or a connection that survives the screen turning off.

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 wait until they exist.

Architecture

  1. Android
  2. Bluetooth PAN
  3. Raspberry Pi
  1. GPS
  2. JSON protocol
  3. Foreground service
Phone and Raspberry Pi on a Bluetooth PAN. Versioned JSON over the link. GPS originates on the phone. A foreground service keeps the socket.

Decisions

  • Bluetooth PAN, not a cloud relay

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

  • Versioned JSON both ways

    A custom protocol, not an informal stream of strings, so a firmware bump can fail closed.

  • Foreground service

    GPS can stream, and the link stays up while the screen is off. A companion that dies in the pocket is not a companion.

If the brief is a phone next to a device that will not have LTE, start with the protocol and the network you actually have — not an app store listing for a remote control.

Outcome

In progress. This is field hardware work, not a consumer Bluetooth gadget listing.

What was handed over

  1. Protocol version notes
  2. How discovery is supposed to happen
  3. What the foreground service is allowed to do

hire@scrocle.cloud

Next project Ingestion Durable web ingestion pipeline