Sartorius xBPI Protocol — Reverse-Engineered Reference¶

A reference to the Sartorius xBPI binary protocol, reverse engineered across three balances spanning Sartorius's product line:

All three families ship from the factory in SBI mode; switching to xBPI requires a front-panel menu change on each unit. The "xBPI default" column above is the framing the unit uses once it has been switched to xBPI — not the protocol it runs out of the box.

Cross-referenced with the publicly available WZG OEM weigh-cell manual, which documents a partial command list for a related OEM cell family. Many commands overlap across all three balances, but the Cubis has expanded the protocol — most notably by requiring TLV-wrapped arguments where WZG shows plain byte arguments.

Where protocol features are uniform across all three balances, they are presented as the xBPI baseline. Where they differ, the text calls out which balance family behaves how. §14 consolidates the cross-family differences in one place.

To the best of our knowledge, this is the first open-source reverse engineering of xBPI. Every "Sartorius driver" on GitHub/PyPI implements the ASCII SBI protocol, not the binary xBPI documented here.

Confidence legend¶

• [SURE] — verified by live captures AND/OR matching the WZG manual.
• [LIKELY] — strongly supported by evidence but not bulletproof.
• [GUESS] — plausible interpretation, not yet validated.
• [UNKNOWN] — observed but meaning not understood.

1. What is xBPI?¶

Sartorius balances speak three documented protocols:

xBPI is the modern binary protocol used by Cubis MSE, Secura, Quintix (when set to binary mode), and OEM weigh cells. It is not publicly documented by Sartorius. Sartorius sells a paid OPC server product whose entire purpose is to bridge xBPI; that product exists because the protocol is closed.

2. Physical and link layer¶

2.1 Serial parameters¶

8-O-1 framing is universal across all three balances. The WZG manual claims "7-bit ASCII" for xBPI, which is wrong — captured frames contain bytes like 0x88, 0xBB that cannot fit in 7 bits. Use 8-O-1.

The PC-USB port is parity-forgiving on receive — the balance accepts requests at any parity regardless of its menu-configured parity, so the "PC-USB parity" menu setting only affects TX from the balance.

All three families ship from the factory in SBI mode and require a front-panel menu change to switch to xBPI. WZA's SBI default is autoprint at 1200-7-O-1 (+ 0.00 g \r\n); MSE and BCE default to SBI command/reply at their respective baud rates with no autoprint enabled.

MSE has two physical ports with separate protocol configuration: the 9-pin SUB-D peripheral port and the USB-B "PC-USB" port. The peripheral port's protocol is settable via xBPI parameter p35 (see §10) — write + 0x47 SAVE_MENU + cold boot to apply. The PC-USB port's protocol is NOT exposed via the xBPI parameter table (indices 0-79 swept empirically 2026-04-25; only the front-panel Device → PC-USB → Dat.Rec. menu can flip it). Consequence: the package's Balance.configure_protocol(...) is host-side only on PC-USB — it cannot rewrite the wire's protocol; the user must flip the front-panel menu first. On the peripheral port, by contrast, the package can both read and re-program p35.

2.2 SBN addressing¶

xBPI supports RS-485 multidrop with a Sartorius Bus Node (SBN) address. On a point-to-point RS-232 link, both host and balance still include their SBN in every host-to-balance frame:

• Host SBN = 0x01 (by convention)
• Balance SBN = set via opcode 0x72 (write) / read via 0x71
• Our MSE1203S reports 0x00 [SURE]
• The balance accepts dst_sbn = 0x09 (its factory default) and responds regardless of its own SBN when directly connected. [LIKELY]

3. Frame format¶

3.1 Host → balance (TX)¶

  [len] [src_sbn=01] [dst_sbn=09] [opcode] [args...] [chk]
  \____/                                              \___/
  = bytes-after-len-byte (incl. chk)            = sum(all-prev-bytes) & 0xFF

• len = count of bytes that follow the length byte (i.e. len + 1 = total frame size). [SURE]
• chk = sum(bytes_0..N-1) & 0xFF where N is the last index. [SURE]
• Default SBNs: src=0x01, dst=0x09. [SURE]

3.2 Balance → host (RX)¶

  [len] [marker=0x41] [subtype] [body...] [chk]

• marker is always 0x41. [SURE]
• subtype classifies the payload shape (see §4). [SURE]
• chk = same formula as TX. [SURE]

3.3 Worked examples¶

Read SBN:              04 01 09 71 7f          len=4, op=0x71, chk=0x7F
Reply (subtype 0x21):  04 41 21 00 66          len=4, subtype=0x21, body=00

Read net weight:       04 01 09 1e 2c
Reply (measurement):   0b 41 48 bb a3 d7 0a 3d 30 82 45 55
                        len=11, subtype=0x48, 8-byte measurement body, chk=0x55

4. Response subtype encoding¶

The subtype byte (byte[2] of a device reply) follows a type-length convention:

  high nibble = type class
  low nibble  = body length (for types 0..4); for type 5, length = 16 + low

5. TLV argument/value encoding¶

Where the WZG manual documents an opcode taking a plain single-byte arg, the Cubis MSE requires the arg wrapped as a Type-Length-Value (TLV) record:

  <opcode>  [tag]  [value bytes...]

The TLV tag encodes the value's size in its low nibble:

5.1 Worked examples¶

WZG form:         0x0C 00        "Read max, area 0"  — ERRORS on Cubis
Cubis form:       0x0C 21 00     "Read max, area 0"  — returns 1200.0 g ✓

WZG form:         0x1E 01        "Read net weight, 10× resolution"  — ERRORS
Cubis form:       0x1E 21 01     "Read net weight, 10× resolution"  — works

5.2 Multi-TLV responses¶

Response bodies may contain multiple TLVs concatenated. Example — 0x55 (read parameter table) at index 0:

TX:  06 01 09 55 21 00 86
RX:  06 41 21 02 21 04 8f
     └─┘ ├──┘ ├──────┐├──┐└─┘
     len mkr  (byte [2] is
              subtype 0x21, also
              the first TLV's tag)
              └─ TLV1: 0x21 0x02 ─┘└─ TLV2: 0x21 0x04 ─┘

So the parameter-table entry at idx 0 has (current=0x02, max=0x04).

5.3 parse_tlv_sequence helper¶

The Python helper sartoriustesting.protocol.parse_tlv_sequence(body) walks a bytes object and yields (tag, value_bytes) tuples. To parse a multi-TLV response body like above, prepend the subtype byte:

f = parse_frame(raw)
tlvs = parse_tlv_sequence(bytes([f.subtype]) + f.body)

6. Error codes¶

When the balance returns subtype 0x01, the single body byte is an error code:

The distinction between 0x04 (no such command) and 0x07 (bad args) is useful for discovery — it identifies opcodes that EXIST but need the right arg form. All codes above are reported identically across MSE, WZA, and BCE (except 0x11, observed only on BCE).

7. Opcode reference¶

Opcode inventory for the Cubis MSE1203S. Annotations:

• [WZG] — documented in the WZG OEM manual.
• [OBS] — observed on our unit.
• [SURE] / [LIKELY] / [GUESS] / [UNKNOWN] — semantic confidence.

7.1 Device information¶

7.2 Metrological constants¶

All require TLV-21 args on Cubis. Arg = "area index" 0..3; our unit reports same value for all areas (single weighing range).

All return subtype 0x35 (typed_float, 5-byte body [float32][aux]).

Coupled triple: 0x0B, 0x0D, and 0x0E scale together. Changing the display-accuracy menu option to "-1 digit" moved all three by exactly 10× in one step (0x0D: 0.001→0.01, 0x0B: 0.1→1.0, 0x0E: 0.01→0.1). 0x0D is the canonical live increment; 0x0B and 0x0E are fixed ratios above it — likely "stability threshold in display units" and "minimum zero-tracking step", pegged to 10× and 100× the increment. [LIKELY]

7.3 Tare and zeroing¶

7.4 Weight and gross-weight reads¶

7.5 Filter / weighing-mode configuration¶

Filter and sampling-rate are independent axes:

7.6 Status queries¶

7.7 Calibration / adjustment¶

7.8 Presettings and menus¶

7.9 Basic / system¶

7.10 Data interface¶

7.11 Extended opcodes (not in WZG)¶

Opcodes in this section are not in the WZG OEM manual but are implemented in Sartorius firmware. Availability varies by family:

• Most are present on MSE (Cubis); a subset (0xBA, 0xB9, 0xAA) are also present on BCE3202.
• WZA lacks most of these entirely (err_04 unknown_opcode).
• Truly Cubis-exclusive: 0x62, 0x59/0x5A (their side effects on 0x62), and the 0x80-set state-byte encoding in status blocks (§8.2).

See §14.2 for the cross-family presence matrix.

ACK-only opcodes (resolved)¶

Data-returning opcodes¶

7.12 The cal record (0xB9) byte layout¶

17-byte body, subtype 0x51:

If the balance has never had a cal recorded in the current RAM buffer, the metadata bytes [4..16] are all zero. The temperature prefix [0..3] may still hold the last-cal reading (kept in a separable field — see below).

Storage architecture (three tiers, all with empirical support):

1. Cal coefficients live in EEPROM-backed RAM loaded by the boot path into the measurement pipeline. Not exposed via 0xB9. Weighing reads remain accurate even when 0xB9 is empty, confirming this layer is independent of the visible buffer.
2. The 0xB9 cal-record RAM buffer (what this opcode reads) is populated on cal events and cleared on every cold boot (plug-pull verified: the full 17 bytes read as zeros immediately after boot).
3. Separable fields within the buffer. Certain undocumented writes (0x2D, 0x53, 0x61, 0x6B, 0xB6) can zero [4..16] while leaving [0..3] intact at the last-cal temperature. This proves cal-metadata and cal-temperature occupy separate backing locations that alias into the same readable record.

8. Measurement frame decoding¶

8.1 Short measurement (8-byte body)¶

Returned by 0x1E, 0x1F, 0x20, 0x21, 0x1C, 0x22, 0x23 — subtype 0x48 with 8-byte body:

byte  field                  type         meaning
[0-3] value                  float32 BE   displayed value in reported units
[4]   aux                    u8           usually last byte of the float
                                          — extra-precision echo [LIKELY]
[5-6] unit                   2 bytes      see §8.4
[7]   flags                  u8           bit 0x40 = stable; low nibble varies
                                          by opcode/mode (NOT persistent)

Overload / underload is signalled simultaneously in three places:

1. The measurement-body sentinel bytes[0..4] == 7f ff ff ff ff.
2. The status block's state byte: 0x82 overload, 0x84 underload.
3. Status byte bit 0x08 clears briefly on the recovery transition out of the off-scale state (sub-second window) but is unchanged during the off-scale state itself — see §8.2.

[SURE] Detect the state itself by watching the sentinel + state byte; the bit-0x08 clearing window is a secondary signal useful for knowing when the ADC has fully re-settled after recovery.

8.2 Status block (also 8-byte body, subtype 0x48, returned by 0x30)¶

byte  field                  type         meaning
[0]   aux_flag                u8          Varies by family (see below).
                                          0x00 on WZA/BCE; observed 0x08
                                          on MSE under some states.
[1-2] marker                  2 bytes     always `00 81`
[3]   state                   u8          family-dependent — see below
[4]   status                  u8          family-dependent — see below
[5-6] marker_suffix           2 bytes     always `10 00`
[7]   seq                     u8          monotonic measurement counter.
                                          On MSE, increments at the
                                          measurement rate. On WZA, the
                                          tick counter (0x35) ticks at
                                          ~50 Hz independently of the
                                          measurement rate, so the `seq`
                                          here may track a different
                                          clock on simpler balances.

State / status byte encoding is family-dependent. Two patterns observed:

Interpretation: - On Cubis, bit 0x80 in state is the "measurement valid" base and bit 0x08 on top marks stable. Status-bit 0x10 = isoCAL attention/due; bit 0x08 = ADC-trust. - On non-Cubis (WZA, BCE), the state byte never sets 0x80; bit 0x08 alone marks stable. Status bit 0x20 appears to carry a "result-ready / settled" signal. - Bit 0x08 is the stable indicator on both families — just placed in different bytes.

Cross-family-portable stable detection: read the measurement-frame flags byte's 0x40 bit (§8.1). That bit is universal; the status-block state byte is not.

Byte [0] behaves as an aux-flag: 0x00 on WZA and BCE across all observed states, but observed as 0x08 on MSE in one capture session while state cycled 0x80/0x88 normally. Most parsimonious interpretation is that byte[0] mirrors or extends the MSE-only ADC-trust bit; needs more in-state captures to pin down. Parsers should not assume byte[0] is zero.

Distinguishing short-measurement from status-block (both subtype 0x48, both 8 bytes): status-block bytes [1..2] are reliably 00 81, status-block bytes [5..6] are reliably 10 00. Short-measurement frames rarely match those patterns.

8.3 Long streaming measurement (17-byte body, subtype 0x48)¶

Returned by 0x1E 09 30 — a short measurement concatenated with a status block via a single-byte delimiter:

[0..7]  short measurement (8 bytes, as §8.1)
[8]     delimiter (always 0x48 — same as subtype!)
[9..16] status block (8 bytes, as §8.2)

The length byte of the overall frame is 0x14 (20), making the total frame 21 bytes. [SURE]

8.4 Unit encoding (bytes [5..6] of measurement body)¶

Byte [5] high nibble = number of decimal places displayed.

This is the universal rule, confirmed across MSE, WZA, and BCE for g, kg, and mg displays at standard, 10×-hires (0x1F 21 01), and 100×-hires (0x1F 21 02) resolutions. Observed values 0x00 (0 dec) through 0x70 (7 dec). The increment opcode 0x0D reports its value in the current display unit, so the decimal count corresponds to displayed resolution, not a fixed unit.

Byte [6] = sign_bits | base_unit_id:

Base-unit IDs (low 6 bits of byte [6]):

So a complete decode is:

decimals = byte[5] >> 4
sign     = byte[6] & 0xC0   # 0x00 zero, 0x40 pos, 0x80 neg
unit_id  = byte[6] & 0x3F

mg low-nibble anomaly: on WZA at display=mg, byte[5] comes back with low-nibble 3 (values 0x03, 0x13, 0x23 at std/10×/100× hires). On MSE at display=mg (1 mg resolution, 0 decimals displayed) low-nibble is 0. The anomaly correlates with WZA's 10 mg display resolution — a balance that can't show 1 mg granularity in mg mode — but the exact semantic isn't decoded. BCE's mg behaviour hasn't been captured. The practical decoder rule is: use byte[5] >> 4 for decimals; treat the low nibble as advisory/quirky.

9. Temperature sensors (opcode 0x76)¶

Live multi-sensor temperature read. TLV arg selects the sensor index. Installed sensors are family-dependent:

Installed sensors → 3 (MSE) / 2 (WZA) / 1 (BCE); not-installed slots return the sentinel 7f ff ff ff. A single-sensor basic balance is expected for the simpler product classes.

Confirmed live (not stored) by observing LSB jitter across repeated reads on every balance — sensor-0 readings drift by tens of µ°C per sample on empty pans.

Return format: subtype 0x35 (typed_float, 5-byte body). Temperature is float32 °C.

On MSE, sensor 0's live reading is what the cal record (0xB9) snapshots into its first 4 bytes at the moment of a calibration event.

10. Parameter table (opcode 0x55)¶

Parameter-table size is family-dependent:

MSE and BCE share the full 70-index parameter table; WZA's 8-index subset is the outlier. The subsections below document MSE+BCE index semantics; WZA exposes the first 8-9 indices with the same meanings but narrower max values on a few (e.g. max=2 on p05 vs MSE's 3; max=23 on p07 vs MSE's 24; max=5 on p09 vs MSE's 18) — consistent with WZA being a simpler balance with fewer available options.

The 70 indices valid on MSE+BCE are organised in contiguous ranges:

0..18    (19 params)
24..25   (2 params)
27..45   (19 params)
50..79   (30 params)

Each read returns two u8 TLVs: (current_value, max_value). Writing is done via 0x56 with TLVs (idx, val) — the frame shape is observed in legacy captures but we have not exercised writes.

Address space is exactly 80 u8 indices, TLV-21 only. 0x55 rejects wider-tag reads (22 XX XX, 24 XX XX XX XX, alt tags 11/12/14) with err 0x07, and u8 indices 80..255 return err 0x03. There is no hidden extended table reachable via wider TLV addressing. The 19 unmapped slots on this unit are either firmware-reserved-but-unused or live behind service-menu state that xBPI alone cannot trigger.

The max field is firmware-family-wide, not product-line-wide. On MSE+BCE many params show max=18 or max=24 even though only a handful of values are accepted — gaps are reserved for balances within the family that expose more menu options. WZA has narrower max values on a few indices, reflecting its simpler feature set.

10.1 Identified parameter mappings¶

48 of 70 indices mapped. Sorted by index:

Unmapped indices (22): p00, p17, p18, p24, p25 (unknown), p27–p30, p42, p43, p45, p51, p52, p54–p56, p58, p62, p76–p79.

These did not surface through any front-panel menu toggle we ran. Likely homes: application-program sub-settings (per-app tolerances, nominal weights, sample sizes, density reference liquids) or deeper service menus not accessible without elevated credentials.

Two distinct persistence classes exist in the balance, distinguishable by whether 0xBA (config counter) bumps on write:

• Weighing-pipeline config (bumps 0xBA): filter mode, stability range, display accuracy, display unit, cal settings, communication settings — most of the table.
• UI preferences / boot flags (don't bump 0xBA): p13 tare-on-power-on, p36 SBI output mode (autoprint switch), p50 acoustic signal. These writes bypass the main config-generation counter, likely because they're persisted to a separate EEPROM section that the host doesn't need to resynchronize on. (Cache-invalidation logic in devices/session.py must therefore not rely on 0xBA to detect changes to these indices — invalidate explicitly on the write path instead.)

10.2 What is NOT in the parameter table¶

Several menu-accessible settings are not reachable through the parameter table or any other xBPI probe we have found:

• Application mode and its sub-settings (weighing / counting / percent / net-total / totalizer / animal-weighing / calculation / density; plus the per-app sub-menus and mode-activation workflows like count's reference-quantity entry). Toggling through all 8 modes and exercising count-mode sub-settings (resolution, ref-upt) against the full 80-index param table, every structured read, and every no-args 0x00–0xFF sweep produces zero byte differences between settings. 0xBA bumps on every commit, confirming the balance persists each change — the setting values are simply not exposed via xBPI. The only app-activity signals are 0xBA bumps on commits and transient 0x62 / 0x50 / 0x51 movements that carry state-machine information but no setting values.

Hypothesis: app mode and its sub-settings are front-panel/UI concepts that reconfigure display and post-processing but not the measurement stream xBPI exposes. [LIKELY] Consequence: the unmapped param-table indices (p27–p30, p42–p45, p51/p52/p54/p55, etc.) are NOT in app-menu territory — they must live elsewhere, most likely behind service-menu access (§13.3 C).

• User ID (free-entry 7-char alphanumeric, "Input" menu): setting it bumps 0xBA but the string appears nowhere — not in the param table, not in any structured probe, not in the full 256-opcode no-args wide sweep. 0x03 (read_user_id per WZG) returns a zeroed measurement frame regardless of args on this unit. The ID is stored in a register that requires specific TLV-addressed reads not yet discovered. By extension, the "date", "time", "password", and "cal weight" free-entry fields in the Input menu are likely in the same category.

• Display language (English / Deutsch / français / italiano / español / …): bumps 0xBA but produces zero readable diffs across any language pair, even with the wide sweep. Language is committed to balance state but unreachable via current xBPI probing. Likely stored in a display-controller chip on a separate bus from the main xBPI processor.

11. Known workflows¶

11.1 Tare¶

→ 04 01 09 14 22                    tare command
← 03 41 00 44                       ACK (synchronous completion)

No arguments, no polling. 0x14 is the real tare command.

11.2 Read weight¶

→ 04 01 09 1e 2c                    read net weight
← 0b 41 48 <8-byte short measurement> <chk>

11.3 Stream weight (long format)¶

→ 06 01 09 1e 09 30 67              read net with status block attached
← 14 41 48 <17-byte long measurement> <chk>

The balance does not stream continuously — each frame is one-shot per request. To poll, re-send. The internal measurement rate is tied to p14 cycle rate (2.5 Hz at "normal" down to 100 Hz at "max"), so polling faster than the measurement rate yields duplicate frames until the internal seq counter advances.

11.4 Read all 4 temperature sensors¶

for sensor in (0, 1, 3):           # index 2 is "not installed" on MSE1203S
    send( 0x76 + [21, sensor] )
    parse reply as subtype 0x35 typed_float

11.5 Read last calibration record¶

→ 04 01 09 b9 be                    read_last_cal_record
← 14 41 51 <17-byte cal record> <chk>

Decode per §7.12. If all metadata bytes are zero, no cal has been recorded since the last EEPROM clear.

12. Implementation notes¶

• The checksum (sum & 0xFF) is trivial; no CRC involved.
• Frame boundaries are unambiguous: read length byte, then length more bytes, then validate checksum.
• Expect to handle unexpected frames if the balance has continuous output enabled from SBI mode (seen once in this project — the balance auto-printed SBI-style ASCII lines even when set to xBPI because "autoprint" was left on from a prior SBI session). Before opening a new session, clear the input buffer and consider probing 0x32 to validate xBPI is live.

• Wide-sweep self-poisoning: when enumerating every opcode 0x00–0xFF to discover behavior, exclude at minimum the ACK-only opcodes that have side effects — 0x59 and 0x5A clear the xBPI 0x62 flag and bump 0xBA. Including them in a sweep corrupts subsequent diffs with phantom "0x62 changes" caused by the tool itself, not the system under test. The sartoriustesting.cli.snapshot tool excludes them from its wide sweep.

• TLV-args-unlock writes: many opcodes that err on no-args silently ACK (executing a write) when given TLV-21 args. An arg-diverse wide sweep that only skips the known-destructive no-args set is unsafe — an undocumented write register can push the balance into an overload state. The SKIP list in snapshot.py:254 covers every WZG-side-effecting op plus every empirically-identified ACK-on-TLV unknown. Always run arg-diverse sweeps behind a recent baseline so any residual state drift is visible on recovery.

• Bootloader-drop risk on wide sweeps — SKIP list may be insufficient for unfamiliar balances: a read-only no-args opcode sweep on a BCE3202 (with an MSE-learned SKIP list plus the WZA-learned 0x9F silent-ACK opcode) left the balance stuck in firmware bootloader mode ("B.LOADER" on front panel). Power-cycling recovered cleanly. The reply log showed no opcode that ACK'd unexpectedly, meaning at least one opcode in the err-0x07 invalid-args class on BCE is not a pure read — its no-args call has a delayed or state-sensitive side effect. Do not run an undifferentiated opcode sweep on an unfamiliar balance. Characterise each novel opcode with a single-shot probe bracketed by a baseline-diff (reads of known stable registers before and after) and a front-panel visual check. The cost of catching a bootloader drop early is low; the cost of a stuck unit without recovery is catastrophic.

• xBPI signals vs real state: 0x62 (and correlated 0x0F bit 6) are menu-activity signals on the xBPI side only; they do not reliably track which app is running on the front panel. Use 0xBA bumps as the canonical "something persisted" signal rather than inferring mode from any single register.

13. Outstanding items¶

13.1 Relationship to the WZG manual¶

This document is a strict superset of the WZG manual. WZG documents 28 opcodes (0x00–0x07, 0x0A–0x0F, 0x13–0x22, 0x26, 0x28–0x29, 0x2C–0x2F, 0x32, 0x35–0x36, 0x40–0x41, 0x46–0x47, 0x4A–0x4B, 0x54–0x58, 0x5C, 0x71–0x72, 0x76, 0x78–0x79); all are covered here plus ~25 Cubis-specific extensions. WZG offers no additional leads on our outstanding unknowns: the data-returning unknowns (0x08, 0x25, 0x31, 0x33, 0x48, 0x7E, 0xAA, 0xB5, 0xB7, 0xBB, 0xBD) don't appear there, the parameter-table section is a bare "Timeless menu index" stub, the status byte has no bit-level documentation, app mode / language / user-ID storage are absent, the 0xB9 cal record is not mentioned, and service access is referenced only as a physical hardware port with no xBPI command.

13.2 Data-returning opcodes of unclear semantic meaning¶

Each returns stable structured data but the meaning isn't decoded. Most likely service/diagnostic registers (calibration coefficients, factory trim values, hardware-version identifiers): 0x31, 0x33, 0x48, 0x7E, 0xAA, 0xB5, 0xB7, 0xBB, 0xBD. Individual characterisations are in §7.11.

13.3 Undocumented write opcodes¶

Five Cubis-specific writes characterised only by error-code texture under TLV-21 args 00/01/02. One of them (most likely 0xB6) caused an overload-state lockup during discovery — they remain in the wide-sweep SKIP list pending isolated probe-op characterisation against a known baseline.

13.4 Parameter-table indices still unmapped¶

19 of 70 indices remain unmapped after exhausting app-layer and user-menu toggles: p00, p17, p18, p24, p27–p30, p42, p43, p45, p51, p52, p54, p55, p62, p76–p79. Three more (p25, p56, p58) are partially characterised as the "boot-resets-to-1" class but their semantic meaning is undetermined. These slots are reachable via 0x55 reads but don't respond to any user-accessible menu — they most likely live behind the service menu (§13.6).

13.5 State-gated opcode cluster¶

A long-arg opcode sweep found opcodes that exist in firmware but return err 0x06 (operation_not_applicable) rather than err 0x04 (unknown_opcode) regardless of arg shape:

• 0x4C, 0x4D, 0x4F — adjacent to the EEPROM/ISI ops (0x46/0x47/0x4A/0x4B); probably cal- or EEPROM-workflow sub-ops.
• 0x77, 0x7A — adjacent to temperature / adjustment-unit ops (0x76/0x78/0x79); probably cal-family.
• 0xA0, 0xA2, 0xA3, 0xA4, 0xA5, 0xA7, 0xAB, 0xAE, 0xB0 — a contiguous cluster with no known siblings. Strongest candidate for a service-menu API surface.

The gating condition is unknown. Most likely requires entering a specific balance state (active cal, active tare, service-mode-unlocked) before responding. Worth a future session that deliberately enters cal / tare / zeroing states and re-sweeps the cluster to see which become valid in each.

13.6 Service menu (Cubis challenge-response)¶

Cubis balances protect service-level settings behind a 6-digit challenge-response. The balance displays a per-session random 6-digit nonce and requires a 6-digit response F(nonce) that only Sartorius service tooling knows. Brute force across sessions is infeasible — the nonce resets each attempt and the search space is 10⁶.

xBPI has no visibility into this flow. The authentication runs on the front-panel / display-controller microcontroller, which shares a bus with language selection, user-ID, and app-layer state (§10.2). At-the-prompt and at-entry snapshots contain no copy of the nonce in any encoding (u32/ u24/u16 BE or LE, BCD, ASCII), no param-table change, and no state-gated opcode activation — the state-gated cluster above does NOT unlock in the password-entry state.

Service-access mechanisms across the Sartorius product line differ:

• Older / industrial balances (Combics, Masterpro, Signum, Expert LE) combine a hardware "menu access switch" (S1 jumper) on the mainboard with static default passwords — 202122 (service) and 40414243 (general), following a sequential-integer pattern (documented in the Combics CAW1P and Masterpro manuals).
• Cubis I/II and newer use the 6-digit challenge-response described above. No hardware switch is documented in user materials. Neither 202122 nor the identity-key (response == nonce) unlocks the Cubis.

The service software implementing F is SARTOCAS Service Program for PCs v1.10+ (older equivalent: PSION server CAS v4.5+). Distributed only to authorised Sartorius service engineers via MySartorius service-tier accounts; no public leak found. If available, a copy would enable two attacks: (a) sniff the xBPI traffic between Sartocas and the balance via the sarto-tap CLI to observe the unlock sequence, and (b) static analysis of the binary to extract F directly.

Nonce-generator characterisation (15 consecutive samples): no LCG-compatible pattern across standard moduli (10⁶, 2²⁰, 2²⁴, 2³⁰, 2³¹, 2³²), GCD of consecutive differences = 1, no XOR or multiplicative structure between pairs. Nonces span most of the 6-digit range (117k–899k) with roughly uniform overall digit frequencies. Statistically significant last-digit bias toward 0 (6 of 15 nonces end in 0 vs 10% expected, p ≈ 0.002) — suggests display-formatting truncation or a timer-derived source with coarser internal resolution than the 6-digit display. The bias characterises the generator but does not recover F.

Status: closed for xBPI-only reachability. Access requires one of (a) a Sartocas binary for analysis, (b) an undocumented hardware jumper on the Cubis mainboard, (c) a JTAG/SPI firmware dump of the front-panel microcontroller, or (d) a legitimate Sartorius service engagement.

13.7 Miscellaneous open questions¶

• 0xB9 bytes [13..15] are confirmed cal-event counters but their exact per-field semantics — and specifically why byte [13] increments by +2 per cal where [14] and [15] increment by +1 — are unresolved.
• TLV-addressed reads with wider tags. Fuzz testing of 0x03, 0x08, 0x25, 0x31, 0x33, 0x48, 0x50, 0x51, 0x7E, 0xAA, 0xB5, 0xB7, 0xBB under TLV-11/12/14/22/24 args returned no new data — the protocol appears to be strictly TLV-21-only for slot addressing, with other opcodes either ignoring args or rejecting wider tags. 0x03 (WZG-documented read_user_id) continues to return a zeroed measurement frame on any arg form; the user-ID storage location remains unknown.
• Per-unit correlation. If a second Cubis is accessible, comparing 0x08, 0xAA, 0xB7, and the other factory-constant-looking opcodes would identify which fields are factory-trim / serial-derived (differ per-unit) vs. universal product constants (identical).

13.8 Destructive opcodes (use caution)¶

The following must not be exercised without clear intent:

• 0x04 write user ID
• 0x28 start adjustment (wrong args can trigger a real calibration)
• 0x40 reconfiguration
• 0x41 reset temporary errors
• 0x56 write parameter table
• 0x58 initiate reset (warm/cold)
• 0x5C set baud rate (can silently break comms)
• 0x72 write SBN address (can silently break comms)
• 0x79 write adjustment unit

Plus the five undocumented writes in §13.3 (0x2D, 0x53, 0x61, 0x6B, 0xB6) — any of these can push the balance into an overload state that only clears on cold boot.

14. Cross-family observations¶

Everything in §1-13 has been validated across three balances. Protocol features described there without a family qualifier are universal unless otherwise noted. This section consolidates the family-specific behaviours and the opcodes that exist on some balances but not others.

14.1 Balance identification¶

14.2 Opcode presence matrix¶

Key opcodes and their behaviour on each balance. ✓ = works, err_04 = unknown_opcode, err_07 = invalid-args (exists but needs args not yet characterised):

14.3 Metrological thresholds (0x0B / 0x0E)¶

0x0D is the live increment (display-unit dependent). 0x0B and 0x0E are thresholds that scale with the increment — but the 0x0B ratio depends on display resolution:

0x0E is consistently 10× increment across families. 0x0B is 100× on 1-mg balances, 50× on 10-mg balances — a resolution-dependent ratio, not a family-dependent one.

14.4 Cycle-time curve is universal (p01-driven)¶

0x57 cycle_time tracks p01 (filter / ambient mode) identically on every balance that has both indices:

Confirmed on MSE at p01=4 (400 ms), WZA at p01 ∈ {2,3,4} (100/200/400 ms), and BCE at p01 ∈ {2,3} (100/200 ms). The doubling sequence is universal. p14 exists on MSE and BCE as a separate parameter but does NOT drive 0x57: isolating on BCE with only p01 changing (and p14 held at 1) moved 0x57 200→100 ms as p01 went 3→2. What p14 drives is open.

14.5 State / status byte encoding by family¶

See §8.2 for the layout and family-specific state byte meanings. In summary:

• Cubis (MSE): state byte has bit 0x80 set (unstable 0x80, stable 0x88); status byte uses bit 0x08 for ADC-trust and bit 0x10 for isoCAL-due.
• Non-Cubis (WZA, BCE): state byte never sets 0x80 — stable is 0x08, unstable is 0x00; status byte uses bit 0x20 for a "measurement ready" signal.

Cross-family stable detection should use the measurement-frame flags byte's 0x40 bit (§8.1), which is universal.

14.6 BCE-specific opcodes¶

All of the following return err_04 unknown_opcode on MSE and WZA. They are BCE-family reads.

14.6.1 0x75 raw load ADC¶

Returns a 4-byte body under novel subtype 0x14, linearly correlated with load:

0x75 ≈ 310,118,054 + 79,767 × mass_g (≈ 12.5 µg per ADC count)

Verified on BCE3202 across three loaded mass points (18.27 g / 199.86 g / 699.54 g) with < 0.01% residuals. The empty-pan reading sits ~785,000 counts above the extrapolated zero-mass intercept (≈ 9.8 g equivalent), because the balance's displayed "0.00 g" is a software-tared value that 0x75 doesn't participate in.

Practical use — field-calibrate two points and interpolate:

1. Tare or leave pan empty, read 0x75 → baseline B.
2. Place known mass m_ref, read 0x75 → reference R.
3. For any later reading v: mass ≈ (v − B) × m_ref / (R − B).

Do NOT anchor on the literal y-intercept constant 310,118,054 — it isn't an observable state.

0x75 exposes sub-display-LSB dynamics that the balance's digital filter hides: ~500-count oscillation (~6 mg) on a stable empty pan; visible creep/relaxation (hundreds of counts) during mass settling; tighter absolute noise at larger loads (160 counts at 700 g vs 500 at 18 g). Candidate applications: custom filters (EMA/Kalman), creep monitoring, sub-LSB averaging for steady-state measurements.

First publicly-documented raw-ADC access on any Sartorius xBPI balance. No published SBI/xBPI driver surfaces this.

14.6.2 0x3B — likely user-unit label storage¶

Stable 12-byte body (subtype 0x48, novel length):

3f 80 00 00   00 00 02 80   43 67 20 20
└─ float 1.0  └─ 4 bytes     └─ "Cg  " ASCII null-padded

Decomposes as: multiplier: float32 (1.0 default), 4 middle bytes (flags or count), 4 trailing ASCII bytes ("Cg "). Hypothesis: storage for p07's userdef=1 user-defined display unit, matching §10.1's note that the user-defined multiplier and label "live in a separate register not yet located." Unchanged across 5 s — a static register, not time-varying. To confirm, program a user-defined unit via the front panel and watch the label field change.

14.6.3 Short novel registers¶

All return 1-byte bodies (subtype 0x21 or 0x41), stable across reads:

14.6.4 Args-accepting reachable surface (uncharacterised)¶

52 opcodes on BCE return err_07 invalid_or_missing_args on no-args and all TLV tag variations tried (11/12/14/21/22/24). They exist but want argument shapes not yet guessed — most likely multi-TLV structured args (e.g. 21 <slot> 35 <float32> <aux> write-with-value forms). Characterisation is blocked by the bootloader-drop risk:

0x06, 0x1B, 0x27, 0x2A, 0x3A, 0x3E, 0x3F, 0x42, 0x43, 0x44, 0x45, 0x49, 0x4B, 0x4C, 0x4D, 0x4E, 0x4F, 0x52, 0x5D, 0x63, 0x65, 0x6C, 0x6E, 0x70, 0x7A, 0x7B, 0x7D, 0x7F, 0x80, 0x82, 0x83, 0x8D, 0xA9, 0xAA, 0xAC, 0xAD, 0xB0, 0xB1, 0xB8, 0xBF, 0xC1, 0xC3, 0xC4, 0xC5, 0xC7, 0xC8, 0xC9, 0xCA, 0xCB, 0xD3, 0xD5, 0xD7, 0xD8

Requires per-opcode characterisation against a baseline with cold-boot recovery budget. See §12 for the bootloader-drop incident.

14.6.5 0x9F — silent-ACK write¶

Acks every TLV-21 arg with no visible change in any monitored register. Almost certainly a write. On the permanent SKIP list until individually characterised.

14.7 MSE (Cubis)-specific features¶

• 0x62 — active menu-activity register on MSE (value varies transiently with menu interaction). Reads as constant 0x00 on WZA (dead register) and is entirely absent on BCE (err_04). Treat as Cubis-exclusive.
• 0x08 — returns factory-trim body 5b 67 df on MSE. Both WZA and BCE return 00 00 00. Appears to be MSE-populated factory data (hardware-variant token or build checksum) with the register unpopulated elsewhere.
• State byte with 0x80 set — Cubis-only encoding. See §8.2.
• Cycle-time driven by p01 only — MSE has both p01 and p14 but 0x57 tracks p01 just like WZA and BCE; p14's effect remains open.
• Status-block byte [0] may be non-zero on MSE — one session observed 0x08 consistently. See §8.2 notes.

14.8 WZA-specific features¶

• Reduced parameter table: 8 valid indices (p01-p07 plus p09) versus MSE+BCE's 70. See §10.
• mg-display byte[5] low-nibble anomaly: at display=mg, byte[5] comes back with low-nibble 3 (values 0x03/0x13/0x23) instead of 0. Correlates with WZA's 10 mg resolution (display can't reach 1 mg granularity in mg mode). See §8.4.
• Time-stamp tick decoupled from measurement rate: 0x35 on WZA ticks at ~50 Hz independently of cycle_time (which is 100-400 ms). On MSE, 0x35 ticks at the measurement rate.
• 0xBA and 0xB9 are absent (err_04 unknown_opcode) despite working on both MSE and BCE. The 0x0B9 cal-record register and 0xBA config-gen counter are genuinely missing from WZA firmware, not Cubis-specific as we originally hypothesised.

14.9 Universal firmware constants (0xAA)¶

0xAA with TLV-21 arg 00 or 01 returns body 14 21 12 00 97 14 00 95 b7 44 on all three balances, byte-for-byte identical. Decodes as two u32 TLVs:

• 0x14 21120097 = 0x21120097 (decimal 555,745,431)
• 0x14 0095b744 = 0x0095b744 (decimal 9,811,268)

TLV-21 args ≥ 02 return err_03. Meaning not decoded; strongest candidates are firmware-build ID and protocol-version tokens. The byte-for-byte match across three families makes this the best candidate for a universal xBPI fingerprint.

14.10 Other structural observations¶

• 0x0A configuration_data embeds the current unit descriptor in its body bytes [5..6]. At display=g, bytes [5..6] = 02 02 (2 decimals, g); at display=kg on BCE, 05 03 (5 decimals, kg). The configuration-data structure reuses the unit-descriptor encoding from measurement frames.
• 0x50 slot availability varies: MSE has slots 0 and 1 both valid (u8=3); WZA has the same pair; BCE has only slot 0.
• 0x48 stored-reference differs per balance: 1000.0 g on MSE, 5000.0 g on BCE (exceeds BCE's 3200 g max, so not a user-settable reference). Appears to be a firmware-wired constant chosen at manufacture.

14.11 Bootloader-drop incident¶

A read-only no-args opcode sweep on BCE3202-1S (with an MSE-learned SKIP list plus the WZA-learned 0x9F silent-ACK opcode) left the balance stuck in firmware bootloader mode ("B.LOADER" on the front panel). Power-cycling recovered cleanly. No reply in the capture log showed an opcode ACK'ing unexpectedly, so at least one opcode in the err_07 invalid-args response class on BCE has a delayed or state-sensitive side effect when called with no args.

This means the §13.8 SKIP list is not sufficient on unfamiliar balance families. The WZA+MSE-derived safe list, which worked on both those balances without incident, triggered the drop on BCE.

Safe exploration strategy for an unfamiliar balance:

1. Characterise each opcode with a single-shot probe, not a sweep.
2. Bracket each probe with baseline diffs (reads of 0x32, 0xBA, a few param-table indices) before and after.
3. Between probes, visually check the front panel — a bootloader drop is front-panel-visible before any serial symptom.
4. Keep a cold-boot recovery budget — the BCE drop cleared with a single power cycle, but don't rely on it.

14.12 Open items¶

• BCE bootloader-drop culprit. Needs bisection probing with a cold-boot budget per iteration.
• BCE state-byte encoding under shake. Only stable captured.
• BCE args-accepting opcode semantics (§14.6.4). The richest untapped reverse-engineering surface.
• What p14 actually drives. Confirmed not 0x57; still unknown.
• 0x3B user-unit label change via front-panel unit programming, to confirm the user-defined-unit storage hypothesis.
• 0x75 on MSE alternatives. Confirmed absent on MSE; whether MSE has a different raw-ADC opcode is open.
• Per-unit variation of 0x08 within the MSE family (we have one MSE). A second MSE would tell us whether 5b 67 df is per-unit factory trim or family-wide.
• Status-block byte [0] semantics on MSE — observed 0x08 in one capture session, 0x00 in earlier ones. Needs state-correlated captures.

15. References¶

• This repository: everything under src/sartoriustesting/ — the Python reference implementation of the findings documented here.
• WZG OEM weigh cell manual: shipped with Sartorius WZG OEM weigh cells. A local copy lives at datalab-output-Bilance_Tecniche_Sartorius_OEM_IP65_DS-WZG-e.md in this project.
• Experiment playbook: EXPERIMENT_PLAYBOOK.md — runbook for the snapshot → toggle → diff workflow.
• Captured sessions: captures/ — JSONL and JSON files with raw xBPI frames and decoded state snapshots from every experiment feeding into this document. Organized by experiment: paramdiff/vNN-<setting>/ for menu-toggle captures, acks/ for opcode-probe experiments, plus the early expN-*.jsonl captures from initial frame-format discovery.