MyTechDailyNews Hardware: Inside the Beybattle Pass BX-09 BLE Data Link — Launch RPM Metrics, Payload Layouts, and the DiZZi 0.2 Companion App
MyTechDailyNews Hardware | bench notes by Sarah Chen, Tech Daily. The telemetry log this teardown is assembled from was published October 22, 2026 and has recorded 10483 views. Every byte pattern, capacity limit and command opcode reproduced below comes straight from that log; wherever a reading is still a hypothesis, it is labelled as one.
Seen from a hardware desk rather than a toy shelf, the Beybattle Pass is a small embedded data logger: one optical sensor, one counter, one fixed-size circular buffer, and a Bluetooth Low Energy (BLE) link that pushes the result to a phone. There is no proprietary cloud handshake, no vendor SDK required, and no need to crack the shell open to understand how a string pull becomes a number. What follows maps the mechanism, the packet layout, the buffer's hard limits, and the companion client built on top of them.
At a glance: the numbers that matter
| Attribute | Observed value | Why it matters for a purchase or a build |
|---|---|---|
| Advertised BLE name | BEYBLADE_TOOL01 | A single service is exposed, so filtering it in any sniffer is trivial |
| GATT characteristics | 2 (Read + Notify, and Write Without Response) | Two UUIDs cover every transaction in both directions |
| Header frame size | 17-byte | State and metadata arrive before you launch anything |
| Launch history capacity | 50 entries, FIFO | Anything older than the 50 newest launches is silently overwritten |
| Reference launch speed | 5,000 RPM reported for an average Beyblade spin | The sanity check that stops byte-order mistakes |
| Decoded samples from one session | 3,234 / 4,194 / 3,477 RPM | Real distribution, not a best-case demo figure |
| Byte order | Little-endian | Reading big-endian inflates 3,234 into 41,484 |
| Buffer integrity check | Sum of b* data bytes, modulo 256 | Lets you validate a capture without the vendor app |
Provenance of the test unit
This is not a review loan, so the sample history matters. At the beginning of June last summer, an Instagram feed reshaped after a 10th algorithm reset started surfacing Beyblades again — specifically Beyblade X, whose reels look genuinely hypnotic. A Dublin toy shop supplied a stadium plus several beys, and That same weekend a games night with friends confirmed the pitch: battles feel faster than earlier versions because the Bit can catch the side rail and trigger the Xtreme Dash gimmick, converting a glancing blow into a heavy collision.
Over the following months came local tournaments, more combos of Blades, Ratchets and Bits than one player needs, and, during a meta-research session, the Beybattle Pass (BX-09). Public information credits Takara Tomy with the device and describes it as, in theory, Japan-only: clipped to a launcher, it pairs with the official Beyblade X app over Bluetooth and transmits the Shoot Power value of each launch — which is literally just the RPM of the launch — and converts those points into entries in a Japan-exclusive lottery for rarer Beyblades. Outside the domestic market the only realistic route is resellers, and the eBay Japan unit in this log arrived at an unfortunate scalper price.
Mechanism first: how a string pull becomes a countable signal
Nothing here required opening the case; given what the BX-09 costs, teardown risk was never on the table. The important parts are visible from outside.
Official Beyblade X launchers, the string launcher shown in the video included, expose two holes on the top face. Inside the first sits a small rotating disc that shifts from black to white depending on how quickly you pull the string.
Now the underside: load a Beyblade onto the three hooks and you also push a little white lever to the top, where it emerges from the second hole.
Aligning the two parts shows the interaction. Sliding upward, the lever enters the Beybattle Pass and signals that a Beyblade is attached; as a button it also powers the module on and wakes a sensor that watches the black-and-white disc while the string is pulled. Using a phone's front-facing camera on the footage, the element looks like an infrared sensor, and the working theory is that it tracks the rotating disc through changes in the reflected infrared signal — that count is what becomes the Shoot Power value.
Capture setup: sniffing BEYBLADE_TOOL01
Long press to power on, hold until the lights blink for pairing mode, and the peripheral announces itself as BEYBLADE_TOOL01. Connect, the blinking stops, and LightBlue plus PacketLogger is enough to watch the traffic. The official Beyblade X app does not have to be installed for launch data to appear.
After connecting, two characteristics are returned:
| UUID | Properties | Observed direction and role |
|---|---|---|
| 0x55c4f002f8eb11ecb9390242ac120002 | Read, Notify | Device to host: header, launch payloads, history dumps |
| 0x55c4f001f8eb11ecb9390242ac120002 | Write Without Response | Host to device: opcodes 0x74, 0x51, 0x75 |
At first the layout looked almost too easy — "Ok, this structure looks simple enough." — and subscribing to the Read and Notify characteristics produced nothing at all. The silence ended the moment the Beybattle Pass was mounted on a launcher with a Beyblade attached: an orange LED came on, and this arrived.
a0 3a 00 04 ff 00 00 00 00 00 00 00 35 b4 04 51 c4 da
Then the launch itself produced a much larger frame, still opening with the same page tags (a0, then b0 through b7, then 70 through 73):
a0 3a 00 00 ff 00 00 a2 0c 01 00 35 b4 04 51 c4 da
b0 a2 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b1 through b5: all 00 until launches accumulate
b6 00 00 00 00 00 00 a2 0c 01 00 01 00 00 00 00 00
b7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5e
70 f2 28 ef 0c cc 09 0f 09 6e 0b 67 0b 73 29 35 13
Several more launches confirmed the shape of the traffic: a small 17-byte header first, the bulky payload only once a Beyblade actually leaves the launcher.
Field map: what the header bytes mean
| Location in a0 | Observed value | Decoded meaning | Confidence |
|---|---|---|---|
| tenth byte (byte 10) | +1 per successful launch | Launch counter; a failed or dropped launch leaves it unchanged | High |
| bytes 8 and 9 | a2 0c, later 62 10 | Mirrored into the b* pages; carries the record score when a new best is set | High |
| bytes 12 to 17 | 35 b4 04 51 c4 da | The BLE device address in reverse byte order, constant across captures | High |
| bytes 3 and 4 | 00 04 armed, 00 00 otherwise | Status flag: Beyblade attached and ready, versus detached or dropped | High |
| byte 5 | ff (255) early, da (218) later | Probable battery level; the differing value inside the bulky payload is still unexplained | Working theory |
| b0 to b7 | byte pairs | Launch history FIFO, with the high score and totals mirrored near the end | High |
| b7, final byte | checksum | Sum of every b* data byte, skipping each page's tag byte and the checksum itself, modulo 256 | High |
| 70 to 73 | varies per launch | Not decoded; see the open-questions section | Unknown |
Byte order: the single mistake that breaks every reading
With each new launch, pairs kept appearing in the b* pages: first a2 0c, then 62 10, then 95 0d. Converted big-endian, a2 0c becomes 41,484 — impossible for a spinning top. Published figures put an average Beyblade launch around 5,000 RPM, so swapping the bytes was worth a try: 0c a2 → 3,234, which is plausible. Bluetooth Low Energy commonly uses little-endian byte order, least significant byte first, and the hypothesis held for the rest of the set:
| Raw pair as received | Little-endian swap | Decoded RPM | LED behaviour after the launch |
|---|---|---|---|
| a2 0c | 0c a2 | 3,234 | usual blink green |
| 62 10 | 10 62 | 4,194 | orange → red → green: a new record |
| 95 0d | 0d 95 | 3,477 | usual blink green |
That also closes the second mystery. Whenever bytes 8 and 9 reappeared inside the b* pages, the module lit differently — orange → red → green instead of the normal blink green — because those launches had beaten the stored value of 4,194, i.e. the high score field.
Buffer behaviour: what happens after the 50th launch
The b* pages fill from b0 onward, which raises an obvious engineering question: what happens at the last page, b7? After 50 more launches the answer showed up on the wire. At the 50th, the values in page b6 stopped at position 6 (counting from 1), leaving a gap filled with 00 00.
50th launch bulky payload (32 hex):
a0 3a 00 00 ff 00 00 61 16 32 00 35 b4 04 51 c4 da
b0 d6 0f c1 03 88 13 02 16 f0 14 c7 14 4e 11 98 13
b1 through b5: five pages of older launch pairs
b6 bc 0d 36 0d 00 00 61 16 32 00 32 00 00 00 00 00
b7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dc
followed by the 70 to 73 pages
51st launch bulky payload (33 hex):
a0 3a 00 00 ff 00 00 61 16 33 00 35 b4 04 51 c4 da
b0 c1 03 88 13 02 16 f0 14 c7 14 4e 11 98 13 18 12
b1 through b5: the same pairs, shifted one slot toward the front
b6 36 0d 2c 13 00 00 61 16 33 00 32 00 00 00 00 00
b7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 37
followed by the 70 to 73 pages
FIFO, in other words. The maximum number of launches that can be recorded is 50: the oldest entry at the beginning of b0 is discarded, and the new launch value is written to byte position 4 of page b6 (2c 13). After the padding at positions 6 and 7, the same high score appears again (61 16), followed by the total number of launches (33 00 → 51) and the number of stored entries (32 00 → 50, the maximum). The final byte on page b7, which resisted interpretation at first, is a simple checksum: add together every data byte across the b* pages, skip each page's tag byte and the checksum byte itself, and take the result modulo 256.
The write side: three distinct scenarios
Everything above came from reading the initial characteristic (0x55c4f002); the open question was what 0x55c4f001 is used for. Answering it meant installing the official Beyblade X app and sniffing Bluetooth traffic straight from an iPhone — installing an official Apple Bluetooth debugging profile and keeping the phone cabled to a Mac, which is the tedious part of this job. Once mapped, the write characteristic exposes three distinct scenarios.
| Opcode | Response shape | Function | Operational risk |
|---|---|---|---|
| 0x74 | b0 through b7, with the 7* pages absent | Full list of recorded launch values | Read-only |
| 0x51 | The 17-byte header | Initial metadata: counter, status flag, address, battery byte | Read-only |
| 0x75 | A previously unseen a1 page, then a zeroed a0 and every b* page | Clears the entire internal database | Destructive, no read-back |
For reference, the reply to 0x74 is the bulky payload without the 7* pages:
b0 a2 0c 71 0f 06 14 f4 13 55 11 88 13 bd 17 23 15
b1 46 13 c9 11 03 0c 1f 0f 46 0e 4d 1b 00 00 00 00
b2 through b5: unused pages, 00 filled
b6 00 00 00 00 00 00 4d 1b 0e 00 0e 00 00 00 00 00
b7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c
The reply to 0x51 is the header alone:
a0 3a 00 00 d3 00 00 4d 1b 0e 00 35 b4 04 51 c4 da
And 0x75 returns the extra a1 page first, then a wiped store:
a1 00 00 00
a0 3a 00 00 d3 00 00 00 00 00 00 35 b4 04 51 c4 da
b0 through b7: every byte reset to 00
That a1 page is what makes the destructive command unmistakable: one opcode lists the whole history, one fetches the metadata, and one clears the dataset.
Open question: the 7* pages
To this day those four pages are not decoded. Plotted in a spreadsheet, nothing immediately jumps out as a recognisable metric.
The working theory is that they hold physical data coming directly from the Beybattle Pass sensor, which would also explain why the 7* pages appear only when a Beyblade is actually launched, and never when the module is queried through the Write Without Response commands. Until that is confirmed, treat them as unvalidated telemetry: good for relative comparison between launches, not for absolute claims.
The companion build: DiZZi 0.2
A fully reverse engineered protocol makes one thing obvious: you can stop depending on the Japan-only app. The next step was a Bluetooth client of your own, portable to tournaments, that scores the highest spin on the table.
The UI brief came from the early-2000s anime: DiZZi 0.1, the AI companion living inside Kenny's computer, apparently exclusive to the Western version, with a distinctive voice and a sharp, sassy personality that analysed battle data, offered tips and occasionally roasted its operator. DiZZi 0.2 is the recreation of that role, driven end to end by the BLE protocol taken apart above. A screenshot of the reference frame went to Claude Code for the first layout sketch; after tweaking the measurements, the result is close to pixel-perfect. Feature set, all sourced from the Takara Tomy protocol:
- Scores after each launch
- A history of previous launches, color-coded by launch intensity
- The highest score
- Battery level
- The AI interface
The architecture reuses the pattern from Max Headbox with one change: voice is generated by Kokoro TTS, and every Ollama request is issued by the Express.js server instead of the browser.
Signal flow, stated as an integration checklist:
- The React frontend opens WebSockets to the Express.js backend for real-time data, and calls a few REST endpoints to trigger the specific Bluetooth commands 0x74, 0x75 and 0x51.
- Express.js connects to the BLE device BEYBLADE_TOOL01 and automatically subscribes to its Notify characteristic.
- When a new launch is detected, the BLE decoder module retrieves the launch data.
- The backend queries the Ollama API using the gemma3:1b model to analyse launch trends, then returns spoken feedback through Kokoro TTS.
The prompt is deliberately narrow, because the model is single-turn and activates on each launch event rather than running as a fully fledged agent:
You can roast the player by judging the result or be also be kind to him when the launch power is actually good.
Higher RPM is better: under 3000 is weak, 3000-7000 is alright, over 7000 is excellent.
Reply with ONE short sentence (max 15 words) about how the player's launches are going.
Small models such as gemma3:1b are weak at arithmetic, so raw numbers never reach the prompt: the trend is pre-computed and summarised instead.
function describeLaunches(launchesValues) {
const lastItem = launchesValues.at(-1);
const previous = launchesValues.slice(-4, -1);
if (previous.length === 0) {
return `First launch: ${lastItem} RPM.`;
}
const avgPrevious = Math.round(previous.reduce((a, b) => a + b, 0) / previous.length);
const diff = lastItem - avgPrevious;
const trend = diff > 300 ? 'improving' : diff < -300 ? 'getting worse' : 'about the same';
return `Previous launches: ${previous.join(', ')} RPM (average ${avgPrevious}).
Last launch: ${lastItem} RPM. Trend: ${trend}.`;
}
App state is derived only from device events, which keeps the client honest about what the hardware actually reported: a Bey is attached, a Bey is launched, a Bey is dropped (failed launch), and the BLE device connects or disconnects. Those same states drive the animations of the spinning 3D Beyblade model on the main screen.
The VoiceFlare component on the left is the polish layer. When a TTS wav file returns from the backend, the frontend plays it through the Web Audio API and pipes it into an AnalyserNode; on every animation frame the analyser returns the frequency spectrum of DiZZi's voice, and only the lower ~60% of the bins are kept to drive a canvas animation of blue and orange flame-like peaks and light streaks mirrored around a glowing horizon.
const analyser = audioCtx.createAnalyser();
analyser.fftSize = 256;
source.connect(analyser);
analyser.connect(audioCtx.destination);
The decoder and the DiZZi 0.2 client are published on GitHub.
Common misconceptions
- "The figure is the Beyblade's spin speed in the stadium." Shoot Power is the RPM of the launch itself, measured while the string is pulled.
- "You need the Beyblade X app to read anything." LightBlue and PacketLogger capture every launch; the official app is only required to map the write-side opcodes.
- "41,484 RPM is a world-record serve." That is a2 0c read big-endian; the little-endian value is 3,234.
- "History is unlimited." The FIFO stores 50 entries, so the 51st launch silently discards the oldest.
- "The battery byte is confirmed." The steady drift from ff (255) to da (218) supports the theory, but the different value in the bulky payload is still unexplained.
- "0x75 is a harmless reset." It clears the internal dataset, and there is no read-back.
Selection and integration advice
- Buy for the protocol, not the lottery: the Japan-only points system only pays off in the domestic market, while the BLE data path is useful anywhere.
- Budget for reseller pricing — an eBay Japan unit will land above the local street price of the rest of the line.
- Before experimenting, query 0x74 and archive the payload text; once 0x75 runs, the history is gone.
- Use two tools rather than one: LightBlue for interactive writes, PacketLogger for clean captures.
- Validate byte order against a known reference — an average launch near 5,000 RPM — before trusting any dashboard figure.
- Implement the modulo 256 checksum in your own client; it is the cheapest guard against truncated or mis-merged notifications.
- For tournament or kiosk deployment, keep the BLE bridge server-side: one Express.js host can serve multiple React clients over WebSockets, so phones stay out of the data path.
- Assume the battery byte is advisory only if you build alerts on it, and label the 7* pages as unvalidated in any export.
Verdict from the bench
As a product the BX-09 is a niche accessory; as a reference design it is unusually clean — a two-characteristic BLE service, a payload layout that yields to inspection without a teardown, a hard 50-entry ring buffer, and a checksum you can reimplement in an afternoon. Two gaps remain open: the battery byte and the 7* sensor pages. If you have captures from a fresh unit, especially a charge-to-dead record or 7* samples taken across different launcher strings, send them to Tech Daily at hello@techdaily.com and MyTechDailyNews Hardware will publish the decode.