DEV Community

Cover image for Air Powered Segment Display: cuando alguien elige aire comprimido en lugar de píxeles
Juan Torchia
Juan Torchia

Posted on • Originally published at juanchi.dev

Air Powered Segment Display: cuando alguien elige aire comprimido en lugar de píxeles

Hay una creencia instalada en la comunidad dev que dice que si podés resolver algo con software, resolverlo con hardware es un capricho. Peor todavía: si podés resolverlo con una pantalla LCD de $3, construir un mecanismo neumático de movimiento físico es directamente un delirio de persona con demasiado tiempo libre.

Con todo respeto: están bastante equivocados.

Vi el video del Air Powered Segment Display y me quedé frenado. Un display de siete segmentos donde cada segmento es una pequeña aleta que se levanta con aire comprimido. Sin LEDs. Sin píxeles. Sin framebuffer. Solo presión de aire, válvulas solenoides, y el sonido — ese sonido — de algo físico moviéndose para mostrarte un número.

Mi primer instinto fue el de siempre: ¿para qué? Tengo una Raspberry Pi que puede hacer lo mismo con dos líneas de Python y un display de $4 de AliExpress.

Después me acordé de la bailarina con ALS controlando una performance con ondas cerebrales, y algo hizo click.

Display neumático hardware artístico: lo que el stack digital no puede darte

Estamos tan metidos en abstracciones que nos olvidamos de algo fundamental: la información tiene peso.

No peso metafórico. Peso literal. Cuando un segmento se levanta con aire comprimido, hay masa moviéndose. Hay inercia. Hay un pequeño delay que no es un bug ni una limitación de hardware — es física. Es el universo funcionando.

Un display LCD te muestra el número 8 en cero milisegundos. Un display neumático te muestra el número 8 después de que cada segmento decide levantarse, con ese sonido de válvula que es imposible de ignorar.

¿Cuál comunica mejor? Depende qué querés comunicar.

Si querés eficiencia: LCD, siempre. Si querés que la persona sienta el dato — que el número tenga presencia en el espacio — el neumático gana sin discusión.

Me pasó algo parecido cuando construí la sonificación de los colectivos de Buenos Aires. Los datos del GTFS-RT son los mismos que usa cualquier app de seguimiento. Pero cuando los datos se convierten en sonido en tiempo real — cuando escuchás un colectivo pasando en lugar de verlo en un mapa — algo cambia en cómo procesás la información. Lo escribí en el post de colectivos sonificados pero sigo pensando en eso.

Cómo funciona un display de segmentos neumático (y por qué es más complejo de lo que parece)

La mecánica básica es deceptivamente simple:

┌─────────────────────────────────────────────────────┐
│  DISPLAY NEUMÁTICO - ARQUITECTURA BÁSICA            │
│                                                     │
│  Compresor → Manifold → Válvulas solenoides (7x)   │
│                              ↓                      │
│                         Segmentos físicos           │
│                         (aletas/paletas)            │
│                              ↓                      │
│                    Controlador (Arduino/ESP32)       │
│                    decide cuáles activar            │
└─────────────────────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

Pero cuando empezás a pensarlo como arquitecto de software — que es como yo no puedo evitar pensar las cosas — aparecen problemas interesantes:

# Esto parece simple pero esconde complejidad real
# Un display LCD haría esto instantáneo
# Un display neumático tiene que manejar:
# 1. Tiempo de apertura de válvula
# 2. Tiempo de cierre
# 3. Presión residual
# 4. Conflictos si cambiás el número muy rápido

SEGMENTOS_POR_DIGITO = {
    # Formato: (a, b, c, d, e, f, g)
    # a=arriba, b=der_arriba, c=der_abajo,
    # d=abajo, e=izq_abajo, f=izq_arriba, g=medio
    0: (1, 1, 1, 1, 1, 1, 0),
    1: (0, 1, 1, 0, 0, 0, 0),
    2: (1, 1, 0, 1, 1, 0, 1),
    3: (1, 1, 1, 1, 0, 0, 1),
    4: (0, 1, 1, 0, 0, 1, 1),
    5: (1, 0, 1, 1, 0, 1, 1),
    6: (1, 0, 1, 1, 1, 1, 1),
    7: (1, 1, 1, 0, 0, 0, 0),
    8: (1, 1, 1, 1, 1, 1, 1),
    9: (1, 1, 1, 1, 0, 1, 1),
}

# El problema real: ¿cómo transicionás entre dígitos
# sin que los segmentos choquen entre sí?
# ¿Apagás todo y después encendés el nuevo número?
# ¿O calculás el delta y solo movés los que cambian?

def calcular_delta_segmentos(digito_actual, digito_nuevo):
    """Calcula qué segmentos hay que mover (no todos)"""
    estado_actual = SEGMENTOS_POR_DIGITO[digito_actual]
    estado_nuevo = SEGMENTOS_POR_DIGITO[digito_nuevo]

    activar = []
    desactivar = []

    for i, (actual, nuevo) in enumerate(zip(estado_actual, estado_nuevo)):
        if actual == 0 and nuevo == 1:
            activar.append(i)    # Este segmento se levanta
        elif actual == 1 and nuevo == 0:
            desactivar.append(i) # Este segmento baja

    return activar, desactivar

# Para ir de 8 a 1:
# Hay que bajar: a, d, e, f, g
# Hay que subir: ninguno (b y c ya estaban arriba)
# Cinco válvulas se activan casi simultáneamente
# El sonido que hace eso es imposible de replicar en software
Enter fullscreen mode Exit fullscreen mode

Ese último comentario no es poético — es técnicamente relevante. El sonido es información. El click de cinco válvulas cerrándose al mismo tiempo te dice algo que un cambio de pixel no puede decirte.

Es la misma razón por la que los trenes del AMBA tocando música tienen algo que un mapa animado no tiene. Lo exploré en el post de datos abiertos y trenes: cuando los datos tienen dimensión temporal y física, cambia cómo los procesamos.

Los errores comunes al pensar en hardware artístico

Error 1: "Es inefficiente, por lo tanto es malo"

Esta es la trampa más grande. Pasé años pensando en eficiencia computacional como métrica universal. Después de 32 años en tecnología, te puedo decir: la eficiencia es una métrica entre muchas. Un display neumático es terriblemente ineficiente en términos de energía, velocidad y costo. También es irremplazable si querés que alguien sienta el dato.

Es el mismo argumento que uso cuando hablo del fracaso de lenguajes de programación técnicamente perfectos: la perfección técnica no garantiza adopción ni impacto. Los humanos no somos compiladores.

Error 2: "Esto no escala"

Correcto. ¿Y? No todo tiene que escalar. Un display neumático no está compitiendo con Times Square. Está compitiendo con la experiencia de que una persona se detenga y preste atención.

Error 3: "Es nostalgia disfrazada de arte"

Aquí me pongo más cuidadoso. Puede ser nostalgia. Pero hay una diferencia entre nostalgia y elección informada. Alguien que en 2025 construye un display neumático sabe que existen los LEDs. La elección es deliberada.

Me pregunto si los que vivimos en el stack digital — Docker, PostgreSQL, APIs, abstracciones sobre abstracciones — perdimos algo de ese contact con lo físico que estos proyectos recuperan.

Error 4: Subestimar la complejidad de control

Control de válvulas solenoides con timing preciso, manejo de presión, debouncing de señales físicas — esto no es más simple que software. Es diferente. Los bugs son literalmente audibles. Un segmento que no baja del todo es visible a tres metros. No hay logs, no hay stack trace, hay un segmento físico que no hizo lo que le pediste.

Me recuerda a cuando tiré el servidor de producción con rm -rf en mi primera semana de trabajo con Linux, a los 19. Los errores físicos tienen una calidad diferente — son innegables, están ahí, en el espacio real.

Error 5: Creer que la IA lo va a reemplazar

Vi muchos argumentos de que la IA generativa va a hacer irrelevante el hardware artístico. Mismo argumento que dieron sobre Apple y la IA on-device: la predicción obvia suele ser la equivocada. Lo físico e irrepetible tiene un valor que aumenta a medida que el mundo se llena de contenido generado.

FAQ: Display neumático y hardware artístico

¿Qué es exactamente un display neumático de segmentos?

Es un display de siete segmentos donde cada segmento es una pieza física móvil (generalmente una aleta o paleta) que se levanta o baja mediante presión de aire comprimido controlada por válvulas solenoides. A diferencia de un display LED donde los segmentos son electroluminiscentes, acá cada segmento tiene masa real, se mueve en el espacio, y produce sonido. El controlador (típicamente Arduino o ESP32) activa las válvulas correspondientes según el dígito que querés mostrar.

¿Es práctico para uso real o es solo arte?

Depende qué llamás "práctico". Para mostrar datos rápidamente a bajo costo, no, no es práctico. Para instalaciones donde querés que la información tenga presencia física — museos, espacios de performance, interfaces que quieran comunicar peso y deliberación — es perfectamente práctico. La pregunta correcta no es si es eficiente sino si cumple el objetivo comunicativo.

¿Cuánto cuesta construir uno?

No hay un número fijo, pero los componentes principales son: compresor de aire pequeño ($30-80), válvulas solenoides 12V ($3-8 por válvula, necesitás mínimo 7), tubing neumático, el mecanismo físico de los segmentos (que generalmente se fabrica con impresión 3D o corte láser), y el microcontrolador. Un prototipo de un solo dígito podría estar entre $150-300 en materiales. El costo real es el tiempo de diseño y ajuste mecánico.

¿Qué microcontrolador se recomienda para controlar las válvulas?

Arduino Uno o Mega para proyectos simples (bajo costo, fácil de debuggear). ESP32 si querés conectividad WiFi para actualizar los datos remotamente — útil si querés mostrar datos en tiempo real como temperatura, precios, o cualquier feed. La lógica de control es sencilla: digital out por pin activa la válvula. Lo complejo es el timing para transiciones suaves entre dígitos.

¿Por qué alguien elegiría esto sobre un display digital en 2025?

Varias razones no excluyentes: la experiencia sensorial completa (sonido + movimiento + presencia física), el contraste deliberado con la omnipresencia de pantallas, la calidad de atención que genera en el espectador, la unicidad del objeto, y honestamente — el placer de construir algo con física real. Hay algo en ver un segmento levantarse con aire que ninguna animación CSS va a replicar. También creo que hay una respuesta a la saturación de contenido digital: lo físico e irrepetible tiene valor creciente.

¿Existe comunidad activa de hardware artístico de este tipo?

Sí, aunque dispersa. Hackaday es el hub principal — ahí aparecen proyectos como este regularmente. r/DIY y r/electronics en Reddit. La comunidad de arte generativo tiene overlap con hardware artístico, y plataformas como Instructables documentan proyectos similares. En Argentina específicamente la comunidad de hardware artístico está creciendo alrededor de espacios como Fundación Telefónica y eventos como la Bienal de Arte y Tecnología. Es nicho pero no está solo.

Lo que este video me dejó pensando

Soy alguien que vive en el stack digital. Mis últimos proyectos son todos software — Next.js, TypeScript, PostgreSQL, Docker corriendo en Railway. La única vez que toco hardware es para diagnosticar por qué mi homelab no levanta.

Pero hay algo en estos proyectos de hardware artístico que me genera una incomodidad productiva. La misma incomodidad que sentí con la bailarina con ALS. La misma que siento cuando sonificó datos de transporte y la gente prefiere escuchar los colectivos a verlos en un mapa.

Creo que los que elegimos lo físico y lo lento no están siendo nostálgicos ni ineficientes. Están haciendo una afirmación sobre cómo queremos relacionarnos con la información.

En un mundo donde todo es instantáneo y sin fricción, que algo requiera presión de aire, válvulas que hacen click, y un segundo de delay para mostrarte un número — eso es una elección filosófica. Están diciendo: este dato merece peso. Merece espacio en el mundo real. Merece que lo esperes.

No sé si voy a construir un display neumático. Sí sé que voy a seguir pensando en la pregunta que levanta: ¿qué perdemos cuando hacemos todo más rápido, más eficiente, más digital?

El aire comprimido que levanta un segmento no tiene respuesta para eso. Pero hace la pregunta de una manera que ningún píxel puede.


Este artículo fue publicado originalmente en juanchi.dev

Top comments (0)