Interpreting LiteJam's Publicly Available BLE Interface

What the publicly accessible web controller was built for, how its published code describes the protocol, and why that is not the same as delivering a documented Open API

Project: LiteJam BLE Lab
Document date: September 1, 2026
Primary evidence archive: C:\Users\david\litejam-analysis

Provenance and scope: This work used only materials that LiteJam made freely available through its public websites and updater, plus ordinary communication with the user's own guitar. No authentication, encryption, access control, firmware protection, device security, or private system was bypassed. “Analysis” in this document means reading and interpreting those published materials with standard developer tools.

Executive summary

LiteJam placed a functioning guitar-control application at playground.litejam.com. The page identifies itself as Litejam Web Control — BLE Live. It is a substantial LED design and test environment: it paints the fretboard, renders a 3D digital twin, generates text and animated effects, assembles clips on a timeline, streams frames to multiple guitars, and stores animations in guitar memory.

The Playground does not look like a finished developer portal. Its publicly served source describes features ported from a “mobile mockup,” retains a localhost Python/Bleak bridge, mentions an internal documentation filename, and contains engineering comments about pixel transforms, BLE backpressure, Chrome flags, and firmware configuration. No internal document was accessed. The most supportable interpretation is that it began as an engineering prototype, test harness, or developer demonstrator and was later deployed to a public subdomain with direct Web Bluetooth support.

Deployment made the protocol technically public. To control the guitar from Chrome, the page must send every visitor's browser the BLE UUIDs and the JavaScript that constructs outgoing packets. Its code reveals the live LED protocol on characteristic EE04, including fret numbers, six-string bitmasks, RGB bytes, packet limits, and the final ASCII marker END. Production GlowTab code and official ESP32 firmware independently corroborate that interpretation.

But “publicly inspectable implementation” is not the same as “documented, supported Open API.” The Playground requires no login and is indexed by search engines, yet the customer-facing navigation and support pages examined do not point to it or to API documentation. LiteJam's March 7, 2026 article “Litejam Open API in Action” says the API allows “anyone” to connect directly to the fretboard, while a community onboarding report describes a gated developer-program form and inaccessible Discord invitation. The commissioning user reports repeatedly requesting Kickstarter-promised API access and receiving no response.

The evidence shows a mismatch between the company's Open API rhetoric, the discoverability and support of its developer interface, and the existence of a powerful but lightly publicized web tool. The ability to interpret a freely published implementation does not by itself establish that any Kickstarter promise of documented API access was fulfilled.

1. What “shipped in readable JavaScript” means

A Web Bluetooth application runs its BLE client inside the user's browser. To control the guitar, its JavaScript must:

1. Ask the browser to select a Bluetooth device.
2. Connect to the device's GATT server.
3. Locate services and characteristics by UUID.
4. Construct byte arrays in the guitar's expected format.
5. Write those bytes to the correct characteristics.

Those operations must be delivered to the browser. A site can minify its program, rename variables, and combine modules into a hashed bundle, but it still sends the connection logic and packet constructor to every visitor. Standard browser developer tools or an ordinary HTTPS download can display the same program the browser executes.

“Readable” does not mean LiteJam published original source code or API documentation. The Playground contains unusually clear, unminified inline JavaScript. GlowTab uses a production bundle with shortened names, but mechanical formatting restores indentation and line breaks while preserving behavior. Numeric constants, error strings, validation rules, array construction, and Web Bluetooth calls remain directly traceable in both.

2. What the LiteJam Playground actually is

The Playground is a full creative control surface for the illuminated fretboard. Its visible interface and source implement:

• Six-string fretboard views for 22- and 25-column model geometry.
• Direct Web Bluetooth attachment to one or more guitars.
• An alternate connection through ws://127.0.0.1:8787 to a local Python/Bleak bridge.
• A rotatable 3D guitar “digital twin” described as showing exactly what is transmitted.
• Live painting and streaming of individual LEDs.
• Fixed and scrolling text rendered on the fretboard.
• More than twenty effects, including fire, wave, chase, sparkle, Tetris, Pong, emoji, notes, and rain.
• A three-track, clip-based timeline editor with a movable playhead.
• Browser-local presets and loop libraries.
• Persistent animation upload and deletion through characteristic EE08.

This breadth suggests a tool for prototyping and exercising the entire visual system, not a narrow public API sample. A firmware or application team could use it to test model geometry, rendering, animations, timing, multi-device behavior, transports, persistent storage, and proposed mobile workflows.

2.1 Evidence of its development-tool origins

The following source artifacts are especially revealing:

• A top-level comment calls the page all mobile-mockup features wired to the real BLE bridge.
• Effect and Studio comments say their engines were “ported from mobile mockup.”
• The bridge protocol is called bnk-guitar-led-v1 and refers to bridge/ble_ws_bridge.py, a local developer-side Python component using Bleak.
• An animation comment cites docs/ble-animation-protocol.md in firmware, an internal repository path rather than a public document.
• Debug output is gated by window.LJ_BLE_DEBUG.
• Comments discuss firmware configuration symbols, pixel ordering, BLE write backpressure, Chrome experimental flags, and differences between hosted and locally served operation.
• The entire application is a monolithic HTML file with extensive inline CSS and JavaScript, not an SDK package or documentation site.

The best-supported interpretation is that the Playground began as an engineering prototype or test harness connecting a mobile-interface mockup to real guitars through a desktop BLE bridge. Direct Web Bluetooth was added later, making the hosted page self-contained in Chrome. It may then have served demonstrations, selected developers, internal remote testing, or rapid feature experiments. The source does not name its intended audience, so a more specific motive would be conjecture.

2.2 What it was not designed to be

The Playground has no protocol reference, changelog, semantic version, compatibility matrix, SDK package, public license grant, third-party tutorial, issue tracker, or stated support commitment. It delivers implementation details to every visitor because it must execute in the browser, but it does not teach an outside developer how to maintain an integration.

The controlling distinction is:

A working first-party client is evidence of a protocol. A supported API is a product commitment.

3. Publicly reachable, but not meaningfully announced

The word “public” has several relevant meanings:

The Playground subdomain returned neither a robots.txt file nor its own sitemap when checked. That only means the subdomain lacks ordinary discovery metadata. Search indexing and the absence of authentication confirm that it was publicly accessible.

The most precise description is “publicly accessible but not prominently linked.” Someone who knew the hostname or searched the relevant terms could find it, while a customer following LiteJam's advertised pathways could easily never encounter it.

4. The exact files examined

The GlowTab page itself was archived as glowtab.html. Its module-script reference identified the hashed JavaScript asset. A hashed production filename is not encryption.

5. How the protocol was located

The interpretation followed the actual data path to Bluetooth:

1. Download the public HTML and referenced JavaScript unchanged.
2. Record sizes and SHA-256 hashes.
3. Format the minified GlowTab bundle with Prettier.
4. Search for navigator.bluetooth.requestDevice, gatt.connect, getPrimaryService, getCharacteristic, and characteristic writes.
5. Trace the UUID constants passed into those methods.
6. Trace backward from each write to its Uint8Array constructor.
7. Convert decimal production constants to hexadecimal.
8. Compare the production path with the explicit Playground encoder.
9. Search official firmware for matching UUIDs and nearby descriptions.
10. Implement the packet grammar independently and test its output.

This follows code that ends in an actual browser Bluetooth write, rather than relying only on suggestive labels.

6. What production GlowTab disclosed

At approximately line 61622 of the formatted GlowTab bundle, an object named Qi contains these values:

The surrounding code requests a device, connects its GATT server, obtains both services and their characteristics, reads initial values, and starts notifications. These are active identifiers, not unused constants.

The command wrappers reveal more:

At approximately line 62315, a formatted function named jo allocates a byte array, writes the number of color groups, converts strings 1–6 into bits 0–5, appends RGB bytes, and ends with decimal 69, 78, 68—ASCII END.

7. The publicly observable live-LED packet

Both clients imply the same EE04 layout:

byte 0: color-group count

for each color group:
    byte: position-pair count
    repeat for each position pair:
        byte: fret number
        byte: six-string bitmask
    byte: red
    byte: green
    byte: blue

final bytes: 45 4E 44    ASCII "END"

Strings use bit 1 << (string - 1). Strings 1 and 3 therefore become 0x05. One color group assigning red to those strings at fret 5 is:

01 01 05 05 FF 00 00 45 4E 44
│  │  │  │  └─ RGB red ─┘ └ END
│  │  │  └ string mask: strings 1 and 3
│  │  └ fret 5
│  └ one fret/mask pair
└ one color group

The encoder in C:\Users\david\litejam\app.js independently implements this grammar.

8. Why the Playground source was decisive

Around lines 1067–1070, the Playground names service 00EE, mode characteristic EE01, preview characteristic EE04, animation characteristic EE08, a 6×25 hardware frame, and a 240-byte maximum EE04 payload.

Its encodePixels function groups positions by RGB color, merges same-fret strings into a bitmask, fills omitted positions with black, limits each write to 25 color groups, appends END, and returns characteristic/payload pairs. An all-black frame becomes a one-byte zero command on EE01.

The same file contains device selection, GATT connection, service and characteristic discovery, an explicit error if EE04 is absent, and a write routine that transmits the constructed Uint8Array. The encoder feeds the live BLE path; it is not unused mockup code.

The Playground also publishes stored-animation behavior on EE08: versioned begin, chunk, commit, and delete operations; PAL16 pixel packing; 180-byte chunks; and CRC-16/CCITT-FALSE. This further demonstrates the depth of protocol information delivered to the browser.

9. Firmware supplied independent corroboration

LiteJam's public updater supplied ESP32 images for RGB24, RGB24L, and RGBA1. They passed esptool checksum and image-hash validation. Standard inspection of those vendor-published files displayed main/ble_gatt_server.c or equivalent GATT metadata and these descriptions beside the corresponding UUID structures:

EE01  Set LED Mode
EE02  Set Pattern
EE03  Set Party Mode
EE04  Set Segment LED
EE05  Set Sound React
EE06  Set Sound React Data
EE07  Set Full Logo Color

EE07 appears in RGB24L and RGBA1 firmware; older RGB24 provides the earlier set. This explains GlowTab's anonymous CHR_B1–CHR_B6 and independently confirms EE04 as the segment/live LED endpoint.

The published firmware metadata was used only to corroborate the GATT map and characteristic meanings already visible in LiteJam's web clients. No further firmware-code interpretation was needed for the implemented live-LED interface, and fields for unrelated pattern, party, and sound-react commands remain unspecified.

10. Why might LiteJam gate official access when an implementation is public?

No available evidence establishes LiteJam's motive. Several nonexclusive explanations fit the facts:

1. A published implementation is not the same as support. LiteJam may treat bytes inside its own clients as implementation details while reserving “API” for documentation, examples, and a developer program.
2. The protocol may be changing. RGB24, RGB24L, and RGBA1 show version and capability differences. A documented contract creates compatibility expectations that an internal tool does not.
3. They may be controlling support load. A form or Discord gate can limit questions and keep experimental integrations among selected users.
4. The Playground may have outgrown its original audience. A tool can be hosted publicly for demonstrations or remote testing without marketing or support treating it as a customer deliverable.
5. Organizational coordination may be poor. The company praises an Open API, a reported email directs users into a developer program, the main site lacks an API entry point, and some participants report inaccessible invitations.
6. They may want control over naming or permission. An official program can impose branding, license, safety, or distribution terms even when raw BLE is inspectable. No such terms were found in the Playground.

The evidence supports poor discoverability and inconsistent official access. Public availability and search indexing establish that the technical materials were available without circumvention; absent documentation and unanswered access requests remain relevant to whether promised developer access was adequately delivered.

11. Does the Playground fulfill a promised Open API?

Technically, the Playground makes independent control possible. Contractually or as a consumer representation, that may not be the same as delivering promised API access.

A reasonable developer understanding of an announced API commonly includes some combination of:

• A documented connection procedure and UUID map.
• Defined requests, responses, and errors.
• Compatibility and version information.
• Examples or an SDK.
• Terms permitting third-party use.
• A distribution channel communicated to promised recipients.
• A route for developer support or defect reporting.

The Playground supplies almost none of that explicitly. It supplies a first-party implementation from which a developer can interpret the protocol using ordinary browser tools. Requiring a backer to discover an unlinked subdomain, read thousands of lines of publicly served JavaScript, interpret minified constants, and compare published updater metadata is not ordinarily what “API access” communicates.

LiteJam's March 2026 Open API article says the API permits anyone to connect directly to the fretboard and invites developers to build, but provides no documentation or access link. A January 2026 community onboarding post describes a Join the Litejam API Developer Program email, form, and broken Discord access. The commissioning user's account of repeated unanswered requests is consistent with that problem, although the correspondence has not been reviewed here.

This analysis does not determine whether a legally enforceable Kickstarter promise was breached or whether class treatment is available. Those questions depend on the exact campaign statement, reward terms, updates and emails, governing terms, jurisdiction, reliance, damages, arbitration provisions, and other backers' experiences. The narrower technical conclusion is firm:

An inspectable first-party implementation does not automatically cure a failure to deliver promised documented or supported API access.

Anyone evaluating the promise should preserve the campaign page, reward description, API-related updates and emails, developer-program form, support requests, responses or nonresponses, and dated captures of the current website. What was promised, what was communicated, and what was merely discoverable in source code are distinct facts.

12. What is proven, inferred, and unverified

Interpretation of the published format and hardware validation remain different steps. The format is directly shown by LiteJam's executable web clients. Acceptance by a particular guitar remains an empirical test.

13. How this became the custom web app

LiteJam BLE Lab independently implements the publicly observable packet format. It represents 150 positions, groups RGB values, combines strings into masks, includes black positions, appends END, and splits frames at 240 bytes and 25 groups.

Automated tests cover the fret-5/string-1-and-3 mask, terminator, black framing, hexadecimal parsing, and worst-case chunking. A 150-color frame becomes six legal packets. These tests prove consistency with the published-client format; physical-guitar testing confirmed interoperability.

Conclusion

LiteJam did not publish a readily discoverable conventional API document. It did deploy a remarkably capable Web Control Playground whose browser code necessarily contains an executable protocol description. Its comments and architecture indicate that it evolved from a mobile-mockup and BLE-bridge development environment into a publicly hosted Web Bluetooth controller. GlowTab provides an independent production implementation, and firmware supplies matching UUIDs and descriptions.

That combination made a custom LED controller feasible directly from readable, publicly served software, without relying on mobile binaries. The essential path—connect to service 00EE, construct grouped fret/string/RGB data, terminate it with END, and write it to EE04—was already visible in LiteJam's browser application.

Why was the API difficult for customers to find despite the public implementation? The protocol was available through LiteJam's publicly served web code, but the company did not present the Playground or protocol as a documented developer deliverable through the customer-facing paths examined. That may reflect instability, gated support, a prototype deployed beyond its original audience, organizational dysfunction, or another reason not established by the evidence.

Whatever the motive, public availability of working client code and fulfillment of a promised Open API are not synonymous. The technical obstacle is now much smaller than it appeared. The communication and promise-fulfillment questions remain.