Hi Mad, the P1 and the S1 are the core of the SDR coding/encoding Ocusync protocol. The S1 chip decodes only the part of the Ocusync relating to the communication of the commands, extrapolates the ocusync packets and sends the video part to the smartphone that will manage the video stream. For this it is also a bit slower and dependent on the decoding speed of the smartphone. Instead, the P1 decodes all of the Ocusync, including the video. In fact we find it in the DJI FPV where there is no smartphone. It is likely that they have also decided to insert it in the new SmartController to speed up the decoding operations. It is a rather common situation for example in DVB-S2 digital communications: adding the header, scrambling, encoding, FEC, interleaving, etc., are performed by an FPGA, the rest by a CPU but an FPGA can also do everything, it depends on the speed you want to achieve in decoding. But a CPU can do it all too. It is full of examples in GnuRadio.
This is eye-opening. It really helps understand why DJI isn't totally backwards compatible. I'm sure it can be forced, but at the cost of reliability. Thank you!
Very good. For a long time I could only find shallow information about the transmission systems of DJI Drones and finally I found a very in-depth technical explanation. Thank you very much
Nice detailed post. You explained alot but the P4P V2.0 wasn't mentioned. It's an O2 machine. Just wondering how it fits in the grand scheme of things 😎
Coming from software development background. It all sounds like Ocusync is not a software product in itself. It is probably a set of libraries/protocols/standards they develop and use to achieve certain things. You end up having (probably) 6 or 7 "OcuSync" software products using it, which while similar are not the same thing and are not out of the box compatible with eachother. In this moment the only thing that a company can do is throw the marketing department that are really good at solving such problems. They say "OK, ok, ok... enough of this, lets assign generational names - OcuSync 1,2,3,+,++ which would separate these implementation in terms of the time they were released and the relative capabilities they have (bitrate, fps, resolution, range)" This way of thinking can easily explain the confusion that we have when we see a few systems labeled the same but behaving differently and being incompatible between eachother.
A very interesting and informative presentation. I will certainly have to watch it at least one more time to learn the information that is important to me (the user of the Ocusync system in the Mavic Pro with goggles and Ocusync 2 in the Mavic mini 2)!
Awesome explanation. If this is true, Air unit for FPV system should be compatible with V2 controller. Maybe Just needed to unlock it. but if unlocked then we wont purchase another controller. Hmph... Got to buy then... why not let customer happy.
Sort of wonder how long they are planning to use P1/S1 for. It's been couple years, so I wonder if they planning to stick with it for a while, or are we bound to be testing P2 sooner rather than later.
Great explanations, very well done! Appatently. DJI is not caring a lot to protect the „investments“ of us customers. The more „professional“ the product, the better it should be downward compatible (SC and transmission system)!
Aloha - not that technical but your explanation was clear and concise and I would like to think I understood it… Couple of questions… DJI originally said that they would make the new goggles compatible with the Air 2s that is why we bought one… is this possible/probable? And the new RC Pro, will that work with the Air 2s. Love your channel - mahalo.
Safe to say that surely no one is more confused about Ocusync * than DJI :). As I've said before, this chaos in their product lines is certainly a direct reflection of an equivalent level of chaos in the conference rooms at DJI themselves. The usual result when a small software/hardware company is forced to become a large software/hardware company. Typically, they make the transition gleefully with increased investments in sales/marketing, but refuse to execute the transition over on the R&D and manufacturing side (the small company naiveté that this kind of penny-pinching is how you achieve long-term success). I've worked for several of these outfits over the last couple decades, so I recognize the symptoms. The move to a programmable ASIC, though, is at least a recognition that they have to reuse something at some point in time, or they'll simply become too toxic of a workplace to keep their developers and the resulting Brain Drain will simply kill them. So I guess at least two or three chips are being reused now. Maybe eventually they'll get the drift and figure out the whole enchilada of large scale R&D and production.....
Thx for that insight. That was really something. What I still don't understand when you talk about bandwith as a possible issue for the SC not really being compatible with the Mavic 3: M2P specs say, they transfer 1080p/30 with 12 MBit/s (no mentioning of the latency). Air 2S is reported 1080p/30 12 MBit/s (130 ms, + 10 ms to the included RC) in their specs, so what additional bandwith does keep the chip struggling and let it get to its limits with the same input conditions? I fully understand, that 1080p/60 is not feasible with their O3+ as on their lates Mavic 3 but as you mentioned several times, it is all software based, and DJI certainly could improve and even make a compatibility mode with less resolution, say 720p/30 if processing power is the reason why. I just want to ask, where the lack of bandwith should come from between M2P and Air 2S? Isn't a halfbaked software im terms of compatibility on the SC for the Air 2S another chance?
I dont believe he said bandwidth. Its the processing power of the chip. SC had a older chip that doesnt seem to be able to handle O2 as well. Couple it with the Air2S which runs a newer firmware and it struggles. Mainly the Video. The RC-N1 which has the S1 chip ( i think he said ) handles it fine because your smart device handles the video.
you're a legend my friend. I listened to you and had a cup of tea with multiple times i paused and went back to what you said. I think you got it right though. Thank you for this video
This is just the video I was looking for. Great job! So the hardware in the standard mavic 3 controller, the shit controller, supports occusync 3+. That's why people are getting great range with the shit controller, as evidenced by the mavic 3 range tests on TH-cam. Myself, I only care about range in the controller, not frame rate, resolution, or latency, as long as it's not real bad. Since the US version gets twice the range as the European version, smart Europeans should buy the US version. It's also good, you explained why the original smart controller, doesn't work with the mavic 3.
![[MV] A leap of faith...ความเชื่อใจครั้งสุดท้าย (From "Petrichor the series")](http://i.ytimg.com/vi/U1piZH2CNXA/mqdefault.jpg)
Hi Mad, the P1 and the S1 are the core of the SDR coding/encoding Ocusync protocol.
The S1 chip decodes only the part of the Ocusync relating to the communication of the commands, extrapolates the ocusync packets and sends the video part to the smartphone that will manage the video stream.
For this it is also a bit slower and dependent on the decoding speed of the smartphone.
Instead, the P1 decodes all of the Ocusync, including the video. In fact we find it in the DJI FPV where there is no smartphone.
It is likely that they have also decided to insert it in the new SmartController to speed up the decoding operations.
It is a rather common situation for example in DVB-S2 digital communications: adding the header, scrambling, encoding, FEC, interleaving, etc., are performed by an FPGA, the rest by a CPU but an FPGA can also do everything, it depends on the speed you want to achieve in decoding.
But a CPU can do it all too. It is full of examples in GnuRadio.
This is eye-opening. It really helps understand why DJI isn't totally backwards compatible. I'm sure it can be forced, but at the cost of reliability. Thank you!
Very good.
For a long time I could only find shallow information about the transmission systems of DJI Drones and finally I found a very in-depth technical explanation. Thank you very much
Fantastic.
Awesome explanations! Many questioned on the generation of Ocusync I had were answered in this video. Thank you for sharing.
Awesome episode. This clears up a lot of questions I've had. Thanks for sharing so we can all understand.
Videos like this show me how little I really know about this technology!
Great video Ian, thank you for all the effort that has gone into this well done:-)
wow what a really knowledgeable person you are, this was truly informative video.
Nice detailed post. You explained alot but the P4P V2.0 wasn't mentioned. It's an O2 machine. Just wondering how it fits in the grand scheme of things 😎
Yea I left it out as it’s basically a side step after the M2 but before the FPV. It’s using Leadcore and basically is identical to the Mavic 2.
Rare moments that I see the internal of drones!
You should have J. Bardwell look at this video.
Hehe good one
Nice content showing us the insides. Most vloggers just show the obvious comparison.
Glad to have stumbled on this video. Explains a lot!
Thanks for giving us some insight on this!
Coming from software development background. It all sounds like Ocusync is not a software product in itself. It is probably a set of libraries/protocols/standards they develop and use to achieve certain things.
You end up having (probably) 6 or 7 "OcuSync" software products using it, which while similar are not the same thing and are not out of the box compatible with eachother.
In this moment the only thing that a company can do is throw the marketing department that are really good at solving such problems.
They say "OK, ok, ok... enough of this, lets assign generational names - OcuSync 1,2,3,+,++ which would separate these implementation in terms of the time they were released and the relative capabilities they have (bitrate, fps, resolution, range)"
This way of thinking can easily explain the confusion that we have when we see a few systems labeled the same but behaving differently and being incompatible between eachother.
A very interesting and informative presentation. I will certainly have to watch it at least one more time to learn the information that is important to me (the user of the Ocusync system in the Mavic Pro with goggles and Ocusync 2 in the Mavic mini 2)!
Awesome explanation. If this is true, Air unit for FPV system should be compatible with V2 controller. Maybe Just needed to unlock it. but if unlocked then we wont purchase another controller. Hmph... Got to buy then... why not let customer happy.
Great explanation pal.
Are you going to revisit this and add O4 to the mix? O4 is Triband now I believe.
Yea there needs to be an update.
Amazing work! Will be a standard reference video for many from now on.
I'd like to see compatibility between DJI goggles v1 or 2 and mavic 3...
Thanks Man
Sort of wonder how long they are planning to use P1/S1 for. It's been couple years, so I wonder if they planning to stick with it for a while, or are we bound to be testing P2 sooner rather than later.
Great explanations, very well done! Appatently. DJI is not caring a lot to protect the „investments“ of us customers. The more „professional“ the product, the better it should be downward compatible (SC and transmission system)!
what a knowledge you have ... amazing! Thx for sharing ¶ :-)
Aloha - not that technical but your explanation was clear and concise and I would like to think I understood it… Couple of questions… DJI originally said that they would make the new goggles compatible with the Air 2s that is why we bought one… is this possible/probable? And the new RC Pro, will that work with the Air 2s. Love your channel - mahalo.
Don't want to rain on your parade, but occusync started on the first mavic pro, not on the 2nd, like it says in your description.
Yea that was a typo thanks for the heads up
@@MadRC yes, I saw it was a typo because of what you said in the video.
Safe to say that surely no one is more confused about Ocusync * than DJI :). As I've said before, this chaos in their product lines is certainly a direct reflection of an equivalent level of chaos in the conference rooms at DJI themselves. The usual result when a small software/hardware company is forced to become a large software/hardware company. Typically, they make the transition gleefully with increased investments in sales/marketing, but refuse to execute the transition over on the R&D and manufacturing side (the small company naiveté that this kind of penny-pinching is how you achieve long-term success). I've worked for several of these outfits over the last couple decades, so I recognize the symptoms.
The move to a programmable ASIC, though, is at least a recognition that they have to reuse something at some point in time, or they'll simply become too toxic of a workplace to keep their developers and the resulting Brain Drain will simply kill them. So I guess at least two or three chips are being reused now. Maybe eventually they'll get the drift and figure out the whole enchilada of large scale R&D and production.....
Great post.
Thx for that insight. That was really something.
What I still don't understand when you talk about bandwith as a possible issue for the SC not really being compatible with the Mavic 3: M2P specs say, they transfer 1080p/30 with 12 MBit/s (no mentioning of the latency). Air 2S is reported 1080p/30 12 MBit/s (130 ms, + 10 ms to the included RC) in their specs, so what additional bandwith does keep the chip struggling and let it get to its limits with the same input conditions?
I fully understand, that 1080p/60 is not feasible with their O3+ as on their lates Mavic 3 but as you mentioned several times, it is all software based, and DJI certainly could improve and even make a compatibility mode with less resolution, say 720p/30 if processing power is the reason why. I just want to ask, where the lack of bandwith should come from between M2P and Air 2S? Isn't a halfbaked software im terms of compatibility on the SC for the Air 2S another chance?
I dont believe he said bandwidth. Its the processing power of the chip. SC had a older chip that doesnt seem to be able to handle O2 as well. Couple it with the Air2S which runs a newer firmware and it struggles. Mainly the Video. The RC-N1 which has the S1 chip ( i think he said ) handles it fine because your smart device handles the video.
Going flying soon
you're a legend my friend. I listened to you and had a cup of tea with multiple times i paused and went back to what you said. I think you got it right though. Thank you for this video
Technically the Ai2/S shoud work with the DJI Googles V2 , hmmm??!
Someone was paying attention ;).
Great, thinks...
First air2 s army out
This is just the video I was looking for. Great job! So the hardware in the standard mavic 3 controller, the shit controller, supports occusync 3+. That's why people are getting great range with the shit controller, as evidenced by the mavic 3 range tests on TH-cam. Myself, I only care about range in the controller, not frame rate, resolution, or latency, as long as it's not real bad. Since the US version gets twice the range as the European version, smart Europeans should buy the US version. It's also good, you explained why the original smart controller, doesn't work with the mavic 3.