The "executive summary" pictures:

Serial signal seems messed up

Feeding 3.3V to mic, probing tablet's TX

I want to decode the serial signal coming out of my tablet's headphone jack. This is a somewhat weird "hack" that exists in a few phones and tablets: basically, if you feed 3.3V in the microphone input of your TRRS plug, the left and right channels become serial TX/RX.

I used a Raspberry PI TRRS-to-TV cable (as you can see in the 2nd picture) to get access to the 4 places I needed: GND, MIC, L, R. The cable is not supposed to do anything other than expose the 3 signals (MIC,L,R - paired with GND) in the three corresponding cables (red, white, yellow).

I used my BitScope's probes to probe between the TX (tip of white cable in 2nd picture) and the common GND (brown probe at the bottom of the 2nd picture). I also used two probes (red and blue one) to "feed" 3.3V from my USB/TTL chip (a PL2303HX plugged in my laptop) to the MIC (red) tip.

Upon rebooting the tablet, I indeed saw what is unmistakably a serial signal at 115200 (peak-to-peak of 8 to 9us), but with lots of capacitance (video).

So, my question - before I go online and order a TRRS plug, cables and a soldering iron - is the capacitance I am seeing due to...

  • the 1 meter long TRRS-to-TV cable, or the use of probes instead of soldered cables

OR

  • the probes and cable in fact cannot account for this much capacitance, and the reason I am seeing this is that the tablet's headphone jack simply wasn't designed to emit this signal (i.e. what I am seeing is indeed what comes out of the jack).

As you can probably guess, I am very new to this sort of thing; I am a software guy, bought my BitScope a week ago, and would love to access my tablet's serial for "fun and profit" (hacking bootloader stuff, compiling Cyanogenmod for it, etc).

I'd appreciate an estimated guess on whether this is a lost cause (i.e. the cables can't explain this much capacitance) or not.

Thanks in advance for any help/suggestions.

  • 1
    The signal looks pretty normal to me. What do you dislike in it? Your RCA cable probably has the bulk capacitance of 1000pF or so, so it should be no surprise to have slow edges. – Ale..chenski Oct 11 '16 at 5:18
  • "What do you dislike about it" - the edges are too slow, I think (my PL2303HX - i.e. my USB/TTL - did not decode anything). – ttsiodras Oct 11 '16 at 5:56
  • (1) ensure your cable is less than 3 meters (10 feet); (2) if you can obtain just jack as a part without cable, plug it into the tablet and measure on it without cable to see the "quality" of signal; (3) just lower baud rate. – Anonymous Oct 11 '16 at 8:35
  • @Anonymous - I tried; posted my results below. – ttsiodras Oct 15 '16 at 21:47
  • 1
    @AliChen: You were right, mate - I used a BSS138 and decoded the signal (see addendum to my answer below). Amazing - didn't expect this. – ttsiodras Oct 18 '16 at 18:56
up vote 10 down vote accepted

So, I followed the advice given by the two kind people that commented... Here are the results.

  1. Ali Chen indicated the slow edges can be attributed to the capacitance of the RCA cable; and "Anonymous" recommended attaching directly to the board with a jack with no wires. I followed their advice, stripped the tablet down to expose the PCB, plugged a naked jack and probed it - but the results were unfortunately the same: very slow, clearly-capacitance-driven edges. It wasn't the RCA wires - instead, it appears that whoever designed the tablet didn't care much for the serial signal coming out from the headphone jack (probably used some other way to interface with the board). I did try probing all over the PCB in hopes of finding a cleaner serial signal, but I failed.

  2. Anonymous also recommended lessening the baud rate; unfortunately, there is no documented way to influence the boot process of my tablet so as to configure the baud rate used during u-boot (which is what I was interested in)...

But it is possible to do so AFTER the boot is completed, from within an ADB shell - since I've managed to compile my own kernel and become root.

So I was able to do this...

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

And indeed, the result is much nicer:

Much better at 9600

I am pretty sure this signal can be decoded fine, if I use a shifter (it's at 1.8V, so my 3.3V USB-TTL still can't decode it).

So, to conclude: my tablet's "serial port inside the headphone jack" can only really be used AFTER the boot is completed, and the UART slowed down to 9600 baud; which is unfortunate, since the serial output is needed most during the boot process (if something fails, that is) - and during that time, the UART speed is hardcoded in my tablet's boot code at 115200 baud.

P.S. I also tried a suggestion from a friend, to use a 3.3K pull-up towards the 3.3V rail in the serial signal sent out by the headphone jack - to no avail.

UPDATE, 3 days later

I persevered :-)

Following the advice from Chris Stratton - that a good shifter can cope even with this kind of signal - I bought a soldering iron, a BSS138, a breadboard and a bunch of cables. After what is probably the worst soldering job EVER, I managed to solder the pin headers on the BSS138, and then proceeded to attach it to the breadboard, and create this tangled mess:

The breadboard and my BSS138

What I didn't expect, was that after spawning minicom and issuing a "fastboot reboot", to my utter amazement, I saw this:

Serial signal decoded!

Unbelievable - after BSS138 "lifts" the signal from 1.8 up to 3.3V, that miserable, capacitance-riddled signal can actually be decoded! I can finally see why my tablet isn't booting.

Hello, little tablet - I OWN you now :-)

  • 1
    While it is quite likely that the original signal could be decoded with a well designed level shifter, it is also possible that the bandwidth of the audio output circuit as shipped is quite a bit less than would be ideal for this digital signal. A consumer product needs to pass emitted interference tests, and the headphone amplifier itself is probably a switching design, so there will likely be LC filters at the board edge to suppress emissions, that would be designed primarily to pass audio, not this. – Chris Stratton Oct 15 '16 at 21:50
  • But also consider if your relatively low performance scope or the settings you are using with it might be misrepresenting the signal - it would be good for comparison to look at the output of your pi or a USB serial converter at the same baud rate, and see how square the scope makes that look. – Chris Stratton Oct 15 '16 at 21:51
  • @ChrisStratton About interference filters: no idea, but sounds plausible, if the feature I uncovered (serial via headphone jack) wasn't meant to be used. I initially found out about this while reading about Nexus devices - and being curious about how my tablet would respond, decided to try it. About checking my scope: of course, that was the first thing I did when I bought it - shows crystal clear square pulses at 115200 sent from my Raspberry PI2's TX GPIO pin. I am pretty sure at this point that it's not me, nor my scope - it's the tablet's HW. – ttsiodras Oct 16 '16 at 8:42
  • @ChrisStratton: "...could be decoded with a well designed level shifter" - do you have any specific chip in mind? – ttsiodras Oct 16 '16 at 8:48
  • @ChrisStratton: Victory! BSS138 decoded the signal - I augmented my answer and included proof :-) Thanks for pointing me in the right direction. – ttsiodras Oct 18 '16 at 18:55

Does your DSO have enough bandwidth @524ksps to even show a square wave at 115.2kbps data rate? I do think so. just FYI. I could be wrong.

Maybe you used a slower resolution.

  • Wow, no love for the little guy! Poor BitScope :-) Seriously, though - BitScope probes fine the 115200 baud coming out of my Raspberry PI, showing nice and clear square pulses... nothing like what it shows for the signal coming out of my tablet's headphone jack (i.stack.imgur.com/WAw6J.png). I am in the process of getting a shifter (to go from 1.8 to 3.3) and a logic analyzer, so maybe the shifter will clean this up. Will see! – ttsiodras Oct 18 '16 at 12:54
  • Made it! BSS138 decoded the signal. – ttsiodras Oct 18 '16 at 18:56
  • BSS138 has a lower Vgs threshold of 1.3V {0.8min,1.5max} rather than Vcc/2 +/-? or 2.5V +/-? so the lower threshold did it. This is the way 74HCTxx works as well accepting 3.3V signals on 5V logic – Tony EE rocketscientist Oct 18 '16 at 19:11
  • now what the heck is a Jiffies overflow? a buggy Linux box? or just normal boot latency – Tony EE rocketscientist Oct 18 '16 at 19:27

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.