Tech 15 min read

Investigating PC Control for the Nikon COOLPIX A1000

実験 Nikon Bluetooth Python
IkesanContents

I own a COOLPIX A1000, and I got curious whether I could pull images from it or do remote shooting from a PC. Nikon’s official software is all geared toward DSLRs and the Z series, while compact cameras basically get funneled into the SnapBridge mobile app.

So I figured I’d just connect it myself, and started digging into the protocols.

COOLPIX A1000 Connection Specs

First, here are the specs pulled from the official reference manual (pp.226-228).

InterfaceSpecification
USBMicro-USB (UC-E21), Hi-Speed USB 2.0
USB ProtocolMTP / PTP / PictBridge
WiFiIEEE 802.11b/g (2.4GHz, ch1-11)
WiFi AuthOpen / WPA2-PSK
WiFi ModeAP mode (camera as AP) / STA mode (joins existing network)
BluetoothBluetooth 4.1 + BLE

Worth noting: 802.11n is not supported. Some third-party spec sites claim it is, but the official manual explicitly states b/g only. Bluetooth is 4.1 as well, which is unchanged from the super-zoom P-series models of the same era. No successor to the A1000 in the A-series has been released since.

Nikon Official Software Support

SoftwareA1000 SupportNotes
NX StudiooImage viewing, editing, and management. Successor to ViewNX-i
ViewNX-ioLegacy. Not supported on Windows 11
Camera Control Pro 2xDSLR/Z series only
Nikon Webcam UtilityxDSLR/Z series only
SnapBridge (Mobile)oiOS/Android. No PC version exists

Camera Control Pro 2 and Webcam Utility don’t support COOLPIX at all. There’s no official way to remote-control it from a PC. NX Studio is an image management application — it can’t control the camera.

USB Connection (MTP/PTP)

When you plug the A1000 in via USB, the OS recognizes it as an MTP/PTP device. Here’s the actual device info confirmed via ioreg -p IOUSB on macOS.

FieldValue
Device NameNIKON DSC COOLPIX A1000
Vendor ID0x04B0 (Nikon)
Product ID0x036B
USBHi-Speed USB 2.0 (480Mbps)
Serial000021000717
Power Draw500mA

SwiftMTP’s device database has the A1000 Product ID registered as 0x4038, but the actual device returned 0x036B. This could vary by firmware version or region, but at least my unit reports this value.

Recognition with gphoto2

I looked into the source code of libgphoto2 (camlibs/ptp2/library.c), the open-source camera control library.

The A1000 is not registered. Here’s how it compares to registered COOLPIX models.

ModelProduct IDCapture SupportFlags
COOLPIX A9000x019eLimitedPTP_NIKON_BROKEN_CAP
COOLPIX B7000x0231Yes (with preview)-
COOLPIX P10000x0232Yes (with preview)-
COOLPIX P11000x0234Yes (with preview)-
COOLPIX B5000x0362LimitedPTP_NIKON_BROKEN_CAP
COOLPIX A10000x036B (measured)Not registered-

The A900 has the PTP_NIKON_BROKEN_CAP flag, indicating issues with remote capture. Since the A1000 is the A900’s successor, adding it to libgphoto2 would likely come with the same limitations.

That said, libgphoto2 has a generic PTP class detection fallback, so running gphoto2 --auto-detect might get basic file transfers working.

The macOS Gotcha

macOS automatically grabs PTP devices (via the PTPCamera process). You need to kill it first before using gphoto2:

killall PTPCamera
gphoto2 --auto-detect

WiFi Connection (PTP/IP)

This is where things get interesting. The A1000’s WiFi communication uses PTP/IP (Picture Transfer Protocol over IP).

PTP/IP Basics

PTP/IP (CIPA DC-X005-2005) was originally co-developed by Nikon and FotoNation. It carries PTP commands over TCP/IP.

FieldValue
PortTCP 15740
Connections2 (Command/Data + Event)
Camera IPUsually 192.168.1.1 in AP mode

Packet Structure

All PTP/IP packets share the same header structure:

[4 bytes: packet length][4 bytes: type code][payload]

Little-endian. Here are the key type codes.

CodeDirectionNameContent
0x01Client->CameraInit_Command_Request16-byte GUID + UTF-16 client name
0x02Camera->ClientInit_Command_AckSession ID + 16-byte GUID + UTF-16 camera name
0x03Client->CameraInit_Event_RequestSession ID (from type 0x02)
0x04Camera->ClientInit_Event_Ack-
0x06Client->CameraCmd_RequestPTP command code + Transaction ID + args
0x07Camera->ClientCmd_ResponsePTP response code + Transaction ID + args
0x09EitherStart_Data_PacketData transfer start
0x0AEitherData_PacketData body
0x0CEitherEnd_Data_PacketData transfer end

Connection Sequence

sequenceDiagram
    participant PC as PC
    participant Cam as COOLPIX A1000<br/>(192.168.1.1:15740)

    Note over PC,Cam: Command/Data Channel (TCP connection #1)
    PC->>Cam: Init_Command_Request<br/>(GUID + client name)
    Cam->>PC: Init_Command_Ack<br/>(Session ID + GUID + camera name)

    Note over PC,Cam: Event Channel (TCP connection #2)
    PC->>Cam: Init_Event_Request<br/>(Session ID)
    Cam->>PC: Init_Event_Ack

    Note over PC,Cam: PTP Session Start
    PC->>Cam: OpenSession (0x1002)
    Cam->>PC: OK (0x2001)
    PC->>Cam: GetDeviceInfo (0x1001)
    Cam->>PC: DeviceInfo (supported commands list, etc.)

Nikon-Specific PTP Operation Codes

On top of the standard PTP commands (0x1001-0x101B), Nikon implements proprietary commands in the 0x9000 range. Here are the key ones extracted from libgphoto2’s ptp.h.

OpcodeNameFunction
0x90C0InitiateCaptureRecInSdramCapture to SDRAM
0x90C1AFDriveAF drive
0x90C2ChangeCameraModeSwitch camera mode
0x90C7CheckEventsFetch events
0x90C8DeviceReadyCheck device ready state
0x9201StartLiveViewStart live view
0x9202EndLiveViewEnd live view
0x9203GetLiveViewImgGet live view image
0x9207InitiateCaptureRecInMediaCapture to media
0x920AStartMovieRecInCardStart movie recording
0x920BEndMovieRecEnd movie recording

Which of these commands the A1000 actually responds to needs to be verified with real-device testing. COOLPIX models are known to leave some commands unimplemented or return errors for certain operations.

BLE Communication — Real Device Testing

BLE Scan

I ran a BLE scan using Python’s bleak library. The camera advertises when you open the “Connect to smart device” screen from its menu.

A1000_21000717  addr=36C20FB9-...  mfr={}
  Service UUIDs: ['0000de00-3dd4-4255-8d62-6dc7b9bd5561']

Confirmed the SnapBridge service UUID 0000de00-3dd4-4255-8d62-6dc7b9bd5561. However, Manufacturer Data was empty — the Nikon Company ID (0x0399) was not included in the advertisement. Filtering by Company ID or device name may fail to detect the camera.

The WiFi SSID (A1000_21000717) is used as-is for the BLE device name.

Detection results varied significantly depending on the scan method.

  • BleakScanner.discover() (snapshot mode) was unreliable — sometimes it found the device, sometimes it didn’t
  • BleakScanner(detection_callback=...) (callback mode) detected it 50+ times over 30 seconds

find_device_by_name() with a name query sometimes timed out after 20 seconds. Using callback mode to catch the device, then connecting, is more reliable.

GATT Connection (Pre-Auth)

Connected with BleakClient the moment the callback fired. MTU negotiated at 185.

Device Information Service (0x180A):

CharacteristicValue
Manufacturer Name (0x2A29)Nikon
Model Number (0x2A24)A1000
Firmware Revision (0x2A26)1.2
Hardware Revision (0x2A28)1.2

Before authentication, all Characteristics within the SnapBridge Service returned zeros.

Blowfish Authentication — Implementation and Execution

Based on information gathered from OSS projects and network analysis tools, I implemented the SnapBridge BLE authentication in Python and ran it against the real device.

The authentication protocol is a Blowfish cipher-based challenge-response scheme consisting of 5 stages.

sequenceDiagram
    participant PC
    participant A1000

    PC->>A1000: Stage 1 (nonce + device ID)
    A1000->>PC: Stage 2 (camera's nonce + Blowfish hash)
    Note over PC: Verify hash and identify salt index
    PC->>A1000: Stage 3 (hash computed from own nonce)
    A1000->>PC: Stage 4 (serial number)
    PC->>A1000: Stage 5 (completion notification)

The Blowfish key and salt table are published by the furble project.

Execution result:

S1-2 OK salt=4
S3-4 OK serial='21000717'
S5 sent
No NOT1
POWER=03 VALID_WAKE

Authentication passed. Salt index identification, camera hash verification, and serial number retrieval all succeeded. However, the expected success notification after Stage 5 (NOT1 = 0x2008 with [0x01, 0x00]) never arrived. The camera is waiting for Bluetooth Classic secure bonding.

GATT Characteristic Map (Post-Auth)

Once authenticated, Characteristics that previously returned zeros become populated. Nikon’s BLE spec is not public, but by cross-referencing communication observations with OSS information, the role of each Characteristic was determined.

UUIDNamePost-Auth ValueNotes
0x2000AUTHENTICATIONContains serial numberWrite target for auth stages
0x2001POWER_CONTROL033 = VALID_WAKE (camera awake)
0x2002CLIENT_DEVICE_NAME(write-only)Write connecting device name here
0x2003SERVER_DEVICE_NAMEA1000_21000717Camera’s SSID name
0x2004CONNECTION_CONFIGURATION0000WiFi config (encrypted). Empty when not connected
0x2005CONNECTION_ESTABLISHMENT0000WiFi/BTC connection trigger
0x2006CURRENT_TIMEea070411123a032026-04-17 18:58:03 (JST)
0x2007LOCATION_INFORMATIONAll zeros (41 bytes)GPS coordinate write target
0x2008LSS_CONTROL_POINT0000Control flag (notify)
0x2009LSS_FEATUREfd030000Supported features bitflag
0x200ALSS_CABLE_ATTACHMENT(notify-only)Cable connection notification
0x200BLSS_SERIAL_NUMBER21000717Camera serial number
0x2A19BATTERY_LEVEL64Battery level 100%

LSS_FEATURE at 0x2009 is 0x03FD, indicating supported features via bitflags — WiFi, BLE, time sync, location data, etc.

Attempting WiFi AP Activation

After authentication, I attempted to activate the WiFi AP by writing the WiFi request bit 0x01 to 0x2005 (CONNECTION_ESTABLISHMENT).

>>> 0x2005 <- 0x01 (WiFi) <<<
Waiting 5s for AP...
CONN_CFG=0000 (2B)
CONN_EST=0000

The write was accepted without error, but 0x2004 (WiFi config) remained empty and 0x2005 immediately reset to 0000. The WiFi AP did not start.

I also tried 0x03 (both WiFi + Bluetooth Classic bits) with the same result.

Why the WiFi AP Won’t Start

Because Bluetooth Classic secure bonding hasn’t been completed. Analyzing SnapBridge’s connection flow reveals this sequence.

graph TD
    A[BLE Connection] --> B[Blowfish Auth<br/>Stages 1-5]
    B --> C{NOT1 success notification?}
    C -->|Not received| D[Bluetooth Classic<br/>Secure Bonding Pending]
    D --> E[Bonding Complete]
    E --> F[NOT1 = 0x01,0x00]
    F --> G[Write 0x01 to 0x2005]
    G --> H[WiFi AP Activates]
    H --> I[SSID/Password in 0x2004<br/>Blowfish-encrypted]
    
    C -->|0x01,0x00| G

    style D fill:#f66,color:#fff
    style E fill:#f66,color:#fff

Python’s bleak library (BLE only) cannot perform Bluetooth Classic bonding. The furble project gave up for the same reason, noting “smart device pairing not fully functional.”

Remote Control Mode Connection

When entering remote mode from the camera’s “Connect to remote” menu, Characteristics that weren’t visible in smart device mode appeared (0x2080-0x2087).

UUIDPropertiesRole
0x2080readRemote state 1
0x2082read, writeRemote configuration
0x2083writeShutter control
0x2084indicate, readCamera feedback
0x2086readRemote state 2
0x2087indicate, read, writeRemote pairing

Remote mode pairing uses a simple handshake that doesn’t require Blowfish — all Stage 1-5 responses are fixed at zero. Pairing itself succeeded, and mode configuration data (0202030320200000...) appeared at 0x2082.

However, the shutter command (writing [0x02, 0x02] to 0x2083) was accepted without error but the camera didn’t react. The A1000’s remote mode protocol may differ slightly from the B600 protocol that furble has verified.

SnapBridge Communication Architecture

Observing SnapBridge’s communication with network analysis tools reveals a 3-layer protocol stack.

graph TD
    A[SnapBridge App] --> B[BLE<br/>Always-on connection, pairing, control]
    A --> C[Bluetooth Classic<br/>Data transfer on some models]
    A --> D[WiFi<br/>Full-size image transfer]

    B --> E[PTP/MTP<br/>Command Layer<br/>ISO 15740 + Nikon Extensions]
    C --> E
    D --> E

    B --> F[GATT Service<br/>UUID: 0000de00-...<br/>Blowfish Auth]
    D --> G[PTP/IP<br/>TCP:15740<br/>GUID Handshake]

Typical usage flow:

  1. BLE always-on connection keeps the camera link alive with minimal battery drain
  2. When a photo is taken, a 2MP thumbnail is auto-transferred via BLE
  3. When a full-size image is needed, it hands off from BLE to WiFi
  4. Full-size JPEG is transferred via PTP/IP
  5. After transfer completes, WiFi shuts down and returns to BLE always-on

Regarding the BLE-to-WiFi handoff, a Foolography developer described it as “a strange combination of BLE Classic, BLE, and WiFi.” This experiment gave a much clearer picture of the overall flow.

WiFi AP Not Broadcasting

On the camera’s “Connect to smart device” screen, the WiFi SSID (A1000_21000717) and password (NikonCoolpix — a common default across models) are displayed. But the SSID didn’t show up in WiFi scans from either Mac or Windows. BLE advertisements were flying, but the WiFi AP wasn’t running.

This screen shows the SSID and password as a preview of the connection info for when the WiFi AP eventually starts after pairing completes. Even writing the WiFi request to 0x2005 (CONNECTION_ESTABLISHMENT) after BLE auth won’t work — the camera ignores the request until Bluetooth Classic secure bonding is done.

OSS Tools Worth Trying

From the tools discovered during this investigation, here are the ones worth trying with the A1000.

Via USB

ToolLanguageOverview
gphoto2 / libgphoto2CThe standard camera control library. A1000 not registered, but has generic PTP detection
python-gphoto2PythonPython bindings for libgphoto2
SwiftMTPSwiftmacOS MTP implementation. A1000 device profile registered
miniPtpPythonMinimal PTP implementation for educational purposes. PyUSB-based

Via WiFi (PTP/IP)

ToolLanguageOverview
ptpip-d5300PythonPTP/IP client for Nikon D5300. Most promising for A1000
libpictCGeneric PTP implementation. USB/IP dual support. No Nikon extensions
ptp-ip (Go)GoPTP/IP implementation. Fujifilm-oriented but standard parts are shared

Via BLE

ToolLanguageOverview
furbleC++ (ESP32)BLE remote shutter. Verified on COOLPIX B600

ptpip-d5300 is the top candidate for WiFi. It targets the D5300, but since PTP/IP is a standard protocol, basic file transfer and device info retrieval might work.

pip install ptpip
from ptpip import PtpIpConnection

# With the A1000's WiFi AP connected
conn = PtpIpConnection("192.168.1.1", 15740)
conn.open_session()
device_info = conn.get_device_info()
print(device_info)

SnapBridge App Permissions

I also checked the permissions that SnapBridge (com.nikon.snapbridge.cmru v2.13.3) requests on Android. Here are the notable permissions from the Exodus Privacy report.

PermissionPurpose
CHANGE_WIFI_MULTICAST_STATEDevice discovery via multicast
NFCFor NFC-enabled cameras (A1000 has no NFC)
RECEIVE_BOOT_COMPLETEDRestoring BLE always-on connection at boot
REQUEST_IGNORE_BATTERY_OPTIMIZATIONSMaintaining BLE always-on connection
FOREGROUND_SERVICE_CONNECTED_DEVICEForeground service for BLE device connection

One tracker detected: Adobe Experience Cloud. Since the communication content is essentially a PTP/MTP command wrapper, data leak risk is low.

Bluetooth Classic Pairing

BLE authentication alone won’t start the WiFi AP. Bluetooth Classic secure bonding is required.

Discovering Classic BT

macOS’s Bluetooth Classic scan (blueutil --inquiry) can’t see the camera’s Classic device while BLE is connected. After restarting Bluetooth (off then on) following BLE auth, the camera appears as a Classic device with a different MAC address.

Connection TypeMAC Address
BLEChanges every time (macOS randomization)
Bluetooth Classic3C:E1:A1:16:13:79 (fixed)

Successful Pairing

Manual Numeric Comparison pairing via macOS System Settings (Bluetooth). Both sides confirm the same 6-digit number and press OK.

The key is confirming on the Mac side first, then immediately on the camera. Reversing the order causes a timeout. Automation via blueutil or expect couldn’t match the timing — success only came through manual interaction with the macOS standard UI.

Camera’s Classic BT Services

Services retrieved via SDP (Service Discovery Protocol) query after pairing.

Service NameRFCOMM ChannelUUID
SPP ServiceChannel 10x1101 (Serial Port Profile)
iAP ServiceChannel 2Proprietary UUID
GATT over L2CAPPSM 310x1800 / 0x1801

An SPP Service exists, and a serial port appeared on macOS as /dev/tty.A1000_21000717.

Freeze Issue

After successful Classic pairing, the camera froze at “Processing connection.” Since there’s no SnapBridge SPP server on the Mac side, the camera attempts an RFCOMM connection and waits forever. Even the power button becomes unresponsive — the only recovery is pulling the battery.

By adjusting the confirmation timing on the Mac side and the order of the OK operation on the camera, there were cases where pairing completed without freezing. The camera returned to shooting mode while maintaining the BT connection. A location settings dialog even appeared, confirming the camera recognizes the Mac as a SnapBridge device.

Flag Changes After Taking a Photo

With Classic pairing done and BT connection maintained, taking a photo caused BLE 0x2008 (LSS_CONTROL_POINT) to change from 0x0000 to 0x0001. The camera appears to be requesting an image transfer.

However, since the BLE authentication (Blowfish handshake) is in a separate session from Classic, the WiFi trigger (writing to 0x2005) is not accepted.

Remaining Barriers

SnapBridge performs BLE auth, Classic bonding, and WiFi AP activation within a single session. In this experiment, a Bluetooth restart was needed after BLE auth, which breaks the session.

On macOS, no method has been found to simultaneously execute Classic pairing during an active BLE connection. On Android, both can be handled on the same BT stack, but macOS’s CoreBluetooth (BLE) and IOBluetooth (Classic) operate as separate layers.

Current Status and Next Steps

What Worked

  • USB: Recognized as MTP/PTP device on macOS, measured Product ID 0x036B
  • BLE: Full Blowfish authentication implementation and execution, salt index identification, serial number retrieval
  • BLE: All GATT Characteristic roles mapped (13 types)
  • BLE: Remote mode Characteristics (0x2080-0x2087) discovered and pairing completed
  • Classic BT: Numeric Comparison pairing via macOS System Settings succeeded
  • Classic BT: Camera’s SPP/iAP service SDP info retrieved
  • Classic BT: /dev/tty.A1000_21000717 serial port confirmed
  • Protocol analysis: WiFi AP activation flow and the full BLE -> Classic -> WiFi 3-stage gate uncovered

Walls That Couldn’t Be Broken

  • Unifying BLE auth and Classic bonding in a single session (macOS limitation)
  • WiFi AP activation (NOT1 doesn’t arrive on BLE re-auth after Classic bonding)
  • PTP communication via RFCOMM serial port (camera doesn’t respond)

What to Try Next

  • Fix the device ID during BLE auth so the camera recognizes the same device during BLE re-auth after Classic pairing
  • Script the Classic pairing procedure (Mac confirms first, then camera, with tuned timing)
  • Use macOS IOBluetooth API to programmatically execute Classic pairing while BLE is connected
  • Start an SPP server before Classic pairing to accept the camera’s RFCOMM connection

SnapBridge functions as a 3-stage gatekeeper: BLE, Bluetooth Classic, then WiFi. BLE auth and Classic pairing were each individually conquered. The camera recognizes the Mac as a SnapBridge device, and the transfer flag fires after taking a photo. The only remaining challenge is completing both within a single session.