Rauschen (kapazitätsbezogen?) Im seriellen Signal


11

Die "Executive Summary" Bilder:

Das serielle Signal scheint durcheinander zu sein

Einspeisen von 3,3 V in das Mikrofon, Prüfen des TX des Tablets

Ich möchte das serielle Signal aus der Kopfhörerbuchse meines Tablets dekodieren. Dies ist ein etwas seltsamer "Hack", der in einigen Handys und Tablets vorkommt: Wenn Sie 3,3 V in den Mikrofoneingang Ihres TRRS-Steckers einspeisen, werden der linke und der rechte Kanal zu seriellem TX / RX.

Ich habe ein Raspberry PI TRRS-zu-TV-Kabel verwendet (wie Sie im zweiten Bild sehen können), um Zugang zu den 4 Stellen zu erhalten, die ich brauchte: GND, MIC, L, R. Das Kabel darf nichts anderes als Belichten die 3 Signale (MIC, L, R - gepaart mit GND) in den drei entsprechenden Kabeln (rot, weiß, gelb).

Ich habe die Sonden meines BitScope verwendet, um zwischen dem TX (Spitze des weißen Kabels im 2. Bild) und dem gemeinsamen GND (braune Sonde am unteren Rand des 2. Bildes) zu prüfen. Ich habe auch zwei Sonden (rote und blaue) verwendet, um 3,3 V von meinem USB / TTL-Chip (ein an meinen Laptop angeschlossener PL2303HX) an die MIC-Spitze (rot) zu "speisen".

Beim Neustart des Tablets sah ich zwar ein unverkennbares serielles Signal bei 115200 (Spitze-Spitze von 8 bis 9us), aber mit viel Kapazität (Video) .

Meine Frage - bevor ich online gehe und einen TRRS-Stecker, Kabel und einen Lötkolben bestelle - ist die Kapazität, die ich aufgrund von ...

  • das 1 Meter lange TRRS-zu-TV-Kabel oder die Verwendung von Sonden anstelle von gelöteten Kabeln

ODER

  • Die Sonden und das Kabel können tatsächlich nicht so viel Kapazität ausmachen, und der Grund, warum ich das sehe, ist, dass die Kopfhörerbuchse des Tablets einfach nicht dafür ausgelegt ist, dieses Signal zu senden (dh was ich sehe, ist tatsächlich das, was aus der Buchse kommt). .

Wie Sie wahrscheinlich erraten können, bin ich für solche Dinge sehr neu. Ich bin ein Software-Typ, habe mein BitScope vor einer Woche gekauft und würde gerne auf die Seriennummer meines Tablets zugreifen, um "Spaß und Gewinn" zu erzielen (Bootloader-Sachen hacken, Cyanogenmod dafür kompilieren usw.).

Ich würde mich über eine geschätzte Vermutung freuen, ob dies eine verlorene Ursache ist (dh die Kabel können nicht so viel Kapazität erklären) oder nicht.

Vielen Dank im Voraus für jede Hilfe / Vorschläge.


1
Das Signal sieht für mich ziemlich normal aus. Was magst du daran nicht? Ihr Cinch-Kabel hat wahrscheinlich eine Volumenkapazität von etwa 1000 pF, daher sollte es keine Überraschung sein, langsame Kanten zu haben.
Ale..chenski

"Was magst du daran nicht?" - die Kanten sind meiner Meinung nach zu langsam (mein PL2303HX - dh mein USB / TTL - hat nichts dekodiert).
Ttsiodras

(1) Stellen Sie sicher, dass Ihr Kabel weniger als 3 Meter lang ist. (2) Wenn Sie nur eine Buchse als Teil ohne Kabel erhalten können, schließen Sie sie an das Tablet an und messen Sie ohne Kabel daran, um die "Qualität" des Signals zu sehen. (3) nur niedrigere Baudrate.
Anonym

@ Anonym - Ich habe es versucht; habe meine Ergebnisse unten gepostet.
Ttsiodras

1
@AliChen: Du hattest Recht, Kumpel - ich habe ein BSS138 verwendet und das Signal dekodiert (siehe Anhang zu meiner Antwort unten). Erstaunlich - habe das nicht erwartet.
Ttsiodras

Antworten:


10

Also folgte ich dem Rat der beiden freundlichen Leute, die kommentierten ... Hier sind die Ergebnisse.

  1. Ali Chen gab an, dass die langsamen Flanken auf die Kapazität des Cinch-Kabels zurückzuführen sind. und "Anonymous" empfahlen, mit einer Buchse ohne Kabel direkt an der Platine zu befestigen. Ich folgte ihrem Rat, zog das Tablet aus, um die Leiterplatte freizulegen, steckte eine nackte Buchse ein und untersuchte sie - aber die Ergebnisse waren leider die gleichen: sehr langsame, klar kapazitätsgesteuerte Kanten. Es waren nicht die Cinch-Kabel - stattdessen scheint es, dass derjenige, der das Tablet entworfen hat, das serielle Signal, das von der Kopfhörerbuchse ausgeht, nicht sonderlich interessiert hat (wahrscheinlich wurde eine andere Art der Schnittstelle zur Platine verwendet). Ich habe versucht, die gesamte Leiterplatte zu untersuchen, in der Hoffnung, ein saubereres serielles Signal zu finden, aber ich bin gescheitert.

  2. Anonymous empfahl auch, die Baudrate zu verringern. Leider gibt es keine dokumentierte Möglichkeit, den Startvorgang meines Tablets zu beeinflussen, um die beim U-Boot verwendete Baudrate zu konfigurieren (woran ich interessiert war) ...

Es ist jedoch möglich, dies nach Abschluss des Startvorgangs innerhalb einer ADB-Shell zu tun - da ich es geschafft habe , meinen eigenen Kernel zu kompilieren und root zu werden .

Also konnte ich das machen ...

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

Und tatsächlich ist das Ergebnis viel schöner:

Viel besser bei 9600

Ich bin mir ziemlich sicher, dass dieses Signal gut dekodiert werden kann, wenn ich einen Shifter verwende (es liegt bei 1,8 V, sodass meine 3,3 V USB-TTL es immer noch nicht dekodieren kann).

Fazit: Der "serielle Anschluss meines Tablets in der Kopfhörerbuchse" kann erst wirklich verwendet werden, nachdem der Startvorgang abgeschlossen ist und der UART auf 9600 Baud verlangsamt wurde. Das ist bedauerlich, da die serielle Ausgabe während des Startvorgangs am meisten benötigt wird (wenn etwas fehlschlägt) - und während dieser Zeit ist die UART-Geschwindigkeit im Startcode meines Tablets mit 115200 Baud fest codiert.

PS Ich habe auch einen Vorschlag eines Freundes versucht, in dem von der Kopfhörerbuchse gesendeten seriellen Signal ein 3,3-K-Pull-up in Richtung der 3,3-V-Schiene zu verwenden - ohne Erfolg.

UPDATE 3 Tage später

Ich habe durchgehalten :-)

Auf den Rat von Chris Stratton hin, dass ein guter Schalthebel auch mit dieser Art von Signal umgehen kann, kaufte ich einen Lötkolben, einen BSS138, ein Steckbrett und ein paar Kabel. Nach dem wahrscheinlich schlimmsten Lötjob aller Zeiten gelang es mir, die Stiftleisten auf dem BSS138 zu löten, sie dann am Steckbrett zu befestigen und dieses Wirrwarr zu verursachen:

Das Steckbrett und mein BSS138

Was ich nicht erwartet hatte, war, dass ich nach dem Laichen von Minicom und dem Ausführen eines "Fastboot-Neustarts" zu meinem größten Erstaunen Folgendes sah:

Serielles Signal dekodiert!

Unglaublich - nachdem BSS138 das Signal von 1,8 auf 3,3 V "angehoben" hat, kann dieses miserable, kapazitätsgeplagte Signal tatsächlich dekodiert werden! Ich kann endlich sehen, warum mein Tablet nicht bootet.

Hallo, kleines Tablet - ich besitze dich jetzt :-)


1
Zwar ist es sehr wahrscheinlich ist , dass das ursprüngliche Signal mit einem gut gestalteten Level - Shifter decodiert werden kann, ist es auch möglich , dass die Bandbreite der Audio-Ausgangsschaltung im Auslieferungszustand ist ein bisschen weniger als ideal für dieses digitale Signal sein würde. Ein Verbraucherprodukt muss emittierte Interferenztests bestehen, und der Kopfhörerverstärker selbst ist wahrscheinlich ein Schaltdesign. Daher befinden sich wahrscheinlich LC-Filter am Rand der Platine, um Emissionen zu unterdrücken, die in erster Linie für die Weitergabe von Audio ausgelegt sind, nicht für diese.
Chris Stratton

Bedenken Sie jedoch auch, ob Ihr relativ geringer Leistungsumfang oder die Einstellungen, die Sie damit verwenden, das Signal möglicherweise falsch darstellen. Zum Vergleich ist es gut, den Ausgang Ihres pi oder eines seriellen USB-Konverters mit derselben Baudrate zu betrachten und zu sehen wie quadratisch das Zielfernrohr das aussehen lässt.
Chris Stratton

@ChrisStratton Über Interferenzfilter: Keine Ahnung, klingt aber plausibel, wenn die von mir entdeckte Funktion (seriell über Kopfhörerbuchse) nicht verwendet werden sollte. Ich habe dies zunächst erfahren, als ich über Nexus-Geräte gelesen habe - und war neugierig, wie mein Tablet reagieren würde, und habe beschlossen, es auszuprobieren. Informationen zur Überprüfung meines Oszilloskops: Das war natürlich das erste, was ich beim Kauf getan habe - zeigt kristallklare Rechteckimpulse bei 115200, die vom TX GPIO-Pin meines Raspberry PI2 gesendet wurden. Ich bin mir zu diesem Zeitpunkt ziemlich sicher, dass es weder ich noch mein Zielfernrohr sind - es ist die HW des Tablets.
Ttsiodras

@ChrisStratton: "... könnte mit einem gut gestalteten Level-Shifter dekodiert werden" - haben Sie einen bestimmten Chip im Sinn?
Ttsiodras

@ ChrisStratton: Sieg! BSS138 hat das Signal dekodiert - ich habe meine Antwort erweitert und einen Beweis beigefügt :-) Danke, dass Sie mich in die richtige Richtung gelenkt haben.
Ttsiodras

0

Hat Ihr DSO genug Bandbreite bei 524 kbit / s, um sogar eine Rechteckwelle mit einer Datenrate von 115,2 kbit / s anzuzeigen? Ich glaube schon. Nur zu deiner Information. Ich könnte falsch liegen.

Vielleicht haben Sie eine langsamere Auflösung verwendet.


Wow, keine Liebe für den kleinen Kerl! Schlechtes BitScope :-) Im Ernst - BitScope prüft die 115200 Baud, die aus meinem Raspberry PI kommt, und zeigt schöne und klare Rechteckimpulse ... nichts Vergleichbares für das Signal, das aus der Kopfhörerbuchse meines Tablets kommt ( i.stack) .imgur.com / WAw6J.png ). Ich bin gerade dabei, einen Shifter (von 1,8 auf 3,3) und einen Logikanalysator zu bekommen, also wird der Shifter dies vielleicht bereinigen. Werden sehen!
Ttsiodras

Machte es! BSS138 decodierte das Signal.
Ttsiodras

BSS138 hat eine niedrigere Vgs-Schwelle von 1,3 V {0,8 min, 1,5 max} anstelle von Vcc / 2 +/-? oder 2,5 V +/-? also tat es die untere Schwelle. Auf diese Weise funktioniert 74HCTxx auch und akzeptiert 3,3-V-Signale auf 5-V-Logik
Tony Stewart Sunnyskyguy EE75

Was zum Teufel ist nun ein Jiffies-Überlauf? eine fehlerhafte Linux-Box? oder nur normale Boot-Latenz
Tony Stewart Sunnyskyguy EE75
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.