Sonido por el puerto serie

[maunix]

Escrito originalmente por antoniofSi lo que vas a hacer es un telefono, para nada te interesa un dsPIC. Yo lo decía por si querias transmitir otro tipo de señal de audio de mayor calidad.

En tu caso, con 8 bits y 4KHz de frecuencia de muestreo tienes de sobra. Para comunicar ambos pic, yo utilizaría el módulo SPI. Es más rápido y economico que el RS-232, aunque todo depende de la distancia que haya entre ambos PIC.

En general se usa 8Khz de muestreo para obtener una señal mas o menos buena con un ancho de banda de 4Khz.  De todas formas antonio, creo que tu ejemplo de usar 16 bits  estereo es algo que escapa a la mayoría de los mortales si es que uno "digitalizará" el audio por lo que mencioné antes de los famosos microvoltios que hay que tener en cuenta.  

Muy diferente es que uno lea un audio directamente de un cd, a 18 bits y luego lo procese, pero el trabajo "duro" de que el audio tenga realmente calidad de 16 o 18 bits, lo hizo la compañía discográfica (o tu grabadora de cd) y luego transmita eso y posteriormente lo decodifique para tener un audio de 16 bits, en ese sentido creo que si estaría bien tu propuesta.

antonio, no entendí la parte del RS-232 porque nadie la mencionó, lo de más rápido puede ser cierto hasta ahi nomas... porque no usa el bit de start y stop pero una comunicacion por USART puede ser tan rápida como tu hadware lo permita.  El SPI es para distancias muy cortas.
El punto es que si de comunicacion serie se trata a gran velocidad, siempre hay montones de variables de compromiso.  Hay otros buses como el rs422, can bus, que funcionan más velozmente y a mayores distancias.


Saludos

[antoniof]

Lo de los 16 bits de audio e incluso los 24bits lo digo porque hay codecs que sí dan esa resolucion con una frecuencia de muestreo de 96KHz. Cualquier reproductor de DVD que tengamos en nuestra casa tiene estas especificaciones.

Ahora bien, para una aplicacion "telefonica" utilizar estos codecs es matar moscas a cañonazos y más aún, si el módulo no soprta más de 9600bps.

Personalmente, he utilizado el procesador de audio TAS3002 de texas instruments de 24 bits y un par de codecs (AD y DA) también de 24bits con un dsPIC para simular el dolby stereo, y estoy pero que muy satisfecho con el resultado. El sonido es de una calidad y limpieza que nada tienen que embidiar a un equipo de home cinema del mercado.

[maunix]

Escrito originalmente por antoniofLo de los 16 bits de audio e incluso los 24bits lo digo porque hay codecs que sí dan esa resolucion con una frecuencia de muestreo de 96KHz. Cualquier reproductor de DVD que tengamos en nuestra casa tiene estas especificaciones.

Ahora bien, para una aplicacion "telefonica" utilizar estos codecs es matar moscas a cañonazos y más aún, si el módulo no soprta más de 9600bps.

Personalmente, he utilizado el procesador de audio TAS3002 de texas instruments de 24 bits y un par de codecs (AD y DA) también de 24bits con un dsPIC para simular el dolby stereo, y estoy pero que muy satisfecho con el resultado. El sonido es de una calidad y limpieza que nada tienen que embidiar a un equipo de home cinema del mercado.

Antonio me interesa lo que dices pero creo que es meritorio para un nuevo hilo.
Un codec de 24 bits para dvd, lee datos en digital y lo pasa a analógico.  Esto es muy diferente a tener que digitalizar la señal a 24 bits de calidad.

Yo podria usar un conversor de 24 bits para sensar temperatura y seguramente si mi circuito no es lo suficientemente robusto y mi fuente de alimentacion lo suficientemente bien filtrada , te aseguro que 12 o 14 bits serán solo ruido blanco.

Saludos

[antoniof]

Hombre yo me estoy refiriendo siempre a audio digital.

Para temperatura me parecen demasiados  24bits

[bartox]

Despues de pasar horas buscando informacion de Bluetooth he decidido hacer las cosas bien echas.

Hay modulos que incorporan PCM para poder transmitir sonido osea que haremos las cosas bien echas y utilizare esta opcion. Para ello se utiliza un simple codec que convierte la señal del microfono a PCM y de PCM al altavoz.

Ahora mi problema es otro. He encontrado un modulo que me iria perfecto (http://edutronica.inware.it/files/prodotti/download/free2move/F2M03C1manual.pdf) pero en el datasheet no salen los comandos que hay que utilizar para configurarlo, comunicar y todo lo necesario para su uso. Mi intencion seria enviarle los comandos desde el PIC para hacer todo.

Bueno me he planteado abrir otro tema para ablar de modulos como este a ver si alguien sabe algo que me sea util para controlarlo desde un PIC, asi que de momento dejo la parte del conversor A/D para hacerlo todo desde el PCM del Bluetooth.

Muchas gracias a todos.
Un saludo.

[maunix]

Escrito originalmente por bartox
Ahora mi problema es otro. He encontrado un modulo que me iria perfecto (http://edutronica.inware.it/files/prodotti/download/free2move/F2M03C1manual.pdf) pero en el datasheet no salen los comandos que hay que utilizar para configurarlo, comunicar y todo lo necesario para su uso. Mi intencion seria enviarle los comandos desde el PIC para hacer todo.

bartox  ante todo me parece bien acertada tu decisión,  es importante a veces primero resolver el problema y después irlo optimizando.  En tu caso es una buena solución ya que el camino para hacerlo mas económico será ir incorporando en tu firmware de pic toda las partes de la codificacion PCM para luego pasar a reemplazar ese módulo bluetooth por alguno más básico pero económico.

Tambien me tome un tiempito para ojear esa datasheet y es tal cual tu dices, no hay mucha explicación al respecto.  Reconozco ser un total desconocedor de las normas bluetooth pero segun lo que leí ahi, hay dos formas de programarlo.
Con un soft de aplicacion hecho con vos o usando el pequeño sistema operativo con su VirtualMachine incorporado que hará que funcione como un modulo stand-alone.

Pero no hay nada mas, al respecto solo pude retener la frase

For more application information consult available application notes or contact Free2move.
[/i]

Osea, ante la duda contactate con ellos que son quienes te podran brindar mas información, o bien navega mas profundamente en su sitio, tal vez tengan una forma standard de comunicarse con todos sus dispositivos de la misma familia y hay a un documento donde se haga referencia  a esto.


Un consejo extra, para poner links usa los demarcadores [ url ] y  [  / url] sin espacios al borde del mismo para que se haga un link que se pueda ejecutar con un click.

Te quedaría asi:

http://edutronica.inware.it/files/prodotti/download/free2move/F2M03C1manual.pdf

Saludos

[bartox]

Perdon por lo de la URL no pasara mas, no me habia dado cuenta.

¿¿¿¿¿Que veis mejor

- Utilizar un modulo bluetooth con PCM para enviar sonido y comunicacion serie para enviar datos
 o
- Un modulo bluetooth con comunicacion serie para enviar datos solamente y con el PIC procesar la señal de sondio y enviarla como datos

?????????????

Tengo dudas porque el 1º me parece mas completo y el 2º me ahorra tener que poner un IC codec de PCM delante del modulo a parte del PIC para enviar datos

[maunix]

Escrito originalmente por bartoxPerdon por lo de la URL no pasara mas, no me habia dado cuenta.

¿¿¿¿¿Que veis mejor

- Utilizar un modulo bluetooth con PCM para enviar sonido y comunicacion serie para enviar datos
 o
- Un modulo bluetooth con comunicacion serie para enviar datos solamente y con el PIC procesar la señal de sondio y enviarla como datos

?????????????

Tengo dudas porque el 1º me parece mas completo y el 2º me ahorra tener que poner un IC codec de PCM delante del modulo a parte del PIC para enviar datos

El 1er módulo empaqueta datos de voz y de datos en paralelo? no entendí esa parte, si es así sería la opción más facil y rápida de implementar pero de seguro la más costosa.

En este caso creo que te enfrentas a lo siguiente:

. En la opción 1) te ahorraras tiempo de implementación pero gastarás mas dinero
. En la opción 2) te ahorraras dinero pero aumntará tu tiempo de implementación

Como dicen los americanos "time is money", hay que invertir dinero para ahorrar tiempo o invertir tiempo para ahorrar dinero.

Repito,  si el primer módulo te gestiona la comunicación de voz y datos por separado y tu solo quieres implementarlo y el costo te parece adecuado hazlo así para al menos tener algo funcionando.  Si luego quieres ahorrar dinero porque quieres hacer mayor cantidad puedes ir solucionando por firmware lo que el módulo te hace solo.

Saludos