Recepção de códigos via wireless - controle remoto

[lpagano]

Pessoal,

Preciso fazer um controle remoto que envie uma série de bits (8 bits) mais um start bit e um stop bit via wireless até um receptor conectado a um PIC.

Isso deve funcionar da seguinte maneira: quando o controle remoto envia os bits em série o PIC que está no receptor identifica o start bit e começa a fazer o reconhecimento do código que está recebendo. Caso esse código recebido esteja em desacordo com o código pré-gravado no PIC, o restante da sequência recebida é ignorado.

Resumindo, é igual àqueles controles remotos de carro ou garagens com encoders e decoders da Holtek, só que no meu caso eu não posso usar eles pois precisa ter a capacidade de trocar o código de envio a partir de comandos do controle remoto, por segurança.

Alguém tem uma noção de como devo começar a fazer isso no PIC, para poder reconhecer o código que é enviado a ele?

Valeu!

[ze]

olá. creio que não deve se preocupar com start e stop BITs. Isto já é inerente ao hw (desde que não vá usar por sw). Sugiro que pense em "start" e "stop" BYTES. P. ex. 0x55--bytes efetivos--0xaa. Ou seja, em palavras humanas, seu sistema vai bufferizando bytes efetivos a partir de da detecção de 0x55 enquanto não for 0xaa.
Só uma sugestão, é lógico. Há + inteligentes.

Com relação ao wireless, existem módulos rf pra isso. Ou pode usar i.r. que também existem prontos. Mas creio que criar 1 (i.r.) fique + em conta.

abrç

[lpagano]

lellis,

Será que se fizer o receptor reconhecer a transmissão via PWM daria certo? Aí o PIC faria o reconhecimento através da duração de cada pulso.

[ze]

pagano,

medir largura pwm tbém é 1 solução, mas vai ter que elaborar um protocolo qualquer pra a consistência dos dados. desconheço. mas veja 1 solução que propus pra alguém em outro forum (ou foi este? nem me lembro).

http://rapidshare.com/files/111325277/txrx.zip.html
(testei e num consigo acertar o cód no fdp do rapidshare!!!!!!!!!!!)

é Proteus. A linha tx seria seu sinal wireless. se vira pra transmiti-lo!! rs
a senha é facil

tenho 1 otro que tô procurando que tem um pic10f no tx e um pic628 no rx. se achar, bosto aqui...

abrç

[tcpipchip]

no caso de PWM, usa interrupt na borda de subida e descida no receptor...
em 1997 o ROGERCOM fez com PWM, um aluno meu usou em TCC com os RF "SHIN WONG" e funcionou.

[lpagano]

Pessoal,

Nesse feriadão vou fazer esse teste com PWM. Vamos ver no que vai dar.
Creio que usando esse recurso a segurança da transmissão ficaria "menos susceptível".

[EDSONCAN]

Se der errado o PWM existem dois caminhos:
- Manchester
- Usar a tecnica que uma é usado nos 6p20.

PWM pode ser influenciado pela distancia, caracteristicas do receptor, temperatura e por ai vai, por isso que o 6p20, por exemplo, faz divisão em 3 clocks - 2 em 1 e 1 em 0 => 0 e 1 em 1 e 2 em 1=> 0, um longo 0 estabelece o inicio do frame, isso força sempre a haver transição de sinal e faz com que vc não dependa do sinal de clock e sim da proporção.

Manchester é usado em pager, mas acho muito complexo para sua aplicação.
Edson
www.moky.com.br

[phophollety]

Use largura de pulso, como o 6p20 que funciona muito bem, aliás, faça um clone do 6p20, ele envia antes o preamble, perfeito para sincronizar com o receptor, interessante dele é que em três ciclos de clock ele envia 1 bit, ou seja se passar dois clocks em 1 e um clock em 0 ele envio um 0, se passar 1 clock em 1 e dois clocks em 0 ele enviou um 1, basta você medir o tempo que ele passa em 1, se for de tanto a tantos ms, é um 0 e se for de tanto a tanto é um 0 (vide carta de tempo do datasheet), funciona muito bem

[kleder]

No ano passado eu estive "ralando" com trasnmissão wireless e posso te passar algumas considerações. No meu caso eu estava usando um módulo pronto da keymark (RXD1 e TXC1) que operam em 434MHz.
Pelo que voce escreveu, está pensando em usar a porta UART do Pic? Se sim, então estará fazendo exatamente o que eu fiz. O maior problema deste módulo é que o receptor fica recebendo ruído digital enquanto não se está transmitindo, e por incrível que pareça seu receptor vai receber um monte de bytes e "pensar" que está correto mesmo com o tx desligado. Então voce precisa de um protocolo de verificação razoável para evitar este efeito.
Eu tentei algumas alternativas como por exemplo:
- modular os bits da sua informação em duas dut cycles diferentes, por exemplo: quando vc quer transmitir 1 (high level), vc envia ao tx uma frequencia de 2KHz com largura de pulso de 80% ativo, e quando quer transmitir 0 (low level) envia ao tx 2KHz com 20% ativo. No receptor voce usa um filtro passa-baixos para recuperar o sinal. O inconveniente é que vc só consegue transmitir a baixas taxas de transmissão. Este funcionou bem, se quizer te passo o esquema que eu fiz por e-mail.
- Outra que eu tambem fiz e funcionou, foi ficar transmitindo sempre. Transmita um código qualquer apenas para o receptor não receber ruido. É importante voce manter um delay entre os bytes transmitidos (algo em torno de 1/2 do tempo total do byte, por exemplo, se estiver a usar 1200bps vc vai levar aproximadamente 8,4ms para enviar o byte, então vc aguarda 4ms antes de enviar novo byte) isso serve para ajudar a sincronizar o tx com o rx.
Em ambos os casos, este receptor é muito suceptivel a ruídos externos, por exemplo de telefones sem fio, celulares, controle de alarme, etc.
Isso é muito prejudicial dependendo da aplicação, então avalie o seu projeto e veja se estes módulos atendem suas expectativas, caso contrário eu sugiro que voce use os módulos de 2.4Ghz da nordic NRF2401, estes são infinitamente melhores e mais seguros.

Espero ter ajudado

[phophollety]

Quando fizemos não usamos a uart, mesmo por que o 16f636 nem tinha isso, a brincadeira era mesmo ficar tentando ler toda a hora que era pedido e sempre sincronizar pelo começo do frame, só

[fabim]

pessoal eu ja vi varios post´s sobre esses modulos e tals..

Não seria muitissimo interessante usar um 12F629 com buffer de uns 64 bytes e transmissão via PCM=PWM..

Tipo um parzinho com 64 bytes de buffer, o que vai estar no receptor ao receber dados válidos sobe um pino pra 1, pra falar pro cabeção.
Aí mano seguinte to com X bytes aqui, vai querer ou quer que eu apague?

o que vai ser o TX, voce informa pra ele sogando 1 em um pino qualquer, aí escravo da po%$# segura 64 bytes aí, no final do envio dos 64 bytes ele fala pro mestre com nivel 1, sinhozim ja foi tudo, algo mais ?

PIC12F629 R$2,48.

fabim

[phophollety]

pessoal eu ja vi varios post´s sobre esses modulos e tals..

Não seria muitissimo interessante usar um 12F629 com buffer de uns 64 bytes e transmissão via PCM=PWM..

Tipo um parzinho com 64 bytes de buffer, o que vai estar no receptor ao receber dados válidos sobe um pino pra 1, pra falar pro cabeção.
Aí mano seguinte to com X bytes aqui, vai querer ou quer que eu apague?

o que vai ser o TX, voce informa pra ele sogando 1 em um pino qualquer, aí escravo da po%$# segura 64 bytes aí, no final do envio dos 64 bytes ele fala pro mestre com nivel 1, sinhozim ja foi tudo, algo mais ?

PIC12F629 R$2,48.

fabim

Fabim e a paixão dele por pic12 auhuhahauhau nem eu gosto tanto assim auhau

Mas sim, é uam boa opção mas, pegar um código holtek é mais simples, até já foi postado aqui uma vez

[fabim]

tudo bem intão.

PEgue no lugar no 12F629, um 18F4455 40 pinos a R$28,00. acho que é melhor mesmo.



Fabim

[HC908]

18F45J10 $1.90 - 40 Pinos 32Kb de memoria flash

[phophollety]

tudo bem intão.

PEgue no lugar no 12F629, um 18F4455 40 pinos a R$28,00. acho que é melhor mesmo.



Fabim

uiiii nervosooo

é uma boa opçào mesmo, só tirando o sarro eheh