Este artigo faz parte da revista
Mecatrônica Jovem - Aeroespacial
Márcio José Soares:
- Página Web – http://www.arnerobotics.com.br
- Instagram - https://www.instagram.com/arnesake/
- YouTube - https://www.youtube.com/c/arnesake
- Thingiverse - https://www.thingiverse.com/arnesake/designs
Introdução
Que tal desenvolver um sistema que ajude a simular uma comunicação a longas distâncias como, por exemplo, as comunicações feitas entre a Marte e a Terra?!? É isso que veremos nesse artigo, como simular tal tipo de comunicação utilizando uma técnica “antiga” de envio de dados, porém aplicada a modernos microcontroladores de 32 bits.
Comunicação entre Marte e a Terra
Nossa simulação partirá da proposta para a solução de um problema: a comunicação entre a Terra e Marte e vice-versa. Para isso precisamos primeiro conceituar alguns pontos importantes.
Sabemos que a distância entre os dois planetas varia de acordo com a posição da órbita de cada um destes em relação ao Sol e também devido ao período de translação que é diferente para cada um. A terra tem um período de translação de 365 dias, enquanto Marte tem um período de 687 dias já que se encontra numa órbita mais exterior.
Com isso a distância entre Marte e a Terra pode variar de 54,6 à 401 milhões de quilômetros (1x106 Km), dependendo da posição das suas órbitas em relação ao Sol. Sendo assim, o tempo que um sinal de rádio leva para percorrer essas distâncias pode variar entre 5 a 20 minutos.
Pensando nisso o sistema de comunicação desenvolvido pela NASA foi feito em duas etapas:
1) Comunicação entre a Terra e o MRO (Orbitador de Reconhecimento de Marte) e vice-versa;
2) Comunicação entre o MRO e os dispositivos na superfície de Marte (Rovers e outros).
A figura 1 apresenta as etapas descritas. Para que essa comunicação possa ser realizada a NASA utiliza frequências diferentes tanto para transmissão como para recepção, conforme o quadro 1.
Quadro 1 – Frequências utilizadas na comunicação Marte – Terra
X-band (Comunicação primária usada durante lançamento, cruzeiro e órbita)
• Transmissão: 8.439 GHz (MRO – Orbitador de reconhecimento de Marte → Terra)
• Recepção: 7.183 GHz (MRO ← Terra)
• Largura de banda: 50MHz
Ka-Band (Kurts-above Band - Teste de comunicação experimental entre espaço e terra)
• Transmissão: 32 GHz (MRO → Terra)
• Largura de banda: 500 MHz
UHF (Transmissão de comandos e dados entre veículos e MRO)
• Transmissão: 435 a 450 MHz (→ orbitadores MRO)
• Recepção: 390 a 405 MHz (← orbitadores MRO)
• 16 canais tipo half-duplex
Note que para a transmissão de um novo programa da Terra para um Rover, por exemplo, é necessário que um “arquivo” seja enviado ao MRO utilizando a banda X-band (com um tempo estimado entre 5 a 20 minutos para a sua chegada). Somente então o MRO envia este arquivo ao Rover usando a frequência de UHF e então aguarda uma resposta do Rover. E em algum momento, uma resposta final precisa ser enviada à Terra sobre a recepção do arquivo e esta gastara o mesmo tempo de ida da mensagem inicial. Observe que não estamos tratando aqui do sucesso ou não da execução do novo programa. Tratamos apenas da sua transmissão/recepção. Percebe-se aqui o grau de dificuldade deste tipo de comunicação. Trata-se de um desafio gigantesco!
A escolha da simulação “perfeita”
Se você observou atentamente o quadro 1 vai perceber que não temos acesso aos transceptores utilizados (ou, pelo menos, a maioria deles), e nem mesmo as distâncias apresentadas.
Então, o que podemos fazer?!?
A) Uma comunicação do tipo serial RS232 entre dois microcontroladores com tempos iguais aos observados (5 a 20 minutos) para troca de dados/arquivos?!? Hum, creio que isso não seria interessante, já que por menor que fosse a taxa da velocidade escolhida a recepção dos dados se apresentaria simultânea à sua transmissão. E mesmo que fossem inseridos tempos entre cada byte, a compreensão do desafio proposto não seria alcançada. Além disso, na simulação não é permitido utilizar qualquer “protocolo” de verificação tipo byte a byte ou mesmo pacote a pacote, já que a transmissão é do tipo “half duplex”;
B) Uma comunicação que permita a troca dos dados/arquivos entre dois microcontroladores convertendo os bytes digitais em frequências audíveis?!? Isso garantiria uma taxa de comunicação muito baixa o que aumentaria bastante a latência e sem qualquer tipo de verificação. Um arquivo seria enviado utilizando “sons”. Acredito que essa opção oferece um desafio maior que a primeira e pode ajudar na compreensão das dificuldades enfrentadas na comunicação entre Marte e a Terra.
Entendendo a escolha
Durante toda a década de 1980 os pequenos microcomputadores disponíveis para alguns poucos sortudos, não possuíam os acessórios de armazenamento de dados que temos hoje como HD’s, SSD’s, SDCard’s, PenDrive’s, “nuvem”, etc. Naquela época utilizavam-se fitas K7, isso mesmo, aquelas pequenas fitas para gravação/reprodução de áudio como as demonstradas na figura 2.
Para armazenar “dados” em fitas de áudio os programadores da época criavam programas e/ou utilizavam os recursos presentes nas ROM’s dos seus pequenos computadores para transformar os bits dos dados em frequências de áudio. Dessa forma era possível “gravar” literalmente os bits/bytes em um formato de áudio suportado pelos antigos gravadores K7. E a lógica reversa também era possível, ou seja, os dados gravados numa fita K7 poderiam ser recuperados mais tarde pelo sistema (microcomputador). O que temos aqui nada mais é que a técnica conhecida como modulação/demodulação, presente nos modens modernos e também daquela época.
Muitos vão se lembrar dos primórdios da Internet, quando durante a conexão à rede, alguns “sons” eram emitidos pelos modens e que ficaram marcados na memória daqueles que vivenciaram o período. E claro, para aqueles que não estavam lá a Internet têm muitos vídeos da época que ajudarão a entender melhor o que estamos falando aqui.
Então se aceitarmos a ideia de que podemos transmitir dados usando frequências de áudio distintas assim como feito no passado, utilizando dois microcontroladores modernos, teremos um desafio mais interessante já que esse tipo de transmissão é cheia de desafios.
A formatação dos “dados”
A primeira coisa a se fazer é compreender que a partir de agora estamos trabalhando com “frequências de áudio” e precisamos aplicá-las ao que conhecemos como bits e bytes.
Para que os dados sejam formatados, precisamos primeiro diferenciar os níveis lógico dos bits. Isso é relativamente fácil no mundo digital. Bits com nível lógico “High” ou “1 lógico” é igual a VCC (5 V, 3,3 V, etc) e bits com nível lógico “Low” ou “0 lógico” é igual a 0 V ou GND.
Poderíamos então fixar duas frequências distintas uma para cada bit, mas isso não estaria de tudo correto. A percepção destes bits no formato de áudio seria prejudicado devido à velocidade da transmissão, e velocidade é o que desejamos manter baixa na nossa simulação. Além disso a interpretação dos dados também estaria sujeita a alguns problemas. Dessa forma o melhor a se fazer é a combinação de frequências que possam ser identificadas posteriormente como bit 0 e bit 1 e que tenham uma velocidade de transmissão/recepção adequada ao que desejamos simular.
Podemos então partir para o que está demonstrado na figura 3 onde vemos que cada bit faz uso das mesmas frequências, mas com quantidade de ciclos diferentes. Para o bit 0 temos 8 ciclos de 2kHz mais 2 ciclos de 1kHz. Já para o bit 1 temos 4 ciclos de 2kHz mais 4 ciclos de 1kHz.
Note que se somarmos os tempos envolvidos nos ciclos de cada bit encontraremos exatos 6ms para cada bit. Veja a seguir:
Para 2kHz temos:
T = 1/F => T = 1/2kHz => T = 500x10-6s ou 500us ou 0,5ms
E para 1kHz:
T = 1/F => T = 1/1kHz => T = 1x10-3s ou 1ms
Somando os tempos do bit 0:
Tbit0 = (8 x 0,5x10-3) + (2 x 1x10-3) = 6x10-3s ou 6ms
E para o bit 1
Tbit1 = (4 x 0,5x10-3) + (4 x 1x10-3) = 6x10-3s ou 6ms
Agora que temos pronto como será o formato de áudio de cada bit, precisamos criar um formato para o nosso byte. E porque não, nesse caso, apelar para uma norma que já existe a muito tempo?! Falo da RS-232C. Vamos utilizar o mesmo formato do byte RS232 para criar nosso byte em áudio, porém com tempos muito maiores. Veja a figura 4.
Note que o que temos é exatamente igual ao que determina a norma RS-232 para o envio de um byte, removendo o bit de paridade que aqui não será necessário. O tempo total de um byte tem então 60ms já que transmitiremos 10 bits. E se cada bit tem em torno de 6ms, podemos calcular a taxa de transmissão que será de:
Taxa(bps) = 1 / 6ms = 166,66 ou ≃ 170 bps (bits por segundo)
O que nos confere algo em torno de 16 bytes por segundo, se não inserirmos nenhum tempo entre os bits e também bytes (lembre-se que aqui qualquer delay é amigo da nossa simulação).
E por último, mas não menos importante é como será o nosso “protocolo” para envio/captura do arquivo. Sim estamos falando do envio de arquivos que podem ser interpretados como mensagens também.
Na figura 5 é descrito este formato. Temos um sincronismo de início composto por 4 segundos na frequência de 1kHz, seguidos de 4 bytes para o nome do arquivo, 2 bytes para endereço inicial, 2 bytes para endereço final (além de apontar para um endereço na memória, estes endereços fornecem o tamanho dos dados), 1 byte para o somatório ou checksum (apenas para nome, endereço inicial e endereço final), sincronismo de dados composto por 2 segundos na frequência de 2kHz, seguido dos “bytes de dados” (frequências já detalhadas) e finalizando com o sincronismo de finalização composto por 1 segundo na frequência de 2KHz.
Com isso finalizamos nosso singelo “protocolo” (pacote de dados), que será utilizado tanto na transmissão/recepção do nosso “arquivo”.
Os circuitos
As figuras 6 e 7 mostram os circuitos do transmissor e do receptor, respectivamente. Para o transmissor o autor optou por usar um microcontrolador de 32 bits ARM Cortex M4 STM32F429ZI aplicado a uma placa de avaliação NUCLEO-F429ZI. Já para o receptor a opção foi por um microcontrolador RISC-V CH32V003F4P6 aplicado a uma placa de avaliação CH32V003F4P6-R0-1v1. Porém os mesmos poderão ser substituídos por outros microcontroladores como o Arduino, ESP32 ou outro. Bastando apenas que o interessado adapte o circuito e os programas para os novos microcontroladores escolhidos.
Nos circuitos são apresentados pinos para uso da USART interna de cada microcontrolador. Estas servem para debug do que acontece em cada programa (envio e recepção), nada mais. Toda a comunicação é feita pelos pinos OUT no transmissor e IN no receptor.
Montagem
As figuras 8 e 9 mostram a montagem do autor para o transmissor e receptor, já evoluídos para utilizar comunicação com um par de rádios HT’s UHF (detalhes mais à frente). Para uma montagem mais simples, sem o uso dos rádios, basta seguir os diagramas apresentados nas figuras 6 e 7.
A montagem para as partes “extras” das placas pode ser feitas em protoboard (matriz de contatos) ou ainda de outro modo que cada um tenha disponível. O amplificador apresentado no circuito transmissor pode ser ligado tanto ao módulo transmissor como também ao módulo receptor. Dessa forma é possível ouvir saída ou entrada, mas nada impede que você monte essa parte duas vezes, uma para o transmissor e outra para o receptor. Lembre-se apenas de limitar o volume através de P1 para não tornar sua experiência incomoda.
No canal do YouTube do autor você poderá ver alguns vídeos demonstrando o funcionamento dos vários momentos desse projeto e também novos vídeos que serão atualizados no momento oportuno demonstrando outros usos para o mesmo. Não deixe de visitar e inscrever-se no canal!
Os programas
Para aquele que se interessar em aprender um pouco mais sobre como os dados são gerados/transmitidos e recebidos/convertidos (modulação/demodulação), o autor deixou em seu site disponível para download os programas do transmissor e do receptor, ambos desenvolvidos na Linguagem C.
Obs.: Os programas estarão em constante evolução! Visite o site regularmente!!!
Teste e uso
Para testar o sistema basta gravar os programas as suas respectivas plataformas e que um fio seja conectado da saída do transmissor até a entrada do receptor, além de um fio entre os GNDs das placas. O programa do transmissor já traz um conjunto de três pequenas mensagens para serem utilizadas como arquivos. Cada vez que o botão BTN1 na placa transmissora for pressionado uma mensagem será transmitida, começando sempre por 1 até 3 e depois retornando a primeira e assim sucessivamente. Nesse momento você poderá ouvir as varias frequências através do alto-falante conectado ao amplificador e, o que estiver sendo enviado pelo transmissor será demonstrado através da sua USART e o que o receptor estiver recebendo também será apresentado através da sua USART. Nesse momento você verá toda uma latência na recepção dos dados e poderá comprovar a eficiência dessa simulação.
Para ir além
Utilizando dois pequenos rádios HT’s (rádios portáteis para a frequência VHF/UHF) como os apresentados na figura 10 você poderá experimentar a transmissão entre pontos mais distantes. Você também poderá utilizar um par transmissor/receptor do tipo 315MHz ou ainda 433MHz que tenha suporte a transmissão analógica. Transceptores exclusivamente digitais não servem nessa simulação!
Para isso utilize os circuitos apresentados na figura 11. Eles servem para auxiliar na saída do sinal, permitindo filtrar melhor as frequências para o caso do transmissor e também melhorar o sinal desejado na entrada do receptor. Eventualmente alguns ajustes precisarão serem feitos tanto nos circuitos como também nos programas, dependendo da qualidade do rádio utilizado na experiência.
Atenção: Alguns rádios requerem uma licença de operação! O autor utilizou em suas experiências um par de rádios que não exigem nenhum tipo de licença para sua operação! Informe-se sobre as normas e leis regulamentares da rádio difusão caso opte por utilizar outro tipo de rádio!
O autor deste artigo continua “brincando e experimentando” os circuitos e você poderá acompanhar esse desenvolvimento continuo através do seu canal no YouTube. Increva-se!!!
Conclusão
A comunicação entre Marte e a Terra é um grande desafio e ela deverá ser muito confiável quando a exploração humana começar. Nosso desafio foi apresentar um modo de realizar uma comunicação que, apesar de local, fosse desafiadora. Utilizar uma técnica ou tecnologia “antiga” em algo “recente” não é algo inédito. Podemos considerar que a técnica demonstrada para modulação/demodulação, muito aplicada no passado, ainda pode ser considerada atual, já que ela reapareceu recentemente nos sistemas de conversação entre IA’s como o Gibberlink (sound-to-sound protocol). Portanto, muitas vezes o “The old is the new one!”. Bons projetos, montagens e até a próxima!
Para os professores:
- Ciências/física: poderá estimular os alunos a pesquisarem mais sobre eletricidade, magnetismo e rádio difusão;
- Matemática: poderá estimular os alunos na pesquisa sobre cálculos com potência de base 10;
- Língua Inglesa: poderá auxiliar os alunos na tradução de pesquisas em sites de língua inglesa sobre Gibberlink e demais protocolos sound-to-sound;
- História: poderá estimular a pesquisa sobre os primórdios da Internet e as tecnologias aplicadas na época;
- Língua Portuguesa: poderá estimular os alunos a escreverem uma redação sobre os desafios encarados na evolução da tecnologia e seus efeitos para a sociedade.
