Solo viaja quien regresa,

quien solo huye hacia delante está realmente perdido

Músic concert

https://www.instagram.com/reel/DXzwEg1oeWm/?igsh=amJrbXY2anBieWI3

Si tienes un Furby Boom/2012 sí puede comunicarse con un PC, pero no por BLE. La vía correcta es audio ultrasónico ComAir.

La mala noticia: es menos directo que BLE.
La buena noticia: como proyecto , puede ser todavía más sorprendente, porque una app también puede comunicarse con hardware usando algo tan aparentemente simple como sonido.

---

Existen varios proyectos open source / públicos con resultados reales usando ComAir, aunque el ecosistema es más artesanal que el de BLE. El más sólido para empezar es Hacksby, y después miraría furbycomm / FurbyCmd II y Furby-KABOOM.

1. Hacksby: el candidato más serio para empezar

Hacksby es probablemente el proyecto abierto más útil para un Furby 2012. Documenta el protocolo de audio, incluye scripts para generar comandos en WAV, reproducirlos al Furby y también decodificar respuestas captadas por micrófono. El repositorio indica explícitamente que el Furby 2012 usa un protocolo de audio para comunicarse con otros Furbys y con las apps oficiales, y que el proyecto intenta analizarlo y recrearlo desde ordenador.

Lo importante: no es solo teoría. El propio README da una prueba funcional:

perl furby-send.pl 350

Según la documentación, el comando 350 debería provocar una reacción de “comida”: el Furby mastica y responde algo parecido a “mmm, yum!”.

También incluye modo interactivo:

perl furby-send.pl 350 --interactive

y herramientas para escuchar/decodificar comandos del Furby desde un micrófono o una grabación WAV.

Valor para nosotros: es la mejor base para una práctica PC → altavoz → Furby.

---

2. furbycomm: utilidades ComAir para Furby 2012/Boom

El proyecto furbycomm, en GitLab, se describe como “Furby 2012/Boom ultrasonic communication utilities”. Es especialmente interesante porque trabaja ya con la terminología ComAir y tiene código C de codificación/decodificación.

En el código fuente se ve que implementa paquetes regulares de 12 símbolos, paquetes Boost de 26 símbolos, símbolo de sincronización y frecuencia de símbolo de 50 Hz. También implementa funciones como comAirEncodePacket, comAirDecodePacket, comAirEncodeBoostPacket y comAirDecodeBoostPacket, lo que lo convierte en una referencia técnica muy útil si queremos portar la lógica a Python.

Además, hay una publicación vinculada donde el autor dice que estuvo haciendo ingeniería inversa de cómo los Furby Boom interactúan con la app mediante ComAir y que escribió un programa para leer sus estadísticas.

Valor para nosotros: muy buena base técnica para entender el protocolo y crear una implementación propia en Python.

---

3. FurbyCmd II: demostrador web con muchos comandos

FurbyCmd II es una página web pública que permite transmitir comandos ComAir. La página muestra una lista enorme de comandos ya etiquetados: juegos, estados, emociones, comida, sueño, cumpleaños, personalidad, acciones F2F, comandos desconocidos y campo de “custom code”.

El proyecto GitLab asociado se describe como “Another version of my Furby Commander thing” y está publicado mediante GitLab Pages. También aparece otro proyecto anterior, furby-commander, descrito como una aplicación JavaScript para controlar Furbys 2012.

Valor para nosotros: ideal como demostración rápida en clase: abrir navegador, elegir comando, subir volumen, transmitir.

---

4. Furby-KABOOM: app web reciente con pruebas declaradas

Furby-KABOOM es un repositorio GitHub muy reciente orientado a Furby 2012, Furby Boom y Furbacca. El README afirma que es compatible con Furbys que usan ComAir, con excepción de Party Rockers, y que ha sido probado con todas las personalidades en Furby 2012/Boom y con cinco Furbys.

También recomienda usar ordenador y poner el volumen al menos al 50–60 % para que el Furby escuche las señales.

Valor para nosotros: puede servir como demo visual y moderna, aunque yo lo usaría como validación práctica, no como base técnica principal.

---

5. Confirmación técnica: ComAir sí es el protocolo correcto

La documentación comunitaria de Furby confirma que ComAir es el protocolo ultrasónico usado por los Furby 2012 y Furby Boom para comunicarse entre sí y con las apps móviles. La página técnica de Furby Boom también indica que los Furby 2012 y Boom usan ultrasonidos para comunicarse con otros Furby y con sus respectivas apps, y que el protocolo se llama ComAir.

Técnicamente, ComAir usa una modulación ultrasónica tipo 5-tone frequency-shift keying, con frecuencias alrededor de 17–18 kHz, y transmite mensajes de 6 o 18 bits; en el uso típico, dos mensajes de 6 bits codifican un comando de 10 bits, es decir, valores de 0 a 1023.

---

Mi recomendación práctica

Para tu caso, yo montaría el proyecto en tres fases:

Fase 1: validar que tu Furby responde

Usaría primero FurbyCmd II o Furby-KABOOM desde el navegador. Objetivo: comprobar que tu Furby Boom escucha comandos ComAir desde el altavoz del PC.

Prueba rápida:

1. Furby despierto.
2. PC cerca del Furby.
3. Volumen medio-alto, sin pasarse.
4. Lanzar un comando sencillo: comida, risa, sueño o personalidad.
5. Observar si responde.

Fase 2: usar Hacksby como base técnica

Después instalaría Perl y probaría:

perl furby-send.pl 350

Si responde, ya sabemos que podemos construir una app propia encima.

Fase 3: portar a Python

A partir de ahí, el objetivo docente sería crear una librería propia:

furby_comair.py

con funciones tipo:

send_command(350)      # comida
send_command(758)      # dormir
send_command(855)      # feliz
send_command(853)      # enfadado
send_command(820)      # modo escucha

El código Python tendría que generar audio con numpy y reproducirlo con sounddevice o pyaudio.

---

Conclusión

Sí, hay proyectos abiertos con resultados demostrados. El mapa sería:

Proyecto	Mejor uso
Hacksby	Base técnica más sólida para PC y scripts
furbycomm	Referencia técnica ComAir 2012/Boom
FurbyCmd II	Demo web inmediata con muchos comandos
Furby-KABOOM	Demo reciente orientada a usuarios
Furby-2012	Ingeniería inversa más general del hardware/software

Para una práctica con alumnos, yo haría esto:

Primero demostrar con FurbyCmd II que el Furby responde. Después construir una versión propia en Python inspirada en Hacksby/furbycomm.

Eso convierte el proyecto en algo muy potente: no solo “controlar un Furby”, sino programar una aplicación que habla en ultrasonidos con un dispositivo físico real.

haz una descripción técnica, lo más completa y profesional posible de la tecnología de comunicación ComAir

Voy a construirlo como una ficha técnica profesional: modelo de capas, medio físico, modulación, trama, codificación, limitaciones y posibilidades de implementación desde PC/Python.Thought for 13s

Descripción técnica profesional de ComAir

Comunicación ultrasónica de los Furby 2012 / Furby Boom

ComAir es el nombre del protocolo de comunicación ultrasónica utilizado por los Furby 2012 y Furby Boom para comunicarse entre sí y con sus aplicaciones móviles oficiales. No es Bluetooth, no es WiFi y no es infrarrojo: es una comunicación acústica de alta frecuencia, transmitida por altavoz y recibida por micrófono. La documentación comunitaria lo atribuye a GeneralPlus, fabricante de los microcontroladores usados en esos modelos.

En términos de ingeniería, ComAir puede describirse como:

Un protocolo de comunicación inalámbrica acústica, de corto alcance, basado en tonos ultrasónicos o cuasi-ultrasónicos, que codifica comandos digitales mediante modulación por desplazamiento de frecuencia.

---

1. Idea general del sistema

El Furby no “se empareja” con el móvil o el PC. Simplemente escucha sonidos de alta frecuencia mediante su micrófono interno.

El flujo básico es:

Aplicación / PC / móvil
        ↓
Generación de tonos ultrasónicos
        ↓
Altavoz
        ↓
Aire
        ↓
Micrófono del Furby
        ↓
Demodulación interna
        ↓
Interpretación del comando
        ↓
Respuesta del Furby

Y en sentido contrario:

Furby
   ↓
Emite sonido ultrasónico junto a su reacción sonora
   ↓
Micrófono del móvil / PC
   ↓
Decodificación
   ↓
La app interpreta qué ha dicho o hecho el Furby

El proyecto Hacksby explica que el Furby 2012 usa un protocolo de audio para comunicarse con otros Furby y con las apps oficiales de iOS/Android, y que el Furby puede tanto recibir comandos como emitir comandos asociados a eventos o frases.

---

2. Naturaleza física de la comunicación

ComAir usa sonido, no radiofrecuencia. Eso tiene varias consecuencias:

Característica	Implicación técnica
Medio físico	Aire
Transmisor	Altavoz, buzzer o transductor acústico
Receptor	Micrófono
Alcance	Corto, normalmente centímetros o pocos metros
Direccionalidad	Depende del altavoz, micrófono y orientación
Robustez	Sensible a ruido ambiente, volumen y calidad del audio
Seguridad	Muy baja; cualquiera cerca puede reproducir comandos
Emparejamiento	No hay autenticación ni pairing tipo Bluetooth

La patente relacionada de GeneralPlus describe precisamente una arquitectura donde una señal de comunicación se modula en ultrasonido o cuasi-ultrasonido y se transmite usando altavoces/micrófonos ordinarios, reduciendo costes frente a tecnologías como IR, RF o Bluetooth.

---

3. Banda de frecuencias

ComAir trabaja en la zona de alta frecuencia audible / cuasi-ultrasónica, alrededor de los 17–18,6 kHz.

Según la documentación comunitaria, ComAir usa 5-tone ultrasonic frequency-shift-keying y centros de frecuencia de 17 kHz, 17,5 kHz o 18 kHz, dependiendo del modo. También se explica que por eso algunas personas pueden llegar a oírlo como un pitido molesto.

La implementación de Hacksby concreta una tabla de tonos usada para generar audio:

Símbolo	Frecuencia aproximada
0	16.386 Hz
1	16.943 Hz
X	17.500 Hz
3	18.057 Hz
2	18.614 Hz

El propio código de Hacksby define X = 17500 Hz como frecuencia central y una separación aproximada entre tonos de 557 Hz.

La elección es técnicamente inteligente: está por encima de la mayor parte del habla y de muchos ruidos cotidianos, pero todavía puede reproducirse con altavoces y micrófonos comerciales baratos.

---

4. Tipo de modulación

ComAir emplea una forma de FSK multinivel.

FSK significa Frequency Shift Keying, o modulación por desplazamiento de frecuencia. En vez de representar la información mediante niveles de tensión o bits directos, cada símbolo se representa con una frecuencia determinada.

En ComAir no se usa solo un tono para “0” y otro para “1”, sino varios tonos. Por eso se suele describir como:

5-tone FSK

Es decir, cinco posibles tonos:

0, 1, 2, 3 y X

Donde:

• 0, 1, 2 y 3 representan datos en base 4.
• X actúa como frecuencia central o símbolo auxiliar de sincronización/intercalado.
• Las frecuencias se separan aproximadamente por saltos de unos 557 Hz.

Desde el punto de vista digital, los símbolos 0, 1, 2 y 3 son muy cómodos porque cada uno representa 2 bits:

Símbolo cuaternario	Bits equivalentes
0	00
1	01
2	10
3	11

---

5. Estructura de comandos

En el uso típico, un comando ComAir se representa como un número entero de 0 a 1023. Es decir, un comando de 10 bits:

2^10 = 1024 comandos posibles

Hacksby documenta que los comandos están en el rango [0..1023], y que cada comando se divide en dos paquetes separados por una pausa de aproximadamente 0,5 segundos: el primer paquete transporta los 5 bits altos y el segundo los 5 bits bajos.

Ejemplo conceptual:

Comando decimal: 350
Binario 10 bits: 0101011110

Parte alta: 01010
Parte baja: 11110

La transmisión se hace como dos paquetes:

Paquete 1 → bits altos
Pausa
Paquete 2 → bits bajos

El wiki técnico de ComAir coincide en que, en el uso típico, dos mensajes de 6 bits codifican un comando de 10 bits, con valores de 0 a 1023.

---

6. Paquetes de 6 bits

Aunque el comando útil tiene 10 bits, ComAir trabaja internamente con grupos de 6 bits.

Hacksby lo resume así:

• Primer paquete: contiene los 5 bits altos del comando.
• Segundo paquete: contiene los 5 bits bajos.
• Cada paquete incluye además un bit que diferencia si es el primer o segundo paquete.
• Los paquetes añaden información de comprobación.

En la implementación de Packet.pm, el primer paquete se calcula con:

packet1 = command >> 5

y el segundo con:

packet2 = (command & 31) + 32

Es decir, el segundo paquete activa el sexto bit para diferenciarlo del primero.

---

7. Codificación cuaternaria

Una característica elegante de ComAir es que representa la información mediante dígitos cuaternarios.

Un grupo de 6 bits se puede expresar como tres símbolos cuaternarios:

6 bits = 3 símbolos de 2 bits

Por ejemplo:

110010

se agrupa como:

11 00 10

y se convierte en:

3 0 2

Así, un valor de 6 bits puede codificarse con tres tonos de datos.

Hacksby explica que cada paquete puede leerse como un número en sistema cuaternario usando los dígitos 0, 1, 2 y 3, y que de esa secuencia se obtienen bytes lógicos y comprobaciones.

---

8. Formato del paquete regular

A partir de la implementación de furbycomm, un paquete ComAir regular tiene 12 símbolos. El código define:

#define COMAIR_PACKET_LENGTH 12

También indica que el reloj de símbolo es de 50 Hz, por lo que cada símbolo dura aproximadamente:

1 / 50 = 0,02 s = 20 ms

La estructura lógica del paquete regular es:

[Prefijo] [Grupo de 6 bits + checksum] [Sufijo]

En furbycomm, la estructura queda:

Símbolo 0       → prefijo
Símbolos 1-7    → grupo codificado con checksum
Símbolos 8-11   → sufijo fijo

El código concreta:

packet[0] = 3;
packet[8..11] = {1, 0, 3, 2};

Por tanto, una representación profesional simplificada sería:

Paquete regular ComAir:
┌─────────┬────────────────────────────┬────────────┐
│ Prefijo │ Grupo de datos + checksum  │ Sufijo     │
│ 1 sym   │ 7 sym                      │ 4 sym      │
└─────────┴────────────────────────────┴────────────┘
Total: 12 símbolos

---

9. Checksum y detección de errores

ComAir incorpora una forma de verificación por tabla de checksums.

Hacksby indica que el segundo bloque de cuatro dígitos cuaternarios depende de los datos y se usa como checksum, aunque el algoritmo original no fue identificado; el proyecto lista los 64 checksums necesarios para reconstruir comandos arbitrarios de 0 a 1023.

furbycomm también implementa una tabla de checksums de 64 entradas, una por cada posible grupo de 6 bits.

Conceptualmente:

Valor de 6 bits → checksum de 4 símbolos

Esto permite al Furby descartar paquetes mal recibidos.

Ejemplo de estructura del grupo:

[3 símbolos de datos] + [4 símbolos de checksum]

Total:

7 símbolos

---

10. Símbolo central X y sincronización

En la descripción de Hacksby aparece un símbolo X, asociado a la frecuencia central de 17.500 Hz. Este símbolo no transporta datos directamente; se intercala entre símbolos de datos y probablemente ayuda a la decodificación, sincronización y estabilidad espectral.

La implementación de audio de Hacksby genera los paquetes intercalando símbolos con X:

0123 → X0X1X2X3X

Esto tiene sentido desde el punto de vista de procesado de señal:

• evita cambios bruscos entre tonos,
• facilita detectar el centro de frecuencia,
• ayuda a segmentar el paquete,
• reduce clics audibles,
• mejora la robustez frente a altavoces baratos.

---

11. Duración temporal

Hay dos formas complementarias de mirar el tiempo.

Según la descripción de Hacksby

Hacksby indica que cada paquete dura aproximadamente 0,5 segundos, y que los dos paquetes de un comando se separan por una pausa también significativa.

En su implementación:

• frecuencia de muestreo: 44,1 kHz,
• audio mono,
• 16 bits,
• tono base: 16 ms,
• transición entre tonos: 4 ms,
• silencios y separación entre paquetes.

Según furbycomm

furbycomm define un reloj de símbolo de 50 Hz, equivalente a 20 ms por símbolo. Un paquete regular de 12 símbolos tendría por tanto unos 240 ms de contenido simbólico, sin contar posibles elementos de sincronización, repeticiones, silencios o envolventes.

La diferencia se explica porque distintas implementaciones describen distintos niveles: paquete lógico, paquete acústico generado, silencios, símbolos intercalados y temporización completa.

---

12. Modo Boost

Además del modo regular de comandos, existe un modo más largo denominado habitualmente Boost mode.

El wiki de ComAir indica que la app de Furby Boom usa una petición especial de estado y que el Furby responde con un mensaje largo de 36 bits, llamado Boost mode.

furbycomm implementa paquetes Boost de 26 símbolos:

#define COMAIR_BOOST_PACKET_LENGTH 26

y codifica un valor de 18 bits repartido en tres grupos de 6 bits.

Esto sugiere dos niveles distintos:

Tipo	Uso	Tamaño lógico
Paquete regular	Comandos básicos	6 bits por paquete
Comando típico	Dos paquetes regulares	10 bits útiles
Boost	Estado / datos extendidos	18 bits por paquete en implementación furbycomm; la documentación comunitaria habla de respuestas largas de 36 bits

La lectura de estado de Furby Boom mediante ComAir ha sido objeto de ingeniería inversa; un autor de furbycomm afirma haber escrito un programa para leer estadísticas del Furby Boom a partir de la interacción ultrasónica con la app.

---

13. Capa de aplicación: comandos

En la capa superior, los comandos son números enteros.

Ejemplos documentados por herramientas públicas:

Comando	Acción aproximada
350	Comida / crunch
758	Dormir
820	Modo aplicación / escucha
853	Enfadado
855	Feliz
864	Eructo
865	Pedo

FurbyCmd II muestra una larga lista de comandos públicos, incluyendo comida, sueño, cumpleaños, juegos, emociones, estados de bebé, patrones y códigos desconocidos.

Hay que tener cuidado: la respuesta exacta puede depender del modelo, idioma, personalidad activa, estado interno y contexto del Furby.

Hacksby también advierte que la interpretación de comandos es compleja porque el Furby puede tener varias personalidades y responder de forma diferente según su estado.

---

14. Modo escucha

Un detalle importante: el Furby no siempre está escuchando comandos.

Hacksby indica que cuando el Furby está hablando o ejecutando acciones, ignora comandos externos. También documenta el comando 820, usado por las apps oficiales para mantenerlo en un modo de escucha durante aproximadamente un minuto, reenviándolo cada unos 40 segundos.

Esto es muy importante para una aplicación propia:

1. Despertar al Furby.
2. Esperar a que esté callado.
3. Enviar comando 820.
4. Enviar comandos de interacción.
5. Repetir 820 periódicamente si se quiere mantener la sesión.

---

15. Requisitos técnicos para implementarlo desde PC

Para transmitir ComAir desde un ordenador se necesita:

PC
Python / otro lenguaje
Generación de audio digital
Altavoz capaz de reproducir ~16-19 kHz
Furby cerca del altavoz
Volumen ajustado
Ambiente relativamente silencioso

Para recibir/decodificar ComAir se necesita:

Micrófono capaz de captar ~16-19 kHz
Grabación a 44,1 kHz o superior
Análisis espectral / Goertzel / FFT
Decodificación de símbolos
Validación con checksum
Reconstrucción del comando

Hacksby usa audio mono, 16 bits y 44,1 kHz para generar WAV, y su decodificador espera PCM mono de 44,1 kHz y 16 bits. También advierte que algunos micrófonos, especialmente integrados en webcams, aplican filtros paso bajo que eliminan las frecuencias usadas por el protocolo.

---

16. Problemas prácticos

ComAir es ingenioso, pero no es un protocolo robusto como BLE.

Limitaciones principales

Problema	Causa
No responde	Furby no está escuchando
No responde	Volumen demasiado bajo
No responde	Altavoz no reproduce bien 18 kHz
Responde mal	Ruido ambiente o reverberación
Molestia auditiva	Algunas personas oyen 17–18 kHz
Fallos al decodificar	Micrófono con filtro paso bajo
Baja bidireccionalidad	Recibir del Furby es más difícil que transmitirle
Sin autenticación	Cualquier fuente cercana puede emitir comandos

Hacksby recomienda empezar con el volumen bajo e ir subiendo poco a poco, y advierte que poner el volumen demasiado alto puede dañar los oídos.

---

17. Comparación con BLE

Aspecto	ComAir	BLE
Medio	Sonido ultrasónico	Radiofrecuencia 2,4 GHz
Hardware necesario	Altavoz y micrófono	Chip Bluetooth
Emparejamiento	No	Sí, opcional según dispositivo
Dirección	Bidireccional posible, pero limitada	Bidireccional robusta
Alcance	Corto	Varios metros
Robustez	Media-baja	Alta
Seguridad	Baja	Mayor
Implementación desde PC	Generación/decodificación de audio	Librería BLE tipo bleak
Valor docente	Muy alto en señal/audio	Muy alto en comunicaciones inalámbricas modernas

La diferencia conceptual clave es:

BLE: el PC escribe datos en una característica GATT.

ComAir: el PC reproduce una señal acústica que el Furby interpreta como datos.

---

18. Arquitectura por capas

Una forma profesional de documentar ComAir sería esta:

Capa de aplicación
    Comandos: 0–1023, estados, comida, juegos, emociones, escucha

Capa de paquete
    División en grupos de 6 bits
    Dos paquetes para comandos de 10 bits
    Paquetes Boost para datos extendidos

Capa de codificación
    Representación cuaternaria
    Checksum por tabla
    Prefijo y sufijo

Capa de modulación
    5-tone FSK
    Frecuencias alrededor de 17–18,6 kHz
    Símbolo central X
    Transiciones suavizadas

Capa física
    Altavoz → aire → micrófono
    Corto alcance
    Sensible a ruido y calidad del hardware

---

19. Esquema de transmisión de un comando

Ejemplo conceptual:

Comando decimal
      ↓
Comando de 10 bits
      ↓
Separación en dos bloques de 5 bits
      ↓
Conversión a dos grupos de 6 bits
      ↓
Codificación cuaternaria
      ↓
Añadir checksum
      ↓
Añadir prefijo y sufijo
      ↓
Convertir símbolos a tonos
      ↓
Generar audio
      ↓
Reproducir por altavoz
      ↓
Furby lo recibe por micrófono

---

20. Valor técnico de ComAir

ComAir es una solución muy interesante porque convierte un juguete barato en un sistema con comunicación inalámbrica sin añadir radiofrecuencia.

Desde el punto de vista de ingeniería, combina:

procesado digital de señal,
modulación FSK,
codificación de símbolos,
detección de errores,
audio digital,
sistemas embebidos,
interacción humano-máquina,
protocolos propietarios,
ingeniería inversa,
comunicación máquina-máquina.

Como práctica docente, es incluso más sorprendente que BLE porque obliga a los alumnos a entender que un sonido también puede ser un paquete de datos.

---

Definición técnica final

ComAir es un protocolo propietario de comunicación acústica ultrasónica o cuasi-ultrasónica, usado por Furby 2012 y Furby Boom, que transmite comandos digitales mediante tonos de alta frecuencia alrededor de 17–18,6 kHz. Utiliza una modulación tipo FSK multinivel, símbolos cuaternarios, paquetes con prefijo, sufijo y checksum, y permite tanto el envío de comandos al Furby como la emisión de eventos desde el Furby hacia una aplicación. Su implementación aprovecha altavoces y micrófonos ordinarios, lo que reduce el coste del hardware, aunque a cambio presenta limitaciones de alcance, fiabilidad, sensibilidad al ruido y ausencia de autenticación.

Te imaginas, poder comunicarte desde tu ordenador con tu Furby?

Sí, es posible. Pero aquí conviene tener en cuenta que se pretende controlar un elemento Bluetooth:

Para controlar un Furby, al ser inalámbrico no usaría librerías habituales como PyUSB, porque PyUSB es solo para conexiones de tipo USB. Para un Furby Connect lo correcto es Bluetooth Low Energy —BLE— con Python y la librería bleak.

La propuesta sería:

Windows 10/11
   ↓
Adaptador Bluetooth 4.0 o superior
   ↓
Bluetooth Low Energy / GATT
   ↓
Python 3.11+
   ↓
bleak
   ↓
Furby Connect

1. Primero: tenemos que descubrir qué Furby queremos controlar

No todos los Furby se comunican igual. Según la documentación técnica recopilada por la comunidad Furby, las generaciones usan sistemas incompatibles: los Furby de 1998 usan infrarrojos, los de 2012/Boom usan ultrasonidos mediante ComAir, los Furby Connect 2016-2017 usan Bluetooth, y los modelos más recientes usan señales sonoras o infrarrojos según generación. (official-furby.fandom.com)

Por tanto, para Windows + Python + comunicación inalámbrica, la opción más razonable es:

Furby Connect, no Furby 2012 ni Furby Boom.

El proyecto bluefluff documenta que Furby Connect usa Bluetooth Low Energy y que se pueden controlar acciones, color de antena, retroiluminación LCD, estados de ánimo y sensores. (GitHub)

2. Librería recomendada: bleak

Para Windows, la librería adecuada es Bleak, no PyUSB. Bleak es un cliente GATT para dispositivos Bluetooth Low Energy y permite escanear, conectar, leer, escribir características y suscribirse a notificaciones. Además, soporta Windows 10 versión 16299 o superior. (Bleak)

Instalación en PowerShell:

py -m venv .venv
.\.venv\Scripts\activate
python -m pip install --upgrade pip
pip install bleak

Comprueba la versión:

python --version
pip show bleak

3. Entorno físico recomendado

Necesitas:

PC con Windows 10/11
Bluetooth 4.0 o superior
Python 3.11 o superior
Furby Connect con pilas nuevas
Furby despierto y no conectado a la app oficial

Recomendaciones prácticas:

1. Usa pilas nuevas. El Furby Connect consume bastante.
2. Apaga Bluetooth en móviles cercanos que hayan usado la app oficial.
3. Despierta el Furby antes de escanear.
4. Acércalo al PC durante las primeras pruebas.
5. No empieces subiendo DLC ni modificando memoria interna; primero solo escaneo, conexión y color de antena.

4. UUID importantes del Furby Connect

El servicio interesante se suele llamar Fluff Service:

dab91435-b5a1-e29c-b041-bcd562613bde

Características relevantes:

GeneralPlusListen:
dab91382-b5a1-e29c-b041-bcd562613bde

GeneralPlusWrite:
dab91383-b5a1-e29c-b041-bcd562613bde

NordicListen:
dab90756-b5a1-e29c-b041-bcd562613bde

NordicWrite:
dab90757-b5a1-e29c-b041-bcd562613bde

FileWrite:
dab90758-b5a1-e29c-b041-bcd562613bde

La documentación de PyFluff/bluefluff indica que GeneralPlusWrite se usa para enviar comandos al Furby, y que esos comandos son arrays de bytes de hasta 20 bytes, donde el primer byte define el tipo de comando. (GitHub)

5. Estructura de proyecto propuesta

furby-connect-control/
│
├── scan_furby.py
├── furby_ble.py
├── demo_antenna.py
└── requirements.txt

requirements.txt:

bleak

6. Script 1: escanear dispositivos BLE

Guarda esto como scan_furby.py:

import asyncio
from bleak import BleakScanner

FURBY_SERVICE = "dab91435-b5a1-e29c-b041-bcd562613bde"

async def main():
    print("Escaneando dispositivos BLE durante 10 segundos...\n")

    devices = await BleakScanner.discover(
        timeout=10.0,
        return_adv=True
    )

    for address, (device, adv) in devices.items():
        name = device.name or adv.local_name or "Sin nombre"
        services = adv.service_uuids or []

        print(f"Nombre: {name}")
        print(f"Dirección: {device.address}")
        print(f"RSSI: {adv.rssi}")
        print(f"Servicios: {services}")
        print("-" * 60)

        if FURBY_SERVICE.lower() in [s.lower() for s in services]:
            print(">>> Posible Furby Connect encontrado")
            print(f">>> Dirección: {device.address}")
            print("-" * 60)

if __name__ == "__main__":
    asyncio.run(main())

Ejecución:

python scan_furby.py

Resultado esperado aproximado:

Nombre: Furby
Dirección: XX:XX:XX:XX:XX:XX
Servicios: ['dab91435-b5a1-e29c-b041-bcd562613bde']
>>> Posible Furby Connect encontrado

Bleak permite usar BleakScanner para escuchar anuncios BLE y obtener dispositivos detectados, datos de advertising y UUIDs de servicio. (Bleak)

7. Script 2: clase mínima para controlar el Furby

Guarda esto como furby_ble.py:

import asyncio
from bleak import BleakScanner, BleakClient

FURBY_SERVICE = "dab91435-b5a1-e29c-b041-bcd562613bde"

GENERAL_PLUS_LISTEN = "dab91382-b5a1-e29c-b041-bcd562613bde"
GENERAL_PLUS_WRITE = "dab91383-b5a1-e29c-b041-bcd562613bde"

NORDIC_LISTEN = "dab90756-b5a1-e29c-b041-bcd562613bde"
NORDIC_WRITE = "dab90757-b5a1-e29c-b041-bcd562613bde"


class FurbyConnect:
    def __init__(self):
        self.device = None
        self.client = None

    async def find(self, timeout=10.0):
        print("Buscando Furby Connect...")

        def is_furby(device, adv):
            services = adv.service_uuids or []
            return FURBY_SERVICE.lower() in [s.lower() for s in services]

        self.device = await BleakScanner.find_device_by_filter(
            is_furby,
            timeout=timeout
        )

        if self.device is None:
            raise RuntimeError(
                "No se ha encontrado ningún Furby Connect. "
                "Comprueba que esté despierto, cerca y con pilas nuevas."
            )

        print(f"Furby encontrado: {self.device.name} / {self.device.address}")
        return self.device

    async def connect(self):
        if self.device is None:
            await self.find()

        self.client = BleakClient(self.device)
        await self.client.connect()

        if not self.client.is_connected:
            raise RuntimeError("No se ha podido conectar al Furby.")

        print("Conectado al Furby Connect.")

        await self.client.start_notify(
            GENERAL_PLUS_LISTEN,
            self._on_generalplus_notify
        )

    async def disconnect(self):
        if self.client and self.client.is_connected:
            try:
                await self.client.stop_notify(GENERAL_PLUS_LISTEN)
            except Exception:
                pass

            await self.client.disconnect()
            print("Desconectado.")

    def _on_generalplus_notify(self, sender, data):
        hex_data = " ".join(f"{b:02X}" for b in data)
        print(f"[GeneralPlus] {hex_data}")

    async def write_generalplus(self, data: bytes):
        if not self.client or not self.client.is_connected:
            raise RuntimeError("El Furby no está conectado.")

        await self.client.write_gatt_char(
            GENERAL_PLUS_WRITE,
            data,
            response=True
        )

    async def set_antenna_color(self, red: int, green: int, blue: int):
        """
        Controla el LED RGB de la antena.
        Comando GeneralPlus 0x14 + RGB.
        """
        red = max(0, min(255, red))
        green = max(0, min(255, green))
        blue = max(0, min(255, blue))

        command = bytes([0x14, red, green, blue])
        await self.write_generalplus(command)

    async def trigger_action_specific(
        self,
        input_id: int,
        index: int,
        subindex: int,
        specific: int
    ):
        """
        Lanza una acción específica.
        Basado en el comando 0x13:
        0x13 0x00 input index subindex specific
        """
        command = bytes([
            0x13,
            0x00,
            input_id & 0xFF,
            index & 0xFF,
            subindex & 0xFF,
            specific & 0xFF
        ])

        await self.write_generalplus(command)

8. Script 3: demo segura de color de antena

Guarda esto como demo_antenna.py:

import asyncio
from furby_ble import FurbyConnect


async def main():
    furby = FurbyConnect()

    try:
        await furby.find()
        await furby.connect()

        print("Rojo")
        await furby.set_antenna_color(255, 0, 0)
        await asyncio.sleep(2)

        print("Verde")
        await furby.set_antenna_color(0, 255, 0)
        await asyncio.sleep(2)

        print("Azul")
        await furby.set_antenna_color(0, 0, 255)
        await asyncio.sleep(2)

        print("Blanco")
        await furby.set_antenna_color(255, 255, 255)
        await asyncio.sleep(2)

        print("Apagado")
        await furby.set_antenna_color(0, 0, 0)

    finally:
        await furby.disconnect()


if __name__ == "__main__":
    asyncio.run(main())

Ejecución:

python demo_antenna.py

9. Qué comandos podemos enviar

La documentación técnica indica que el comando 0x14 sirve para establecer el color RGB de la antena, 0x13 para disparar una acción específica, 0x24 para modificar estados como excitación, cansancio, hambre o bienestar, y otros comandos permiten gestionar DLC o acceder a estados internos. (GitHub)

Para una primera fase, yo limitaría el proyecto a:

Fase 1: escaneo BLE
Fase 2: conexión
Fase 3: lectura de servicios
Fase 4: color de antena
Fase 5: recepción de notificaciones
Fase 6: acciones preprogramadas
Fase 7: sensores
Fase 8: integración con una aplicación propia

No tocaría todavía:

Subida de DLC
Borrado de slots
Modificación persistente
Actualizaciones
Manipulación de firmware

10. Diagnóstico de problemas típicos en Windows

Problema	Causa probable	Solución
No aparece el Furby	Está dormido	Despertarlo y repetir escaneo
Aparece pero no conecta	Conectado al móvil o app oficial	Apagar Bluetooth del móvil
Se desconecta	Pilas bajas	Cambiar pilas
No aparecen servicios	Caché BLE de Windows	Quitar dispositivo en Bluetooth y volver a escanear
BleakError	Bluetooth inestable	Reiniciar adaptador o PC
No responde a comandos	No es Furby Connect	Verificar modelo

La demo FurBLE también recomienda cambiar pilas si hay desconexiones o comportamientos extraños, y reiniciar el Furby si rechaza conexiones. (pdjstone.github.io)

11. Propuesta de aplicación docente

Podrías montar una práctica muy interesante:

Práctica: Control inalámbrico de un juguete interactivo mediante BLE

Objetivos:
1. Escanear dispositivos BLE.
2. Identificar servicios y características GATT.
3. Conectarse a un periférico.
4. Enviar comandos binarios.
5. Recibir notificaciones.
6. Relacionar protocolo, actuadores y comportamiento físico.

Aplicaciones:

Indicador físico de estado de una clase
Notificador de compilaciones
Mascota robótica controlada desde Python
Interfaz tangible para videojuegos
Ejemplo de ingeniería inversa responsable
Práctica de BLE + GATT + Python

12. Conclusión técnica

La propuesta equivalente al control del i-Buddy sería:

i-Buddy:
Windows + Python + PyUSB + USB HID

Furby Connect:
Windows + Python + Bleak + Bluetooth Low Energy / GATT

Para empezar de forma segura, yo prepararía el entorno con Python 3.11+, Bleak, escaneo BLE y control del LED de antena. Una vez validado eso, ya pasaría a acciones, sensores y automatizaciones.

---

MOTIVACIÓN, llamada a la acción

Propuesta docente: “Haz que un Furby cobre vida con tu app”

Título de la actividad

FURBY HACK LAB

Programa una mascota interactiva real con Python, Bluetooth y diseño de videojuegos

---

Mensaje para los alumnos

Imaginad que no estáis programando una práctica más.

Imaginad que vuestra aplicación no se queda dentro de la pantalla, sino que controla un juguete real, con luces, movimientos, reacciones, estados de ánimo y comportamiento físico.

Ese es el reto: crear una aplicación capaz de comunicarse inalámbricamente con un Furby Connect mediante Bluetooth Low Energy.

No se trata solo de “hacer que algo funcione”. Se trata de diseñar una experiencia interactiva donde el Furby se convierta en:

• una mascota virtual-física,
• un personaje no jugable del mundo real,
• un indicador emocional,
• un periférico alternativo,
• una interfaz tangible,
• o incluso un actor dentro de un videojuego.

La pregunta no es solo:

“¿Podemos controlar un Furby?”

La pregunta interesante es:

“¿Qué experiencia podemos diseñar cuando un personaje físico responde a nuestra aplicación?”

---

El reto

Vais a crear una aplicación que se comunique con un Furby de forma inalámbrica. Para ello usaréis conceptos reales de ingeniería y desarrollo:

Python
Bluetooth Low Energy
GATT
Servicios y características BLE
Comandos binarios
Eventos
Sensores
Interacción física
Diseño de experiencia de usuario

El Furby dejará de ser un juguete cerrado y pasará a ser un dispositivo interactivo programable.

---

¿Qué se espera que podáis hacer?

Como mínimo, vuestra aplicación debería ser capaz de:

1. Detectar el Furby

La app deberá escanear dispositivos Bluetooth cercanos y encontrar el Furby Connect.

Resultado visual esperado:

Buscando dispositivos BLE...
Furby encontrado.
Conectando...
Conexión establecida.

Esto ya introduce una idea clave: la aplicación descubre dispositivos del mundo físico.

---

2. Conectarse inalámbricamente

Una vez detectado, la app debe establecer conexión con el Furby mediante Bluetooth Low Energy.

Aquí ya no hablamos de enchufar un cable USB. Hablamos de comunicación inalámbrica real, como la que usan pulseras deportivas, sensores médicos, dispositivos domóticos o mandos modernos.

---

3. Controlar elementos visuales

La primera función espectacular será controlar la antena RGB del Furby.

Por ejemplo:

Estado de la app	Color del Furby
Conectando	Azul intermitente
Todo correcto	Verde
Error	Rojo
Modo juego	Morado
Alerta	Rojo + parpadeo
Evento especial	Arcoíris

Aquí aparece una idea potente para videojuegos:

El Furby puede convertirse en una luz ambiental física que representa el estado del juego.

---

4. Ejecutar acciones

El siguiente nivel será lanzar comportamientos o acciones del Furby: movimientos, reacciones o respuestas preprogramadas.

La app podría hacer que el Furby reaccione cuando:

• el jugador gana,
• el jugador pierde,
• ocurre un evento importante,
• se recibe una notificación,
• se supera un reto,
• el usuario pulsa un botón,
• cambia el estado emocional de la aplicación.

En vez de mostrar solo un mensaje en pantalla, la aplicación puede hacer que un personaje físico reaccione.

---

5. Leer respuestas o notificaciones

La comunicación no tiene por qué ser solo de la app al Furby. También puede haber información que vuelva desde el dispositivo.

Eso permite pensar en el Furby no solo como “muñeco controlado”, sino como periférico interactivo.

---

Ideas de aplicaciones espectaculares

Aquí está la parte importante: no queremos una demo técnica aburrida. Queremos que el resultado parezca una aplicación real, atractiva y con personalidad.

1. Furby como mascota de escritorio inteligente

Una app donde el Furby reacciona al estado del usuario o del ordenador.

Ejemplos:

Tienes clase → Furby se pone azul.
Hay una tarea pendiente → Furby se pone amarillo.
Has terminado una actividad → Furby celebra.
Hay un error → Furby se enfada.
Modo concentración → Furby se queda tranquilo.

Resultado espectacular: el Furby se convierte en una mascota física de productividad.

---

2. Furby como personaje no jugable físico

La aplicación puede ser un pequeño videojuego donde el Furby representa a un personaje externo al ordenador.

Por ejemplo:

“El Furby es el guardián del laboratorio. El jugador tiene que resolver pruebas y, según lo que ocurra, el Furby cambia de color, reacciona o celebra.”

Resultado espectacular: un videojuego donde uno de los personajes existe fuera de la pantalla.

---

3. Furby como jefe final

La app podría plantearse como un minijuego:

El Furby está dormido.
El jugador debe superar pruebas.
Cada acierto cambia su estado.
Cada fallo lo enfada.
Al final, el Furby despierta o se calma.

Puede haber niveles, puntuación, sonidos, luces y eventos.

Resultado espectacular: una experiencia híbrida entre videojuego, escape room y juguete interactivo.

---

4. Furby como indicador emocional de una IA

La app puede conectarse a una lógica conversacional sencilla o a un sistema de estados:

Estado emocional	Reacción
Contento	Verde
Enfadado	Rojo
Triste	Azul
Nervioso	Amarillo intermitente
Sorprendido	Blanco
Modo fiesta	Secuencia RGB

Resultado espectacular: el Furby funciona como avatar físico emocional.

Esto conecta muy bien con diseño de personajes, narrativa interactiva y experiencia de usuario.

---

5. Furby como periférico alternativo de videojuegos

El Furby puede actuar como salida física del juego.

Ejemplos:

Vida baja → antena roja.
Energía cargada → antena verde.
Peligro cercano → parpadeo rápido.
Misión completada → celebración.
Modo sigilo → luz azul tenue.

Resultado espectacular: el alumno diseña un sistema de feedback háptico/visual externo al videojuego.

Esto es especialmente interesante para diseño de videojuegos porque obliga a pensar más allá de la pantalla.

---

6. Furby como “streamer companion”

Una aplicación tipo compañero de directo:

Nuevo seguidor → Furby se ilumina.
Donación → Furby celebra.
Mensaje importante → Furby reacciona.
Alerta técnica → Furby cambia a rojo.

Resultado espectacular: el Furby se convierte en un dispositivo de notificaciones físicas para streaming.

---

7. Furby como escape room físico-digital

La aplicación puede plantear una historia:

“El Furby guarda un secreto. Para desbloquearlo, hay que resolver pruebas desde la app. Cada prueba modifica su comportamiento.”

Ejemplo de fases:

Fase 1: detectar al Furby.
Fase 2: activar color correcto.
Fase 3: resolver secuencia.
Fase 4: desbloquear reacción.
Fase 5: final narrativo.

Resultado espectacular: mezcla de programación, narrativa, interacción física y juego.

---

Qué hace que este proyecto sea atractivo

Este proyecto tiene algo que muchas prácticas no tienen:

Se ve. Se toca. Reacciona.

No es solo código en consola.

Cuando el código funciona, ocurre algo en el mundo real:

La antena cambia de color.
El Furby responde.
El personaje parece vivo.
La app controla un objeto físico.

Eso produce una recompensa inmediata. El alumno ve que su programa tiene consecuencias físicas.

Y eso engancha.

---

Versión tipo “pitch” para clase

Podrías presentarlo así:

En esta práctica no vais a programar una calculadora, ni una pantalla de login, ni una app que solo muestra datos.

Vais a programar una aplicación capaz de comunicarse con un personaje físico real.

Vuestro reto será convertir un Furby Connect en una mascota interactiva controlada por software. Tendréis que descubrirlo por Bluetooth, conectaros a él, enviarle comandos, controlar sus luces y diseñar una experiencia que tenga sentido.

No gana el proyecto que solo consiga encender una luz. Gana el proyecto que consiga que el Furby parezca formar parte de una experiencia: un juego, una historia, una alerta, una mascota, un asistente o un personaje.

La parte técnica es importante, pero la parte creativa lo es todavía más: ¿qué haréis con un personaje físico que podéis controlar desde vuestra aplicación?

---

Qué deberían entregar los alumnos

Entrega mínima

Una aplicación que:

1. Escanee dispositivos BLE.
2. Detecte el Furby.
3. Se conecte correctamente.
4. Cambie el color de la antena.
5. Ejecute al menos una secuencia de comportamiento.
6. Tenga una interfaz mínima o menú de control.

Entrega buena

Una aplicación que:

1. Tenga interfaz gráfica.
2. Permita seleccionar estados.
3. Incluya varios modos de comportamiento.
4. Gestione errores de conexión.
5. Documente el protocolo usado.
6. Incluya vídeo demostrativo.

Entrega excelente

Una aplicación que:

1. Proponga una experiencia completa.
2. Integre narrativa, juego o utilidad real.
3. Use estados emocionales.
4. Reaccione a eventos externos.
5. Cuide la interfaz de usuario.
6. Presente una demo espectacular y comprensible.

---

Ejemplo de aplicación tipo ideal

Nombre

Furby Mood Controller

Idea

Una aplicación que convierte al Furby en una mascota emocional conectada al ordenador.

Funciones

Modo feliz → antena verde + reacción positiva.
Modo enfadado → antena roja + reacción intensa.
Modo sueño → antena azul tenue.
Modo fiesta → secuencia RGB.
Modo alerta → parpadeo rojo.
Modo juego → colores según puntuación.

Pantalla principal

[Conectar Furby]

Estado: Conectado

[ Feliz ] [ Triste ] [ Alerta ] [ Fiesta ] [ Dormir ]

Color personalizado:
R: ___  G: ___  B: ___

[Enviar color]
[Ejecutar secuencia]
[Desconectar]

Resultado visual

El profesor pulsa “Fiesta” y el Furby cambia de colores.

El alumno activa “Alerta” y el Furby se ilumina en rojo.

El juego detecta que el jugador ha ganado y el Furby celebra.

Eso es mucho más memorable que imprimir:

Victoria

en una consola.

---

Lo que aprenderán sin darse cuenta

Aunque parezca una actividad divertida, en realidad toca muchos contenidos serios:

Área	Aprendizaje
Programación	Python, funciones, clases, asincronía
Comunicaciones	Bluetooth Low Energy, GATT, UUID
Ingeniería	protocolo, comandos, pruebas, errores
Videojuegos	feedback, estados, narrativa, eventos
UX	diseño de interacción física
Robótica ligera	actuadores, respuesta externa
Creatividad	convertir tecnología en experiencia

La gracia es que el alumno no estudia BLE como teoría aislada. Lo aprende porque quiere que el Furby responda.

---

Enfoque de Aprendizaje Basado en Proyectos

La actividad puede formularse así:

Problema inicial

Tenemos un dispositivo interactivo real, pero no queremos usar su app oficial. Queremos diseñar nuestra propia aplicación para comunicarnos con él y crear una experiencia nueva.

Producto final

Una aplicación funcional que controle un Furby Connect de forma inalámbrica y lo integre en una experiencia interactiva.

Pregunta guía

¿Cómo podemos transformar un juguete comercial en un personaje interactivo programable?

---

Criterios para que el proyecto sea espectacular

Para que una demo destaque, no basta con decir “hemos cambiado el color”.

Debe haber intención.

Demo normal

Pulso un botón.
El Furby se pone rojo.

Demos interesantes

El jugador falla una prueba.
La app detecta el fallo.
El Furby se pone rojo.
El Furby reacciona.
La interfaz muestra que está enfadado.
El jugador debe calmarlo.

La diferencia está en el diseño de la experiencia de usuario.

---

Ideas de nombres para proyectos de alumnos

Furby Mood Lab
Furby Game Master
Furby Quest
Furby Companion
Furby Alert
Furby Boss Fight
Furby Escape Room
Furby Stream Buddy
Furby Classroom Guardian
Furby Emotional Engine

---

Frase de cierre:

Este proyecto no consiste en controlar un Furby.

Consiste en demostrar que sabéis conectar software, hardware, comunicación inalámbrica, diseño de interacción y creatividad para construir una experiencia que sorprenda.

Cuando vuestro código haga que un objeto físico reaccione, habréis cruzado una frontera importante: la frontera entre programar una pantalla y programar el mundo real.

LeoCAD

Design virtual models you can build with LEGO® bricks

Diseña modelos virtuales que puedas construir con ladrillos LEGO®.

https://www.leocad.org

Fácil de usar

LeoCAD cuenta con una interfaz intuitiva diseñada para que los nuevos usuarios puedan empezar a crear nuevos modelos sin tener que dedicar demasiado tiempo a aprender a usar la aplicación.

Al mismo tiempo, cuenta con un amplio conjunto de funciones que permite a los usuarios experimentados crear modelos utilizando técnicas más avanzadas.

Compatible con LDraw

LeoCAD es totalmente compatible con el estándar LDraw y las herramientas relacionadas, y lee y escribe archivos LDR y MPD para que puedas compartir y descargar modelos de Internet.

También utiliza la biblioteca de piezas LDraw, que cuenta con más de 10.000 piezas diferentes y que recibe actualizaciones constantemente.

Multiplataforma, código abierto

Existen versiones nativas para Windows, Linux y macOS para garantizar que los usuarios estén familiarizados con la interfaz del programa.

LeoCAD es de código abierto, por lo que cualquiera puede contribuir con correcciones y nuevas funciones, y siempre seguirá siendo gratuito.

Microsoft acaba de soltar una impresionante solución en la generación de modelos 3D:

Su software se llama TRELLIS.2 y es uno de los modelos Image-to-3D más potentes y abiertos del momento.

¿Qué hace?

Convierte una sola imagen en un modelo 3D completo

Genera mallas de alta resolución (hasta 1536³)

Incluye texturas PBR completas (color, brillo, metálico, rugosidad…)

Usa una nueva estructura llamada O-Voxel que permite geometrías complejas, bordes nítidos y topología rica

Características clave:

4 mil millones de parámetros

Open-source (código + pesos disponibles)

Compresión espacial 16× muy eficiente

Ideal para videojuegos, VFX, prototipado, impresión 3D y diseño de productos

Microsoft lo ha liberado con todo: código en GitHub, demo en Hugging Face y artículo técnico.

¿Qué pasa con el futuro de la creación 3D?

Ya está aquí y es open-source.

¿Qué te parece? ¿Lo probarías para crear tus assets de juegos, productos o simplemente arte en 3D?

#TRELLIS2 #Microsoft #AI #GenerativeAI #3D #ImageTo3D #OpenSource

---

“Genera mallas de alta resolución (hasta 1536³)” significa lo siguiente:

¿Qué es 1536³?

• Es una rejilla de vóxeles (voxel grid) de 1536 × 1536 × 1536.
• Es decir, el modelo divide el espacio 3D en una caja virtual con más de 3.5 mil millones de celditas (vóxeles).
• Cuanto más grande es este número, mayor detalle puede tener la geometría del objeto 3D.

Comparación para que se entienda mejor:

Resolución	Nivel de detalle	Tiempo aproximado (en H100)
512³	Bajo / Básico	~3 segundos
1024³	Bueno (usado normalmente)	~17 segundos
1536³	Muy alto / Alta resolución	~60 segundos

¿Qué significa en la práctica?

• 1536³ permite generar modelos 3D con mucho más detalle fino: bordes afilados, superficies complejas, texturas pequeñas, arrugas, relieves, etc.
• Después de crear esta rejilla de vóxeles de alta resolución, el modelo extrae una malla (mesh) de polígonos (normalmente en formato .glb o .obj) que ya tiene buena topología y se puede usar directamente en Unity, Unreal Engine, Blender, etc.
• También genera texturas PBR (color, rugosidad, metálico, opacidad) de alta calidad que acompañan a esa malla.

En resumen: “Genera mallas de alta resolución (hasta 1536³)” quiere decir que TRELLIS.2 es capaz de crear objetos 3D con un nivel de detalle geométrico muy superior al de la mayoría de modelos Image-to-3D actuales, llegando hasta una precisión de 1536 vóxeles por lado.Esto es especialmente útil para:

• Assets de videojuegos de alta calidad
• Modelos para VFX / cine
• Diseño de productos
• Impresión 3D

¿Quieres que te explique también qué es el O-Voxel o cómo se compara con otros modelos como TripoSR, Luma Genie o Meshy?

---

Comparación clara: TRELLIS.2 vs TripoSR vs Luma GenieAquí tienes una comparación actualizada (2026) entre los tres modelos de generación 3D a partir de imagen o texto:

Aspecto	TRELLIS.2 (Microsoft)	TripoSR / Tripo AI	Luma Genie (Luma AI)
Tipo principal	Image-to-3D (solo imagen)	Image-to-3D y Text-to-3D	Principalmente Text-to-3D (también acepta imagen)
Resolución máxima	Hasta 1536³ (voxel grid) – Muy alta detalle	Media-Alta (generalmente inferior a 1536³)	Media (enfocado en velocidad más que resolución extrema)
Calidad de geometría	Excelente en detalles finos, bordes nítidos y topologías complejas (mejor en pruebas recientes)	Buena, con retopología limpia y meshes listos para producción	Buena para conceptos rápidos, pero topology irregular (a menudo necesita limpieza en Blender)
Texturas	PBR completas de alta calidad (color, rugosidad, metálico, transparencia)	Buenas texturas PBR y HD	Texturas decentes, pero menos consistentes que TRELLIS.2
Velocidad	3s (512³) / 17s (1024³) / ~60s (1536³) en H100	Muy rápida (10-30 segundos en versiones estándar)	Extremadamente rápida en previews (~10s), refinamiento más lento
Open Source / Local	Sí (código + pesos disponibles en GitHub y HF)	TripoSR es open-source, pero la versión completa de Tripo AI es comercial	Cerrado (propietario de Luma AI)
Mejor para	Alta fidelidad, objetos complejos, VFX, impresión 3D, assets detallados	Producción de juegos (clean topology, rigging), uso diario	Ideación rápida, conceptos rápidos, prototipado veloz
Ventajas	Máxima resolución y detalle geométrico, open-source, excelente con superficies abiertas y transparencia	Pipeline completo (retopología + rigging), muy práctico para game dev	Velocidad extrema, fácil de usar, bueno para brainstorming
Desventajas	Alto consumo de VRAM en máxima resolución (32GB+ para 1536³), mesh muy denso (muchos polígonos)	Calidad geométrica algo inferior a TRELLIS.2 en detalles finos	Menos detalle geométrico y topología menos limpia para producción

Resumen rápido:

• TRELLIS.2 destaca claramente en calidad y resolución máxima (1536³). Es el ganador actual en detalle geométrico y fidelidad cuando usas una sola imagen buena. Ideal si quieres el mejor resultado posible y puedes correrlo localmente o pagar por GPU potente.
• TripoSR / Tripo AI es más equilibrado y práctico para workflows profesionales (especialmente juegos), gracias a su retopología limpia y herramientas adicionales como rigging.
• Luma Genie es el rey de la velocidad para generar ideas rápidas, pero suele requerir más post-producción porque la topología no es tan profesional.

Conclusión actual (a fecha de abril 2026): Si buscas la máxima calidad y detalle → TRELLIS.2 es la mejor opción ahora mismo, especialmente siendo open-source.
Si necesitas assets listos para producción con buena topología → Tripo AI suele ser más recomendado.
Si quieres generar muchas ideas en segundos → Luma Genie.

---

Sánchez, con S de SANCHEZ

https://youtube.com/playlist?list=OLAK5uy_k_mZoJ3A2SYNxQZwYihcOokiFOr9Nxb7M&si=V3JZHZvXLd6iwdjs

El álbum La verdad o la imaginación (2026) de Fangoria marca el regreso de Alaska y Nacho Canut al formato de larga duración con canciones inéditas tras una década. [1, 2]

Productor

El disco ha sido producido íntegramente por el holandés Matt Pop, quien ha aportado un sonido enfocado al eurodance, el techno melódico y el pop electrónico bailable. Además, existe una colaboración especial con Rojuu para un formato corto de cuatro canciones más oscuras que se incluye en la edición especial.

Lista de canciones

El álbum estándar se compone de 12 temas, entre los que destacan: [2, 3, 5, 6, 7]

• Me voy (primer sencillo)
• La verdad o la imaginación
• El síndrome de París
• Bailo
• Todo existe a la vez
• Consecuencias
• El punto de partida
• El beso que jamás te pude dar
• La sombra
• Tigres de escayola
• Pasará
• Cada quien con su cual

En la edición especial en vinilo, se añade un CD exclusivo con 4 temas producidos por Jon Klein junto a Rojuu, incluyendo una versión de “Heroes” de David Bowie.

-> Generado con IA.

“Pillarse los dedos” puede tener habitualmente dos sentidos por lo menos:

1. Literalmente: hacerse daño atrapándose los dedos con una puerta, cajón, máquina, etc.
Ejemplo: Me he pillado los dedos con el asiento abatible de una furgoneta.


2. Figurado: comprometerse demasiado, arriesgarse o quedar mal por haber dicho/prometido algo que luego puede volverse en contra.
Ejemplo: No quiero pillarme los dedos dando una fecha exacta.

También se usa mucho en negativo:

“No pillarse los dedos” = ser prudente, no comprometerse demasiado.
Ejemplo: El profesor no se quiso pillar los dedos y dijo que la nota saldría “tan pronto como fuera posible, en los próximos días”.

https://www.premiosgoya.com/pelicula/el-viaje-a-ninguna-parte/

» Premios Goya

Cómicos de la legua