Martin Schmidt has worked out digital camera control using ptp over usb, sort of like the Promote. Implementing it would require a simple addition of a Vinculum chip to the OCC. This will be a rainy-day project, unless someone else has time to tackle it. We'd have to use the unused Guitar Hero additional control lines on the current OCC design, probably.

I am interested in joining development on the hardware end. I have been thinking about a USB camera controller for a few months and stumbled on this project at about the same time. I have a vinculum dev board and have been researching the canon USB protocol. I also applied for the canon SDK which I have not received a response, any trick to getting approval? I am currently trying to learn more about the GBA Cartridge interface. Do you have links to info on the Guitar Hero control lines?

Hi Luke, I'm afraid the Canon SDK won't do much good here. The SDK is a precompiled driver that acts as a hardware abstraction layer, which is why it takes a bit for software to support new Canon cameras; they have to wait for Canon to supply a new HAL. The SDK won't give you any info about what is actually communicated to cameras through USB.

Hi Luke, I'm afraid the Canon SDK won't do much good here. The SDK is a precompiled driver that acts as a hardware abstraction layer, which is why it takes a bit for software to support new Canon cameras; they have to wait for Canono to supply a new HAL. The SDK won't give you any info about what is actually communicated to cameras through USB.

I was going to use the STK to reverse engineer the canon USB protocol using a software USB sniffer. I just need to find the command sets to do simple things like setting the aperture, exposure time, iso, focus, and shot firing. I was going to write a simple program to interface with the STK and command the camera to change aperture, etc and sniff the USB traffic. I have been sniffing the traffic with the EOS utility and there seems to be a lot of extra traffic going on such as pinging the camera to check for user changes which makes it harder to figure out what is what.

Quote:

This site will put you on track to programming for the Guitar Hero data lines. You'd need to modify the firmware of the OCC to write or read data from these lines as well.

Yes, you are absolutely correct, I think I spoke too soon. (Especially since I bought the SDK and a USB sniffer for just such a purpose!) There seems to be quite a bit of data transferred back-and-forth to change even simple settings, which may be why it is possible to control the full usb device capacity of cameras with one machine. (128 cameras - #of hubs, I think.) This is why we're looking at PTP as a simpler subset of controls, which will hopefully support more than just Canons. It seems to be the approach that some other handheld remotes are taking.

I've browsed the devkitarm files for clues to how to make the GH lines an output with no luck. Obviously it can be done (http://www.bayerdidget.com/Home), but whether this needs some bits of assembly code, I'm not sure. Memory.h is the key, I think.

I was wondering if the other devices use the GH control lines. They probably are writing directly to DMA on the GMA port and using a FPGA\CPLD or uC with some clever code to decode it. I was thinking of doing serial bit banging or writing and reading from a set address on the GBA port so you could just present and read\write the data in parallel on the D0-D7 lines. I found some code on how to read and write to SRAM on a GBA cartridge which should make the process easier to get setup: http://double.co.nz/nintendo_ds/nds_develop5.html

EDIT: haha, looks like you beat me to it.

I am interested in PTP\MTP too, at this point I know basically nothing about it though. gphoto (open source camera control software) uses PTP and I sniffed out the traffic used with that software but it does not really work on my camera (Rebel XS, 1000D), I can get it to change a few settings. Hardware is more of my strong suite so I am having a hard time understanding the gphoto code. I am going to continue to research it on my free time, hopefully it will become more clear over the next few weeks.

I though I would post an update. I desoldered all the components on a GBA game cartridge and soldered in jump leads from each pin to pins on a header. I wrote a program on the DS to write 0x0F0F to 0x80000AC then I logged the traffic on a logic analyzer. I still need to solder in jumper leads to a working GBA cartridge and log how the DS reads from the GBA cartridge RAM and ROM. From there I should be able to have a uC talk back and forth to the DS in a basic parallel read and write.

I have been sniffing out the USB traffic and have been able to decipher the partial commands used to set ISO, aperture, exposure time, exposure compensation, and white balance. I still have not been able to figure out what is going on directly before and after these commands. Also I do not yet understand the commands used in the constant pinging back and forth with the EOS utility. I know the EOS utility is constantly polling the camera to see if the user has changed any settings, when I change a setting on the camera I can now pick out the strings that contain the changed setting but the rest is still unknown at this time.

Once I get further along in the coming weeks I will post all the info. Here is some pics of the fun..

It's an interesting site, although our current budget probably doesn't allow for it. I don't think we are more than an afternoon away from implementing the USB controller in prototype form, the main constraint I face is a lack of free time. I'm bogged down working on a 3D movie, though my cross-fingers plan for the long holiday weekend is to finish a DS breadboard configuration that will allow easier manipulation and testing. The new config will use Ladyada's in-circuit microcontroller programmer while remaining connected to the DS & camera.