Lynxmotion Tech Support

That's interesting. I could see 50 uS CMD word to CMD word, I can't remember off hand how that compares with what I ended up with. "Looks close" on an eyeball check.

I'd like to know the clock hi/low times, the space between command bytes, and the rep rate of the command string (together they should define the "dead time" between strings of command bytes. Preferably for the PS2. If you zoom in, can you see the clock edge relationship to the cmd and data? I keep hearing "data/cmd changes on the falling clock edge", but that didn't seem to work for me.

I think you're on to something on the alternating 43h and 42h. I believe I have seen some F3h IDs also. but very random. I qualify a received string with the mode 73h and 5Ah "data ready" before I copy it into my DualShock[] array.

Adding ACK to our interface could be useful, as you've verified.

Good job! It's late, I'm off to bed.

Alan KM6VV

Hi,

Well, I seem to have lost the reply I made last night. Too late, I guess!

I would suggest getting the pulse width of the clock (hi/lo times) and it's frequency. Also the rep rate of the read command (some 9 bytes), and the "dead time" between the string of bytes, and the end of the "frame". The time between bytes looks very close on eyeball inspection, but it would be good to nail it down. Then we can see how close you and I are to a "working" system.

You might also try to "zoom-in" and see what the data/cmd to clock-edge timing looks like. I've read several places (maybe they copy each other?) that data/cmd should change on the falling clock edge, but that didn't work for me.

I think you're on to something with the observation of the 43h and 42h commands alternating. I might try that.

I wonder if we should really be watching for ACK? I'd really like to get the DELAYS (other then 1us?) out of this code. They waste processor execution cycles! And in deterministic programs and RTOS, they're a no-no, as they BLOCK. One time initialization sequences on startup are probably OK.

Good work!

Alan KM6VV

Here are some readings I got off a PS2 with a regular wired controller. I got a glimpse of the startup commands by plugging/unplugging the controller and taking a screen shot right as the signal started appearing. Hard to see here, but it looks like its nearly 1 us per half clock cycle with equal on/off time (so ~16us between bytes). Initial delay before first byte seems to be 20us. Also, it seems like data is transmitted slower during the config period when controller is first plugged in.



I wrote a program to "trigger" on the controller being plugged in and to print out the command bytes sent immediately after the 'trigger'. Each line has the packet #, followed by a space, and then the command sequence (taken to 9 bytes) in hex, in reverse (right most byte is the first one transmitted). I only went up to 10 lines because that's all the print terminal I am using has, but it seems like I will have to go longer before the commands stabilize and go in to regular operation (000...004201). Here it is: (regular wired PS2 controller + PS2)

0 000000000000004501
1 000000000000004601
2 000000000001004601
3 000000000000004701
4 000000000000004C01
5 000000000001004C01
6 000000000301004401
7 00FFFFFF0100004D01
8 000000000000004101
9 00000003FFFF004F01
10 000000000200004001
184897 us

0 000000000000004501
1 000000000000004601
2 000000000001004601
3 000000000000004701
4 000000000000004C01
5 000000000001004C01
6 000000000301004401
7 00FFFFFF0100004D01
8 000000000000004101
9 00000003FFFF004F01
10 000000000200004001
184789 us

n
1 000101010101010101
2 000045010001004301
3 000000000000004601
4 000000000001004601
5 000000000000004701
6 000000000000004C01
7 000000000001004C01
8 000000000301004401
9 00FFFFFF0100004D01
10 000000000000004101
1887308 us

Below each of the 3 readings is an estimate of how much time it took to get the 10 readings. The first two seem to form a consistent pattern, but the third reading is slightly different. This may be because of the timing of things. I have one processor constantly reading the signals and another just for printing. Thus, half way through while the printing processor is accessing the data, the 'reading processor' may be changing the data, causing the reading to look strange. I need to fix this...

I also really need to hook up the ACK line and find a way to print more data.

So it looks like the PS2 runs at half speed while it's doing configuration. I was wondering if it needed more time between commands, but I couldn't detect any changes.

Maybe you can use a "trigger word" to get later data (act as a "trigger delay")?

I've ported from the PICDEM FS USB demo board over to a "Quick Flash" (PICBOOK.COM) 18F452 (& 18F4620 et al) board. Shouldn't change anything, although I will be periodically sending data requests based on a timer interrupt rather then as a result of program speed. I'd REALLY like to get the SPI back to hardware; rather then have to bit-bang it! That way, I can get rid of the *blocking* delays needed currently. And the data collection will be in the "background" and handled more by hardware.

Yes, I suspect the ACK line might be useful as well.

Thanks for the data.

Alan KM6VV

I revised the program and got it to print up to 30 data packets, trigger on the "5A" status of the controller. However, there is only room for the first 6 command bytes, and no room for the data bytes. I can however, print 10 data packets with the full command and data bytes. Here is the format:

packet 1 packet 2 packet 3
packet 4 packet 5 packet 6
....
packet 28 packet 29 packet 30
<time in us it took to get all 30 packets>

I took several looks at the pattern for the wired controller right after it is plugged into a ps2, and here is a sample that represents the majority of the frames I saw:

010000004201 010101010101 010001004301 Wired DS2
000000004601 000001004601 000000004701 on GT4, PS2
000000004C01 000001004C01 000301004401
FF0100004D01 000000004101 03FFFF004F01
000200004001 000201004001 000202004001
000203004001 000204004001 000205004001
000206004001 000207004001 000208004001
000209004001 00020A004001 00020B004001
000000004101 000000004301 010000004201
000000004201 000000004201 000000004201
2035626 us
9 000301004401
10 FF0100004D01
1752212 us

And here, just for comparison, a wireless controller (I just did it once)

010000004201 010101010101 010001004301 WIRELESS
000000004601 000001004601 000000004701 PREDATOR
000000004C01 000001004C01 000301004401 on GT4, ps2
FF0100004D01 000000004101 03FFFF004F01
000200004001 000201004001 000202004001
000203004001 000204004001 000205004001
000206004001 000207004001 000208004001
000209004001 00020A004001 00020B004001
000000004101 000000004301 010000004201
000000004201 000000004201 000000004201
1534679 us

Stuff to note:
-the 00...004201 is the "regular transmission" command, which goes into effect after the26th or so startup packet is sent, meaning it takes about 26 bytes to "initialize" a controller
-wireless setup seems same as wired
-30 packets takes 1.5+ seconds, regular transmission is 60 packets/second exact (not coincidentally, ps2 video is 60 fps)

Conclusion: It seems like the PS2 console "tries" a variety of "get dat" commands and "looks" for a response from the controller (in the incoming data bytes where button data usually is). In this way, the console can find out what type of controller it is, and perhaps, the controller (wireless ones at least) can be configured to run.

I think the next step would be to print 30 packets of cmd AND dat bytes to see each controllers (wired vs wireless) response to each of these different commands.