Sony published recently the documentation of some part of the API of their "WLAN enabled" cameras:
https://camera.developer.sony.com/pages/documents/view/?id=camera_apiThe zip file linked on that page contains two PDF files, one with a very nice introduction how to set up a connection to a camera, the other describes a part of the camera API.
Unfortunately, the API documentation is quite incomplete.
Nevertheless, I was quite curious and bought a Sony DSC-QX10 a few days ago and then spent the evenings cobbling together a little proxy server that allows to log the data exchange between the camera and a smartphone running Sony's playmemories app.
After looking at the first captured logs, I have really mixed feelings. The API seems to be really easy to use and understand -- but the more interesting features seem to be locked down with a kind of challenge-respone mechanism -- even some of the API calls used by playmemories seems to be locked down, like setTouchAFPosition, used to set the auto focus point by tapping on the preview image on the phone.
But this is a _very premature_ conclusion: I haven't yet written even a single line of code for the camera -- up to now, i was just curious, how playmemories controls the camera with (yet) undocumented API calls.
Anyway, if anybody wants to tinker too with a WLAN enabled camera from Sony that works with playmemories: I'll attach its sourcecode to this post.
0. IntroductionThe basic protocol is very well described, and the API uses HTTP as the transport protocol and JSON as the data format, so the data exchanged between camera and controlling application can be easily monitored and analyzed.
I wrote a small HTTP and UPnP proxy that can capture the interesting data exchanged between playmemories -- still quite hackish, but working.
The core idea: Use a regular PC or laptop as a proxy that routes data between the camera and the smartphone.
I used the Twisted async framework for Python as the basis for the proxy. Setting this up under Linux should be easy, just install the Twisted package of your favourite distribution -- but I have no idea how the stuff would work under Windows or MacOS...
1. Network configuration"ASCII drawing" of the setup:
camera
|
| Laptop's WLAN port connected to
| the camera's access point
| SSID: DIRECT-xxxx:DSC-QX10
|
Laptop
|
| Ethernet cable
|
access point
|
| WLAN connection
| SSID: DIRECT-xxxx:DSC-QX10a
|
smartphone running playmemories
The laptop is connected via WLAN with the camera's internal access point, and via an Ethernet cable with a second access point. The smarthone with the playmemories app connects to the network of the access point.
(Thinking again about the setup: It might even work to just let the smartphone login to the camera's AP but then let playmemories select the proxy instead of the real camera -- would be worth a try,
but that would probably require some modifications of the proxy...)
1.1 SSID of the access pointPlaymemories connects only to WLAN networks with certain SSIDs. I tried a few variants of the QX10's SSID, "DIRECT-xxxx:D<SC-QX10", where "xxxx" look like four random characters -- but they are not completely random:
If you just change one of the "xxxx" characters of the camera's SSID and use the new string as the SSID for the AP, playmemories does not recognize the AP as a possible camera. But appending an "a" to the original camera's SSID works. Other changes of the part after the ':' may work too.
1.2 Notes about DHCP on the laptop.The AP must provide DHCP for the smartphone; the camera's internal AP has a DHCP server too which means that the laptop sees two DHCP servers -- and this can lead to some confusion, at least under Ubuntu. I'd recommend to assign static IP addresses to the two interfaces of the laptop.
Static IP addresses are also more convenient for the proxy setup -- you don't need to check any possible changes of the IP address when you start the proxy.
2. Proxy installation.Install the Twisted package(s) of your Linux distribution (python-twisted for Debian and Ubuntu).
In the file socaprox.py, adjust the IP addresses OWN_C_IP (address the WLAN interface of the laptop in the network of the camera's AP), CAMERA_IP (address of the camera itself (yes, i know, the proxy could discover this address automatically...) and OWN_OTHER_IP (the address of the Ethernet interface of the laptop in the network of the second AP).
Run "chmod 755 socaprox.py", and finally start the program.
stderr will print a a few messages; if the server starts properly, you should see
Got discovery response from camera.
HTTP proxies started
If these messages do not appear, something went wrong -- time to start debugging
The proxy prints the captured API calls to stdout as JSON strings: one line contains the data for one request/response pair. Reading this stuff is hard -- send stdout output instead into a file.
The file show_log.py shows the logged data in a better readable format.
(and yes, I know that show_log.py could in theory easily read the output from socaprox.py -- I'm just too lazy to do the small required changes right now
[message size limit reached -- next part will follow an a reply]
