I picked up my Playstation Eye today. The VID/PID are 1415:2000. Strangely, 1415 is not assigned to any company, according to any list that I've found, including the official one here.
For video, it's not just a UVC device (disappointing), so it will take some effort to get it working outside of GameOS.
The audio input works fine under Linux using the usual ALSA usb driver. As advertised there are 4 microphones inside, and they're all individually exposed as different channels. With the camera facing you, the channel order is 1, 3, 2, 4 from left to right.
Usually when you have four microphones(antennas,cameras) they are used for direction/tracking. Figuring out which is which may be nice in order to attempt to make something that translates the signals into relative directions by looking at the doppler shifts.
unsolo wrote:Usually when you have four microphones(antennas,cameras) they are used for direction/tracking. Figuring out which is which may be nice in order to attempt to make something that translates the signals into relative directions by looking at the doppler shifts.
Yep, I already figured out the order, it's listed in the first post.
It's not doppler shift, just the relative phase shift between inputs. If you're sampling at say 44100 then you should be able to resolve about a quarter inch difference in path length between mics. Indeed, I did some quick tests with Audacity and the difference between left/right clapping is definitely visible. I'll focus on getting the camera to work before I play with the audio too much more, though. :)
Yeah, it wasn't so bad; basically just more-or-less matching the PS3's initialization sequence and then read the frame data on bulk EP 1. It's coming at 640x480 uncompressed YUYV at the moment, so it's a really high data rate and my libusb-based test program is having trouble dealing with that (a kernel driver shouldn't have a problem).
According to the SCCB product & version registers, the OV chip used in here is most likely an OV7721 (or something close). After writing my test program and realizing that the command structure was very similar to the OV51x series interface chips, I took it apart and found that it's just an OV538. In fact it even has "NEW EYETOY OV538 SOLUTION" silkscreened on the board, so it's not that much of an upgrade:
EyeToy: OV519 + OV7648
Playstation Eye: OV538 + OV7721
Getting docs on these chips is difficult, but I'll see what I can find. The "ECX" Windows driver here includes a data/settings file for the OV7720, which might be useful.
ov519 and ov7640 documentation is easy to find, i have a complete doc for both it was very helpfull for my full eyetoy(audio and video) iop replacement. However OV538 and OV7720 will be more difficult to find, we will make a try...
Do you know if 0V772X support 120fps with 320x240?
Sony says it supports 120fps at 320x240, but I don't know.
With what I have, I can write a simple limited-functionality driver already, so even if we can't find docs we can get something going and just experiment from there. Right now I'm not sure the best way to write this driver -- looking at existing drivers, it seems I could go the route of a full implementation in one file (like ov7670.c) or add the sensor to the ovcamchip i2c layer and make an interface like w9968cf.
Mihawk wrote:Any chance to get you to post some sample program with source code? ;)
Here's my test app: https://jim.sh/svn/jim/devl/playstation/ps3/eye/test/. It drops most of the data because libusb just can't handle it well. After initializing it waits for 100 complete frames for the camera to settle, then prints out the last one as a ppm.
Ive been searching the web every day for the last week, and it seems that you are the closest to making a working webcam out of this thing! YOU ROCK! Please keep posting as your make progress.
And even if you can only make it take pics, can you post the drivers for that?
yes, but thats in the source form, Im not sure how to turn it into a usable form for me. Could you explain how to do that if you have the time? cuase that would be great, like i said, out of everywhere ive looked, your the closest to having it working perfectly =)
I have, Microsoft Viusal C#, Microsoft Visual c/c++ and bloodshed Dev-c++ for compliers.
However, other than compiling DS games, im not to good at the compiling thing, how would I compile the file correctly. Or could someone else compile it, and then upload it?
What im trying to say is im a newb when it comes to all this, I can make my homebrew for DS, and script in flash, other than that, 101% noob. Anyway, I tried loading eye.c into dev-c++ but it gets loads of errors cuase im missing files, Im guessing im missing the needed libary.
and I see the gcc.exe in the bin folder... but its not the noraml windows install version, its a version just for dev-c++ for its compiling correct? im guessing thats why it wont work.
haha, understood, looks like ill just have to wait patiently. Hopefully youll have it fully working, and for windows someday, as im really looking forward to it, and it seems that your the only person working on it!
hi jimparis,
thanks for this work! I managed to compile your code with minimal changes on win32 using libusb-win32, after creating the necessary windows .inf files etc.
it finds the device ok,
however usb_claim_interface fails with error -22. after a bit of googling it seems that on win32 you need to call usb_set_configuration before you call usb_claim_interface, which I tried. configuration 1 is the ony one I can make succeed (as in, usb_set_configuration(eye, 1)==0)
....and after that the claim_interface works! the led flickers on and off as requested, until it gets to the first eye_bulk_in, which fails again with error -22. this makes your 'wait for frame 100' code loop forever because the eyetoy is not sending back any bulk data for the frame.
help! do you have any ideas how I could bring it to life?
I'll post my win32 patches if its any help.
got a bit further... I found that bulk_in was failing with 'invalid endpoint 0x01' according to libusb; so I tried endpoint 0x81 and it started succeeding.
however the first call to bulk_in sends back 135232 bytes of image data - not enough to trigger your code to see a full frame. in fact that data looks like a 640x105 image of the top of the frame! and then each subsequent call to bulk in just goes into a loop returning alternately 12 and 4160 bytes. and that's it for the rest of time - no idea what is in those packets or where the rest of the frame went (or subsequent frames...). is this all because of my added 'set_configuration(eye,1)' call?....
usb_set_configuration & fixing the endpoint should be correct. If you'd like, I can give you svn commit access to that repository so you can add your win32 fixes, just PM me.
Not seeing a full frame is a big problem, but it's most likely because libusb is just too slow. At 640x480 60fps 16bit YUYV that's basically 300 MB/s, which comes close to saturating USB 2.0's theoretical 480 MB/s. I'd guess the Windows libusb library just isn't up to handling it. On my Linux system, I get full frames on maybe 10% of the attempts. A real driver would really help here.
It's not fully clear how the thing behaves on dropped frames. I think the 12-byte packet basically says "sorry, you lost data" and the 4160 is the start of the next frame (which gets dropped early because you spent too much time processing the 12-byte packet).
For testing, you could just modify it to look for the top of the frames (640x100?). Another option would be to look at the commands used to initialize the camera and figure out how to put it in a lower resolution/framerate.
thanks for the quick reply :)
the 4160 byte packets dont look much like image data sadly :(
the 12 byte packets are odd - here are some, 1 line per packet
[0000] 0C CE 43 ED 0B 02 EB F1 1B 02 36 07 ..C.......6.
[0000] 0C CE F3 2D 1B 02 85 2C 2B 02 57 07 ..........W.
[0000] 0C CE A3 6E 2A 02 C2 73 3A 02 79 07 ...n...s..y.
[0000] 0C CE 53 AF 39 02 83 AE 49 02 9A 07 ..S.9...I...
[0000] 0C CE 03 F0 48 02 A1 F5 58 02 BB 07 ....H...X...
[0000] 0C CE B3 30 58 02 36 2C 68 02 DD 07 ...0X.6.h...
[0000] 0C CE 63 71 67 02 4F 71 77 02 FE 07 ..cqg.Oqw...
[0000] 0C CE 13 B2 76 02 E3 A9 86 02 1F 00 ....v.......
[0000] 0C CE C3 F2 85 02 41 F5 95 02 41 00 ......A...A.
[0000] 0C CE 73 33 95 02 77 3A A5 02 62 00 ..s3..w...b.
[0000] 0C CE 23 74 A4 02 F5 72 B4 02 83 00 ...t...r....
[0000] 0C CE D3 B4 B3 02 42 BA C3 02 A5 00 ......B.....
[0000] 0C CE 83 F5 C2 02 D7 F2 D2 02 C6 00 ............
[0000] 0C CE 33 36 D2 02 2B 3C E2 02 E7 00 ..36........
[0000] 0C CE E3 76 E1 02 A2 72 F1 02 09 01 ...v...r....
[0000] 0C CE 93 B7 F0 02 BB B7 00 03 2A 01 ............
[0000] 0C CE 43 F8 FF 02 71 F4 0F 03 4B 01 ..C...q...K.
[0000] 0C CE F3 38 0F 03 AC 3B 1F 03 6D 01 ...8......m.
[0000] 0C CE A3 79 1E 03 C1 7E 2E 03 8E 01 ...y........
[0000] 0C CE 53 BA 2D 03 90 BB 3D 03 AF 01 ..S.........
[0000] 0C CE 03 FB 3C 03 8E FE 4C 03 D1 01 ........L...
[0000] 0C CE B3 3B 4C 03 21 37 5C 03 F2 01 ....L..7....
[0000] 0C CE 63 7C 5B 03 7C 80 6B 03 13 02 ..c.....k...
[0000] 0C CE 13 BD 6A 03 0D B9 7A 03 34 02 ....j...z.4.M
the bytes that look like '03' at the bottom there are some kind of timestamp, slowly ticking up...
anyway, ignoring them the consistent size of the 4160 byte packet (and it doesnt change when I pause in the debugger) implies I've somehow put the thing into a bad mode. alas.
oh well, I'll have to give up for a bit.
probably not worth committing any code yet :)
The 12-byte packet might be something like "you lost data, the next packet starts at this byte offset". Notice how the PS3 handles it if you plug the eye in through a full-speed hub which definitely can't handle the bandwidth: it draws a few lines of data at specific locations in the image as if it knows exactly where to put what little data it can receive. Anyway, I haven't really played with that aspect very much. I'm sure the protocol has a way to handle lost data like that, but again a proper driver for the thing (or figuring out how to maximize libusb performance) would make that less necessary.
jimparis: hmm, that sounds right! I didn't get any further with this, instead I borrowed a PC compatible webcam to solve the problem I was trying to use a ps3 eye for. but hopefully this will be resolved one day. as you say, libusb just isn't fast enough for 640x480x60x2... ah well. thanks for the code anyway :)
