# Reverse Engineering the Pinsetter: How We Integrated Legacy Bowling Equipment with a Mobile App
After three years of failed attempts to extract data from mechanical bowling machines (pinsetters), the Brooklyn Bowl team turned to reverse engineering the critical sensor digitization unit. The main hurdles were a proprietary interface, an outdated tech stack, and a lack of documentation. In this article, we'll break down the system's architectural quirks, why standard integration methods failed, and the solution that, while not elegant, actually works.
Pinsetter Architecture and Data Flow
A mechanical pinsetter is a complex machine reminiscent of a tank's automatic loader. After the ball is thrown, an optical sensor triggers to detect the object passing by. Then a measuring frame with holes lowers to check for pins in each position using photodiodes or contact probes. Sensor data feeds into the NextGen unit, which converts it into game events (like the number of pins knocked down). This unit connects to a Dell OptiPlex 3020 server (2014 model) via a proprietary current loop serial interface. The server handles game status and displays results on monitors above the lanes.
It's crucial to understand that the machine itself doesn't digitize signals—that's handled by the external NextGen unit. Data is sent in raw hex format without a standard protocol. The system lacks support for modern tech like IoT or MQTT, making integration with external systems (like a mobile app) extremely challenging.
Three Fundamental Integration Challenges
Attempts to pull data hit three insurmountable barriers:
- Commercial restrictions from Brunswick and AMF. Manufacturers deliberately block third-party integrations to monopolize sales of add-on modules (e.g., for displaying scores on websites or integrating with club cards). Any workaround requires buying a license, making it economically unviable.
- Outdated tech stack. The Dell server runs FoxPro and Sybase SQL Anywhere databases. FoxPro locks the database during writes, crashing the main software if read simultaneously. Sybase needs ODBC drivers, and credentials are buried in Brunswick binaries, making access nearly impossible without decompiling.
- No push mechanism and unstable data. The system doesn't push data on events; the server constantly polls it. Plus, game status can get corrected: for example, it might first register two pins down, then instantly all ten. These async corrections cause data discrepancies, making a reliable event stream impossible.
Failed Approaches: Analyzing the Shortcomings
The team and hired engineers tested four methods, all unviable for production:
- Reading the database on the Dell server. Connecting to FoxPro or Sybase caused lock conflicts and crashed the core software. Even successful reads had delays unsuitable for real-time mobile apps.
- Integrating with the NextGen unit. Direct current loop access gave raw hex data, but without docs, decoding was a puzzle. Traffic analysis showed the format varies by machine state, and status corrections added "noise" to the stream.
- Computer vision over the lane. Installing a camera and using OpenCV to detect pin positions required perfect lighting and calibration. In real conditions (player movement, shadows, glare), accuracy dropped below 70%, making it unacceptable.
- Full NextGen rewrite. Emulating the unit was technically daunting: it needed to replicate all pinsetter interactions, including status correction handling. The project stalled at prototype due to complexity.
Approaches like OCR from monitors via HDMI splitter or printer emulation weren't tested—their reliability seemed low due to extra failure points.
Working Solution: Replacing the Digitization Unit
The current setup reverse-engineers the NextGen unit. Instead of integrating with the legacy system, engineers built a custom module that connects directly to the pinsetter's sensors. This module:
- Captures analog signals from photodiodes and contact probes.
- Digitizes data at 100 Hz, filtering false triggers.
- Generates events in JSON format and sends them to the server via MQTT.
The key advantage is isolation from the legacy system: the new module bypasses Dell and NextGen entirely, dodging all restrictions. The downside is physical mods to each machine, requiring 2-3 hours of lane downtime. But for Brooklyn Bowl's network of 12 bowling alleys, it was the optimal fix.
Key Takeaways for Engineers
- Don't waste time bypassing commercial locks. If a manufacturer intentionally restricts access (like Brunswick), isolate critical components instead of integrating with legacy systems.
- Raw sensor data is your best friend. In systems without digital interfaces, hooking straight into analog sensors is often simpler than decoding proprietary protocols.
- Reverse engineering takes patience. Analyzing current loop traffic took 6 months but revealed hex data patterns for filtering status corrections.
This solution isn't perfect, but it works. For other bowling alley owners with similar gear, we're happy to share our experience—contacts at the end of the article.
— Editorial Team
No comments yet.