Interpretando la señal capturada en el osciloscopio

[MichaelKnight]

Bueno, esta noche he sacado un tiempo para poder desmenuzar la señal. Esta se compone de una parte iregular de 167bits y luego termina con 95bits a 1. No tengo claro si 95 o 96 porque al dividir me daba un da un decimal alto, todo es probar.

Mañana tengo que ir a comprar un componente para poder programar el pic y pruebo si de verdad esta señal esta bien imitada.

Pruebas empiricas aparte, lo unico que no estoy muy orgulloso de la optimizacion del codigo. Esta claro que vuestras ideas han sido cruciales, fijaos que he pasado de no poder compilar por exceder la ram del pic a usar un maximo del 16% de la misma segun el compilador. Ahora en cambio lo que me parece "desperdiciada" es la rom, pues dice estar usando el 77% en algo que considero que es simplisimo y disponiendo una rom de 256. He creado programas mucho mas complejos y mas largos en cuanto lineas de codigo que han ocupado muchisimo menos tras su compilacion. Os pongo la parte del codigo que desperdicia recursos por si me sugeris soluciones mas optimas.

Código: [Seleccionar]

   const unsigned long parte1=1011101111;
   const unsigned long parte2=1011101010;
   const unsigned long parte3=1110101010;
   const unsigned long parte4=1110111010;
   const unsigned long parte5=1110111010;
   const unsigned long parte6=1011101110;
   const unsigned long parte7=1110101011;
   const unsigned long parte8=1010101010;
   const unsigned long parte9=1110111010;
   const unsigned long parte10=1011101110;
   const unsigned long parte11=1010101010;
   const unsigned long parte12=1010101010;
   const unsigned long parte13=1010101010;
   const unsigned long parte14=1010101010;
   const unsigned long parte15=1010101010;
   const unsigned long parte16=1010101110;
   const unsigned long parte17=0101010;
   unsigned int i;
   
   for(i=0; i<10;i++){
   
      if(((parte1>>i)&1)==0){
         
         no;
      }
      else{
     
         si;
      }
     
      delay_us(tiempo);
   }
   
   for(i=0; i<10;i++){
   
      if(((parte2>>i)&1)==0){
         
         no;
      }
      else{
     
         si;
      }
     
      delay_us(tiempo);
   }
   
.......

   for(i=0; i<7;i++){
   
      if(((parte17>>i)&1)==0){
         
         no;
      }
      else{
     
         si;
      }
     
      delay_us(tiempo);
   }
   
   for(i=0;i<96;i++){
   
      si;
      delay_us(tiempo);
   }


Dado que un long llega hasta 4,294,967,295 con lo que he tomado solo 10 digitos por cada trozo.

¿Hay alguna solucion mas elegante para por lo menos los 167 primeros bits?

Saludos y gracias a todos por vuestras aportaciones que han sido de gran ayuda hasta el momento.

[MerLiNz]

estas usando una variable de 32bits para 10bits, eso es un derroche de memoria.

Como ya te dije, en CCS usa "int32" en vez del long, el long te lo puse porque yo uso C18 y es distinto el tamaño de las variables.


int32 trama1=0b11111111....hasta 32 (sin contar el 0b).

ES MUY IMPORTANTE PONERLE EL 0b, esto significa que estas diciendo que el numero es binario, el 0b no cuenta nada, el numero 0b110 es 1-1-0 en binario.
Tienes que tener muy claro que no es lo mismo trabajar con binario, que decimal, que hexadecimal, al fin y al cabo todos significan lo mismo, pero cuando te he propuesto la idea del desplazamiento de bits debes trabajar en binario con esa variable.

[MichaelKnight]

Pues mano de santo! con esta ultima optimizacion he reducido el numero de trozos y el uso de la ROM ha caido hasta el 36%, lo que es una mejora importante.

Ahora he pensando hacer el codigo aun mas elegante y crear un doble bucle for de modo que lleve la cuenta del trozo de señal que esta procesando y tras terminar con uno pase al siguiente. Salvo errores en tiempo de ejecucion, en cuanto a tiempo de compilacion todo sale ok para este metodo.

Código: [Seleccionar]

   unsigned int i,j;
   char trozo[6];
   
   for(j=1;j<6;j++){
   
      strcpy(trozo,"parte");
      strcat(trozo,j);
     
      for(i=0; i<32;i++){
   
         if(((trozo>>i)&1)==0){
         
            no;
         }
     
         else{
     
            si;
         }
     
         delay_us(tiempo);
      }
   }
Y mejor aun, la rom queda mucho mejor aprovechada con un 18% de uso, practicamente nada, y la ram oscilando entre un 11% y un 30% que lo veo mas que razonable. Ahora que he optimizado recursos (no se si aun se pueden optimizar mas) me surge la duda de si con este nuevo algoritmo no interferire entre los retardos, pues nos movemos en 155us por bit. A falta de que mañana pueda programar el pic y hacer pruebas empiricas, ¿a vuestro juicio puede penalizarme mucho esta ultima solucion?

[MichaelKnight]

Entre esta noche y mañana espero poder poner en la protoboard el montaje. Por lo pronto el pic ya esta programado y solo falta ponerlo a prueba. Os pondre al tanto de los resultados.

Saludos.

[MichaelKnight]

Vale... pues fiasco

Encima me despiste con un cable que usaba para dar la señal de activacion e hice cortocircuito y ya he quemado un agujero de la protoboard

Bueno, tratando de buscar soluciones se me ocurren varias aunque no tengo claro que sean la solucion.

Como referencia, ahi el codigo empleado:

Código: [Seleccionar]

#include <12f683.h> // Selecciona el PIC
#include <string.h>
#fuses INTRC_IO, NOMCLR, NOWDT, NOBROWNOUT
#use delay(clock=4000000) // Velocidad del reloj : 4 Mhz

#define ir PIN_A2
#define activacion PIN_A3
#define si output_high(ir)
#define no output_low(ir)

const unsigned int tiempo=155;//us

void prueba(){

   //señal=01010101010101110101010101010101010101010101010101010101010101010101011101110111011101010101010101110101011101110111011101110101110111010111010101010111010101011101111;
 
   
   const unsigned int32 parte1=0b10111010101010111010101011101111;
   const unsigned int32 parte2=0b10111011101110111011101011101110;
   const unsigned int32 parte3=0b10111011101110101010101010111010;
   const unsigned int32 parte4=0b10101010101010101010101010101011;
   const unsigned int32 parte5=0b10101011101010101010101010101010;
   const unsigned int   parte6=0b0101010;
   unsigned int i;
 
     
   for(i=0; i<32;i++){
   
      if(((parte1>>i)&1)==0){
         
         no;
      }
     
      else{
     
         si;
      }
     
      delay_us(tiempo);
   }

   
   for(i=0; i<32;i++){
   
      if(((parte2>>i)&1)==0){
         
         no;
      }
      else{
     
         si;
      }
     
      delay_us(tiempo);
   }
   
   for(i=0; i<32;i++){
   
      if(((parte3>>i)&1)==0){
         
         no;
      }
      else{
     
         si;
      }
     
      delay_us(tiempo);
   }
   
   for(i=0; i<32;i++){
   
      if(((parte4>>i)&1)==0){
         
         no;
      }
      else{
     
         si;
      }
     
      delay_us(tiempo);
   }
   
   for(i=0; i<32;i++){
   
      if(((parte5>>i)&1)==0){
         
         no;
      }
      else{
     
         si;
      }
     
      delay_us(tiempo);
   }
   
   for(i=0; i<7;i++){
   
      if(((parte6>>i)&1)==0){
         
         no;
      }
      else{
     
         si;
      }
     
      delay_us(tiempo);
   }

   
   for(i=0;i<96;i++){
   
      si;
      delay_us(tiempo);
   }
}
   
void main(){
   
 
   do{
   
      if(input(activacion)==TRUE){
   
         prueba();
      }
     
   }while(TRUE);

}
Ideas:

- La primera es que este comentiendo errores al "trocear" los bits y para evitar contaminaciones, por radical y ridiculo que suene, voy a buscar la forma de abrir el mando y conectar directamente el osciloscopio al propio emisor.
- La segunda es que, como ya comente anteriormente, quizas los retardos de las comprobaciones y bucles falseen la señal

En principio esto es lo que me viene en mente, si me podeis aportar alguna idea mejor estare encantado de probarla.

Saludos.

[MerLiNz]

te puedes ahorrar mas codigo haciendolo de la siguiente manera:

const unsigned int32 partes[6]={0b.......,0b.....,....};


for(y=0;y<6;y++) {
for(i=0;i<32;i++) {
 
if(y==5 && i>6) break; //este para el ultimo que solo contiene 7bits 0->6
      if(((parte[y]>>i)&1)==0){
        
         no;
    ..................

}




}

[MichaelKnight]

Es un codigo muy astuto que tendre que probar. No obstante, creo que esta noche probare con otro mando de otro electrodomestico a ver si tiene una trama menos extraña.

Saludos e ire informando de mis resultados.

[solapower]

Por si puede servirte de ayuda navegando en busca de otras cosas me ha aparecido esta información que quizás pueda serte de ayuda.
http://sunbizhosting.co.uk/~spiral/blog/?p=85
Salud

[MichaelKnight]

Por si puede servirte de ayuda navegando en busca de otras cosas me ha aparecido esta información que quizás pueda serte de ayuda.
http://sunbizhosting.co.uk/~spiral/blog/?p=85
Salud

Mas que nada es una buena curiosidad, pues desconocia que el PIC KIT2 hiciera de osciloscopio para este tipo de casos. En cuanto a la captura de la trama, creo que ya la tenemos, su interpretacion creo que tambien y ahora falta su correspondiente implementacion que no se si falla en cuanto a una mala interpretacion o a retardos excesivos derivados de los bucles y comprobaciones. Esta noche espero poder dedicarle un tiempo.

Gracias por tu interes.

[MichaelKnight]

Poco a poco todo va empezando a aclararse, aunque aun no tengo nada operativo.

Segun he podido aprender en el foro de Nocturno, los mandos tienen diferentes standares y el efecto que a nosotros nos parecia anomalo de que los 0 y los 1 tuvieran diferentes duraciones resulta que no es tan anomalo si no normal. Ahora toca, descifrar el standard que usa el mando que me ocupa y a partir de ahi ir sacando conclusiones.

Con todo lo anterior podria parecer que es todo pan comido, pero a tenor de lo que veo la cosa no pinta facil:

http://users.telenet.be/davshomepage/

En ese enlace explican varios standares y segun he podido comprobar mi mando no casa con ninguno.

Añado imagen para ilustarlo



Como se aprecia, la duracion del pulso inicial no coincide con ninguno de los standares. O al menos yo no logro ver correspondencia alguna.

Saludos y gracias de antemano.

[pablomanieri]

Acá hay algunos rotocolos más http://zerocircuits.zobyhost.com/Protocolos/protocolos.php

[micro_pepe]

Pues viendo este último oscilograma que has puesto, yo creo que se corresponde con un Sony ( http://www.sbprojects.com/knowledge/ir/index.php                            http://www.sbprojects.com/knowledge/ir/sirc.php ).

¿Como estás midiendo? ¿Con un sensor de infrarrojos? Si es así y es de este tipo:



te invierten la señal, entonces para verlo correctamente deberias invertir la señal en el osciloscopio.

Saludos.

[MichaelKnight]

Gracias por colaborar.

El mando que trato de imitar es el de un aire acondicionado para que se encienda cuando la habitacion supera los 30ºC y se apague al bajar de 22ºC. Es para una sala de servidores de una pequeña empresa que instalo un split convencional para el control de temperatura de la sala pero que logicamente es ineficiente porque no tiene termostato y alguien tiene que estar encendiendo y apagando. Logicamente, por la noche no es tan necesario y lo dejan apagado y lo encienden por el dia, pero para que no se olvide y no haya "error humano" se va automatizar.

Segun he ido leyendo, los mandos de aire acondicionado son muy puñeteros porque tienen diferentes protocolos y las señales son muchisimo mas largas de lo que con el osciloscopio estoy pillando. Es mas, la señal que implemente esta incompleta porque tengo que poner el muestreo a un tiempo por division mayor para pillarla entera, siendo imposilbe ver pulsos.

Lo mejor en este caso es utilizar la tarjeta de sonido y poner a grabar la onda con un programa de edicion de audio. Con este otro metodo puedes jugar mucho mas con la señal.

Ire comentando mis progresos.

Saludos.