Guide ECU & Remapping · Bytes & tables

How Byte Data Becomes a Synthetic Table

Learn how a chosen byte offset and dimensions arrange values into a table, and how map tools represent supplied data without confirming ECU map meaning.

By Adam Johnston Published by Hex Labs 4 min read

After learning bytes, hexadecimal notation and offsets, the next question is how a sequence can be displayed as a table. The dimensions and starting position are choices supplied by a person. A rectangular display can help inspect data, but it does not prove that the values came from a map or reveal their physical meaning.

From supplied bytes to a table

Hex bytes at zero-based decimal offsets become a rectangular view only after a user chooses a range and dimensions.

Raw sequence

  1. Offset 0 10 Outside range
  2. Offset 1 20 Outside range
  3. Offset 2 30 Selected
  4. Offset 3 40 Selected
  5. Offset 4 50 Selected
  6. Offset 5 60 Selected
  7. Offset 6 70 Outside range
  8. Offset 7 80 Outside range

Selected range

Start at zero-based offset 2; take 4 consecutive bytes through offset 5.

  1. Offset 230
  2. Offset 340
  3. Offset 450
  4. Offset 560

The starting offset and range are supplied by the user.

Dimensions

2 rows × 2 columns

4 cells use the selected values in order, row by row.

Table view

Selected bytes at Offsets 2–5 shown in 2 rows and 2 columns; each cell includes its source offset.
RowColumn 1Column 2
1 Offset 230Offset 340
2 Offset 450Offset 560
The user-selected offset and dimensions determine this arrangement. Values remain traceable by offset in row-major order; this demonstrates table shaping, not ECU map discovery or identification.
Text equivalent

The synthetic sequence has 8 bytes at zero-based offsets 0 through 7: 0: 10; 1: 20; 2: 30; 3: 40; 4: 50; 5: 60; 6: 70; 7: 80. The selected range is Offsets 2–5, containing 30 40 50 60. The 2-row by 2-column table uses those values in order, row by row; each table cell repeats its source offset.

The same bytes can produce other valid views at different offsets or dimensions. None proves the values’ ECU meaning.

What the tools do

The Map Extractor validates supplied hex or decimal byte values and applies user-selected dimensions. It formats a bounded rectangle; it does not find semantic map boundaries. It can export CSV or JSON and hand the values to Map Viewer. The handoff does not preserve the source file’s absolute offset.

The Map Viewer displays supplied values as a table and supports local input/recent-map storage, in-session undo/redo history, and CSV, JSON or SVG downloads. Its share link places values and labels in the URL, so recipients and browser history can read them; links are not private and have an 8,000-character limit. A visually regular table is still only arranged input data. The view does not write modified values back into an original binary or establish a table’s identity.

The Map Definer takes supplied bytes, a start offset and dimensions, with optional names and row/column labels. It previews a selected definition and can output definition JSON or hand values to Map Viewer. This is explicit user-provided context, not automatic map discovery. Any labels or axes are metadata; Hex Labs does not independently verify that they correspond to engine parameters.

Transforming values is still arithmetic

The Map Scale Adjuster accepts rectangular rows of unsigned decimal integers from 0 through 255. For a non-negative percentage p, it calculates value × p / 100; in offset mode it calculates value + offset, where the finite offset may be positive, negative or fractional. It rounds the calculation to a whole integer, then clamps the result to 0–255.

InputOperationCalculationOutput
40110%40 × 1.10 = 4444
41110%41 × 1.10 = 45.1 → 4545
250110%250 × 1.10 = 275 → 275255, clamped
3offset −53 + (−5) = −2 → −20, clamped

This operation does not interpret signed encodings, multi-byte values, byte order, map axes or ECU units. A transformed table cannot tell us whether those values or operations are appropriate in any real calibration.

Candidates and profiles provide different context

Map Finder scans byte windows using selected dimensions, an inclusive minimum/maximum byte range, and optional repeated-row and monotonic-row filters. A returned candidate means that window matched the selected conditions. False positives are expected: the match does not confirm a map, axes, purpose or compatibility. A candidate can be previewed or handed to the Viewer or Extractor for further inspection, which still does not establish its meaning.

Map Profile Loader takes a supplied profile schema and supplied bytes. The profile describes offset-addressed maps with dimensions and optional labels or display metadata; the tool checks that selected ranges fit the byte sequence and presents the interpretation. It does not infer a profile from bytes. The JSON emitted by Map Definer describes a selected table and is a different format from the profile JSON accepted by Map Profile Loader; they are not directly interchangeable.

Keep the workflow educational

For a synthetic exercise, move from a known byte sequence and offset to a bounded region, choose dimensions, view the resulting table, optionally add clearly identified labels, and demonstrate arithmetic or schema interpretation. This workflow teaches representation and assumptions. It does not identify arbitrary ECU maps, verify a file, establish vehicle compatibility, or validate calibration safety.

Continue in the ECU Data & Calibration Concepts course, beginning with Working with Raw ECU Files, then the lessons on synthetic tables and byte-table scaling.

Privacy preferences

This setting controls Hex Labs Google Analytics only. It does not control Google advertising consent. No ads are currently loaded.