Bruit (lié à la capacité?) Dans le signal série

11

Les images du "résumé":

Le signal série semble foiré

Alimentation 3,3 V au micro, sonde TX de la tablette

Je veux décoder le signal série sortant de la prise casque de ma tablette. Il s'agit d'un "hack" quelque peu bizarre qui existe sur quelques téléphones et tablettes: en gros, si vous alimentez 3,3 V dans l'entrée microphone de votre prise TRRS, les canaux gauche et droit deviennent des TX / RX série.

J'ai utilisé un câble Raspberry PI TRRS-to-TV (comme vous pouvez le voir sur la 2ème photo) pour accéder aux 4 endroits dont j'avais besoin: GND, MIC, L, R. Le câble n'est pas censé faire autre chose que d'exposer les 3 signaux (MIC, L, R - couplés avec GND) dans les trois câbles correspondants (rouge, blanc, jaune).

J'ai utilisé les sondes de mon BitScope pour sonder entre le TX (extrémité du câble blanc sur la 2e photo) et le GND commun (sonde brune au bas de la 2e photo). J'ai également utilisé deux sondes (une rouge et une bleue) pour "alimenter" 3,3 V de ma puce USB / TTL (une PL2303HX branchée sur mon ordinateur portable) à la pointe MIC (rouge).

Lors du redémarrage de la tablette, j'ai en effet vu ce qui est incontestablement un signal série à 115200 (crête à crête de 8 à 9us), mais avec beaucoup de capacité (vidéo) .

Donc, ma question - avant d'aller en ligne et de commander une prise TRRS, des câbles et un fer à souder - est la capacité que je vois en raison de ...

  • le câble TRRS vers TV de 1 mètre de long, ou l'utilisation de sondes au lieu de câbles soudés

OU

  • les sondes et le câble ne peuvent en fait pas représenter autant de capacité, et la raison pour laquelle je vois cela est que la prise casque de la tablette n'a tout simplement pas été conçue pour émettre ce signal (c'est-à-dire que ce que je vois est en effet ce qui sort de la prise) .

Comme vous pouvez probablement le deviner, je suis très nouveau dans ce genre de choses; Je suis un gars du logiciel, j'ai acheté mon BitScope il y a une semaine et j'aimerais accéder à la série de ma tablette pour "du plaisir et du profit" (pirater des trucs de bootloader, compiler Cyanogenmod pour cela, etc.).

J'apprécierais une estimation approximative de savoir s'il s'agit d'une cause perdue (c'est-à-dire que les câbles ne peuvent pas expliquer autant de capacité) ou non.

Merci d'avance pour toute aide / suggestion.

ttsiodras
la source
1
Le signal me semble assez normal. Qu'est-ce qui vous déplaît? Votre câble RCA a probablement la capacité globale de 1000pF environ, donc il ne devrait pas être surprenant d'avoir des bords lents.
Ale..chenski
"Qu'est-ce qui vous déplaît" - les bords sont trop lents, je pense (mon PL2303HX - c'est-à-dire mon USB / TTL - n'a rien décodé).
ttsiodras
(1) assurez-vous que votre câble mesure moins de 3 mètres (10 pieds); (2) si vous pouvez obtenir juste la prise en tant que pièce sans câble, branchez-la sur la tablette et mesurez-la sans câble pour voir la "qualité" du signal; (3) vitesse de transmission juste inférieure.
Anonyme
@Anonymous - j'ai essayé; affiché mes résultats ci-dessous.
ttsiodras
1
@AliChen: Vous aviez raison, mec - j'ai utilisé un BSS138 et décodé le signal (voir l'addendum à ma réponse ci-dessous). Incroyable - ne m'attendais pas à cela.
ttsiodras

Réponses:

10

J'ai donc suivi les conseils des deux gentils qui ont commenté ... Voici les résultats.

  1. Ali Chen a indiqué que les bords lents peuvent être attribués à la capacité du câble RCA; et "Anonymous" a recommandé de fixer directement à la carte avec une prise sans fil. J'ai suivi leurs conseils, j'ai dépouillé la tablette pour exposer le PCB, j'ai branché une prise nue et l'ai sondée - mais les résultats étaient malheureusement les mêmes: des bords très lents et clairement capacitifs. Ce n'était pas les fils RCA - au lieu de cela, il semble que celui qui a conçu la tablette ne se souciait pas beaucoup du signal série sortant de la prise casque (probablement utilisé d'une autre manière pour interfacer avec la carte). J'ai essayé de sonder le PCB dans l'espoir de trouver un signal série plus propre, mais j'ai échoué.

  2. Anonymous a également recommandé de réduire le débit en bauds; malheureusement, il n'existe aucun moyen documenté d'influencer le processus de démarrage de ma tablette afin de configurer le débit en bauds utilisé lors du u-boot (ce qui m'intéressait) ...

Mais il est possible de le faire APRÈS le démarrage, à partir d'un shell ADB - puisque j'ai réussi à compiler mon propre noyau et à devenir root .

J'ai donc pu faire ça ...

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

Et en effet, le résultat est bien plus agréable:

Beaucoup mieux à 9600

Je suis sûr que ce signal peut être décodé correctement, si j'utilise un levier de vitesses (il est à 1,8 V, donc mon USB-TTL 3,3 V ne peut toujours pas le décoder).

Donc, pour conclure: le "port série de ma tablette à l'intérieur de la prise casque" ne peut vraiment être utilisé qu'une fois le démarrage terminé et l'UART ralenti à 9600 bauds; ce qui est regrettable, car la sortie série est la plus nécessaire pendant le processus de démarrage (si quelque chose échoue, c'est-à-dire) - et pendant ce temps, la vitesse UART est codée en dur dans le code de démarrage de ma tablette à 115200 bauds.

PS J'ai également essayé une suggestion d'un ami, d'utiliser un pull-up 3,3K vers le rail 3,3V dans le signal série envoyé par la prise casque - en vain.

MISE À JOUR, 3 jours plus tard

J'ai persévéré :-)

Suivant les conseils de Chris Stratton - qu'un bon levier de vitesses peut faire face même à ce type de signal - j'ai acheté un fer à souder, un BSS138, une planche à pain et un tas de câbles. Après ce qui est probablement le pire travail de soudage JAMAIS, j'ai réussi à souder les en-têtes de broches sur le BSS138, puis j'ai procédé à le fixer à la planche à pain et à créer ce désordre emmêlé:

La planche à pain et mon BSS138

Ce à quoi je ne m'attendais pas, c'est qu'après le lancement de minicom et l'émission d'un "redémarrage rapide", à ma grande stupéfaction, j'ai vu ceci:

Signal série décodé!

Incroyable - après que le BSS138 ait «élevé» le signal de 1,8 à 3,3 V, ce signal misérable et criblé de capacité peut en fait être décodé! Je peux enfin voir pourquoi ma tablette ne démarre pas.

Bonjour, petite tablette - JE VOUS POSSÈDE maintenant :-)

ttsiodras
la source
1
Bien qu'il soit très probable que le signal d'origine puisse être décodé avec un décalage de niveau bien conçu, il est également possible que la bande passante du circuit de sortie audio tel qu'il est expédié soit un peu inférieure à ce qui serait idéal pour ce signal numérique. Un produit de consommation doit passer des tests d'interférence émis, et l'amplificateur de casque lui-même est probablement une conception de commutation, donc il y aura probablement des filtres LC au bord de la carte pour supprimer les émissions, qui seraient conçus principalement pour transmettre l'audio, pas cela.
Chris Stratton du
Mais considérez également si votre portée de performances relativement faible ou les paramètres que vous utilisez avec elle peuvent déformer le signal - il serait bon pour la comparaison de regarder la sortie de votre pi ou d'un convertisseur série USB au même débit en bauds, et voir à quel point la portée donne cette apparence.
Chris Stratton
@ChrisStratton À propos des filtres d'interférence: aucune idée, mais cela semble plausible, si la fonctionnalité que j'ai découverte (série via la prise casque) n'était pas destinée à être utilisée. J'ai d'abord découvert cela en lisant sur les appareils Nexus - et curieux de savoir comment ma tablette réagirait, j'ai décidé de l'essayer. À propos de la vérification de ma portée: bien sûr, c'était la première chose que j'ai faite quand je l'ai achetée - montre des impulsions carrées cristallines à 115200 envoyées depuis la broche TX GPIO de mon Raspberry PI2. Je suis à peu près sûr à ce stade que ce n'est pas moi, ni ma portée - c'est le HW de la tablette.
ttsiodras
@ChrisStratton: "... pourrait être décodé avec un levier de niveau bien conçu" - avez-vous une puce spécifique en tête?
ttsiodras
@ChrisStratton: Victoire! BSS138 a décodé le signal - j'ai augmenté ma réponse et inclus la preuve :-) Merci de m'avoir pointé dans la bonne direction.
ttsiodras
0

Votre DSO a-t-il suffisamment de bande passante à 524 kps pour afficher même une onde carrée à un débit de 115,2 kbps? Je pense. juste FYI. Je peux me tromper.

Vous avez peut-être utilisé une résolution plus lente.

Tony Stewart Sunnyskyguy EE75
la source
Wow, pas d'amour pour le petit bonhomme! Poor BitScope :-) Sérieusement, cependant - les sondes BitScope affinent le 115200 bauds sortant de mon Raspberry PI, montrant des impulsions carrées claires et agréables ... rien de tel que ce qu'il montre pour le signal sortant de la prise casque de ma tablette ( i.stack .imgur.com / WAw6J.png ). Je suis en train d'obtenir un shifter (pour passer de 1,8 à 3,3) et un analyseur logique, alors peut-être que le shifter nettoiera cela. Verra!
ttsiodras
C'est fait! BSS138 a décodé le signal.
ttsiodras
BSS138 a un seuil Vgs inférieur de 1,3 V {0,8 min, 1,5 max} plutôt que Vcc / 2 +/-? ou 2,5 V +/-? donc le seuil inférieur l'a fait. C'est ainsi que 74HCTxx fonctionne aussi bien en acceptant des signaux 3,3 V sur une logique 5 V
Tony Stewart Sunnyskyguy EE75
maintenant que diable est un débordement Jiffies? une boîte Linux buggy? ou latence de démarrage normale
Tony Stewart Sunnyskyguy EE75