Re: Android Headset specification

Den Sun, 20 Jan 2019 13:06:19 +0200 skrev Marko Mäkelä
<msmakela@gmail.com>:
> On Fri, Jan 18, 2019 at 01:07:43PM +0000, smf wrote:
> >On 18/01/2019 07:15, Marko Mäkelä wrote:
> >>It could be somewhat of a challenge to implement bidirectional 
> >>transfer. If the interface were to play nice (and emulate the
> >>loading of tapes), then it would have to connect not only CASS READ
> >>but also CASS SENSE and CASS MOTOR. With that you would already
> >>have exhausted the 2 outputs and 1 input that are available in a
> >>TRRS connector (stereo headphones and microphone). Something
> >>magical would be needed to additionally connect CASS WRITE.
> >
> >You could do it like the hands free kits where the answer buttons
> >use in band signalling.
> >
> >So something like hookup cass write to the mic input when the motor
> >is running & have some signal level that is used to tell the device
> >that the motor is stopped.
> 
> I dug up the relevant information:
> https://source.android.com/devices/accessories/headset/jack-headset-spec
> https://source.android.com/devices/accessories/headset/plug-headset-spec
> 
> I learned that the two wiring standards for 3.5mm TRRS connectors are 
> not tied to specific manufacturers but to time. The OMTP pinout order 
> (tip,ring,ring,sleeve: left,right,microphone,ground) was used by
> Nokia and also by my 2011 SonyEricsson Xperia Active. My current
> Samsung Galaxy J5 follows the CTIA or AHJ wiring, where the
> microphone and ground are swapped.

Side track: Sony Ericsson Vivaz U5 (or whatever it was called), a
Symbian phone, could also use the "microphone ring" as a composite
video output.

I think that that older pinout were inherited from compatibility with
then existing cables, for example for a digital camera to be able to
play back video with stereo audio or similar.

I assume that the common pinout did change partially because Apple
wanted to do something in another way than what everyone else were
already doing (compare the USB charger problems they introduced), and
partially to reduce crosstalk between mic and headphones.

> It turns out that the Android signaling employs a resistor divider
> with the phantom power that is fed to the mono microphone. The
> primary button would directly short the microphone line to ground.
> Other buttons would use resistors. In any case, it would seem that
> any audio signal from the microphone needs to be muted while these
> buttons are being pressed (to get rid of 'pop' sounds when the DC
> level abruptly changes).

I assume that signal processing in the Android device takes care of
removing DC pop sounds.

Is there any use case of reading CASS WRITE while CASS MOTOR is
inactive? I assume not. That would make it easy, just ground the
microphone pin if MOTOR isn't on.
 
> One thing that could be done is to tie the microphone line to ground 
> (optionally via a resistor) when the CASS MOTOR signal is not active, 
> and otherwise allow the DC level on the microphone line to remain.
> 
> So, it would be like this:
> 
> tip (left audio): CASS READ
> ring (right audio): CASS SENSE
> 2nd ring: ground
> sleeve: CASS MOTOR and CASS WRITE
> 
> For CASS SENSE, I think that the easiest might be to use a bridge 
> rectifier and a bandpass filter. That is, if a specific 'pilot tone'
> is present, activate the line. The 'datasette app' would generate
> this pilot tone whenever the emulated PLAY or RECORD+PLAY buttons are 
> pressed.

Is there even any need for a band pass filter? 

> >You may be able to do cass sense in a similar way, rather than 
> >dedicating one ear to cass read and the other to cass sense.
> 
> I do not think that there is any digital signaling in that direction.
> 
> Furthermore, given that the 3.5" plug seems to be facing extinction
> on phones, developing such a product could be a dead end. It might be 
> easier to develop a Bluetooth device that would be powered from the 
> cassette port. Some system-on-chip like this would have more than
> enough power for the task (also for emulating a disk drive):
> https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52832
> 
> I might prefer a little more powerful system-on-chip that runs
> GNU/Linux and could be used as a 'modern desktop machine' next to the
> 8-bit Commodore (or as a gateway to an even more powerful machine).
> It is a pity that the Raspberry Pi does not have any I/O processor;
> it could be hard to get stable timing for doing bit-banging over its
> GPIO pins.
> 
> 	Marko
> 



-- 
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.