# I Want to Bring Old Surf Sensors Back to Life

**TL;DR:** BreakFinder now has a first board sensor import for DIY surf trackers. You can upload GPS + IMU files, preview a surf session, and save it after login. The first version uses BreakFinder's existing GPS wave detection. The next step is using board-mounted IMU data for turns. Longer term, I want to revive old Trace, Xensr Air, and similar sensors instead of letting them become e-waste.

I do not like the idea that a working piece of surf hardware becomes useless because an app disappeared, a server shut down, or a company moved on.

There are old Trace sensors, Xensr Air pucks, and other board-mounted surf trackers sitting in drawers. Some still charge. Some still record. A lot of them probably have useful GPS and motion data inside. The problem is the software layer around them.

So I started with the part I can control first: BreakFinder can now accept board sensor data.

---

## What Exists Now

The first version is called **Board Sensor Import v0**.

It accepts JSON, JSONL/NDJSON, and CSV files with GPS samples. Optional IMU data can be included too: accelerometer, gyroscope, and quaternion orientation.

The public tool is here:

`/en/surf_sessions/board-sensor-import`

What it does today:

- Upload a file without an account
- Parse GPS and optional IMU samples
- Generate a temporary surf session preview
- Show session vitals
- Show detected waves
- Show an interactive wave map
- Show wave-by-wave breakdown
- Save the session only after login

That last part matters. Anonymous uploads are preview-only. If someone wants the session in their BreakFinder logbook, they create an account or log in first.

---

## How Waves Are Detected Right Now

This first version does **not** invent a new board-sensor algorithm yet.

Right now the imported file goes through the same GPS-based wave detection pipeline that BreakFinder already uses for surf sessions from wearable data and file imports.

The flow is:

1. The uploaded file is normalized into samples: timestamp, latitude, longitude, speed, and optional IMU fields.
2. BreakFinder builds internal GPS records from those samples.
3. Those records go into the existing `SurfSessions::WaveDetectionService`.
4. The service uses the GPS heuristic detector.
5. The detector smooths speed, watches for riding-speed bursts, validates duration and distance, then creates wave rides.

So v0 is GPS-first.

That means it can already answer:

- When did the session start?
- How far did the surfer move?
- How many likely waves were ridden?
- Where did each wave start and end?
- How long was each wave?
- What was the max speed?

The IMU data is already accepted and counted, but it is not yet used to classify turns.

That is the next interesting layer: GPS says "this was probably a wave." Board-mounted IMU data can later say "this section had a bottom turn, a rail-to-rail transition, a cutback, or a snap."

---

## Why Board Sensors Are Different From Watches

Watches are useful. BreakFinder already integrates with Garmin, Apple Watch, Wear OS, Amazfit, Strava, and file imports.

But a watch sits on your wrist.

That means it sees arm movement, paddle rhythm, and body motion. It can infer a lot, but it does not directly know what the board is doing under your feet.

A board-mounted sensor sees different things:

- Edge changes
- Direction changes
- Board rotation
- Impact on landings
- Nose angle
- Rail engagement
- Turn timing

That is why I am interested in GPS + IMU pucks mounted on the board. Not because everyone needs another gadget, but because the data is closer to the surfboard itself.

---

## Why Start With DIY Files Instead of Hardware

Building custom hardware first would be expensive and probably premature.

The better first step is an import layer.

If someone already has a DIY ESP32, nRF52, GNSS, BNO085, ICM-20948, or similar setup in a waterproof case, they can target a simple schema and test it against a real surf-session pipeline.

If someone has old hardware, the same import layer can become the adapter target later.

That keeps the architecture simple:

1. **DIY sensor file** today
2. **Authenticated API uploads** for firmware and scripts
3. **Trace/Xensr adapters** once I can inspect real hardware
4. **Possible BreakFinder puck** only if the data and demand justify it

No separate toy database. No parallel product. The imported session becomes a real BreakFinder surf session, using the existing surf logbook, wave map, wave breakdown, and future community surfaces.

---

## The Open File Format

The recommended JSON shape is intentionally boring:

```json
{
  "schema": "breakfinder.board_sensor.v0.1",
  "device": {
    "type": "diy",
    "model": "esp32-bno085-ublox",
    "mount": "nose_gopro",
    "firmware": "0.1.0"
  },
  "session": {
    "id": "local-session-001",
    "started_at": "2026-06-27T08:12:00Z",
    "timezone": "Europe/Lisbon"
  },
  "samples": [
    {
      "t_ms": 0,
      "lat": 39.355812,
      "lon": -9.381102,
      "speed_mps": 4.2,
      "accel": [0.02, -0.14, 9.81],
      "gyro": [0.01, 0.03, -0.12],
      "quat": [1, 0, 0, 0]
    }
  ]
}
```

Required per sample:

- `lat`
- `lon`, `lng`, or `longitude`

Useful optional fields:

- `timestamp`, `time`, or `recorded_at`
- `t_ms` when `session.started_at` exists
- `speed_mps` or `speed_kmh`
- `accel` or `accel_x/y/z`
- `gyro` or `gyro_x/y/z`
- `quat` or `quat_w/x/y/z`

There is also an authenticated JSON API:

```bash
curl -sS -X POST https://breakfinder.surf/api/v1/board_sensor_imports \
  -H "Authorization: Bearer ${BOARD_SENSOR_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data-binary @session.json
```

API tokens are separate from smartwatch integrations. The full token is only shown once when created or rotated.

---

## Why I Want Trace and Xensr Hardware

The next research track needs physical devices.

I would like to get old Trace, Xensr Air, or comparable board-mounted surf sensors and inspect what is still possible:

- Does it still power on?
- Does it still record locally?
- Does it expose BLE characteristics?
- Is the data stored unencrypted?
- Can a session dump be decoded?
- Can the output be mapped into the BreakFinder board sensor schema?

If yes, those sensors can become useful again.

That is the sustainability angle for me. There is no reason to produce new plastic, batteries, cases, and electronics if a lot of usable hardware already exists and only needs a new software bridge.

If you have old surf sensor hardware and are open to lending, donating, or documenting it, email me:

`philipp.winkler@breakfinder.surf`

Trace, Xensr Air, PIQ-style pucks, anything similar. Even protocol notes or sample files would help.

---

## What DIY Sensor Builders Can Do Now

If you are already building a surf tracker, you can use the schema as a target.

Good first test:

1. Record GPS at roughly 1 Hz or better.
2. Include timestamps or `session.started_at` plus `t_ms`.
3. Include speed if your GNSS module provides it.
4. Add IMU arrays even if BreakFinder does not classify turns from them yet.
5. Upload the file and compare the wave map against your memory of the session.

The interesting feedback is not "does it look perfect?" yet.

The useful feedback is:

- Does the schema feel easy to emit?
- Are important fields missing?
- Does the GPS wave detection roughly match the session?
- What sample rate is realistic in a waterproof DIY setup?
- What battery life is realistic?
- What mounting position gives useful IMU data?

That is the kind of practical feedback that can shape the standard before any custom hardware exists.

---

## What Comes Next

The next steps are pretty clear:

1. Improve the board sensor import with more sample files.
2. Collect real DIY sensor data from surfers.
3. Add IMU-based turn and board-movement analysis.
4. Get old Trace and Xensr devices for reverse engineering.
5. Build adapters for any legacy hardware that can still produce useful data.
6. Only then decide whether a BreakFinder hardware puck makes sense.

I would rather prove the data layer first.

If people use it, if DIY builders find it useful, and if old sensors can be revived, then hardware becomes a much better decision. Until then, the best move is to make the existing infrastructure open enough that other people can experiment.

No e-waste if we can avoid it.

No new puck before the old ones get a fair shot.
