Amplificador do PC - Montagem final

Bom, quatro anos depois e três esquemas diferentes "terminei" o amplificador do PC (o link leva para todos os posts sobre o assunto.. Ainda falta pintar o painel, fazer as marcações e corrigir a agressividade dos VUs. Mas funciona e estou usando. Comprei um kit de amplificador com TDA2030 na China e montei.

Infelizmente perdi os vídeos que tinha feito da montagem e só sobrou algumas fotos. Esta aqui é do teste com a fonte do amplificador anterior (com NE5532), para tentar eliminar o ruído da rede:

Amplificador na caixa

Acabei gravando outro vídeo, com o amplificador já montado e funcionando:


Das fotos que sobraram achei as que postei no Facebook. Aqui a placa montada, ainda com a ponte de diodos e só faltando os potenciômetros:
Kit de amplificador

Os componentes do kit:
Kit de amplificador

O esquema está bem ruim, alguns componentes não dá pra ler. Vou tentar redesenhar ele qualquer hora pra posta aqui. Se alguém ainda assim quiser ver é só pedir que eu escaneio do jeito que está mesmo. Como já apareceram pedidos para ver o esquema, segue:
Esquema do amplificador com TDA2030


A placa do amplificador da caixinha da HP é esta:
Amplificador da caixinha de som

Usei ela para os VUs. Tirei o potenciômetro de volume e coloquei dois trimpots. Tirei também a chave liga/desliga e botei um regulador 7805 na alimentação. Os VUs são usados para monitorar o nível de entrada, logo ela é ligada diretamente nos conectores RCA do amplificador. Ajustei os trimpots para que o VU marque logo antes da faixa vermelha um nível de 2V na entrada, que é o nível máximo que minha placa de som entrega. Na saída da plaquinha, antes do VU, montei um resistor limitador de 330 Ohms e uma ponte de diodos de Germânio:
Placa para VU

A versão original era essa aqui, com amplificador operacional:
Placa para VU

Ela não funcionou e depois de vários testes com ela não tive como reaproveitar. Acredito que tenha sido por causa da tensão de alimentação desregulada e bem acima do limite do amp-op. Devia ter confiado menos na especificação do transformador...

Contando instruções para verificar a viabilidade de um projeto

Nota: Este post é um registro dos primeiros estudos para um projeto que estou envolvido (e é mais um registro pessoal). Aqui apresento o problema inicial e vejo se existe a possibilidade da minha idéia vir a funcionar.

1. Sobre o problema:

Um conhecido possui uma máquina fabricada nos anos 80 que executa determinada tarefa. Tal máquina possui como controlador principal um processador equivalente ao MOS 6502, com circuito tipico da época com entradas (digitais e analógicas) e saídas, interface com o usuário (até quatro simultâneos) não muito avançada e pouca memória RAM. 

A programação é feita com "cartões" (placas de circuito impresso) com memórias EPROM (e/ou RAM em alguns casos), ligadas diretamente ao barramento de dados, endereços e controle. Troca-se a placa para se trocar o programa que a máquina irá executar (feitos em Assembly). Acontece que as tais placas de programação vão se desgastando com o tempo, se perdem, queimam, apresentam problemas e tem que ser trocadas. Como o hardware é antigo é um pouco complicado encontrar peças para manutenção. Em alguns casos é só trocar a EPROM por uma nova e continua-se a usar a máquina. 

Para facilitar a vida dos usuários pensou-se numa unica placa onde se possa trocar o programa via cartão SD ou por uma porta USB. Tal placa já existe e é fabricada lá fora justamente para atender a esta demanda. Custa por volta de $100 dólares (inclua-se aí o custo de trazer uma destas pra cá e deve dar duas ou três vezes esse valor). 

Antes que me perguntem, existem outras opções:

- Máquinas modernas especificas para este trabalho já existem . Mas não são tão simples, são mais caras que uma antiga usada (cinco a dez vezes mais) e as licenças de software exigem conexão com a rede do fabricante. O sistema é fechado, dificultando que você faça um programa ou modifique um existente para suas necessidades. Fora isso tem um desempenho anos-luz a frente de sua ancestral. Quem tem e usa diariamente nem quer saber da antiga mais.

- Dá pra emular o controle da máquina com um PC. Conheço pessoas que usam esta alternativa e gostam. Poderia ser a melhor opção, mas alguns operadores não gostam de usar um teclado para controle e a tela do PC como UI. Acho que é mais questão de gosto e diria até de saudosismo não usar um PC para isso. Alguns usam também a desculpa do tempo de boot do sistema, já que a máquina original é só ligar e usar.

Mas voltando a este caso especifico, o dono da máquina não quer se livrar dela e quer o projeto de uma placa equivalente a fabricada lá fora (cartão SD + USB).


2. Pré-projeto:


Os mais atentos já devem ter notado que a solução é algo parecido com um emulador de memória. Seria então uma placa nas mesmas dimensões do "cartão de programação" que carregaria um programa de um cartão SD ou outro meio para uma memória que seria acessada pelo processador da máquina. Os fatores limitantes são:
* Como em todo circuito da época as linhas de dados, endereços e controle são de 5V.
* Os componentes devem ser faceis de encontrar por aqui.
* O custo total deve ficar bem abaixo dos $100,00 Dolares. Caso fique maior ou igual compensa comprar a solução de fora.
* O tempo de acesso da memória, segundo o datasheet dos 6502 e equivalentes, é de, no máximo e com uma margem de segurança, 500 ns.

No primeiro rabisco do projeto pensei em um microcontrolador ligado a uma memória RAM externa (qualquer uma hoje tem um Tacc menor que 100ns) e alguns conversores de nível (3.3V para 5V). Em alguns "cartões" a memória é paginada e necessita de alguma lógica extra (feita com CIs TTL nas placas originais). Para estes casos pensei em uma CPLD, mas daí o projeto já ficou grande (não iria caber), custo alto (melhor comprar lá fora) e com componentes complicados de achar (PLD). 

Após alguns anos (!) pensando sobre o assunto eu sempre esbarrava nestes três problemas. Até que ano passado o meu conhecido, dono da máquina, me mostrou uma plaquinha com um microcontrolador SAM3X8E da Atmel que poderia ser a solução (quase) perfeita. O dito microcontrolador roda a 84MHz, tem pinos mais que suficientes para ser ligado (quase) diretamente aos barramentos de dados, endereços e controle da máquina e, mais importante, memória RAM interna de 96kB. Analisando a placa em relação aos quatro limitantes anteriores temos:
* Três ou quatro conversores de nível como o TXB0108 da Texas resolvem o problema do 3.3V vs 5V.
* Ele já tem a placa e os conversores de nível.
* O custo da placa é de $15,00 segundo o dono da máquina. Os conversores de nível são bem baratos ($1,00).
* O tempo de acesso é que vai pegar. Todo o processo do 650X da máquina acessar o barramento de endereços e ter um dado válido tem que levar menos de 500ns.

Será que agora vai? Bom, antes de botar a mão na massa (montar o protótipo) é preciso testar a possibilidade do microcontrolador fornecer os dados ao processador dentro de um Tacc de 500ns.

3. Testes da possibilidade de funcionamento:


O microcontrolador da plaquinha é um ARM Cortex M3 rodando a 84MHz. Isso dá um ciclo de clock de aproximadamente 12ns. Em um mundo ideal e num microcontrolador ideal eu teria 42 ciclos de clock (500ns/12ns) para completar a tarefa de ler um endereço no barramento do 650X da máquina e colocar um dado válido no barramento de dados. O número de ciclos de clock que um ARM gasta por instrução depende de vários fatores e não é muito fácil de calcular. O certo então seria escrever uma função, compilar e olhar o código de máquina (ou assembly) gerado e contar e/ou estimar os ciclos usados.

Para complicar um pouco a plaquinha com o ARM parece ter sido roteada para facilitar as ligações. Isso causou um problema com as linhas de endereços que não ficarão continuas. Tenho um buraco entre dois pinos do microcontrolador no portal de endereços que não são ligados externamente. Para resolver é necessário dois deslocamentos e uma soma no software, e perder alguns ciclos de clock ou usar uma tabela usando o endereço como indexador e gastar muita memória (128kB) mas ganhando alguns ciclos. Como o microcontrolador possui 512kB de Flash optei pela segunda opção.

Para os testes iniciais escrevi umas linhas de código em C já com o caso mais difícil, com paginação de memória. Neste caso seria para substituir uma EPROM 27C256 e alguma lógica com TTLs. O vetor table é a tabela para ajustes dos endereços e o vetor buffer é o conteúdo da EPROM que será emulada. "data" é o valor no barramento de dados e "addrs", claro, a entrada no barramento de endereços. "bank" é responsável pela troca de bancos de memória.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
//Codigo em C
const unsigned short table[65536] = {0};
unsigned char buffer[32768];

int main (void)
{
    unsigned short portc;
    unsigned char data;
    unsigned short addrs;
    unsigned char bank = 0;
  
    for(;;)
    {
        addrs = table[portc];
        if((addrs >= 0x1ff4) && (addrs <= 0x1ffb))
        {
            bank = (addrs & 0x000f) - 4;
        }
        data = buffer[addrs + (bank * 4096)];
    }
    return 1;
}

Para não gastar muito tempo instalando uma IDE para testar, usei o Compiler Explorer para ter uma noção de como ficaria o Assembly gerado pelo GCC. Selecionei o ARM gcc 5.4.1 e coloquei na caixa "compiler options..." o seguinte: "-mtune=cortex-m3". O resultado foi:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
;codigo em ASSEMBLY
table:
buffer:
main:
        str     fp, [sp, #-4]!
        add     fp, sp, #0
        sub     sp, sp, #12
        mov     r3, #0
        strb    r3, [fp, #-5]
.L3:
        ldrh    r3, [fp, #-8]
        ldr     r2, .L4
        mov     r3, r3, asl #1
        add     r3, r2, r3
        ldrh    r3, [r3]        @ movhi
        strh    r3, [fp, #-10]  @ movhi
        ldrh    r3, [fp, #-10]
        ldr     r2, .L4+4
        cmp     r3, r2
        bls     .L2
        ldrh    r3, [fp, #-10]
        ldr     r2, .L4+8
        cmp     r3, r2
        bhi     .L2
        ldrh    r3, [fp, #-10]  @ movhi
        and     r3, r3, #255
        and     r3, r3, #15
        and     r3, r3, #255
        sub     r3, r3, #4
        strb    r3, [fp, #-5]
.L2:
        ldrh    r2, [fp, #-10]
        ldrb    r3, [fp, #-5]   @ zero_extendqisi2
        mov     r3, r3, asl #12
        add     r3, r2, r3
        ldr     r2, .L4+12
        ldrb    r3, [r2, r3]
        strb    r3, [fp, #-11]
        b       .L3
.L4:
        .word   table
        .word   8179
        .word   8187
        .word   buffer


código em C e em ASM

A área de interesse começa em .L3 e, no pior caso, a função consome 28 instruções. No ARM, normalmente, as instruções de carga (ldr, ldrh e outras) são executadas em 2 ciclos de clock. Assim, num cálculo meia-boca, parece que vai caber nos 42 ciclos de clock que tenho para executar a função.

Três coisas interessantes:
1. Se trocar o tipo da variável "bank" para long (32 bits) o código cai para 26 instruções.
2. Se trocar o tipo do vetor "table" para long (32 bits) o código cai para 24 instruções.
3. Trocando o escopo das variáveis de local para global o código aumenta para 39 instruções.
Isso mostra que, sempre que possível, é interessante usar o tamanho nativo do processador usado. No meu caso o ganho do item 1 (2 instruções) ao custo de 3 bytes de RAM compensa. Já no item 2 o custo é muito alto (+128kB de flash) para o ganho resultante (-2 instruções). Já o item 3 é bem conhecido e esperado. Usar variáveis locais normalmente faz o compilador usar os registradores do processador (mais rápido) e não alocação de memória ou pilha para elas.

Ok, continuando os testes chegou a hora de testar na IDE do ARM que, talvez, será usada no projeto. Como esta IDE (e praticamente tudo que usa ARM) usa o GCC esperei resultados parecidos ou melhores (devido as otimizações ligadas no compilador). Só não esperava tão melhor:


void main(void)
{
   801c4: 4b0b       ldr r3, [pc, #44] ; (801f4)
   801c6: 7819       ldrb r1, [r3, #0]
  for(;;)
  {
    addrs = table_addrs[REG_PIOC_PDSR];
   801c8: 4b0b       ldr r3, [pc, #44] ; (801f8 )
   801ca: 681a       ldr r2, [r3, #0]
   801cc: 4b0b       ldr r3, [pc, #44] ; (801fc )
   801ce: f833 3012  ldrh.w r3, [r3, r2, lsl #1]
    if((addrs >= 0x1ff6) && (addrs <= 0x1ff9))
   801d2: f5a3 52ff  sub.w r2, r3, #8160 ; 0x1fe0
   801d6: 3a16       subs r2, #22
   801d8: 2a03       cmp r2, #3
   801da: d803       bhi.n 801e4 
    {
      bank = (addrs & 0x000f) - 6;
   801dc: f003 010f  and.w r1, r3, #15
   801e0: 3906       subs r1, #6
   801e2: b2c9       uxtb r1, r1
    }
    REG_PIOD_ODSR = buffer[addrs + (bank * 4096)];
   801e4: 4a06       ldr r2, [pc, #24] ; (80200 )
   801e6: eb03 3301  add.w r3, r3, r1, lsl #12
   801ea: 5cd2       ldrb r2, [r2, r3]
   801ec: 4b05       ldr r3, [pc, #20] ; (80204 )
   801ee: 601a       str r2, [r3, #0]
    }
    REG_PIOD_ODSR = buffer[addrs + (bank * 4096)];
  }
}

void main(void)
   801f0: e7ea       b.n 801c8 
   801f2: bf00       nop
   801f4: 200788f1  .word 0x200788f1
   801f8: 400e123c  .word 0x400e123c
   801fc: 00084ad4  .word 0x00084ad4
   80200: 200708f0  .word 0x200708f0
   80204: 400e1438  .word 0x400e1438

00080208 _Z2f4:
    REG_PIOD_ODSR = buffer[addrs + (bank * 4096)];
  }
}

No pior caso, depois de entrar no for e cair na checagem de endereços, são 17 instruções! Isso cabe com folga na janela de tempo. Uma coisinha interessante neste código é a linha 801F2, onde o compilador marotamente incluiu um NOP ali que nunca será executado. Pode parecer desperdício, mas aquele singelo NOP serve para alinhar a memória em endereços de 32 bits para que o ARM não gaste mais ciclos quando acessar o que vier depois. Os caras pensaram até nisso ao criar o compilador. Por isso a briga ASM vs C não tem mais sentido hoje em dia. Um programador sozinho em ASM nunca pensará em todas as possibilidades. Já uma equipe de centenas de pessoas fazendo um compilador fará um serviço muito melhor. 

Bom, agora já tenho razões de sobra para acreditar que a plaquinha irá dar conta do recado. Vou montar e testar e, se tudo der certo, mostrar pra vocês também. Aguardem. ;-)

Apagador de EPROM Minipa ME-121 por dentro

Apagador de EPROM Minipa ME-121

E hoje eu desmontei meu apagador de EPROM Minipa modelo ME-121. É um modelo meio antigo, com timer eletromecânico. Segue o vídeo e logo depois mais umas fotos e comentários:


A placa do aparelho é esta:
Apagador de EPROM Minipa ME-121 placa

Me parece que é um oscilador com um único transistor (2SD880) para elevar a tensão para a lâmpada. O oscilador só funciona se o timer estiver ligado e a chave da gaveta de EPROMs fechada. A lâmpada é um germicida de 4W:

Apagador de EPROM Minipa ME-121 Lâmpada

AP Router WR254 LCD por dentro


A placa acima é de um roteador AP Router WR254 LCD-b. Era um roteador para alinhamento de antenas, com um LCD e um teclado, que dispensa o uso de um notebook. A solução até que é boa, com um roteador comercial ligado a uma placa para leituras via serial (acho). Segue o vídeo onde apresento o aparelho:


A placa do LCD do roteador tem um PIC 16F627 e uma outra plaquinha com um PIC 12F675:

Placa do LCD do roteador WR254

Desmontando um Walkie Talkie Continental de brinquedo

Walkie Talkie Continental

E hoje eu mostro pra vocês o que tem dentro de um Walkie Talkie de brinquedo da Continental. Estes Walkie Talkies são todos muito parecidos por dentro e já falei de um da Boxer Toys aqui. Segue o vídeo:


A placa é pequena:
Walkie Talkie Continental - Placa

Tem bastante espaço dentro do brinquedo, quem vê de fora acha que deve ter um circuito enorme. Mas é o de sempre: Um transistor que vira oscilador-transmissor ou receptor, conforme a posição da chave:
Walkie Talkie Continental - RF

E um amplificador de áudio com três transistores e saída com transformador:
Walkie Talkie Continental - Amplificador de audio
O Alto falante vira microfone quando a chave push-to-talk está na posição de transmissão.

Respostas as perguntas mais frequentes sobre reaproveitar LCD de notebook, TV ou monitor

Placas Universais de LCD

Devido ao sucesso dos meus vídeos sobre placas universais de LCD, centenas (sim, centenas) de perguntas surgiram e resolvi criar uma FAQ sobre o assunto. Era pra ser um texto aqui no blog, mas acabou virando um vídeo:



Em breve colocarei a transcrição do vídeo ou uma FAQ em texto aqui...

Desmontando um videocassete (Panasonic NV-L26BR)

Mais uma desmontagem pra abrir espaço no "laboratório". Desta vez foi um videocassete Panasonic NV-L26BR. O post vai ser um pouco diferente, com mais fotos e menos texto. Mas antes, segue o vídeo onde desmonto o aparelho e falo algumas abobrinhas:


E quebrando aqui...

Gibi Trissemanal 1947 com Popeye

Gibi Trissemanal com Popeye na capa

Calma, isso aqui ainda é um blog sobre eletrônica. Mas é que não quero criar outro blog e nem outro canal pra mostrar isso, então vai aqui mesmo.

São duas edições do Gibi Trissemanal: número 1313 de 10 de Setembro de 1947 e número 1333 de 26 de Outubro de 1947. Esse é o Gibi de verdade, que deu origem ao uso da palavra como equivalente para "Revista em quadrinhos". As duas estão há tempos enquadradas e penduradas loga acima da mesa do meu PC.

No vídeo abaixo eu mostro elas melhor:

Montando um pequeno transmissor de FM

Transmissor de FM - Placa montada
E lá vou eu de novo montar um kit Chinês. E pra não variar é um micro transmissor de FM. Segue a montagem em vídeo:

E uma foto dos componentes do kit (não veio esquema):
Kit de transmissor de FM - componentes

Desmontando um telefone Ibratele Capta Phone

Telefone Ibratele Capta Phone
Sim, eu consegui remontar ele só pra tirar uma foto...
Mais um "por dentro" aqui no blog e lá no canal do Youtube (já se inscreveu no canal? Não custa nada e você ainda me ajuda). Depois do antigo telefone de disco agora é a vez de um telefone mais moderno. Este Ibratele Capta Phone tem memórias, viva-voz e identificador de chamadas. Não tenho mais linha física, então não tenho como testar... Mas vamos ao vídeo de hoje:


Embaixo do aparelho tem um suporte para três pilhas pequenas para alimentar o telefone quando falta linha. Só que alguém acabou esquecendo as três lá dentro e:

As pilhas vazaram e "fundiram" com o suporte. Por isso que é sempre bom retirar as pilhas de aparelhos eletrônicos quando não for usar mais.

O telefone propriamente parece ser esta placa:
Placa do display - Telefone Ibratele Capta Phone

 É a placa onde fica o LCD e embaixo do LCD tem este CI:

Placa do display - Telefone Ibratele Capta Phone

É aí que está toda a "inteligência" do aparelho e me parece um módulo comprado pronto de outro fabricante. Já o teclado é feito num placa de circuito impresso, sem chaves. Não dá pra reaproveitar nada dele: 
Placa do teclado - Telefone Ibratele Capta Phone

E esta placa bonita aqui é a parte analógica do telefone. Só tem transistores, diodos e passivos montados em uma ordem bem legal:
Placa analógica - Telefone Ibratele Capta Phone

Uma marcação na parte superior da placa parece indicar que ela é de 2007.

Desmontando uma vídeo babá eletrônica

E ontem o Mário aparece aqui em casa com mais uma doação:
Video babá eletrônica

É uma vídeo babá eletrônica. Ela tem uma câmera que envia o vídeo para a centralzinha que mostra num LCD. Os dois aparelhos tem baterias internas que parecem que já estragaram. Fora isso acho que funcionam. Como sempre, segue o vídeo de "por dentro":


Aqui central por trás:
Video babá eletrônica - Central

Não tem marca, etiqueta de identificação do fabricante, certificações, nada. Nem na central e nem no módulo da câmera:
Video babá eletrônica - Camera

A câmera tem 9 LEDs infravermelhos e um LDR, para visão noturna. As conexões e controles neste módulo são estas:
Video babá eletrônica - Conexões

Um conector para a antena, um botão de liga/desliga, LED e conector da alimentação (5V). A parte de baixo da placa da central:
Video babá eletrônica - Placa

Tudo SMD e o microfone ali embaixo a esquerda é pra poder falar e ser ouvido lá no módulo da câmera. Isso indica que a parte de RF é um transceptor. Agora a parte de cima da placa:

Video babá eletrônica - Placa

O CI grande é um SONI (sim, isso mesmo!) SN933 impossível de achar alguma referencia. A memória de 8 pinos é uma 25L400 e aquele CI embaixo é a direita é um NE8P120S (também não achei nada sobre ele). Dentro da câmera tem esta placa de circuito impresso e o circuito deve ser o mesmo de uma câmera de segurança comum:
Video babá eletrônica - Placa camera

Aqui a placa de controle da câmera, sem o módulo de RF:
Video babá eletrônica - Placa camera
O CI também é da SONI com a mesma memória ligada a ele. Depois que olhei melhor a foto e vi que a placa de alimentação está com as indicações dos pinos.

Vista dos LEDs, do LDR e da lente do sensor da câmera:
Video babá eletrônica - Modulo camera

Os módulos de RF são os mesmos e o código NET924 não rendeu nada numa busca no Google:
Video babá eletrônica - Modulo RF 2.4GHz

Sobre módulos de RF de 433MHz

Módulos de 433MHz

Comprei estes módulos de RF de 433MHz no Aliexpress para montar novamente um projetinho que fiz em 2002 (ou foi em 2003?). Precisarei de apenas um par mas por segurança comprei dois, pois vai que um deles apresente problemas. Este post é um ajuntamento das informações inciais que levantei nos últimos dias e que talvez interesse a alguém.

1. Fotos dos módulos


O módulo de transmissão mede 2 x 2 cm e tem três pinos: VCC, GND e data. Na parte de cima tem duas bobinas e aquela "caneca" de metal. Aquilo é um filtro SAW (Surface Acoustic Wave) de 433MHz usado no oscilador, permitindo que o módulo não precise de ajuste de frequência. Note que os módulos vem com um pad na placa para soldar a antena. A alimentação é de 3V até 12V. Quanto maior a tensão de alimentação maior a potência de saída e, consequentemente, maior o alcance.
Módulos de 433MHz - Transmissor

O módulo de recepção mede 1.5 x 3 cm e tem quatro pinos: GND, VCC e dois para a saída de dados. A sintonia é feita naquela bobina no centro, selada com tinta vermelha. O módulo é alimentado por 5V. Também temos um pad para soldar uma antena, no canto inferior esquerdo:
Módulos de 433MHz - Receptor

2. Esquemas


Existem esquemas dos módulos em baixa resolução por aí. Mas como fui simular a parte do operacional no Tina-TI acabei completando com o receptor para postar aqui em formato maior:
Módulos de 433MHz - Esquema do receptor
O receptor é regenerativo, com T1 como amplificador de RF e T2 como oscilador. O primeiro amp-op do LM358 está ligado como amplificador com ganho de 221 (47dB). Já o segundo é um comparador com histerese para quadrar o sinal para a saída.

O esquema do transmissor é este aqui:
Módulos de 433MHz - Esquema do transmissor
Q1 é o oscilador de RF com frequência definida pelo filtro SAW X1. As bobinas tem 6,5 (L2) e 2,5 (L3) voltas. Os valores dos resistores e capacitores foram retirados dos esquemas que tem por aí na web e precisam ser confirmados. Q2 é usado para chavear a alimentação da parte de RF via R1. Assim o consumo com a entrada de dados em 0 é bem baixo.

3. Alcance teórico dos módulos


Então, dando uma olhado nos manuais (aqui, aqui e aqui) é dito que o alcance é de 20 a 200 metros dependendo da tensão de alimentação do transmissor. Embora a tensão de alimentação do transmissor influencie no alcance, a sensibilidade do receptor também conta muito. Olhando os manuais e alguns anúncios sempre é dito que a sensibilidade do receptor é de -105dB. Como essa medida é relativa era pra ter algo a mais além de só dB, como dBm ou dBuV que são as mais usadas para sensibilidade. Se fosse em dBuV e considerando uma impedância de entrada de 50 Ohms, daria -212dBm o que seria absurdo. Nenhum receptor tem essa sensibilidade.

Já em dBm achei o valor de -105dB muito bom para um receptor regenerativo. Muito bom demais para ser verdade. Para ver se minhas suspeitas de que este valor é inflado calculei o alcance de um par destes módulos no espaço livre com a equação de Friis:


Equação de Friis

Ignorando os valores dos ganhos das antenas (Gt e Gr), considerando a velocidade de propagação igual a c (eu sei, eu sei) e pegando a menor potência descrita nos manuais dos módulos de transmissão (10mW ou 10dBm), joguei no Wolfram Alpha e ele montou a equação:

E calculou o alcance r:
Eita! "Alguma coisa errada não está certa". 30km de alcance esses modulozinhos não conseguem nem aqui, nem na China. Voltando ao valor de sensibilidade do receptor, um receptor regenerativo tem sensibilidade por volta dos -60 a -70 dBm, chegando a, no máximo, -80 dBm em um ótimo caso. Acima disso só num heteródino. Recalculando para uma sensibilidade de -65dBm o alcance cai para 310 metros, muito mais próximo da realidade. Fica então a questão sobre de onde tiraram o valor de -105dB.

Para quem quiser brincar no Wolfram Alpha, segue a string para a equação acima: -105=10+20*log10((3e8/4.33e8)/(4*pi*r))

4. Teste inicial (08/03/2017):


Para verificar se os módulos estão funcionando montei o transmissor e o receptor no protoboard. Para o transmissor liguei um resistor de 1k para o terra e uma chave para o Vcc. Já no receptor coloquei um LED para o terra com um resistor limitador. Testei também com um transmissor de portão de garagem. Aproveitei e filmei um dos testes:


4. Próximos passos


Agora preciso testar os módulos pra ver se estão funcionando. Isso é fácil e talvez eu faça um vídeo. Depois vou fazer um teste de alcance. Não preciso de muito (uns 10 metros dentro de casa já tá bom) e deve dar certo. Por último vou montar o projetinho e, se tudo der certo, publicar os resultados aqui.

Por dentro de um antigo telefone de disco

Telefone de disco antigo verde

O aparelho da foto foi comprado ontem, no ferro-velho. Ainda não tenho um uso pra ele, mas acho que dá pra reaproveitar o disco para um projetinho com Arduino e a campainha eletromecânica para incomodar os outros. Claro que tem vídeo de "por dentro" (o pessoal parece que realmente gosta disso):


E vamos as fotos. Primeiro uma vista interna do aparelho:

Telefone de disco - por dentro

Como eu disse no vídeo, o circuito é mais ou menos padrão e pelo que me lembro tinha um tal de "padrão Telebrás" com um esquema básico. Me lembrou da época em que trabalhei consertando telefones públicos. O capacitor de 1uF é o da campainha para não deixar passar o nível DC. O transformador é uma hibrida telefônica para separar o áudio que vem do que áudio que vai:

Telefone de disco - por dentro - placa

O disco tem uma marcação escrita "1972" que deve ser o ano de fabricação. Pela caixa transparente dá pra ver os dois contados chaveadores. Um é fechado quando se gira o disco e só abre novamente quando ele para. O outro é interrompido um número de vezes igual ao do número discado:
Telefone de disco - por dentro do disco

A bobina da campainha, que aciona o badalo (ou martelo) que bate nos sinos. A peça de plástico branca é o "controle de volume" da campainha. Ele ajusta a força com que o badalo (ou martelo, como queira) bate nos sinos:
Telefone de disco - Campainha eletromecânica

Um angulo melhor, de cima, onde se vê o martelo (ou badalo, hehe). Preciso tirar a parte elétrica, desmontar as peças e limpar tudo:
Telefone de disco - Badalo da campainha