Esta es la bibliografía principal de Joseph Campbell (obras como autor principal o coautor), en orden cronológico inverso (de más reciente a más antiguo).
opusarchives.orgEsta lista se basa principalmente en la bibliografía del OPUS Archives (fuente autorizada sobre su archivo) y se complementa con referencias de Wikipedia y otras fuentes confiables. Se centra en libros y obras principales. Muchas obras póstumas forman parte de The Collected Works of Joseph Campbell (publicadas por New World Library / Joseph Campbell Foundation), que reedita y compila material inédito o agotado. Incluyo ediciones originales y notas relevantes.
opusarchives.orgObras póstumas y colecciones (principalmente de los años 90 en adelante, basadas en material inédito o conferencias)
Mito y sentido (2024, Ediciones Atalanta, en español; compilación).
El éxtasis del ser: Mitología y danza (2022, Ediciones Atalanta; también en Collected Works).
Goddesses: Mysteries of the Feminine Divine (ed. Safron Rossi, ~2013/2020s en Collected Works).
Thou Art That: Transforming Religious Metaphor (2001).
Sake & Satori: Asian Journals – Japan (2002).
Myths of Light: Eastern Metaphors of the Eternal (2003).
Baksheesh and Brahman: Indian Journal 1954–1955 (1995; 2ª ed. 2002).
The Mythic Dimension: Selected Essays 1959–1987 (1997).
Mythic Worlds, Modern Words: On the Art of James Joyce (1993; 2ª ed. 2004).
Reflections on the Art of Living: A Joseph Campbell Companion (ed. Diane K. Osbon, 1991).
The Hero’s Journey: Joseph Campbell on His Life and Work (ed. Phil Cousineau, 1990; ediciones centenarias posteriores).
Transformations of Myth Through Time (1990).
Obras de los años 80 y finales de carrera
The Inner Reaches of Outer Space: Metaphor As Myth and As Religion (1986).
Historical Atlas of World Mythology (1983-1989, incompleto; 2 vols., 5 partes: The Way of the Animal Powers y The Way of the Seeded Earth. Campbell completó parte antes de su muerte en 1987). opusarchives.org
Tarot Revelations (con Richard Roberts, 1979/1982).
Años 70 y 60
The Mythic Image (1974, Bollingen Series).
Myths to Live By (1972).
Flight of the Wild Gander: Explorations in the Mythological Dimension (1969; a veces listado como 1968).
The Masks of God (serie de 4 vols., Viking Press, 1959-1968):
The Hero with a Thousand Faces (El héroe de las mil caras, Bollingen Series XVII, 1949; múltiples ediciones posteriores, incl. 2008 con JCF). Su obra más influyente. isfdb.org
A Skeleton Key to Finnegans Wake (con Henry Morton Robinson, 1944; última ed. 1983).
Where the Two Came to Their Father: A Navaho War Ceremonial (con Jeff King y Maud Oakes, 1943; comentario de Campbell).
Otras contribuciones notables
Campbell editó y completó obras póstumas de Heinrich Zimmer (Myths and Symbols in Indian Art and Civilization, 1946; The King and the Corpse, 1948; Philosophies of India, 1951; The Art of Indian Asia, 1955).
Editó volúmenes de los Eranos Yearbooks (Spirit and Nature, The Mysteries, etc., 1954-1968).
Editó The Portable Arabian Nights (1952), The Portable Jung (1971), y otros.
Numerosos ensayos, conferencias, entrevistas (ej. The Power of Myth con Bill Moyers, 1988, póstumo pero basado en grabaciones de 1987) y grabaciones de audio/video (Mythos series, etc.). opusarchives.org
Notas:
The Collected Works of Joseph Campbell (serie en curso desde ~2000s) incluye reediciones corregidas, material inédito, diarios asiáticos, conferencias y más (más de 20-75 títulos según fuentes). Es la forma más completa de acceder a su obra hoy. jcf.org
Muchas obras tienen múltiples ediciones (Princeton, New World Library, Harper, etc.). En español, Ediciones Atalanta ha publicado varias en los últimos años.
Para la bibliografía más exhaustiva (incluyendo artículos y ediciones), consulta el sitio del OPUS Archives o la Joseph Campbell Foundation (JCF).
La sinestesia es el fenómeno neurológico por el cual la estimulación de un sentido activa automáticamente otro diferente, permitiendo a las personas "ver" sonidos, saborear palabras o sentir colores. El creador Eddie Graf quiso mostrar lo que vive él cuando escucha música pic.twitter.com/j2wpaBjVPU
Las música como no la habías visto, las notas de la partitura toman vida como si fuera una carrera por entender como se mueven los sonidos y como hablan los instrumentos
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:
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.
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)
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)
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())
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.
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.
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.
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.
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 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.