Skip to main content
A technical summary of the app, instrument cluster (Tripper Dash on Bear 650), and Wingman telematics—for interoperability and research (e.g. home automation, custom telematics on your own bike).

Purpose and legal note

This post is written for interoperability and research: for example, integrating a lawfully owned motorcycle with other systems (e.g. home automation) or understanding protocols to build your own telematics for your own use. The work was done on lawfully obtained products (bike, official app, and firmware obtained through normal channels). I do not publish any vendor source code, decompiled code dumps, keys, secrets, or instructions to circumvent technical protection measures. The post contains my own observations, decoded protocol mappings, and analysis—paraphrased and summarized—not copies or substantial excerpts of the vendor’s software. It is not intended to create a substantially similar product to the vendor’s, nor to enable others to do so.
Laws on reverse engineering and publishing (including in the EU) allow limited room for interoperability but restrict how results are used and shared. I do not describe or encourage circumvention of access controls, and any security-relevant findings would be handled through responsible disclosure. If you are unsure how this applies to your situation, consult an IP lawyer in your jurisdiction before publishing or reusing this material. This post does not constitute legal advice.
Royal Enfield’s newer bikes (e.g. Bear 650) ship with a connected ecosystem: an Android/iOS app, an in-dash instrument cluster, and (in some markets) a Wingman telematics unit for “My RE” features like odometer and locate motorcycle. On the Bear 650 the cluster is the Tripper Dash (Visteon K Dash): it has WiFi for the app and CAN to the ECU. A separate product, the Tripper, is a more limited round Bluetooth nav pod (no CAN); this post does not cover it. Almost everything here is Visteon under the hood.
Findings below are from observation and testing of the official app and cluster behavior, analysis of the cluster FOTA image format (structure and my own CAN ID scans), the official wiring schematic, and public references. No proprietary code or resources are reproduced here.

The two devices that matter for Bear 650 (cluster + Wingman)

Device
What it is
How it talks
Tripper Dash (K Dash)
Instrument cluster on Bear 650: speed, RPM, trip, fuel, nav prompts. In the dash.
WiFi (AP on the bike) + CAN (to ECU).
Wingman
Telematics box: odometer, fuel, ignition, GPS to the cloud.
Cellular to RE backend; likely CAN on the bike to read odo/fuel.
The app talks to the cluster (Tripper Dash) over WiFi after you join the bike’s hotspot. It does not send odometer or service data to the bike—that data is read by the app from the backend (Firestore / Fetch Vehicle API), which is written by the Wingman (or equivalent). The standalone Tripper (round Bluetooth pod on some other RE bikes) is a different, more limited unit with no CAN; I leave it out of this post.

Phone ↔ bike: WiFi and UDP

WiFi connection

  • The bike is a WiFi access point. SSID prefix is RE_ (e.g. derived from chassis/device). You connect the phone to it; no internet.
  • The app uses standard Android APIs to bind to that WiFi network and then reads the phone’s IPv4 address on that interface; that address is used for all cluster communication. The cluster is identified as a K Dash–type device; chassis number is used in FOTA and other flows.

UDP: the main on-bike protocol

The only on-bike protocol I identified between app and cluster is UDP (no HTTP or WebSockets for the dash):
  • Send: The app sends UDP from local port 2000 to the broadcast address of the bike’s network (e.g. 192.168.4.255), port 2000. So: destination = broadcast:2000.
  • Receive: The app listens on port 2002 on the same network. Incoming packets are parsed as binary payloads; the app handles navigation, FOTA/commands, and other events. Replies from the bike are likely unicast back to the phone.
Payloads are custom binary/hex, not JSON. To re-use or emulate: connect to the bike’s WiFi, send UDP to broadcast:2000, listen on port 2002, and parse with the same logic as the app (or capture real traffic and reverse the format).

What the app sends (navigation metadata)

The app pushes navigation metadata to the cluster so it can show turn-by-turn prompts. The payload includes: maneuver/instruction text; step/instruction type; distances and units to the current step and destination; time/formatted ETA; distance and time to destination; step index; and display options—i.e. distance to turn, ETA, instruction type, and text. This is sent as binary UDP to broadcast:2000.

What the app receives (frame types)

Incoming UDP on port 2002 appears to be dispatched by the leading byte of the payload. From observation and traffic analysis, the following frame types are used:
  • 0F (with sub-types 0F01–0F0A): general/device info (see “Data you can extract” below).
  • 03: settings sync (clock format, temperature unit, etc.).
  • 0B, 0C: also present in traffic; exact use not fully mapped. Further capture and correlation would map additional frame types.

Other protocols (optional or legacy)

  • H.264 / TCP: The app can connect to 192.168.1.1:5000 (TCP) with H.264/NAL-style handling—likely an optional video stream (e.g. nav or camera).
  • RTSP: An RTSP URL is built using the phone’s IP on bike WiFi; typically used for streaming to the phone.
  • STOMP over WebSocket: The app uses STOMP over WebSocket, likely for cloud/backend (e.g. FOTA, config), not the direct bike–phone link. The primary on-bike protocol I observed is UDP as above.
What
How
Address / port
Direction / content
WiFi
WifiNetworkSpecifier + requestNetwork
Bike AP (SSID RE_*)
Phone joins bike’s WiFi
Cluster metadata
UDP
Send: broadcast:2000; Recv: :2002
Send: navigation metadata; Recv: binary frames (0F, 03, etc.)
Video (optional)
TCP (H.264)
192.168.1.1:5000
H.264 stream (likely bike → phone)
RTSP
URL from string
Template uses phone IP
Streaming (e.g. to phone)
STOMP/WebSocket
krossbow
URL not in bike path
Likely cloud/config

Time and outside temperature (phone → dash)

The cluster gets clock and outside temperature from the phone over the same UDP channel (send to broadcast:2000, receive on :2002).
  • Settings (format/unit)
    When the cluster sends a sync-settings request (payload starting with 03), the app interprets it (e.g. clock format, temperature unit), updates local preferences, and sends a sync response (a fixed header plus payload) containing clock format (12h/24h), temperature unit (Celsius/Fahrenheit), distance unit, fuel unit, language, theme, notifications, POI toggles, to broadcast:2000.
  • Actual time and temperature
    When the cluster sends a request with type 0F (e.g. 0F01–0F0A), the app sends a general settings response over UDP. Current time is taken from the phone; outside temperature is taken from the app’s weather source. So the bike requests; the phone replies with time and ambient temperature, and the dash displays them.

Data you can extract from the cluster over UDP (no nav UI)

All of this is received on UDP port 2002. You can implement a listener on that port (on the same WiFi as the bike) and decode the same frame types.

Device identity and hardware (0F-type)

When the cluster sends 0F frames, the app decodes and stores (or responds). Mirror that parsing to read from the bike:
Data
Sub-type
Notes
Chassis number
0F01
Some fields may be obfuscated or encrypted; the app decodes and stores them.
Serial number
0F02
Same as above.
BSSID
0F05
WiFi BSSID of the cluster.
Manufacturing date
0F06
From cluster payload.
Hardware version
0F07
From cluster payload.
Part number / variant
0F08
From cluster payload.
FOTA version
0F0A
From cluster payload.

Settings / preferences (03-type)

When the cluster sends 03 frames, the app updates nav settings. From 03 (and related) you can infer what the bike is reporting or requesting (my observed mapping):
  • Clock format: 12h vs 24h (03080001 + value).
  • Temperature unit: Celsius vs Fahrenheit (03030001).
  • Distance unit: km vs miles (03040001).
  • Fuel consumption unit: km/L, L/100km, MPG, etc. (03060001).
  • Theme: Auto / dark (03050001).
  • Language: English, Italian, Spanish, Portuguese, German, French (03090001).
  • Notification toggles: Messages, incoming call, contextual alerts, vehicle alerts, weather alerts (030A0005...).
  • POI categories: Gas, restaurant, RE workshop, parking, etc. (0409...).

What is not on bike UDP

I did not observe total mileage (odometer) or service-interval data on the bike ↔ phone UDP channel. Odometer in the app is supplied by the backend (vehicle/connected-data API); service history is loaded from a backend API. The ODO / Trip 1 / Trip 2 options in the app are display toggles for which widgets to show on the dash, not values read from the cluster over WiFi.

Where odometer and ConnectedData come from (backend, not app)

The app does not write odometer or connected-vehicle data. It only reads them.
  • The vehicle document returned by the Fetch Vehicle API includes connected data (battery, fuel, gps, gsm, ignition, lastSyncDate, lat, lng, odometer). The app displays this data (e.g. on “My RE”).
  • I did not observe any app logic that uploads or writes odometer or connected data to the backend. So the odometer is populated by the backend (or by a system that writes to the same store). In typical setups, a telematics backend receives data from the bike (e.g. via Wingman over cellular) and updates the vehicle document; the phone app only displays what the server already has.

When “My RE” and ConnectedData are visible (region + Wingman)

Connected-vehicle data (odometer, fuel, ignition, etc.) is shown on My RE and Home (and related screens), but two conditions affect visibility.
  • Region
    The bottom navigation (including the My RE tab) is only shown in certain regions (e.g. India). In other regions the app may show only the Navigation experience, so My RE is not reachable in the UI.
  • Wingman and connected vehicle
    The connected-data block (odometer, ignition, fuel, GPS/GSM) on My RE is only shown when the backend reports a linked Wingman (e.g. device IMEI) and the selected vehicle is marked by the backend as a connected motorcycle. Otherwise the app shows a link-vehicle or empty state.
So you only see odometer/connected data when the backend has reported a Wingman and the vehicle is flagged as connected.

Instrument cluster on the CAN bus (official schematic)

The instrument cluster on the Bear 650 is the Tripper Dash (Visteon K Dash) and is a CAN bus node. Royal Enfield’s wiring schematic shows the cluster connected to the CAN lines:
So the Tripper Dash has two data paths: WiFi (app, FOTA, nav, time/temp) and CAN (speed, RPM, odo, fuel, etc. with the ECU). A Wingman or DIY telematics device can tap the same CAN bus to read those signals.

Cluster FOTA firmware: layout, unpacking, and CAN ID hints

I had access to the Bear 650 Visteon cluster FOTA package: reflash_manifest.xml plus several .bin images.

Manifest and images

  • FBL (bootloader): e.g. kcluster_FBL_Platform_TCM_merged.bin
  • APP (application): e.g. kcluster_alpha_VP_NOR_Comp_merged.bin
  • CALIB1–8 (calibration): e.g. kcluster_FLASH_CONST1_Comp_merged.bin … kcluster_FLASH_CONST8_Comp_merged.bin
Each file has a 256-byte header; the payload starts at offset 256 (0x100).

Header format (256 bytes)

  • Bytes 0–3: AA 55 AA 55 (signature)
  • Bytes 4–7: FF FF FF FF or variant
  • Bytes 8+: Application-specific (type, size, version, etc.)
  • Bytes 0xF0–0xFF: Second signature AA 55 AA 55 in some images

Unpacked payloads (header stripped)

Role
Example file
Payload size
Bootloader
FBL_Platform_TCM_merged
262,144 B
Application
alpha_VP_NOR_Comp_merged
~1.65 MB
Calibration
FLASH_CONST1 … CONST8_Comp_merged
~1.3–2.2 MB each
“Comp” likely means composite/compressed; binwalk did not detect known compression. Content is mostly ARM code (FBL/APP) and calibration data (CALIB). To re-pack a full .bin from payloads you extracted yourself, prepend the original 256-byte header (from the same lawfully obtained image) to the payload. Standard shell commands for concatenating a header and a payload apply; I do not publish or distribute any firmware binaries.

No Linux rootfs in these images

I scanned payloads for ISO 9660, SquashFS, ext2/3/4, cpio, U-Boot uImage, DTB, zlib, and common archives. Nothing standard was found. The FBL payload starts with a second 256-byte block (again AA 55 AA 55, then 04 0A 00 00, then padding); executable-looking code begins around payload offset 0x40. So this FOTA is almost certainly bare-metal or RTOS on the cluster MCU, not a full Linux system. A Linux rootfs would typically appear in an infotainment/SOC package (e.g. ISO + rootfs.tar as in Gorgias’ Visteon post), not in this kcluster FOTA.

CAN ID–like values in the binaries

I scanned payloads for 16-bit values in 0x100–0x7FF (11-bit CAN ID range).
Strong candidates (FBL, APP, CALIB8):
  • 0x7E0 — Standard OBD-II/UDS request ID (diagnostics); response often 0x7E8.
  • 0x100, 0x101, 0x1CC, 0x200, 0x300, 0x400, 0x500 — Recurring in FBL; plausible cluster/body/powertrain IDs.
  • 0x28C, 0x408 (APP); 0x60C, 0x306, 0x103, 0x100, 0x300 (CALIB8) — Additional candidates.
CALIB1–7: Very high, uniform counts for certain 16-bit values (e.g. 65536 occurrences)—likely fill/alignment in large tables, not a short list of CAN IDs; treat as low-confidence.
There are no readable DBC files or “odometer”/“service” strings in the firmware—only RPM and DbC-like sequences. So these IDs are candidates for live CAN capture; they are not a complete map. If you sniff CAN on the Bear 650, correlate traffic with the cluster display (speed, RPM, odo, fuel) and with these IDs to build a DBC or signal list.

FOTA: where the app gets cluster updates

FOTA for the cluster does not use a hardcoded download URL. The app requests metadata from the backend (observable via the API path /otap/otap/firmwaredownload), then downloads the firmware file from the URL returned in that metadata.
  • Request: POST to a base URL (configurable; a default API base is used if not overridden) with JSON body containing firmwareDeviceType, region, vehicleVariant.
  • Response: JSON with firmwareVersion, campaignName, firmwareUrl, checkSum (and optionally firmwareMappingUrl, updateType, description). The app downloads the file from firmwareUrl (e.g. via the platform download facility) and then presumably sends it to the cluster over the same WiFi/UDP path. The same metadata can also be supplied via the backend’s Firestore/streaming path in some flows.
  • Other OTAP-related endpoints (same base): e.g. addFotaReport (report FOTA status), deviceStatus (device status). These are observable from normal API usage; I do not publish keys, tokens, or bypass methods.
The FOTA image format I describe (256-byte header, payload layout) corresponds to the kind of image the server can push to the Bear 650 cluster.

Wingman and the backend

The app only reads ConnectedData; the backend (fed by the Wingman) writes it.

APIs / flows to discover

  • Connected-info — The app enables “Wingman” when it gets a connected-info response with non-empty device IMEI. Your device may need to register (link IMEI to user/vehicle) so the backend returns it.
  • Fetch Vehicle — Returns userVehicles with ConnectedData (odometer, fuel, ignition, battery, gps, gsm, lastSyncDate, lat, lng). You need the upload endpoint and payload the real Wingman uses (e.g. POST with vin/chassis, IMEI, odo, fuel, ignition, position).
  • OTAP — firmwaredownload (cluster firmware), addFotaReport, deviceStatus.

What Wingman must send to the backend

From the connected data the app displays (my observation of the data shape):
  • odometer — From CAN (cluster or ECU).
  • fuel — From CAN (fuel level/sender).
  • ignition — From CAN (ignition on/off).
  • battery — Likely 12 V; could be from CAN or ADC on your device.
  • gps, gsm — Your device’s GPS and modem status.
  • lastSyncDate — Server or device timestamp.
  • lat, lng — From your GPS.

Practical next steps

  • CAN capture — Use a CAN interface on the Bear 650 (OBD-II or direct CAN H/L). Log with engine on, key cycles, and a short ride. Map which IDs change with speed, RPM, odo, fuel; cross-check with 0x7E0/0x7E8, 0x100, 0x1CC, 0x200, 0x300, etc. from the firmware. Build a small DBC or ID → signals table.
  • Wingman → backend — If you have a real Wingman, capture its cellular traffic (modem trace or proxy) to see the exact upload API (URL, headers, body) for odo, fuel, position.
  • Cluster WiFi — Join bike WiFi (SSID RE_*), listen on UDP 2002, send to broadcast:2000. Implement parsing for 0F and 03 to read chassis, serial, BSSID, FOTA version, and settings. Useful for identification and FOTA; not for odo/service.

Summary table

Data / feature
Source (current RE system)
For your Wingman clone
Odometer, fuel, ignition
Backend (from Wingman upload)
Read from CAN → send to backend; or capture Wingman API.
Speed, RPM
Cluster (from CAN)
Read from CAN (same IDs as cluster).
Service interval/due
Backend (service history API)
Derive from odo + last service or CAN.
Chassis, serial, FOTA version
Cluster over UDP (0F)
Join bike WiFi, listen :2002, parse 0F.
Clock, temp on dash
Phone → cluster (UDP)
Same UDP channel; app sends time + weather.
Nav prompts on cluster
App → cluster (UDP)
Send navigation metadata to broadcast:2000.
Wingman “enabled” in app
Backend (connected-info + IMEI)
Register device / IMEI with backend.

References and docs

The work above is from observation and analysis of app behavior, cluster FOTA image structure (and my own CAN ID scans), the official wiring schematic, and public references. No proprietary code, keys, or backend credentials are published. No circumvention of technical protection measures is described. If you run CAN or WiFi capture on your own bike, you can turn the candidate CAN IDs and UDP frame types into a concrete protocol map for interoperability (e.g. home automation, your own telematics). This post is for interoperability and research only and does not constitute legal advice; readers should consult an IP lawyer in their jurisdiction if unsure about their own use or publication.

More Stories