envio de dados por rádio freqüência

[carlos_bugs]

Olá amigos do fórum. Estou usando um módulo de rádio freqüência da WENSHING Electronics para envio de dados para um microcontrolador pic. Estou usando a comunicação serial USART para leitura de dados recebidos por rádio freqüência. Mas estou com o seguinte problema: quando o transmissor não está enviando dados, ou seja, a linha de transmissão está em nível alto, o receptor (RX), recebe dados aleatórios, como se fosse ruído mesmo. Como estou usando comunicação assíncrona, muitas vezes o pic acaba se perdendo, gerando erros na recepção de dados.

Gostaria de saber, se alguém já mexeu com esses módulos de rádio frequencia, e se já implementaram a leitura pela própria usart. A propósito: há um CIs que são usados muito em alarmes de carro, que convertem os dados recebidos seriais em paralelo. Será que teria alguma vantagem em utilizá-los?

Se alguém puder acrescentar alguma sugestão ou informação, será de grande valia para mim.

desde já agradeço a atencãp de todos, carlos augusto bugs

[zielpunkt]

Olá, Carlos.

Seguinte, esses módulos trabalham numa configuração chamada de "super-regenerativo" e o ruido na ausencia de modulação é típico dessa configuração. Alguns fabricantes (Telecontrolli, por ex) produzem receptores do tipo "super-heterodinos", que é melhor resolvido tecnicamente e possuem um circuito chamado de "squelch" que minimiza esse problema.

Uma alternativa seria a de vc enviar um pulso de duração fixa "x" antes de iniciar a transferencia de dados, o que fará o seu firmware descartar os pequenos impulsos (ruidos) que saem do receptor. De qualquer forma, e por causa dos ruidos, o seu micro vai estar sempre ocupado lendo o RX da usart e sempre vc terá que comparar o que está chegando.

Quanto aos ci's que falou, eles seriam"decoder's" dedicados, como o HT12D da Holtek e tais? Se for isso, eles são eficientes nessa etapa de recepção e, salvo engano, disponibilizam alguns bits paralelos (4) a partir do que recebem. O problema é que, nativamente, eles falam apenas com os "encoder's" específicos deles (no caso do Holtek, HT12E). Ai, para usar como vc quer me parece que a coisa pega um pouco. Aconselho verificar o datasheet dele para confirmar essa informação. É isso.

Abço.

[fabim]

dependendo do caso.
Tipo se vc estiver usando encoder´s HCS ou HT6P20B.
Você pode usar na saida do receptor um pic10FXX, e usar o protocolo do HCS e do 6P20 para recepção e enviar os dados para o pic mestre através de serial.
Tipo.
O 10FXXX vai ficar observando a saida do receptor, e só ira enviar dados em formato serial para o PIC se os dados que chegaram no receptor forem validos.

Abraços

Fabim

[zielpunkt]

Em partes...

Ele não está usando um encoder e, portanto, se é para usar um 10F da vida dedicado na saida do receptor, ele nem precisaria do tal encoder. O 10F se encarregaria de discriminar o que é ruido e o que é dado válido, antes de passar para o micro principal do sistema, que iria ficar totalmente liberado.

Agora, se originalmente o micro só fica enxergando a saída do receptor, eu ainda acho que a discriminação de ruidos por meio de um pulso inicial de duração conhecida (exagerando, 500ms em "0", por ex), antes da transmissão, mata o problema. Recebeu o dado? Repete a leitura e compara com a anterior pra confirmar (os ci´s dedicados fazem isso). Mas para aplicar o tal pulso inicial também vai depender do volume de dados que ele está transmitindo, porque isso pode gerar atrasos inaceitáveis no sistema...

Aliás, palpites a parte, essa de comparar 2 ou 3 vezes o dado recebido pode ser uma boa solução nesse caso de ruido.

É isso.

[carlos_bugs]

Seus comentários foram muito pertinentes, mas ainda tenho algumas dúvidas.

Quanto ao pulso para iniciar transmissão, achei uma boa idéia e por sinal melhorou bastante a recepção do meu sinal, porém estou tendo problemas com a usart interna do pic o qual programo com o compilador C da CCS. Sendo uma comunicação assíncrona, ela necessita de um start e um stop bit. quando estou transmitindo dados, tudo bem e o sincronismo é perfeito, já quando não estou, aqueles ruídos que chegam no receptor, as vezes fazem a usart se perder, talvez por nao ter recebido um stop bit ou um overflow do buffer de recepção. Com isso o pic para de receber dados. Já tentei manipular as flags responsáveis por erros na comunicação, porém sem sucesso. Se alguém usa o compilador CCS com a usart e saiba como me ajudar, desde já agradeço

[fabim]

bom vou tentar ser bem simples.

Suponha que vc vai enviar 32 bits.. 4 bytes.

O HT6P20B funfa assim..
T=400uS
1Bit = 3T = 1.2mS

Bits entendidos como zero.
Start bit = 400uS
1T em baixo e 2T em alto.

Bits entendidos como hum.
Start bit =400uS
2T em baixo e 1T em alto.

Vou mandar um byte no padrão HT6P20.

Código: Selecionar todos

   T   T   T  T   T  T  T   T   T  T
 |´´|__|´´´´|____|´´|__|´´´´|................................
 ST | Bit0     | Bit1     | Bit2      |
nivel    0           1           0        ....................................


Observe que no protocolo foram usados 10T.
Sendo 1 T para start e mais 9T/3=3Bits

Você pode por exemplo fazer uma procedure ou function que entre com 1,2,4,8,16,..... bytes.. Ele vai rotacionando pra direita ou pra esquerda conforme sua necessidade MSB e LSB..
Pro protocolo na parte de recepção funcionar sertinho fica assim.

Chegou um pulso... esta em 1 ?? sim..
Dispara contador que quando chegar a 420uS ele sai da interrupt pois é outro codigo ou ruido....

Mais vamos la..

o pulso passou de 1 pra zero.. quanto tempo deu ?
Deu 280uS..
Intão não é meu codigo pois eu aceito que é se o start permanecer apenas entre 380 e 420uS..

Espero ter ajudado,,,

Fabim

[carlos_bugs]

caro fabim.. você ajudou sim... mas estou querendo mesmo é implementar essa rotina de leitura sem utilizar um CI que me decodifique de serial para paralelo. quero apenas utilizar a entrada serial do pic. porém, como havia falado, algumas vezes o pic acaba se perdendo, desabilitando a usart. só sendo reabilitada com o resset do microcontrolador. isso se dá pela falta de sincronismo quando não estou mandando dados. a pergunta eh a seguinte: como faço para detectar erros na recepção usart e consequentemente evitar que a mesma seja desabilitada. Deixando claro que estou usando o compilador CCS.

abracos, carlos augusto bugs

[fabim]

um ponto fundamental..

C vc quer especificamente usar a serial para transmitir e ler usando modulos de RF, xing ling...

ESQUECEEEEE.. DESISTA... PARTE PRA OUTRA....

Vc vai fazer funcionar dentro de sua sala a 10 metros de distância. Quando chegar na rua, for usado em uma industria, em um garagem de shoping,rsrsrs..

Crie um protocolo de comunicação conforme eu dei a dica...

No receptor, coloque a rotina no ponto de interrução, e use o pino RB0 interrupção por mudança de estado, configurado pra borda de subida..
Quando chegar pulso ele vai dar uma olhadinha no start, não é o que ele quer REFTIE......

Abraços

Fabim

[zielpunkt]

Carlos,

Experimente adicionar no RX um pino INT_EXT trabalhando por interrupção na borda de descida, detectando e discriminando aquele 'pulso' inicial de start de transmissão que falamos. Se a RTI detectar que ele está presente, só então vc inicializa e habilita o canal de recepção. Ai vc isola os ruidos da USART. Isso deve matar o problema. Mas posta ai o resultado, se vc implementar isso, ok.

Abço.

[MOR_AL]

Olá a todos!

Somente para acrescentar mais alguma informação além das boas dicas já apresentadas.

Parece também que o seu problema é a relação sinal/ruído.

1 - Seu receptor pode estar captando sinais com baixa amplitude. Tão baixa que capta até ruído. Isso é equivalente a colocar a frequência de recepção em uma região que não há transmissão ou por falta de sinal transmitido ou por sintonia fora da faixa de transmissão. "Entra lixo sai lixo". Receptores mais elaborados possuem um controle automático de ganho (CAG). Quando o sinal de RF estiver presente, o ganho do receptor fica ajustado para um valor otimizado, amplifica o sinal de RF com um ganho próximo a um valor que forneça seu sinal de baixa frequência em um nível apropriado para sensiblilzar o estágio seguinte. Isso inclusive prevê (e tenta corrigir) a condição do fator "distância entre transmissor e receptores".
2 - Seu receptor pode estar com uma faixa de recepção (bem) maior que a necessária. Aí, sinais ou ruídos fora da sua faixa desejada podem causar estes ruídos e perturbar o funcionamento correto no seu PIC. Aqui uma melhoria seria melhorar a curva de sintonia do receptor (seletividade). Isso é normalmente conseguido com filtros ativos sintonizados na frequência desejada. Eles podem ser simples ou complexos, vai depender da sua necessidade.

Sugestão:

Depende da sua aplicação: Se for para um brinquedo de criança, seu circuito já está bom. Se for para controlar um bisturí à distância, nunca será o suficiente.

a - Implemente o padrão com a transmissão durante um período antes do seu sinal, como na sujestão do zielpunkt.

b - Implemente o código do fabim.

c - Crie mais redundâncias. Repita o código transmitido e verifique na recepção se eles aparecem corretamente.

c - Veja se é possível transmitir a RF durante todo o tempo. Ajustando o ganho do seu receptor para este nível de RF. Seu receptor ficará menos sensível a ruídos.

Até aqui não haverão gastos extras no projeto, porém não se sabe se serão medidas suficientes.

d - Tente medir a relação sinal ruído. Se estiver baixa, ou aumente a potência do seu transmissor, ou melhore a seletividade do seu receptor com estágios sintonizados.

e - Se seu problema ainda não foi reduzido para níveis aceitáveis, veja se dá para reduzir a taxa de transmissão. Com isso a banda de seu sinal fica reduzida e você pode melhorar a seletividade do receptor.

f - Tente verificar a densidade do espectro de RF, existente na região onde ficam os receptores. Veja se há regiões (na faixa de RF) em que a densidade seja menor. Você pode colocar sua frequência nesta região.

g - Se o espectro de RF na região é "sujo", talvez seja necessário mudar de tipo de comunicação. Pense em canal de comunicação ótico (infra vermelho por exemplo). A comunicação via fibras óticas é ótima para evitar interferências devido a RF. Pense em canal de comunicação acústico (ultrasom na região de 20kHz a 40KHz).

Estou sendo genérico porque não sei quais são as suas necessidades e sob quais circunstâncias elas se apresentam.

Espero ter contribuído para ampliar seus horizontes.

MOR_AL

[carlos_bugs]

Nossa, valeu mesmo pelas dias. Caro MOR_AL, com certeza você ampliou sim minha linha de visão sobre o assunto.

Zielpunkt e Fabim, acho que vou tentar sim implementar a transmissão e recepção do sinal usando aqueles módulos padrão: encoder e decoder. Como sugerido, andei olhando os da holtek e me parecem bem simples de operá-los além do preço acessível.

Acho que minha banda de recepção está sim muita larga e como o receptor é apenas um módulo prontoe barato, provavelmente ele não apresenta controle automático de ganho. A minha aplicação é bem simples, tendo o receptor apenas que receber, alguns bytes. Porém como o equipamento deverá operar na rua e não dentro dum laboratório, a confiabilidade é algo imprescindível.

O transmissor mandará um informações para uma estação de comando que estará dentro do ônibus, indicando para o mesmo qual lado das portas poderá ser aberto, bem como a velocidade máxima naquele ponto entre outros parâmetros.

Obrigado pela ajuda de todos e vou continuar fazendo os meus testes.

abraços, Carlos