HEX V8 — Preprint (español)

v1.5.4Satinus E.I.R.L. · 2026 · Referencia [18] en informe técnico

HEX V8: un símbolo 2D ternario hexagonal con capacidad escalable y lectura móvil bajo condiciones de impresión controladas

Autor: Jorge Figueroa
Afiliación: Investigador independiente, Satinus E.I.R.L., Chile
Contacto: jorgefigueroacifuentes@gmail.com, satinuseirl@gmail.com
Fecha: 2026-07-12 (pasada de cohesión narrativa, alineada a EN)

Resumen

Los códigos bidimensionales dominantes —QR Code, Data Matrix y Aztec— codifican el payload en módulos binarios sobre una cuadrícula rectangular. Ese diseño favorece el ecosistema y la lectura integrada en smartphone, pero impone un techo práctico de bytes recuperables cuando el símbolo debe seguir siendo legible con óptica móvil, distancia típica de escaneo e impresión monocroma.

Este trabajo formula una pregunta acotada: bajo reglas explícitas de escala en milímetros y con un lector dedicado, ¿puede un símbolo monocromo con geometría distinta de la cuadrícula y más de dos estados por elemento físico transportar más bytes útiles que un QR de referencia a legibilidad comparable? La respuesta evaluada es HEX V8: malla triangular ternaria empaquetada en rombos S2-octal; header autodescriptivo de 8 bytes; Reed–Solomon en GF(256) con borrados nativos del par (1,1); ring interleave; padding determinista; y capa visual checkerboard (spec v1.1), decodificada por un pipeline móvil alineado al anillo hexagonal y al parámetro N.

Bajo un protocolo declarado (RS-M, 300 DPI al 100 %, captura a 25–35 cm, tri_mm (arista media del triángulo impreso, en mm) ≈ 5 mm, sesión Auto N8→N15), un modelo cerrado de capacidad, una regresión sintética 15/15 y pruebas de campo en papel con el lector Android 0.4.7 —instalado como APK de distribución libre— en un Redmi Note 9 Pro documentado producen 137 B de payload útil en HEX N15 (impreso ≈ 85 mm) frente a ~37 B de un QR de referencia a ~25 mm a la misma legibilidad de arista. Eso no es un claim a igual huella: a $\mathrm{tri_mm}$ fijo, subir $N$ agranda $\mathrm{code_mm}$ (p. ej. N10 a 58 mm transporta 35 B; N15 a 85 mm transporta 137 B). HEX V8 no sustituye la universalidad del QR ni reduce la huella de un QR pequeño: es un canal monocromo especializado que exige aplicación dedicada, impresión controlada y encuadre angular estricto en N altos.

Palabras clave: código 2D; código de barras 2D; codificación ternaria; malla hexagonal; Reed–Solomon; visión por computador móvil; capacidad de payload; QR Code; Data Matrix; Aztec; simbología monocroma

1. Contexto: códigos bidimensionales y capacidad bajo límites de legibilidad

Los códigos de barras bidimensionales actúan como un canal físico: convierten un payload de datos —secuencia de bytes con significado para la aplicación— en un patrón imprimible o mostrable, y un lector con cámara intenta recuperar esos bytes. En la práctica el payload viaja en claro en el símbolo; la corrección de errores protege contra daños de impresión y captura, no sustituye cifrado.

El modelo dominante —QR Code [1,7], Data Matrix [2], Aztec [3]— empaqueta la información en módulos binarios (dos estados por celda: claro u oscuro) sobre una cuadrícula rectangular. Tras detectar marcadores de sincronización (finders, bullseye, perímetro), el lector muestrea cada módulo y reconstruye bits; la capa lógica aplica Reed–Solomon [5] en GF(256) sobre bloques de bytes. La versión o el tamaño del módulo escala la capacidad: a mayor versión, más filas de módulos y más bytes posibles, a costa de un símbolo físicamente mayor o de celdas más pequeñas y más difíciles de leer.

Ese diseño prioriza ecosistema: estandarización (p. ej. ISO/IEC 18004 [1]), lectores integrados en smartphones y flujos de impresión conocidos. El coste estructural es un techo de capacidad útil bajo legibilidad móvil: cuántos bytes recuperables quedan disponibles cuando el elemento mínimo impreso debe seguir siendo legible con ópticas móviles, distancia típica de ~25–35 cm e impresión monocroma cotidiana [6,17]. Reducir el módulo aumenta los bits/mm² nominales pero reduce el margen ante desenfoque, curvatura del soporte y resolución efectiva de la cámara—así que «mayor densidad» y «más payload útil bajo lectura de campo» no son el mismo objetivo.

Otras simbologías abordan el mismo problema con compromisos distintos. DotCode [16] apunta a impresión industrial de alta velocidad y sigue siendo binario por punto. Los códigos multicanal en color [13,14] multiplican estados por celda, pero exigen reproducción fiel del color y calibración de cámara —condiciones más frágiles que monocromo en campo. MaxiCode [15] emplea celdas hexagonales en un formato cerrado de mensajería, no un códec abierto de bytes arbitrarios. En conjunto, la familia ISO más extendida comparte un supuesto: un módulo ≈ un bit, muestreo sobre cuadrícula (o equivalente rectangular) y pipelines de lectura diseñados para ese supuesto [8–10,17].

La lectura con cámara móvil está bien documentada: detección, corrección de perspectiva (homografía), binarización y decodificación RS. Esas técnicas no se trasladan automáticamente a un símbolo con otra geometría o más de dos estados por elemento sin rediseñar detección, muestreo y capa lógica. Queda abierta, como pregunta de diseño, la exploración de formatos monocromos, con lector dedicado y reglas de impresión explícitas, cuando el objetivo es priorizar capacidad de payload frente a universalidad de lectura.

2. Pregunta de investigación

Ante el panorama de §1, este trabajo parte de una pregunta abierta y acotada:

¿Es posible diseñar un símbolo 2D monocromo, con geometría distinta de la cuadrícula binaria y más de dos estados por elemento físico, que transporte más bytes útiles de payload que los códigos de referencia (p. ej. QR) a legibilidad móvil comparable, siendo legible con un lector dedicado bajo condiciones explícitas de impresión?

No se pregunta si buscamos un sustituto del QR en ecosistema, norma ISO ni confidencialidad. No se pregunta si HEX empaqueta más bits en una caja impresa más pequeña que un QR compacto. Se pregunta si existe una alternativa medible en payload útil cuando el símbolo se imprime y se lee bajo reglas declaradas: tamaño en milímetros, resolución de impresión, distancia de captura y umbral de legibilidad del elemento mínimo (tri_mm) —cuantificados en §4 y §6. Bajo esas reglas, subir $N$ cambia una huella mayor por más bytes manteniendo la legibilidad de arista aproximadamente fija.

El resto del artículo relata cómo se buscó esa alternativa: qué se probó, qué capas se añadieron hasta converger en la versión evaluada, qué datos se obtuvieron y qué se entrega como evidencia. El nombre HEX y el protocolo V8 designan esa convergencia; el significado de la sigla se explicitará en §3.7.

Organización. §3 traza la evolución del diseño hasta HEX V8 (capa lógica en §3.5; Tabla 1). §4 cuantifica capacidad y escala de impresión (Tabla 2). §5 describe el lector móvil dedicado (perfiles, etapas y resolución de N; Tabla 7). §6 declara el protocolo de evaluación (Tabla 6), reporta evidencia sintética y de campo, y ofrece una comparación acotada con QR (Tablas 4–5b). Las contribuciones numeradas aparecen en §8.2, tras la evidencia. §7–§9 cubren limitaciones, conclusiones y disponibilidad de materiales. Los apéndices indexan términos y floats.

3. Construcción del formato: evolución del diseño

A partir de la pregunta de §2 se abrió una línea de diseño que más tarde se denominó HEX. El formato no se definió de una sola vez: esta sección sigue el orden en que se probaron ideas y se añadieron capas, cada una en respuesta al límite de la anterior, hasta la versión V8 evaluada en §6.

Figura 7. Secuencia de decisiones de diseño (§3.1–3.7).

3.1 Punto de partida: panal hexagonal binario

La primera propuesta concreta fue deliberadamente modesta: un símbolo con silueta hexagonal formado por módulos hexagonales binarios (blanco/negro), inspirado en la teselación del panal pero conservando el bit por celda del QR. El payload se concentraba en un borde codificado con Reed–Solomon; el interior cumplía sobre todo función estructural. Era un banco de pruebas teórico: verificar si la geometría hexagonal merecía exploración antes de invertir en un alfabeto más rico.

En paralelo se fijaron restricciones alineadas con §2: sin canal RGB [13,14]; sin asumir el lector QR del teléfono; sí aceptar un lector dedicado y reglas de impresión explícitas (DPI, tamaño en mm) a cambio de buscar más bytes útiles a un umbral de arista declarado, no una huella menor que un QR compacto.

3.2 Primera línea: borde binario (insuficiente)

La implementación agrupó triángulos en módulos hexagonales de primer nivel y codificó datos en el perímetro. Las capacidades medidas quedaron del orden de 18 B (N8) a 64 B (N20) —muy por debajo de un QR comparable (p. ej. versión 10 nivel M ≈ 652 B en referencia habitual).

El hexágono grueso como unidad y un canal binario perimetral desperdiciaban el área interior y no competían en densidad con la cuadrícula madura del QR. Era necesario cambiar alfabeto y empaquetado, no solo la silueta exterior.

3.3 Malla triangular y trit

La silueta se fragmentó en una malla triangular hexagonal —teselación bariocéntrica de triángulos equiláteros alternos upright e inverted. Cada triángulo codificable lleva un trit, dígito ternario $\in{0,1,2}$. Nominalmente cada trit aporta $\log_2 3\approx 1{,}58$ bit de información por celda, frente a 1 bit del módulo QR.

Los trits aislados, sin embargo, no forman bytes estables ni resisten el ruido de captura sin una capa lógica adicional.

3.4 Rombo, S2-octal y parámetro N

Los trits se empaquetan en rombos: cada rombo une un triángulo upright con uno inverted adyacente (arista compartida). Dos trits admiten nueve combinaciones; ocho se mapean a un símbolo de datos S2-octal de 3 bits y el par (1, 1) queda reservado como borrado nativo (§3.5.1)—ese es el puente de celdas ternarias a alfabeto octal de cómputo, no la afirmación de que un trit valga tres bits.

El entero N es el número de divisiones radiales de la malla triangular del panal (cuán finamente se subdivide el hexágono en coronas de triángulos concéntricas). No es un «número de versión» al estilo QR dibujado como hexágonos anidados. A mayor $N$, más triángulos codificables y por tanto más rombos de payload (§4); a $\mathrm{tri_mm}$ fijo, también aumenta el ancho flat-to-flat impreso $\mathrm{code_mm}$. La unidad atómica de codificación es el rombo, no el triángulo aislado ni el hexágono grueso de §3.2.

Figura 4d. Escalado de huella impresa y payload útil (RS-M) con el parámetro $N$ (subset N8 / N12 / N15; valores de Tabla 2). A legibilidad de arista comparable, subir $N$ agranda $\mathrm{code_mm}$ y la capacidad.

Bajo las alternativas exploradas en esta línea —trit aislado, hexágono binario grueso (§3.2) y un empaquetado experimental por células de tres rombos— el S2-octal ofrece el mejor balance hasta la fecha entre capacidad, alineación a bytes/RS y rastreabilidad óptica (§3.5.1, §7). La agrupación de tres rombos por hexágono se evaluó solo como hipótesis de packing y no entra en el códec V8; se menciona aquí por completitud del diseño.

Figura 4b. Atlas de rombos: ocho símbolos de datos (3 bits) y el par (1,1) reservado como borrado. Arista compartida entre upright e inverted.

3.5 Capa lógica: S2-octal, header, interleave y Reed–Solomon

La captura no devuelve trits perfectos: manchas, compresión JPEG, desenfoque y ambigüedad en clasificación convierten el símbolo impreso en un canal ruidoso. La capa lógica V8 responde con tres decisiones acopladas: un alfabeto físico con señal de borrado, un orden de escritura resistente a daño local y un bloque de metadatos autocontenido.

3.5.1 Símbolos S2-octal y erasure nativo

Cada rombo aporta dos trits $(t_a, t_b)$. Nueve combinaciones son posibles; ocho se mapean a símbolos de datos ${0,\ldots,7}$ (3 bits cada uno) y el par (1, 1) queda excluido de la tabla de codificación. Si el lector clasifica un rombo como (1, 1) —ambigüedad típica del trit checkerboard bajo ruido— el decodificador no lo interpreta como dato: lo registra como borrado (erasure) en posición conocida. En Reed–Solomon, corregir un borrado consume la mitad de la paridad que corregir un error en posición desconocida; el diseño alinea el alfabeto físico con el tipo de fallo más frecuente en captura móvil.

Los símbolos se empaquetan en bytes (MSB-first, tres símbolos por byte con un bit de relleno) antes de aplicar RS en GF(256), igual que en QR, pero la unidad de corrección visual sigue siendo el rombo, no el byte aislado.

3.5.2 Header V8 (8 bytes)

El header es un bloque fijo de 8 bytes serializado en big-endian. Viaja al inicio del flujo lógico y se replica en los primeros rombos de la malla. Su integridad se protege con CRC-8/MAXIM sobre los siete primeros bytes; el decodificador rechaza headers corruptos antes de intentar RS (fail-fast).

Tabla 1. Layout del header V8

Los 22 rombos reservados en §4.1 corresponden a $\lceil 64/3 \rceil$ posiciones necesarias para empaquetar estos 8 bytes como símbolos S2-octal en la malla.

3.5.3 Ring interleave

Sin interleave, un rayado o mancha local destruiría bytes contiguos del payload. En V8 el encoder ordena los rombos de datos por corona hexagonal de la malla de datos (interior → exterior) y, dentro de cada corona, reparte en round-robin sectorial (seis sectores del panal). Este orden lógico de escritura es distinto del anillo visual de §3.6 (el perímetro negro grueso usado para pose/detección de $N$). Los bytes codificados se escriben en el orden intercalado; el decoder reconstruye el stream lógico invirtiendo la permutación (deinterleave).

Efecto práctico: un daño local en la imagen se traduce en errores dispersos en el bloque RS, no en un segmento contiguo del mensaje. El flag ring_interleave del header documenta que el símbolo usa este orden; en V8 canónico está siempre activo.

3.5.4 Reed–Solomon (nivel M)

Todos los experimentos de este artículo usan RS nivel M (~20 % de paridad sobre el bloque de datos). El codificador calcula el layout del bloque (datos + paridad) dentro del espacio disponible en rombos después de reservar header y anclas; el valor rs_nsym resultante se escribe en el header para que el decoder aplique la misma configuración sin parámetros externos.

El nivel M equilibra capacidad y margen ante JPEG, desenfoque leve y errores de clasificación de trits —condiciones típicas del corpus sintético (§6.1) y del campo en papel (§6.2).

3.5.5 Padding determinista

Los rombos no ocupados por header, payload RS y paridad se rellenan con símbolos S2-octal pseudoaleatorios pero reproducibles. La semilla se deriva de BLAKE2b-64("HEXV8_PAD" ‖ header ‖ datos ‖ N) y un generador xorshift64* produce la secuencia de trits. Encoder y decoder generan el mismo padding dado el mismo contexto, sin almacenarlo explícitamente en el símbolo. Tras decodificar RS, el payload se trunca a data_length del header; el padding nunca se confunde con datos válidos.

En conjunto, la contribución de §3.5 no es Reed–Solomon en abstracto, sino el co-diseño alfabeto con borrado nativo + orden inter-anillos + header autocontenido + padding verificable.

3.6 Materialización en tinta: spec visual v1.1

Tres estados ternarios deben sobrevivir a impresión monocroma sin depender de gris plano —la tinta suele fusionar grises medios. Convención de implementación (alineada al encoder/decoder de referencia):

Figura 4. Tres estados ternarios en orientación upright e inverted (atlas didáctico). El trit 1 se discrimina por textura, no por tono continuo.

Figura 4c. Recorte de un símbolo impreso: el checkerboard bajo captura real.

Un anillo visual hexagonal en el perímetro sincroniza orientación y permite estimar N antes de leer el núcleo. Fuera del anillo, una zona tranquila (margen blanco) cumple la misma función que la quiet zone del QR. En el interior de ese margen, junto al borde interno del anillo, el encoder de referencia puede dibujar un patrón de timing de quiet zone opcional: seis segmentos rectangulares blanco/negro alternados por cara del hexágono. Es una banda de calibración binaria entre la malla ternaria de datos y el anillo visual—útil como pista auxiliar de alineación—, mientras que la pose, la escala y la estimación de $N$ siguen gobernadas por el anillo visual y el ring ratio (§5.2). La generación de imágenes usa 300 DPI, escala 100 % y supersample en raster (detalle en [18]).

La capa visual no es decoración: el trit 1 debe ser legible por integral de imagen en la cámara, no solo por inspección humana.

3.7 Convergencia: protocolo HEX V8

Las capas anteriores convergen en HEX V8 (Hexagonal Encoding eXtended), un códec visual bidireccional: convierte payload de bytes y valor N en imagen (PNG/PDF), y recupera bytes desde una fotografía.

Encode: header → RS sobre espacio disponible → bytes a S2-octal → ring interleave → padding → mapa de triángulos + anillo + margen → rasterización.

Decode: escala de grises y recorte → anillo visual → pose y N → homografía → muestreo de trits → rombos → deinterleave → RS con erasures → validación de header → truncado a data_length.

Invariantes: dentro de la capacidad de §4, roundtrip (decode(encode(data)) = data); ante corrupción irrecuperable, fail-fast (error explícito, sin decodificación silenciosa incorrecta).

Figura 1. Pipeline lógico: encode (izquierda), canal físico (centro) y decode (derecha).

Figura 2. Render de referencia (N=10, RS-M): anillo visual, zona tranquila (con segmentos de timing opcionales en el borde interno del anillo) y malla triangular.

4. Capacidad y escala física

Con el formato definido (§3), la pregunta de §2 se vuelve cuantitativa: ¿cuántos bytes caben por N y a qué tamaño imprimir?

4.1 Capacidad geométrica

La geometría depende del parámetro N (divisiones radiales de la malla hexagonal). Dos anillos exteriores se reservan para el anillo visual de sincronización; el núcleo interior queda para datos. Definimos el kernel de datos:

$$K = N - 3$$

equivalente a $L = N - 2_{\text{visual}} - 1$ anillos codificables en la malla bariocéntrica.

Paso 1 — triángulos codificables. Por sector (seis sectores en el panal), la teselación aporta $K^2$ triángulos de datos; en total:

$$T_{\text{datos}} = 6K^2$$

Paso 2 — rombos. Cada rombo consume dos triángulos (upright + inverted adyacentes). Los rombos de datos se agrupan en tres bandas concéntricas de $K$ posiciones, con solapamiento de borde entre bandas:

$$\text{rombos}_{\text{bruto}} = 3K(K-1)$$

Paso 3 — overhead fijo (en rombos, no en bytes):

Paso 4 — bytes geométricos. Cada rombo de payload aporta 3 bits:

$$\text{pay_rombos} = 3K(K-1) - 25$$

$$\text{payload_bytes_geom} = \left\lfloor \frac{\text{pay_rombos} \times 3}{8} \right\rfloor$$

Esta expresión es la capacidad geométrica: cota superior del espacio disponible para el bloque lógico (header + payload RS + padding) antes de considerar la eficiencia de empaquetado.

Ejemplo ($N=15$). $K=12 \Rightarrow \text{rombos}_{\text{bruto}} = 396$; menos 25 $\Rightarrow 371$ rombos de payload $\Rightarrow \lfloor 371 \times 3 / 8 \rfloor = 139$ B geométricos (Tabla 2).

Ejemplo ($N=10$). $K=7 \Rightarrow 101$ rombos de payload $\Rightarrow 37$ B geométricos; con RS-M el payload máximo medido es 35 B (Tabla 2).

4.2 Escala en milímetros

La arista media del triángulo impreso (tri_mm) escala con el ancho flat-to-flat del hexágono (code_mm) y con N:

$$\text{tri_mm} \approx \frac{\text{code_mm} \times 0{,}86}{N}$$

El factor 0,86 relaciona el ancho del hexágono con la arista del triángulo en la malla bariocéntrica. Esta ligera desviación respecto al ideal geométrico ($\approx 0{,}866$) obedece estrictamente a la compensación de tolerancia de impresión (sangrado o inset visual áureo) en la generación del raster.

Invertiendo la fórmula, dado un tri_mm objetivo y un N deseado, el tamaño de impresión queda:

$$\text{code_mm} \approx \frac{\text{tri_mm} \times N}{0{,}86}$$

Umbral de campo. La lectura móvil fiable exigió empíricamente tri_mm ≳ 5 mm en N altos. Por debajo, la clasificación del trit 1 (checkerboard) y la estimación de N se degradan. El protocolo de evaluación (§6) fija tamaños de impresión por N (Tabla 2) para mantener ese umbral: N8/N10 a 58 mm (tri ≈ 6,2 / 5,0 mm), N12 a 70 mm y N15 a 85 mm (tri ≈ 5,0 / 4,9 mm).

Regla de lectura (anti-confusión). No leer la Tabla 2 como «N15 empaqueta 137 B en la misma caja de 58 mm que N10». A $\mathrm{tri_mm}$ emparejado, $\mathrm{code_mm}$ crece aproximadamente con $N$ (fórmula §4.2). N10@58 mm ≈ 35 B y N15@85 mm ≈ 137 B son puntos de misma legibilidad, no de misma huella. El QR de referencia ~37 B a ~25 mm (§6.4) es aún más pequeño; HEX cambia huella por payload bajo el umbral declarado.

Figura 5. Tamaños en milímetros validados en campo; impresión a 300 DPI, escala 100 %. Cap. es capacidad geométrica (Tabla 2); Payload es la cadena demo de esta hoja, no el máximo RS-M.

4.3 Capacidad útil con RS (nivel M)

La capacidad geométrica es una cota del espacio en rombos; el payload máximo en claro es menor porque el bloque RS ocupa paridad dentro del mismo espacio. Para cada N, el codificador de referencia busca el mayor data_length admisible con RS-M mediante búsqueda binaria sobre el espacio disponible (junio 2026); los resultados están en la columna Datos máx. de Tabla 2.

La columna Utilización mide qué fracción de los trits codificables de la malla se ocupan al saturar el símbolo (datos + paridad RS + header empaquetado), no el cociente simple datos/geom. A mayor N, la utilización sube (~83 % en N8 → ~90 % en N15) porque el overhead fijo de 25 rombos se diluye.

Relación geométrica → útil. Aproximadamente, RS-M reserva ~20 % del bloque para paridad; la diferencia entre Cap. geom. y Datos máx. en Tabla 2 es pequeña en bytes porque el header ya está descontado en la fórmula de §4.1 y la paridad se ajusta al espacio restante. Detalle de layout por N en informe técnico [18].

Tabla 2. Capacidad por nivel N (RS-M)

Figura 3. Crecimiento de la capacidad útil con N (valores de Tabla 2).

5. Lector móvil: de la foto al payload

Un símbolo de mayor capacidad bajo el protocolo de §4–§6 no lo lee el escáner QR integrado en el teléfono. Hace falta un pipeline de decodificación móvil alineado con trits, anillo hexagonal y N variable. Esta sección describe la arquitectura del lector usado en la evaluación de campo (release 0.4.7, julio 2026)—el baseline de §5.6—, complementaria al códec de §3.7.

5.1 Por qué hace falta una aplicación dedicada

El decode móvil reutiliza componentes estándar [8–12] —escala de grises, homografía, Reed–Solomon— pero el supuesto QR (módulo binario sobre cuadrícula, finders rectangulares, versión discreta) no traslada directamente a HEX. El lector dedicado añade cinco capacidades que un pipeline QR no posee:

1. Detección del anillo visual hexagonal y estimación de escala antes de leer datos.
2. Resolución de N —el símbolo puede ser N8, N10, N12 o N15 en la misma sesión.
3. Clasificación ternaria por triángulo, incluida la textura checkerboard del trit 1 (§3.6).
4. Deinterleave por coronas según el orden de escritura V8 (§3.5.3).
5. Adaptación a escena —papel, monitor con moiré, N15 denso— sin agotar batería en un único barrido costoso.

Sin estas piezas no es posible recuperar el payload ni siquiera con el motor de decode correcto: el cuello de botella en campo no es la capa RS, sino geometría + clasificación + política de reintentos.

5.2 Captura y región de interés

La UI fija un recuadro de encuadre; al capturar, se recorta una región de interés (ROI) del fotograma con corrección de bias vertical empírico (monitor: el símbolo suele quedar ligeramente bajo el centro óptico si no se compensa). Antes del decode se calculan métricas de escena —contraste local, varianza, dispersión de intensidades— usadas por el enrutador de §5.4.

Cada intento parte de una imagen en escala de grises. El primer paso geométrico es detectar el anillo visual: barrido radial desde el centro estimado buscando la banda oscura del perímetro hexagonal. Del anillo se obtiene el centro refinado, la orientación y el ring ratio —cociente entre radios exterior e interior— que correlaciona con N (p. ej. N10 ≈ 0,874, N15 ≈ 0,887). Si el ratio es ambiguo, el lector conserva varios candidatos de N en lugar de fijar uno erróneo. Cuando el patrón de timing de quiet zone de §3.6 está presente, el pipeline puede puntuar el acuerdo de segmentos como comprobación auxiliar opcional de alineación radial; no sustituye la detección del anillo ni condiciona el éxito del decode.

5.3 Núcleo geométrico por intento

Tras detectar el anillo, el pipeline ejecuta el núcleo compartido con §3.7:

1. Homografía — rectifica el plano del símbolo hacia malla canónica, corrigiendo perspectiva y rotación (anclas en sectores 0, 2, 4).
2. Preprocesado — variantes de contraste, desenfoque (blurred) y escalado según la etapa S0/S1/S2 (§5.4).
3. Muestreo de trits — integral por triángulo rectificado; trit 1 por checkerboard (§3.6).
4. Rombos y deinterleave — símbolos S2-octal; inversión del ring interleave (§3.5.3).
5. RS + header — GF(256) con erasures en (1,1); validación del header V8 (Tabla 1) y truncado a data_length.

La latencia suma captura (~1,4–2,0 s) y decode (decenas de ms a ~3,5 s en N altos, §6.2). Los reintentos multiplican el decode, no la captura.

5.4 Enrutador de perfil y etapas S0 → S1 → S2

Antes de escalar el coste, el lector 0.4.7 clasifica la escena (ProfileRouter). Ante duda en papel, la ruta conservadora es perfil papel (más rápida).

Tabla 7. Comportamiento por perfil y etapa (resumen)

Las etapas S0–S2 son políticas de coste: más combos de preprocesado y más reintentos por candidato de N. En papel, la mayoría de aciertos ocurre en S0; en monitor N15, S1 acotado a dos variantes evitó barridos de 12–23 s de releases anteriores. Muchos hatch_fail por encuadre bajo no agotan S2: el operador reencuadra (centerDy ≈ −14 px en aciertos N15, §6.2).

5.5 Resolución de N y pista de sesión

En modo Auto, la resolución de N sigue este orden:

1. Pill N — N fijo en UI → un solo candidato.
2. sessionNHint — último N acertado; cadena 8 → 10 → 12 → 15; tras N12, N15 se prueba primero.
3. Ring ratio — estimación desde el anillo; hasta cuatro candidatos si hay ambigüedad.
4. Expansión por etapa — más candidatos en S1/S2 si S0 falló.

Con sessionNHint ≥ 12 en pantalla, el lector puede fijar N desde la sesión y desactivar autoScan para N15 —validado en monitor 4/4 (§6.3).

5.6 Baseline evaluado

La campaña de campo de julio 2026 usó el lector Android (release 0.4.7), instalado como APK de distribución libre en el dispositivo de referencia: ProfileRouter activo, resolución de $N$ antes del barrido, sessionNHint persistente, S1 acotado en monitor N15 y warp canónico experimental desactivado. Las métricas de §6 (centerDy, decodeMs, perfil, etapa, candidatos de $N$ y motivo de fallo) se registraron sobre ese build durante las sesiones de protocolo.

Figura 6. Pipeline de decodificación del baseline evaluado (ROI → perfil → resolución de $N$ → etapas S0→S2 → núcleo geométrico → payload).

6. Evaluación experimental

Esta sección responde a la pregunta de §2 sobre el artefacto construido en §3–§5. Los experimentos comparten un protocolo común (§6.0); luego se reportan tres ejes: regresión sintética (§6.1), campo en papel (§6.2) y campo en monitor (§6.3), cerrando con la comparación acotada frente a QR (§6.4). Salvo indicación contraria, las métricas de campo móvil (centerDy, decodeMs, perfil/etapa) provienen del baseline 0.4.7 de §5.6.

6.0 Protocolo de evaluación

Tabla 6. Parámetros fijos del protocolo

Procedimiento de campo (papel). (1) Imprimir la hoja de referencia (Fig. 5). (2) Instalar el APK 0.4.7 usado en este estudio. (3) Abrir modo Auto; tras cada lectura correcta, avanzar al siguiente N sin reiniciar la sesión. (4) Encuadrar el símbolo activo dentro del recuadro; en N15, centrar el código ligeramente por encima del centro óptico (centerDy ≈ −14 px en aciertos).

Criterios de fallo aceptables vs bloqueantes. Un miss por hatch_fail o header inválido con centerDy positivo se clasifica como error de encuadre, no como regresión del códec. Un fallo de RS con símbolo bien centrado y perfil correcto sería bloqueante; no se observó en las sesiones jul 2026.

Resolución angular (paraxial). La discriminación del trit checkerboard (§3.6) y el umbral tri_mm ≈ 5 mm (§4.2) dependen de la distancia de captura $D$ y de la resolución angular óptica —distancia focal efectiva $f$ y paso de píxel del sensor $p$ (Tabla 6). Bajo un modelo pinhole en régimen paraxial (distorsión despreciable cerca del eje óptico), la arista del triángulo proyectada en el sensor ocupa

$$p_{\text{tri,sensor}} \approx \frac{\text{tri_mm}}{D} \cdot \frac{f}{p}$$

(con longitudes en mm). Se omiten términos de tambor/cojín: dentro del ROI del visor el desplazamiento radial es pequeño frente a $D$, y los polinomios típicos de gran angular móvil son de segundo orden cuando $|r|\lesssim 0{,}3\,D$.

Del fotograma completo al buffer de decode. Con tri_mm ≈ 4,9 mm, $D\approx 30$ cm, $f\approx 5{,}6$ mm (equivalente 26 mm sobre sensor 1/1,72″) y $p\approx 1{,}6$ µm (binning 4:1 habitual en esta clase de sensor), el orden de magnitud en fotograma completo es ~50 px/arista antes del recorte. El pipeline recorta el ROI y lo redimensiona a ~560 px de ancho; en aciertos N15 se reportan radios de anillo 126–164 px, es decir ~10–12 px/arista en el buffer —margen estrecho para la textura del trit 1, alineado con el umbral operativo. La degradación periférica en N15 se trata como límite de campo (§7.1), no como corrección dentro de esta estimación. Dispositivos con distinto $f/p$ o rango dinámico pueden caer por debajo de ese margen sin cambiar el símbolo impreso, lo que motiva la matriz multidispositivo (§7.1, §8.4).

6.1 Corpus sintético

El corpus de regresión de laboratorio consta de 15 imágenes PNG generadas a partir de un símbolo base (N=8, payload Hola HEX) con degradaciones controladas:

Resultado: los motores de decode en Python y TypeScript recuperan 15/15 payloads esperados (npm run benchmark:matrix, junio 2026). La latencia p95 del motor Python es ≈ 898 ms por imagen en el hardware de laboratorio. Este corpus valida el códec antes del ruido específico de impresión y de la UI de captura.

6.2 Campo en papel

Sesiones julio 2026 con el APK 0.4.7 —Android, distribución libre de APK— sobre la hoja de Fig. 5, capturadas con el Redmi Note 9 Pro de Tabla 6.

Tabla 3. Resultados en papel

Telemetría de la sesión confirmatoria (2026-07-04). Cuatro lecturas correctas secuenciales N8→N15; cinco misses adicionales, todos al intentar N15 con el símbolo bajo el centro del recuadro (centerDy +11…+26 px): tres garbage_header, un crc_fail y un hatch_fail. N15 exitoso: decodeMs 2955 ms, centerDy −14 px, etapa S0, perfil papel. Rango de decodeMs en aciertos: 116–3524 ms (p95 marginal 3524 ms en N12, por encima del umbral de regresión de 3 s pero sin fallo funcional).

Interpretación. El formato V8 es estable en papel; el cuello de botella operativo es encuadre en N15, coherente con la mayor densidad visual y el área activa del símbolo. La Figura 9 (columna izquierda) documenta lecturas exitosas N8→N15 en las condiciones de la hoja impresa.

6.3 Campo en monitor (secundario)

El canal monitor es secundario: valida el perfil pantalla del lector (§5.4) bajo moiré y reflejos, pero el papel sigue siendo el sustrato de demostración principal. La Figura 9 (columna derecha) muestra lecturas exitosas en monitor para los mismos niveles N que en papel.

Moiré (por qué es menos reproducible que el papel). El moiré digital es un batido entre la frecuencia espacial del panel $f_{\text{display}}=1/d_{\text{display}}$ y la densidad de muestreo del pipeline $f_{\text{cam}}=p_{\text{tri,decode}}/\mathrm{tri_mm}$ tras el resize del ROI (§6.0). En el panel ThinkPad L14 WUXGA documentado [20], $d_{\text{display}}\approx 0{,}157$ mm y $f_{\text{display}}\approx 6{,}4$ ciclos/mm. Mostrado a los mismos milímetros físicos que Fig. 5 (zoom 100 %), N15 da $p_{\text{tri,display}}\approx 31$ px/arista en el panel y, tras el pipeline, $p_{\text{tri,decode}}\approx 11$ px/arista ($f_{\text{cam}}\approx 2{,}2$ ciclos/mm). Cuando armónicos de la malla o del checkerboard se acercan al límite de Nyquist $f_{\text{cam}}/2$, el batido aliasa la textura del trit 1 y eleva hatch_fail —distinto de un fallo RS. Paneles con otro $d_{\text{display}}$ cambian ese acoplamiento; por eso el monitor no es intercambiable con el papel.

Las sesiones golden 2026-07-03 y 2026-07-04 usaron este L14 como única pantalla de prueba. N8/N10 en monitor requirieron ~6–7 s de decode (pantalla, S1 con moiré) antes de fijar sessionNHint; N12/N15 exitosos bajaron a 136–1333 ms con encuadre fino. Sesión 2026-07-03: 4/4 OK, N15 en 1333 ms (blurred, dos variantes, solo S1). Confirmación 2026-07-04: 4/4 OK tras ocho misses de encuadre; N15 en 458 ms con centerDy ≈ −15 px. Los misses vuelven a seguir desplazamiento vertical positivo (+1…+16 px). Con sessionNHint ≥ 12, S1 se acota a dos variantes y se evitan los barridos de 12–23 s de releases anteriores.

Figura 9. Capturas de la app lectora Android (APK 0.4.7, distribución libre; Redmi Note 9 Pro, jul 2026): por fila, papel (izquierda, hoja Fig. 5) y monitor (derecha, ThinkPad L14 WUXGA, perfil pantalla) para N8, N10, N12 y N15. Cada panel muestra decodificación exitosa bajo el protocolo de §6.0. Los banners en pantalla reportan bytes de capacidad geométrica (Tabla 2); los máximos útiles RS-M son 11/35/69/137 B.

6.4 Comparación acotada con QR

Narrativa que esta sección rechaza. HEX V8 no se presenta aquí como «la evolución hexagonal del QR», como sucesor drop-in, ni como un formato simplemente «3,7× más denso». La razón $137/37$ que aparece al poner N15 junto al QR de referencia ~25 mm es un ratio de payload bajo protocolo (misma banda de $\mathrm{tri_mm}$ / RS-M declarado), no un concurso de densidad a igual tamaño. El eje decisivo es bytes útiles a legibilidad móvil comparable; los bits/mm² de huella completa y la universalidad de ecosistema quedan deliberadamente en segundo plano (§7.3, Tabla 5b).

Tabla 4 contrasta el modelo de canal de las simbologías binarias típicas de §1 con HEX V8 (Figura 8d). Tabla 5 resume payloads de referencia bajo el protocolo de campo (Figura 8). Tabla 5b añade área hexagonal impresa y densidad útil en bits/mm² (Figura 8c).

Tabla 4. Modelo cualitativo: simbologías ISO típicas vs HEX V8

Tabla 5. Payload de referencia (protocolo de campo, tamaños de la hoja de referencia)

Tabla 5b. Densidad útil y área (HEX V8 RS-M vs QR de referencia §6.4)

Área del hexágono con ancho flat-to-flat (W): (A = \frac{\sqrt{3}}{2} W^2). Densidad: (8 \times \text{payload (B)} / A). El QR de referencia usa caja cuadrada (W\times W) como cota de área (no es hexágono).

Cómo no leer las Tablas 5–5b. Una razón como $137/37\approx 3{,}7$ es un ratio de payload bajo el protocolo declarado, no evidencia de que HEX N15 ocupe los mismos milímetros que el QR de referencia, ni de que HEX gane en bits/mm² de huella completa (la Tabla 5b muestra lo contrario para el área del hexágono completo). No hay un «QR N15 equivalente» en este manuscrito: el punto QR es un demo de campo a ~25 mm, mientras HEX N15 es un símbolo de 85 mm a $\mathrm{tri_mm}\approx 5\,\mathrm{mm}$.

La comparación justa no es solo «más bytes en menos milímetros», sino más bytes manteniendo legibilidad móvil. El indicador operativo adoptado es la arista del triángulo impreso (tri_mm ≈ 5 mm, §4.2). Bajo esa restricción, un QR de referencia impreso a ~25 mm en la misma banda de distancia de captura (§6.0) transporta ~37 B de payload útil en las hojas de comparación de campo (punto demo acotado, no una afirmación sobre todas las versiones o niveles ECC del QR). HEX N10 a tri ≈ 5 mm (~58 mm de ancho flat-to-flat) alcanza 35 B útiles (RS-M) —el mismo orden de magnitud—; HEX N15 a tri ≈ 5 mm (~87 mm teórico; 85 mm en campo) alcanza 137 B (Figura 8b). La Tabla 5 recoge los tamaños validados en campo (Fig. 5): en N15 el protocolo usa 85 mm (tri ≈ 4,9 mm), ligeramente por debajo del umbral nominal pero dentro del margen observado (§6.2). HEX no reduce la huella en mm respecto a un QR pequeño: cambia un hexágono impreso más grande por más payload al escalar $N$, manteniendo la legibilidad de arista cerca del umbral declarado. Frases como «capacidad superior» o «mayor densidad» son, por tanto, inseguras si ese trade-off no se dice en la misma frase.

Lectura de la Tabla 5b. Hay que distinguir dos lecturas de densidad. (i) Densidad de huella completa usa el área hexagonal impresa $A(W)$ y da ≈0,175 bits/mm² para HEX N15 a 85 mm —inferior al QR de referencia a ~25 mm (≈0,47 bits/mm²), porque la huella HEX incluye anillo y zona tranquila. (ii) Densidad del núcleo de trits restringe el área a (W_K=W\cdot K/N) (solo malla codificable) y eleva N15 a ≈0,27 bits/mm²; esa cifra es una métrica auxiliar del alfabeto, no un claim de marketing de etiqueta. Bajo el protocolo declarado, la comparación decisiva no es «más bits por mm² a cualquier escala», sino más bytes útiles a legibilidad comparable (tri_mm ≈ 5 mm), con una densidad HEX de huella completa que aún crece con N a tri casi fijo (≈0,030 → ≈0,175 bits/mm² de N8 a N15; Figura 3, Figura 8b). Data Matrix [2] comparte el alfabeto binario por módulo de Tabla 4; no se tabula aquí un punto ISO concreto bajo el mismo protocolo de campo, para no mezclar capacidades nominales de versión con la referencia QR ya acotada en §6.4.

Figura 8d. Contraste cualitativo del modelo de canal (Tabla 4): QR / Data Matrix / Aztec comparten alfabeto binario y topología de cuadrícula; HEX V8 cambia alfabeto, malla y lector.

Figura 8. Payload útil (RS-M) bajo el protocolo de campo (Tabla 5): QR de referencia ~25 mm frente a HEX N10 y N15.

Figura 8a. Relación entre bytes útiles (RS-M) y tamaño del símbolo (Tabla 2); punto QR de referencia incluido.

Figura 8b. Comparación a legibilidad comparable (misma arista de triángulo impresa $\approx 5\,\mathrm{mm}$)—no a igual ancho total.

Figura 8c. Densidad útil de huella completa (bits/mm²; Tabla 5b). El QR de referencia a ~25 mm es más denso por área; HEX gana en bytes a tri comparable al escalar $N$.

7. Limitaciones

Las evidencias de §6 apoyan la pregunta de §2 bajo reglas explícitas; fuera de ese marco el formato y el lector no deben extrapolarse sin nuevas mediciones.

7.1 Alcance experimental

La evaluación de campo documenta un solo dispositivo (Redmi Note 9 Pro, Tabla 6) y un build del lector Android (APK 0.4.7, §5.6), instalado mediante distribución libre de APK. No hay matriz de hardware entre OEM, ni un segundo sistema operativo, ni un barrido controlado de iluminación. El corpus sintético 15/15 (§6.1) valida el códec ante degradaciones de imagen, pero no sustituye la variabilidad de impresión, el encuadre ni la latencia de la UI móvil (§6.2–6.3). Los resultados de campo son, por tanto, una prueba de concepto sobre ese baseline: sensores con menor rango dinámico, pipelines ISP distintos o mayor distorsión gran angular pueden desplazar la detección de anillo, el hatch y el decodeMs. La generalización exige la matriz multidispositivo priorizada en §8.4.

Techo empírico vs. hardware moderno e industrial. Las métricas de §6.2–6.3 acotan el baseline Redmi Note 9 Pro; no agotan el techo teórico del formato ni del pipeline. Se dejan abiertas —como trabajo futuro o vía de colaboración de investigación— estimaciones y validaciones de lectura y velocidad en hardware moderno (sensores de mayor resolución, ópticas dedicadas, iluminación controlada) y en entornos industriales (cámaras fijas, distancia y ángulo nominalizados, sustratos estandarizados), donde el modelo paraxial de §6.0 sugiere márgenes de resolución angular y latencias potencialmente superiores a los observados aquí, sin modificar el códec.

Modelo paraxial frente a óptica periférica. No deben confundirse dos capas. (1) Paraxial / ROI central. El modelo de proyección de §6.0 (pinhole, pequeño offset radial) relaciona arista del triángulo, distancia $D$, focal $f$ y paso $p$ dentro del recuadro del visor donde se pretende situar el símbolo. Explica el orden de ~10–12 px/arista en el buffer de decode y permite estimar $p_{\text{tri,sensor}}$ en otros dispositivos. (2) Degradación periférica / fuera de eje. Cuando el anillo N15 de 85 mm se desplaza hacia la periferia de la lente, crecen la aberración radial y la curvatura de campo; ese régimen queda fuera del sweet spot paraxial y se trata como límite de hardware/óptica de campo, no como evidencia de fragilidad del códec.

Tolerancia angular del encuadre. La telemetría centerDy (desplazamiento vertical del centro del anillo detectado respecto al centro del buffer de decode, en px) se traduce a las mismas unidades angulares. Con altura útil del sensor $h_{\text{sensor}}$ (≈ 7,2 mm en 1/1,72″), distancia focal f, distancia de captura D y altura del buffer $H_{\text{decode}}$ (≈ 560 px, Tabla 6),

$$\delta\theta_y \approx \frac{\text{centerDy}}{H_{\text{decode}}} \cdot 2\arctan\frac{h_{\text{sensor}}}{2f}$$

(equivalentemente, $\delta y \approx D \tan\delta\theta_y$ en el plano del símbolo). Con f ≈ 5,6 mm, D ≈ 30 cm y el baseline Redmi Note 9 Pro, cada píxel de centerDy es ≈ 0,7 mm y ≈ 0,12° en escena. En la sesión confirmatoria de §6.2, los aciertos N15 se concentran cerca de −14 px (≈ −1,7°, símbolo ligeramente por encima del centro óptico); los cinco misses en N15 quedan en +11…+26 px (≈ +1,3°…+3,1°, símbolo bajo el recuadro). La ventana empírica en elevación es del orden de ±2° —coherente con la capa (2) anterior (óptica periférica)— y no con fallo de Reed–Solomon o S2-octal bajo un símbolo bien centrado.

La métrica decodeMs de §6.2–6.3 no es generalizable sin una matriz multipantalla/multidispositivo (§8.4). El modelo paraxial de §6.0 sigue permitiendo estimar $p_{\text{tri,sensor}}$ en otros dispositivos antes de medir latencia de campo.

7.2 Alcance del formato y de la operación

Los niveles N8–N15 están validados en móvil bajo el protocolo de §6.0. La cadena Auto 8 → 10 → 12 → 15 omite los N impares intermedios (9, 11, 13) pese a ser encodables (Tabla 2): no es una limitación del códec, sino una decisión de protocolo de campo y de geometría angular.

Geometría e incompatibilidad de fase. El panal tiene seis sectores con $K^2$ triángulos cada uno ($K=N-3$, §4.1). El lector estima N rotando una cuadrícula de muestreo angular con paso $\Delta\theta = 360°/N$ sobre la malla bariocéntrica, mientras las anclas de temporización del formato —anillo visual y sectores 0, 2, 4 (§3.4)— están fijas en fases $0°$, $120°$ y $240°$. Un N es armónico cuando $\Delta\theta$ reparte uniformemente esas fases; equivalentemente, $360° \bmod N = 0$. N11 y N13 violan esa coherencia de fase: el barrido rotacional no alinea de forma única la cuadrícula de estimación con las anclas del símbolo, lo que incrementa la ambigüedad al resolver N —se clasifican como disonantes en la heurística de diseño [18], no como fallo del códec. N9 sí es armónico, pero aporta un escalón de densidad casi iso-capaz a N10 bajo el mismo tri_mm (Tabla 2) sin beneficio operativo; incluirlo fragmentaría el espacio de candidatos del barrido de N y del ProfileRouter (§5.4–5.5). La progresión +2 hasta N12 mantiene escalones de capacidad espaciados con sectores simétricos; N15 cierra la cadena como extremo denso validado (impar pero armónico: $\Delta\theta = 24°$).

Con N ≥ 18 y arista de triángulo por debajo de ~5 mm, la lectura deja de ser fiable en las pruebas realizadas.

El cuello de botella operativo en N alto es encuadre, no el códec (fenómeno directamente correlacionado con la aberración óptica periférica anticipada en §7.1): en papel, los misses de la sesión confirmatoria (§6.2) se explican por centerDy positivo al situar N15 bajo el centro del recuadro. El canal monitor (ThinkPad L14, $d_{\text{display}} \approx 0{,}157$ mm, §6.3) es secundario y menos estable que el papel por moiré —sensible al acoplamiento $f_{\text{display}} \times f_{\text{cam}}$— y reflejos, aunque confirma el perfil pantalla del lector.

HEX V8 no aporta confidencialidad intrínseca: el payload permanece en claro en el símbolo; la corrección de errores protege integridad ante daño físico, no sustituye cifrado ni autenticación de aplicación. Empaquetados alternativos sobre la misma malla (p. ej. agrupación de tres rombos por hexágono) se exploraron fuera del códec canónico y no mejoraron capacidad ni alineación a bytes (§3.4).

7.3 Comparación, ecosistema y estado del documento

La comparación con QR (§6.4, Tablas 4–5) está acotada al protocolo declarado —RS-M, tri_mm ≈ 5 mm, un QR de referencia a ~25 mm— y no pretende cubrir el ecosistema ISO completo ni todos los niveles de corrección QR.

HEX exige lector dedicado y reglas de impresión explícitas; no compite en universalidad de lectura con cámaras QR integradas. Este manuscrito es un preprint sin revisión por pares. La reproducibilidad ampliada —especificación detallada, tablas, telemetría de campo y procedimientos de regresión— se documenta en el informe técnico [18].

8. Conclusiones y entregables

8.1 Respuesta a la pregunta de §2

La pregunta de §2 admite una respuesta afirmativa y acotada. Bajo las condiciones del protocolo (§6.0, Tabla 6) —impresión monocroma controlada, tri_mm ≳ 5 mm como criterio de legibilidad, lector dedicado con perfiles y resolución de N (§5)—, el artefacto HEX V8 evaluado transporta más bytes útiles que las referencias QR declaradas a legibilidad comparable: hasta 137 B en N15 / ≈85 mm con RS-M (Tabla 2, Figura 8b) frente a ~37 B de un QR de referencia a ~25 mm. La respuesta afirmativa no es «HEX sustituye al QR» ni «137 B caben en una etiqueta de 25–58 mm»; es «más bytes útiles cuando la legibilidad de arista se mantiene cerca de 5 mm». No se afirma validez fuera de ese marco (§7).

La evidencia es complementaria, no intercambiable:

1. Códec — regresión sintética 15/15 (§6.1): prueba necesaria del motor lógico ante JPEG, desenfoque, desplazamiento y perspectiva; no sustituye impresión ni UI de captura.
2. Campo — 4/4 OK secuencial N8→N15 en papel con APK 0.4.7 en Android (distribución libre de APK; §6.2, Figura 9), en un Redmi Note 9 Pro documentado. Los cinco misses de la sesión confirmatoria en N15 llevan centerDy +11…+26 px (≈ +1,3°…+3,1°, fuera del sweet spot paraxial de §7.1); el acierto correspondiente usa centerDy −14 px (≈ −1,7°) —patrón de encuadre periférico, no de fallo RS. En N alto el cuello operativo es encuadre/óptica, no Reed–Solomon.
3. Comparación — criterio operativo tri_mm ≈ 5 mm (§6.4), no densidad nominal en mm² ni empaquetado a igual huella; a igual legibilidad, N15 supera al QR de referencia en payload, no en huella mínima impresa.

Qué no afirmamos (ya excluido en §2 y detallado en §7): sustituto del QR en ecosistema o norma ISO; un «siguiente QR» evolutivo; confidencialidad intrínseca; lectura universal sin app dedicada; generalización a otros hardware sin nueva medición; un claim de etiqueta «3,7× más denso» a igual tamaño. HEX cambia huella por payload al escalar $N$, con lector dedicado y sensibilidad al encuadre en N15 —coherente con el arco de diseño de §3 (el borde binario de §3.2 no alcanzó esa banda de payload; V8 sí, bajo las reglas anteriores).

8.2 Contribuciones

Lo siguiente resume lo sustentado en §3–§6, alineado con el no-alcance de §2 y las limitaciones de §7:

1. Especificación convergente HEX V8 con evolución de diseño documentada (§3).
2. Modelo cerrado de capacidad geométrica y tabla empírica N8–N15 con RS-M (§4, Tabla 2).
3. Co-diseño de canal: ring interleave, erasures nativos (1,1), header V8 de 8 bytes (Tabla 1) y padding determinista (§3.5).
4. Capa visual v1.1 (checkerboard) para impresión monocroma a 300 DPI (§3.6).
5. Lector móvil con ProfileRouter, etapas S0–S2 y resolución de $N$ (§5, Tabla 7), evaluado bajo el protocolo declarado con el build 0.4.7 (§5.6, §6.0).

8.3 Entregables

Evidencia y materiales reproducibles asociados al estudio (no comercialización del formato):

8.4 Trabajo futuro

Prioridades, ordenadas por impacto evidencial:

1. Matriz multidispositivo / multi-ISP — repetir el protocolo de papel de §6.0 en al menos dos teléfonos Android adicionales (formatos de sensor y distorsión gran angular distintos), manteniendo la distribución libre de APK. Reportar ventanas de centerDy, tasa de acierto N15 y distribuciones de decodeMs por dispositivo, de modo que el baseline Redmi Note 9 Pro deje de ser el único ancla de campo.
2. Validación multipantalla — paneles con $d_{\text{display}}$ distinto al ThinkPad L14 de §6.3, separando el acoplamiento de moiré del comportamiento del códec.
3. Extensiones de protocolo — N impares y $N\geq 18$ con tri_mm medido; comparación BER formal frente a QR bajo las mismas reglas de impresión/captura.
4. Operaciones — conjunto público de capturas de campo con telemetría; ayudas de encuadre en N15 (guía o ROI adaptativo); especificación pública 1.0.
5. Métricas teóricas e industrialización — complemento al baseline móvil de §6: modelar y medir lectura y velocidad en hardware moderno y en entornos industriales (cámaras fijas, iluminación y geometría de captura controladas), como línea de investigación colaborativa; el modelo paraxial de §6.0 anticipa márgenes superiores a los del Redmi, pero esas cifras no se extrapolan como evidencia en este preprint.

Más allá de la medición, HEX V8 se posiciona como un canal especializado con lector dedicado (§5.1, §7.3), no como sustituto de la cámara del sistema operativo frente al QR. Usos industriales prospectivos —etiquetado denso de piezas, trazabilidad en planta, empaque técnico— aceptan ese compromiso cuando el payload a tri_mm ≈ 5 mm importa más que la huella mínima de marketing; no están validados en §6 y motivan la vía de colaboración de §9. Un encoder/decoder en navegador (§9) apoya roundtrips didácticos y exploración de capacidad; no sustituye el baseline Android de campo.

9. Disponibilidad de documentación y materiales

La documentación técnica ampliada se publica como informe técnico Satinus E.I.R.L. [18]:
https://satinus-eirl.github.io/docs/informes/hex-v8-informe-tecnico.html.

Materiales en línea (centro de documentación):

• Preprint HTML (español)
• Informe técnico [18]
• Hoja de tamaños (PDF) y capacidad máxima RS-M (PDF)
• HEX encoder/decoder (navegador) — herramienta TypeScript de roundtrip (15/15 vs Python en §6.1); solo didáctica, no sustituto del APK 0.4.7

Lector de campo. La línea Android usada en §6 se publica vía GitHub (hex-scanner): APK firmado, notas de versión y canal de actualización en la app. No figura en tiendas de aplicaciones durante la fase preprint.

Reutilización y contacto. Los entregables de §8.3 y los materiales públicos anteriores son gratuitos para uso didáctico, evaluación del formato y reproducción parcial del protocolo de §6.0. El núcleo algorítmico de referencia y la explotación comercial permanecen en Satinus E.I.R.L. (Ley chilena de PI N° 17.336). Colaboración, licenciamiento y apoyo al desarrollo ulterior del formato/lector están disponibles por acuerdo.

Contacto: jorgefigueroacifuentes@gmail.com, satinuseirl@gmail.com (Satinus E.I.R.L., Chile).

Referencias

1. ISO/IEC 18004:2015 — QR Code. iso.org/standard/62021
2. ISO/IEC 16022:2006 — Data Matrix.
3. ISO/IEC 24778:2024 — Aztec Code. iso.org/standard/82441
4. ISO/IEC 15438:2015 — PDF417. iso.org/standard/65502
5. I. S. Reed and G. Solomon, J. SIAM, 8(2):300–304, 1960. DOI: 10.1137/0108018
6. ISO/IEC 15415:2011 — Print quality for 2D symbols.
7. DENSO WAVE — QR development history. denso-wave.com
8. E. Ohbuchi et al., Proc. Cyberworlds, IEEE, 2004. DOI: 10.1109/CYBER.2004.144
9. J.-A. Lin and C.-S. Fuh, Math. Probl. Eng., 2013. DOI: 10.1155/2013/848276
10. L. F. F. Belussi and N. S. T. Hirata, Proc. SIBGRAPI, IEEE, 2011.
11. K. Zuiderveld, Graphics Gems IV, 1994.
12. G. Bradski and A. Kaehler, Learning OpenCV, O’Reilly, 2008.
13. D. Parikh and G. Jancke, IEEE WACV, 2008.
14. O. I. Bulan et al., Color Imaging Conf., 2011.
15. ISO/IEC 16023:2000 — MaxiCode.
16. AIM, Inc., DotCode Symbology Specification 4.0, 2019.
17. H. Kato et al., IEEE Pervasive Computing, 6(4):76–85, 2007.
18. Satinus E.I.R.L., HEX V8 — Especificación técnica, tablas de capacidad y protocolo de evaluación, informe técnico (en línea), 2026. satinus-eirl.github.io/docs/informes/hex-v8-informe-tecnico.html
19. Xiaomi Redmi Note 9 Pro — especificaciones de cámara (variante global). gsmarena.com/xiaomi_redmi_note_9_pro-10217
20. Lenovo ThinkPad L14 — especificaciones de panel (14″ WUXGA 1920×1200 IPS). psref.lenovo.com — ThinkPad L14

Apéndice A — Índice de términos

Referencia rápida. Las definiciones completas aparecen en la primera mención en el cuerpo.

Apéndice B — Índice de tablas y figuras

Los floats se numeran automáticamente en el PDF; el cuerpo usa referencias cruzadas. Este índice lista títulos por sección narrativa.