Reading a TIX Clock — the Encoding

A TIX clock keeps its secret in plain sight. The face is lit, the pattern is obvious, and a first-time viewer still cannot read it — because the one instruction they are missing is the whole of the encoding: count the lit cells; ignore where they are. Vol 1 stated the rule in a sentence and a figure; this volume takes it apart properly. We define the count-not-position rule rigorously, walk the four colour fields and why each is the size it is, map a time to four counts and back with a fistful of worked examples, and then justify the single most surprising property of the clock — that it can scramble its own display every minute and still tell the same time. We close with an information-theory aside that explains, with numbers, why a TIX clock “wastes” most of its LEDs, and why that waste is exactly the point.

Everything here is about the reading. The physical grid of LEDs and its diffusion are Vol 3; the firmware that chooses which cells to light is Vol 5. This volume is the contract between them: the rule both must honour for the clock to mean anything.

2.1 The count-not-position rule, stated rigorously

Let a field be a fixed set of n LED cells of one colour. At any minute some subset of those cells is lit. Write k for the number of lit cells — the count. The encoding is:

The digit a field displays is k, the number of its cells that are lit. The identity of which cells are lit carries no information whatsoever.

Formally, two lit-cell patterns P₁ and P₂ in the same field are equivalent — they display the same digit — if and only if |P₁| = |P₂|, that is, if they have the same number of lit cells. Their positions, their adjacency, their left-or-right arrangement: all irrelevant. A field of n cells therefore has exactly n + 1 distinguishable states (counts 0, 1, 2, …, n), no matter how many physical arrangements — 2ⁿ of them — those states are spread across.

This is the formal sense in which a TIX clock is unary, or base-1: a digit d is represented by d tally marks (lit cells), and you read it by tallying. It is not a binary clock. A binary clock assigns each LED a positional weight (8, 4, 2, 1) and you read the pattern; move one LED and the value changes. A TIX field assigns every cell the same weight — one — so the pattern is free to change without the value changing. That single difference (weight-by-position vs weight-all-equal) is the clock’s entire personality, and §2.4 shows what it buys.

2.2 The four fields: colour, size, digit, range

A 24-hour time is four decimal digits, H₁ H₀ : M₁ M₀. TIX gives each its own field, in reading order left to right, and colours each field distinctly so four counts never blur into one. The collected builds — gweeds’ DIY TiX and ujjaldey’s uTixClock — both use the same scheme of yellow / red / blue / green and the same 3 / 9 / 6 / 9 cell counts, for 27 LEDs total.¹²

Table 1 — 2.2 The four fields: colour, size, digit, range

#	Field (colour)	Cells	Digit	Range it must cover	Why this size
1	yellow	3	tens of hours H₁	0–2	largest value is 2 (the “2” of 23h)
2	red	9	units of hours H₀	0–9	largest value is 9
3	blue	6	tens of minutes M₁	0–5	largest value is 5 (the “5” of :59)
4	green	9	units of minutes M₀	0–9	largest value is 9

The sizing rule is simple and worth stating because it is the only reason the field sizes look irregular: each field has exactly as many cells as the largest digit it ever needs to show. A unary field of n cells can display 0…n, so to show a maximum digit d you need n = d cells — no more (the extra cells would never light), no fewer (you could not reach d).

• Tens of hours in 24-hour time runs 0, 1, 2 only (00–09h → 0, 10–19h → 1, 20–23h → 2), so its maximum is 2 and it needs 3 cells. (Three cells, max count 3, so the state “3” is unreachable and unused — a deliberate spare, since the digit never exceeds 2.)
• Units of hours runs 0–9, maximum 9, needs 9 cells.
• Tens of minutes runs 0–5 (minutes are 00–59), maximum 5, needs 6 cells.
• Units of minutes runs 0–9, maximum 9, needs 9 cells.

Hence 3 / 9 / 6 / 9. The colours are a reading aid, not part of the maths: with four counts to take in at a glance, distinct hues let the eye segment the face into fields without rules or gaps doing the work (Vol 3 covers colour choice and the square-cell look).

2.2.1 The 12-hour variant: 1 / 9 / 6 / 9

Drop to a 12-hour face and only the first field changes. Hours then read 1–12, so the tens-of-hours digit is only ever 0 (for 1–9 o’clock) or 1 (for 10, 11, 12) — maximum 1, needing just 1 cell. The layout becomes 1 / 9 / 6 / 9, a 25-LED clock. The other three fields are identical because units-of-hours (now 0–9, e.g. the “2” of 12), tens- and units-of-minutes are unchanged. The collected builds are both 24-hour, so 3/9/6/9 is the layout this series carries throughout; the 12-hour case is noted for designers laying out their own face (Vol 3).

2.3 Mapping a time to four counts, and reading one back

The encoding is a two-way street. To encode a time, split it into its four digits and light that many cells in each field. To decode, count and concatenate.

Encoding HH:MM → counts:

1. H₁ = ⌊HH / 10⌋ → light H₁ of the 3 yellow cells.
2. H₀ = HH mod 10 → light H₀ of the 9 red cells.
3. M₁ = ⌊MM / 10⌋ → light M₁ of the 6 blue cells.
4. M₀ = MM mod 10 → light M₀ of the 9 green cells.

Decoding (the fluent reading technique) is the reverse, and it is genuinely fast once the colours are learned. Scan left to right by colour, and at each field do one thing — count:

1. Yellow — count lit cells → tens of hours.
2. Red — count lit cells → units of hours.
3. Blue — count lit cells → tens of minutes.
4. Green — count lit cells → units of minutes.

Then concatenate: (yellow)(red):(blue)(green). No place-value arithmetic, no weighting — four small counts, each 0–9, read off in order. With practice you stop counting the larger fields one-by-one and start recognising small quantities at a glance (the perceptual trick called subitising handles up to four or five lit cells without deliberate counting), so a TIX clock becomes nearly as quick to read as numerals once the colour order is reflex.

2.3.1 Worked examples

The five canonical examples below are taken directly from the uTixClock source’s own worked cases, written here as aY bR cB dG = “a yellow, b red, c blue, d green cells lit”.² The last two are the extremes of the range.

Table 2 — 2.3.1 Worked examples

Lit counts	H₁ H₀ : M₁ M₀	Reads	Note
0Y 0R 0B 0G	0 0 : 0 0	00:00	midnight — see the quirk in §2.5
0Y 1R 1B 2G	0 1 : 1 2	01:12	one red, one blue, two green
1Y 1R 3B 9G	1 1 : 3 9	11:39
1Y 6R 2B 4G	1 6 : 2 4	16:24	the Vol 1 hero time
2Y 3R 4B 7G	2 3 : 4 7	23:47
2Y 3R 5B 9G	2 3 : 5 9	23:59	the maximum — every field near full
0Y 0R 0B 0G	0 0 : 0 0	00:00 (blank)	the minimum — every field dark

Work one by hand. 16:24: tens-of-hours ⌊16/10⌋ = 1 → 1 yellow; units-of-hours 16 mod 10 = 6 → 6 red; tens-of-minutes ⌊24/10⌋ = 2 → 2 blue; units-of-minutes 24 mod 10 = 4 → 4 green. So 1Y 6R 2B 4G, exactly the count in the table. Reading it back is the same steps in reverse: see one yellow, six red, two blue, four green → 1 6 : 2 4 → 16:24.

The maximum the clock can ever show is 23:59 = 2Y 3R 5B 9G — two of three yellow, three of nine red, five of six blue, nine of nine green. No field is ever fully lit and maximal at once except green; the blue field at its maximum shows 5 of 6, the yellow shows 2 of 3, because those fields carry a deliberate spare cell (§2.2). The minimum is 00:00, all fields dark — which, on the shipped uTixClock, is exactly what midnight looks like (§2.5).

2.4 Randomisation as the reader experiences it

Here is the property that makes a TIX clock more than a colour-coded tally. Because position carries no information (§2.1), the firmware is free to choose which cells light up to reach each field’s count — and it re-rolls that choice every minute.² A reader watching 16:24 for its full minute sees one frozen arrangement; come back at 16:25 and not only has green ticked from 4 to 5, but the whole face has reshuffled, every field’s lit cells flung to new positions even where the count did not change.

Make this concrete. The units-of-minutes field is 9 cells showing, say, 4. The number of ways to choose which 4 of 9 cells are lit is

C(9, 4) = 9! / (4! · 5!) = 126

so “units = 4” alone has 126 distinct faces. Multiply across all four fields and a single time like 16:24 — C(3,1) · C(9,6) · C(6,2) · C(9,4) = 3 · 84 · 15 · 126 = 476 280 distinct lit-cell arrangements, every one of them reading 16:24. The clock will, quite literally, almost never show you the same face twice for the same minute.

Why a binary clock cannot do this. In a binary field the LEDs are weighted 8-4-2-1 and the value is the pattern: light the 8-cell and the 4-cell and you have 12; move either lit cell to a different position and you have a different number (or nonsense). There is exactly one valid arrangement per value, so a binary clock has nothing to randomise — its display is pinned. A TIX field, weighting every cell equally, has C(n, k) valid arrangements for the value k, and the randomiser is free to walk among them at will. The shuffling is not a gimmick bolted on; it is a direct consequence of choosing a count encoding over a positional one. (Vol 5 covers how the firmware actually draws the random subset each minute.)

This is why §2.1 insists the rule be stated as an equivalence: the clock treats all C(n, k) arrangements of a count as the same display, and exploits that equivalence as its signature visual effect. The randomness is the encoding wearing its inefficiency proudly.

2.5 Edge cases and unambiguity

Counts are never ambiguous. Because a field’s value is just “how many are lit,” there is no pattern to misparse — no leading-zero confusion, no orientation to get wrong, no two values that share an arrangement. Every face maps to exactly one time, and the only way to misread it is to miscount. The fields’ fixed colours and sizes mean even a half-lit display is unambiguous: three of nine red is always 3, wherever the three sit.

The blank-midnight quirk. At 00:00 all four digits are zero, so every field is dark and the entire face goes blank — there is genuinely nothing lit. On the shipped uTixClock build this is a known quirk: midnight reads as an unlit clock rather than, say, a deliberate “all cells briefly flash” indicator, so for one minute a powered, working clock is indistinguishable from an unpowered one.² It is harmless (00:01 lights a single green cell and the face returns) but worth knowing before you assume a dark clock has lost power. The source documents the behaviour but not a workaround; designing one (a heartbeat cell, or showing 00:00 as a brief full-face test) is left to the builder and noted in Vol 5.

The near-full 23:5x cases. At the top of the range the face is dense: 23:5x lights two of three yellow, three of nine red, five of six blue, and the green field marching 0→9 through the final ten minutes of the hour. 23:59 (2Y 3R 5B 9G) is as full as the clock ever gets — and is a good calibration face, because if green ever reads 10 (impossible — only 9 cells) or blue reads 6 (impossible at any real minute — tens-of-minutes never exceeds 5) you have a wiring or firmware fault, not a time. The unused states (yellow’s “3”, blue’s “6”) are useful precisely as impossible readings: they should never appear, and if they do, something is wrong (Vol 5).

2.6 An information-theory aside: the productive waste

A TIX clock spends 27 LEDs to show a time that a four-digit numeric display shows in four characters, and it is worth seeing how extravagant that is, because the extravagance is the aesthetic.

A field of n cells using a unary count has n + 1 states and therefore carries

log₂(n + 1) bits

of information, regardless of its n physical LEDs. The 9-cell red field carries log₂(10) ≈ 3.32 bits but spends 9 LEDs to do it. A positional binary code would carry those same ~3.32 bits in 4 LEDs (4 bits = 16 states ≥ 10); a BCD seven-segment digit uses 7 segments but each segment is positional, so it too beats unary on LED count for the larger digits. Unary is the least dense encoding there is — it spends one LED per unit of value — and that is the deliberate trade: the “wasted” cells are the slack the randomiser plays in (§2.4). A denser code would be unshuffleable.

Tally it across the whole clock: 27 LEDs carry, at most, log₂(3+1) + log₂(9+1) + log₂(5+1) + log₂(9+1) = 2 + 3.32 + 2.58 + 3.32 ≈ 11.2 bits — and a day has 1440 minutes, needing only log₂(1440) ≈ 10.5 bits, so the clock’s encoding is even a little more wasteful than the fields’ raw capacity suggests (the impossible states — yellow 3, the unreached high counts — account for the slack). A purely positional binary clock shows all 1440 minutes in 11 LEDs. TIX uses 27. The 16 “extra” LEDs buy nothing but the count-not-position aesthetic and the half-million reshufflings of §2.4 — which, for a desk object whose entire job is to be quietly interesting, is a bargain.

The table below shows the same single digit — a units digit of value 6 — rendered three ways, to make the density difference tangible.

Table 3 — 2.6 An information-theory aside: the productive waste

Encoding	How “6” is shown	Cells used	Cells lit for “6”	Position carries info?
TIX (unary count)	6 of 9 same-weight cells lit, anywhere	9	6	no — count only
Binary (positional)	weights 8-4-2-1 → light 4 and 2	4	2	yes — pattern is the value
7-segment (BCD)	segments a,c,d,f,g lit (the glyph “6”)	7	5	yes — each segment is a fixed place

FIGURE SLOT 2.4 — A real photograph of a finished TIX clock face lit at a legible time, ideally one of the collected builds, to anchor the abstract encoding in a physical object. License-clean source hint: the gweeds DIY TiX or ujjaldey uTixClock Instructables pages own their build photos (reference, not reproduce); otherwise a Wikimedia Commons / Openverse search for “TIX clock” via the Photo Helper, credited verbatim.

2.7 Summary — the encoding in five lines

• A TIX clock shows 24-hour HH:MM as four colour fields; the count of lit cells in each is one digit, and the positions are meaningless.
• The fields are yellow / red / blue / green, sized 3 / 9 / 6 / 9 to their largest digit (a 12-hour face is 1 / 9 / 6 / 9); 27 LEDs in the collected 24-hour builds.
• Read left-to-right by colour: count, count, count, count → (Y)(R):(B)(G).
• Because position is information-free, each count has C(n, k) valid faces, so the firmware re-rolls the arrangement every minute — something a positional binary clock cannot do.
• The encoding is deliberately unary (most LEDs are “wasted”); that inefficiency is the slack the randomiser lives in, and the whole aesthetic of the clock.

The physical display that these counts live on — the LED grid, the colours, the square cells and diffusion — is Vol 3; the firmware that computes the four counts and draws the random subset each minute is Vol 5.

2.8 References (Vol 2)

Footnotes

1. DIY TiX Clock by gweeds (Guido Seevens), Instructables, 2011 — AVR (ATmega-class) in BASCOM-AVR scanning a transistor-multiplexed LED matrix; yellow/red/blue/green fields, 3/9/6/9 cells, 27 LEDs, 24-hour. Held in 02-inputs/DIY-TiX-Clock.pdf. Source: http://www.instructables.com/id/DIY-TiX-Clock/. ↩

2. uTixClock by ujjaldey, Instructables — Arduino Nano + DS1302 RTC + two 74HC595 shift registers, 27 LEDs (Y3 / R9 / B6 / G9), 24-hour, per-minute random arrangement. The worked examples (00:00, 01:12, 11:39, 16:24, 23:47) and the blank-midnight behaviour are taken from this build’s source. Held in 02-inputs/UTixClock.pdf. Source: https://www.instructables.com/id/UTixClock/. ↩ ↩² ↩³ ↩⁴