arduino, eletrônica, robotica...
[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..
...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?
Respostas a este tópico
-
Permalink Responder até Carlos kwiek em
-
Oi Pedro,
As ideia não esquisita do meu ponto de vista, tudo é valido tratando-se de opiniar, veja tudo o que este pessoal fabrica AQUI, quem sabe não é uma solução pronta.
Abs.
CK
-
Permalink Responder até Weider Duarte em
-
Pedrosão,
Nós só temos a ganhar com suas ideias "fora do padrão" isso é maravilhoso, continue assim.
Eu tambem tinha mania de criar bastante coisas fora do padrão, até que percebi que não precisava reinventar a roda, se alguem já o tivesse feito.
Nesse caso, existem radiocomunicadores dos mais variados tipos, todos sem exceção vão ter pros e contras como qualquer método.
Tenho lido e estudando sobre instrumentação eletrônica sem fio, inclusive existe um livro famoso de um brasileiro ( VEJA O LIVRO AQUI ) , eu o tenho e já o li assim como diversos outros.
A questão é que todo mundo usa pra isso os radios XBEE que um unico radio desses sai por mais de R$ 300,00 e depois que você começa a mexer com eles e outros vê que ele não esta tão distante assim de radios que custam menos de R$ 50,00.
Uma coisa que descobri é que as vezes a coisa é cara, pra quem não quer pensar, pra quem quer pegar pronto, dai você paga o preço, mas quando você faz como estou fazendo, questionando, fuçando, estudando, você vê outras possibilidades.
-
Permalink Responder até Akira Sato em
-
Se voce ler o que usam na industria nao eh uma boa?
http://w3.siemens.com/mcms/sensor-systems/en/process-instrumentatio...
http://w3.siemens.com/mcms/sensor-systems/en/process-instrumentatio...
Talvez em algum estudo de caso tenha algo que lhe ajude a ter mais ideias.
Se fosse eu usaria algo pronto de um fabricante grande.
Se fosse para uso pessoal eu tentaria fazer o meu.Estou montado uma maquina para testar vazamento em cabecote de motor diesel, no final acabei optando pelo sensor da Keyence, certeza que funciona, qualquer um alem de mim consegue ajustar, poderia ler e tentar fazer com um sensor feito por mim, mas perderia muito tempo estudando.
-
Permalink Responder até rodrigo em
-
Já transmiti áudio estéreo com 2 laser pointers, ficou muito bom, o problema é a "contaminação" (sujeira na ponta do laser pointer ou no ldr). Também poderia ser utilizado photo transistores para serem mais rápidos.
-
-
Akira e rodrigo,
Obrigado mesmo por responderem e dar suas opiniões, valeu mesmo.
Akira,
Observe bem, o que estou propondo uma discussão é sobre princípios de transmissão de dados em altíssimas frequências.
Veja bem, o tipo de rádio, o protocolo, etc. apesar de ter sido colocado em debate por alguns amigos, Não é o nosso foco aqui.
O que temos até o momento é que transmissão de dados analogicos, é algo relativamente simples, visto que você tem em uma ponta um ADC e na outra um DAC e como analogicos variam pouco dentro de um mesmo segundo, a transmissão é tranquila.
Já dentro da transmissão digital, encontramos dois tipos de problemática de transmissão, a transmissão de altas cargas, e a de altas frequências, mas isso é o problema seja pra transmissão tanto sem fio como por cabo.
Como respondido nesse mesmo post, a transmissão de altas cargas é algo que já foi resolvido por protocolos como o WI FI, onde se transmite imagens e sons por exemplo.
A questão aqui porem, é o debate sobre a transmissão em Altas frequências, onde você transmite UM UNICO BIT ( 0 ou 1) só que você tem que fazê-lo de forma muito rápida, pra acompanhar a realidade de um equipamento que o gera.
Tipo, um motor girando, e a cada volta ele gera um pulso, aqui são gerados dois dados o de 0 quando o sensor não é estimulado e o 1 quando é, dai a cada ciclo, tem que ser transmitido dois dados.
Seja por radio, seja por cabo, quando colocamos diversos motores gerando pulsos, se colocamos cada um com seu radio(2.4ghz) ou cabo, tudo bem, mas e se quisermos usar um unico BUS, um unico cabo ou um unico radio? imagine a carga sobre ele? e a perca de dados?
Dai a discussão aqui seria: Se você tem junto ao motor e ao sensor um microcontrolador que já pega e converte os pulsos em uma informação como 10.000 RPM, mas você precisa do outro lado, não a informação mas os pulsos, qual a melhor forma de transmitir e simular?
Deu pra entender?
-
Permalink Responder até Allisson Henrique em
-
Meu caro Weider lendo seu problema e as respostas lembrei que a algum tempo atras fiz um trabalho de faculdade onde eu tinha que fazer um controle de carga com PID utilizando arduino e o labview.
Para a carga eu precisava controlar a senoide em 60 Hz, e fiquei tentando enviar para o arduino o controle via porta serial e mesmo com a velocidade de 115000 o controle era muito atrasado.
Então para resolver este problema eu mudei o sistema, onde eu fazia todo o controle PID no computador e no arduino eu envia a simplesmente porcentagem em que eu queria o controle da potência e deu muito certo.
Com isso acho que sua ideia de emular a frequência na outra ponta funcionaria muito bem, você poderia enviar um pacote muito pequeno via wi-fi fazendo eles emularem a frequência do outro lado.
Outra ideia que pensei e talvez não seja o tema mas seria utilizar um dos cabos já passado para se criar uma rede RS485 entre dois microcontroladores trabalhando.
-
-
Alisson amigo,
Cara, não sei se eu estava me explicando mal pra a galera, mas foi um alento você entrando e me dando uma luz em cima de algo que já tentou, obrigado mesmo.
Eu já tinha ouvido falar do controle PID, mas não entendia bem do que se tratava, estudei isso nos tempos de escola, mas como não utilizava a muito tempo foi tudo pra o lixo mental.
Fico feliz que você já tenha tentado e tenha dado certo, porem, agora a minha duvida fica não na falta mas no excesso de opções.
Deixa explicar:
Como dito acima temos váriadas formas de trabalhar o dado:
1- Captação pelo comando pulse - OPINIÃO: como dito gera um serissimo problema pra emular do outro lado por trabalhar com micros as oscilações são enormes.
2- Criar uma variavel conter, que soma mais 1 a cada pulso alto, fecha valores a cada 1.000millisegundos ( 1 segundo) dentro de um laço while OPINIÃO: Exige a implementação de interrupções, coisa que ainda to aprendendo, visto que se for pelo simples if(digitalRead(x)==1) não tem precisão de leitura, usei um codigo pronto da net e melhorou o resultado, mas preciso aprender melhor sobre interrupções.
Esse metodo é o verdadeiro RPM só que aqui tá sendo RPS rotações por segundo,
3- Capturar na variavel1 o pulso quando chegado em 1, aguardar enquanto em pulso baixo, e quando entrar novamente em pulso alto colocar na variavel2 tirar dai a diferença entre pulsos, pra saber quanto tempo ele tá levando entre pulsos OPINIÃO: É um bom metodo permite uma bola emulação do outro lado, mas quando o tempo dos pulsos é muito grande, pode gerar problemas.
Bem, tem mais metodos mas não lembro agora.
O que percebo é que vai depender muito do que se deseja transmitir, tipo, numa industria que tem monitoramento de Strokes(pistonadas) e RPM (rotação) para cada um, um metodo é mais eficiente.
Tipo, quando se mede strokes, em geral os pistões estão empurrando ou compactando alto, e a cada pistonada uma quantidade desse algo é contado, dai pra esse sistema, acredito que o metodo que conta os pulsos em um segundo é bem eficiente, pois vai transmitir reais quantidades de pulsos é é isso que interessa.
Já pra emular RPM do outro lado, curiosamente parece ser mais eficiente pegar o tempo entre pulsos e emula-lo.
E ai qual sua opinião?
-
-
Sim,entendi.
Mas se vc entrar em contato com o departamento tecnico dessas empresas grande e conversar com o engenheiro ele nao fala qual a solucao que eles tem para o seu problema?Vc faria essa pesquisa em diversas empresas grandes e a partir dela usaria algo deles ou criaria a sua solucao se nada o satisfazer.
-
-
Akira,
Um produto da Siemens, é com certeza um produto de qualidade, robusto, testado, mas te deixa escravo das soluções deles e a ideia aqui é ir mais longe.
Dei uma lida no material deles, eles trabalham com radios 2.4Ghz como os Xbee e os Nrf24l01, e utilizam um protocolo privado(HART), da mesma forma que os dois radios citados(shockburst e 802.15)
Outro fator que percebi é que ao menos nas paginas disponiveis, eles disponibilizam soluções apenas pra sensoriamento de dados AD ou seja, provinda de fontes analógicas, como temperatura e pressão, coisa que é muuuuuuuuuito simples de monitorar e transmissão, devido a baixas taxas de variação, dentro dessa realidade eu consigo mandar um dado com 100% de confiabilidade pra até 1.000m e com mais algum tempo de estudo estarei sendo capaz de enviar pra mais de 20km, apesar que será apenas pra estudo.
Esse problema que estou apresentando aqui dificilmente uma empresa com a solidez da siemens se meteria pra dizer que tem solução, visto que estamos falando de transmissão de altíssima frequência de dados, algo na escala de Gigahertz, coisa que sai do ISM, e que pra se manter dentro das normas, só com emulação como citado pelo grande alisson henrique ai em cima.
Apesar de muito badalado, e na moda, nem tudo dentro do mundo da comunicação sem fio já foi desvendado, cabe aos malucos de plantão como nós desbravarmos.
-
Permalink Responder até Allisson Henrique em
-
Meu caro Weider no meu projeto eu utilizei a interrupção do arduino para detectar quando a tensão passava no ponto zero em 60Hz e funcionou perfeitamente.
Quanto ao lado do emulador eu recomento você fazer como eu fiz jogando valores em porcentagem para a saída PWM do arduino acionando um Foto Acoplador 4n35 que são bem rápidos e você não terá problemas de corrente reversa.
-
-
Alisson,
Eu tava pensando justamente no uso dos optoacopladores, por varias razões, mas a principal seria segurança mesmo.
Fiz uns testes de captura sem o uso de interrupções, o resultado é horrivel, quando parti pras interrupções, o resultado é concreto.
Quanto ao uso do PWM eu não acho o mais indicado pra o pretendido, pois desejo controle extremo.
Acho que depois de tanto "matutar" a melhor solução, é que cada caso é um caso.
Ou seja, se pra transmissão de sensores analogicos, é bastante o simples valor do conversor AD, pra sensores digitais, pelo que "matutei" até agora, o ideal é dividir em dois tipos, os quais chamarei aportuguesadamente de PULSOS e GIROS.
PULSOS - São equipamentos com pistão, onde cada pistonada gera a incrementação de um valor/volume fechado do produto trabalhado, logo, aqui o numero de pistonadas exatas é que é o importante.
MELHOR METODO - Nesse caso, eu acredito que o melhor metodo, é captar o numero de pistonadas não em 1 segundo(hertz) mas em algo como 5 ou 10 segundos , ou seja, contar quantas pistonadas é dada a cada 5 segundos, dai do outro lado tem que fazer a matematica inversa,
GIROS - Quando falamos de motores que giram em alta velocidade, o importante é representar bem o numero de giros por minuto RPM.
MELHOR METODO - Acho que a melhor forma de se reproduzir a rotação com perfeição, é captar o tempo entre um pulso ALTO e outro pulso ALTO, e tirar o tempo que leva entre eles pra se executar.
Lembrando que motores tendem a pouca variação, quando o assunto é RPM, se pegamos a diferença entre os pulsos e do outro reproduzimos igual, com certeza isso expressará o resultado com perfeição.
-
-
-
Perfeito, entendi seu ponto.
O meu ponto era no sentido de vc ter algo ja funcionando e executar o servico o mais rapido possivel e ganhar uma moral :)
Bem-vindo a
Laboratorio de Garagem (arduino, eletrônica, robotica, hacking)
© 2024 Criado por Marcelo Rodrigues.
Ativado por
