Skip to main content

R700 CAP Overview

CAP (Custom Application Program) is the on-reader program that lets Titan Cloud Start/Stop an Impinj R700 remotely. Stock firmware can publish tag reads but cannot subscribe to commands. CAP is the subscriber.

Why CAP Is Needed​

Stock R700 firmware:

  • Publishes tag reads to MQTT (Titan receives reads)
  • Cannot subscribe to MQTT (hub Start/Stop buttons do nothing)

With CAP installed:

  • Tag reads published (same as stock)
  • Subscribes to titan/v1/{serial}/commands
  • Hub Start/Stop buttons work
  • Remote configuration push (future)

Current Status​

CAP 0.1.6.0: Tested end to end on a lab reader; not yet deployed at a customer site.

Proven:

  • Subscribes to command topic
  • Receives Start/Stop commands
  • Applies commands via reader's REST API (POST /presets/{id}/start, POST /profiles/stop)
  • Acks on command-response topic
  • Reads identity from /cust/rw_dir/ (ca.crt, client.crt, client.key, titan.json)

Requirements:

  • R700 rev 2 (64-bit ARM)
  • Firmware 10.0.0 or later
  • CAP install mode: Open
  • Identity files in /cust/rw_dir/ (persists across CAP upgrades if "Persistent Data = rw_dir")

How CAP Works​

┌────────────────────────────────────────┐
│  R700 Reader                           │
│                                        │
│  ┌──────────────┐   ┌──────────────┐  │
│  │ Stock        │   │ Titan CAP    │  │
│  │ Firmware     │   │ (subscriber) │  │
│  └──┬───────────┘   └───────┬──────┘  │
│     │ Publishes         │ Subscribes  │
│     │ tag reads         │ commands    │
└─────┼───────────────────┼─────────────┘
      │                   │
      │                   │
      ▼                   ▼
   titan/v1/{serial}/events
   titan/v1/{serial}/status
                           │
                           │
   titan/v1/{serial}/commands  ◀─ Hub UI (Start/Stop)
   titan/v1/{serial}/command-response

Data Flow:

  1. Hub user clicks Start → titand publishes {kind: "start", id: "uuid", preset: "titan-default"} to titan/v1/{serial}/commands (retained, QoS 1)
  2. CAP receives command → POST to reader's local REST API: /api/v1/profiles/inventory/presets/titan-default/start
  3. Reader starts reading → CAP publishes {id: "uuid", ok: true, status: "started"} to command-response
  4. titand receives ack → updates hub UI ("Reader online, reading tags")
  5. Tag reads flow from firmware → broker → titand → hub

Identity Files (rw_dir)​

CAP reads MQTT credentials from /cust/rw_dir/ on the reader:

FilePurpose
ca.crtTitan Cloud CA (PEM format) - reader trusts broker's cert
client.crtReader's client certificate (PEM) - CN is reader serial (device identity)
client.keyPrivate key matching client.crt (PEM, mode 0600)
titan.jsonReader REST API credentials (JSON: {"user":"root","password":"..."})

Why rw_dir? This directory persists across CAP upgrades if CAP is configured with "Persistent Data = rw_dir". Identity stays intact even if CAP is reinstalled.

Current Reality: These files are written manually at the bench (Wonder-shipped) or will be pulled via claim-and-pull API (BYO, designed but not built).

See CAP Identity for details on how these files are provisioned.

Installation​

See CAP Install Guide for step-by-step instructions:

  1. Download CAP .upgx file
  2. Set reader to CAP install mode: Open
  3. Upload .upgx via reader's web UI
  4. Configure "Persistent Data = rw_dir"
  5. Provision identity files to /cust/rw_dir/
  6. Restart CAP → connects to broker, subscribes to commands

Supported Commands​

CommandJSONEffect
start{"kind":"start","id":"uuid","preset":"titan-default"}POST /presets/{preset}/start (or /presets/titan-default if no preset specified)
stop{"kind":"stop","id":"uuid"}POST /profiles/stop
push-config{"kind":"push-config","id":"uuid","preset":{...}}POST /presets/{id} (future)

Ack Format (on command-response):

{
  "id": "uuid-from-command",
  "ok": true,
  "error": null,
  "status": "started"
}

If command fails (e.g. reader REST API returns 500), ok: false and error contains the failure reason.

Operational Notes​

CAP does not persist across factory reset. Reader config-image modes:

  • removecap: Wipes CAP and identity files (full factory reset)
  • default: Keeps CAP and rw_dir intact (config-only reset)
  • Physical Default Restore button: Uses config-image setting (default = keep CAP)

CAP log: Accessible via reader's web UI under CAP → Log. Shows MQTT connection, commands received, REST API calls.

Troubleshooting:

  • CAP installed but Start/Stop doesn't work → Check identity files in rw_dir (are all 4 present? Is client.key readable?)
  • CAP crash-loops → Check GCC/libstdc++ version (0.1.1.0 fixed crash on firmware 10.0.0 due to static-linked libstdc++)
  • Commands acked but reader doesn't start → Check reader REST API log (CAP forwards errors from API)

See CAP Operations for day-to-day management.

What CAP Does NOT Do​

  • Modify tag reads (firmware handles all RFID operations)
  • Store data locally (stateless; all state in titand)
  • Require internet on reader (MQTT broker is on LAN for On-Prem, or internet for Cloud)
  • Authenticate itself (identity files provide credentials)

CAP is glue between MQTT and REST API. It's the subscriber that stock firmware is not.

Version History​

VersionDateChanges
0.1.6.02026-09Current build. Tested end to end on a lab reader; not yet deployed at a customer site. Reads rw_dir identity. Static-linked libstdc++/libgcc.
0.1.1.02026-08Fixed crash-loop on firmware 10.0.0 (libstdc++ compatibility)
0.1.0.02026-08Initial release. Crash-looped on some firmware versions.

Next Steps​