[DUVIDA] Transmissão de dados digitais sem fio, qual a melhor forma ?

Olá Galera,

   Bom, não é bem uma Duvida, é mais um pedido de opinião de vocês.

   É um estudo de caso.

   A situação é a seguinte:  Um amigo me levou em uma empresa(do tio dele), com um parque com um determinado nível de controle,  mas tudo bem surrado, desgastado e antigo.

   Nesse parque basicamente a automação se dá por conta do monitoramento de RPM de motores e Pulso/Strokes de pistões.

   Ou seja, em linguagem técnica, tudo captação de pulso digital 0 e 1.

    Tudo é captado por sensores indutivos..

Resultado de imagem para sensores indutivos

      ...e transmitidos por cabo, até um sistema aquisitivo que converte os pulsos em valores e os joga dentro do sistema para ser trabalhado.

        O PROBLEMA:  O problema é que:

1- Ele esta querendo passar a transmissão dos dados dos sensores para sem fio, visto que a estrutura de tubulação dele tá velha e entupida, e pra sair quebrando tudo vai sair uma fabula.

2- Ele não deseja mudar as pontas, ou seja, deseja manter os mesmos tipos de sensores indutivos pra captar os dados, e deseja manter a mesma placa conversora ligada ao sistema já existente.

     Ai veio o problema,  QUAL A MELHOR FORMA DE TRANSMITIR TANTOS DADOS DIGITAIS ?

     Vou explicar: A solução inicialmente pensada por ele, era que cada vez que um motor estivesse em um 1 ou 0,  essa informação fosse captada pelo microcontrolador mandada por radio, do outro lado passada a placa aquisitora.

     Bem, se você colocar um, dois, três ou algo assim, pendurado em um radio de 2.4ghz a uma determinada distancia,  transmitindo pulsos de RPM, ele até vai fazer,  mas com certeza vai rolar algumas perdas.

     Mas pra piorar, não são só 3 ou 4, são varios, dai uma sobrecarga de dados transitando.

     O QUE PENSEI:

         Pensei em colocar um microcontrolador na ponta captando o dado do sensor indutivo, e lendo o tempo de intervalo entre cada pulso.

         Dai não seria transmitido pulso a pulso,  mas o valor médio dos intervalos entre eles.

         Do outro lado, um segundo microcontrolador ligado a placa aquisitora, simularia o sinal, gerando pulsos com os intervalos determinados, visto que a aquisitora não aceitaria o dado trabalhado, apenas os pulsos.

         Bem,  a ideia acima pra RPM até serviria, pois na maioria das vezes um motor industrial tende a mudar pouco o RPM,  mas para os Strokes dos pistões não é bem assim,  eles tendem a mudar, pois são usados pra compactar coisas, como o ar por exemplo, dai a resistencia do material trabalhado inteferiria nos pulsos.

      Nesse caso pensei num sistema Misto,  ou seja, ele tambem pegaria o tempo dos intervalos,  mas se houver intervalos longos, ou muitas oscilações, ele passaria a emitir os 0 e 1 reais.

    BEM,  qual sua opinião sobre transmitir dados digitias que precisam ser reconvertidos em pulsos do outro lado?

Exibições: 1193

Responder esta

Respostas a este tópico

Weider,

Olha amigo, eu não tenho muito para agregar ao seu projeto, porque a avaliação se torna mais palpite do que algo objetivo.

Os sensores indutivos são muito confiáveis e muito usados na industria por sua confiabilidade, mas sempre que se respeitem as condições de operação e a distancia do cabo que geralmente não passa de 3 metros.

Como estes sensores operam com uma tensão relativamente alta, entre 10V e 30V eles tem uma alta imunidade a ruídos, agora fazer tudo isso via radio... Eu não sei se seria viável, e se esta pessoa fizer uma nova instalação aparente em vez de embutida, hoje isso é muito usado, eletrocalhas por exemplo.

Agora do meu ponto de vista, se fosse o caso eu faria tudo usando uma topologia I2C, mas isso significaria uma mudança radical, porque deveriam ser usados outros sensores etc. um bus de dados de quatro fios praticamente, sei lá, será porque estou fazendo um projeto com esta topologia que estou influenciado rsrsrs.

Boa sorte, e aguarde os colegas opinarem, sempre tiramos boas conclusões aqui não é?

Veja com que estou brincando.

Grande abraço!

CK

CK,

   Muito obrigado pela colaboração, toda ideia é bem vinda.

   Bem, não sei se você leu, mas o protocolo I2C foi planejado pela phillips para comunicação entre perifericos proximos, dai pelo que pesquisei, a maxima distancia dele vai de 1 a 2m estourando.

   Logo, I2C é mais recomendado pra interligar coisa proximas, eu o usei pra fazer uma placa arduino de triplo núcleo, ou seja, 3 atmegas328 em uma só placa, visto que precisava de processamentos individuais de dados, logo dois processavam e mandavam pra um terceiro que fazia coisas como exibição em uma TFT e atuação.

    Bem, a comunicação de instrumentação por cabo é valida, estabelecida e robusta.  Mas ela gera enormes transtornos de logistica, dai a cada dia que passa a comunicação sem fio se torna mais robusta e eficiente.

    Como todo técnico sabe, não trabalhamos com a realidade, mas com uma representação eletro magnetica da realidade,   ou seja, quando você vê a imagem do apresentador no jornal, você não esta vendo a pessoa,  mas a representação elétrica dele em seu equipamento,  da mesma forma quando escutamos uma musica, não ouvirmos a voz do cantor,  mas pulsos eletricos transmitidos de forma codificada na ponta de captação, e decodificada na ponta de saida.

    Ai que tá,  quando falamos de Instrumentação eletrônica WIRELESS de dados analogicos,  a coisa é muito simples,  bastando a simples conversão do valor atraves de ADC e transmissão de uma variável simples, em pulsos regulares que indiquem apenas as mudanças ou manutenção.

    Já no cado da transmissão de pulsos digitais a coisa é mais complicada, e é esse o objetivo desse topico,  pois você pode transmitir pulso a pulso cada HIGH ou LOW digital,  ou pode criar algum metodo de captação, identificação do padrão e ai sim, o envio do padrão e não dos pulsos em si.

    A questão é que se trata de uma área bem nova, e eu tô justamente querendo trocar ideia pra ver se alguem já se meteu com isso, e o que acha melhor e mais confiável.

  

Oi Weider,

Já penssou em soluções prontas, veja este link, quem sabe abre alguma porta.

AQUI

Abs.

CK

Não sei se é uma rede confiável, mas eu tentaria usar vários ESP8266. 

E montar várias estaçôes de monitoramento, cada uma com um ESP8266.

Grande Zé Gustavo,

   Entendo que você esteja estudando os ESP8266 e esteja empolgado com eles, afinal são grandes radios.

   Entretanto na pratica, o Menu de opções é bem variado, e como venho pregando em vários posts,  pessoalmente não vejo um radio ou componente superior a outro,  vejo apenas opções que se encaixam de acordo com cada projeto e necessidade.

   Existe uma infinidade de opções, e a cada dia, descubro algo novo,(ontem por exemplo descobri mais um, vou falar abaixo), com novas caracteristicas que podem atender a um determinado projeto de forma mais eficiente.

   De básico,  até agora tirei algumas lições:

1- Preço não quer dizer muita coisa nesse mundo,  por exemplo, um Xbee custa mais de R$ 300 enquanto os seus amigos os ESP8266 podem custar menos de R$ 20,00,  e os ESP8266 podem fazer coisas como dar acesso direto a um roteador que acessa a internet enquando um xbee não,    logo, volto ao mantra,  cada um é bom a depender do projeto,   mas o fator preço nem sempre é sinonimo de melhor ou mais potente.

2- Existem variadas faixas de frequencia ISM(Industrial Sientific and Medical) no Brasil e no mundo, mas a maioria dos radios que encontramos trabalha em 433Mhz ou 2.4Ghz,   as principais diferenças entre as duas são:

2.4GHZ-

Pros - Grande taxa de transferencia de dados,  maior facilidade de encontrar equipamentos

Contra -  Baixa capacidade de atravessar paredes e obstaculos,  baixa imunidade a inteferencias.

433MHZ-  

 Pros - Maior capacidade de penetração,  maior imunidade a ruidos e inferencias,

 Contras - menor quantidade de dados transitaveis,  menor velocidade de comunicação. 

Mas vamos agora aos "sabores" que possuo ou mantive contato:

ESP8266 -     Tecnologia:  WIFI ( IEE 802.11)    Faixa: 2.4Ghz

XBEE -   Tecnologia: Zigbee  ( IEE 802.15)        Faixa:  principal 2.4Ghz (existem modulos de 900Mhz)

NRF24L01 -  Tecnologia: ShockBurst                Faixa: 2.4Ghz

RFM69HW -  Tecnologia: ???                           Faixa: 315 ou 433 ou 868 ou 915MHz ajustable

Semtech SX1278 -  Tecnologia: Lora (lorawan)   Faixa:  433Mhz  ( ajustavel de 137 MHz to 525 MHz )

HC-12 - Tecnologia: ???-Serial Communication  Faixa: 433Mhz

Isso que eu me lembro, e não tô citando range, pois nos citados acima a coisa vai de 100m a 25km(lora).

   Mas a duvida aqui do post é:   Qual a melhor forma de emitir os pulsos de RPM e Strokes (sinais digitais) de diversos motores ao mesmo tempo por radio?

   A questão é:  Radios 433mhz são mais confiáveis, tem menor perca de pacotes, mas tem limitações no numero de dados transmitidos, logo, se você transmite pulso a pulso, se o RPM aumenta, e aumenta a transmissão, com certeza a velocidade de transmissão dele será afetada.

   Já nos 2.4Ghz. Eles aceitam grandes cargas de uma só vez,  mas grandes transitos de dados é outra historia, fora que eles tendem a ter percas maiores de pacotes.

    Bem, pra mim a solução até agora tá sendo emulação e não transmissão direta,   ou seja,  eu pego o padrão em uma ponta e emulo na outra.

O que vocês acham?

     
     
     
     
     

Sei lá, mas não confio em wireless/rf em ambiente industrial.

Olá Weider.

Então, eu aconselho você usar WiFi, em vista que o protocolo implementado pela rede garante a entrega de dados.

Com isso você pode usar um módulo consolidado WiFi para Arduino (Qualquer modelo que encontrar vai servir).

Dessa forma, você também consegue integrar com um sistema rodando em uma raspbery para um eventual processamento mais pesado e geração de relatórios, fora o acesso aos dados de onde estiver (Onde cabe aqui colocar um aplicativo também).

Se quiser ajuda no projeto, ficarei feliz em poder ajudar.

Meu email: joaopandolfi@gmail.com

Rodrigo,

    A ideia inicial é um piloto, um teste,  algo que funcione em paralelo com o sistema atual por questões de avaliação, segurança  e desempenho.

 

João carlos,

   Na verdade amigo, dentro das características de cada um, praticamente todos os radios garantem a entrega de pacotes, a questão aqui é que não estamos falando de um grande volume de dados, transitado um numero X de vezes por segundo, mas algo mais critico, vou dar um exemplo comparativo mais pratico.

   SITUAÇÃO 1- Um filme qualquer dentro dos padrões da industria mundial trabalha a 60FPS (frames por segundo) ou seja, se você fizer uma transmissão de um filme por sistema sem fio, tera que fazer transitar apenas 60 pacotes de dados em um segundo, o tamanho do pacote ira variar de acordo com a qualidade do filme,  mas serão apenas 60 transmissões dentro de um segundo, e isso falando em dados brutos,  visto que o mais comum, como protocolos como o WI FI suportam altas cargas, é você mandar em cada envio, mais de um pacote, ou mais de um quadro,  dai você reduziria drasticamente o numero de pacotes em um segundo,  tipo, se vocÊ consegue colocar 6 frames em um pacote,  você precisaria de apenas 10 transmissões por segundo.

   Logo,  alta capacidade de carga, mas numero limitado de pacotes por segundo.

   SITUAÇÃO 2- Agora imagine que você tenha um motor que gira a 10.000 RPM,  (rotações em 1 minuto) logo como um minuto tem 60 segundos,  teriamos 10.000 / 60 = 166,6 giros por segundo.

    Imagine agora você ira transmitir não grandes pacotes, mas apenas um BIT com 0 ou 1,  mas tem que transmitir 166 vezes em um segundo, ao inves dos apenas 10 vezes em um segundo,  imaginou?

    Agora imagine que você tem poucos,  apenas 10 motores,  dai teriamos 166 x 10 = 1.660 transmissões em um só segundo.

    Ou seja, o payload é pequeno, apenas 1 bit,  mas o trafego é monstruoso.

    Essa é a diferença da transmissão de um dado por WIFI para um determinado tipo de uso,  pra uma transmissão de dados de sensoriamento digital por pulso.

Entendi o ponto em questão.

Você está certo, em situações que a frequência de envio é a chave do problema protocolo WiFi não é uma boa escolha mesmo.

Neste caso, é melhor o envio por RF e implementar o próprio protocolo.

Não havia olhado por esta ótica, obrigado pela correção.

Weider, 

Ideias não tradicionais e meio loucas são aceitas aqui? rsrsr

E se colocar laser (pointer) e sensores LDRs. Ou Infra vermelho?

Se o lugar permitir uma linha acima do movimento das coisas, conseguiria comunicação bastante confiável , será que não?.

 

Pedrosão,

    Eu juro que não entendi bem onde entra o laser com ldr,  seria pra substituir os sensores indutivos e captar os RPM ou pra substituir os radios?

    Bem, seja pra um ou pra o outro, agradeço sua ideia, mas pra o problema em questão não serviria.

    Na verdade eu já usei esse metodo citado por você pra captação de RPM em um sistema que dava muito problema utilizando sensores indutivos,  pois era uma roda com polias que sempre acabava dando problemas nos sensores independente do lugar colocado,  dai soldamos um simples pedaço de metal na roda, e colocamos protegido em um lado o laser e do outro o ldr,  dai toda vez que o pino soldado passava ele contava +1,  lembro que o problema era que ele contava duas vezes por volta, mas isso foi facil de resolver com logica.

   Mas nesse caso em questão, o sensor não é o problema,  e sim a transmissão do dado.

    Se sua ideia é transmitir utilizando laser e ldr, não dá, é lerdo demais,  um radio operando a 2.4ghz é infinitamente mais eficiente que isso.

    O problema que estou mesmo é de ter que criar um protocolo,  visto que a emissão dos valores brutos esta se mostrando inviavel.

   Ando meio ocupado ultimamente, dai estou sem poder testar as opções que pensei, mas o que pensei foi o seguinte:

1- Transmitir os pulsos de 0 e 1 reais -   PRO:  Realismo    CONTRA: Altissima chance de perca de pacotes e resultados errados

2- Capturar o tempo usando a função PulseIn(PIN, HIGH)  transmitir o valor(so precisaria retransmitir quando houvesse alterações) e reproduzir do outro lado . -   PRO:  Baixissimo e facil trafego de dados  CONTRA: O pulseIN captura em microsegundos, o que leva o resultado a resultados altamente oscilantes.

3- Abre uma contagem de quantos pulsos acontece dentro de 1.000 millis ( 1 segundo), se não houver, aumentaria a captura pra 10...  e transmite o resultado pra ser reproduzido do outro lado -  PRO e CONTRAS: em sistemas que contem o numero de strokes(pistonadas) seria mais realistico, mas em sistemas de rpm daria muitos problemas

4- Capturar o tempo em HIGH e capturar o tempo em LOW cada vez que um mudar para o outro.  PRO- a)Facil transmissão, baixo pacote de dados b)poderia usar tanto millis() como microns() mas com preferencia por millis()     CONTRA: a)Seria uma simulação, o resultado pode não ser tão perfeito do outro lado. b)quando houvessem intervalos grandes em qualquer posição, haveria problemas em transmitir tal dados

4- Mixto - Utilizaria uma logica usando o casamento de dois dos sistema, tipo,  se os pulsos forem muito rapidos, transmite no metodo 4,  já quando os pulsos ficarem lentos vai pra o metodo 1  -   Esse pela lógica foi o que mais gostei,  mas tem que testar.

foi mal, não deixei claro, inconscientemente   pela falta de conhecimento profundo no tema.

O que eu pensei foi para comunicar mesmo. duas coisas me vieram a cabeça. Cominicação Fibra optica, só que sem a  fibra, considerando transmitir os dados coletados pelos sensores e enviados do pointer até o LDR piscando em linha reta. mas como falei antes, não tenho ideia na taxa de transmissão.  

Outra coisa que lembrei é o conceito "LI-FI" que são lampadas leds piscando absurdamente rápidas e transmitindo muitos dados para computadores. 

se isso funciona ou se é viável, acho que não, mas gosto de participar com ideias esquisitas. vai que alguma é util para alguem,,,

abraço e obrigado por compartilhar suas completas respostas.

RSS

© 2024   Criado por Marcelo Rodrigues.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço