ASM51

Ola a todos.
Estou trabalhando em um conversor ad em vhdl.
Quero utilizar este conversor ad em áudio.
Ele esta funcionando, mas apresenta um pouco de chiado na conversão.
Como eu fiz?
O conversor ad, é feito com a técnica SAR (registrador por aproximações sucessivas), escrito em vhdl.
É necessário o uso de um conversor DA, este eu fiz com rede R2R com resistores de 20K e 10K.
A resolução é de 16bits por enquanto, depois vou aumentar esta resolução.
O circuito de sample-and-hold, éfeito com o c.i max323 que é próprio para esta função.
A frequência de clock é de 4Mhz com cristal de quartzo.
O comparador analógico e o OPA4354 :
UNITY-GAIN BANDWIDTH: 250MHz
WIDE BANDWIDTH: 100MHz GBW
HIGH SLEW RATE: 150V/μ
este opa é muito rápido.
O resumo da técnica é a seguinte.
Após o reset, o circuito de S_H faz uma amostra do sinal de entrada.
O conversor AD, juntamente com o DA, convertem o sinal em 16 pulsos de clock.
Após a conversão, o valor é armazenado em um registrador de dados feito com flip-flop’s tipo D.
Em seguida, este valor armazenado é entregue para outro AD, também feito com rede R2R de 20k e 10k.
Como este é um conversor unipolar, ou seja, somente trabalha com valores entre 0V e Vcc, e os sinais de áudio são bipolares (-V a +V) tenho que utilizar um circuito divisor resistivo na entrada do ad, em VCC/2 para transformar os sinais bipolares em unipolares. Dois resistores de 1M.
O sistema funciona, mas apresenta um pequeno chiado nas conversões, e eu não sei onde esta sendo produzido este chiado.
Quando retiro o divisor resistivo, posso utilizar este conversor para converter valores entre 0V e 3,3V, que é o valor de alimentação do cpld xc95288xl da xilinx.
O valor aferido no segundo DA, acompanha o sinal de entrada. É muito legal.
No entanto, com áudio temos este pequeno chiado. Alguém pode me ajudar a resolver esta questão?
Mais alguns dados.

Com 4Mhz de clock e 16 bits de resolução, tenho uma taxa de amostragem de 4000000Mhz/ 16=250000hz ou 250Khz. é muito acima de niquist, e mesmo assim existe o chiado, mesmo diminuindo ou aumentando a frequência do clock, o chiado persiste.
Todos os componentes trabalham com 3.3Volts e são especificados para esta tensão. A PCI é dupla face, e procurei ser cuidadoso em relação a blindagem.
Para o sinal de entrada, utilizo um gerador de sinais que gera sinais neste caso entre 20 e 20khz.
Tenho osciloscópio da kenwood aqui também.
Verificando os diversos sinais desde o clock, sinal de entrada prodizido pelo gerador de áudio, até o converor DA, não consigo encontrar a fonte de ruído.
Enfim, não sei onde pode estar o problema.

Se esse ruido for 'branco' em princípio um capacitor de baixo valor no final do circuito de conversão deveria ajudar, mas sem ver mais detalhes do sinal fica meio dificil dar palpites.

Acredito que o caminho da solução é algo como foi comentado pelo André: estudar o ruído presente no sinal.
Pelo que foi dito, o que eu faria é salvar um trecho das conversões e plotar uma FFT no Matlab ou Scilab ou similar para verificar se o ruído é randômico ou é situado em frequências específicas.

Estou usando o ubuntu em meu pc, e ainda não consegui configurar o áudio, então gravei duas amsotras de áudio da saída do conversor AD com o celular.
É o suficiente para se ouvir o chiado na saída do segundo DA, enquanto, colocando o amplificador de áudio no primeiro DA, não existe praticamente nenhum ruido.
Na entrada do AD antes do S_H (sample and hold) existe um filtro bassa baixas passivo de primeira ordem RC com frequência de corte em aproximadamente 22KHz e estes filtros também existem nas saidas dos DA’s.
O segundo DA funciona assim:
ele não é conectado diretamente na saida do SAR como o primeiro DA é.
O segundo DA esta conectado em um registardor de 16 bits feito com flip flop tipo D que a cada fim de conversão, é carregado com o valor convertido.
em anexo segue uma imagem dos tempos do SAR.
Enfim o ruído persiste.

Não consegui anexar os arquivos. Depois vejo porque.

wilson souza escreveu:Estou usando o ubuntu em meu pc, e ainda não consegui configurar o áudio, então gravei duas amsotras de áudio da saída do conversor AD com o celular.

No Ubuntu você pode capturar a entrada de áudio *microfone ou entrada do microfone) com o octave (um programa semelhante ao matlab) e depois analisar o espectro fazendo, por exemplo:

Código: Selecionar todos

y=record(1,16000);
plot(abs(fft(y)));


os argumentos do record significam: adquirir 1 segundo de áudio a uma taxa de amostragem de 16000 samples/sec.

Se o record falhar dizendo que não encontra o /dev/dsp eu creio que só precisa instalar o ALSA, depois disso, ele funcionará, mas na primeira vez que você chamar a função ela vai chiar com coisas do tipo

Código: Selecionar todos

LSA lib pcm_dmix.c:1029:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_dmix.c:1029:(snd_pcm_dmix_open) unable to open slave
...
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock
...


mas vai funcionar, as próximas chamadas não produzirão essas mensagens de erro.

Use plot(y); para verificar a amplitude do sinal capturado, se estiver com ganho alto e for cortada, a FFT não produzirá o espectro correto e se estiver muito baixa, o espectro gerado pela FT conterá muito ruído decorrente do erro de quantização na conversão AD

Legal vou tentar isso. Mas percebi, que a única diferença no acionamento do segundo dac R2R , é o tempo. Enquanto o primeiro dac fica o tempo todo conectado ao sar, porque ele precisa fazer a conversão durante todo o tempo, o segundo dac somente recebe os dados no final da conversão, quando todos os bits estão prontos. Como o segundo dac possui em sua entrada um registrador com FF tipo d, os dados permanecem os mesmos até a próxima conversão. O problema pode estar ai. Já que o sinal de áudio do primeiro ad é muito limpo, o defeito deve estar na forma como capturo os dados. Vou continuar investigando.