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 350Segú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 --interactivey 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 350Si 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.pycon funciones tipo:
send_command(350) # comida
send_command(758) # dormir
send_command(855) # feliz
send_command(853) # enfadado
send_command(820) # modo escuchaEl 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 FurbyY 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 FurbyEl 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 FSKEs decir, cinco posibles tonos:
0, 1, 2, 3 y XDonde:
0,1,2y3representan datos en base 4.Xactú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 posiblesHacksby 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: 11110La transmisión se hace como dos paquetes:
Paquete 1 → bits altos
Pausa
Paquete 2 → bits bajosEl 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 >> 5y el segundo con:
packet2 = (command & 31) + 32Es 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 bitsPor ejemplo:
110010se agrupa como:
11 00 10y se convierte en:
3 0 2Así, 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 12Tambié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 msLa 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 fijoEl 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ímbolos9. 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ímbolosEsto 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ímbolos10. 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 → X0X1X2X3XEsto 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 26y 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 silenciosoPara 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 comandoHacksby 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 hardware19. 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ófono20. 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.