PACTOR-4

One protocol, several physical layers

Chirp, robust, normal

PACTOR-4 extends the PACTOR ARQ family, but its normal waveform is different from PACTOR-3’s parallel carriers. A normal P4 packet carries symbols on one carrier at 1800 symbols/s. Robust packets spread a slower differential symbol across 8 or 16 chips at that same chip rate. Chirp mode uses two sweeping carriers with a different symbol clock.

The robust short renderer’s explicit geometry is 20 header symbols + 1 phase reference + 64 block symbols, all spread by 16: 1360 chips, or 755.556 ms before shaping. Its measured 64-symbol block is a masked Hadamard code carrying a six-bit value, rather than an ordinary user-data field. The value’s relative coding is established; assigning it a protocol meaning is a separate task.

A 27-symbol SF16 control word has 432 chips, 240 ms before shaping. The measured word bank contains distinct response and break-in patterns; these should not be silently replaced by a generic Chu-sequence template. Nominal geometry and a recovered word are different kinds of evidence.

Exact ideal coordinates

Constellation geometry

These are the label-ordered coordinates used by the normal-LONG diagnostic implementation. They are generated from the code, not taken from a received recording. Each signed integer axis is divided by 4096. The 16- and 32-point QAM geometries are specific constructions, not generic square grids.

The PSK labels use a Gray phase walk. The 32-QAM construction combines an inner grid with fixed outer points; its three-decimal pre-rounding reproduces the implemented integer table. That is an inferred compatibility rule, not a claim about the original manufacturer’s quantizer.

Net bytes include one status byte and two CRC bytes. Data-field capacity still includes any source-coding or application overhead. Short packets at SL5 and SL6 share the 43-byte BPSK variant; the measured 206-byte normal-LONG BPSK path is a different rate-1/3 variant. Body modulation alone cannot distinguish all packet variants.

A channel estimate between blocks

Training and frame layout

The implemented normal layout uses 32 symbols of training before each data block and an additional terminal training. A short body has six 176-symbol blocks; a long body has twenty-four 207-symbol blocks. This figure starts at the first training symbol. It excludes the packet header and shaping tails.

The training sequence is C[9…16], C[1…16], C[1…8] from a 16-symbol CAZAC sequence, giving 32 symbols. Successive trainings alternate the base sequence and its conjugate. The receiver uses these known values to estimate and equalize the channel; a good training fit alone is not a packet acceptance test.

The published normal-mode pulse is retained as an exact 129-tap array. P4’s recovery helpers use 28800-Hz complex baseband, 16 samples per chip. Their matched-filter delay is 128 samples. At the audio interface, waveform renderers resample to the requested audio rate.

The renderers use measured 140-chip headers. Their nominal pulse-inclusive emission spans are 792.778 ms for SHORT and 3.286111 seconds for LONG; resampling produces the exact audio sample counts shown above. Those durations fit within short and long ARQ cycles of 1.25 and 3.75 seconds; the cycle also includes gaps and the response slot. The page does not equate emission duration with payload throughput.

The normal headers in these renderers were measured chip by chip. Their semantic interpretation remains incomplete. Reproducing a header does not prove that a peer will accept what a newly rendered packet claims.

Bits before symbols

Turbo coding

The turbo code retains the systematic input bits and adds parity from two eight-state recursive systematic convolutional components. C1 sees the bits in their original order. C2 sees the same bits in its own input permutation. After parity selection and packing, a separate symbol permutation controls placement in the waveform.

1. Net fieldData + status + little-endian CRC; whiten the complete byte field.
2. C1 and C2Two components from explicit initial states. Only C2 gathers the permuted input.
3. Pack and mapKeep systematic bits; select parity, assign labels, then permute symbols.
4. Shape the signalInsert training and headers; spread where required; apply the exact pulse.

state = (s1, s2, s3), newest delay first
u = input XOR s2 XOR s3
parity = u XOR s1 XOR s3
next state = (u, s1, s2)

C1 input[j] = systematic[j]
C2 input[j] = systematic[pi2[j]]

The zero-state transfer is (1 + D + D³) / (1 + D² + D³). Calling the encoder with an octal polynomial pair would leave important conventions unspecified: register ordering, feedback, parity order, state initialization and termination all matter.

At rate 1/2, the implementation keeps C1[0::2] and C2[1::2]. At rate 5/6 it keeps C1[0::10] and C2[4::10]. These are indexed from the start of each component stream. Packet paths define how the tail and padding fit around that selection.

Normal-short BPSK expands a 43-byte net field into 352 systematic bits: 344 field bits, five zero bits and three inputs terminating the first component. Both components start from zero, but C2 is not independently terminated. Full rate-1/3 packing yields 1056 coded bits, one per BPSK body symbol. This is not VARA’s 12-bit dual-tail convention.

An exact table without a literal array

Symbol and component permutations

C2’s input permutation changes which systematic bit enters the second encoder at time j. The symbol permutation acts later, after coding and mapping. Inverting either order changes the operation. A size such as 1056 can appear in both systems without meaning that the two tables are interchangeable.

Canonical u16-LE SHA-256: a96675e46a0e83610c759bf188b1a1829f5ad1bea64c58b79eb7e599624ed0cb

Runtime reconstruction starts with w = isqrt(N), concatenates range(r, N, w) for r = 0…w−1, then applies ordered index swaps from the compact resource. The constructor checks resource hashes, index bounds, the bijection and the canonical unsigned-16-bit little-endian permutation hash before use.

All thirteen supported tables, including 1160, are exactly reconstructible. The 1160 resource has 22 corrections. These corrections describe the final table relative to the arithmetic walk; they are not a recovered random generator-state doping recipe or the original generator’s accepted-swap trace.

Twelve original CML construction recipes are separately reproducible. They require seeds, prior constructor calls, continuous random state, the neighborhood rule and the accepted-swap budget. The original 1160 seed/history is still unresolved. Some large runtime tables need nearly N swaps: “compact” describes their representation, not a promise that every table differs from the base at only a few positions.

The normal-LONG symbol order is a 24-by-207 product of the published walks: row walk (24, 5) and column walk (207, 23). Normal-SHORT uses a 24-by-44 product with column walk (44, 22). Those 4968- and 1056-symbol tables are generated arithmetically and remain distinct from the C2 input tables.

C2 table construction

PRNG state and call history

Twelve of the thirteen runtime C2 sizes have recovered CML recipes. A recipe specifies the seed, ordered constructor calls, spread parameter and accepted-swap budget. The 1160-entry table is exact at runtime; its original seed and call history remain unresolved.

The two recurrence moduli are 2147483563 and 2147483399, with multipliers 40014 and 40692. The shuffle result is scaled in double precision and clamped to 1 − 1.2e−7. Integer modulo is not an equivalent position selector.

The first seed-99 call is discarded, but cannot be skipped. The recovered recipes use 20N accepted swaps; upstream CML defaults to 10N. These are offline table constructors, separate from the per-packet whitener and from the stored swaps used by the runtime.

Exact recurrence, initialization and acceptance rules · All thirteen runtime tables, twelve recovered recipes and verification commands

A CRC boundary, then a host boundary

Packet framing and status

The net packet is source-coded data, one status byte and two little-endian CRC-16/X-25 bytes. Whitening covers that complete byte field and resets for every packet. The implementation XORs the register’s low byte, then advances eight right-shift Galois steps using seed 0x00B770CD and feedback 0x48000000. Channel-code tails are outside that byte transform.

Bit 7      Bits 6–5       Bits 4–2        Bits 1–0
E          S1 S0          M2 M1 M0        C1 C0
extended   protocol       source mode    packet counter

The two protocol bits form one enumeration, not two independent PACTOR-3 flags. The implementation names normal, CLOSE, CHANGEOVER and speed-up values; the speed-up meaning lacks a recorded instance. Header type, packet status, receive timing and the session state must agree before a field can authorize an acknowledgement.

A CRC-valid field still contains source-coded bytes. It is not automatically a Winlink message. Extended status does not authorize removing an unknown prefix. One bounded recorded extension is handled explicitly; other unrecognized extensions remain refused. The raw frame is preserved independently of any host transformation.

The turn machine separates proposals from actual emissions: queued bytes advance on a keyed result, and settlement requires accepted associated response evidence. Waveform detection, CRC acceptance, ARQ acknowledgement, host delivery and completed mail transfer are separate outcomes.

What has been established

Implementation coverage

The project has live PACTOR-4 signaling observations, retained foreign waveform decodes and packet-specific round trips. Normal-short and normal-long BPSK paths have CRC-valid recorded examples. Chirp framing is checked against four retained Dragon fields. Higher-order normal-short paths have recorded checks; the normal-LONG SL6–10 module shown above is a standalone diagnostic path.

Those results do not establish complete live PACTOR-4 mail delivery or full interoperability across every packet family. The current offline replay reaches a CMS prompt and sends a B2F login/proposal. The implementation evidence describes that narrower result separately from demonstrated PACTOR-3 mail exchanges.

Measured normal-header semantics remain incomplete. Robust-word names and timings are backed by particular observations; their presence is not a complete specification of every control transition. Source framing and fill include documented assumptions. Live receiver dispatch, acknowledgement eligibility, deadline budgets and every higher-rate transmit path require their own evidence.

The geometry on this page remains ideal and code-derived. The constants do not establish interoperability at every speed level.

Reproduce the implementation

Protocol and source references

The detailed notes identify literal arrays, generators, resources, bit order, framing and remaining assumptions. Built source links stay local to this release.

The linked protocol notes cite SCS’s technical description, including its published modulation, training, pulse and coding sections. Derived implementation conventions and measured interpretations are identified separately.