I recently discovered the DHD D5, which looks like a clone of the JJRC Elfie but sells for a slightly lower price (£15 each, which is a serious bargain). I got a pair of them and I was hoping I'd be able to control them from my scripts straightaway but found out that at least from the software point of view they are significantly different.

What I've learned so far:

- The IP of the quad is 192.168.0.1 and it assigns the tablet the 192.168.0.100 (I haven't check if there's a DHCP that keeps a list of devices with different IPs)

- The control signal from the control app is sent by UDP to port 8080 every 100 ms but the message seems to be different. While in standby, most messages are a single byte 0x25 ("%") with a longer 5 byte message happening every second or so 0x08c0a80164. When the on-screen controls are on, the pattern is similar but you see 11 byte long messages from time to time. I haven't done a TCP dump while flying yet.

- Video is sent by UDP through a connection started by the app on ports 55934 or 577-something. The quad sends a chain of messages containing the video every 46 milliseconds. Assuming these are single frames, it gives some 21 fps, which is more or less the same framerate of the video from the JJRC Elfie.

- The video link is negotiated through a brief TCP conversation through port 7070 that lasts for some 200 ms and contains the following:

>> (from App to Quad)
OPTIONS rtsp://192.168.1.1:7070/webcam RTSP/1.0
CSeq: 1
User-Agent: Lavf56.40.101
<< (from Quad to App)
RTSP/1.0 200 OK
CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
>>
DESCRIBE rtsp://192.168.1.1:7070/webcam RTSP/1.0
Accept: application/sdp
CSeq: 2
User-Agent: Lavf56.40.101
<<
RTSP/1.0 200 OK
CSeq: 2
Content-Base: rtsp://192.168.1.1:7070/webcam/
Content-Type: application/sdp
Content-Length: 122
<<
v=0
o=- 1 1 IN IP4 127.0.0.1
s=Test
a=type:broadcast
t=0 0
c=IN IP4 0.0.0.0
m=video 0 RTP/AVP 26
a=control:track0
>>
SETUP rtsp://192.168.1.1:7070/webcam/track0 RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=19398-19399
CSeq: 3
User-Agent: Lavf56.40.101
<<
RTSP/1.0 200 OK
CSeq: 3
Transport: RTP/AVP;unicast;client_port=19398-19399;server_port=55934-55935
Session: 82838485868788898A8B8C8D8E8F90
>>
PLAY rtsp://192.168.1.1:7070/webcam/ RTSP/1.0
Range: npt=0.000-
CSeq: 4
User-Agent: Lavf56.40.101
Session: 82838485868788898A8B8C8D8E8F90
<<
RTSP/1.0 200 OK
CSeq: 4
Session: 82838485868788898A8B8C8D8E8F90

- Some kind of "heartbeat" is sent to another UDP port (55935, which is the same port as the video + 1).  A short message is sent there every second. I assume this is a way for the quad to know that there's an application reading the video stream. It might be a common video protocol given that the info exchanged in the TCP stream above seems to indicate that a common video streaming protocol is used.

I'm a bit lazy to go through the process of reverse-engineering all this stuff but this quad seems to be more advanced and cheaper than the JJRC, which is an incentive to give it a go. I may start a new project if I have the strength.