Ruído (relacionado à capacitância?) No sinal serial


11

As imagens do "resumo executivo":

O sinal serial parece bagunçado

Alimentando 3.3V ao microfone, sondando o TX do tablet

Quero decodificar o sinal serial que sai do fone de ouvido do meu tablet. Este é um "hack" um tanto estranho que existe em alguns telefones e tablets: basicamente, se você alimentar 3,3V na entrada de microfone do seu plug TRRS, os canais esquerdo e direito se tornarão TX / RX serial.

Usei um cabo Raspberry PI TRRS para TV (como você pode ver na segunda foto) para ter acesso aos 4 locais que eu precisava: GND, MIC, L, R. O cabo não deve fazer nada além de expor os 3 sinais (MIC, L, R - emparelhados com GND) nos três cabos correspondentes (vermelho, branco, amarelo).

Usei as sondas do meu BitScope para sondar entre o TX (ponta do cabo branco na segunda foto) e o GND comum (sonda marrom na parte inferior da segunda foto). Também usei duas sondas (vermelha e azul) para "alimentar" 3,3V do meu chip USB / TTL (um PL2303HX conectado ao meu laptop) até a ponta do MIC (vermelho).

Ao reiniciar o tablet, vi de fato o que é inconfundivelmente um sinal serial em 115200 (pico a pico de 8 a 9us), mas com muita capacitância (vídeo) .

Então, minha pergunta - antes de entrar on-line e pedir um plugue TRRS, cabos e um ferro de solda - é a capacitância que estou vendo devido a ...

  • o cabo TRRS para TV de 1 metro de comprimento ou o uso de sondas em vez de cabos soldados

OU

  • as sondas e o cabo, na verdade, não são responsáveis ​​por tanta capacitância, e a razão pela qual estou vendo isso é que o fone de ouvido do tablet simplesmente não foi projetado para emitir esse sinal (ou seja, o que estou vendo é realmente o que sai do conector) .

Como você provavelmente pode adivinhar, sou muito novo nesse tipo de coisa; Eu sou um cara de software, comprei meu BitScope há uma semana e adoraria acessar a série do meu tablet por "diversão e lucro" (hackear coisas do bootloader, compilar o Cyanogenmod para isso etc.).

Eu apreciaria um palpite estimado sobre se essa é uma causa perdida (ou seja, os cabos não podem explicar tanta capacitância) ou não.

Agradecemos antecipadamente por qualquer ajuda / sugestões.


1
O sinal parece bem normal para mim. O que você não gosta nele? Seu cabo RCA provavelmente tem a capacidade de 1000pF a granel, aproximadamente, portanto, não deve ser surpresa ter bordas lentas.
11406 Ale..chenski

"O que você não gosta" - as bordas são muito lentas, eu acho (meu PL2303HX - ou seja, meu USB / TTL - não decodificou nada).
Ttsiodras

(1) verifique se o cabo está a menos de 3 metros (10 pés); (2) se você puder obter apenas um conector como parte sem cabo, conecte-o ao tablet e meça nele sem cabo para ver a "qualidade" do sinal; (3) taxa de transmissão apenas mais baixa.
Anônimo

@ Anonymous - eu tentei; postou meus resultados abaixo.
Ttsiodras 15/10

1
@AliChen: Você estava certo, companheiro - usei um BSS138 e decodifiquei o sinal (consulte o adendo à minha resposta abaixo). Incrível - não esperava isso.
Ttsiodras 18/10/16

Respostas:


10

Então, eu segui o conselho dado pelas duas pessoas gentis que comentaram ... Aqui estão os resultados.

  1. Ali Chen indicou que as bordas lentas podem ser atribuídas à capacitância do cabo RCA; e "Anônimo" recomenda a conexão direta à placa com uma tomada sem fios. Eu segui o conselho deles, tirei o tablet para expor o PCB, liguei uma tomada e a sondou - mas infelizmente os resultados foram os mesmos: bordas muito lentas e claramente orientadas por capacitância. Não eram os fios RCA - parece que quem projetou o tablet não se importou muito com o sinal serial saindo do fone de ouvido (provavelmente usado de outra maneira para fazer interface com a placa). Tentei investigar todo o PCB na esperança de encontrar um sinal serial mais limpo, mas falhei.

  2. O Anonymous também recomendou diminuir a taxa de transmissão; infelizmente, não há nenhuma maneira documentada de influenciar o processo de inicialização do meu tablet, de modo a configurar a taxa de transmissão usada durante o u-boot (que é o que eu estava interessado) ...

Mas é possível fazer isso APÓS a inicialização ser concluída, de dentro de um shell do ADB - desde que eu consegui compilar meu próprio kernel e me tornar root .

Então eu pude fazer isso ...

$ su
# stty -F /dev/ttyHSL0 9600
# while true ; do echo UUUUUUU > /dev/ttyHSL0 ; sleep 0.1 ; done

E, de fato, o resultado é muito melhor:

Muito melhor em 9600

Tenho certeza de que esse sinal pode ser decodificado corretamente, se eu usar um shifter (é de 1,8V, então meu USB-TTL de 3.3V ainda não pode decodificá-lo).

Então, para concluir: a "porta serial dentro do fone de ouvido" do meu tablet só pode realmente ser usada APÓS a inicialização ser concluída, e o UART diminuiu para 9600 baud; o que é lamentável, já que a saída serial é mais necessária durante o processo de inicialização (se houver alguma falha) - e durante esse tempo, a velocidade do UART é codificada no código de inicialização do meu tablet a 115200 baud.

PS: Tentei também uma sugestão de um amigo, para usar um pull-up de 3,3K em direção ao trilho de 3,3V no sinal serial enviado pelo fone de ouvido - sem sucesso.

ATUALIZAÇÃO, 3 dias depois

Eu perseverei :-)

Seguindo o conselho de Chris Stratton - que um bom shifter pode lidar com esse tipo de sinal - comprei um ferro de solda, um BSS138, uma tábua de pão e um monte de cabos. Após o que provavelmente é o pior trabalho de soldagem de TODOS OS SEMPRE, consegui soldar os cabeçalhos dos pinos no BSS138 e, em seguida, prendi-o à tábua de pão e crie essa bagunça emaranhada:

A placa de ensaio e meu BSS138

O que eu não esperava era que, depois de gerar o minicom e emitir uma "reinicialização do fastboot", para minha total surpresa, vi o seguinte:

Sinal serial decodificado!

Inacreditável - depois que o BSS138 "eleva" o sinal de 1,8 a 3,3V, esse sinal miserável e cheio de capacitância pode realmente ser decodificado! Finalmente, posso ver por que meu tablet não está inicializando.

Olá, pequeno tablet - EU POSSO você agora :-)


1
Embora seja bastante provável que o sinal original possa ser decodificado com um deslocador de nível bem projetado, também é possível que a largura de banda do circuito de saída de áudio enviado seja um pouco menor do que seria ideal para esse sinal digital. Um produto de consumo precisa passar nos testes de interferência emitidos, e o próprio amplificador de fone de ouvido é provavelmente um design de comutação, portanto, provavelmente haverá filtros LC na borda da placa para suprimir as emissões, que seriam projetados principalmente para transmitir áudio, e não isso.
Chris Stratton

Mas considere também se o seu escopo de desempenho relativamente baixo ou as configurações que você está usando com ele podem estar deturpando o sinal - seria bom comparar comparar a saída do seu pi ou um conversor serial USB na mesma taxa de transmissão e consulte quão quadrado o escopo faz essa aparência.
Chris Stratton

@ ChrisStratton Sobre filtros de interferência: não faço ideia, mas parece plausível, se o recurso que eu descobri (serial via fone de ouvido) não fosse para ser usado. Inicialmente, descobri isso ao ler sobre dispositivos Nexus - e, curioso para saber como meu tablet responderia, decidi tentar. Sobre a verificação do meu escopo: claro, foi a primeira coisa que fiz quando o comprei - mostra pulsos quadrados claros em 115200 enviados pelo pino TX GPIO do Raspberry PI2. Nesse momento, tenho certeza de que não sou eu, nem meu escopo - é o HW do tablet.
Ttsiodras 16/10/16

@ ChrisStratton: "... pode ser decodificado com um shifter de nível bem projetado" - você tem algum chip específico em mente?
Ttsiodras 16/10/16

@ Chrishratton: Vitória! O BSS138 decodificou o sinal - aumentei minha resposta e incluí a prova :-) Obrigado por me indicar a direção certa.
Ttsiodras 18/10/16

0

Seu DSO tem largura de banda suficiente a 524ksps para mostrar uma onda quadrada na taxa de dados de 115,2kbps? Eu acho que sim. apenas para sua informação. Eu poderia estar errado.

Talvez você tenha usado uma resolução mais lenta.


Uau, sem amor pelo rapaz! BitScope :-) ruim :-) Sério, porém - a BitScope examina os 115200 bauds que saem do meu Raspberry PI, mostrando pulsos quadrados agradáveis ​​e claros ... nada parecido com o que mostra o sinal que sai do fone de ouvido do tablet ( i.stack .imgur.com / WAw6J.png ). Estou no processo de obter um shifter (de 1,8 para 3,3) e um analisador lógico, então talvez o shifter resolva isso. Verá!
Ttsiodras

Feito isso! BSS138 decodificou o sinal.
Ttsiodras 18/10/16

BSS138 tem um limiar Vgs mais baixo de 1.3V {0.8min, 1.5max} em vez de Vcc / 2 +/-? ou 2.5V +/-? então o limite mais baixo fez isso. Esta é a maneira 74HCTxx funciona tão bem aceitar sinais de 3.3V na lógica 5V
Tony Stewart Sunnyskyguy EE75

agora o que diabos é um estouro de Jiffies? uma caixa de buggy Linux? ou apenas latência normal de inicialização
Tony Stewart Sunnyskyguy EE75 18/06
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.