WU-1a

The WU-1a is designed to allow wireless shooting from the D3200 and and D5200. It's tied to the WMAU nikon app for android or iphone which is severely limited. The WU-1b is almost identical except for the connector, and it works with the D600 and V2

Some slides about reverse engineering: http://goo.gl/5530H

video of my D800 working from the nikon android app: http://www.youtube.com/watch?v=tm7l25xjUes

Device info
controller: STMicroelectronics STM32F205

USB: STMicroelectronics USB2.0 PHY

Wireless: Broadcom BCM4336

normal operation

 * device plugs into the D3200
 * device senses ~3v on pin 6, supplied by the camera
 * [magic stuff happens]
 * camera supplies 5v on Vbus (pin 1)
 * device powers up
 * light flashes fast for a second
 * device connects to camera over standard usb d+ and d-
 * device shares wifi access point
 * light flashes slowly

From this point on, it appears the device works as a standard ptp-ptpip bridge.

firmware update
there are two means for grabbing the firmware. I haven't done either, but likely the single wire debug is the better choice if possible

single wire debug

 * Inside the device, there are two pads on the PCB right near the proper pins to be the single wire debug port data and clock lines. have not confirmed this

usb dfu

 * when powering the device with v5 on pin one and connecting it to usb host on a pc, it shows up as a device with a DFU port:
 * [[File:wu1a-dfu.jpg]]
 * firmaware is listed as readable, but the device terminates the connection when you try to read.
 * Using DFU-util:
 * [[File:wu1a-dfu-util.jpg]]
 * message -9 means broken pipe. anyone care to try and debug this?


 * ST has a windows app - DFUsE - for using DFU on the STM32F205 and other chips.
 * 
 * I modified the .inf but could not get the driver to load

hacking on to other cameras

 * basically we need to properly power the device.
 * connect pin 2 and pin 4 to usb d+ and d- (i forget polarity, or if it even matters. if it doesn't work, just swap them)
 * apply 3v to pin 6
 * apply 5v to vbus - pin 1
 * power pin 6 first or at the same time - if you power pin 1 first it will go into firmware update mode

tested cameras
these all work with the WU-1a in this hacked mode. Support by the WMAU app is different.
 * D3200
 * D800
 * D600


 * i tried the D7000 and D300s before i had everything figured out completely, but they should work fine.

WMAU app
I examined the android app. There was no protection, encryption, or obfuscation to be found. It's also not a very friendly app, messes with wifi settings, and has to force close every time i stop it. This is just when using it only with the D3200 properly.


 * 3 shared libraries - NCC, PTP, and PTPIP.so are included. they're android native libraries for ARM. I looked at them briefly in the free version of Idapro
 * there are 'modules' for 4 cameras - D300s, D7000, D600 and D3200. The names of the D600 and D3200 are obfuscated as MD5 hashes. Nikon has a very short dictionary for possible product names :)
 * Cameras other than the 4 above have default implementations in the base class of the module and should work, although possibly buggy.
 * D800 is the only totally unsupported camera i used with it. Most of the time it works fine. Sometimes it does liveview, but then fails to capture an image.

Due to the quality, functionality, and licensing of the app, i se no reason to put any effort into modifying it. Effort is best spent in a less grey area to make something more useful.

gphoto
Libgphoto in linux supports ptpip. I used libgphoto2 2.4.13 and made some modifications trying to figure out how things worked, but i think it was all unnecessary and i could have just used it unmodified.

In order to talk to the camera, connect to the camera's access point with wifi. Once connected, use the command line utility to manipulate the camera: > gphoto2 --port=ptpip:192.168.1.1 --summary

There are still bugs to be found. The D3200 does not report itself as supporting Liveview, and Gphoto checks this reporting. Comment out the break from the error condition and liveview works again: in camlibs/ptp2/library.c@1820 if (ret != PTP_RC_OK) { gp_context_error (context, _("Nikon enable liveview failed: %x"), ret); SET_CONTEXT_P(params, NULL); //				return translate_ptp_result (ret); }			while (ptp_nikon_device_ready(params) != PTP_RC_OK) /* empty */; }

entangle
Entangle is an app for tethered capture and liveview that uses libgphoto2. Biggest issues is that it asks gphoto for a list of cameras, which only returns USB cameras. I modified it to insert a ptpip device in the list (and to not remove it) in src/backend/entangle-camera-list.c@250 gp_abilities_list_detect(priv->caps, priv->ports, cams, priv->ctx); //added to inject ptpip camera {       const char *model, *port; int n;       EntangleCamera *cam; CameraAbilities cap; model="Nikon DSC D800 (PTP mode)"; port="ptpip:192.168.1.1"; {           n = gp_abilities_list_lookup_model(priv->caps, model); gp_abilities_list_get_abilities(priv->caps, n, &cap);

ENTANGLE_DEBUG("New camera '%s' '%s' %d", model, port, cap.operations); cam = entangle_camera_new(model, port,                                 cap.operations & GP_OPERATION_CAPTURE_IMAGE ? TRUE : FALSE,                                  cap.operations & GP_OPERATION_CAPTURE_PREVIEW ? TRUE : FALSE,                                  cap.operations & GP_OPERATION_CONFIG ? TRUE : FALSE); entangle_camera_list_add(list, cam); g_object_unref(cam); }   } //end of modification for (int i = 0 ; i < gp_list_count(cams) ; i++) { and prevent it from being pruned (sloppy fix) in src/backend/entangle-camera-list.c@331 //entangle_camera_list_remove(list, cam);

python
For all my testing and work, and for a final usable interface, i'm working on a few python scritps. I'll get them posted to a source control website soon so i can get some more input

performance
It appears that the WU-1a is decently capable of transfering data and files, however it's REALLY slow when doing lots of round trip transactions, such as when you do gphoto2 --summary or connect to the photo with entangle. Every single property field is half a dozen ptpip requests. It took almost half an hour to probe from 0x0000 to 0xffff with getdevicepropvalue to see if it was hiding any secrets (it wasn't, except liveview on the D3200)