Picatinny CLIK v3.0 — Payload Serial Control Protocol

A manufacturer-neutral description of the CLIK v3.0 serial control interface between a host/integrator (carrier platform, fire-control system) and a CLIK-compatible payload module. It covers the electrical interface, frame format, message set, function-state model, timing, and status indication.

Values that a payload vendor assigns per program build are marked [vendor]; behaviour the base interface leaves to the integration profile is marked [profile] and summarised in §12. Nothing here identifies a specific manufacturer or part number.

1. Overview

The module is a command server: it transmits only in response to a received command frame and never sends unsolicited traffic. A host reads the module’s status/identity, activates it, and drives it through a safety state machine gated by two hardware discretes plus serial commands.

                        RS-232 serial (CLIK v3.0)
  Host / Fire-Control ── SAFETY ENABLE  (discrete) ──►  CLIK Payload ── Firing/actuation output ──►
  System              ── SAFETY EXECUTE (discrete) ──►  Module        ── Status indicator (RGB) ──►
  DC Power ────────────── V+ / Return ───────────────►

2. Physical & electrical interface

2.1 Serial link

Signal names are from the module’s perspective: RS-232 Rx is driven by the host, Tx is driven by the module.

2.2 Power

2.3 Safety discretes

Two isolated discrete inputs form the hardware side of a two-key interlock:

Both discretes share a dedicated isolated return. Arming and the terminal action each require the serial command and the matching discrete — neither alone advances the state (§8).

2.4 Connector (9-19 insert)

The module mates through a single Picatinny CLIK payload connector (micro-miniature dual-start, “Mighty Mouse” class; receptacle; shell 9-19; size #23 male contacts; keying Configuration A). Pins used by a given module are marked in its wiring drawing; unused/reserved pins shall not be repurposed.

3. Frame format

Every message (command and response) uses one frame. All multi-byte fields are big-endian.

+-----+-----+----------+----------+--------+-----+----------+-----------+
| AA  | 55  | MsgID hi | MsgID lo | Sync   | Len | Data...  | CRC16 be  |
+-----+-----+----------+----------+--------+-----+----------+-----------+
  0     1      2          3         4       5     6..6+N     6+N, 7+N

• CRC-16/CCITT-FALSE: polynomial 0x1021, init 0xFFFF, no reflection, no final XOR. Check value for ASCII "123456789" is 0x29B1.
• Total frame size is 8 + N bytes.

Framing rules

• After a valid 0xAA 0x55 header the module waits up to 500 ms for the rest of the frame, then discards the buffer and resynchronises on the next header.
• Frames that fail the CRC are ignored — the module does not reply to a frame it cannot trust (msg_id/sync are unverifiable on a corrupt frame). A Bad checksum result code exists for host-side decode but is not transmitted by the module. [profile]

4. Message set

4.1 Standard messages

A GET response returns a multi-byte data structure. A command/SET response returns a single data byte (a result code, §7); this is how a host distinguishes a data response from a result code.

4.2 Application (vendor) command range

Message IDs 0x8000–0xFFFF are reserved for payload-specific commands. A safety payload typically defines a three-command guard group; the IDs and guard payloads below are an [vendor] example assignment, not part of the base interface:

5. Command payloads

5.1 SetFunctionState (0x0004)

Data: [channel, state]. channel = 1 (single-function modules). state: 0x00 = De-Activate, 0x01 = Activate. Wrong length → 0x03; unknown channel or state value → 0x04.

5.2 Guard-word safety commands

Each application safety command carries a fixed guard payload (a vendor-defined constant that must match exactly) to reduce the chance of an accidental or corrupted command being acted on. The guard word is typically 4 bytes [vendor]. Wrong length → 0x03; correct length with a mismatched guard → 0x04.

“Concurrent discrete” means the serial command must arrive within the discrete-to-serial window (§9) after the corresponding discrete’s rising edge.

6. GET responses

Each success response echoes the request’s Msg ID and Sync, sets Data[0] = 0x00, and appends:

6.1 GetPayloadStatus (0x0000)

Status bits: bit0 Health (1 = OK), bit1 SAFETY ENABLE level, bit2 SAFETY EXECUTE level, bit3 Functions Available, bit4 Functions Activated, bit5 Functions Armed.

6.2 GetPayloadIdentifier (0x0001)

uid:u16-BE, then a null-terminated ASCII identifier string [vendor], then a null-terminated ASCII version string. Identifier ≤32 chars, version ≤16 chars.

6.3 GetPayloadSystemConfig (0x0002)

max_power_cpu:u8 (units of 250 mA @ 28 V), max_weight:u16-BE (0.1 lb units), monitors_discretes:u8 (boolean — whether the module enforces the safety discretes). These are fixed device properties; there is no Set* counterpart. A host uses them as a pre-flight compatibility check (bay power budget, mass/CG update, interlock enforcement).

6.4 GetFunctionStateIdentifiers (0x0003)

The supported state IDs and their names. Byte layout is [profile]; a common encoding is count:u8, then per state {id:u8, name ASCII, 0x00}.

7. Result codes

A rejected message returns exactly one data byte:

A 0x00 result confirms acceptance; a host should always confirm the resulting state with GetPayloadStatus.

8. Function-state model

State IDs are sparse — 4 and 5 are unassigned in v3.0:

        (power on)
            │
            ▼  power-on delay elapsed
       Unavailable ───────────────────► NotActivated
            ▲  idle lockout                 │ ▲
            │  ┌─────────────────────────────┘ │ SetFunctionState(De-Activate)
            │  │ SetFunctionState(Activate)     │
            │  ▼                                │
            └ Activated ◄─────────────────────┘
              │  ▲ ▲
   ENABLE+Arm │  │ └ Disarm / ENABLE released / armed-inactivity timeout
   (in window)│  │
              ▼  │
            Armed │
              │   │ Disarm
 EXECUTE+Fire │   │
 (in window)  ▼   │
            Firing ┘   (Firing exits only via Disarm — not on a discrete drop)

Key rules:

• Edge-triggered arm/execute. Arm requires Activated + SAFETY ENABLE asserted within the discrete-to-serial window of its rising edge; Fire/execute requires Armed + SAFETY EXECUTE the same way. Missing the window → 0x80.
• ENABLE release while Armed demotes to Activated. Firing is not exited by a discrete drop — only Disarm.
• Disarm returns Armed or Firing to Activated.
• Two-key principle: arm and execute each need both the serial command and the matching physical discrete.

If the module reports monitors_discretes = false, it does not enforce the discretes and the serial commands alone drive the states (a bench/test posture; a safety regression for field use).

9. Timing

Timer reset behaviour is [profile]: a common resolution is that the armed-inactivity timer resets on any valid frame (status polls keep it alive) while the idle-lockout timer resets only on actual state transitions.

10. Status indicator

The module drives an RGB indicator:

Modules with only a two-colour indicator approximate the two “blue” states with a distinct pattern (e.g. alternating colours for power-on delay, both solid for fault/lockout). [profile]

11. Integration sequence

1. Apply power. Poll GetPayloadStatus until state = Not Activated (2) — this covers the power-on delay.
2. Discover. GetPayloadIdentifier and GetPayloadSystemConfig; verify identity, bay power budget, mass/CG, and that discretes are monitored.
3. Activate. SetFunctionState(Activate) → Activated (3).
4. Arm. Assert SAFETY ENABLE, then send Arm within the window → Armed (6). Keep SAFETY ENABLE asserted while armed.
5. Execute. With SAFETY ENABLE still asserted, assert SAFETY EXECUTE, then send Fire within the window → Firing (7).
6. Safe / abort. Disarm (→ Activated), or de-assert the discretes; SetFunctionState(De-Activate) to return to Not Activated.

Host invariants:

• Drive the discrete GPIO and the serial command from the same task so the 50 ms window is met.
• Loss of comms does not auto-disarm; the safest abort is to drop the discrete (hardware-authoritative) then Disarm when comms return.
• Status polling is the only liveness signal — the module is server-only.

12. Points requiring profile agreement

The base v3.0 interface leaves several behaviours to the integration profile / vendor. The items marked [profile] above, collected:

1. Whether the module ever transmits 0x01 or silently drops all malformed frames.
2. Exact use of 0x80 vs 0x81, and the retry contract for each.
3. Whether a successful arm/execute consumes its discrete edge (so a held-high discrete needs a fresh drop-and-raise to re-arm).
4. Timer reset semantics (armed-inactivity vs idle-lockout).
5. State/command legality matrix at the edges (arm-while-armed, disarm-from-other-states, deactivate-while-armed).
6. Whether Disarm from Firing de-energises the actuation output, and whether that output latches.
7. Byte layout of the GetFunctionStateIdentifiers (0x0003) response.
8. Entry conditions for the Faulted state.
9. Two-colour indicator substitution for the RGB “blue” states.

Vendor-assigned values ([vendor]): identifier/version strings, UID, MPC/MPW, and the application (0x8000–0xFFFF) command IDs and guard payloads.