Search YouTube for it there is a video I have done ages ago it. there is also a few threads on here somewhere discussing it.
One requirement is is must be on the latest firmware and you may need to switch the TX and RX lines. As for settings it just the usual Mavlink just like a telem radio. default settings for UART works.
Hi Alex,
Apologies for the dealyed reply. I took the plane out Sunday and didn’t make it past launch 
Anyway, I did some digging and worked out that somehow, probably during a 1am soldering session, I had the TX/RX wired wrong between FC and DJI. Swapped the lines around and presto, MSP works!
So, I can confirm that Arduplane works with MSP support on a Matek F765-Wing!
Thank you for all your hard work thus far.
No worries, all of us at least once did a 1am faulty solder job 
I want to briefly come back to the issue of DJI OcuSync Air unit with Goggles RE and MAVLink support. I did some tests and I am pretty confident that at least with the present FW v01.00.0700 there is no MAVLink support on this DJI equipment.
I hooked up two FTDI converters, one to the Telemetry Tx line, the other to the Telemetry Rx line and observed the output of both with SERIALx_PROTOCOL in ArduPilot Telemetry serial output port set to 1 (=MAVLink1), set to 2 (=MAVLink2) and set to 30 (=MSP).
Only in case of 30 (=MSP), the OcuSync Air Unit keeps polling the data and can convey information back to the Goggles RE. With SERIALx_PROTOCOL set to 1 or 2, I see in the serial capture that the OcuSync Air Unit tries to poll for a brief moment after start (using MSP Protocol, I see “$M” strings), but then stops.
My conclusion is that without the work of Alex, implementing the MSP protocol in ArduPilot, DJI Goggles RE with OcuSync Air Unit would NOT be able to receive telemetry, at least with the presently latest FW.
I would be interested to hear from anybody, who can prove me wrong.
Cheers!
Thanks for the detailed feedback Risto!
Sorry but this is wrong and it natively supported in the last release as I beta tested it for DJI. Also this is why I specifically added it to the Wiki as working.
Here is the video I made showing it working and how to set it up. https://youtu.be/6tCBVynN8EI
There is also at least 2 threads on this forum of other users using it with out issues in Mavlink.
Here is one of them where the user was having issues but he had not updated the firmware
The only bit that does not work correctly is the GPS layout if I recall.
While Alex addition means it works natively with MSP Mavlink works fine on the original RE system.
Dear Ian,
your reply gave me further motivation to look into the issue. And you are right - DJI Goggles RE with OcuSync Air Unit also supports MAVLink. How DJI solved supporting MSP and MAVLink at the same time is quite clever and took me some time to understand. The difficulty lies in the used baud rates. MSP is using 115200 and MAVLink 57600 baud. By looking at the OcuSync Air Unit Telemetry Tx line, I see that it is using 115200 baud MSP and 57600 baud MAVLink after cold start back-to-back to query with which protocol it should talk to the connected flight controller/OSD.
My fault was that I was using 115200 setting in ArduPilot SERIALx_BAUD, also for MAVLink, whereas for MAVLink ArduPilot baud rate needs to be set to 57600 baud (also for the debug-tool… which was an error in my part).
For someone interested in more nitty-gritty detail can read on down below, for someone just to have a brief overview, here’s a quick summary: DJI Goggles RE with OcuSync Air Unit will also output telemetry to ArduPilot with SERIALx_PROTOCOL set to 1 (MAVLink1), it is important that the SERIALx_BAUD is set to 57. With MAVLink you although do not get GPS data (no coordinates, no satellite count) displayed in Goggles RE, whereas with MSP you do.
Here now in detail. What the DJI OcuSync Air Unit is doing on power-up is:
Step 1. OcuSync Air Unit requests using MultiWii Serial Protocol (MSP) at 115200 six values, namely:
1.1) 0x24 0x4D 0x3C 0x00 0x65 0x65, which is MultiWii request for message type 101 “GET MSP_STATUS”.
(0x24 = “$”, 0x4D = “M”, both together are the MSP preamble “$M”, 0x3C is direction and “<” means request, payload length is 0 and message type is 0x65=101=MSP_STATUS, last 0x65 is XOR checksum, which by zero payload length is always the same byte as the message type)
1.2) 0x24 0x4D 0x3C 0x00 0x6A 0x6A, which is MSP Request 106 = GET MSP_RAW_GPS
1.3) 0x24 0x4D 0x3C 0x00 0x6B 0x6B = MSP Request 107 = GET MSP_COMP_GPS
1.4) 0x24 0x4D 0x3C 0x00 0x6C 0x6C = MSP Request 108 = GET MSP_ATTITUDE
1.5) 0x24 0x4D 0x3C 0x00 0x6D 0x6D = MSP Request 109 = GET MSP_ALTITUDE
1.6) 0x24 0x4D 0x3C 0x00 0x6E 0x6E = MSP Request 110 = GET MSP_BAT
And now happens the trick that I was previously not able to decode, as I had my debug tool at 115200 baud - OcuSync switches to 57600 baud and sends out MAVLink v1 frame:
Step 2. 0xFE 0x06 0x00 0x01 0x01 0x42 0x64 0x00 0x01 0x01 0x00 0x01 0xD1 0x80
Here’s the byte-by-byte decoding of the MAVLink v1 telegram:
0xFE MAVLink v1 packet start
0x06 payload size = 6 bytes
0x00 packet sequence 0
0x01 System ID = 1
0x01 Component ID 1
0x42 Message ID 0x42 = 66 = REQUEST_DATA_STREAM
Next 6 bytes are payload 64 00 01 01 00 01 and they mean target system 0x64 = 100, target component = 0, req_stream_id = 1, req_message_rate (uint16) = 1 Hz, 1 start sending
0xD1 low byte of CRC-16 checksum
0x80 high byte of CRC-16 checksum
Step 3. then OcuSync Air Unit switches back to 115200 baud and requests again the 6 values using MSP as in step 1 above.
Step 4. it changes again back to 57600 baud and requests again the same stream start, but now with packet sequence being 1 and a new CRC because of changed content naturally.
After this, OcuSync Air unit stops streaming out (in my case with MatekF405-CTR), as the MAVLink messages from flight controller start coming in. In Goggles RE, I can see orientation, height, speed, battery voltage and current, but no GPS data. GPS presently only works in MSP mode.
In comparison, with flight controller in MSP mode, OcuSync Air Unit keeps repeatedly polling the 6 MSP requests, as in step 1 above (at roughly 100 Hz).
Update: for someone interested, I add two Saleae Logic analyzer software captures of DJI OcuSync Air Unit telemetry Rx and Tx lines during the first 10 seconds after cold start:
Saleae capture of OcuSync Air Unit with ArduPilot in MAVLink1 mode.zip (142.0 KB)
Saleae capture of OcuSync Air Unit with ArduPilot in MSP mode.zip (997.3 KB)
I have flashed version 0.9 for F405-Wing, but in MP no protocol 30 and also no MSP_OSD_* entries …
Are the entries for Yaapus Default OSD Screen also available for download?
Edit: is not necessary… The MSP branch has version 0.7 … FrSky BiDir 0.9 …
Edit2: works perfectly!
What about if you have 2 pair of goggles and put one set in audience Mode will they record the osd ?
Hi Alex
Very new in this hobby and busy with my first build. It is a quad, with a orange cube, kore carrier board, here 2 gps, dji hd goggles and air unit. Can you please help me with the osd setup and how can we compensate for your work and time? Thanks
Hi, what is your issue? I’m sure we can help you get your quad running!
Thanks for getting back to me, how do I connect the air unit to the carrier board and where do I upload the program you wrote?
Sorry for the stupid questions.
Josh
Let’s assume you have your quad working without my code, you probably used Mission Planner or QGC to flash a recent firmware on your Cube Orange: to enable MSP support you need to flash your cube with my version of arducopter.
Please remember that this is experimental code and as such is not the best choice for a beginner, having said that many users are flying it so it probably is mostly all right
After flashing my custom ArduCopter version you need to configure a serial port (telem1 or telem2) to respond to msp protocol.
Let’s say you use telem1: connect the Air Unit to the selected serial port (telem1) using GND, Uart TX and Uart RX, (pick VCC directly from the battery if <= 17.6V) to telem1 GND, telem1 RX and telem1 TX respectively.
Set the following parameters:
SERIAL1_PROTOCOL 30
SERIAL1_BAUD 115
reboot!
A full step by step guide is probably OT but this will get you started!
Thanks Alex will give it a try
No DJI does not support OSD recording at this time, its a clean feed
Hi All,
Can we expect the MSP code to be merged to master soon?
I would be very happy about this as well. It works very well, I have had no hiccups with v0.7 whatsoever.
Hi, don’t know how soon, it’s under review now.
One big question is: will MSP support be enabled for 1MB flash boards
MSP support requires about 9KB of flash and on some 1MB boards there simply is no space left, for instance it will be hard to support it on kakutef7 without disabling something else.
We need people to let us know if MSP support is a “popular” feature among 1MB boards such as:
Hi Alex,
In my opinion as technology moves on it will be more and more popular.
In the world of FPV DJI is simply the best. I know a lot of people who fly INAV simply because of the MSP.
