Caller ID

Hola: Hace tiempo que no doy la lata con este tema, pero he seguido experimentando. Después de que no obtuviera resultados con la primera versión que hice en Pascal debido a los problemas que me daba el compilador, traduje el programa al C de CCS, que me ha ido mucho mejor, pero he llegado a un punto en que no avanzo, pues el micro solo captura algunos caracteres (solo dos o tres) y pierde los demás. Para descartar problemas con el CMX602B, lo configuré para que no usara el ?data retiming? y ?escupiera? los caracteres según los decodificara, viéndolos en el PC previo paso por un MAX232. El resultado es que se recibía perfectamente todo el mensaje, con los bytes de control, fecha, hora y número de teléfono completos, aunque antes y después del mensaje se colaban algunos caracteres aleatorios, de ruido, pero fácilmente eliminables. Mirando el montaje aparecido en ?Todo electrónica?, me di cuenta de que algunos componentes que rodean al CMX eran diferentes respecto a los que aparecen en el data sheet del fabricante, concretamente los del amplificador operacional que incluye, y que es el que amplifica la señal FSK antes de demodularla. Están ajustados de forma que tenga menos ganancia. Lo probé así y se reciben menos caracteres de ?ruido? al principio y final del mensaje, pero los datos útiles se reciben perfectamente de las dos formas. Así descarté que el problema estuviera aquí. Después he dejado los componentes del montaje de ?Todo electrónica? para que capte menos ruido. Después vuelvo a montarlo con el PIC y el CMX configurado en modo ?data retiming? y pensé que el problema pudiera estar en que el programa del PIC fuera demasiado lento y no fuera capaz de seguir el ritmo que le imponía el CMX, por lo que cambié el PIC por uno más rápido, pues estaba usando un 16F84A con la misma señal de reloj del CMX, concretamente a 3,579545 Mhz. Lo he cambiado por un 16F876A con un cristal de 20 Mhz, pues el 16F84A que tenía es de 4 Mhz. El resultado es exactamente el mismo, captura los mismos pocos caracteres. Sospeché que pudiera ser problema de falta de velocidad porque originalmente el programa era para un Atmel AVR, que como sabréis, son unas cuatro veces más rápidos que un PIC a la misma frecuencia de reloj, pues ejecutan una instrucción por cada pulso de reloj, mientras que los PIC necesitan cuatro. Así pues, como mis escasos conocimientos de los PIC no dan para más, incluyo el listado a continuación por si alguno quiere perder un rato en estudiarlo, por si detecta algún error o se le ocurre alguna idea para mejorarlo. El montaje es el siguiente: La pata 10 (MODE) del CMX la he unido a la RB3 del PIC. La pata 11 del CMX (ZP) la he puesto a masa La pata12 (IRQN) a la RB0, la de interrupción externa. La pata 13 (DET) del CMX no la he usado. La pata

14 (RXCK) va a RB2 y la pata 15 (RXD) a RB1. En cuanto al programa, en la función main() he hecho un bucle sin fin que solo hace que cambie de color un LED bicolor conectado a las patas RB6 y RB7, que puse para asegurarme de que el programa estaba funcionando. En la pata RB4 he puesto un pulsador para parar el programa y grabar en la EEPROM una serie de variables que he usado para saber hasta donde llega la decodificación. Después de recibir la llamada, la variable CMX_State me suele alcanzar el valor 2 y cont alcanza 5, aunque si cambio el retardo al principio de la rutina de interrupción (delay_cycles (8)) a un valor muy bajo (0 o 1) o muy alto (mayor de 16) CMX_State solo alcanza 1, o cont solo llega a 2 o 3. En el mejor de los casos, la matriz x solo me captura unas dos ?U?, a veces tres, y después caracteres sin sentido, pues sabéis que antes del mensaje principal, se envía una ráfaga de caracteres U (unas 15 o 20). Como veréis, la mayor parte del trabajo se hace en la rutina de interrupción El programa es tal vez demasiado complicado y confuso, pero es que no lo he hecho yo, sino que lo he ?fusilado? del que hay en
formatting link
, limitándome a ?traducirlo? de un AVR a PIC. Es el siguiente:

--------------------------------------------------------------- // Based on Reinhard Kapeller

formatting link

#include #fuses HS, NOPROTECT,NOWDT,NOPUT,NOLVP,NOBROWNOUT,NOCPD,NODEBUG,WRT #use delay (clock=20000000)

#BIT INTEDG = 0x81.6

//Signals of CMX602B - pins of port B of PIC16F876A #DEFINE IRQN PIN_B0 #DEFINE RXD PIN_B1 #DEFINE RXCK PIN_B2 #DEFINE MODE PIN_B3

#define DTMAX 8 // buffer length for datetime #define NBMAX 20 // buffer length for number // CMX602B CMX_States #define IDLE 0 #define RCV 1 #define RCV_U 2 #define RCV_MSGLEN 3 #define RCV_MSG 4 #define RCV_DTLEN 5 #define RCV_DT 6 #define RCV_NBLEN 7 #define RCV_NB 8 #define RCV_ARLEN 9 #define RCV_AR 10 #define RCV_XLEN 11 #define RCV_DONE 12 #define RCV_ERROR 13

char DateTime[DTMAX]; char Number[NBMAX]; byte CMX_State = IDLE; byte NBLen; byte DTLen; byte MsgLen; byte MsgPos; byte BufPos; byte Checksum; byte AbsenceR;

byte cont = 0; byte i, RX_Byte; char x[8];

void Init() { set_tris_a (0); set_tris_b (0b00010011); set_tris_c (0); output_low (MODE); output_low (RXCK); ext_int_edge (H_TO_L); //IRQ on falling edge enable_interrupts (INT_EXT); //enable interrupt (RB0) enable_interrupts (global); // CMX_State = IDLE; }

/* interrupt service routine */ #int_ext void ext_int_handler(void) { if ((CMX_State >= RCV) && (CMX_State < RCV_DONE)) { /* receive bits */ RX_Byte = 0; for (i = 8; i > 0; i--) { delay_cycles (8); output_high (RXCK); RX_Byte >>= 1; if (input (RXD)) /* get bit */ RX_Byte |= 0x80; output_low (RXCK); } x[cont]=RX_Byte; cont++; if (CMX_State >= RCV_MSGLEN) Checksum += RX_Byte; /* calculate checksum */ if (CMX_State >= RCV_MSG) { MsgPos++; /* current message position */ if (MsgPos > MsgLen) /* last byte: checksum */ { if (Checksum == 0) CMX_State = RCV_DONE; else CMX_State = RCV_ERROR; output_bit (MODE, 0); /* FSK receive mode off */ } }

switch (CMX_State) /* process RX_Byte */ { case RCV: if (RX_Byte == 'U') { MsgPos = 0; DTLen = 0; NBLen = 0; AbsenceR = 0; CMX_State = RCV_U; /* -> RCV_U state */ } break; case RCV_U: if (RX_Byte == 0x80) /* "call setup" message */ { Checksum = RX_Byte; /* start calculating checksum */ CMX_State = RCV_MSGLEN; /* -> RCV_MSGLEN state */ } break; case RCV_MSGLEN: MsgLen = RX_Byte; /* message length */ CMX_State = RCV_MSG; /* -> RCV_MST state */ break; case RCV_MSG: switch (RX_Byte) { case 0x01: /* "date/time" parameter */ CMX_State = RCV_DTLEN; /* -> RCV_DTLEN state */ break; case 0x02: /* number parameter */ CMX_State = RCV_NBLEN; /* -> RCV_NBLEN state */ break; case 0x04: /* "absence reason" parameter */ CMX_State = RCV_ARLEN; /* -> RCV_ARLEN state */ break; default: /* unused/unknown parameter */ CMX_State = RCV_XLEN; /* -> RCV_XLEN state */ } break; case RCV_DTLEN: if (RX_Byte == DTMAX) /* valid "date/time" length */ { DTLen = RX_Byte; BufPos = 0; CMX_State = RCV_DT; /* -> RCV_DT state */ } else CMX_State = RCV_MSG; /* -> RCV_MSG state */ break; case RCV_DT: DateTime[BufPos] = RX_Byte; /* store "date/time" byte */ BufPos++; if (BufPos >= DTMAX) /* end of "date/time" parameter */ CMX_State = RCV_MSG; /* -> RCV_MSG state */ break; case RCV_NBLEN: NBLen = RX_Byte; /* store "RX" length */ BufPos = 0; CMX_State = RCV_NB; /* -> RCV_NB state */ break; case RCV_NB: Number[BufPos] = RX_Byte; /* store "RX" byte */ BufPos++; if ((BufPos >= NBLen) || (BufPos >= NBMAX)) CMX_State = RCV_MSG; /* end of "RX" parameter -> RCV_MSG state */ break; case RCV_ARLEN: if (RX_Byte == 1) /* valid "absence reason" length */ CMX_State = RCV_AR; /* -> RCV_AR state */ else CMX_State = RCV_MSG; /* -> RCV_MSG state */ break; case RCV_AR: AbsenceR = RX_Byte; /* absence reason */ CMX_State = RCV_MSG; /* -> RCV_MSG state */ break; case RCV_XLEN: CMX_State = RCV_MSG; /* -> RCV_MSG state */ break; } } /* if ((CMX_State >= RCV) && (CMX_State < RCV_DONE)) */ else if (INTEDG) /* rising edge => end of ring indication */ { delay_ms (2); output_high (MODE); /* FSK receive mode */ CMX_State = RCV; disable_interrupts (INT_EXT); ext_int_edge (H_TO_L); /* IRQ on falling edge */ enable_interrupts (INT_EXT); } else /* falling edge => ring indication */ { disable_interrupts (INT_EXT); ext_int_edge (L_TO_H); /* IRQ on rising edge */ enable_interrupts (INT_EXT); } }

void main() { // int i; Init(); write_eeprom(0x38, 'S'); write_eeprom(0x39, 'p'); write_eeprom(0x3A, 'o'); write_eeprom(0x3B, 'c'); write_eeprom(0x3C, 'k'); // while 1 do nop; //endless loop while (input(PIN_B4)) { output_high (PIN_B7); output_low (PIN_B6); delay_ms (250); output_low (PIN_B7); output_high (PIN_B6); delay_ms (250); } for (i=0; i

Reply to
Spock_Andaluz
Loading thread data ...

Spock, dices que funciona bien con el max232 pero cuando lo conectas al pic no funciona no ?.. pierde caracteres verdad?, si me puedes pegar dos, o tres ejemplos... es para mirar un poco eso y el codigo y revisarlo poco a poco.

P.D: te has fijado si la perdida es aleatoria ?.. o siempre se pierde a partir del mismo caracter?..

--
"Por cierto, de sobra es conocido que no hay quien entienda lo que escriben
los médicos a mano, pero resulta curioso comprobar que tampoco se les
 Click to see the full signature
Reply to
RooT

ponme xxx donde no quieras que se vea XDD, pero ponme una x por cada caracter que quites

--
"Por cierto, de sobra es conocido que no hay quien entienda lo que escriben
los médicos a mano, pero resulta curioso comprobar que tampoco se les
 Click to see the full signature
Reply to
RooT

uf ! Coger un programa ajeno, y tratar de depurarlo, es algo que escapa a mis posibilidades.

Sin embargo este programa tiene cosas en comun con el que uso yo, tambien se trata de un pic trabajando contra un puerto serie (en mi caso de un telefono movil).

Lo que yo he hecho es hacerlo paso a paso, y siempre conectado contra un ordenador que simula el funcionamiento del movil. Además he añadido controles en el programa, éste manda mensajes por el puerto serie, son mensajes para el programa que corre en el ordenador y que quito cuando conecto con un movil.

en cuanto ha hacerlo paso a paso, por ejemplo:

- haces una rutina que envía strings por el puerto serie, la programas en el pic, la pruebas con el ordenador. - idem, recibiendo strings y devolviendo un eco (con la rutina probada en el paso anterior)

- haces un rutina que analice el string que recibe, el resultado lo manda por el puerto serie.

- ... creo que no te quedaría mucho más.

Toda la parte de "enviar por el puerto serie" no te serviría en el programa definitivo, pero es muy util mientras depuras porque puedes seguir desde el PC el funcionamiento del PIC por los mensajes que este te envía.

La ventaja es que cuando algo no funciona, sabes donde no funciona, aún así a veces cuesta encontrar el fallo.

En programa que has posteado no lo entiendo, pero me ha parecido ver una rutina de interrupcion enoooorme, que incluso tiene dentro bucles de delay, .... no parece un buen enfoque.

Reply to
Nolo Pongo

He simplificado al máximo la función que atiende la interrupción, haciendo que solo capture los caracteres ?en bruto?, sin preocuparse de que caracteres son, para que vaya lo más rápido posible y el resultado sigue igual, solo captura uno o dos caracteres U y otros dos o tres caracteres más sin sentido y no se ejecuta más. Cuando empecé a hablar de este asunto, hubo otros dos (creo recordar que KT88 y ZooM) que dijeron que también habían comprado el chip. Estaría bien que alguien más intentara usarlo, pues yo no consigo avanzar. Da la impresión de que el CMX602B no funciona bien en el modo ?data retiming?, como si algo lo interfiriera. Teniendo en cuenta que el montaje lo he hecho con una placa de prototipos Ariston, de las que los componentes se pinchan sin soldar y que los componentes los he dejado con las patas completas, tal como vienen, sin cortarlas, pienso que tal vez esto cause algún problema, pero lo extraño es que cuando no se usa el ?data retiming? y lo conecto al PC a través de un MAX232, se reciben perfectamente todos los caracteres en el PC. Es cuando el CMX602B está controlado por un micro cuando la cosa no funciona. Salu2.

--
Este mensaje está compuesto de electrones 100% reciclables.
Reply to
Spock_Andaluz

Fíjate bien, porque creo recordar que algunos de esos sin condensadores no valían para velocidades menores que 9600 bps. Hoy día no se suelen usar velocidades inferiores, pero es algo a tener en cuenta.

--
Saludos de José Manuel García
jose.mgg@terra.es
 Click to see the full signature
Reply to
pepitof

En el peor de los casos, 116kbps con el MAX203, y en el mejor, 250kbps, con los MAX3233 y MAX3235. El conocido MAX232, tiene un techo de 120kbps, y la versión MAX232A llega a

200kbps.
Reply to
KT88

KT88 escribió:

los MAX3233 y

200kbps.

Pero lo que dice Pepitof es que esos chips no funcionan con una velocidad muy baja. Por ejemplo, para el caller id tuve que usar un MAX232 funcionando a 1200 baudios, por lo que seguramente los que dices no se podrían usar. Salu2.

--
Este mensaje está compuesto de electrones 100% reciclables.
Reply to
Spock_Andaluz

MAX203E, MAX233,

integrados

Samples en camino...

--
"Por cierto, de sobra es conocido que no hay quien entienda lo que escriben
los médicos a mano, pero resulta curioso comprobar que tampoco se les
 Click to see the full signature
Reply to
RooT

Yo no leo, nada de eso en el datasheet. Solo indican el Maximum Data Rate, que es de 120kbps para el MAX203, y una escueta referencia al principio; "The MAX203 and MAX205 use no external components, and are recommended for applications with limited circuit board space". Eso es todo, en ningún momento, indican que exista una velocidad mínima, para que funcionen en condiciones, y si esa así, es decir no tienen limitaciones por debajo, el ahorro es considerable, en el diseño de cualquier circuito.

Ya tengo por aquí unos samples, los probaré con un circuito que comunica el movil con el PC.

También tengo, samples del MAX3233, que tiene un techo de 250kbps, y alimentación a 3v., o la versión MAX3235 con el mismo techo, y 5v de alimentación. De nuevo, en este datasheet, tampco veo referencia alguna, a velocidad mínima.

Además, incluyen auto-shutdown, que los ponen en bajo consumo, hasta que detectan tránsito de datos, para mejorar la autonomía del circuito.

Reply to
KT88

Por eso te lo digo, porque no aparece en el data-sheet. Supongo que dan por hecho que no se van a usar para velocidades bajas. Es que yo estuve probando el MAX3233 y me encontré con ese problema, que me tuvo un poco loco al principio. A 1200 baudios daba fallos esporádicos, y claro, antes de pensar en el MAX, pensé en fallos en mi programa, en el cable, etc, hasta que se me ocurrió probar a 9600 e iba perfecto.

--
Saludos de José Manuel García
jose.mgg@terra.es
 Click to see the full signature
Reply to
pepitof

Ok, lo probaré, y de paso les voy a enviar una consulta por email, a MAXIM, a ver que se cuentan al respecto.

Reply to
KT88

Acabo de escribir una email a MAXIM, comentandoles el caso, a ver que dicen. De todas formas, podría ser un problema del hardware (a menos que con un MAX232 si que funcionase), por ejemplo, mis pruebas con móviles, no permiten establecer comunicaciones por debajo de 4800bps, hacen cosas raras y fallan constantemente, sin embargo a

9600bps van perfectos, usando MAX232 y MAX3232.
Reply to
KT88

No lo sé. En mi caso era comunicando con un modem de aquellos antiguos que montaba telefónica en los bancos para 3270, y al conectarlos a un terminal (o un emulador en PC) no había problema, ni a 1200 ni a 9600. De todas formas puede que el fallo estuviera en mi firmware, y que se solucionara al cambiar la rutina para 9600 (era sobre un 8751). No lo tengo muy reciente y no puedo asegurártelo, pero tenlo en cuenta si te da fallos a baja velocidad. Habitualmente tendemos a pensar que sólo hay límites en cuanto a la máxima velocidad, pero los chips para RS232 pueden tener problemas en cuanto a mínima velocidad. De hecho, los clásicos MAX232 también dan problemas a baja velocidad si se usan condensadores de valor muy bajo.

--
Saludos de José Manuel García
jose.mgg@terra.es
 Click to see the full signature
Reply to
pepitof

Bueno, he recibido la respuesta de MAXIM, si que han sido rápidos, y es la siguiente:

======================================================= Luis, I can find no documentation regarding your concern for the functionality of the MAX203. However, I do recommend that you use the newer MAX3233E instead of the MAX203 so that you may take advantage of the 4 years worth of technological advantages packaged in the MAX3233E. You will be very satisfied with the performance that the MAX3233E affords.

Regards Apps Tech Support =======================================================

En principio, ellos no tienen constancia de tales fallos, pero recomiendan usar el MAX3233, que es bastante más moderno. Como tengo de ambos, haré pruebas, pero no debería haber problemas trabajando a 4800 ó 9600bps, pero la ventaja de eliminar los condensadores tradicionales, para el MAX232, me parece muy interesante, para simplificar, sobre todo el PCB, que en muchas ocasiones es lo más problemático, sobre todo tratando de evitar doble cara o puentes.

Reply to
KT88

Por cierto, lo he soñado, o me ha parecido leer, que hay algún PIC, que incluye el cuarzo del oscilador en su interior, o al menos algún tipo de oscilador, bastante estable, y que se calibra por software. No me refiero al típico oscilador RC, que poca estabilidad puede ofrecer, sobre todo ante cambios de temperatura.

Si no existe, y yo fuera ingeniero de algún fabricante de microcontroladores, ya se me hubiera ocurrido integrar el cuarzo en su interior, para solo precisar alimentarlo y arreando. Siempre pensando en un oscilador estable, controlado por cuarzo o PLL, nada de chapuzas RC.

Reply to
KT88

En las característivas de los RFPIC dice que tienen "Integrated crystal oscillator", pero creo que incluyen todo el oscilador menos el cristal en sí. Yo también me he preguntado más de una vez por qué ningún micro integra un cristal o un resonador cerámico. Es sorprendente que ni siquiera algunos micros destinados casi exclusivamente a relojes lo lleven.

--
Saludos de José Manuel García
jose.mgg@terra.es
 Click to see the full signature
Reply to
pepitof

Desde la más absoluta ignorancia: ¿no será que un xtal tiempre tiene un tamaño respetable ? Yo compre unos cristales para montaje smd, de ancho y de fondo eran tan grandes como los normales, solo que la altura era bastante pequeña. Digo yo que si un crital se pudiera meter en 1 mm2, ya los estarían haciendo así ¿ no ?

Reply to
Nolo Pongo

Se podrían reducir bastante. Los típicos de 32768 Hz que usan los relojes se encuentran en encapsulados muy pequeños (un cilindro de 1.5mm de diámetro por 5mm de largo), y se supone que a más frecuencia, el tamaño del cristal será más pequeño. Aunque seguirá siendo un trasto comparado con la die del chip, se podría embutir en la misma cápsula. Una razón que se me ocurre, desde el punto de vista del fabricante, es que eso encarecería el producto, al restarle flexibilidad y obligar a crear micros de varias frecuencias, con lo que las tiradas de cada tipo son menores. Pero creo que si algunos modelos muy utilizados, como el 8051, se fabricaran con cristal de frecuencia bien elegida integrado, podrían tener bastante éxito. Y teniendo en cuenta la cantidad de periféricos que integra hoy en día cualquier micro, no sería difícil añadir un generador de frecuencias suficientemente flexible para permitir obtener una gran gama de frecuencias a partir de la frecuencia del cristal.

--
Saludos de José Manuel García
jose.mgg@terra.es
 Click to see the full signature
Reply to
pepitof

Voy ha hacer de abogado del diablo,

formatting link

Lo mismo que los max, pero el 202 con condesadores y el 203 sin, te envian samples, por desgracia a mi me han tardado un mes, y hoy me han llegado y no sabia ni que eran, sorpresa al mirar el datasheet.

P.D: Lo extraño de todo es que tienen las patillas para las conexiones, sin embargo en el datasheet pone, NO CONECTAR XD.

--
"Por cierto, de sobra es conocido que no hay quien entienda lo que escriben
los médicos a mano, pero resulta curioso comprobar que tampoco se les
 Click to see the full signature
Reply to
RooT

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.