Ou melhor dizendo - Tentando desvendar Controle Remoto RF.

Depois que consegui fazer funcionar o Analisador Lógico com o Arduino, tenho feito várias verificações que sempre quis fazer. Fiz uma análise de controle remoto usando a Luz infravermelha e agora estou fazendo uma análise mais apurada de controle remoto que usa Rádio-frequência RF).

Tutorial - Analisador Lógico com Arduino:

http://labdegaragem.com/profiles/blogs/tutorial-analisador-l-gico-c...

Decodificando Controle Remoto infravermelho:

http://labdegaragem.com/profiles/blogs/6223006:BlogPost:315534

Já li em vários Blogs do Lab de Garagem, que muitos desejam usar o Controle Remoto RF com o Arduino.

Para a minha decepção e acredito que  muitos se decepcionarão também, os controles remotos atuais são criptografados.Por isso, alguns já tentaram usar e falharam.

Para entender melhor, fiz uma análise do Controle Remoto do fabricante Rossi. (aciona a abertura e fechamento de portões de garagem). Esse controle usa o chip HCS201 da Microchip:

http://ww1.microchip.com/downloads/en/DeviceDoc/41098c.pdf

Possui dois botões (chaves) S0 e S1. A frequência da portadora é de 433,92 MHz. Usa uma pilha de 12V.

O link da Rossi portões, com os circuitos de controle de portões:

http://www.rossiportoes.com.br/produtos/120-central-de-comando.html

Lendo o data sheet do chip HCS201 da Microchip, percebi que a tecnologia usada é bem segura.

Ele é bem versátil - cada chip tem um número de série programável de 28 bits e uma chave de criptografia de 64 bits (acredito que é impossível descobri-la) . Essas informações são gravadas pelo fabricante do controle remoto (no caso a Rossi).

Cada transmissão tem um código diferente, por isso, se o circuito receptor não souber a chave criptográfica do fabricante, não haverá rotina de decodificação que permita identificar qual código foi transmitido. Fiz vários testes e comprovei ! Pressionei várias vezes o botão S1 e a cada momento o trem de pulsos era de um formato diferente.

Seria possível usar o controle remoto, desde que usasse um chip programado pelo desenvolvedor.

Assim a rotina de decodificação usaria a chave gravada no chip.

Vejam que interessante as várias telas capturadas usando o Analisador Lógico com o Arduíno.

Minhas medições foram no saída TX OUT do chip HCS201. Alimentei o controle remoto com 5V para não danificar o Arduino.

Essa captura foi feita pressionando o botão S1 - taxa de amostragem de 5 KHz :

Vejam que tem 12 pulsos de preambulo para sincronização :

Taxa de amostragem de 10 Khz.

Os 12 pulsos de preambulo usam a largura de pulso de 780 us:

(taxa de amostragem 50 KHz) 

Para decodificar os bits 0 e bit 1 :

Esse é o formato do Bit 0 : (taxa de amostragem 50 KHz) 

E esse é o formato do Bit 1 : (taxa de amostragem 50 KHz) 

Exibições: 87366

Responder esta

Respostas a este tópico

O sensor de  que você  esta falando é do link que eu enviei.

Nesse  sensor de porta , deve existir um circuito comparador de tensão que aciona uma das portas do HT6P20B.

Estranho, perdeu meu post.

Eu tenho nenhum conhecimento de eletrônica, muito menos de como funcionam esses sensores. Então só estou divagando mesmo.....

Se eu fosse implementá-los, eu usaria um reed switch com 3 pernas (um pouco mais caro no aliexpress) que tem conexões N/A e N/F.

E usaria um capacitor para alimentar o circuito.

Assim, quando o sensor estivesse em repouso, o switch conectaria a bateria no capacitor mantendo uma carga nele.

Quando o sensor fosse acionado, o switch inverte desconectando a bateria e conectando o capacitor no circuito de transmissão.

Quando a  bateria está boa, a carga no capactior é completa e é capaz de alimentar o circuito por um determinado tempo fazendo com que este consiga transmitir o código HT6P umas 40x vezes por exemplo.

Quando a bateria começasse a ficar fraca, a tensão no capacitor diminui e consequentemente a carga nele. Assim, quando o switch inverte a carga no capacitor será suficiente para alimentar o circuito por menos tempo e ele transmitirá menos vezes, por exemplo 20x. Assim a central saberia que pilha está fraca quando a quantidade de repetições diminuisse.

A ventagem seria a de gastar menos. A desvantagem é que a central só saberia que a bateria está fraca quando houvesse um acionamento.

Tivesse essa idéia quando percebi que o sensor transmitia sempre 40x o código HT6P completo e mais os primeiros bits do que seria a 41a repetição, me parecendo que o circuito parava de transmitir quando a carga acabava.

Estava respondendo ao Leonardo - são esses sensores 
http://labdegaragem.com/forum/topics/projeto-alarme-sem-fio-arduino...

divagações acima...não sei por que a primeira vez q postei só saiu a primeira frase, então refiz o post.

Divagações...

O sensor de porta deve ter um comparador de tensão. 

Quando a tensão da bateria abaixa além do limite, esse comparador aciona uma das portas do HT6P20B. 

Simples assim...

desculpa a minha falta de conhecimento, mas para usar um "comparador de tensão" não teria que ter uma tensão de referência para "comparar"? Ou funciona de forma diferente?

Boa noite Clovis, 

Você esta certo. Um monitor de tensão de bateria compara uma tensão de referência menor do que o valor da tensão da bateria descarregada. 

Assim através do calculo proporcional, pode-se avaliar a tensão da bateria.

A tensão de referência deve ser ajustada por um diodo zener ou por  um outro circuito regulador. (existem chips específicos para isso) . 

Acredito que o software no receptor fica verificando se o cod. apresentar erros depois das primeiras sequências do transmissor...   tipo o transmissor começa transmitindo corretamente de pois passar a enviar lixo, provavelmente a bateria esta ficando ruim...

Caro Alexandre , quando a bateria esta fraca, o sensor envia um código HEXA. 

 http://labdegaragem.com/forum/topics/projeto-alarme-sem-fio-arduino...

Me desculpe JGAM, fui muito econômico em minha resposta...
Em um sistema de alarme residencial comercial o qual os transmissores (chaveirinhos) e sensores sem fio utilizam somente o chip HT6P20B... li em algum paper (há muito tempo) que o software no receptor fica verificando se o cod. apresentar erros depois das primeiras sequências do transmissor... tipo o transmissor começa transmitindo corretamente de pois passar a enviar lixo, provavelmente a bateria esta ficando ruim..
Imagina que seu controle deve transmitir o seguinte padrão 3134630303..
Você aperta o botão ele transmite....
3134630303.....3134630303.....3134630303....31346300... 3134000..
O soft no receptor só tem que verificar se as transmissões que começaram bem (padrão detectado algumas vezes) mas acabaram mal em uma sequencia de varias transmissões do padrão.... e com isso supor que a bateria do transmissor esta fraca...

Olá á todos, tudo bem ? 

Está acontecendo um conflito estranho em um código meu...

Eu utilizei este código do Torquato para ler o controle 433, funcionou perfeitamente ( https://acturcato.wordpress.com/2014/01/10/emulator-for-ht6p20b-enc...) porém neste mesmo projeto tenho um LCD que mostra data, hora, temperatura e umidade, e vem acontecendo o seguinte: 

Quanto carrego os dois códigos simultaneamente ele "anula" o 433, a porta que eu estou usando para o shield 433 é a porta D8, a porta analógica para a função de piscar o LED enquanto faz a leitura eu desativei.

Desconfiei de que era problema com loop, então utilizei a biblioteca TimerOne.h para que o 433 ou o LCD rodasse no fim do loop, o codigo do LCD funciona tanto no loop quanto por interrupção com timer, já o 433 também funciona exceto quando eu ativo o LCD.

Vocês tem conhecimento se há incompatibilidade entre as bilbliotecas utilizadas no LCD (LiquidCrystal_I2C.h, DS1307.h e Wire.h)

Obrigado!

Código do LCD (http://pastebin.com/7DWHXB5G)

Boa tarde Fábio, 

As rotinas de descodificação do controle remoto são totalmente dependentes de tempo. 

Se intercalar qualquer outra rotina juntamente, não vai funcionar. 

Minha sugestão seria usar dois Arduinos e interliga-los através de serial ou outro tipo de comunicação. 

RSS

© 2024   Criado por Marcelo Rodrigues.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço