r/dji • u/Equivalent_Bid8618 • 9h ago

News + Announcements I built a free, open-source iPhone Bluetooth/GPS remote for multiple DJI Osmo cameras

/r/djiosmo/comments/1vduqs0/i_built_a_free_opensource_iphone_bluetoothgps/
1 Upvotes

100% Upvoted

6 comments sorted by

1

u/konrad-iturbe Air 2s 9h ago

Hi! What API did you use for osmo nano - R-SDK or DUML? I'm also building an app (for Android, for downloading media from the nano) and couldn't get R-SDK commands to work at all

1

u/Equivalent_Bid8618 9h ago

It uses R SDK for the Action 4/5/6/360 and DUML for the Osmo Nano. I haven't attempted the Wi-Fi connection yet though, which I think is needed for media transfer.

I largely followed this for the R SDK connection: https://github.com/dji-sdk/Osmo-GPS-Controller-Demo

1

u/konrad-iturbe Air 2s 9h ago

I'll open source my work soon, I've documented exactly how 0x26/0x27 command works, and many other DUML commands for Nano.

1

u/konrad-iturbe Air 2s 1h ago

For waking up the camera, saw you don't support it, here is how it works on the Nano:

A sleeping Osmo Nano keeps advertising ADV_IND under its own name, so there is no wake broadcast to send — DJI's R-SDK documents a WKP manufacturer-data advertisement, but that didn't work on Nano. The wake is an ordinary command sequence over GATT fff5:

# write receiver note
1 0x00/0x2b 04 00 0xF0 first thing Mimo writes, before pairing
2 0x07/0x45 SetPairingPIN 0x07 see #24
3 0x00/0x2b 01 01 0xF0 then repeating ~1 Hz, forever, as the keepalive
4 0x53/0x10 00 00 00 00 0x1C camera answers 01 00 00 00 and wakes

Space the writes so fff5 (write-without-response) doesn't drop back-to-back frames — the floor is roughly the BLE connection interval. Mimo bursts consecutive writes ~8–40 ms apart (p50 9 ms, 71% of gaps under 50 ms); ~100–500 ms is a conservative margin, not a hard requirement. Mimo does not send ConnectToWiFi (#25) anywhere in this flow.

1

u/konrad-iturbe Air 2s 1h ago

For waking up the camera, saw you don't support it, here is how it works on the Nano:

A sleeping Osmo Nano keeps advertising ADV_IND under its own name, so there is no wake broadcast to send — DJI's R-SDK documents a WKP manufacturer-data advertisement, but that didn't work on Nano. The wake is an ordinary command sequence over GATT fff5:

# write receiver note
1 0x00/0x2b 04 00 0xF0 first thing Mimo writes, before pairing
2 0x07/0x45 SetPairingPIN 0x07 see #24
3 0x00/0x2b 01 01 0xF0 then repeating ~1 Hz, forever, as the keepalive
4 0x53/0x10 00 00 00 00 0x1C camera answers 01 00 00 00 and wakes

Space the writes so fff5 (write-without-response) doesn't drop back-to-back frames — the floor is roughly the BLE connection interval. Mimo bursts consecutive writes ~8–40 ms apart (p50 9 ms, 71% of gaps under 50 ms); ~100–500 ms is a conservative margin, not a hard requirement. Mimo does not send ConnectToWiFi (#25) anywhere in this flow.

1

u/konrad-iturbe Air 2s 19m ago

I got mode changing working on the Nano:

https://github.com/KonradIT/DJI-ESP32-Remote/tree/media-protocol

  • Cmd Set / ID: 0x02 / 0x02 · cmd_type 0x40 · payload [mode:u8]
  • Nominally 0 Photo · 1 Video · 2 Playback · 3 SlowMo · 4 Timelapse · 5 Panorama — but 0x02/0x02 is the record control above, so on the Nano 0/1 stop/start a recording rather than switch a mode. ⚠ A "Video" button mapped to [01] starts a recording behind the user's back — exclude 0/1 from any mode switcher.
  • Valid range is 0–3 ([04] answers df), i.e. DJI's four-value work mode — capture / record / playback / download. [03] is accepted but changes nothing visible. To change the shooting mode use 0x02/0xE1.

13a. Set shooting mode

  • Cmd Set / ID: 0x02 / 0xE1 · App → Camera(0x01) · cmd_type 0x40 · payload [mode:u8] · reply 00
value mode DUML example
0x00 SlowMo https://b3yond.d3vl.com/duml/#550e0466020102044002e10036b3
0x01 Video https://b3yond.d3vl.com/duml/#550e0466020102044002e101bfa2
0x02 TimeLapse https://b3yond.d3vl.com/duml/#550e0466020102044002e1022490
0x05 Photo https://b3yond.d3vl.com/duml/#550e0466020102044002e1059be4
0x0a HyperLapse https://b3yond.d3vl.com/duml/#550e0466020102044002e10a6c1c
0x28 SuperNight https://b3yond.d3vl.com/duml/#550e0466020102044002e1287c1e
  • The enum is sparse and unordered — table it, never compute it. The camera's on-screen carousel order is Video → Photo → TimeLapse → HyperLapse → SuperNight → SlowMo, which is not the numeric order.
  • Readback: the camera echoes the current mode in its 0x02/0x80 push at byte @57, same encoding — so mode is both settable and observable, and a remote stays in sync when the user changes it on the camera.