BP BitPads Protocol

Enhancement Sub-Protocol · Category 1110

Telegraph
Emulation
Mode I

Every byte in the stream is a signal. The same byte stream is readable by a 1960s teleprinter and a BitPads receiver simultaneously.

Category 1110 is the most powerful of the three Enhancement Sub-Protocol categories. The full C0 Enhancement Grammar is active for the entire stream duration — not just at declared signal slots.

Named for the telegraph protocols from which it inherits the byte structure, Telegraph Emulation Mode delivers a vocabulary of 232 distinct typed events per byte position while remaining byte-for-byte backward compatible with legacy C0 receivers.

232
typed events per byte

29 agreed C0 controls × 8 flag combinations. Every byte position in the stream.

1110
meta category code

Meta byte 1: bit1=0 (Wave), bit4=1 (category mode), bits5-8=1110.

100%
backward compatible

Legacy receivers see standard C0 controls. Plain C0 bytes (flags 000) are identical to their legacy counterparts.

3
flag bits per byte

Upper 3 bits carry P/A/C (Priority, Acknowledge, Continuation) flags. Lower 5 bits carry the C0 code identity.

Design Achievement

The Legacy Compatibility Design

This is the central design achievement of Category 1110. A BitPads Telegraph Emulation stream transmits bytes 0–31 as genuine C0 controls. A legacy teleprinter or terminal receiving the same byte stream sees standard controls throughout — BEL rings, FS separates files, EOT closes the transmission.

A BitPads receiver reads the enhancement flags in the upper 3 bits and decodes rich typed events from the same stream. The two receive modes coexist on the same byte stream. No channel switching. No mode flags to the legacy device.

Legacy Receiver View
  • Bytes 0–31 read as standard C0 controls
  • Bytes 32+ seen as printable ASCII or Latin-1 content
  • BEL (0x07) still rings the bell
  • EOT (0x04) still closes the transmission
  • SYN (0x16) still provides synchronisation idle
  • FS, GS, RS, US still act as data separators
  • Enhancement bytes (≥32) appear as text
  • Completely transparent — no mode negotiation
BitPads Receiver View
  • Plain forms (000 + code) = standard C0 semantics
  • Enhanced forms (001–111 + code) = C0 meaning + P/A/C flags
  • Priority BEL (0x87) = urgent alert, elevated handling
  • ACK-req EOT (0x44) = confirmed close, ACK back required
  • Continuation SYN (0x36) = signal sequence opening
  • Full+ACK+Cont BEL (0xE7) = emergency alert with detail
  • Every byte decoded for flag state + C0 identity
  • 232 distinct typed events per byte position

The structural reason this works: ASCII bytes 0–31 are C0 controls. Bytes 32–127 are printable characters. Latin-1 extends to 255. A legacy receiver treats bytes ≥32 as content. A BitPads receiver treats ALL bytes as enhanced C0 bytes — reading the upper 3 bits as flags and the lower 5 bits as the C0 code identity. The same 8 bits carry two complete, non-conflicting interpretations simultaneously.

Session Configuration

Activating Category 1110

Category 1110 is declared in Meta byte 1. The Wave mode bit (bit 1 = 0) is set, and the Category Mode bit (bit 4 = 1) is set. Bits 5–8 carry the category code 1110.

Meta Byte 1 — Category 1110 Declaration
1 0 Wave
Mode
2 0 Cat/
ACK
3 0 Cont.
4 1 Cat.
Mode
5 1 Cat.
Bit 1
6 1 Cat.
Bit 2
7 1 Cat.
Bit 3
8 0 Cat.
Bit 4
Mode / Control Category Code 1110

Layer 1 is required if no prior session is established. In an established session, Layer 1 is not required.

Difference from Session Enhancement Flag (Layer 1 bit 12 = 1): The session flag activates enhancement at all 13 signal slot positions P1–P13. Category 1110 activates enhancement for the entire stream content — every byte in the stream body is an enhanced C0 byte. These two mechanisms are complementary. Both can be active simultaneously: session-scoped signal slots P1–P13 remain operational, and every byte in the stream body carries enhancement flags.

Byte-Level Architecture

Stream Open Sequence

A Category 1110 transmission follows a defined opening sequence. Each element is present at a specific byte position. The stream body begins immediately after the Stream-Open Control byte.

1
Meta Byte 1
Declares category 1110. Wave mode, bit 4 = 1, bits 5–8 = 1110. Always present. This is byte 0 of every transmission.
2
Layer 1
Required for new sessions. Contains sender identity, session flags. Session Enhancement Flag (bit 12) optionally set here. Not required in established sessions.
3
Session Config Ext.
Present when Layer 1 bit 12 = 1. Declares nesting level code, codebook baseline, P1–P3 slot declarations. 1 byte.
4
Stream-Open Control
Always present for category 1110. Declares active archetype, codebook selection, cipher shift, and update flag. 1 byte. See Section 5.
5
Length / Open
Either a length prefix (number of stream bytes to follow) or stream-until-close (length inferred from EOT or new Meta byte). Declared in Stream-Open Control byte Update Flag.
6
Stream Body
Every byte is an enhanced C0 byte. Upper 3 bits = P/A/C flags. Lower 5 bits = C0 code identity. No "content bytes" vs "signal bytes" distinction. The stream IS the signal.
7
Stream Close
EOT byte (plain or enhanced), length exhausted, or new Meta byte (SOH 0x01). Three distinct close mechanisms. See Section 11.

Protocol Element

The Stream-Open Control Byte

The Stream-Open Control byte immediately follows the session preamble and precedes the stream body. It declares the semantic context for everything that follows.

Stream-Open Control Byte — 8 Bits
5–6 CC Codebook
7 S Cipher
Shift
8 U Update
Flag
Active Archetype (4 bits) Codebook Selection Cipher Shift Update Flag

Active Archetype Field (Bits 1–4)

The 4-bit archetype field declares the semantic context for the stream's binary content — the universal domain flow relationship that governs interpretation of all stream events. Click any row to expand the archetype details.

CodeArchetype NameFlow DirectionDomain
0000 ▾ TransferA → BUniversal

Direct transfer from sender entity to receiver entity. The canonical flow. Financial: payment. Physical: mass transport. Energy: direct delivery. The baseline archetype — most common in simple sessions.

0001 ▾ ExchangeA ⇄ BUniversal

Mutual exchange — both parties give and receive. Financial: swap, barter. Physical: heat exchange. Encoded as two simultaneous flows. Each flow direction encoded separately with the Exchange archetype.

0010 ▾ DepositA → PoolFinancial/Physical

Entity deposits into a shared pool or reservoir. Financial: bank deposit, fund contribution. Physical: tank filling, reservoir input. The pool is the destination — not a specific entity but a shared store.

0011 ▾ WithdrawalPool → AFinancial/Physical

Entity withdraws from a shared pool. Financial: bank withdrawal, fund redemption. Physical: drawing from tank, reservoir output. The pool is the source.

0100 ▾ Issuance∅ → AFinancial

New value created and issued into circulation. Financial: bond issuance, money creation, equity issuance. No corresponding debit from an existing store — the flow originates from the issuance authority. Used with careful conservation accounting.

0101 ▾ RedemptionA → ∅Financial

Value retired from circulation. Financial: bond maturity, share buyback, loan repayment (destroying the obligation). The flow terminates rather than transferring to a new holder.

0110 ▾ AllocationA → A:subInternal

Entity allocates from its own total to a designated sub-account or purpose. Financial: budget allocation. Physical: subsystem power budgeting. The total does not leave the entity — it is internally partitioned.

0111 ▾ ConsolidationA:sub → AInternal

Sub-account balances consolidated back to the parent entity. Releases earmarked funds or resources back to the general pool. Reverse of Allocation.

1000 ▾ ObligationA ← B (future)Contractual

B is obligated to deliver to A at a future point. Financial: loan, forward contract, receivable. The obligation is the record — the future flow is not yet encoded. Creates a liability/asset pair in the double-entry system.

1001 ▾ SettlementA ← B (closing)Contractual

Closes a prior Obligation. The flow discharges the liability recorded in a prior transaction. The settlement record references the obligation record by session key or timestamp.

1010 ▾ ConversionA[x] → A[y]Universal

Same entity converts one quantity type to another. Financial: currency conversion. Physical: energy conversion (chemical → electrical). The conservation law applies within the conversion rate at the time of encoding.

1011 ▾ DistributionA → B,C,DUniversal

One source distributes to multiple destinations. Financial: dividend distribution, payroll. Physical: power bus distribution to multiple loads. Encoded as a batch with the Distribution archetype and multiple destination entries.

1100 ▾ AggregationA,B,C → DUniversal

Multiple sources aggregate to one destination. Financial: pooled funding, crowdfund collection. Physical: multiple generators feeding a common bus. Reverse of Distribution.

1101 ▾ EscrowA → [hold] → BContractual

Value moves to a held/locked state pending condition fulfilment. Financial: escrow account, collateral. Physical: staged propellant hold for future burn. The hold is the destination until release conditions are met.

1110 ▾ Release[hold] → BContractual

Held value released to the intended destination. Closes an Escrow record. The release record references the escrow record. Conditions verified at release time by the session authority.

1111 ▾ Audit / ReconciliationA ↔ ledgerControl

Declares the reconciliation state between an entity's actual holdings and the ledger record. Financial: audit confirmation, balance verification. Used in sessions where ledger integrity checks are transmitted as stream events.

Codebook Field (Bits 5–6)

CodeModeEffect
00 Universal Standard BitPads nibble codebook. 16 entries. Globally agreed. No session declaration needed.
01 Session-declared Codebook declared at session open in custom domain extension block. Receiver holds the codebook from session negotiation.
10 Shift offset / cipher Cipher-shifted codebook. Active codebook = session baseline shifted by cipher key. Provides semantic obscuration without cryptographic overhead.
11 Extended Extended codebook declaration follows in the next bytes immediately after the Stream-Open Control byte. Allows arbitrary codebook definition at stream open.

Stream Architecture

Every Byte in the Stream

In Telegraph Emulation mode, every byte in the stream body is an enhanced C0 byte. There are no "content bytes" vs "signal bytes" — the distinction disappears. The stream IS the signal.

Generic Telegraph Stream Byte
1–3 PAC Flags
P / A / C
4–8 CCCCC C0 Code Identity
Enhancement Flags (P/A/C) C0 Code Identity (5 bits)
Vocabulary per byte position:
agreed C0 controls × flag combinations = typed events
29 unconditional controls × 8 flag states = 232 distinct typed events
At every byte position in the stream. One C0 signal per byte. Three flag bits add P/A/C information to each signal.

This means the stream carries structured semantic data at the rate of one typed event per byte, with the three flag bits adding priority, confirmation, and continuation information to each signal. A 100-byte telegraph stream carries up to 100 typed events — each uniquely identified by a (C0 code, flag state) pair from the vocabulary of 232.

Byte-Level Decoding

C0 Byte Anatomy in Telegraph Mode

Every byte is decoded by splitting the 8 bits into the 3-bit flag field and the 5-bit C0 identity. The following examples show a variety of byte values and their complete decoded meaning.

EXAMPLE BYTE SEQUENCE — TELEGRAPH STREAM DECODE
──────────────────────────────────────────────────────────
 
Sequence: 0x16 0x96 0x16 0x16 0x86
 
──────────────────────────────────────────────────────────
0x16 = 000 10110 = Plain SYN → keep-alive / heartbeat, no flags
0x96 = 100 10110 = Priority SYN → priority heartbeat / pre-announce
0x16 = 000 10110 = Plain SYN → return to normal cadence
0x16 = 000 10110 = Plain SYN → normal cadence continues
0x86 = 100 00110 = Priority ACK → priority acknowledgement
──────────────────────────────────────────────────────────
EXAMPLE SEQUENCE — ALERT ESCALATION
──────────────────────────────────────────────────────────
 
Sequence: 0x07 0x87 0xE7 0x44 0x04
 
──────────────────────────────────────────────────────────
0x07 = 000 00111 = Plain BEL → standard alert, legacy rings bell
0x87 = 100 00111 = Priority BEL → elevated urgency alert
0xE7 = 111 00111 = Full BEL (P+A+C) → emergency, confirm + detail seq follows
0x44 = 010 00100 = ACK EOT → confirmed close signal incoming
0x04 = 000 00100 = Plain EOT → stream close
──────────────────────────────────────────────────────────
EXAMPLE SEQUENCE — CONFIRMED DATA HANDOFF
──────────────────────────────────────────────────────────
 
Sequence: 0x1C 0x9C 0xBC 0x1E 0x02
 
──────────────────────────────────────────────────────────
0x1C = 000 11100 = Plain FS → file separator (legacy compatible)
0x9C = 100 11100 = Priority FS → priority file separation event
0xBC = 101 11100 = P+C FS → priority FS, component escalation opens
0x1E = 000 11110 = Plain RS → record separator (legacy compatible)
0x02 = 000 00010 = Plain STX → start of text / stream resume
──────────────────────────────────────────────────────────
EXAMPLE SEQUENCE — CONTINUATION SEQUENCE
──────────────────────────────────────────────────────────
 
Sequence: 0xB6 0x36 0x36 0x16
 
──────────────────────────────────────────────────────────
0xB6 = 101 10110 = P+C SYN → priority SYN, opens signal sequence
0x36 = 001 10110 = C SYN → continuation SYN in sequence
0x36 = 001 10110 = C SYN → continuation SYN in sequence
0x16 = 000 10110 = Plain SYN → sequence close, normal heartbeat
──────────────────────────────────────────────────────────

Flag Grammar

Enhancement Fields — All 8 States

The upper 3 bits of every telegraph stream byte carry the P/A/C flag combination. Eight states. Each has a defined meaning in the stream context. Click any row to expand the detail.

Flags (P/A/C)Byte FormStream MeaningLegacy Safe?
000 — Plain ▾ 0x00–0x1F Standard C0 semantics. No enhancement flags. YES
Behaviour

Byte values 0–31. Byte-for-byte identical to standard C0 control codes. Legacy receivers and BitPads receivers decode identically. This is the backward-compatible ground state.

Protocol Flow

No response required unless the C0 code itself requires it (e.g., ENQ expects ACK). No escalation. No signal sequence opens. Stream continues normally after the byte.

Example

0x16 = Plain SYN = synchronisation idle / keep-alive. Transmitted at regular intervals on idle streams. Legacy receivers re-synchronise. BitPads receivers note the heartbeat.

001 — Continuation ▾ 0x20–0x3F Opens a signal sequence. More bytes follow at this semantic position. PARTIAL
Behaviour

Byte values 32–63. Legacy receivers see printable ASCII characters (space, !, ", # ...). BitPads receivers enter Continuation mode: the semantic position remains open until a byte without the C flag (bit 3 = 0) closes the sequence.

Protocol Flow

Receiver buffers the C0 code identity of the opening byte. Subsequent bytes with C=1 extend the sequence. First byte with C=0 closes the sequence and triggers the semantic event.

Example

0x36 0x36 0x16: two continuation SYNs followed by plain SYN. The receiver accumulates three SYN signals before triggering the keep-alive event. Extended heartbeat pattern.

010 — ACK-request ▾ 0x40–0x5F Reliable delivery within the stream. Receiver must ACK this byte's event. PARTIAL
Behaviour

Byte values 64–95. Legacy receivers see ASCII D, E, F... BitPads receivers note the ACK-request flag. The C0 code identity declares what is being confirmed. The receiver must ACK within the session timeout.

Protocol Flow

Sender marks the byte as requiring acknowledgement. Receiver processes the C0 event. Receiver sends ACK byte (0x06 or enhanced ACK form) before the timeout. Sender may retransmit on timeout.

Example

0x44 = ACK EOT = confirmed close request. Receiver must acknowledge the stream close before the channel tears down. Allows orderly session termination.

011 — ACK + Continuation ▾ 0x60–0x7F Reliable delivery within a signal sequence. Confirmation required for a continuation event. PARTIAL
Behaviour

Byte values 96–127. ACK-request and Continuation both set. The event requires confirmation AND more bytes follow. Used for confirmed multi-byte signal sequences.

Protocol Flow

Sender opens a signal sequence that requires confirmation. Receiver must ACK the opening event before the sequence continues. Sequence continues after ACK receipt. Provides confirmed ordered delivery of extended events.

100 — Priority ▾ 0x80–0x9F Elevated urgency. Pre-empts normal stream processing priority. PARTIAL
Behaviour

Byte values 128–159. Priority flag set. The event is elevated above normal stream priority. Receiver interrupts any pending normal-priority processing to handle this event first. Same C0 code identity as the plain form.

Protocol Flow

Receiver pre-empts normal queue. Processes the C0 event at elevated priority. Normal stream processing resumes after the priority event is handled. No ACK required unless also flagged.

Example

0x87 = Priority BEL = urgent alert. Immediate interrupt of any pending lower-priority processing. The bell is an emergency rather than a notification.

101 — Priority + Continuation ▾ 0xA0–0xBF Urgent announcement with detail following. Triggers Component Escalation at signal slots. NO*
Behaviour

Byte values 160–191. Priority set, Continuation set, no ACK. At a declared signal slot position: triggers Component Escalation (full BitPads Record embedded inline). Within stream body: opens priority signal sequence with detail following.

Protocol Flow

At signal slot: parser pushes state, reads inner Record, pops state, resumes stream. In stream body: receiver processes high-priority event and awaits continuation bytes defining the detail payload.

Legacy Note

*Legacy receivers see byte values 160–191, which fall in the Latin-1 extended character range. They appear as extended characters — visible on screen but not processed as controls. The stream continues to be receivable.

110 — Priority + ACK ▾ 0xC0–0xDF Standard form for confirmed important events. Critical system state with required confirmation. NO*
Behaviour

Byte values 192–223. Priority set, ACK-request set. Used for critical events that must be confirmed. Lower 5 bits of C0 identity also carry codebook shift index when used at rolling codebook shift positions.

Protocol Flow

Receiver pre-empts normal queue. Processes at high priority. Must ACK within timeout. No continuation — this is a single confirmed event. The combination of Priority and ACK marks high-reliability critical events.

Example

0xC7 = Priority+ACK BEL = critical alert requiring confirmation. Receiver must ACK before the sending system considers the alert delivered. Maximum reliability for critical state changes.

111 — All Flags (P+A+C) ▾ 0xE0–0xFF Emergency with confirmation and detail sequence. Maximum event weight. NO*
Behaviour

Byte values 224–255. All three flags set. Emergency-level event requiring confirmation, with a continuation sequence following to deliver the detail. The highest-weight event form in the protocol.

Protocol Flow

Receiver drops all normal queue processing. Handles at emergency level. Must ACK the opening event. Reads continuation bytes. The full sequence constitutes the emergency record. Receiver may trigger hardware interrupt or failsafe.

Example

0xE7 = All-flags BEL = full emergency alert, confirmation required, detail sequence follows. In a spacecraft: triggers immediate safing mode entry, transmits full fault record in the continuation sequence, requires ground ACK before system can resume.
Stream Decoder / Simulator

Enter hex bytes separated by spaces (e.g. 16 96 16 86 04 84). Decoder shows C0 identity, flag states, and both legacy and BitPads interpretations.

Enter hex bytes above and click Decode Stream.

Advanced Capability

Component Escalation — Field 101

Enhancement field 101 (Priority + Continuation, no ACK) at a stream signal slot triggers Component Escalation: the delivery of a full BitPads Record within the active stream. This is the most significant capability of the Enhancement Sub-Protocol — embedding a complete Record, with all its structure and components, inside a Telegraph stream.

What this enables: A stream can deliver a fully identified, timestamped, valued record inline — without interrupting the stream. The outer stream resumes immediately after the embedded record. No new session. No stream break. The embedded record can itself be a BitLedger transaction with conservation-verified double-entry accounting.

Parser Stack Operation

When the decoder encounters a byte with flags=101 (Priority+Continuation) at a declared signal slot, the parser stack mechanism activates:

COMPONENT ESCALATION — PARSER STACK OPERATION
──────────────────────────────────────────────────────────
 
Step 1 Detect byte with flags=101 at declared signal slot
Step 2 Save current ParserStateFrame (stream state, codebook, position)
Step 3 Push frame onto parser stack
Step 4 Begin reading inner Record from current byte position
(full Meta byte, Layer 1 if new session, all components)
Step 5 Inner Record parsed completely as a BitPads transmission
(may itself trigger further escalation, up to max depth)
Step 6 Inner Record reaches natural close (ETX / EOT / length end)
Step 7 Pop top frame from parser stack
Step 8 Restore all state from frame (stream position, codebook, etc.)
Step 9 Outer stream resumes from resume_position
 
──────────────────────────────────────────────────────────
Outer stream continues as if inner record was a single signal event.

Parser Stack — Before / After Diagram

Before Escalation
Outer Stream
Category 1110 · Codebook 01
Position: byte 47
(empty)
→
During Inner Record
Inner Record
Parsing: Meta + L1 + Value
Current parser position
Outer Stream [saved]
Category 1110 · Codebook 01
Resume: byte 47
→
After Escalation
Outer Stream [restored]
Category 1110 · Codebook 01
Resuming from byte 47
(empty — frame popped)

Example Byte Sequence

EMBEDDED RECORD EXAMPLE — BYTE SEQUENCE
──────────────────────────────────────────────────────────
 
Outer stream body continues:
... 0x16 SYN heartbeat — normal stream idle
... 0xBC flags=101 FS at P11 signal slot → ESCALATION TRIGGER
 
Inner Record begins (parser stack pushed):
[0] 0x01 SOH — inner Record Meta byte 1 (Record mode)
[1] 0x80 Meta byte 2
[2-6]Layer 1 bytes (sender ID, session flags)
[7+] Layer 3 value, time, task, note components
[N] 0x03 ETX — inner Record close
 
Outer stream resumes (parser stack popped):
... 0x16 SYN heartbeat — stream continues as if uninterrupted
──────────────────────────────────────────────────────────

Signal Architecture

Signal Slot Positions in Telegraph Streams

When the Session Enhancement Flag (Layer 1 bit 12) is active alongside category 1110, both the 13 signal slot positions P1–P13 and the stream's enhanced byte content are simultaneously available. How do these interact?

SlotsScopeOperation in Category 1110
P1–P3 Session layer Operate at session level, before and after the stream. P1 fires at session open before any stream content. P3 fires at session close. P2 is the session-boundary slot between consecutive streams.
P4–P8 Record layer Available when a full BitPads Record is embedded in the stream via Component Escalation (field 101). These slots operate within the inner Record's structure — pre-value, post-value, pre-task, post-task, note slots.
P9–P10 Batch layer Batch boundary slots. Active when the stream is part of a batch context. P9 fires at batch open, P10 at batch close.
P11 Stream layer The stream-open slot position. Fires at the point where the stream body begins — immediately after the Stream-Open Control byte. This is where the Component Escalation trigger is most commonly declared for stream-level embedded records.
P12–P13 Wave / inline Available in Wave mode with Extended Flags set. In the context of Category 1110, P12 and P13 can be used for pre-stream and post-stream inline signals at the transmission boundary.

Key principle: Within the stream body itself, every byte is an enhanced C0 byte — the signal slot architecture becomes the stream content itself. The two mechanisms combine rather than conflict. Session-scoped signal slots operate at their declared positions; the stream content carries the byte-level enhancement grammar throughout.

Stream Termination

Stream Close Mechanics

Three distinct mechanisms close a Telegraph Emulation stream. Each produces a different outcome for the session and channel state.

Close Method 1 — Length Exhausted
Type: Automatic length-prefixed close
Trigger: Stream body byte count reaches declared length
Effect: Stream closes silently. Parser returns to pre-stream state.
Session: Remains open. Next transmission can begin immediately.
Example: 0x1E [stream-open] [length=0x0A] ... [10 stream bytes] → CLOSE
Close Method 2 — EOT Byte
Type: End-of-Transmission signal
Trigger: Any EOT form in the stream body
 
0x04 = 000 00100 Plain EOT → stream close, no confirmation
0x44 = 010 00100 ACK EOT → confirmed close, receiver must ACK
0x24 = 001 00100 Continuation → stream SUSPENDS, will resume
0xC4 = 110 00100 Priority+ACK → urgent confirmed close
0xE4 = 111 00100 Full EOT → emergency confirmed close with detail
 
Session: Depends on EOT form. ACK EOT waits for receiver ACK before tearing down.
Close Method 3 — New Meta Byte
Type: New session open detected
Trigger: Byte 0x01 (SOH) detected — the context-free session-open signal
Effect: Current stream abandoned. Parser treats 0x01 as new session open.
Warning: Any in-flight stream data is discarded. Emergency use only.
Session: New session begins from the 0x01 byte. Layer 1 read begins.

Compatibility Analysis

Legacy Receiver Perspective

A legacy teleprinter or ASCII terminal receiving a Category 1110 Telegraph Emulation stream. The same 15 bytes. What the legacy device sees and does.

LEGACY RECEIVER — STREAM DECODE
──────────────────────────────────────────────────────────────────────────────
Byte Hex Binary Legacy Device Sees Legacy Action
──────────────────────────────────────────────────────────────────────────────
1 0x16 000 10110 SYN (0x16) Synchronise idle
2 0x96 100 10110 Extended char – (Latin-1) Display or ignore
3 0x07 000 00111 BEL (0x07) Ring bell / alert
4 0xC7 110 00111 Extended char Ç (Ç) Display character Ç
5 0x04 000 00100 EOT (0x04) End transmission signal
6 0x44 010 00100 ASCII 'D' (0x44) Display character D
7 0x16 000 10110 SYN (0x16) Synchronise idle
8 0x1C 000 11100 FS (0x1C) File separator
9 0x9C 100 11100 Extended char œ (Latin-1) Display or ignore
10 0x02 000 00010 STX (0x02) Start of text marker
11 0xBC 101 11100 Extended char ¼ (¼) Display character ¼
12 0x06 000 00110 ACK (0x06) Acknowledge signal
13 0xE7 111 00111 Extended char ç (ç) Display character ç
14 0x16 000 10110 SYN (0x16) Synchronise idle
15 0x04 000 00100 EOT (0x04) End transmission — stream closed
──────────────────────────────────────────────────────────────────────────────
Legacy receiver: no errors, no protocol violations. Standard C0 stream.

The legacy receiver sees bytes 0–31 as their standard C0 controls (which execute normally), and bytes 32+ as printable characters (which are displayed or ignored). The stream is fully functional for legacy devices. BEL rings. EOT closes. SYN synchronises. The rich BitPads event layer is invisible to legacy hardware.

Full Decode

BitPads Receiver Perspective

Same 15-byte stream. BitPads receiver. Every byte decoded for flags, C0 identity, event name, and response requirements.

BITPADS RECEIVER — FULL STREAM DECODE
──────────────────────────────────────────────────────────────────────────────────────
Byte Hex Legacy View BitPads View
──────────────────────────────────────────────────────────────────────────────────────
1 0x16 SYN — sync idle SYN, flags=000 — keep-alive pulse, no response
2 0x96 [extended char] SYN, flags=100 (Priority) — priority pre-announce
3 0x07 BEL — bell / alert BEL, flags=000 — standard alert, no response required
4 0xC7 [extended char Ç] BEL, flags=110 (Priority+ACK) — CRITICAL ALERT, ACK required
5 0x04 EOT — end transmission EOT, flags=000 — stream close signal
6 0x44 D — printable letter D EOT, flags=010 (ACK) — confirmed close, ACK back required
7 0x16 SYN — sync idle SYN, flags=000 — heartbeat, normal cadence
8 0x1C FS — file separator FS, flags=000 — file boundary event
9 0x9C [extended char] FS, flags=100 (Priority) — priority file boundary
10 0x02 STX — start of text STX, flags=000 — stream content marker
11 0xBC [extended char ¼] FS, flags=101 (P+C) — COMPONENT ESCALATION at P11
12 0x06 ACK ACK, flags=000 — acknowledgement signal
13 0xE7 [extended char ç] BEL, flags=111 (P+A+C) — EMERGENCY, ACK + detail seq
14 0x16 SYN — sync idle SYN, flags=000 — heartbeat resumed
15 0x04 EOT — end transmission EOT, flags=000 — stream close
──────────────────────────────────────────────────────────────────────────────────────
BitPads receiver: 15 typed events decoded. 4 requiring responses. 1 component escalation.

The contrast in a single pair: Byte 4 (0xC7) — the legacy receiver displays "Ç". The BitPads receiver triggers a critical alert handler, queues an ACK byte for transmission, logs the event with timestamp, and may trigger a hardware interrupt. Same byte. Two complete and non-conflicting interpretations.

The richness of the decoded event stream vs the legacy view demonstrates why Telegraph Emulation Mode is named for its heritage. The same wire carries two simultaneous communication layers — one for backward compatibility with equipment from 1970, one for modern binary-native systems requiring typed event streams with priority, confirmation, and continuation semantics.