This isn't a troubleshooting question, it's purely to satisfy my curiosity...

MagTek makes a product called the uDynamo credit card reader that uses the audio channel on android devices as a communication bus to interface with the mobile devices. This makes perfect sense; you have a TRRS audio jack, supporting three channels (audio L, R, and mic) and a ground. Everything the uDynamo needs and more to facilitate full duplex communication.

However, one of my phones, the Android-sporting ZTE ZMAX PRO, with a functional TRRS headset jack, doesn't appear to ever succeed in synchronizing or handshaking with the device (there's a tester app that tries for a long time to get to step 2, then says 'test failed'). The app my company developed has the same problem. The PCM sync tone emitted from the android is excessively audible if I plug in headsets when running the test, and the microphone wire on the TRRS jack is functional. Interestingly, the card reader works on my other android phones. It appears that this particular phone simply is not supported.

So, my question is, why would some android phones be able to communicate over a TRRS headset jack while others can't? I mean, it's a PCM signal over standardized audio cables, it doesn't seem like much could be different from phone to phone.

Anyway, thank you in advance.

  • \$\begingroup\$ You sure the TRRS pinout is L-R-G-M for your device? \$\endgroup\$
    – Jeroen3
    Commented Jun 27, 2017 at 6:41
  • \$\begingroup\$ I'm fairly sure, see the comment thread on @DmitryGrigoryev 's answer below. \$\endgroup\$ Commented Jun 27, 2017 at 15:46
  • \$\begingroup\$ This could be any number of things, from excessive latency (historically a real problem on some Android devices), to a very severe buffer offset calculation bug in certain Android version's audio API code, to insufficient harvested power if the reader doesn't have it's own battery, to even something as simple as slight mechanical incompatibility with a perhaps now somewhat worn connector. \$\endgroup\$ Commented Jul 6, 2017 at 22:19

2 Answers 2


This may be due to CTIA (aka Nokia) vs OMTP (aka Apple) 3.5 mm jack standard that different phones use:

enter image description here

It's easy to check: if the handset of one phone doesn't work properly with the other (non functional microphone, very faint sound unless you push the MIC button), they most probably have GND and MIC contacts swapped.

  • 1
    \$\begingroup\$ This is a great line of inquiry. I tested the phone by making a call with an apple earbud-style headset, making sure the phone wasn't supplementing the receiver with it's own built-in one. It was audible on both ends. \$\endgroup\$ Commented Jun 27, 2017 at 15:04
  • \$\begingroup\$ @JamesM.Lay You other phones also work with Apple earbuds, right? \$\endgroup\$ Commented Jun 27, 2017 at 15:13
  • \$\begingroup\$ Yeah it appears so. Is that a good thing? \$\endgroup\$ Commented Jun 27, 2017 at 15:25
  • \$\begingroup\$ @JamesM.Lay No, it means I guessed wrong. Which is too bad, because the pinout would be very easy to fix, compared to noise cancellation or whatever else may be wrong. \$\endgroup\$ Commented Jun 27, 2017 at 15:34

perhaps it is the Active noise cancellation with dedicated mic.

Most Modems do EQ training for spectral and group delay distortion with 1 echo cancellation ( not 2 like the old DSP versions). But if more distorted than some specified amount, the modem will fail.

  • \$\begingroup\$ What's the point of echo cancellation when a handset is used? Most users plug the speakers in their ears (far away from the mic), not their mouth. \$\endgroup\$ Commented Jun 27, 2017 at 14:39
  • 1
    \$\begingroup\$ feedback is still possible from earbuds if loud and mic does not use echo cancellation. But echo cancellation must be stable or noise cancelling differential pressure. This one has Active noise cancellation, hence the pre-connect training EQ constants become wrong and perhaps why the card read modem fails. It also depends on the return loss or sidetone levels in full duplex modems. \$\endgroup\$ Commented Jun 27, 2017 at 14:53
  • \$\begingroup\$ @TonyStewart.EEsince'75 This is very plausible. Is there any way to test this? \$\endgroup\$ Commented Jun 27, 2017 at 15:08
  • \$\begingroup\$ Yes monitor the two way signals for group delay and sideband or crosstalk with a test set. It is easier to design a test set, if you learn how modems run pre-connect EQ tests. This helps understand the root cause of your failures. Then the solution needed will be obvious if possible. Sometimes this is done with "pre-compensation" \$\endgroup\$ Commented Jun 27, 2017 at 15:16
  • \$\begingroup\$ What's your spec? V.32bis: 14400/ 12000/ 7200 bps TCM?? K56Flex, V.90?? \$\endgroup\$ Commented Jun 27, 2017 at 15:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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