No es una recriminación. Más bien era un contestación genérica, a todos los que están dando soluciones pelín rebuscadas, que van más allá de lo simple que resulta usar un demodulador FSK integrado, o un chip especializado en decodificar el "caller ID", que por supuesto existen y son bien baratos (yo tengo 3 chips de estos en mi poder, comprados en Amidata recientemente, el CMX602, CMX612, y el MT8843)
El CMX612, permite además, hacer unas cuantas virguerías más, que pueden resultar muy interesantes.
Ya, pero me parece más simple usar un integrado, barato y sencillo, en vez de andar urgando en el teléfono, con inventos teóricos usando optoacopladores, transformadores etc. Es como matar moscas a cañonazos y con una venda en los ojos.
Además quedará algo más limpio, aseado, e independiente del teléfono, montar un pequeño circuito, en un PCB.
Pues si es muy simple. Convierte tonos (modulación FSK), en niveles lógicos. La salida la conectas a la UART de un PIC, o a través de un MAX232 al puerto serie del PC, y arreglado.
Como digas, pero ese 'pequeño circuito' deberá proveer aislamiento galvánico si es que quieres *enchufar* el identificador al PC. Es ese aislamiento el que lleva el peso de este hilo, *no* la decodificación.
Spock... adum130x y adum140x, son la solucion de analog para aislar sin usar optoacopladores. Tienen samples..analog no tarda mucho, y asi no te tendras que desplazar, creo que solo necesita un condensador y un par de resistencias... yo lo miraria por lo menos, es que recibi hoy el catalogo y lo vi.. "pla pla aisladores bla bla.." XD, entonces le echaria un vistazo que yo ahora no tengo tiempo.
Hola: La parte física tengo bastante claro como hacerlo: no hay más que usar uno de los circuitos de aplicación de uno de estos circuitos "caller id", yo me inclino por el CMX602, y poner un PIC a su salida, que será el que excitará el relé o un optoacoplador con salida por triac. El problema para mi no es ese, sino como hacer el programa para el PIC, pues nunca he hecho ninguno. Como los datos que recibe y decodifica el CMX602 lo tiene disponible en el registro de desplazamiento de su salida durante un tiempo muy pequeño, pues son sustituidos por el siguiente byte que decodifique, el programa del PIC tiene que ir pidiendo estos bits al ritmo en que estén disponibles, por lo que hay que controlar con mucha precisión los tiempos, decodificar los bytes recibidos, almacenarlos en una serie de registros y cuando ya acaben de recibirse datos, calcular el checksum para ver si es correcto, comparar el número recibido con uno previamente almacenado y, la verdad, no me siento capaz de hacer un programa así, pues normalmente supongo que uno empieza con los PIC haciendo cosas más sencillas. Lo que me parece más difícil es la primera parte, es decir, como pedir los bits al CMX602 sin perder ningún byte al ritmo apropiado, pues una vez decodificados los bytes, el resto (comparar el número almacenado, etc) me parece relativamente fácil. No se si una rutina para recibir datos en serie RS232 podría servir de base para este programa ¿o sería muy diferente? Por otra parte, no se si un sistema de desarrollo para PIC, como este:
formatting link
me podría ayudar para desarrollar no solo este proyecto, sino cualquier otro que haga en el futuro con PIC. Salu2.
Es que para empezar con los PIC, partiendo de cero, no es un proyecto sencillo, y mucho menos si se hace en ensamblador.
8,3 milisengundos, según el datasheet, pero no te asustes, para un PIC que ejecuta 1 millón de instrucciones por segundo, eso no es nada.
Eso es solo en apariencia. Date cuenta que las lineas de control del CMX602, te dicen cuando está disponible un caracter (8 bits), y ya solo tienes que leerlos en serie, mandando pulsos a la patilla RXCK, y recogiendo un bit por pulso, en la patilla RXD.
¿ cuando tienes que recoger los 8 bits del buffer del CMX602 ?, facil, cuando la patilla IRQN esté a nivel bajo. Fíjate lo que te dicen en el datasheet:
"An open-drain active low output that may be used as an Interrupt Request / Wake-up input to the associated µC."
Si no conoces nada de microcontroladores, probablemten no te diga nada esto, pero, tanto en los microcontroladores, como en los microprocesadores, hay unas entradas que pueden emplearse como INTERRUPCIONES, es decir que puedes estar ejecutando un programa, y si en alguna de esas patillas se detecta un nivel alto, automaticamente el programa salta a la rutina que le hayas programado. Tambien podrías simularlo metiendo el programa en un bucle sin fín, que chequee constantemente el puerto del PIC, que conectes a la patilla IRQN del CMX602.
Por otra parte tienes la patilla DET, que si aplicas nivel alto a MODE y bajo a ZP, te indicará cuando se recibe señal FSK, es decir cuando están llamando por teléfono, y se están recibiendo los tonos FSK del "caller ID". La patilla DET, sería la candidata ideal para activar la interrupción del PIC, y saltar a la rutina de proceso de datos.
En esa rutina, metes dentro de un bucle sin fín, una lectura de comprobación de IRQN, si está a nivel bajo, llamás a una rutina que recoja los 8 bits, y los almacene en una tabla (habrá que ver de cuantos carácteres máximo, es el mensaje recibido, para definir la longitud de esa tabla). En cuanto hayas llenado esa tabla, llamas a una rutina que la procese, extraiga la información que precises, comparé el número de teléfono con los que tengas almacenados y active el relé.
A mi no me parece complicado, pero para alguien que no haya tocado nunca un microcontrolador, puede parecer "la obra del Escorial".
En efecto, cosas como encender un LED, testar un pulsador, más delante manejar un LCD, etc..etc..
Como te he explicado. Interrupción activa programa principal, por patilla DET a nivel alto (recibiendo tonos FSK). Bucle chequeando IRQN, si está a nivel bajo, a leer el buffer, envias 8 pulsos por RXCK, y por cada uno recoges un bit en RXD. Almacenas el caracter (8 bits), en una tabla (en base a un contador que inicializas a cero, cuando se entra al programa principal). Cuando llenes la tabla, la procesas, extraes lo que te interese, y activas el relé, comparando con un nº prefijado.
Se pueden añadir más virguerias, como registrar los teléfonos que activarán el rele, introduciéndolos con un micropulsador (aunque necesitarías un LCD para verlo), o con un jumper decirle al PIC, que el número de teléfono que llame se almacene en determiandas posiciones de la EPROM del PIC. Haces una llamada desde el teléfono que deberá activarlo, y pones de nuevo el jumper en la posición de trabajo del programa. También podrías poner los nº de teléfono, a piñón fijo en el programa, pero si quisieras cambiarlo tendrías que recompilar el fuente.
Pues más bien no. De todas formas creo que este caso es más sencillo, ya que no hay que parametrizar la UART, solo utilizar 4 puertos del PIC, 3 como entradas (IRQN, DET y RXD) y uno como salida (RXCK).
De todas formas, podría resultar más sencillo de programar (aunque creo qeu no), usando un XR2211 y la UART del PIC.
Nunca me ha gustado ese chisme, es caro y muy poco flexible. En Elektor han salido varios entrenadores, y de todas formas con 4 chorradas se monta uno, mucho más barato.
Me estoy oliendo el problema a km.. XD, tu sabes programar en pc verdad? tu eres de los mios, de programacion matematica que lo llamo yo, a ensayo y error, verdad? y el problema que tienes con el pic es que no ves la informacion que procesas, pero esto tiene una solucion mucha mas barata que el trainer ese, o te montas algo con un lcd ( nunca me gusto.. tengo dos
2x16 y otro 2x20, y no me muestra todo lo que yo quiero ), o lo comunicas con el pc, tampoco es tan dificil, cuando tengas todos los datos en memoria simplemente tendrias que comunicarlo con el pc, ya bien por serie o por lpt, y puedes muestrear cualquier dato en la pantalla del pc.
Me hize un programador LVP con el lpt, con las demas de entrada me hize una especie de debugger, y enviando los datos por el mismo lpt y sin desconectar ni quitar el chip, tienes una preciosa codificacion ascii que puedes ver lo que quieras. Es currarte algo en C para el pc que lo reciba, y algo para el pic para enviarlo.
Para el tema de ver los registros, hay varias soluciones. Para PICs antiguos o con poca memoria de programa, un método fácil es volcar la RAM (o parte de ella) a la EEPROM cuando te interese. Entonces, lees la EEPROM con el ICProg y listo. Una rutina para hacer eso no ocupará más de 20 líneas de código, y son procedimientos archiconocidos y que se pueden simular perfectamente en MPLAB. Para PICs más modernos, otra posibilidad es comprar o hacerse un sistema ICD (In Circuit Debugging), que te mantiene el PIC conectado con el PC y en cualquier momento puedes parar la ejecución y volcar los registros al PC (y algunas cosas más), todo ello sin necesidad de escribir ni una línea de código, porque ya viene implementado de fábrica. Por último, en sistemas tan simples como este, lo más fácil es simular en MPLAB y cuando funcione bien, pasarlo a hardaware.
En cuanto a la "complejidad" de lo que tiene que hacer el PIC en este caso, puede ser tan simple como esto:
1º. Poner RXCK a 0 y esperar hasta que IRQN sea 0.
2º. Cuando IRQN sea 0, repetir 8 veces: a. Desplazar DATO (una variable cualquiera) a la derecha. b. Leer RXD y poner su valor en el bit 7 de DATO. c. Poner un 1 en RXCK, esperar 1us, poner un 0 en RXCK y esperar 1us.
3º. Procesar DATO (guardarlo en donde sea o compararlo con lo que sea...)
Yo creo que no es muy complicado, ¿no? Y si el programa tiene otras muchas cosas que hacer, pues utiliza para leer IRQN una patilla de interrupción y metes este código en la rutina de interrupción. En cuanto al tiempo... Un PIC a 4MHz puede ejecutar 8300 instrucciones en el tiempo que tarda en llegar cada carácter, así que puedes hacer virguerías con él.
--
Saludos de José Manuel García snipped-for-privacy@terra.es http://213.97.130.124
"Spock_Andaluz" escribió en el mensaje news: snipped-for-privacy@QUITAESTOenextremadura.com...
Mi caso es parecido al tuyo, y te puedo decir el entrenamiento que he usado:
- Monté un pic, con su xtal y un led conectado a un pin en una placa de prototipos. - Hice un programa para encender y apagar el led cada segundo, controlando el tiempo en un bucle software - Idem, controlando el tiempo con el timer. - Lo mismo, pero el timer genera interrupciones. - Lo mismo, pero usando el WDT. Con eso, tienes trabajo para una temporada (yo programaba en asm para el PC y no me costó mucho).
- Luego seguí conectando dos servomotores, y un receptor de mandos a distancia philips, en la misma placa. - Ahora tengo el pic conectado al puerto serie del ordenador y tengo varios programas de ordenador que interactuan con el pic. La comunicacion serie en el PIC la hago por software, pues uso el 16F84. Este PIC (lo mismo que el 16F876) lo tienes en cualquier tienda, e incluso mucha gente que conoces tienen estos PIC y no los usan, te los podrían regalar ;-)
Sobre el entrenador: Solo tienes que usar una placa de prototipos grande, montar el PIC con su xtal y para cada prueba que vayas a hacer soldar en la placa lo que necesites, si la placa no es muy pequeña no veo mayor problema.
"Spock_Andaluz" escribió en el mensaje news: snipped-for-privacy@QUITAESTOenextremadura.com...
Los 16F87x lo soportan, y en encapsulados menores, los 16F818, 16F819 (buenos sustitutos para el 16F84) y todos los 18F.
en
Sí, claro. Me refería a que no se trata de simular un montón de señales, sino dos o tres, y con una lógica bastante simple.
No tengo ni idea de cómo funcionará eso. La verdad es que sería un tema interesantísimo averiguarlo, especialmente la forma de enviar SMS por línea fija. Si alguien conoce algo de esto, que hable ahora o calle para siempre. :-))
--
Saludos de José Manuel García
jose.mgg@terra.es
http://213.97.130.124
Ni idea, es la primera noticia que tengo de eso. Será cuestión de llamar a Telefónica y preguntar como funciona ese servicio y que cuesta. Probablemente, teniendo el DOMO sirva (yo lo tengo). Lo lógico es que se reciba también, por FSK, será cuestión de probar un circuito con el XR2211 y el hyperterminal del PC, para visionar si se recibe algo.
Sacado de Google::
Si es un teléfono fijo que incluye esta funcionalidad, el mensaje se recibirá en la pantalla de la línea fija. Mientras que si el modelo de teléfono fijo no soporta mensajes de texto, el mensaje se convertirá automáticamente en un mensaje de voz y quedará grabado en el buzón de voz del teléfono fijo. En el caso de que el fijo no tuviese buzón de voz activado, el SMS se convertirá en una llamada de voz. El precio del mensaje enviado desde su móvil Vodafone a un teléfono fijo es de 0,15?. (impuestos indirectos no incluidos)
begin 666 red_square.gif M1TE&.#EA! `$`)$``````/____\``/___R'Y! $```$`+ `````$``0```(& (E".(%QT%`#L` ` end
In the last 2 years, some telephone companies have provided a land-line based SMS service, where short messages are sent in the form of a V23 (1200baud) modem signal, and received by a suitable phone, using essentially the same circuit that is used to decode the Caller ID signal.
These SMS services rely on the telephone company running a message server, which receives the messages and forwards them on to the destination subscriber, in the form of a no-ring call. Some telcos have agreements with the mobile phone service providers, so that the SMS messages are passed from PSTN network to the mobile network.
V23 is an ideal format for short messages, or sending control instructions for home automation projects over the telephone line. A PIC as simple as the
16F84 can dial a telephone number, wait for the far end to answer and then send the message. All this can be done in firmware with next to no hardware.
At the far end, a PIC can detect the incoming call, identify that it is a data message from a known source - by decoding the Caller ID, picking up the call and then storing or acting on the message.
This is ideal for remotely controlling devices around the home (central heating, security lights, burglar alarm, VCR) when you are away from home.
Alternatively, the PIC could be used as a datalogger for sensing temperature, humidity, gas/electricity consumption, security or PIR sensors and convery this data to a remote location via the phone line.
Although these tasks could be performed using a PC and internet, it is unlikely that you would wish to have a PC permanently powered.
As an aside - GSM modem technology is getting much cheaper and for about US $100 you can get a GSM modem with voice, data and SMS functionality. When combined with a PIC such as the 18F8720, you could have a very capable, low cost telematics/telemetry device. New devices are just about to be available which for $30, provide a low cost data only connection using the GSM control channels. See
Basado en eso mismo, se puede habilitar la UART del PIC, y enviar cualquier variable o valor de un registro al puerto serie del PC. Ni siquiera haría falta un programa específico en el PC, con usar el hyperterminal, visionariamos el valor de la variable que queramos.
Se podrían emplear 2 variables en la rutina que envía los valores al puerto serie, una para indicar el nombre del campo o registro, y otra para enviar el valor de ese campo o registro.
Yo cuando programaba en RPG, y todavía no existían herramientas de debug, volcaba las variables a la impresora o la pantalla. Por el mismo principio, podríamos dar salida de esos datos al puerto serie del PC, y visualizarlas en la pantalla.
La rutina para enviar datos usando la UART, ocupa muy poco, y siempre se podría capar, cuando el diseño ya esté probado y funcione a la perfección, aunque sería recomendable, no eliminar la rutina del fuente, solo asteriscarla, para posibles usos futuros.
Bueno, siempre que abras la linea telefónica, puedes establecer comunicaciones facilmente, utilizando modulación por tonos (FSK), como la empleada por los modems, y que es la misma del "caller ID".
El demodulador lo puedes construir con el XR2211, y el modulador con el XR2206. Al fin y al cabo, no es más que un modem, autoconstruido, que codifica y decodifica, de tonos a pulsos y viceversa, a 1200bps.
Otra cosa que falta por saber es si los SMS que reciben los teléfonos fijos, se hace sin ABRIR la linea, osea gratis.
Jojojo, ola compañeiro.. XD, yo tambien toi en sistemas, el fp no.. hize selectividad, pero pa el caso da igual ^^. No te asustes por los pic, a mi me pasaba lo mismo y me sigue pasando, cuando programo algo en el pc me da por meter miles de mensajitos de debug que luego quito pero ayudan a seguir mucho el caudal del programa. Con los pic al principio te meas, pero no te preocupes con el tiempo veras como las cosas cambian, para empezar ( y para todo.. ) yo y mi experiencia me ha demostrado que es lo mejor, al paralelo o al serie y envias datos.. es lo mejor.. pero con los pics normalmente soy mucho mas cuidadoso programandolos, porque aun teniendo los debug, no es lo mismo un pc que un pic y voy revisando linea por linea, por cierto, si sabes C, bajate el PCW del... e-m*l* xD, me van acusar de pirateria o algo, pero es lo mejor que he visto de momento.. de pago si.. para quien lo pague... no es asequible para un estudiante como yo lo siento mucho ( se que hay freeware pero.. ejem.. usaba JaL y la diferencia.. ejem.. )
I have long wanted to get back to experimenting with the PIC as the means of sending and receiving V23 modem data.
This is 1200 baud FSK and uses 1300Hz and 2100Hz to represent the 1 and 0 data.
I have wired up a simple opto-isolator to the serial port of my PC, so that it is now safe to connect to telephone line connected circuits. I use hyperterminal set to 1220baud, 8 bits, No parity and 1 stop bit to examine the output from the V23 decoder.
I decided to compare the performance of the NPC 8223A which is both a DTMF and FSK decoder, with my PIC16F84 circuit which calculates the time between the half cycles to determine whether the modem is sending a 0 or a 1.
I have a PIC wired up to generate a repetative short text message of between
32 and 256 bytes connected to one of my phone lines. When I activate this sending unit (by lifting the handset of a parallel connected phone) it dials up my other phone line and sends the message continuously.
I can report that the PIC seems to be able to decode the V23 as well as the NPC chip, provided that there is plenty of signal level. My 1 transistor amplifier worked fine for larger signals but failed on the weaker signals present at the receiving end. I decided to build a quick op-amp circuit using a LM358 to make a combined boost amplifier and squaring comparator. This seems to work well and I hope to release the circuit to the files area later on.
Meanwhile I am finding that my sending PIC sometimes corrupts the message for a few characters and then sends a few good characters. This may be because my 1200 baud routine is not quite correctly timed so I will need to investigate.
My aim is to publish some code routines which handles the entire V23 send and receive process so that telephone remote communications can easily be added to a PIC with minimum of difficulty.
Anyone interested in this project - please email me
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.