Teste de Transmissão de um TX de 433MHz

MOR_AL · 29 de janeiro

Em 19/01/2025 às 18:29, MOR_AL disse:

Desta vez escrevi a "receita de bolo" para não ter que partir do zero.

O Windows 11 "queimou" a minha "receita de bolo".

O K150 não identificava a bendita porta 7.

Fiquei duas horas para poder fazer o K150 funcionar.

Finalmente gravei o firmware do receptor no PIC.

Meu PC contém um HD 1TB com e um SSD com 250GB com o W11.

Como o SSD é pequeno, incluí quase todos os programas não W11 no HD.

Nomeei a pasta que coloco esses outros arquivos de "___Programas_2024".

Será que isso está causando todos esses problemas?

Voltando ao projeto...

Próximo passo:

Gravar um vídeo, mostrando os pulsos do Preâmbulo, produzido pelo Tx. Quero ver se estes pulsos estão corretos.

MOR_AL

rmlazzari58 · 5 de fevereiro

Em 27/01/2025 às 07:53, .if disse:

pctools

Norton Utilities, rs...

Saudades... Talvez haja um editor hexa para arquivos executáveis que funcione em SOs atuais, será que não? Como a moçada de agora se vira sem essas utilidades?

MOR_AL · 5 de fevereiro

Projeto0 temporariamente parado. Aguardando uma forma de gravar um PIC.

MOR_AL

MOR_AL · 11 de fevereiro

Pessoal.

A instalação do VirtualBox no W11 tem apresentado problemas. Alguns foram devido a minha inexperiência e fáceis de se resolver. O último porém, não consegui resolver. Segue o link do tópico (ou clique na setinha superior à direita).

Perdi a batalha com o VirtualBox, mas não a guerra. Tenho boas notícias!!!

Em breve o projeto vai continuar.

Eu tinha diversos componentes do meu PC anterior, faltava apenas um monitor, cabos e um mouse.

Comprei o monitor usado de tamanho médio por um bom preço (100L).

Espero instalar o WXP nele e poder usar todos o hardwares e programas que não funcionam mais com o W11.

Além disso, prevejo poder usar novamente um K150 novo, pois vi um vídeo com maiores e novos detalhes de sua instalação.

Também estou pensando no PicKit 3, clone.

[]'s

MOR_AL

.if · 11 de fevereiro

Moris .. não visito aquelas bandas...

Me fez lembrar que certa feita atualizei o virtualbox e deu a maior zica nas minhas máquinas virtuais. Por sorte são pequenas - de 50 a 100GB - e mantenho cópias dos .vdi num HD externo 1TB.

O vbox que uso atualmente com sucesso no linux é o 7.0. Não ousei (nem precisei) atualizar pro seu 7.1.6. Se achar que deve, use o 7.0 ou anterior pra ver que merdadá. Lembrando que de w11 entendo paul newman... Falando nele, alguém viu Paulão @aphawk por aí? Saudadêle...

Moris.. editei kk

MOR_AL · 18 de fevereiro

Ontem chegou o meu programador K150. Como já mencionei, a alma do anterior foi entregue a Deus.

Hoje consegui, até que em menos de 30 minutos. fazer o K150 gravar o PIC12F675 no Windows 11.

Para testar se este procedimento deu certo, eu desinstalei o drive e o PL 23xx no Gerenciador de Dispositivos.

Repeti o procedimento e deu certo novamente.

Vou criar um tópico para mostrar como fiz. Mas acredito que o moderador transferirá o tópico para o de microprocessadores.

Continuo com os entendimentos para ter um PC com o WXP, ou o W7. Este vai permitir usar os programadores e os hardwares (placas de desenvolvimento).

Vamos continuar com o projeto....

MOR_AL

MOR_AL · 22 de fevereiro

Ontem, 21/02/2025, gravei o PIC12F675 com o código do transmissor. Tirei fotos do preâmbulo (49ms em '1' , um stopbit em '0', além dos bytes 0xF8, 0xF8 e 0xFA). Em seguida fotografei os primeiros bytes (de 0x00 a 0x0E), mostrando que os primeiros bytes, do loop desde 0x00 a 0xFF estão de acordo com o esperado.

Seguem s fotos:

Próximos passos:

1 - Documentar em um relatório.

2 - Partir para o Rx, que já está avançado.

MOR_AL

Sérgio Lembo · 23 de fevereiro

@MOR_AL

Parabéns, parte 1 (transmissão) resolvida.

Parte 2, a recepção da informação. Conseguiu vencer os obstáculos?

Estou acompanhando este tópico com muito interesse, sua discussão com a Isadora está me rendendo conhecimentos. Obrigado por compartilhar as pedras do caminho. Na teoria tudo é fácil, saber desviar ou conviver com as pedras é que separam os homens dos meninos.

MOR_AL · 23 de fevereiro

@Sérgio Lembo

Olá, Sérgio!

Ontem e hoje eu editei o arquivo do Word com o relatório das informações obtidas.

Deletar parte do que não funcionou, deixar a parte das informações sobre a transmissão e recepção via protocolo Manchester, apesar de ainda não usá-lo.

Atualizar os números das figuras, para permitir a leitura do relatório em sequência cronológica.

Neste meio tempo, troquei com meu amigo, o meu PC anterior, com o W10 e HD lento, pelo PC dele com o W7.

Estou fazendo ajustes no PC com W7, para incluir todos os programas que rodam a instalação dos programas (hardware e software), que usam a porta serial (tem uma) e a porta paralela. Tenho um hardware que inclui mais duas portas seriais. Só saberei se podem ser incluídas após abrir o PC.

Por mencionar a abertura do PC, terei que trocar algumas portas USB, que devem estar com mau contato.

Quanto ao receptor.

Já havia trabalhado um bom tempo com o fluxograma do receptor. Hehehe!! Terei que relembrar dos detalhes já incluídos, para poder avançar.

Esta semana, com o carnaval, minha esposa assumiu compromissos, que me incluem. Mas vamos avançando firmemente um passo por vez.

Em tempo:

Fiz uma gravação de um vídeo, mostrando o Tx funcionando. É um pisca led. O led fica aceso durante a transmissão do Preâmbulo e da transmissão dos bytes desde 0x00, até 0xFF, quando a transmissão termina, o led apaga por um segundo e o processo reinicia.

Olhando, só é visível o led piscar.

No futuro pretendo fazer um vídeo com todas as etapas (que funcionaram) deste projeto.

[]'s

MOR_AL

MOR_AL · 24 de fevereiro

Semana passada troquei o meu PC anterior, com o W10, com o PC do meu amigo, com W7.

O PC dele já tinha uma porta serial e uma paralela na placa-mãe.

Hoje incluí um slot com duas portas seriais e uma paralela.

Até o presente momento este PC possui três portas seriais e duas paralelas, verificadas no Gerenciador de dispositivos.

Ainda estou inserindo todos os meus programas com os meus kits, que precisam de porta serial e paralela.

Depois que eu inserir, vou testar para ver se as portas estão funcionando.

Aí ficarei independente do W11 para gravar PICS e Atmegas (apesar de já ter usado o W11 para gravar o PIC com o K150)..

MOR_AL

MOR_AL · 5 de março

Atualizando...

I - PC trocado com o meu amigo (dei um com W10 e recebi um com W7).

1 - Ao tentar colocar o WXP em uma partição, consegui não colocar e ainda perder o W7 instalado.

2 - Comprei um DVD com o WXP aqui no Brasil, mas com o carnaval, só devem começar a se mexer agora.

II - Tx/Rx...

1 - Com o Tx aparentemente funcionando (vide postagem #57), retomei o trabalho com o Rx.

2 - Realizei pequenas alterações no fluxograma.

3 - Incluí 7 pontos de identificação de erros. Os erros são exteriorizados nos três leds.

4 - Conferi todo o fluxograma mais de uma vez e não consegui encontrar/identificar disparidades.

5 - Passei as alterações para o arquivo asm no MPLAB.

6 - Gravei o PIC12F675 com o KIT K150 e o aplicativo Microbrn no W11. Confesso que nem precisei reinstalar novamente o drive do K150. Ao conectar o KIT (hardware), o Microbrn já identificou a porta serial.

7 - Coloquei o PIC12F675 no conector da placa do Rx. Instalei o Tx com bateria Ion-Lítio em uma caixinha "Altoids". Fiz o mesmo com o Rx. A potência transmitida mais que dobra, pois a caixa metálica cria um dipolo com a antena. O mesmo acontece com o Rx. O sinal captado também aumenta. Neste caso tanto devido ao aumento na transmissão, como na antena receptora.

8 - Liguei as bagaças (Tx e RX a 50cm de distância entre eles)!!!!

Observações:

1 - O led do Tx permanece aceso por cerca de 2,5s, enquanto transmite o preâmbulo e os 256 bytes. Depois ele apaga por 1s sem que haja transmissão. Depois o loop recomeça.

2 - Os três leds do receptor apagados estavam e apagados permaneceram. Será que o Rx está energizado? Resp.: Sim!!

Eu esqueci de colocar alguma informação de que a recepção estava funcionando. Antes de voltar ao fluxograma, para incluir este detalhe,,,

Comecei a me afastar com o Rx. Passei por uma parede, ... depois outra e mais um metro.

Os três leds acenderam. Código do erro 111 - Não foi identificado o Byte 0XFA do preâmbulo. O detalhe é que isso só deveria ocorrer, DEPOIS de ter sido identificado pelo menos um byte 0xF8. Mas continuando...

Fui retornando aquele metro que ocorreu o problema. Os três leds apagaram. Claro. Depois de 5s, o programa reinicia apagando os leds, mas não acusou mais erro, permanecendo apagado.

Fiz outro teste. Desliguei o transmissor.

Logo aparece o o código 001 - Não foi identificado o pulso em '1', com pelo menos 11ms da parte Pre1 do preâmbulo. Isso mesmo que deveria ocorrer.

Próximos passos:

1 - Vou tentar saber porque não foi identificado o byte 0xFA do preâmbulo, sem ter sido identificada a ausência de pelo menos um byte 0xF8.

2 - Vou tentar descobrir um meio de ajustar a bobina do Rx para uma maior sensibilidade. Como está, o receptor não permite este ajuste, pois ele está programado para receber os dados já pré-identificados. O ajuste introduziria ruídos não permitidos.

3 - Vou levar o Tx e o Rx a um local aberto, para identificar até que distância eles continuam funcionando.

Em tempo:

1 - Tem um vídeo no YouTube, onde o sujeito fez um teste parecido com este par TX/Rx. O link é o seguinte:

https://www.youtube.com/watch?v=b0lVBJEH3fk&list=PLKbXQpiLi1hU1z7Pnv4wMQCZEc7ptDefj&index=20&t=415s

a - O sujeito conseguiu transmitir a uma distância de 315m.

b - Bom. O teto metálico do carro, onde ele colocou o Tx certamente aumenta a potência transmitida, mas 315 metros é uma distância excepcional, muito difícil de se conseguir.

c - Pelo tempo observado para que o erro seja corrigido, ele não deve ter enviado todos os 256 bytes.

d - Se ele conseguiu esta façanha, alimentando o transmissor com uma bateria de Li-ion (4V), eu tenho que tirar o meu chapéu.

e - Ele usou Arduíno, tanto no Tx, como no Rx. O micro do Arduino tem USART. Eu estou programando em Assembly e os PICs 12F675 não possuem USART. Acho que devo estar levando mais de 10 vezes o tempo que ele levou para fazer o teste.

Para os próximos projetos, estarei migrando para a linguagem C, apesar de saber usar o BASIC há mais de 45 anos.

MOR_AL

MOR_AL · 6 de março

Mais Novidades...

Ficou a dúvida. Saber se o receptor está funcionando ou não.

1 - Incluí um código para ser aceso nos três leds por 5s. Código 111. Três leds acesos. Conseguiu ler o preâmbulo (49ms em '1' e 1ms de stopbit em '0' + os bytes 0xF8, 0xF8 e 0xFA) e os 256 bytes possíveis.

2 - Código 101 - Algum byte da sequência de 0x00 a 0xFF não coincide com o esperado. Isso ocorreu, enquanto estava caminhando pela casa, com paredes e lajes pelo caminho.

Testes preliminares:

1 - Obtive o código 111 (tudo ok) com o sinal através de duas paredes e mais alguns poucos metros, limitados pelo tamanho da casa.

2 - Deixei o transmissor funcionando em um cômodo e saí de casa com o receptor. Obtive o código 111 (tudo ok) com o sinal atravessando a parede com a rua, com 40cm de espessura, ou com uma pequena janela (sem visada direta com o transmissor). Da parede até onde me posicionei, dever ter uns 25 metros. Não deu para ir mais longe por limitação de visão, (um prédio se interpôs no caminho).

Próximos passos:

1 - Como todos os pinos do PIC12F675 já estão ocupados, terei que substituir o programa provisoriamente, por um que gere um trem de pulsos com o período de 2ms e 50% de semi período. A ideia é ajustar o indutor variável do receptor, para uma máxima distância entre o Tx e o Rx.

2 - Fazer um vídeo do experimento. Ir a um local aberto e testar a máxima distância, que o código ainda indique o perfeito funcionamento. Medir esta distância.

MOR_AL

.if · 6 de março

17 horas atrás, MOR_AL disse:

PICs 12F675 não possuem USART. Acho que devo estar levando mais de 10 vezes o tempo que ele levou para fazer o teste.

Para os próximos projetos, estarei migrando para a linguagem C

Acho que já disse em páginas viradas, mas não custa lembrar .. bit banging (clique)

Em c é quase bem fácil que quase digito aqui online com quase tudo comentado...Lembrando que o fonte e ideia é 100% original oriundo de uma época sem www

#define TX GPIO0

txbyte (unsigned char t)
{
TX=1; //start bit
asm("nop"); //ajuste de baud rate
//asm("nop"); ...
TX=0;
for(unsigned char i=0;i<8;i++) //8 bits
{
TX=t;//só considera o bit0
asm("nop");//ajuste de baud rate
//asm("nop"); ...
t>>=1;//desloca pra direita=próximo bit
}
TX=1; //stop bit
asm("nop"); //ajuste de baud rate
//asm("nop"); ...
TX=0;
}

E claro, como não precisa seguir padrões, pode fazer o start e stop como quiser... p.ex. enviar caractere começador e terminador...

Preguiça agora mas + tarde digito o rxbyte()

.if · 6 de março

2 horas atrás, .if disse:

digito o rxbyte()

Ainda não..

Refinei o código acima pra transmitir primeiro o MSbit... caso preferíeis ...

unsigned char GPIO0; //simula port
#define TX GPIO0
#include <stdio.h>

void txbyte (unsigned char t)
{
printf("%s","start ");
TX=1; //start bit
asm("nop"); //ajuste de baud rate
//asm("nop"); ...
TX=0;
for(unsigned char i=0;i<8;i++) //8 bits
{
TX=t;//só considera o bit0
asm("nop");//ajuste de baud rate
//asm("nop"); ...
printf("%d",(t>>7)&1); //simula osciloscópio no pino
t<<=1;//desloca pra esquerda=próximo bit
}
TX=1; //stop bit
asm("nop"); //ajuste de baud rate
//asm("nop"); ...
TX=0;
printf("%s"," stop");
printf("%c\n");
}

int main()
{
txbyte(0x55);
txbyte(0xaa);
txbyte(0x0f);
txbyte(0xf0);

txbyte(73); //primo e palíndromo em 7 bits :o)
}

Também testei em https://www.jdoodle.com/c-online-compiler

Faça ctrl-c ctrl-v e rode lá ... muito perto da inutilidade.. só como terapia ocupacional mesmo...

MOR_AL · 6 de março

@.if

Beleza. Já é um início....

Seu programa é a primeira coisa a se fazer, mas... Tem sempre o mas...

Partindo do zero...

1 - Levei um bom tempo para decidir, qual é a taxa de transmissão. Fiz algumas experiências e estudei algo postado na net. Cheguei a conclusão que a limitação da taxa se encontra no receptor. A melhor taxa está entre 1000 e 1200Hz. Mas o Ton distorce para menos Delta e vai diminuindo na medida que a taxa vai aumentando. Recuperar o dado fica mais complicado, se não impossível. Diminuir esta taxa também tem um preço. Tem um limite para o tempo em Ton. Piorando quando o dado é 0xFF, dando 10 ms em '1'. StartBit, mais dado e mais paridade (que não usei). Além disso a taxa menor não é o que se deseja.

2 - Tem que considerar que TEM QUE HAVER a transmissão de um preâmbulo antes de transmitir o primeiro byte, para que o receptor estabilize a sua polarização. Sem ele o dado não é recuperado. Estou falando de distâncias maiores que as encontradas em testes na net, onde em 99% dos vídeos a distância é de 20cm. Nestes casos o firmware fica fácil. Esse preâmbulo tem que satisfazer os itens 1.

3 - Considerei também a ausência de StopBit e de StartBit. Isso reduz bastante o lixo que o receptor capta.

Considerei também o período do StartBit e do StopBit. Idem.

4 - Tem que pensar nos muitos momentos em que o receptor capta lixo. O mesmo quando a distância começa a aumentar e o receptor capta apenas parte do byte. Eu pensei nisso e o firmware considera estes fatos.

Em tempo. O portão da vila onde eu moro, frequentemente abre sozinho. Ele tem uma placa comercial bem conhecida que contém estes módulos. A placa já foi trocada diversas vezes.

O programa em si é simples, mas quando se quer aumentar a distância entre o Tx e o Rx, as coisas complicam.

Valeu pela amostra do que poderia ser em c.

E mais!!!

Quero mesmo que comentem (e participem) para que eu possa usar as dicas e melhorar a bagaça.

Depois desse trabalho todo , o meu vídeo no YouTube vai ter poucas visualizações. Já aconteceu isso com os meus vídeos, mas eu tenho eles para ter um apanhado geral de como fazer as coisas.

MOR_AL

Renato.88 · 6 de março

31 minutos atrás, MOR_AL disse:

Em tempo. O portão da vila onde eu moro, frequentemente abre sozinho. Ele tem uma placa comercial bem conhecida que contém estes módulos. A placa já foi trocada diversas vezes

Não seria exatamente um problema, mas o que há de errado aqui é o seu controle, transmissor.

Nos padrões mais simples, ele envia números binários codificados em hexadecimal.

A sequência de dígitos pode formar 16777216 combinações possíveis que o fabricante do controle pode colocar neles de maneira aleatória.

E aí, você pode ter o azar de algum vizinho seu ter o controle igual, com a mesma combinação.

.if · 6 de março

22 minutos atrás, MOR_AL disse:

taxa está entre 1000 e 1200Hz

Sim amigo.. este ajuste no meu (meu) programinha de pode ser feito com adições de asm("nop")

35 minutos atrás, MOR_AL disse:

2 - Tem que considerar que TEM QUE HAVER a transmissão de um preâmbulo antes de transmitir o primeiro byte, para que o receptor estabilize a sua polarização

A isto denomina-se protocolo de comunicação. .. Está fora do escopo do meu exemplo. (Apesar que recebi um de um chinês que me vendeu 1 aparelho.. talvez eu ache... ) É você que tem que se virar pra garantir a consistência dos dados... Existem muitas técnicas bit de paridade, checksum, CRC, e etc além das que você pode criar

39 minutos atrás, MOR_AL disse:

aumentar a distância entre o Tx e o Rx, as coisas complicam.

37 minutos atrás, MOR_AL disse:

Tem que pensar nos muitos momentos em que o receptor capta lixo

Os cara da voyager que o diga ... falando nela.. olha que morno de agora há pouco https://www.inovacaotecnologica.com.br/noticias/noticia.php?artigo=nasa-desliga-instrumentos-sondas-voyager-mante-las-funcionando&id=010130250306

Se até eles conseguem captar o sinal, yes you can!

Ok.. mesmo que se ache o programa simples, aí vai o exemplo do rxbyte() que prometi a quem interessar possa

unsigned char rxbyte ()
{
unsigned char rxb=0;
for(unsigned char i=0;i<8;i++) //8 bits
  {
  rxb<<=1; //libera bit0 
  /*if (GPIO1) ...*/ if ((txb>>7)==1) rxb|=1; //bit7--->bit0
  asm("nop");//ajuste de baud rate
  //asm("nop"); ...
  txb<<=1; //só pra este teste online
  }

printf("%.2x",rxb);//resultado

printf("%c\n");
}


int main()
{
txb=0b101010101; //simula byte transmitido
rxbyte();

txb=0b10101010;
rxbyte();

txb=0b11110000;
rxbyte();

txb=0b00001111;
rxbyte();

}

Rodei no https://onecompiler.com/c/43b27pnkm

MOR_AL · 6 de março

1 hora atrás, Renato.88 disse:

Não seria exatamente um problema,

O portão abrir é um problema. Hoje em dia tem muito vagabundo na rua, só esperando uma brecha.

1 hora atrás, Renato.88 disse:

E aí, você pode ter o azar de algum vizinho seu ter o controle igual, com a mesma combinação.

Isso pode ser possível. O portão é de uma vila. Não é exclusivamente meu. Pode ter alguém dos prédios adjuntos acionando com o mesmo código.

1 hora atrás, .if disse:

Se até eles conseguem captar o sinal, yes you can!

Hahahaha!!!

@.if

É isso aí. Na medida que vamos nos aprofundando, a bagaça começa a complicar.

Se eu (eu) entendi (dei apenas uma olhada até a cabeça doer), você compara o byte recebido com quatro bytes em sequência. Mas cada byte recebido considera apenas um dos bytes testados de txb.

Se eu entendi, como ficaria a sincronização?

Como saber qual é o byte recebido se ele é comparado com apenas um dos bytes em txb?

Como fazer isso sincronizado para todas as opções de bytes?

@.if Não precisa se aprofundar. Sei que você é capaz. Devido às suas prioridades, você não teria como fazer em alguns minutos, que deve ser o tempo para relaxar aqui no fórum. Eu é que sou teimoso e decidi investir o tempo que for necessário.

Seguem as partes mais relevantes do fluxograma do Rx. Daí para o asm é um pulinho de gato.

As chamadas às rotinas são blocos em negrito.

As rotinas tem fundo amarelo em seu nome.

Não há perguntas em losango, pois ocupariam muito espaço. As respostas estão indicadas. Tudo é em retângulos. Com isso, a concentração dos blocos é máxima. Dá para ver a figura com mais detalhes. Lembra?... 1 jpg >> 1000 palavras, hehehe!

No começo é complicado de entender, mas a gente se acostuma.

O detalhe é que eu me acostumei, e para mim é mais fácil criar fluxograma do programa. Para passar para asm é quase que diretamente, mas para transformar em linguagem de maior nível que asm, como c, ou basic, aí fica complicado para mim.

Acho que é por este motivo, que eu reluto em mudar. Teria que pensar em c, ou em basic.

MOR_AL

.if · 6 de março

56 minutos atrás, MOR_AL disse:

como ficaria a sincronização?

Como saber qual é o byte recebido se ele é comparado com apenas um dos bytes em txb?

Como fazer isso sincronizado para todas as opções de bytes?

Desculpe... não expliquei (ou achei que não precisava) que o programinha é um simples receptor/transmissor de byte qualquer. Ele apenas desmembra em bits e vai deslocando cada bit até o port ou pino. Tipo um multiplex/demultiplex ou shift register.

A sincronização seria que ambos tx e rx devem possuir o mesmo baud rate ,, no caso nem precisei lançar mão de timers.. perceba o asm('nop') no meio do loop que literalmente dá uma alargada no bit que se traduz em redução (controle) do baud rate (algo como a frequência de transmissão).. o mesmo que ocorre nas interfaces seriais. Já o protocolo com preâmbulo, byte começador, controles e etc não está implementado lá, ok? De fato aquilo está literalmente na camada mais elementar do sistema e ganha por uma cabeça (em duplo sentido) do assembly

Ah sim, no rx no loop principal (que não está lá) ele fica esperando um bit no GPIO... algo como

while(GPIO1 && tmout--);//espera dado, se demorar, sai fora

Vou ver se acho no email o protocolo de um dispositivo que um chinês me passou há alguns anos.. este sim tem algumas camadas de segurança e confirmação da informação e etc

Renato.88 · 7 de março

8 horas atrás, MOR_AL disse:

O portão abrir é um problema. Hoje em dia tem muito vagabundo na rua, só esperando uma brecha

Sim, tem razão. Mas eu falava especificamente da eletrônica da placa do portão.

MOR_AL · 12 horas atrás

Pessoal!

Testei os programas do Tx e do Rx ao mesmo tempo.

Parece que está funcionando. Será? Não acredito que funcionou quase sem retoques.

Quando o Rx consegue identificar o preâmbulo e os 256 bytes transmitidos, os três leds acendem por 5s. Durante esse tempo, o receptor (aparelho) não lê o que chega ao receptor (módulo).

Depois ele apaga os leds e monitora o que o módulo Rx está recebendo.

Fica esperando pelo próximo preâmbulo e somente depois de identificá-lo é que ele continua.

Caso ocorra algum problema, ele explicita o código nos leds. Isso permite que se conheça qual o local do programa ocorreu o erro.

Geralmente ele mostra o led 1 aceso, também por 5s. "Foi detectado um ruído que não se parece com o preâmbulo".

Isso é um modo de saber que o receptor está com problema em identificar os dados. A chance do receptor estar longe do transmissor, ou com obstáculos entre eles é de quase 100%. Um retorno até a última posição detectada corretamente, logo faz com que os três leds acendam. "Tudo recebido como o esperado".

Com o desejo de aumentar a distância entre o Tx e o Rx, fui querer ajustar a frequência do receptor com a do transmissor. Só piorei as coisas. Depois de muito tentar, parece que retomei ao ponto que estava. O indutor variável do Rx é impregnado por uma resina, quase impedindo sua calibração. Nem adianta esquentar o indutor para retirar a resina, pois o plástico do indutor é de baixa temperatura de fusão.

Testes de distância:

Pretendo fazer os testes na praia. É o único lugar com espaço por aqui por perto.

1 - Fiz duas bases para serem fincadas na areia. Uma para o Tx e outra para o Rx.

2 - Fincarei a base do Tx (com ele) e prenderei o início de uma trena com 50m.

3 - Com muito otimismo, marcarei três pontos. O de 50m, o de 100m e o de 150m.

4 - Com a base do receptor comigo, irei me afastando do Tx, até o ponto em que o receptor ainda funcionou.

Um detalhe. Não sei porque, mas com o receptor em movimento ele acusa erro, mesmo estando próximos um do outro.. Então ando uns 10m e aguardo pela alteração do código nos três leds.

Já estou fazendo o vídeo com todo o procedimento.

Decidi que não vou verbalizar e nem escrever em qualquer língua. Apenas On, Off, Ok, ou pequenas fórmulas. A intenção é a que qualquer pessoa que goste de eletrônica, possa entender, qualquer que seja a sua linguagem.

Vou usar "1 jpg = 1000 txt". Olá @.if .

Problemas:

Um dos problemas é que com esse calor infernal, a praia fica com muita gente desde cedo até o sol ir embora. Isso atrapalha na visão direta entre Tx e Rx.

Outro problema é o ladrãozinho. Um dia estava fazendo ginástica lá pelas 5h30m da manhã, quando vi um sujeito roubar o celular de uma garota.

Já tinha até incluído um app que mostra a distância percorrida com o auxílio do GPS, mas deixarei o celular em casa. Só levarei uma filmadora, que ficará comigo o tempo todo e rezarei para que ele não leve o Tx durante o teste.

MOR_AL