TODOPIC
Microcontroladores PIC => Todo en microcontroladores PIC => Mensaje iniciado por: bartox en 14 de Febrero de 2006, 12:52:00
-
Hola gente tengo una duda
¿Hay alguna manera de conectar un microfono a un PIC y que este envie el sonido por el puerto serie a otro PIC que lo decodifique y lo saque por un altavoz?
Tiene que ser en tiempo real. No vale guardar la señal de sonido y enviarla toda como un paquete.
El sonido no hace falta que sea de mucha calidad, me conformo con la calidad de un telefono.
Gracias a todos, a ver si alguien sabe como solucionar este problema que me vuelve loco
-
Escrito originalmente por bartox
Hola gente tengo una duda
¿Hay alguna manera de conectar un microfono a un PIC y que este envie el sonido por el puerto serie a otro PIC que lo decodifique y lo saque por un altavoz?
Tiene que ser en tiempo real. No vale guardar la señal de sonido y enviarla toda como un paquete.
El sonido no hace falta que sea de mucha calidad, me conformo con la calidad de un telefono.
Gracias a todos, a ver si alguien sabe como solucionar este problema que me vuelve loco 
Dejando de lado la parte del circuito de adquisición como ser:
- elevar la tensión a un valor medio para que el A/D del pic la pueda convertir ya que su rango es de 0 a 5v
- acomodar la señal para que el rango de lectura del pic sea el adecuado, es decir si la señal es pequeña amplificarla y si es grande
atenuarla.
Una vez logrado esto, lo digitalizas y luego lo envias con el módulo usart, el cual si usas a 20Mhz puede ir practicamente tan rápido como el clock.
Si, no hace falta que sea un baudeaje estandar de 115200 por ejemplo, puedes usar uno mayor si la distancia entre pics es muy pequeña, todo esto lo
trabajas desde el SPBRG, cargando un valor mas pequeño.
con dicha velocidad puedes transmitir facilmente a unos 115.2Kbits por segundo, lo cual es algo asi como 11.2Kbps (ya que la usart transmite 10 bits de los cuales solo 8 son datos).
Con esa tasa de trasnferencia tienes mas calidad que un teléfono por lejos.
Luego deberás hacer de nuevo la señal analógica (con un DAC) y le deberás quitar el valor medio de continua para sacarla por la salida
Si has entendido algo podremos continuar
-
¿Y esa no es exactamente la definición de MODEM?
MOdulador-DEModulador
Como su nombre lo dice, el módem, se encarga de transformar la señal digital que sale del micro, en analógica, que es en la forma que viaja a través de las líneas de teléfono comunes (modula la señal); y a su vez, el módem receptor se encarga de "demodular" la señal, transformándola de analógica a digital para ser recibida de nuevo por la computadora.
De las tres formas que usualmente se han utilizado para modular-demodular una transmisión digital:
1.- Desplazamiento de Amplitud (ASK): En esta técnica de modulación los dos valores binarios se representan mediante dos amplitudes diferentes de la portadora.
2.- Desplazamiento de Frecuencia (FSK): los dos valores binarios se representan por dos frecuencias diferentes próximas a la frecuencia de la portadora, donde los ángulos de la señal para el cero y el uno binarios, son comunmente de misma magnitud pero en sentidos opuestos de la frecuencia portadora.
3.- Desplazamiento de Fase (PSK): la fase de la señal portadora se desplaza para representar con ello datos digitales. En este sistema, un 0 binario se representa mediante la transmisión de una señal con la misma fase que la señal anteriormente enviada. Mientras que un 1 se representa mediante la transmisión de una señal cuya fase está en oposición de fase respecto a la señal precedente
Probablemente con la segunda de ellas, la FSK, sea la que tu necesitarías para poder transmitir mediante sonido los datos ....
De hecho yo he visto modems que no se conectaban a ningún hilo electrico, el cable del telefono, sino que todo el auricular se colocaba encima del modem, haciendo coincidir tanto el microfono como el altavoz del auricular sobre unos encajes del modem que contenián los correspondientes opuestos y que transmitía exactamente eso, sonidos y solo sonidos, como digo, sin conexión electrica alguna.
Hummmm ... interesante experimento .... muy interesante ...
Un PIC hablando con otro a grito pelado ... ja ja ja
-
Gracias por contestar a todos.
En cuanto a la respuesta de maunix, se ajusta bastante a la idea que tenia pero no sabia se seria lo suficiente rapido como para repruducir la señal del microfono.
La respuesta de RedPic me parece muy tecnica pero no acabo de entenderla.
Gracias a los dos, probare en principio lo que tenia pensado que creo que mas o menos es lo que decis. Incluso probare grabar en una memoria externa una melodia para que se reproduzca al iniciar el aprato que estoy haciendo.
Un saludo.
-
Incluso si consigues los 11.2Kbytes por segundo, estás seguro de que el conversor AD del PIC te da esa velocidad?. Tendrás que utilizar un conversor analógico-digital externo.
Cuando lleguen los datos al pic receptor como vas a pasarlos a analógico?
Te lo digo porque hay dsPICs que tienen módulos de interfaz con codecs externos que te proporcionan una calidad muy superior e incluso en estereo.
Haciendo unos cálculos por encima, puedes muestrear la señal a 22KHz en estéreo y 16bits y enviar los datos con el módulo SPI a 1Mbps
-
Si supongo que lo mejor seria utilizar un DPS pero la verdad es que en este tema todavia no me he metido, y ahora mismo no se si podria meterme con los DSP.
En principio habia pensado utilizar un PIC, por ejemplo el 16f876 es capaz de muestrear a 20MHz y las frecuencias del oido van de 20Hz a 20KHz aproximadamente.
Creo que en principio no tendria que haber problema, pero todavia no lo he probado.
Si me viese con problemas podria recurrir a un A/D externo que me diese el dato en paralelo con 8 bits por ejemplo a si podria ir un poco mas rapido.
En cuanto al D/A pues me buscaria uno por interner, en www.alldatasheet.com puedes encontrar un monton. Buscaria el mas adecuado.
En cuanto al estero, pues no me lo habia planteado pero de momento lo que quiero hacer es una especie de telefono, o sea que de momento el estereo no lo necesito.
Un saludo.
-
Lo de que un pic puede muestrear a 20MHz es totalmente erroneo y menos un 16F87X. Como máximo te dará unos pocos KHz.
-
Tienes razon, ya me estrañaba a mi que consiguiese tanta velocidad de muestreo con un cristal de 20MHz como maximo jeje, perdon
.
He calculado que como mucho llegara a unos 50KHz. ¿Puede ser? ¿Alguien sabe que frecuencia se puede samplear con un cristal de 4MHz y con uno de 20MHz en el PIC?







-
Hey, que se puso activo el hilo este.
A ver, para ir por partes.
RedPic creo que fue muy linda tu explicacion sobre modems pero nuestro amigo quiere otra cuestión.
AUDIO --> PIC --> comunicacion serie --> PIC --> AUDIO
Es una comunicación en un solo sentido y donde no le interesa saber "qué" está recibiendo, sino solo mandarlo a otro lugar.
antoniof tu dijiste:
Escrito originalmente por antoniof
Incluso si consigues los 11.2Kbytes por segundo, estás seguro de que el conversor AD del PIC te da esa velocidad?. Tendrás que utilizar un conversor analógico-digital externo.
Cuando lleguen los datos al pic receptor como vas a pasarlos a analógico?
Te lo digo porque hay dsPICs que tienen módulos de interfaz con codecs externos que te proporcionan una calidad muy superior e incluso en estereo.
Te paso a responder.
Primero, tu estas confundiendo bits por segundo, con bytes por segundo. UN conversor de pic 16F877 a 20Mhz tranquilamente puede digitalizar 10 mil muestras por segundo o 11200 muestras por segundo si se utiliza siempre el mismo canal. La recibes en PARALELO (tomas solo los 8 bits mas significativos) y eso mismo se transmite en SERIE por el pic.
Para pasarlo a analogico del lado del receptor, ya describi que lo puede hacer con un dac y un circuito que le elimine el valor medio de continua y luego amplifique esa señal para sacarla por el parlante. Es más, no está mal la idea de en este caso usar un transformador, que permite de un solo paso amplificar y adaptar impedancia de una forma mas elegante que solo con operacionales.
Creo que un dspic es exagerado para lo que nuestro amigo quiere hacer, además un micrófono estereo? para que quieres eso... las guitarras, los microfonos, los teclados, son todos mono.
Además, para convertir audio a 16 bits, no solo es cuestión de poner un conversor... solo pensar que 2^16 = 65536 valores, lo que implica que con una señal de 5V, tenemos 76 microVoltios entre valor y valor... para lograr eso, REALMENTE hay que tener un circuito de una calidad excelente, con eliminacion de ruido por todas partes, compensaciones de temperatura, etc!! No es para novatos ni mucho menos, además que es MUY COSTOSO. Uno coloca el conversor, y los ultimos 6 u 8 bits, terminan siendo RUIDO, es decir que si uno aplica una señal toda esos ultimos bits no aportan nad de información sino que es solo ruido.
Nuevamente 8 bits creo que es adecuado para lo que nuestro amigo pretende.
Escrito originalmente por bartox
Tienes razon, ya me estrañaba a mi que consiguiese tanta velocidad de muestreo con un cristal de 20MHz como maximo jeje, perdon
.
He calculado que como mucho llegara a unos 50KHz. ¿Puede ser? ¿Alguien sabe que frecuencia se puede samplear con un cristal de 4MHz y con uno de 20MHz en el PIC?
Mmm, no es tan facil hacer un cálculo asi como dices tu porque depende mucho de tu circuito externo, de todas formas como referencia puedes ver en la datasheet en el modulo A/D como se calcula el Tacq (tiempo de adquisición) y luego le debes sumar el tiempo de conversión.
Tacq lo calculas de tu circuito de entrada, que en el ejemplo de microchip dura unos 12useg aproximadamente
El Tconversion depende del cristal que hayas usado y del modo que hayas elegido en el A/D.
Imaginemos funcionado a 20Mhz con 32Tosc de clock source, nos dará unos 1.6useg por TAd. Una conversion a 10 bits, demora unos 11Tad = 17.6 useg
Además entre conversiones se debe esperar 2TAD = 3.2 useg
Esto da un total de unos 32.8 useg tipico para cargas de 1Khm, si no cambias de canal entonces podrás tener ese tiempo de muestreo, de alrededor de unos 20Ksps. Esto siempre para 20Mhz.
En las datasheet de los PIC18 está explicado cuanto es el sampling time que pueden soportar sus A/D, en algunos casos hay hasta de 200Ksps.
Nuevamente no creo que te haga falta un dsPIC para esta aplicación.
Saludos
-
Maunix creo que me has entendido perfectamente.
Tendre que mirar de hacerlo con los 18f a ver si consigo mejores resultados.
Mi intencion es hacer una especie de telefono, donde puedas hablar y escuchar a una persona que esta en el otro lado de la transmision con un aparato igual, donde el tambien pueda hablar y escuchar.
De momento probare con enviar sonido solo desde los dos lados de la comunicacion. Mas adelante probare de hacer un protocolo para poder enviar datos y sonido. Tendre que mirar si no influye mucho en el sonido y relentiza la comunicacion.
Gracias por todo.
-
Escrito originalmente por bartox
Maunix creo que me has entendido perfectamente.
Tendre que mirar de hacerlo con los 18f a ver si consigo mejores resultados.
Mi intencion es hacer una especie de telefono, donde puedas hablar y escuchar a una persona que esta en el otro lado de la transmision con un aparato igual, donde el tambien pueda hablar y escuchar.
De momento probare con enviar sonido solo desde los dos lados de la comunicacion. Mas adelante probare de hacer un protocolo para poder enviar datos y sonido. Tendre que mirar si no influye mucho en el sonido y relentiza la comunicacion.
Gracias por todo. 
Esta bien, me alegro de haberte entendido.
Sin la finalidad de desmoralizarte pero ten en cuenta que la velocidad será inversamente proporcional a la distancia que uses... si aumentas la distancia, deberás modificar la velocidad para que los datos lleguen bien.
En estos casos se usan los modem banda base, u otros modulos de comunicacion que son mas robustos frente al ruido o a las distancias. Es por esto que para comunicar a grandes distancias y a alta velocidad se han desarrollado complejos sistemas de modulación, pero los cuales en todos sus casos consumen "ancho de banda" es deecir que tu medio conductor debe ser muy bueno.
Si observas verás que mucha velocidad = poca distancia, mucha distancia # poca velocidad. Esto es así por limitaciones físicas.
El problema que tiene el cobre es que funciona como un "pasa bajo" es decir que aumentas la frecuencia yla distancia y veras como tus pulsitos se van redondeando.
De todas formas, te servirá de una linda experiencia y aprenderás muchas cosas.
Saludos
-
Si 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.
-
Bien voy a dejar claro lo que pretendo para que no hayan lagunas y malos entendidos.
Esta especie de telefono se comunicara por BlueTooth, el echo de utilizar comunicacion serie se debe a que el modulo de bluetooth que tengo solo tiene este tipo de comunicacion.
El modulo es este : http://www.parallax.com/detail.asp?product_id=30068
He encontrado otros que tenian transmision de voz pero el alcance era de 10m y este que utilizo yo alcanza los 100m. He elegido este porque es sencillo de utilizar y el precio es bajo comparado con otros que cubran el mismo alcance.
En principio el modulo enviara y recibira sonido y datos pero me estoy planteando que solo envie y reciba sonido y que los datos se envien por RF con modulos de estos de 433.92 MHz.
Ventajas del bluetooth+RF:
-Puedo recibir datos y sonido sin hacer un protocolo especial.
-Podria saber si estan intentando comunicar desde otro terminal de estos mientras estas conversando. El Bluetooth solo no se si puede recibir un intento de comunicacion mientras tienes una conexion establecida con otro.
Inconvenientes del bluetooth+RF:
-Lo veo un poco engorroso tener una comunicacion para datos y otra diferente para sonido y de hay que quiera hacer un protocolo de comunicacion que me permita enviar las dos cosas por el bluetooth.
He visto por algun sitio que hay modulos Bluetooth punto-multipunto y el que yo utilizo es punto-punto. No se si con ellos podria hacer que si hay una llamada entrante mientras tu estas ablando con otra persona el PIC puediese saberlo. Esto lo quiero hacer por que quiero poner "telefonos" que tengan mas prioridad que otros y si por ejeplo estas hablando con una persona sin prioridad y otra persona con prioridad quiere decirte algo automaticamente te avise de esta llamada con prioridad.
JJJEEE no se si me explico bien, pero queria dejar claro esto antes de meternos en temas de longitud de cables porque mi intencion es hacerlo con Bluetooth con un alcance de unos 100m mas o menos (o si hay alguna manera mejor de hacerlo sin cables pues se podria mirar).
Un saludo.
-
OK ya tengo claras tus intenciones.
Pues ya nos contarás como ha ido la cosa.
-
Haberlo dicho antes, sin leer el datasheet del módulo que mencionas fíjate si realmente puede recibir a una tasa de 115200 bits por segundo. Tal vez no pueda, sencillamente porque despues no puede transmitir a esa tasa.
Algunos modems gsm por ejemplo, tienen conexion 115200 pero solo entre tu microcontrolador y el modem, pero no puedes comunicarte a esa tasa en forma continua. Es por "rafagas" , le mandas los datos y luego sigues haciendo otra cosa.
Ten cuidado con esto ya que no es un detalle menor.
Con respecto a mezclar voz y datos, no es tan complicado como crees.
Si usas 8 bits para la voz, puedes transmitir un poquito mas velozmente y hacer que 1 bit de cada byte, sea de datos y así ir armando los sucesivos bytes del protocolo de comunicación. Mientras tanto los restantes 7 bits, uno detras de otro pudieran ser los que necesites. Otra cuestión seria que transmitas a 9 bits, donde 8 bits sean de voz y el noveno de datos, pero como te dije antes no leí el datasheet.
Espero te salga todo bien con tu proyecto, sino aquí estamos.
-
Escrito originalmente por antoniof
Si 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
-
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.
-
Escrito originalmente por 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.
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
-
Hombre yo me estoy refiriendo siempre a audio digital.
Para temperatura me parecen demasiados 24bits
-
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.
-
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
-
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
-
Escrito originalmente por 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
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