forums.ps2dev.org

[Ihsan]

I was thinking on building a small pcb that permits to hear the PSP in any FM receiver (your car radio or your hi-fi home system), but I've got no idea if the remote control connector (the 6 pin flat one) has any signal of power (+3'3 or something similar). Any idea?

[Ihsan]

I don't remember exactly how it was an audio signal to headphones, but could it be possible to extract power from that?

I just ask if someone knows it... :P

[mc]

Yes. The remote control contains a microcontroller of some sort (can't tell exactly which sort as it's covered in black plastic, as per tradition :), so one of the pins will definitely be a power feed to drive it. Don't know exactly which one though. I started investigating the remote control port, putting the results on http://mc.pp.se/psp/phones.xhtml, but I didn't have time to finish it at the time. If you want to help out with the measurements, you're welcome. Signal ground can be found on the normal headphone connector, to get a good reference point.
_________________
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people

[Ihsan]

For sure I will make some tests...

[cj]

well I ripped mine open earlier today, took some pic's (they are bad, but gives you a jist of whats up.

8 wires inside, 2 for the audio, 6 for the buttons, which looks like all 6 may be used (dunno), just 6 buttosn = 6 wires + one of the audio ones for a ground would make it work, + theres a small chip inside, but its covered with a small heatsink (in a way)

www.cjpcweb.com/psp/r1.JPG
www.cjpcweb.com/psp/r2.JPG
www.cjpcweb.com/psp/r3.JPG
www.cjpcweb.com/psp/r4.JPG

(yeah there bad but MEH)..and if you take your's apart, be careful the buttons tend to "fall" out

[Cogboy]

have you tried just testing the terminals for a constant voltage?

and if you can get some photos that are in focus that would help. it doesn't matter if they aren't as big, they just have to be clear.

I don't get why they would need 6 wires for a simple remote like this anyway?

[Ihsan]

Finally hi opened my controller and those are the results;

looking the conector from the front of the psp I numbered the pins like that;

1 2 3
- - -
O
- - -
4 5 6

And the jack ones are 7, 8 and 9 (7 is the contact in the end, 8 the middle and 9 the bigger, usually gnd).

They correspond to wires colours;


1 - BROWN
2 - BLUE
3 - ORANGE
4 - GREEN
5 - YELLOW
6 - GREY
7 - PINK
8 - RED
9 - BLACK

Testing those cables with the controller plugged there are some interesting things;

1,2 - are tyed to GND
3 - seems some kind of serial interface controlled by PSP asking for some information at some rate (some kind of SCL in I2C).
4,5 - are tyed to 2'5V, they seem comunication lines, they canot give power, 4 is managed by PSP and 5 by the external controller (when you unplug this 4 keeps it's state but 5 changes to GND)
6 - seems the corresponding data pin from the serial comunication, when you press something the serial signal changes (some kind of SDA in I2C).
7 - Audio channel signal PLUS 600mV DC (I guess this is the power output for external devices).
8 - Audio channel with no DC value.
9 - GND

That's all, when I've got time I will try to decouple the DC value for feeding some electronics. Have fun!

[mc]

Nice. Did you look at pin 3 and 6 in an oscilloscope? I do have access to an oscilloscope myself, but I did not want to splice up my cable. :-)

I'm a little sceptical to the idea that the remote is phantom fed through the left channel; if for no other reason 0.6 V seems a somewhat low voltage. Could not the DC offset be related to ProLogic surround or something?

And why do you say that pin 4 can not give power? Did you measure the current when the remote was plugged in?
_________________
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people

[Ihsan]

Yes, I did use an oscil.loscope to look at all the signals, and while most where fixed I saw those variations in pins 3 and 6 suposed to be due to data comunication, and since 3 is periodically changing I supose It was PSP asking for something, while the other is the response (it changes when you press something). It's not necessary to slice your cable, you can just open the box with the buttons (that's what I did).
I not measured the current, but I put a led with a resistor between pin 1 and 4 (1.7V led with 100 Ohms, suposed to draw just 8 mA and the output did not suported that, I have tryed also a 1k resistor for lower load, but the output still goes to a value near zero, so it seems a pull-up or something similar).

I agree 0'6V seems quite a small signal... but it's ALWAYS fixed. I don't know much about audio signals, but it's very strange to me, and there are step up converters that may work at that voltage, and it's the only way I see to power the device... by the moment.

[Ihsan]

Ok, let's try the easy way... If you desolder yellow cable the remote controll does not work, so power may come from that line. I guess that if the chip says nothing when the PSP asks, the output power is disabled...

[Ihsan]

Ok... don't trust very much what I've said... It seems that SCE likes to do things the "hard way"... someting as simple as powering devices become very complicated. What I've stated by now is that when you connect the jack, starts a round of qüestions/answers; the psp brings power up form pin 4, it looks if pin 5 is up (I must check that) and if it's up it asks something, if PSP does not see pin 5 up it does nothing, just stop power. If the answer to the question is not good the psp lows ping 4 and retries 2 times. Quite difficult, don't you think so?? I want to make some more tests but I need to build hardware (something like a pic12f629 atached to the psp) and that would need some time...

[mc]

It seems like pin 5 is an indicator that the device is connected, yes. So the PSP will power down the device if it doesn't answer to the communication, even if pin 5 is still active? Maybe it's intended as a way to reset the device if it gets into some kind of weird state...

I'll have to check out these data/clock signals for myself to see if they're really I2C or something else, I suppose I'll just attach the probes inside the remote as you suggested.
_________________
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people

[mc]

[Ihsan]

It's not a standard I2C, it's a very strange protocol, the PSP first downs one pin for a long time, then the controller responds doing the same, and later the PSP asks for something (some kind of frame) and the controller responds with four bits (if you don't press anything). So it seems a one line protocol with fixed baud rate...

[Ihsan]

I already tryed audio ground, but It's not conected with digital ground in the controller. It works equally, but I think blue(I don't remember exactly) cable is the proper gnd (at least the one used in the small pcb).

[Ihsan]

If you want you can download a document I've been writting summing up all those things... it's available here; http://www.comerma.net/PSP/ I'm still working on it. Let's hope today I've got time to make some oscil.loscope captures...

[Ihsan]

I have uploaded a pair of osciloscope captures, images, and raw-data, the first (TEK000) corresponds to the startup process, when you plug the remote controller what happens. The second one is the periodically interrogation that does the PSP. The probes conections are;

BLUE-GND
YELLOW - CH1
ORANGE - CH2
GREY - CH3
GREEN - CH4

[mc]

Yes, you're right. This looks like RS232, ~4800bps, 8N1 to me.
_________________
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people

[pukko]

Have you guys checked the data interface Sony uses for its Minidisc & CD remotes? I'd be surprised if they made up a completly new interface/protocol just for the PSP (feel free to prove me wrong ;).

[Victor]

psp remote like somy plam clie remote , it a another interface.
hehe, or soon sony make like this....:

[ooPo]

This sounds like the type of serial connector a GPS unit would use.

[Victor]

if a serial that is cool. sony must use that port to open psp service menu.

[mc]

Ok, I've now done some scoping of my own.

First of all, I now agree that blue (pin 2) is digital ground. It is directly connected to various ground planes on the PCB, as well as to the cases of the volume control switches (a great place to attach a crocodile clamp for grounding the probes, btw :).

I suspect that it's pin 6 which is used by the PSP to send, and pin 3 which is used by the remote though. The reason being that when I pressed a button on the remote, I noticed a change in the pattern on pin 3, but not on pin 6.

What I see happening after the remote has been connected and when no buttons are pressed, is that an exchange takes place once a second. Assuming the RS232 protocol and 4800bps 8N1 (which it really seems to be, all the waveforms I have seen have the correct framing), it looks like this every other time:

Pin 3: 0xf0 (this corresponds to a 1ms pulse of low signal)
Pin 6: 0xf0
Pin 3: 0xfd 0x02 0x00 0x02 0xfe
Pin 6: 0xfa

and every other time it's like this:

Pin 3: 0xf0 (this corresponds to a 1ms pulse of low signal)
Pin 6: 0xf0
Pin 3: 0xfd 0x03 0x00 0x03 0xfe
Pin 6: 0xfb

i.e. the 0x02:s have changed to 0x03, and the final 0xfa on pin 6 to 0xfb. This final byte might be some kind of checksum to acknowledge that the message has been correctly received.

Now, if I press the rewind button, the sequence

Pin 3: 0xf0
Pin 6: ?
Pin 3: 0xfb 0xf0
Pin 6: ?

is is inserted between the regular exchanges. I only had one channel connected and I was running out of time, so I don't have the responses on pin 6 (hence "?"), neither did I try any other buttons at the time.

The plot thickens... :-)
_________________
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people

[mc]

I have updated my webpage with some of the new information.

It just occured to me that pin 4 and 5 might be CTS and RTS, since we're dealing with RS232 here. The levels seem inverted though.
_________________
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people

[Ihsan]

Yes, I also think the same, but still have no idea where power comes from, perhaps the RTS signal?

P.D.; what's your webpage?

[Ihsan]

Sorry, I meant CTS...

[mc]

The URL is posted further up in this thread. :-)

Well, the one pin we have left as a candidate for power supply is pin 1 (brown), which would be logical as it is next to the ground pin. But if you measured it as being ground level when the remote was connected, I suppose it can't be it either...
_________________
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people

[Ihsan]

Yes, sorry, I didn't remember... I will verify pin1, just in case...

[Ihsan]

Yes, 1 is tied to GND... so power don't come from there. I've uploaded a pair of higher resolution pics of the remote circuitry in my webpage.

[mc]

Ok, now I can't keep my soldering iron out of the remote any longer.

I built a snooping device using an EZ-USB microcontroller, and logged all the traffic between the PSP and the remote control.

First of all, forget what I said about pin 3 and 6. Looking at the logs, it is clear that pin 3 is the PSP talking, and pin 6 is the remote.

Without further ado, here are the logs I captured:

Cold start
=======

Pin6 00:00:00.557 : f0
Pin6 00:00:00.617 : f0
Pin6 00:00:00.677 : f0
Pin6 00:00:00.737 : f0
Pin6 00:00:00.796 : f0

Pin6 00:00:00.856 : f0
Pin3 00:00:00.870 : f8
Pin6 00:00:00.876 : fd 80 01 01 01 81 fe
Pin3 00:00:00.906 : fa
Pin6 00:00:00.911 : f0
Pin3 00:00:00.916 : f8
Pin6 00:00:00.921 : fd 83 01 a8 00 47 6d fe
Pin6 00:00:01.001 : f0
Pin6 00:00:01.061 : f0
Pin3 00:00:01.080 : f0

Pin3 00:00:02.430 Framing error (BRK?)
Pin6 00:00:02.430 Framing error (BRK?)

Pin6 00:00:02.555 : f0
Pin3 00:00:02.567 : f8
Pin6 00:00:02.571 : fd 80 01 01 01 81 fe
Pin3 00:00:02.600 : fa
Pin6 00:00:02.605 : f0
Pin3 00:00:02.617 : f8
Pin6 00:00:02.620 : fd 83 01 a8 00 47 6d fe
Pin3 00:00:02.650 : fb f0
Pin6 00:00:02.655 : f8
Pin3 00:00:02.667 : fd 03 01 02 fe
Pin6 00:00:02.680 : fb
Pin3 00:00:02.683 : f0
Pin6 00:00:02.685 : f0
Pin3 00:00:02.700 : f8
Pin6 00:00:02.705 : fd 84 00 00 84 fe
Pin3 00:00:02.719 : fa f0
Pin6 00:00:02.725 : f8
Pin3 00:00:02.733 : fd 02 00 02 fe
Pin6 00:00:02.745 : fa

*

Pin3 00:00:03.749 : f0
Pin6 00:00:03.757 : f8
Pin3 00:00:03.767 : fd 03 00 03 fe
Pin6 00:00:03.782 : fb

Pin3 00:00:04.800 : f0
Pin6 00:00:04.807 : f8
Pin3 00:00:04.817 : fd 02 00 02 fe
Pin6 00:00:04.832 : fa

repeat from *

As I already had seen on the oscilloscope, the last exchanges are repeated every second indefinitely. By pressing the button, I can get other exchanges:

Play/Pause Pressed
=============

Pin6 00:00:38.302 : f0
Pin3 00:00:38.317 : f8
Pin6 00:00:38.322 : fd 85 01 00 84 fe
Pin3 00:00:38.351 : fb f0
Pin6 00:00:38.357 : f8
Pin3 00:00:38.368 : fd 03 00 03 fe
Pin6 00:00:38.382 : fb

Play/Pause Released
==============

Pin6 00:00:42.250 : f0
Pin3 00:00:42.268 : f8
Pin6 00:00:42.275 : fd 84 00 00 84 fe
Pin3 00:00:42.301 : fa f0
Pin6 00:00:42.310 : f8
Pin3 00:00:42.334 : fd 03 00 03 fe
Pin6 00:00:42.350 : fb

(these logs show both one key even and one periodic event each.)

From studying this, much of the protocol becomes clear.

Control characters
============
F0 : I want to speak
F8 : Go ahead and speak
FD: Message begins
FE: Message ends
FA: Message received ok (phase 0)
FB: Message received ok (phase 1)

If a message is not acknowledged with FA/FB in due time, F0 is sent again to initiate a retransmission. If three F0's go unanswered after a connection has already been established, some kind of BREAK seems to be used to reset the communication (it's a low pulse longer than 9 bit lengths, but I haven't measured the exact length).

The actual messages begin with one command byte, the least significant bit of which is the phase bit, which is not part of the command itself. The phase is inverted for each successfully acknowledged command, so that you can tell a new command from a retransmission of an old one. This is also why there are two acknowledge codes.

After the command comes zero or more data bytes, depending on the command, and finaly a checksum, which is XOR of the command byte and all data bytes.

The periodic command, which is sent by the PSP, has command code 0x02, and one data byte which seems to be always zero.

The remote uses commands 0x80 and 0x82 during the init phase (presumably all commands that go from the peripheral to the PSP have the MSB set), probably to identify itself and perhaps set some parameters.

When keys on the remote are pressed or released, the command 0x84 is sent (this is also sent during the init phase, to tell which keys were already pressed when the remote was plugged in). It has two bytes of data, which is a 16 bit (little endian) bitfield of which keys are pressed. The keys are

0x0001: Play/Pause
0x0004: Fast Forward
0x0008: Rewind
0x0010: Vol +
0x0020: Vol -
0x0080: Hold

The remaining 10 bits do not correspond to any key on the remote, but the jumps in the codes suggest that they might be assigned to keys present on more feature-rich remotes.

Now one of the probe wires came loose, so I guess it's time to go and update the webpage. :-)
_________________
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people