Decodificação de controle remoto IV da Philips

[kaoalex]

Pode ser isso que o jeanfernandes se referia
http://www.picbasic.nl/rc5-rc6_transceiver_uk.htm

[MOR_AL]

Pode ser isso que o jeanfernandes se referia
http://www.picbasic.nl/rc5-rc6_transceiver_uk.htm

Hã! Agora entendi. Realmente não tive oportunidade de navegar pelo site. O Velox daqui ficou lento e morreu por dois dias. Agora ressuscitou. Hehe!.
Mas vamos lá:
Jean
O projeto é legal sim mas não atende às minhas diretivas, quais sejam:
1 - Aprender fazendo.
Se eu copiar o projeto, provavelmente vou tê-lo funcionando, porém sem saber projetar um. Projetando, eu tenho o domínio do assunto. Isso me capacita para a diretiva seguinte.
2 - Fazer um segundo projeto. Usar o controle remoto para acionamento. Vide figura:

A idéia é usar um PIC16F628A para acionar 13 saídas, cujos códigos são: de 1 a 9, V (seta para baixo), /\ (seta para cima), < (esquerda) e > (direita). O zero é usado para outra finalidade.
Os leds são apenas para visualizar as saídas. Após estarem funcionando, eu retiro os jumpers e uso as outras saídas mostradas na placa.
Pretendo, mas não sei de dará para fazer, o seguinte:
a) Que algumas saídas simplesmente mudem de estado ao receberem o código dela.
b) Que algumas saídas gerem um pulso com um tempo programado anteriormente.
c) Que algumas saídas gerem o pulso dos rádio-controles.

Ainda estou na fase da lógica de programação (o fluxograma do que deve ocorrer). Considero esta a parte mais difícil. Estou usando o assembler porque haverão diversas interrupções ocorrendo intercaladas. Nem sei se dará para fazer. Enquanto, que na identificação dos códigos (projeto anterior), os períodos eram gerados por contagem de tempo, ou melhor, por perda de tempo, e apenas uma interrupção, deu trabalho mas foi possível. Agora, com estas saídas gerando tempos, ficou mais difícil compatibilizar o tratamento da entrada de dados, via controle remoto, com os tempos das saídas.
Mas vamos ver se dá para fazer.

jorgeluiz

1 - Use algum protocolo de comunicação. É mais apropriado e já possui alguma insensibilidade a erros.
2 - Aumente esta insensibilidade introduzindo alguma redundância. Esta redundância poderá ser a repetição do mesmo código três vezes. Isso também diminui a rapidez do seu sistema. Porém, acredito que não haverá problema, uma vez que qualquer motor possui inércia a ponto dela ser superior ao atraso causado pela repetição do código.
3 - Use um código que transmita o clock embutido. Isso traz dois benefícios:
a) Reduz a banda de frequências do seu sinal a ser transmitido. O que é um benefício. Imagine que com uma banda larga, você terá que fazer o filtro de seu receptor, plano para as frequências do seu sinal. Isso é difícil.
b) Com o clock embutido você dobra a sua frequência do seu sinal. O mesmo sinal precisa do dobro do limite superior da frequência do seu sinal. Isso poderia levar a pensar que a sua faixa de sinal aumentou em relação ao seu intento original. Mas não é verdade. Com o clock você aumenta a frequência inferior do seu sinal. A faixa fica mais estreita.
Outro benefício é que você, provavelmente não precisará de cristal para decodificar o seu sinal, uma vez que o clock te fornece o sincronismo em cada bit transmitido. Ou seja. Se o seu sincronismo original era para um byte (8 bits) e a taxa de transmissão do seu sinal (baud rate), era fixa e com especificação de erro percentual de, digamos 5%, com o clock a coisa muda. Com o sincronismo ocorrendo em cada bit, seu sistema melhora na precisão, de cara, 8 vezes. Além disso, a percentagem do seu erro poderá aumentar também, a ponto de não precisar usar cristal. Veja que na minha placa não há cristal.
Use o código Manchester, por exemplo.
Eu já fiz um sistema de comunicação, antes da era do 8051, com componentes discretos e portas lógicas e deu certo. E olha que era um sistema que controlava um equipamento, que transportava 600A @ 13600V, ou 8,16MVA.
Espero ter ajudado.
[]'s
MOR_AL

[jorgeluiz]

"clock embutido". Beleza! Nem tinha pensado nisso. Valeu pelas dicas.

[MOR_AL]

"clock embutido". Beleza! Nem tinha pensado nisso. Valeu pelas dicas.

Ok!
MOR_AL

[MOR_AL]

Bom.
Terminei mais uma etapa.
O controle identifica as teclas e aciona as saídas. Agora ele usa duas interrupções; INT para as transições do sinal infravermelho de entrada e do TIMER0 para a contagem dos tempos. O programa não usa mais tempos gerados por rotina de atraso. Apenas a interrupção do TIMER0.
Este fato é essencial para poder atualizar as saídas. Principalmente as de rádio controle.
Conforme eu havia previsto, a lógica do programa deu (muuuiiitooo) mais trabalho que a programação em assembler. Esta, após o fluxograma ter sido concluído, foi até simples.
Para quem se interessar, segue o fluxograma da parte de decodificação do sinal do receptor infravermelho. Ele é auto-explicativo, mas leva algum tempo para assimilá-lo.
http://rapidshare.com/files/299786987/RC5.doc
O passo seguinte é introduzir uma senha de acesso e depois a possibilidade de programar o modo de funcionamento de cada saída. Se inverte a saída a cada pressionar da tecla (já feito), se gera um tempo em '1', ou se gera um sinal de rádio controle.
MOR_AL