Estimados seguidores, con esta entrega final vamos a colocarlos al tanto del protocolo de comunicación definitivo del grupo (ya se había explicado el protocolo, pero sin explicar cómo se utilizarían los 2 bytes de datos), el sintetizador realizado en Labview, así como todas las fotos y videos de distintas pruebas realizadas para lograr el resultado.
Han sido unas semanas bastante fuertes, donde el deadline de entrega del proyecto se unió a todos los demás requerimientos académicos, pero aún así, nos sentimos satisfechos como grupo por lo logrado. Sonó uno de los instrumentos con un funcionamiento completo que abarcó todas sus características, lo que nos indica que el trabajo con el sintetizador y la comunicación del DEMOQE128 con el mismo usando el protocolo propuesto fue ejemplar. Quizás faltó una semana más, para una entrega completa con todo lo que se había planeado, por supuesto nos habría ayudado menos colaboración por parte de nuestro querido amigo Murphy, quien nos acompañó hasta el final: no sólo colaboro con dañar una de las computadoras personales donde se trabajaba, tampoco le bastó con borrar programas grabados de las computadoras restantes, ni mucho menos le bastó hacer muy lenta la única computadora donde funcionaba el Labview; se tuvo que lucir el último día haciendo de las suyas. Pero con esto no pretendemos excusarnos, ni hacer de mártires, pretendemos reflexionar, este proyecto ha sido realmente interesante y ha representado un aprendizaje significativo, es por ellos que hay satisfacción, porque se lograron los objetivos que en una primera entrega del blog parecían imposibles.
Así pues empezaremos hablando de la definición para los bytes del protocolo de comunicación no tomados en cuenta anteriormente.
Protocolo de Comunicación
Se utilizaron 4 bits LSB del byte de estado (explicado anteriormente), para identificar los instrumentos siguientes:
| Instrumento | Identificador |
| Saxofón | 0000 |
| Cello | 0001 |
| Multitasking Trompeta Tambor Platillo | 0010 0011 0100 |
| Xilófono | 0101 |
Tabla . Asignación de los LSB del byte de estado.
PRIMER BYTE DE DATA: fue dividido de la siguiente forma:
Los primeros 5 bits constituyen la nota musical, lo cual permite representar un total de 32 notas. Esta selección fue con la finalidad de disponer de 4 octavas (28 notas) para los diversos instrumentos.
Identificador | ||||
Nota musical | Octava 1 | Octava 2 | Octava 3 | Octava 4 |
DO | 00000 | 00111 | 01110 | 10101 |
RE | 00001 | 01000 | 01111 | 10110 |
MI | 00010 | 01001 | 10000 | 10111 |
FA | 00011 | 01010 | 10001 | 11000 |
SOL | 00100 | 01011 | 10010 | 11001 |
LA | 00101 | 01100 | 10011 | 11010 |
SI | 00110 | 01101 | 10100 | 11011 |
Tabla . Asignación de bits a cada nota.
Los últimos 3 bytes conforman el volumen, habilitando hasta 8 variaciones del mismo.
SEGUNDO BYTE DE DATA: en este sintetizador no se agregaron efectos adicionales a las notas a reproducir.
Sintetizador de Labview
El sistema sintetizador está constituido por lo siguiente:
A continuación se presenta una explicación detallada de cada una de las etapas desarrolladas:
Adquisición de datos
Constituye la primera etapa del sistema en Labview. Recibe la data desde el instrumento como se muestra:
Es decir, las señales generadas por los sensores que se encuentran en los instrumentos, son recibidas por el microcontrolador. Luego en Codewarrior se constituye el protocolo de comunicación. Luego el mensaje es enviado a LabVIEW por comunicación serial.
En esta etapa se usan los drivers VISA para recibir los datos a través del serial, utilizando una transmisión de 8bits a 115200 baudios. En la figura 1 se observa la estructura encargada de obtener la data. La misma se encuentra dentro de un while para asegurar que la recepción se realice todo el tiempo.
Figura 1. Adquisición de datos.
Los datos constituyen un mensaje del protocolo explicado anteriormente, con el adicional de dos bytes, uno de inicio de trama y otro de fin de trama (figura 2 ). Estos bytes permiten determinar si la información está llegando correctamente. Cuando se verifica que la data llega bien, se procede a analizar los demás bytes.
INICIO DE TRAMA 0XFF | BYTE DE ESTADO | PRIMER BYTE DE DATA | SEGUNDO BYTE DE DATA | FIN DE TRAMA 0XFC |
Figura 2. Mensaje que recibe el LabVIEW
Para la verificación se usa la estructura siguiente:
Figura 3. Estructura utilizada para la revisión del inicio de trama.
En la misma se establece como condición del while una comparación del primer byte del mensaje, con el 255 (0xFF). Por lo tanto no se realiza el procesamiento de los datos, hasta que obtenga el inicio de trama.
Esta igualación también se realiza con el fin de trama, cambiando 255 por 252 (0xFC). La diferencia es que ya no representa la condición de un while, sino la condición para acceder a la información de reproducción de sonido.
Procesamiento de datos
Principalmente realiza comparaciones del protocolo para determinar que operaciones se realizaran. Se observa el byte de estado, así como los bytes de data, determinando que acciones ejecutará el instrumento indicado.
Figura 4. Extracción de la información del protocolo.
Esta fase se encuentra en un ciclo, permitiendo examinar constantemente cambios del mensaje. Le envía modificaciones a la etapa de sonido mediante el uso de variables locales.
Entre estas modificaciones está el NOTE ON y NOTE OFF para cada instrumento, el volumen, y la frecuencia (nota a reproducir),
Reproducción de sonido
Primero se utilizó la siguiente configuración básica para la reproducción de un archivo .wav:
Figura 5. Reproduccion de archivo .wav
Los últimos tres bloques sirven para escribir la información en la tarjeta de sonido, esperar a que se termine de reproducir y limpiar el buffer. Ésta configuración funciona para reproducir el tambor, el platillo y el xilófono, ya que no mantiene el sonido continuo.
En el caso de los instrumentos que necesitan mantener una nota continua, como la trompeta, el cello, y el saxofón, este diagrama no se debe usar, pues al tratar de repetir la nota, se escuchan cortes antes de la nueva reproducción, por lo que fue necesario dividir el archivo en 3 partes: ataque, sostenido y caída. Con esta división se crea una representación que reproduce el ataque, luego mantiene sonando el sostenido tanto tiempo como sea requerido, y finalmente suena la caída. Esta segmentación fue realizada con el programa Audacity.
Figura 6 Reproducción continua del sostenido
Figura 7. Reproducción ataque-sostenido-caída
Para el cambio de la frecuencia se tiene:
Figura 8. Modificación de frecuencia.
Basándose en los diagramas anteriores, se crearon secciones para la reproducción de cada uno de los instrumentos con una serie de subVI’s., que reciben como entrada variables locales provenientes del procesamiento de datos. En las mismas se incluyeron variaciones de la frecuencia de muestreo a utilizar, volumen, NOTEON y NOTE OFF. La etapa de reproducción de sonido se muestra a continuación:
Figura 9. Reproducción de sonido.
Combinando la figura 5 y 9 se tiene el sintetizador final.
Xilófono:
En el video se puede apreciar el resultado final del instrumento. Suena como una trompeta porque el Labview sólo quería correr el programa en que se encontraba sólo la trompeta (recuerdan Murphy?). Se puede evidenciar que las teclas suenan más o menos fuerte dependiendo de la intensidad con que la tecla es golpeada, y cambiando de tecla, cambia la frecuencia del sonido.
Guante Multitasking:
El video siguiente muestra el desempeño del acelerómetro con su canal de adquisición en Baquelita:
En el siguiente se muestra el mismo comportamiento del acelerómetro, pero usando ya el protocolo para el envío de los datos en paquetes. Para este caso, se colocó byte de inicio FF, 3 bytes con los datos de los 3 ejes del acelerómtero y byte dee fin FC.
Resultado final (Nótese la tarjeta para la comunicación con el micro sirviéndose de un conector DB9):
En el video se puede apreciar el resultado final del instrumento. Suena como una trompeta porque el Labview sólo quería correr el programa en que se encontraba sólo la trompeta (recuerdan Murphy?). Se puede evidenciar que las teclas suenan más o menos fuerte dependiendo de la intensidad con que la tecla es golpeada, y cambiando de tecla, cambia la frecuencia del sonido.
El video que se presenta a continuación muestra la prueba de la baquelita para el canal de adquisición de los piezoeléctricos, un total éxito:
El video que se presenta a continuación, muestra la prueba de las fotoresistencias, en este video, los Datos ya se estaban enviando dentro de sus respectivos paquetes al Labview:
Fotos durante la realización del instrumento:
Resultados finales:
Guante Multitasking:
El video siguiente muestra el desempeño del acelerómetro con su canal de adquisición en Baquelita:
En el siguiente se muestra el mismo comportamiento del acelerómetro, pero usando ya el protocolo para el envío de los datos en paquetes. Para este caso, se colocó byte de inicio FF, 3 bytes con los datos de los 3 ejes del acelerómtero y byte dee fin FC.
Fotos durante la realización de las baquelitas para el guante:
Resultado final (Nótese la tarjeta para la comunicación con el micro sirviéndose de un conector DB9):
No hay comentarios:
Publicar un comentario