Building Grid
Ricoh publishes no SDK, no API documentation, and has no developer program for
the GR series. Everything Grid does with the camera is built on the work of a
small community that reverse-engineered the protocol. On that foundation I
built an app in Swift/SwiftUI, verified on real hardware.
The story
The GR communicates over two channels, and Grid uses them exactly the way
the official Ricoh app does:
- Bluetooth Low Energy (BLE) is the control channel. The camera
advertises itself as
GR_XXXXXX. After pairing (a standard iOS bond; the
camera needs to be in pairing mode once), the app can use GATT
characteristics to read the battery and storage, power the camera on and
off, push GPS positions for geotagging. And, crucially, it can read
the camera's own WiFi credentials.
- WiFi is the data channel. The camera is an access point (no internet).
Grid reads the SSID and passphrase over BLE, has iOS join the network
(
NEHotspotConfiguration), and then talks to a simple HTTP server at
192.168.0.1: photo listings, thumbnails, downloads, and a WebSocket for
live updates.
Sources
None of this came from Ricoh. dm-zharov mapped the full BLE GATT tree
of the GR II/III by sniffing traffic between the camera and the official
app. clyang's GRsync and adriantache's GReat-Image-Downloader independently
confirmed the same WiFi HTTP endpoints in their own desktop tools.
What about the GR IV?
For the GR IV there is nothing at all. No documentation, no
reverse-engineering. Grid's GR IV profile therefore starts as an exact copy
of the GR III profile, with a diagnostics screen in the app that can dump
the full GATT tree of a connected camera to spot differences. In practice
the GR IV (firmware 1.11) turns out to be compatible: the same UUIDs, the
same HTTP endpoints, with two known differences. The bulk
/v1/photos/infos listing is missing (so Grid fetches per-photo info
lazily), and there are two storages (internal + SD, via the
?storage= parameter).
All Ricoh codes in use
BLE Services (GR II/III, verified on GR IV)
BLE Device information (read)
BLE Camera status (read/write/notify)
BLE Geotagging (GPS Control service)
BLE WiFi bridge (WLAN Control service)
The heart of the connection:
BLE Bluetooth behavior (Bluetooth Control service)
BLE Value encodings
- Enums (power, mode, network type, …): one signed byte (
Int8 rawValue).
- Strings (SSID, names): UTF-8, NUL-padded at the end.
- Battery: byte 1 = level (0–100), optional byte 2 = power source (battery / AC adapter).
- GPS payload (32 bytes, written to GPS Information):
| Bytes | Contents |
| 0–7 | Latitude, float64 big-endian |
| 8–15 | Longitude, float64 big-endian |
| 16–23 | Altitude, float64 big-endian |
| 24–25 | Year, uint16 little-endian |
| 26–30 | Month, day, hour, minute, second (1 byte each, UTC) |
| 31 | Datum: 0 = WGS84 |
BLE Scanning
No advertised service UUID is known; Grid scans by name prefix:
GR, RICOH, PENTAX.
WiFi HTTP API (http://192.168.0.1:80)
Downloads use a keep-alive TCP connection on the same port, so a batch
doesn't pay a handshake per file.