The function designed to print out the settings would print garbage (even taking into account the different offsets that need to be used due to MTP processing).Īt this point, I dumped the received data into the log file as hex. However, the data made absolutely no sense. The code in that project reads the current settings from the camera, and I was able to reproduce the request and get a nice (1.5kB) chunk of data back. This is where the previously mentioned GitHub example (a) helped, and (b) hindered development. It responds appropriately, though, without the secret Sony sauce, they either don’t function properly, or they fail altogether. The basic “must implement” functions are indeed supported by the camera. Sony appears to have taken a leaf from Microsoft’s book ( embrace and extend), embrace the standard, but then add your own secret sauce ( extend) such that code that follows the standard will only get very limited access. However, using this interface I have been able to locate, open, and talk to my camera.
Everything goes through COM, requires many function calls, and many HRESULT checks. It sits atop the USB subsystem and manages the communication with the device. MTP is an extension to PTP (Picture Transfer Protocol). Trying to access it using WinUSB failed – I can’t remember why.įinally, I stumbled upon a Microsoft MTP page. I tried opening the device using its internal filename, success – but failed when trying to read/write. Yeah, so Windows is very protective of USB devices, and refused to let me communicate directly with the camera.
This project has proved to be a good refresher. Since then my time has been spent developing systems using what some would argue to be higher-level languages, mainly on *nix platforms. The last time I wrote any C/C++ code for Windows was around 2006-2007. The packet-replay project above gave some insight, and some rummaging around on the Internet surfaced the USB specification that Sony have based their protocol upon. I found one piece that uses the above SDK, another simulates mouse clicks/etc on the Imaging Edge Remote application, and one that replays captured USB packets for a very specific combination of camera model and software.Īs such, I decided to try writing my own pseudo-driver that connects to the camera via USB using the same protocol as the Imaging Edge Remote software. Īfter hunting around, I was unable to find any suitable software that would let me directly interface with the camera. Developer World no longer offers updates and active support for Camera Remote API. * Camera Remote API has now been archived. The last post on their website announcing newly added cameras was around mid-2015, and prominently has the following message on every page: Sadly it appears they have officially “Archived” the SDK and no longer offer active support. It seems they (Sony) definitely thought about letting people control their own cameras for a while, as they released a camera SDK (it can still be downloaded) that allows control of a number of cameras over their built-in WiFi. This was very disappointing to me after I forked out US$1,000 for a new a6400, only to find that the only way to control the camera remotely was the Sony “Imaging Edge” suite. As mentioned in my ASCOM driver post, Sony doesn’t seem particularly interested in allowing third-party access when it comes to remote control of their cameras.
0 kommentar(er)
