Pogo Connector Pin-out

Search This thread

8008Hacker

Member
Dec 1, 2012
33
14
Sunny San Diego
Hi. I've followed the Pogo Charger thread looking for pin-out info on the Nexus 10 pogo connector. No posts on the actual pin-out. I did learn about the 'polimeter', but I digress.

I've done some probing around and have some preliminary info on the connector to share. I used a Fluke 189 dvm and a Tektronix 2252 scope.

First order is to identify pin 1. I'm assuming that when viewing the connector with the screen up, pin 1 is on the left.

Pins 1 and 6 are ground. Zero resistance between the two.

Pin 2 is a control pin. Open circuit voltage is 1.12 V. If you pull it down with a 1.5K ohm (minimum) resistor momentarily and let it go up, the Nexus 10 powers on. (Discovering that was good for excitement ...) Once powered on, if you pull it down again, Nexus goes into clock mode. Obviously meant for a dock. Don't know if this pin does other tricks. Note that the picture of the pogo charger connector shows pin 2 missing.

No clues about pins 3-5. One is obviously +5 for charging. But I'm not ready to apply power to unknown pins yet. Seems to me that since there's a charger floating around, it would be better to wait for someone to check out its pins.

Pins 3-5 are near ground level. No pull-ups, clocks, etc.

I had no luck finding audio on any of the pins. There might be a control function that mutes the Nexus speakers and enables audio. Or it might happen when you supply charging power.

I hope that there are some brave souls out there that could help identify more pins. The charger is the most important because it might enable other pins.

Murray
 

alias_neo

Senior Member
Jun 9, 2006
2,081
205
London
Usually, with these SOCs, varying resistances between the control pin and ground can cause you to enter various modes, such as download mode on other Samsung devices, along with countless other modes, dock, speaker dock, etc.

If we could get some ultra high resolution teardown photos, I could work out the charging pins.

My pins should be here in a couple of weeks too, so I can start making my pogo charger.

Sent from my GT-I9300 using Tapatalk 2
 

8008Hacker

Member
Dec 1, 2012
33
14
Sunny San Diego
The hi-res photo is a good idea, but I don't think it's going work here. Take a look at the logic board in the teardown at

www dot powerbookmedic dot com/wordpress/2012/11/16/google-nexus-10-take-apart-first-look.

(Sorry, but the site isn't letting me insert a proper URL because I'm a new guy ...)

The dock cable connector is the one on the lower right diagonal from the SoC. Judging from the size of the passive components, it looks like the power management circuit is above the connector just to the right of the processor. Here's the problem: the top of the board has a power/ground plane that hides all of the traces from the connector.
 

8008Hacker

Member
Dec 1, 2012
33
14
Sunny San Diego
Usually, with these SOCs, varying resistances between the control pin and ground can cause you to enter various modes, such as download mode on other Samsung devices, along with countless other modes, dock, speaker dock, etc.

If we could get some ultra high resolution teardown photos, I could work out the charging pins.

My pins should be here in a couple of weeks too, so I can start making my pogo charger.

alias_neo - Any progress on the pin out or your pogo charger?
 

tpayne1

Senior Member
Oct 6, 2007
99
7
Friday not, haven't been home much, working late to finish up before Christmas, so by the time I been getting home I'm collapsed.

Will probably get started and finished with it over Christmas holiday.

Sent from my GT-I9300 using Tapatalk 2

I'll have mine by then and I plan on ripping it apart the day I get it and figuring out the proper pins for charging...
 

alias_neo

Senior Member
Jun 9, 2006
2,081
205
London
I'll have mine by then and I plan on ripping it apart the day I get it and figuring out the proper pins for charging...

Just as importantly, see what the ID pin is connected to (if anything?) and which two pins are connected for data (which, since it has 5 pins, I assume it does data too).
 

tpayne1

Senior Member
Oct 6, 2007
99
7
according to this site 2 pins are for data transfer and 2 pins are for audio (left and right).

Apparently you haven't read anything in this thread, which completely nullifies that speculation page completely.

3 pins are already known...that leaves 3....we have 1 for power...that leaves 2....can't have data AND audio...
 

BuGGr

Member
May 13, 2011
17
2
I did, but I forgot about the dock pin. maybe some pins have a multi purpose of some sort.
a spec sheet from samsung would be ideal but I guess that will never happen.
 

8008Hacker

Member
Dec 1, 2012
33
14
Sunny San Diego
After not seeing any interesting signals on the pogo pins a few weeks ago, I decided to look at the software. The kernel file ".../arch/arm/mach-exynos/board-manta-pogo.c" gives a lot of clues about the pogo connector. This post has some of my initial findings. I have to preface this rather long post by saying that although I've done embedded h/w and s/w for decades, I've never done an embedded Linux system and my knowledge of the Exynos gpio came from a few hours with the 911 page Exynos 4412 User's Manual. Please feel free to critique/correct anything said here.

The good news is that the code defines much of what the dock can do. It is more complex than I would have thought. Obviously the code doesn't define how the gpio connects to the pogo pins. Looks like some may connect directly, but others go through external logic, like the audio MUX mentioned below.

Here is an overview of the dock interface:

- The dock circuitry triggers an interrupt during docking/undocking. The interrupt triggers software debouncing of a gpio input to determine the dock state: UNDOCKED, UNSTABLE, DOCKED.

- I couldn't find an ADC input. This means that its unlikely that an external resistor can set various doc states based its value as others have postulated.
- The N10 uses one pin for a bi-directional data interface. It uses a non-standard protocol that bit-bangs MFM-encoded short command-response messages. When the dock is "acquired" (i.e., connected with stable signals), it sends an ID address and DOCK_VERSION constants. This probably tells the dock which features are supported by the device. Looks like the N10 can tell if its a Samsung dock based on the response message. Haven't followed the trail to find out other command functions.

- The audio interface is SPDIF, not analog or USB as others have predicted. Makes good sense as SPDIF requires only one pin. The reason that I didn't see SPDIF when I scoped the pogo pins is that the audio gets turned on and off. One other wrinkle: the audio pin is being multiplexed with another function. The mux logic looks like it's external to the cpu.

- The code sets the power status to one of four states: NONE, 500MA, 1A, and 2A.

- The code has several interfaces to the USB interface. For example, it controls power to the vbus line.
Suggests that it might support OTG on the dock.

Based on this, here is a SWAG on what the pin-out might be. We know we've got 2 ground and 1 charging pin. Let's assume that pin 2 is the interrupt pin. The two remaining pins might be multiplexed: in one state, the pins are the proprietary command interface and the SPDIF out; in the other state they are the USB d pins.

I'll continue reading the code to refine what I've seen. It would be great if some of the kernel devs could jump in and confirm some of this. I'm not comfortable in this environment yet. If I were, I'd be running the code under the debugger to see what happens when pin 2 is stimulated. ;)

To me the data interface is the most exciting. The protocol should be hackable to extend the command set for use with custom docks. Want the docked N10 to turn on the table lamp when the alarm goes off? No problem. I'm sure that there are lots of ways that this could be used. Open source docks maybe?
 
Last edited:

dalingrin

Inactive Recognized Developer
Nov 6, 2007
1,433
2,756
After not seeing any interesting signals on the pogo pins a few weeks ago, I decided to look at the software. The kernel file ".../arch/arm/mach-exynos/board-manta-pogo.c" gives a lot of clues about the pogo connector. This post has some of my initial findings. I have to preface this rather long post by saying that although I've done embedded h/w and s/w for decades, I've never done an embedded Linux system and my knowledge of the Exynos gpio came from a few hours with the 911 page Exynos 4412 User's Manual. Please feel free to critique/correct anything said here.

The good news is that the code defines much of what the dock can do. It is more complex than I would have thought. Obviously the code doesn't define how the gpio connects to the pogo pins. Looks like some may connect directly, but others go through external logic, like the audio MUX mentioned below.

Here is an overview of the dock interface:

- The dock circuitry triggers an interrupt during docking/undocking. The interrupt triggers software debouncing of a gpio input to determine the dock state: UNDOCKED, UNSTABLE, DOCKED.

- I couldn't find an ADC input. This means that its unlikely that an external resistor can set various doc states based its value as others have postulated.
- The N10 uses one pin for a bi-directional data interface. It uses a non-standard protocol that bit-bangs MFM-encoded short command-response messages. When the dock is "acquired" (i.e., connected with stable signals), it sends an ID address and DOCK_VERSION constants. This probably tells the dock which features are supported by the device. Looks like the N10 can tell if its a Samsung dock based on the response message. Haven't followed the trail to find out other command functions.

- The audio interface is SPDIF, not analog or USB as others have predicted. Makes good sense as SPDIF requires only one pin. The reason that I didn't see SPDIF when I scoped the pogo pins is that the audio gets turned on and off. One other wrinkle: the audio pin is being multiplexed with another function. The mux logic looks like it's external to the cpu.

- The code sets the power status to one of four states: NONE, 500MA, 1A, and 2A.

- The code has several interfaces to the USB interface. For example, it controls power to the vbus line.
Suggests that it might support OTG on the dock.

Based on this, here is a SWAG on what the pin-out might be. We know we've got 2 ground and 1 charging pin. Let's assume that pin 2 is the interrupt pin. The two remaining pins might be multiplexed: in one state, the pins are the proprietary command interface and the SPDIF out; in the other state they are the USB d pins.

I'll continue reading the code to refine what I've seen. It would be great if some of the kernel devs could jump in and confirm some of this. I'm not comfortable in this environment yet. If I were, I'd be running the code under the debugger to see what happens when pin 2 is stimulated. ;)

To me the data interface is the most exciting. The protocol should be hackable to extend the command set for use with custom docks. Want the docked N10 to turn on the table lamp when the alarm goes off? No problem. I'm sure that there are lots of ways that this could be used. Open source docks maybe?

I've also been looking through the kernel today and my findings were the same.
Looks to me like the pogo can do USB data, SPDIF, and/or power for charging.
 
  • Like
Reactions: 8008Hacker

SiliconS

Senior Member
Jun 13, 2004
735
9
I love this thread. This sort of intelligent, collaborative discussion is what these forums used to contain back in the good old days (when all of this were fields etc.). I'm fascinated to learn how you guys are able to probe and deconstruct the software and hardware to discover the inner workings of these amazing machines. :)
 
I couldn't find an ADC input. This means that its unlikely that an external resistor can set various doc states based its value as others have postulated.

It's possible dock state is triggered using binary pulses. I seem to remember the Nexus One dock used this method. The N1 docks also had audio out jacks which actually connected to the phone using a private bluetooth pairing.

We know we've got 2 ground and 1 charging pin. Let's assume that pin 2 is the interrupt pin

I was looking through the documentation on the Atmel ATtiny series microprocessors Here, specifically, the amount of functions available on each pin. Is it possible that one of the ground pins is actually the interrupt pin and is currently pulled low until a voltage is present on the vcc pin?

Keep up the good work:)
 

8008Hacker

Member
Dec 1, 2012
33
14
Sunny San Diego
It's possible dock state is triggered using binary pulses. I seem to remember the Nexus One dock used this method.

It does. The dock code maintains several states. Docked, power state, audio state, usb state, etc. Some of them are affected by the command/response channel I mentioned. This channel uses binary pulses on the pogo connector.

The N1 docks also had audio out jacks which actually connected to the phone using a private bluetooth pairing..
The N10 uses SPDIF, a well-known protocol for transmitting CD-quality audio in stereo or 5.1 surround sound. Good choice by Sammy, imho

I was looking through the documentation on the Atmel ATtiny series microprocessors Here, specifically, the amount of functions available on each pin...
I'm a real fan of the Atmel AT devices and have done a lot of projects with them. The Exynos has even more options on its I/O pins. Take a look at the manual.

Is it possible that one of the ground pins is actually the interrupt pin and is currently pulled low until a voltage is present on the vcc pin?..

Don't think so. There's zero resistance between them. Having two grounds is actually a safety feature. Note that the grounds are on both ends of the connectors. This ensures that one of the grounds connects first before other signals no matter how the device is mechanically skewed as it docks. Prevents ESD (electro-static damage) to the interface.
 

jerryp7

Senior Member
Feb 20, 2011
408
56
Front Royal, VA
I'm all for open source and reverse engineering but doesn't it seem like this is something that Nexus could just make a diagram available for? I don't get why this is something the community if left to figure out.
 

alias_neo

Senior Member
Jun 9, 2006
2,081
205
London
I'm all for open source and reverse engineering but doesn't it seem like this is something that Nexus could just make a diagram available for? I don't get why this is something the community if left to figure out.

Well,

The pogo technology as with the rest of the hardware in the nexus devices isn't open hardware, it's proprietary for someone, they probably don't want to share it except with licensed partners making hardware.

Sent from my GT-I9300 using Tapatalk 2
 
  • Like
Reactions: jerryp7

Top Liked Posts

  • There are no posts matching your filters.
  • 5
    Hi. I've followed the Pogo Charger thread looking for pin-out info on the Nexus 10 pogo connector. No posts on the actual pin-out. I did learn about the 'polimeter', but I digress.

    I've done some probing around and have some preliminary info on the connector to share. I used a Fluke 189 dvm and a Tektronix 2252 scope.

    First order is to identify pin 1. I'm assuming that when viewing the connector with the screen up, pin 1 is on the left.

    Pins 1 and 6 are ground. Zero resistance between the two.

    Pin 2 is a control pin. Open circuit voltage is 1.12 V. If you pull it down with a 1.5K ohm (minimum) resistor momentarily and let it go up, the Nexus 10 powers on. (Discovering that was good for excitement ...) Once powered on, if you pull it down again, Nexus goes into clock mode. Obviously meant for a dock. Don't know if this pin does other tricks. Note that the picture of the pogo charger connector shows pin 2 missing.

    No clues about pins 3-5. One is obviously +5 for charging. But I'm not ready to apply power to unknown pins yet. Seems to me that since there's a charger floating around, it would be better to wait for someone to check out its pins.

    Pins 3-5 are near ground level. No pull-ups, clocks, etc.

    I had no luck finding audio on any of the pins. There might be a control function that mutes the Nexus speakers and enables audio. Or it might happen when you supply charging power.

    I hope that there are some brave souls out there that could help identify more pins. The charger is the most important because it might enable other pins.

    Murray
    4
    After not seeing any interesting signals on the pogo pins a few weeks ago, I decided to look at the software. The kernel file ".../arch/arm/mach-exynos/board-manta-pogo.c" gives a lot of clues about the pogo connector. This post has some of my initial findings. I have to preface this rather long post by saying that although I've done embedded h/w and s/w for decades, I've never done an embedded Linux system and my knowledge of the Exynos gpio came from a few hours with the 911 page Exynos 4412 User's Manual. Please feel free to critique/correct anything said here.

    The good news is that the code defines much of what the dock can do. It is more complex than I would have thought. Obviously the code doesn't define how the gpio connects to the pogo pins. Looks like some may connect directly, but others go through external logic, like the audio MUX mentioned below.

    Here is an overview of the dock interface:

    - The dock circuitry triggers an interrupt during docking/undocking. The interrupt triggers software debouncing of a gpio input to determine the dock state: UNDOCKED, UNSTABLE, DOCKED.

    - I couldn't find an ADC input. This means that its unlikely that an external resistor can set various doc states based its value as others have postulated.
    - The N10 uses one pin for a bi-directional data interface. It uses a non-standard protocol that bit-bangs MFM-encoded short command-response messages. When the dock is "acquired" (i.e., connected with stable signals), it sends an ID address and DOCK_VERSION constants. This probably tells the dock which features are supported by the device. Looks like the N10 can tell if its a Samsung dock based on the response message. Haven't followed the trail to find out other command functions.

    - The audio interface is SPDIF, not analog or USB as others have predicted. Makes good sense as SPDIF requires only one pin. The reason that I didn't see SPDIF when I scoped the pogo pins is that the audio gets turned on and off. One other wrinkle: the audio pin is being multiplexed with another function. The mux logic looks like it's external to the cpu.

    - The code sets the power status to one of four states: NONE, 500MA, 1A, and 2A.

    - The code has several interfaces to the USB interface. For example, it controls power to the vbus line.
    Suggests that it might support OTG on the dock.

    Based on this, here is a SWAG on what the pin-out might be. We know we've got 2 ground and 1 charging pin. Let's assume that pin 2 is the interrupt pin. The two remaining pins might be multiplexed: in one state, the pins are the proprietary command interface and the SPDIF out; in the other state they are the USB d pins.

    I'll continue reading the code to refine what I've seen. It would be great if some of the kernel devs could jump in and confirm some of this. I'm not comfortable in this environment yet. If I were, I'd be running the code under the debugger to see what happens when pin 2 is stimulated. ;)

    To me the data interface is the most exciting. The protocol should be hackable to extend the command set for use with custom docks. Want the docked N10 to turn on the table lamp when the alarm goes off? No problem. I'm sure that there are lots of ways that this could be used. Open source docks maybe?
    4
    I opened a pogo cable up to look at the board inside to try and make out the connectors. Here are pictures:





    From what I can tell, 2 vout in the center, 2 grounds on either side one spdif, and one where I can't recongnize the marking.

    Any ideas anyone? Anyone still care? :)
    3
    The outer pins (1 and 6 ) are ground. The middle pins ( 3 and 4 ) are supply, the other 2 pins are connected to the data pins on the USB plug.
    1
    After not seeing any interesting signals on the pogo pins a few weeks ago, I decided to look at the software. The kernel file ".../arch/arm/mach-exynos/board-manta-pogo.c" gives a lot of clues about the pogo connector. This post has some of my initial findings. I have to preface this rather long post by saying that although I've done embedded h/w and s/w for decades, I've never done an embedded Linux system and my knowledge of the Exynos gpio came from a few hours with the 911 page Exynos 4412 User's Manual. Please feel free to critique/correct anything said here.

    The good news is that the code defines much of what the dock can do. It is more complex than I would have thought. Obviously the code doesn't define how the gpio connects to the pogo pins. Looks like some may connect directly, but others go through external logic, like the audio MUX mentioned below.

    Here is an overview of the dock interface:

    - The dock circuitry triggers an interrupt during docking/undocking. The interrupt triggers software debouncing of a gpio input to determine the dock state: UNDOCKED, UNSTABLE, DOCKED.

    - I couldn't find an ADC input. This means that its unlikely that an external resistor can set various doc states based its value as others have postulated.
    - The N10 uses one pin for a bi-directional data interface. It uses a non-standard protocol that bit-bangs MFM-encoded short command-response messages. When the dock is "acquired" (i.e., connected with stable signals), it sends an ID address and DOCK_VERSION constants. This probably tells the dock which features are supported by the device. Looks like the N10 can tell if its a Samsung dock based on the response message. Haven't followed the trail to find out other command functions.

    - The audio interface is SPDIF, not analog or USB as others have predicted. Makes good sense as SPDIF requires only one pin. The reason that I didn't see SPDIF when I scoped the pogo pins is that the audio gets turned on and off. One other wrinkle: the audio pin is being multiplexed with another function. The mux logic looks like it's external to the cpu.

    - The code sets the power status to one of four states: NONE, 500MA, 1A, and 2A.

    - The code has several interfaces to the USB interface. For example, it controls power to the vbus line.
    Suggests that it might support OTG on the dock.

    Based on this, here is a SWAG on what the pin-out might be. We know we've got 2 ground and 1 charging pin. Let's assume that pin 2 is the interrupt pin. The two remaining pins might be multiplexed: in one state, the pins are the proprietary command interface and the SPDIF out; in the other state they are the USB d pins.

    I'll continue reading the code to refine what I've seen. It would be great if some of the kernel devs could jump in and confirm some of this. I'm not comfortable in this environment yet. If I were, I'd be running the code under the debugger to see what happens when pin 2 is stimulated. ;)

    To me the data interface is the most exciting. The protocol should be hackable to extend the command set for use with custom docks. Want the docked N10 to turn on the table lamp when the alarm goes off? No problem. I'm sure that there are lots of ways that this could be used. Open source docks maybe?

    I've also been looking through the kernel today and my findings were the same.
    Looks to me like the pogo can do USB data, SPDIF, and/or power for charging.