DRAFT · SPECULATIVE

Bollard Physical Specification

Version 1.0-draft · Status: speculative draft · Updated 2026-11-07

Speculative draft. No Pop Boll hardware has shipped, and nothing on this page has been built or validated on hardware. Dimensions, pinouts and protocols will change without notice, and nothing here is an offer, a commitment or a promise of compatibility. We would love to hear about partnership, OEM and dev-kit ideas: use the contact form on this site.

Bollard is the open interface on the bottom of a Pop Boll: how a dock, a speaker, a charging stand, a stack of light pucks or a cartridge computer mates with the ball. This document fixes only that interface. Everything else about your device (its shape, its sound, its price) is yours. The software that runs over the connector is the bollardeck API, and the overview page introduces both.

1. Scope and conventions#

This specification defines how a dock mates with the bottom (the south-pole foot) of a Pop Boll. For the Full profile it also defines how independently made cylindrical modules, called pucks, stack under a Boll in any order. Docks are expected to compete with each other: a three-foot reverse-tapering tower with booming bass, a dock with its own processor that reads the song's MIDI and remixes it, a charging stand with a light ring, a bookshelf amp. The specification fixes only the interface between them and the Boll.

The key words MUST, MUST NOT, SHOULD, RECOMMENDED and MAY are used as described in RFC 2119.

• All dimensions are in millimetres and all angles in degrees unless stated otherwise.
• Tolerances are given as ± or as upper and lower deviations: Ø 41.5 −0.05/−0.15 means 41.35 to 41.45.
• Figures marked estimate come from calculation or datasheets, not from a measured sample.
• Part numbers are examples. Any part that meets the stated requirement is conforming.
• Requirement identifiers (L1, U3, M6 and so on) are stable within a version, so conformance claims can cite them.

1.1 Terms#

2. The interface in brief#

Decision (normative): the Bollard interface is a 3.5 mm TRS plug, a USB-C plug and a BCR-10 row (a straight 1×10 row of spring pins at 2.54 mm pitch), all on one floating plate inside a spring piston. They mate with a 3.5 mm jack, a USB-C receptacle and 10 hard-gold pads in the floor of the Boll's foot well. Four NdFeB magnets hold the Boll down, and a key bump sets its rotation.

The three connectors split the work:

• 3.5 mm TRS carries analog stereo audio (A-BUS) down the stack.
• USB-C carries power up to the Boll and USB 2.0 data, with the Boll always the USB host.
• BCR-10 carries the stack rail (V_STACK), ground, I2C for enumeration and control, a service-request line, hardware beat sync, the point-to-point CHAIN line, and a 5 V charging input for docks without USB.

Why a straight spring-pin row:

• Anyone can buy the male side. It is a standard 0.1-inch single-row spring-pin strip that solders straight into perfboard. The female side is copper pads on any PCB.
• The pins ride on the floating plate with the plugs. Once the plugs enter their jacks, the plate is registered to the Boll and the pins land on the pads within the plug fit, so tolerances do not add up through a stack.
• When nothing is docked, the piston face covers the pins and the plugs, so a dropped Boll, a coin or a finger cannot bend or short them.
• The pads sit flush in the floor of a recessed well, away from the face that meets tables, coins and wet worktops.

Alternatives that were evaluated and set aside: magnetic pogo connector pairs (no common standard for pitch, magnets or polarity; their magnets fight the four retention magnets; retail 2.54 mm versions stop at 5 contacts), a second USB-C receptacle used as a custom connector (it shears in a knock, and people would plug chargers into it), a pin header behind a door (not blind-matable), leaf or button spring contacts (short stroke, and they snag when slid sideways), and DIN, mini-DIN or a second TRRS barrel (contacts short while sliding in, and the pins are fragile).

Two of them remain allowed inside a dock. A Lite dock MAY use a magnetic pogo module behind its boss, and any dock MAY use leaf or button spring contacts at the BCR-10 positions, as long as the contact positions, the boss or piston, and conformance items M3 and M6 (§21) are met.

   A Boll seated on a dock (side view, not to scale)

              .-------------------------------.
             /            POP BOLL             \
            |      glowing ball, Ø 135 mm       |
             \                                 /
              '----.  foot well (female)  .---'     well floor: 3.5 mm jack, USB-C
          ~~~~~~~~~|______________________|~~~~~~   receptacle and 10 gold pads
          =========|  piston (pushed in)  |======   dock top face (male): plugs and
          |        | [3.5]  [C]  :::::::: |     |   BCR-10 pins on the floating plate
          |        '----------------------'     |
          |                 DOCK                |
          '-------------------------------------'

3. Profiles#

All profiles mate with the same foot. They differ only in which of its features they use, and no profile adds a connector. A dock declares exactly one profile.

Any dock, on any profile or with no physical connection at all, MAY also speak bollardeck over BLE.

            what each profile puts against the Boll's foot (dock top faces, side view)

   Full                 Lite                 USB-C                Passive
   ___|piston|___       ___|boss|___         ___|boss|___         ___|piston|___
  | [3.5] [C]    |     |  (no plugs)  |     |     [C]     |      | [3.5]  [C]   |
  | ::::::::::   |     | :  ::  :     |     |  no pins    |      |  no pins     |
  | BCR-10 (10)  |     | pins 3,7,8,10|     |  magnets    |      |  magnets     |
  '--------------'     '--------------'     '-------------'      '--------------'
   stack, sync,         charge (V_AUX),      USB power, USB       line audio,
   V_STACK, A-BUS       1-Wire ID, SYNC      audio, bollardeck    USB-C charge

A USB-C or Passive dock may use either the piston or a fixed boss (rules C1 and P1 below), so the drawing shows one of each.

3.1 Compatibility matrix#

✓ = works · opt = works if the dock implements the optional part · — = not available.

3.2 Lite profile rules#

• L1 Pilot. A fixed boss Ø 41.5 −0.05/−0.15 with a 2.5 × 45° lead chamfer and the key bump of §5.2. Its face is at +7.0 above Datum A, so it stops 0.5 mm short of the well floor (+7.5).
• L2 Pins. Spring pins at BCR-10 positions 3, 7, 8 and 10 only (§6), with free tips 0.7 ± 0.25 mm above the pad plane at seat (+8.2 above Datum A). The other six positions MUST be empty.
• L3 Retention. Magnets N pole up at the §5.2 positions, or steel discs at the same positions.
• L4 V_AUX. 5.0 V ± 5 %, at most 2.0 A, current-limited (an eFuse set to ≤ 2.2 A), and switched on only when a seated Boll is detected (a Hall sensor under one of the Boll's magnets, or a pilot switch). The Boll treats V_AUX ≥ 4.5 V for 50 ms as attach.
• L5 ID. A 1-Wire slave (standard speed) on pin 7 that holds the 32-byte binary header of §12.5, followed by up to 96 bytes of short descriptor. A 1-Wire EEPROM works, and so does a small microcontroller emulating one (example: WCH CH32V003).
• L6 SYNC. Pin 8, receive only. There is no I2C, CHAIN or colour-frame broadcast on the Lite profile.
• L7 Terminal. A Lite dock is the bottom of the stack and MUST NOT offer a female face.

3.3 USB-C profile rules#

• C1 Pilot. The piston of §5.2 is RECOMMENDED. A fixed boss per L1 is allowed if the USB-C plug floats (±0.4 mm radial, ±3° tilt).
• C2 Power and roles. The dock is a USB Type-C Source to the Boll (5 V, up to 3 A; USB PD optional) and MUST accept a data-role swap (DR_Swap) from the Boll (§10, U1).
• C3 Device. The dock is a USB 2.0 device with a CDC-ACM interface whose interface string is bollardeck (bollardeck transports). It MAY add USB Audio Class 2 sink and/or source functions.
• C4 No pad contact. Nothing touches the pads, and the Boll leaves them high-impedance.

3.4 Passive profile rules#

These rules are numbered P1–P4 within the Passive profile. They are separate from the power rules P1–P8 in §9.2, and the checklist in §21 says which is meant.

• P1 Pilot. As C1, with both plugs on one floating plate.
• P2 Audio. The 3.5 mm plug receives A-BUS per §11.
• P3 Power. The dock is a Source only. D+ and D− are left unconnected, or wired straight to a rear receptacle under rules U3 and U5 (§10).
• P4 Identity. None. The Boll sees a USB-C attach with no USB data partner and no answer at I2C address 0x2F. It labels the dock "passive", routes audio to its foot jack and charges.

4. Coordinates and datums#

• The origin is on the module axis, in the interface plane.
• +Y points to the module's front, which on the Boll is the direction of its medallion (the control panel with its buttons and ports). This direction is 0°.
• +X points to the right when you look down at a dock's top face with +Y pointing away from you. The 3.5 mm plug is at negative X and the USB-C plug at positive X.
• The Boll's foot, seen from below, is the mirror image: its +X points to the left, so pad 1 (x = −11.43) is on the right when you look up at the Boll.
• Datum A is the top of the dock's rigid land, which is the same plane as the Boll's rigid foot face when the Boll is docked. All heights are measured from Datum A, positive toward the Boll (upward, for a dock standing on a table).
• The only angular positions in this version lie on the axes: the four magnets on the ±X and ±Y axes (0°, 90°, 180° and 270°), and the Boll's well drain and the Boll Cap's side ports at the rear (−Y, 180°).

4.1 Heights at a glance#

The well floor is 7.5 mm above Datum A, which is 10.5 mm above the Boll's TPE rim plane. Earlier drafts measured the 10.5 mm from Datum A; the figures above are the corrected ones.

5. Mechanical interface#

5.1 Module classes#

These classes apply to Full-profile modules. Docks on other profiles, and terminal docks that offer no female face, may be any shape that meets the stability rules of §16.

A module with both faces is at least 48.5 mm tall, because two assemblies stack on the same axis: the top plug assembly (15 mm of piston travel, the piston guide and the plug bodies, about 23 mm) sits above the bottom jack assembly (the 10.5 mm well measured from the rim plane, plus jack bodies of about 15 mm). 50 mm is the first multiple of 25 mm above that.

5.2 Top face (male)#

   DOCK TOP FACE, viewed from above (piston drawn retracted; +Y = front = 0°)

                               magnet (N up)
                 .-------------------------------------------.
               .'   TPE seat ring Ø70 / Ø58, land Ø56 / Ø50   '.
              /      .--------------------------------.         \
   magnet    |      /  piston Ø41.5                    \         |    magnet
   (N up)    |     |          key bump o (0, +15)       |        |    (N up)
             |     |                                    |        |
             |     |    ( )                [=USB-C=]    |        |
             |     |  3.5 (-7, 0)           (+8, 0)     |        |
             |     |                                    |        |
             |     |   1  2  3  4  5  6  7  8  9 10     |        |
             |     |  [:  :  :  :  :  :  :  :  :  :]    |   BCR-10 pins, y = -11.0
             |      \   slot 25.0 x 3.6 in the piston  /         |
              \      '--------------------------------'         /
               '.                                             .'
                 '-------------------------------------------'
                               magnet (N up)
                              -Y (rear, 180°)

5.3 Bottom face (female)#

The Boll's foot and the underside of every puck present the same female face.

The Boll's own foot adds a drain and specific parts (§15).

   BOLL FOOT, viewed from below (looking up at the Boll; medallion toward the top of the page)
   This is the mirror image of the dock view: interface +X points LEFT here.

                               magnet (S down)
                 .-------------------------------------------.
               .'    TPE rim Ø70 / Ø58, foot face inside      '.
              /      .--------------------------------.         \
   magnet    |      /  well Ø50 -> Ø42                 \         |    magnet
   (S down)  |     |          key pocket o (0, +15)     |        |    (S down)
             |     |                                    |        |
             |     |   [=USB-C=]               ( )      |        |
             |     |    (+8, 0)            3.5 (-7, 0)  |        |
             |     |                                    |        |
             |     |  10  9  8  7  6  5  4  3  2  1     |        |
             |     |  [] [] [] [] [] [] [] [] [] []     |   pads in the well floor, y = -11.0
             |      \          o drain (0, -16)        /         |
              \      '--------------------------------'         /
               '.        drain exits to the rim at 180°       .'
                 '-------------------------------------------'
                               magnet (S down)

5.4 Piston and floating plate#

• The piston hides the plate when nothing is docked. Its face covers both plugs and the pin row, which sit at least 0.5 mm below it.
• The plate carries both plugs and the BCR-10 row and floats ±0.4 mm radially and ±3° in tilt on a spring gimbal. The plugs register the plate to the Boll, and the pins move with the plate.
• Lateral loads MUST flow well ↔ piston ↔ piston bore (guide length ≥ 20 mm). Neither the plate, nor the plugs, nor the pins may be a structural load path.
• Bayonet or twist retention is not allowed: it would shear the USB-C plug.

Order of engagement while a Boll is pressed down: the lead chamfer finds the well (capture about ±4 mm), and the key finds its pocket at up to ±8° of rotation, self-correcting. The piston retracts. The plugs enter the jack and the receptacle and pull the floating plate into registration. The pins touch the pads last, 0.7 mm before Datum A seats. The pads therefore never see a pin slide across them under load, and no pin touches a plug shell.

5.5 Forces and tolerances#

6. BCR-10 contact row#

   BCR-10 row on the dock's top face, viewed from above (row at y = -11.0, pitch 2.54 mm)

   pin:      1       2       3       4       5       6       7       8       9      10
   x:     -11.43   -8.89   -6.35   -3.81   -1.27   +1.27   +3.81   +6.35   +8.89  +11.43
            [ ]     [ ]     [ ]     [ ]     [ ]     [ ]     [ ]     [ ]     [ ]     [ ]
          V_STACK V_STACK   GND     GND     SDA     SCL   ATTN_N   SYNC   CHAIN   V_AUX

Example male parts: a 10-position, 2.54 mm single-row spring-pin strip such as Mill-Max 823-22-010-10-040101, or any generic 2.54 mm spring-pin strip for hobby builds. Mill-Max offers several 10-position single-row series (818, 823, 837, 873 and others) with different strokes and heights, and the stroke and force of the example part have not yet been checked against the requirement above. Generic strips are usually not rated for 5,000 cycles.

The female side is a strip of pads on any PCB. On the Boll it is a 1.0 mm FR-4 pad strip potted flush with the well floor. A reference pad-strip layout will be published with v1.0 final.

7. Pinout#

The two power pairs sit at one end of the row and the 5 V input at the other, so a half-seated or tilted plate cannot bridge V_STACK to a logic pin before ground makes contact: pins 3 and 4 always sit between them.

• In a pass-through module, pins 1–8 and 10 are wired straight through: top pin n to bottom pad n.
• Pin 9 MUST NOT be wired through, except in Class-0 modules (§12.2).
• On the Boll itself, pads 1 and 2 (V_STACK) are not connected: the Boll neither sources nor sinks V_STACK.
• A Lite dock populates only positions 3, 7, 8 and 10.

8. Electrical limits#

9. Power#

9.1 The three rails#

9.2 Power rules#

• P1 A module MUST NOT source VBUS on its bottom receptacle. It MAY source VBUS on its top plug, and is then the Boll's power source.
• P2 A V_STACK source MUST feed the rail through an ideal diode or a diode-OR (example controllers: TI LM74700, TI LM66100), limit its own current to ≤ 4 A and stay within 10.0–17.0 V.
• P3 A V_STACK sink MUST declare vstack_ma_avg and vstack_ma_peak (§12.5) and MUST tolerate the rail vanishing at any time.
• P4 V_STACK inrush MUST be ≤ 1 A for ≥ 1 ms, with ≤ 47 µF before the soft-start.
• P5 The stack host sums the declared loads. If they exceed what is available, it MUST switch off the lowest-priority loads (command 0x11, POWER_OFF, §12.4).
• P6 Module logic SHOULD be diode-ORed from VBUS pass-through and V_STACK into a ≤ 3.3 V regulator, so the module can enumerate on either rail.
• P7 A passive module's VBUS pass-through MUST be ≤ 0.10 Ω round trip at 3 A. At most 2 passive modules may sit between a VBUS source and the Boll.
• P8 A V_AUX source MUST hold 5.0 V ± 5 %, limit to ≤ 2.2 A and feed through an ideal diode. V_AUX MUST NOT power loads in the stack.

9.3 Power classes#

9.4 What the Boll sources and sinks#

• The Boll never sources power on its foot. Its foot USB-C only receives power, its V_STACK pads are not connected, and pad 10 is an input only.
• On its foot the Boll sinks USB-C VBUS at 5 V, up to 3 A, or V_AUX at 5 V, up to 2 A.
• The only place a Boll supplies power is its medallion USB-C port, at most 5 V / 1.5 A (7.5 W), for cable-attached accessories. Those are USB accessories, not Bollard devices.
• So every powered dock, speaker and cartridge on the foot brings its own power, and charges the Boll as a side effect.

10. USB-C roles#

• U1 Where USB data exists, the Boll is always the USB host (DFP) of the stack. On its foot receptacle it is a power sink and becomes host through a USB PD DR_Swap. The Boll never sources VBUS on its foot.
• U2 An active-USB module's top plug MUST be a Type-C Source with USB PD and MUST accept DR_Swap. Its bottom receptacle MUST be a Sink, presented downstream through a USB 2.0 hub port. (The Reference Bollard does this with an ST STM32G0B1, which has USB PD controllers for both ports, and a Microchip USB2422 hub.)
• U3 A passive module MUST wire VBUS, GND, CC1 to CC1, CC2 to CC2, D+ and D− straight through, MUST leave SBU and the SuperSpeed pairs unconnected, and MAY draw ≤ 100 mA from VBUS.
• U4 No module may present Rp or Rd on a pass-through CC line.
• U5 USB 2.0 High-Speed only. A passive D+/D− pair MUST be 90 Ω ± 15 % differential and ≤ 60 mm long.
• U6 The foot's USB-C is a real USB-C port and MUST behave like one. Nothing in the Bollard interface uses a USB-C connector for non-USB signals.

Notes for dock designers:

• If a partner refuses the Boll's DR_Swap, dock USB data stays off. Power, A-BUS and I2C still work.
• The foot USB-C sits behind the Boll's internal USB hub, so a computer plugged into the foot (directly, or through a pass-through like the Boll Cap) charges the Boll but gets no data link. Computers configure a Boll through its medallion port.

11. Analog audio bus#

• A1 A wire through every module. The top plug's tip, ring and sleeve MUST connect directly to the bottom jack's tip, ring and sleeve, so A-BUS passes through even an unpowered module. Modules tap the line (for example, a woofer puck sums left and right through 2 × 47 kΩ).
• A2 One driver. Only one module drives A-BUS: the Boll when present, or otherwise a stack host that declares abus_source. A processor module that breaks and re-drives the line (EQ, crossover) MUST bypass with a normally-closed switch when unpowered, and MUST declare abus_break.
• A3 Digital audio is optional. A module MAY expose USB Audio Class 2 behind an active-USB hub. bollardeck routes it (the audio message). No profile requires it.
• A4 The Boll's foot jack is its own output. The Boll's medallion 3.5 mm output and its foot A-BUS come from the same DAC. Their routing (foot only, medallion only, or both) is a Boll setting that a dock MAY request over bollardeck (dock messages).

12. Enumeration and identity#

12.1 How the Boll tells what docked#

Physical enumeration comes first and the bollardeck session second. A dock that answered the I2C or 1-Wire header and then opens bollardeck MUST send the same vid and pid in its hello (handshake). This lets the Boll tie the API session to a physical position in the stack.

12.2 Required hardware per enumerable module#

Every enumerable module carries a small microcontroller acting as an I2C target (example: WCH CH32V003; any ATtiny, RP2040 or STM32 works). It implements the register map of §12.4, reads CHAIN_IN, and drives CHAIN_OUT and ATTN_N.

Class-0 modules (a spacer, a pure battery, a riser) have no microcontroller and MAY tie CHAIN_IN to CHAIN_OUT. They are then invisible to the host, and MUST be Power Class L or a V_STACK source only.

12.3 CHAIN algorithm#

 host:  pull-ups on; CHAIN_OUT(host) = LOW; wait 10 ms; n = 0
 loop:
   host:   raise CHAIN_OUT (first module)        -- or the previous module raises its CHAIN_OUT
   module: sees CHAIN_IN HIGH -> answers at default address 0x2F within 50 ms
   host:   read 32-byte header @0x2F; write NEW_ADDR = 0x30 + n; write CMD = COMMIT
   module: moves to 0x30+n, releases ATTN_N, raises its CHAIN_OUT within 10 ms
   host:   n += 1; no ACK at 0x2F for 100 ms -> done (n modules, in stack order)
 host:  read JSON descriptors; configure; enable loads within the power budget

• Only a module whose CHAIN_IN is high and which has no address yet answers at 0x2F, so exactly one module answers at a time.
• The bus holds at most 15 enumerable modules (addresses 0x30–0x3E).
• The I2C general-call address 0x00 carries broadcast frames (§13.2).
• Hot-plug: a newly attached module holds ATTN_N low, and the host re-enumerates from the top (under 200 ms for 5 modules).

12.4 Register map#

The bit positions of the STATUS flags are not yet assigned (§22).

12.5 Binary header#

The header is little-endian. Its fields, in order:

Vendor and product IDs: open-hardware makers SHOULD take a VID/PID from the pid.codes open registry (VID 0x1209), so the same IDs work for USB, for this header and for the bollardeck hello.

12.6 Class bits#

Bits 12–14 are a minor addition for Bolltridges.

12.7 JSON descriptor#

Every enumerable Full-profile module also carries a JSON descriptor of at most 1,024 bytes, UTF-8, read through DESC_PTR and DESC_DATA.

{
  "bollard": "1.0",
  "profile": "full",
  "vendor": "Example Labs", "product": "Lux Puck",
  "class": ["light"],
  "od_mm": 135, "height_mm": 50, "mass_g": 280, "cog_mm": 22,
  "power": { "class": "S", "vstack_ma_avg": 350, "vstack_ma_peak": 900, "vbus_ma": 0 },
  "abus": { "tap": false, "break": false, "source": false },
  "usb": { "active": false, "bollardeck": false },
  "light": { "pixels": 24, "layout": "ring", "sync": ["frame", "beat"], "personas": 16 },
  "controls": [
    { "reg": 64, "name": "brightness", "type": "u8", "min": 0, "max": 255 },
    { "reg": 65, "name": "mode", "type": "enum", "values": ["follow", "beat", "static"] }
  ],
  "url": "https://example.org/lux-puck"
}

• The Boll's UI shows enumerated modules from these fields alone.
• A module of an unknown class still gets its declared controls, which point at its class or vendor registers.
• Hosts MUST ignore unknown fields.
• A Bolltridge adds a bolltridge object (§17.6).

12.8 Lite identity over 1-Wire#

A Lite dock has no I2C. Its identity is the same 32-byte binary header, followed by up to 96 bytes of short descriptor, served by a 1-Wire slave on pin 7 (L5). The Boll's 1-Wire master enables its 4.7 kΩ pull-up on pad 7 only after it has seen a Lite attach (V_AUX present).

13. SYNC and lighting#

13.1 SYNC line#

SYNC is driven push-pull by the stack host through a series 100 Ω resistor. Each module input is ≥ 10 kΩ and ≤ 20 pF.

Modules MUST tolerate an absent SYNC and free-run.

13.2 Colour frames#

The stack host MAY send I2C general-call (0x00) writes at up to 16 Hz: 0xC0, frame_no, 16 × (R, G, B), one colour per musician persona (the 16 channels of the Boll's lightshow). Light pucks latch each frame on the next SYNC tick. Docks that want the full 60 Hz, 24-pixel light ring use the bollardeck led message instead.

14. Docks without a Boll#

The Reference Bollard (§19) is a complete Bluetooth speaker in this state, and it is the stack host for pucks below it.

15. What the Pop Boll provides#

15.1 The foot#

The Boll's south pole is a rigid die-cast foot, the fixed female half of the interface. It floats on an elastomer isolation collar inside the ball, so it can move up to about 4 mm on impact, and the squishy outer ball is moulded around it.

The Boll's interior is sealed. The exposed foot contacts are designed to get wet and dry out, which is why every contact stays dead until attach.

15.2 The medallion#

The medallion is the Boll's front panel (the +Y direction of the interface). It has three concentric buttons (inner: play/pause, middle: online/upload, outer: power), a USB-C port and a 3.5 mm TRS headphone and line output.

Medallion accessories are USB devices on a cable, not Bollard devices, but they may speak the same bollardeck messages.

15.3 Size, mass and balance#

Use these figures when you compute the tip angle of a dock or stack with a Boll on top (§16).

16. Stacking#

        [ POP BOLL ]        female foot (the fixed half)
   ======|piston|======     Full male face: 3.5 mm + USB-C + BCR-10 on the floating plate
   |   SPEAKER DOCK    |    for example the Reference Bollard: stack host when no Boll is on top
   ======|  well  |=====    Full female face: pads in the well floor
   ======|piston|======
   |    LIGHT PUCK     |    taps nothing, passes everything through, lights on SYNC
   ======|  well  |=====
   |   BATTERY BASE    |    V_STACK source; sources VBUS up toward the Boll
   '-------------------'

• Order: Full-profile modules stack in any order. CHAIN tells the host the order.
• Depth: at most 5 modules plus the Boll above any base, and at most 15 enumerable modules on one I2C bus.
• Stability: the static tip angle of the whole stack with a Boll on top MUST be ≥ 12°. Every module MUST publish its mass and centre of gravity in its descriptor, so the host can check.
• Mini modules: the mass above a Mini (Ø 72) module MUST be ≤ 1.0 kg.
• Pass-through: pins 1–8 and 10, the 3.5 mm contacts and (for passive modules) USB-C are wired straight through. Pin 9 is point-to-point.
• Passive USB depth: at most 2 passive modules between a VBUS source and the Boll (P7).
• A-BUS taps: at most 6 tapping modules; only one driver (A2).
• Stack host: the Boll when present; otherwise the topmost host-capable module (§14). Only the stack host fits I2C pull-ups.
• Power budget: the host sums declared V_STACK loads and sources and switches off the lowest-priority loads first (P5).
• Lite docks are terminal: always at the bottom (L7).

17. Bolltridge device class#

A Bolltridge is a cartridge for the Pop Boll: a Bollard device whose job is computation. It docks like any Bollard device, and inside it is a small Linux computer running one approved cartridge image from a developer: a synthesizer, a sequencer, a soundfont pack, an audio-file player, an effect, a visualiser or a remixer. Bolltridges can be chained. Their messages are in bollardeck Part C; this chapter covers the hardware.

17.1 Definition#

A Bolltridge:

1. MUST present a male Bollard top face on the Full profile (as an active-USB module, U2) or on the USB-C profile. Lite and Passive carry no USB data, so they cannot carry a Bolltridge.
2. MUST enumerate to the Boll as a USB device on that face (the Boll is always the USB host, U1), with at least a CDC-ACM function whose interface string is bollardeck. It SHOULD add USB Audio Class 2 and MAY add USB-MIDI.
3. MUST run exactly one cartridge image, built on the published cartridge base image and signed after review (§17.11), unless its owner has turned on hacker mode on their own Boll.
4. MAY present a female Bollard bottom face (Full profile only), which makes it chainable (§17.9).

17.2 Geometry#

The only mandatory geometry is the male top face of §5.2, or the USB-C-profile pilot of C1.

• A terminal Bolltridge (no female bottom face) MAY be any shape: a tray, a wedge, a tower, a plush toy. It MUST still meet the rules that protect the ball: a static tip angle ≥ 12° with a Boll on top, lateral loads through the piston and well, and a published mass and centre of gravity.
• A chainable Bolltridge (with a female bottom face) MUST be a Full (Ø 135) or Mini (Ø 72) class module at least 50 mm tall (§5.1), so the stack above and below it stays stackable and stable.

17.3 Compute#

The cartridge computer must:

• run in USB device ("gadget") mode on a USB 2.0 port, because the Boll is the USB host. On Linux the functions are composed through configfs (libcomposite): CDC-ACM for bollardeck, UAC2 for audio both ways, and optionally USB-MIDI. A board whose only USB-C is power-only, or whose controller is host-only, needs an extra USB device chip.
• run arm64 containers: the cartridge base image is linux/arm64.
• offer I2S to a small DAC or codec if it wants the optional analog mix-through (§17.7).
• stay within its power profile (§17.4) and its heat budget inside a closed puck.

Images declare a compute tier: 1 for the Zero 2 W class, 2 for the Pi 4 and CM4 class, 3 for the Pi 5 and CM5 class. Soundfont packs larger than about 150 MB need tier 2.

17.4 Power#

The Boll never sources power on its foot (§9.4), so a Bolltridge on the foot powers itself, and charges the Boll. On either profile its top plug is a Type-C Source to the Boll (C2 or U2).

A cartridge adds about 0.4–0.8 W of its own (hub, supervisor microcontroller, DAC and summing amplifier, LED) to the board's draw. Typical totals at synthesizer load (estimates): Zero 2 W cartridge 2.1–2.7 W, peak 3.5 W; Pi 4 or CM4 cartridge 4.1–5.2 W, peak 7.2 W; Pi 5 or CM5 cartridge 4.6–6.7 W, peak 12 W or more. Only the Zero 2 W class fits the boll profile.

17.5 Brown-out behaviour#

A supervisor microcontroller watches the cartridge's input rail and owns the safe states, so a sagging supply never leaves the Boll's audio or the chain in a bad state. This table is normative.

The always-on rail (hub, supervisor, and the relay coil, which is off in bypass) is diode-ORed from the cartridge's own input, V_STACK and VBUS from below (P6). A boll-profile cartridge on the medallion that drops below 4.40 V for 1 s is switched off by the Boll, which tells the user why.

17.6 Enumeration flags#

A Bolltridge sets class bits 12 (bolltridge), 13 (power_boll, if it needs the medallion's 5 V) and 14 (abus_mix) in its binary header (§12.6), alongside the existing bits that apply: 1 abus_break (set with abus_mix), 3 vstack_source, 4 vstack_sink, 5 vbus_source_top (always set on the foot), 6 usb_active and 11 bollardeck. Its JSON descriptor adds a bolltridge object:

"bolltridge": {
  "spec": "0.1",
  "compute": {"board": "rpi-zero-2w", "tier": 1, "ram_mb": 512},
  "power": {"profile": "self", "avg_mw": 2600, "peak_mw": 3500,
            "vbus_source_ma": 1500, "vstack_source_ma": 0,
            "vstack_ma_avg": 0, "vstack_ma_peak": 0},
  "audio": {"usb": true, "abus_mix": true, "latency_ms": 14},
  "chain": {"female_bottom": true, "hub_ports": 1}
}

The same values come back in the bollardeck hello, and the Boll checks that they match, as it checks the vendor and product IDs.

17.7 Audio#

Decision (normative): every Bolltridge that makes sound MUST offer USB Audio to the Boll (UAC2, the audio_usb capability). A Bolltridge MAY also offer analog mix-through on A-BUS (abus_mix). The Boll selects one return path per cartridge and session, never both at once.

Rules for a mixing cartridge:

• Line level. It passes the Boll's signal at unity (0 dB ± 0.2 dB) and adds its own at a gain the Boll sets. With n mixing cartridges in a chain, each one's full-scale contribution is ≤ 1.0 / n Vrms, so the worst in-phase sum is 2.0 Vrms, the tap limit.
• Output stage. It MUST drive ≥ 2.2 Vrms into 10 kΩ with ≤ 100 Ω output impedance. Its input is ≥ 20 kΩ (it is a tap). Noise added per stage is ≤ −100 dBV, A-weighted.
• Bypass relay. A double-pole signal relay, normally closed = straight through on tip, ring and sleeve, so an unpowered, booting or crashed cartridge is a wire. The supervisor microcontroller drives the coil, not Linux.
• Mute on boot. The cartridge MUST boot with the relay in bypass and the DAC soft-muted, and leaves bypass only after the Boll enables it and selects the abus return.
• Click-free switching. It asks before switching the relay; the Boll ramps A-BUS down over 20 ms, answers, and ramps back up 30 ms later. A crash switches without the handshake and may click, which is acceptable.

17.8 Clock#

• The Boll is the musical clock. The song exists on the Boll as MIDI before it is heard, so the Boll is the transport master. It sends tempo, bar and beat messages over bollardeck, and on the Full profile the hardware SYNC line gives sub-millisecond beat edges (§13.1).
• The cartridge plays early, not late. The Boll streams song MIDI ahead of time by the cartridge's declared latency plus 20 ms, and the cartridge schedules each event so its sound lands on the Boll's beat. Live input (a keyboard plugged into a cartridge) cannot be sent ahead and is heard about 6–16 ms late (estimate), like any USB instrument.
• The sample clock is the USB host's. UAC2 runs on the Boll's USB frame timing. A cartridge's I2S DAC runs from its own crystal, so the base image resamples adaptively between the two and reports underruns in its health messages.

17.9 Chaining#

A chain is a Full-profile stack under one Boll in which one or more modules are Bolltridges. All the stacking rules of §16 apply.

   Pop Boll        USB root hub = tier 1, its internal hub = tier 2
      |            USB, CHAIN, SYNC, A-BUS
   Bolltridge A    CHAIN address 0x30; its hub = tier 3
      |
   Bolltridge B    0x31; tier 4
      |
   Bolltridge C    0x32; tier 5
      |
   Bolltridge D    0x33; tier 6, and its USB device sits at tier 7, the deepest USB 2.0 allows
      |
   speaker dock or powered base: V_STACK source (10-17 V, 4 A) for A-D, A-BUS listener,
   and the VBUS source that feeds power up toward the Boll

17.10 Software contract#

The cartridge base image provides:

• bollardeck client libraries for Python and C, which talk to a JSON-lines Unix socket that the system container proxies to the USB link. The proxy owns the identity, heartbeat and update messages, so image code cannot impersonate the system.
• Audio: PipeWire with its ALSA plugins. The USB audio function appears as a sink and source pair, the I2S DAC as an analog output, and an adaptive resampler bridges the two clocks.
• FluidSynth and the General MIDI soundfonts the Boll itself uses, so an instrument can sound like the Boll's own band out of the box.
• A sequencer runtime (bwx-seq) that follows the Boll's clock, gives 96 ticks per quarter note, schedules MIDI against the Boll's timestamps with latency compensation, and handles swing, pattern banks and transport changes.
• The USB gadget composition: CDC-ACM with the interface string bollardeck, UAC2 at 48 kHz with 2 channels each way (24-bit samples in 32-bit slots), and optionally USB-MIDI, using VID 0x1209 with the maker's pid.codes PID. On boards with a tight endpoint budget (the Zero 2 W) it drops USB-MIDI first (MIDI then travels in bollardeck messages), then the UAC2 capture direction.
• A watchdog: the SoC's hardware watchdog (15 s) plus a 1 Hz heartbeat to the supervisor microcontroller. 3 s of missed heartbeats switch the relay to bypass and notify the Boll; 20 s reset the computer.
• An image-update receiver that takes new images over the link, verifies their signatures, installs them into the spare slot, switches at a song boundary and rolls back if the new image misses its first three heartbeats.

The cartridge manifest (cartridge.yaml) and the full message set are in bollardeck Part C.

17.11 Signing and hacker mode#

• Signed images. Cartridge images are reviewed and signed before they are distributed (the planned process is in bollardeck distribution). The Boll verifies the signature offline against the public keys it carries, and the cartridge verifies it again before loading.
• The Boll refuses unsigned images. A cartridge whose image has no valid signature gets the unsigned_image error, only the state grant, and no enable, no audio routing and no voice takeover.
• Hacker mode lifts that on one Boll, for its owner, so a developer can build and test on their own Boll before publishing:
  • Turn it on in the Boll's local web UI (Settings, Developer, Hacker mode), then confirm on the Boll itself within 30 s by holding the middle and outer buttons for 5 s. It cannot be set over bollardeck, BLE, the storefront or a routine.
  • While it is on, unsigned cartridges are enabled and labelled "unsigned" in the UI, and one light-ring LED stays amber. Every other rule still holds: corpus rules, the stems and audio-in consents, the power budget, and no corpus files or credentials to any cartridge.
  • It turns off in the same UI, on a factory reset, or by itself after 30 days, when the Boll asks again.
  • Unsigned images are never distributed through the storefront.
• Bundled content. Images MAY bundle soundfonts, samples and audio files under licences that permit redistribution. They MUST NOT bundle anything extracted from a corpus.

17.12 Reference design: the Dev Puck#

The Bolltridge Dev Puck is the reference cartridge. It is specified but not built.

• Form: a Ø 135 × 50 mm Full-class puck, chainable. A 35 mm Dev Tray is the terminal variant: the same top face and board, no female bottom face, and any outline (a Ø 135 tray or a 100 × 140 mm slab).
• Top face (male, Full): the piston, with the floating plate carrying a 3.5 mm TRS plug (example: Same Sky SP-3533-02 on a 90° daughterboard), a vertical USB-C plug (example: JAE DX07P024MJ2R1500) and the BCR-10 strip (example: Mill-Max 823-22-010-10-040101); 4 magnets N up.
• Bottom face (female): a vertical USB-C receptacle (example: GCT USB4225-03-1000-C), a 3.5 mm jack (example: Same Sky SJ1-43502PM), a gold pad strip in the well floor, 4 magnets S down, and the Ø 1.5 mm well drain.
• Rear: a USB-C power input (PD sink, 5 V / 3 A or 15 V / 3 A), a 3.5 mm monitor jack fed from the DAC, an RGB status LED, a recessed recovery button, and a microSD slot (Zero 2 W build).
• Compute: a Raspberry Pi Zero 2 W on the carrier (soldered by its castellated pads, or socketed for the dev build), or a Compute Module 4 on two board-to-board connectors (the "Dev Puck CM4").

  DEV PUCK BLOCK DIAGRAM

  top USB-C plug (to the Boll)
     |
     +-- STM32G0B1 supervisor: USB PD on both faces (top Source that accepts DR_Swap,
     |   bottom Sink), Bollard I2C target at 0x2F, CHAIN, ATTN_N, SYNC capture,
     |   relay drive, computer reset, heartbeat
     |
     +-- USB2422 2-port hub --+-- port 1 --> Pi Zero 2 W or CM4: USB gadget CDC + UAC2 (+ MIDI)
                              |
                              +-- port 2 --> bottom USB-C receptacle (to the next device)

  computer --I2S--> PCM5102A DAC --> OPA1678 summer (Boll's A-BUS at unity + cartridge)
  top 3.5 mm plug (A-BUS in) --+--> summer --> DPDT relay, normally closed = bypass
                               +------------------------> relay --> bottom 3.5 mm jack

  rear USB-C PD input (CH224K) --> TPS56637 5 V / 6 A buck --+--> computer
                                                             +--> TPS2595 eFuse --> top VBUS
                                                                  to the Boll (Rp 1.5 or 3.0 A)
  always-on 3.3 V rail (diode-OR of the input, V_STACK and VBUS from below) --> supervisor, hub

The supervisor is one STM32G0B1 (the same part the Reference Bollard uses for USB PD), doing USB PD on both faces, the Bollard I2C target and CHAIN, the watchdog and the relay. V_STACK sourcing from a 15 V input (an LM74700 ideal diode and an eFuse) is laid out but not populated by default.

Notes for a 3D-printed enclosure:

• Print in PETG or ASA; PLA creeps above 50 °C. Make the piston and its guide in POM or PETG with 0.25 mm clearance.
• Use 2.4 mm walls. Print the Ø 135.0 outside 0.2 mm oversize and sand it to the ±0.3 mm of M1.
• Print the well upright so the Ø 42.0 +0.10/0 bore comes out round, then ream it to size.
• Magnet pockets 6.2 × 3.1 mm, press-fit with a drop of cyanoacrylate. Print an N/S polarity legend (N up on top, S down on the bottom).
• Press the SoC against an aluminium top plate with a 1.5 mm gap pad. A Zero 2 W at 2.5 W stays below about 60 °C (estimate); a CM4 at 5 W needs the plate and 8 vent slots in the lower wall. Put no vents on top: the Boll sits there.

Schematics, layouts, mechanical models and print profiles will be published under the licence of §24.

18. The Boll Cap#

Every Pop Boll ships with the Boll Cap fitted to its foot. It is the simplest Bollard device there is, and the zero-feature reference: a Passive-profile pass-through with no chip, no power of its own, no identity and no pins.

• Protection: it fills the well, so lint, crumbs and coins stay out.
• Cables from the side: a USB-C cable and a 3.5 mm cable plug into its rear wall, so the Boll stays upright instead of balancing on a plug.
• A flat stand: the Boll's Ø 70 mm flat sits on the cap's deck, and the cap's Ø 80 mm base sits on the table.
• The upgrade path: pull it off and put any Bollard device on the same foot.

18.1 Electrical#

• No Rp, Rd or Ra anywhere in the cap (U4). Whatever is plugged into the side is the Boll's USB-C partner directly, so the Boll's role rules apply unchanged.
• D+/D−: a 90 Ω ± 15 % pair, ≤ 45 mm from plug to receptacle (the limit is 60 mm, U5).
• VBUS and GND: ≤ 0.10 Ω round trip at 3 A (P7), using both VBUS and both GND pins of each connector.
• ESD: ±8 kV contact on every exposed contact (example: a TPD4E05U06 on CC1, CC2, D+ and D− at the side receptacle, and two 5 V bidirectional TVS diodes on tip and ring at the side jack).
• Orientation: the key fixes the cap's rotation, so its plug's CC contact always lands on the Boll's CC1. The side receptacle is reversible as usual, and the Boll detects the cable's orientation as on any port.
• Naming: a receptacle-to-plug pass-through like this is not a USB-C cable extension under the USB-C specification. It MUST NOT be sold or described as a "USB-C extension" and MUST NOT carry a USB-IF logo. Describe it as a Bollard Passive device.
• No ID, by design. An ID would need pins and would need the Boll to probe pad 7 before anything attached, which breaks the dead-until-attach rule (B4). With an empty side, the Boll reports nothing attached; with a cable in the side, it reports the partner. The cap's floor under the pad row is left flat and empty, 0.5 mm below the pads, so a later cap could add pins.

18.2 What works from the side ports#

Charge-only USB cables charge the Boll with no data. USB 3.x, USB4 and 5 A e-marked cables work as USB 2.0 at 3 A. USB-A-to-C cables, which are always live, charge at the Default USB rate.

18.3 Mechanical#

18.4 Conformance#

The cap claims the Passive subset (§21.4): M2 face fit on the reference foot gauge; M4 insertion ≤ 40 N and extraction ≤ 22 N, or the manual says "hold the cap to lift the Boll off"; M5 50 lateral knock-offs with no plug damage; M6 5,000 cycles; E5 ESD; E6 A-BUS straight through; power rule P1 (it has no source); Passive P3 (the side partner is the source); U1 straight through.

19. Reference Bollard#

The Reference Bollard is the worked example of the Full profile: an open reference design that anyone may build and sell, under any name and at any price (under the proposed licence of §24), with no certification. It has not been built.

19.1 Overview#

• A Ø 135 × 300 mm extruded-aluminium tube that is a complete Bluetooth speaker on its own, and the dock for the Boll.
• A male Full face on top and a female Full face on the bottom, so pucks stack above or below it.
• Two 3.5-inch full-range drivers firing front and back, and two passive radiators firing left and right, in force-cancelling pairs, in a 2.2 L chamber.
• A DSP amplifier at about 20 W per channel, running straight off a 4S 72 Wh battery pack.
• A docked Boll feeds it over A-BUS and is charged over USB-C at 5 V / 3 A.
• Halo LEDs under a diffuser ring at the top edge glow in time with the Boll over SYNC.

        [ POP BOLL ]        female foot (the fixed half)
   ======|piston|======     Full male face: 3.5 mm + USB-C + BCR-10 on the floating plate
   | REFERENCE BOLLARD |    Ø 135 × 300 mm, Bluetooth speaker, 72 Wh, halo on SYNC
   ======|  well  |=====    Full female face: pads in the well floor
        [  PUCK  ]          for example a woofer or battery puck

19.2 Block diagram#

  AUDIO PATH
    top 3.5 mm plug (A-BUS in) ---+-----------------------------> bottom 3.5 mm jack
                                  |                               (wired straight through, A1)
                                  v
                            PCM1808 ADC ----I2S---> +------------+
                                                    | I2S 2:1    |---> TAS5825M amp and DSP
           Bluetooth module (QCC3034 class) --I2S-> | bus switch |           |
                                                    +------------+           v
                                                           2 x 3.5" drivers + 2 radiators
  USB AND CONTROL
    top USB-C plug (the Boll is host) <--> USB2422 hub <--> bottom USB-C receptacle
                                               |
                                               +--> STM32G0B1 (firmware update, status)
    STM32G0B1: USB PD on both USB-C ports, Bollard stack host or target, buttons, halo LEDs,
               I2C to the amplifier, the charger and the Bluetooth module
    top pins 1-8 and 10 <------ wired straight through ------> bottom pads 1-8 and 10
    top pin 9 (CHAIN_IN) --> STM32G0B1 --> bottom pad 9 (CHAIN_OUT)

  POWER PATH
    rear USB-C (charge only) --> TPS25750 PD sink --+
    bottom USB-C VBUS (from a puck below) ----------+--> TPS2121 input mux --> BQ25792 charger
                                                                                     |
                                    4S 72 Wh pack with BQ76905 protector <-----------+
                                       |
            +--------------------------+------------------------------+
            v                          v                              v
     amplifier rail (direct)   TPS62933 5.1 V buck --> TPS2595   LM74700 ideal diode
                               eFuse --> top VBUS to the Boll    --> V_STACK (pins 1-2)

The docked Boll's audio arrives analog on purpose: the A-BUS input costs one ADC, works through unpowered pucks, works with any phone or player on a 3.5 mm adapter, and does not depend on the Boll's software. USB data is still carried for control, for firmware updates from the Boll, and for USB devices further down the stack.

19.3 Behaviour#

19.4 Parts list#

Example parts, as designed. Any equivalent part is fine.

The rear USB-C port is charge-only (USB PD sink at 5, 9, 15 or 20 V, up to 45 W).

19.5 Stability#

Estimates, with the TPE foot rim as the contact ring (radius 64 mm):

A Reference Bollard supports at most 5 full-size pucks above it. The 350 g ballast ring in its base is the cheapest stability lever (about +0.8° per 100 g). Its weight (about 27 N) is above the estimated Boll extraction force (about 3–22 N), so lifting a Boll off leaves the speaker on the table.

20. Hobbyist builds#

20.1 Lux Puck (Full, 50 mm)#

The smallest thing that is a real Full-profile module is a 24-LED light puck. It passes everything through and lights on SYNC.

1. Top face: a vertical USB-C plug (example: JAE DX07P024MJ2R1500), a 3.5 mm plug (example: Same Sky SP-3533-02 on a 90° daughterboard; there is no off-the-shelf vertical PCB-mount 3.5 mm plug), and one 1×10 2.54 mm spring-pin strip (example: Mill-Max 823-22-010-10-040101, or a generic strip). All three go on a small plate PCB that floats on 3 printed flexures. Add 4 magnets N up and a printed piston and spring (PETG or POM is fine for hobby use).
2. Bottom face: a vertical USB-C receptacle (example: GCT USB4225-03-1000-C) and a 3.5 mm jack (example: Same Sky SJ1-43502PM), panel-mounted in the well. The pads are a pad-strip PCB (ENIG for hobby use, hard gold for products). Add 4 magnets S down.
3. Pass-through: USB-C VBUS, GND, CC1, CC2, D+ and D− straight through (a short 90 Ω pair); 3.5 mm tip, ring and sleeve straight through; pins 1–8 and 10 straight through (pins 1–4 on traces at least 2 mm wide in 2 oz copper).
4. Logic power: V_STACK into a buck converter (example: TI TPS62933) to 5 V for the LEDs, then an LDO to 3.3 V. A Schottky diode from VBUS feeds the 5 V node, so the puck enumerates on VBUS alone (with the LEDs limited to 100 mA).
5. Microcontroller: a WCH CH32V003F4U6 as I2C target (no pull-ups), with CHAIN_IN on a GPIO with a 100 kΩ pull-down, CHAIN_OUT push-pull starting low, ATTN_N open-drain, and SYNC on a timer capture input.
6. Load: 24 × SK6805-EC15 LEDs on a ring behind a diffuser, switched by a P-FET that the microcontroller turns on after the POWER_ON command.
7. Protection: a TPD4E05U06 on pins 5–9, an SMBJ18A TVS on V_STACK, and a 1 A polyfuse.

Its JSON descriptor is the example in §12.7.

20.2 The perfboard route#

For a first light puck (not a product): the BCR-10 pitch is 0.1 inch, so the spring strip solders straight into 2.54 mm perfboard. The pad strip can be any 2.54 mm-pitch board with pads at least 1.6 mm wide. Generic strips are not rated for 5,000 cycles.

Indicative single-unit hobby costs, November 2026: a generic 2.54 mm spring-pin strip about $1–3, a Mill-Max 10-position strip about $7. A whole Lux Puck with generic strips and printed parts comes to roughly $22–28; with the Mill-Max strip and ordered PCBs, roughly $28–36. These are indicative only.

20.3 The Lite minimum#

A charging-and-light stand needs a printed boss, 4 spring pins (positions 3, 7, 8 and 10 of a 1×10 strip with 6 pins pulled), a 5 V USB-C receptacle on its back for its own power, an eFuse, a Hall sensor, a CH32V003 acting as 1-Wire slave and SYNC reader, and a ring of LEDs. That is roughly $10–15 as a hobby build (indicative).

21. Conformance checklist#

There is no certification. A maker who says "Bollard v1.0, Full profile" (or Lite, USB-C or Passive) states that every applicable item below passes. Test fixtures will be published with v1.0 final: a reference Boll-foot gauge (female) and a reference dock-top gauge (male, Full).

21.1 Mechanical#

21.2 Electrical and power#

21.3 USB and protocol#

21.4 Profile subsets#

21.5 Bolltridge items#

A maker who says "Bolltridge v0.1" states that these pass, on top of the Bollard checklist for its profile.

21.6 Listing (planned)#

A future storefront will list docks, pucks and cartridges. Listing is planned to be free, with no testing by the storefront (each listing will say so). To be listed, a maker gives:

1. the specification version (for example "Bollard v1.0") and the profile, plus the Bolltridge version for cartridges;
2. whether the product speaks bollardeck (USB, BLE or both, and which API major);
3. a photo of the product with a Pop Boll docked;
4. a safety self-declaration: which regulations the maker states the product meets (for example FCC and CE EMC, IEC 62368-1 for mains products, UN 38.3 and IEC 62133-2 for lithium-ion cells), with a name, a contact and a product URL.

A listing can be removed after credible safety complaints.

22. Open items#

Not yet validated on hardware. Nothing in this specification has been built, so every item below is open until an engineering sample exists.

• BCR-10 has no physical sample. The 0.7 mm compression, the ±0.2 mm registration through the plugs, and whether the force of 10 pins (up to 10 N) can tilt the plate against the piston all need a prototype build.
• Clearance under the well floor between the pad row (y = −11.0) and the bodies of the 3.5 mm jack and the USB-C receptacle has been checked against nominal outlines only, not against the vendors' 3D models.
• The example spring-pin strip has not been checked against the 1.2 mm stroke and 0.4–1.0 N requirement; a different series may be the right part.
• The well's lead-in cone is defined by its two diameters and heights (Ø 50.0 at −3.0, Ø 42.0 at +3.0). An earlier draft also quoted a 21.8° half-angle, which does not match those figures; the angle is under review.
• The binary header lists fields that fill 31 of its 32 bytes; the position of the remaining byte, the CRC-16 variant and the bytes it covers are not yet specified. height_mm and cog_mm are single bytes, so modules taller than 255 mm (such as the 300 mm Reference Bollard) cannot yet declare their height. The STATUS register's bit positions are not assigned.
• Unknown class bits: the rule that hosts ignore unknown JSON fields does not yet say the same for unknown class bits, which the Bolltridge bits 12–14 rely on.
• Module height H does not yet name its reference planes (rim plane or Datum A, top and bottom).
• Enumeration above a non-Boll host is not possible in v1.0 (§14).
• The Boll Cap's detailed drawings are being redrawn to the corrected datum of §4. The cap is the easiest part to adjust and will be tooled last. Its extraction force (two friction plugs, weak steel-disc retention) may exceed the Boll's weight, so the cap could lift with the Boll; that will be measured.
• The Reference Bollard acoustic figures are estimates from assumed driver parameters, and the amplifier's thermal path to the tube has not been checked.
• Bolltridge compute: UAC2 + CDC + MIDI gadget composites are not verified on the Uno Q, the Radxa Zero 3W or the CM5; the Zero 2 W's endpoint budget for all three functions at once is not verified; UAC2 feedback-endpoint support varies by board kernel; all load, latency, SYNC-edge and thermal figures are estimates; one supervisor microcontroller doing USB PD on two ports plus the Bollard target and watchdog duties is not yet proven.
• No hardware attestation for cartridges in this version. A counterfeit cartridge could replay a valid identity, but it gains nothing: the Boll gives cartridges no files, tokens or credentials, and stems only with the user's consent.
• To be published with v1.0 final: the reference gauges, the reference pad-strip layout, and the Reference Bollard and Dev Puck design files.

23. Versioning and change log#

• The binary header carries spec_major and spec_minor, and the JSON descriptor carries "bollard": "1.0".
• Minor versions only add registers, classes, profiles or JSON fields. Hosts MUST ignore unknown fields.
• Major versions are for any mechanical change or any change to an assigned pin. Each major version gets a new header magic.
• The bollardeck API is versioned independently (bollardeck/1). A Bollard v1.0 dock speaks bollardeck/1.
• Candidates for v1.1: upward enumeration above a non-Boll host, the Thin class with a coaxial pass-through, V_STACK battery-charging rules, the published gauges and the reference pad-strip layout.

Nothing was built to 0.1 or 0.2, so no adapters are planned.

24. Licence#

Proposed, and not yet final:

• Hardware designs (the Reference Bollard and Lux Puck designs, the reference pad strip, the gauges and the mechanical drawings): CERN-OHL-P v2, a permissive licence, so anyone can build and sell closed commercial docks.
• Firmware and code (the puck microcontroller reference, bollardeck client libraries, the example routines): Apache-2.0, which includes an explicit patent grant.
• This specification text: CC BY 4.0.

These licences cover the documents and designs, not the project's names and logos. You may describe a product as "built to the Bollard Physical Specification v1.0, Full profile" (or whichever profile applies).