Skip to content

Reference: open-source work on Wi‑Fi toy drones (cooingdv / KY UFO and others) #196

Open
Open
Reference: open-source work on Wi‑Fi toy drones (cooingdv / KY UFO and others)#196
Labels
referenceReference material: links, protocols, notes

Description

@compot-dev
compot-dev
opened on Oct 15, 2026

Reference material for #187 (FLOW-UFO) and for toy drones in general (see docs/toys.md).

For FLOW-UFO, look first at anything about the cooingdv family. cooingdv publishes the KY UFO and RC UFO apps, and KY UFO is the app named in the FLOW-UFO manual. The repositories below are grouped by app family.

Most useful: a multi-protocol project

  • marshallrichards/turbodrone: a reverse-engineered API and client to fly popular ~$50 toy drones from a computer instead of the closed mobile apps. The backend is chosen with DRONE_TYPE:

    • s2x (com.vison.macrochip, e.g. S20, S29)
    • wifi_uav (V88, D16)
    • cooingdv (RC UFO, KY UFO)
    • cooingdv_jieli (KY FPV / Jieli CTP, RTP/JPEG video)
    • wifi_cam
    • x69_lg

    Its README describes how to add a new drone: decompile the APK with jadx and look for ports and protocols. The video handling usually lives in native C++ libraries inside the APK.

cooingdv / KY UFO (closest to FLOW-UFO)

  • cklam12345/morphDrone (morph-pilot on PyPI): an MCP server that flies a KY UFO from Claude. From its README: the drone runs an AP at 192.168.1.1, and video is RTSP at rtsp://192.168.1.1:7070/webcam. It also notes that on the KY UFO, pitch and throttle are inverted in hardware.
  • DevloperAnuj/fallarmydetect: a pest-detection project with a section Reverse-engineering notes (KY UFO drone). Its integration is based on decompiling the official app com.cooingdv.kyufo with jadx. Key points from the notes:
    • video is handed to ijkplayer, with no video protocol of its own;
    • UdpClientHeartBeatTask sends {0x01, 0x01} to UDP port 7099 every second.

WiFi UAV (com.lxhd and related)

  • FahrulRPutra/reversing-wifi-uav: reverse engineering of the LSRC-S1S drone.
    • Control commands go to UDP port 8800, and a separate packet turns the stream on.
    • Video arrives from port 1234.
    • A Python script and board photos, including the Wi‑Fi camera module.
  • JadanPoll/DroneUAVHack: a WiFi UAV video stream decoder. The HTB forum thread points out that the standard Huffman, quantisation and chroma tables are not sent in the UDP stream; the client has to supply them.

Other platforms (useful as reference)

  • rooterkyberian/syma, Syma X22W.
    • The camera board is made by Joyhonest.
    • UDP only, with 172.16.10.1; commands go from port :6666 to 172.16.10.1:5555.
    • Hardware: STM32F031K6 + MPU6050, Wi‑Fi on a Marvell 88W8801.
  • karolis1115/DroneHackOpenCV, JJRC H49. The author found an open UART with a U-Boot shell on the separate video/link board, and the Wi‑Fi module runs RT-Thread.
  • zturner1/h120d-protocol, Holy Stone H120D: a full PROTOCOL.md with a byte-level description of the binary protocol on UDP port 8080.
  • MetaIdea/OpenDroneProject: the LSE525 and Eachine E58 protocols, with control through an ESP.

Identifying a model

Check which app the toy's manual names, and what answers on 192.168.1.1. If RTSP is open on 7070 and a heartbeat goes to 7099, it is cooingdv, and turbodrone with DRONE_TYPE=cooingdv should work straight away.

Notes for this app (added by the maintainers):

Activity

  1. compot-dev
    added
    referenceReference material: links, protocols, notes
    on Oct 15, 2026

  2. compot-dev commented on Oct 15, 2026

    @compot-dev
    compot-dev
    on Oct 15, 2026
    CollaboratorAuthor

    What turbodrone's code says (marshallrichards/turbodrone 2c09cf8, Apache-2.0), compared with the FLOW-UFO transport in #188:

    Wi‑Fi name turbodrone backend Toy address Video Notes
    FLOW_… (D16, V88, K417) wifi_uav 192.168.169.1, UDP 8800 (some units 8801) MJPEG fragments 93 01, client ACKs EF 02, the client supplies the JPEG header The same protocol as our FLOW-UFO (the BL60x engine in the vendor libraries). D16 is marked tested there. Their ACK quality bytes are 32 4B 14 2D. Bytes 0x34/0x35 of a fragment are the main and flow camera status. The drone sends from source port 1234
    FLY-UFO-… (K200), KY UFO / RC UFO cooingdv 192.168.1.1 RTSP rtsp://192.168.1.1:7070/webcam, MJPEG heartbeat 01 01 to UDP 7099 every 1 s
    HF_… (YL3), HF UFO app none yet (research notes only) 192.168.80.x Jieli stack: CTP command OPEN_RT_STREAM, RTP/JPEG (or H.264) to the phone's UDP 6666 not implemented there
    KY FPV (Jieli) cooingdv_jieli 192.168.8.15 CTP on UDP 2228, RTP/JPEG to local UDP 6666, keepalive every 1 s first pass, not validated on hardware
    WiFi_CAM wifi_cam 192.168.4.153 UDP 8080: 42 76 starts the stream; complete JPEGs in 0x5C0-byte datagrams, no ACKs

    The subnet is a good hint for the family: 192.168.169.x is FLOW-UFO, 192.168.1.x is KY UFO RTSP, 192.168.80.x or 192.168.8.x is Jieli, and 192.168.4.153 is WiFi_CAM.

  3. compot-dev commented on Oct 15, 2026

    @compot-dev
    compot-dev
    on Oct 15, 2026
    CollaboratorAuthor

    HF_… toy (YL3), from a PCAPdroid capture of the vendor app (phone → 192.168.80.1; 2026-10-08, ~114 s)

    What Observed
    Device GET http://192.168.80.1:8080/mnt/spiflash/res/dev_desc.txt returns JSON with "product_type": "AC79X_wifi_car_camera" (Jieli AC79), "firmware_version": "79.2230.12.6M02.HFFLOW.1CH", "match_app_type": "DVRunning 2", "rtsp_forward_support": "0"
    Control TCP 3333, CTP messages: CTP: + topic length u16 LE + topic + JSON length u32 LE + JSON
    Session start → APP_ACCESS {"op":"PUT","param":{"ver":"25","type":"0"}}. ← KEEP_ALIVE_INTERVAL {"timeout":"60000"}, SD and battery status, VIDEO_PARAM {"w":"640","h":"480","format":"0","fps":"25"}. → DATE_TIME {"op":"PUT","param":{"date":"YYYYMMDDhhmmss"}}, → CTP_KEEP_ALIVE {"op":"PUT"}
    Keepalive CTP_KEEP_ALIVE {"op":"PUT"} about every 7.5 s; the device answers with an empty CTP_KEEP_ALIVE
    Stream on → OPEN_RT_STREAM {"op":"PUT","param":{"format":"0","h":"480","w":"640","fps":"25"}}, then ← OPEN_RT_STREAM NOTIFY (~0.5 s later)
    Stream off → CLOSE_RT_STREAM {"op":"PUT","param":{"status":"1"}}
    Flight → FLIGHT_CONTROL {"op":"PUT","param":{"DRONE_DATA":"…"}} over CTP. Stick packets 66 14 80 80 80 80 … 99 (20 bytes) go to UDP 3456, plus 00 every 0.5 s before the session and 8/10-byte zero packets after the stream starts
    Video Not in the capture. Without root, PCAPdroid only sees traffic through its VPN, while the video comes to the phone's Wi‑Fi address. From turbodrone's research on the same stack it is RTP/JPEG (payload type 26) to the phone's UDP 6666; not yet confirmed for this unit

    Other notifications seen: PULL_VIDEO_STATUS / PULL_VIDEO_PARAM (1280×720, format 1 and 0), CAMERA_TYPE → CTP_NO_TOPIC_MSG, and AP_SSID_INFO.

  4. compot-dev
    added a commit that references this issue on Oct 15, 2026

    feat: FLOW-UFO after turbodrone (both ports, quality bytes, lagging s…

    b898ca1

  5. CatRovacer commented on Oct 15, 2026

    @CatRovacer
    CatRovacer
    on Oct 15, 2026

    First shot, for K200 work rtsp://192.168.1.1:7070/webcam nice video streaming, but good idea rotate ccw and landsscape orientation. ))) And split to 2 screens, for two eyes
    flyufo:// no video
    App for D16 - WIFI UAV

  6. CatRovacer commented on Oct 15, 2026

    @CatRovacer
    CatRovacer
    on Oct 15, 2026

    stats.json и log слишком велики для выкладывания непосредственно в комментарии (((

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    referenceReference material: links, protocols, notes

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions