Controller revA vs revB

No according to DJI the hardware decode function has nothing to do with A or B spec mofdel, its the internal graphic processing unit of the ipad. You can switch it on or of with that function. when its on the internal ipad GPU make the decoding, otherwise its the normal CPU. But yes, i wonder why the remote controller has this internal video decoder
Hello there,
On the ver_B or if you have a ver_B I heard that the option is no longer available in the Go-App... or greyed out...can you find out if this is true for me...I only have access to the ver_A RC...!!! ;-)
 
Hardware decode on or off should be the internal GPU of the ipad, not the remote controller. Thats what DJI said a long time ago but i agree it also sounds plausible that it could mean the internal hardware decode of the remote controller but that according to DJI its not like that. I think hardware decode on or off can only be used with some IOS devices otherwise its greyed out.
Hello there,
Say...I am hoping you have a ver_B RC...could you take a look for us if you do I was told that this option is only greyed out on the ver_B RC because there is no video processing hardware in it...that will clear things up for me...as to if the switch is only for the internals of the mobile device used only...!!! ;-)
 
Hello there,
Say...I am hoping you have a ver_B RC...could you take a look for us if you do I was told that this option is only greyed out on the ver_B RC because there is no video processing hardware in it...that will clear things up for me...as to if the switch is only for the internals of the mobile device used only...!!! ;-)
I have the A version in my early Phantom3. hmm, ok i did not know that with the greyed out. I always thought the hardware decode button appeared only for ios devices, not for android and i was told its the internal gpu switch of the tablet. Would be interesting when b spec remotes are greyed out
 
This was posted on an Italian Phantom 3 site and translated via Google Translate:

if true, it may account for why some people get lagging and video glitches even when using same display devices.
===========================================================

After analyzing and collecting the experiences had during the last firmware updates by users with the Phantom 3, especially in relation to upgrading the RemoteController, we discovered, doing research on the web, some very interesting things about their characteristics radio supplied with the drone of home DJI ...
Apparently the boys, there would be two radio models on the market, the GL300A and GL300B (you can read the code on the back of your RC, at the bottom, as in the picture). What are the differences between the two models?
- GL300A (the model "old"), would be equipped with video processor "DaVinci" TMS320DM368 Texas Instruments (http://www.ti.com/product/tms320dm368) and USB 2.0 controller CY7C68013 of Cypress (http: / /www.cypress.com/file/138911/download)
- GL300B (the model more "recent"), would without a video processor "DaVinci", but would instead be equipped with USB 3.0 (not 2.0 as in version A) CYUSB2014 of Cypress (http://www.cypress.com / file / 140296 / downloads) and sensing of charge CW2015CWAD CellWise (http://www.cellwise-semi.com/en/pro_show.asp?id=1498), not present on version A. Additionally, other difference, B apparently can be refreshed only via app and not via USB ...
So, in summary in plain English, the GL300A have an internal hardware for better performance management and encoding (or decoding) video stream, while the GL300B higher speed connection to the tablet / smartphone ...
This leads us to make some arguments and ask ourselves some questions, to which we would like to answer with you ...
First, why these two models of radio? Are linked to the model of the drone (professional / advanced) or only to the period of production? And, if they are related only to the period of production, because this rethinking by DJI during construction?
POSSIBLE SCENARIOS:
SCENARIO 1:
two different strategies of management of the video stream:
- A more in capacity of internal processing;
- In B "delegation" or part of the calculation to the CPU / GPU of the mobile device (this also justifies the presence of USB 3.0 port for sending data faster than the tablet / smartphone).
SCENARIO 2:
with model B the DJI decided not compress more direct flow to the USB port (disappearance of video processing), being therefore the need for greater "capacity" data (the appearance of the USB 3.0 controller).
And finally, we throw there, but if the problems of overheating of the mobile device that presented above with the previous firmware, were linked to one of the two versions of the radio in particular (and maybe the B that "stresses" more smartphone / tablet)?
We do not have answers for now, and maybe ours are simple inferences who knows (maybe they are also wrong to our sources), but we'd like to do with you a census data and a series of surveys to understand something more ... Please, if you are interested or want to make your contribution, join our group affiliated https://www.facebook.com/groups/1566114093641842/, thanks
Grazie mille per il tuo racconto interessante. :)

I have two P2P controller and both Rev. A - I thought my backup one could be P2A, but (now) it's good to obtain perfectly the same thing. ;-) One is very early lot (ordered on the next day of the DJI show, first few thousand) and another one is mid-May production.
My guess is, the "Da Vinci" (not "Leonard"? :) ) chip is "remains" or "caecum" from Inspire controller. Many guys estimates:

(camera) raw stream ->(P3) H.264 encode -> (transmitter)...(radio)...>(receiver) ->
--> (rev. A) H. 264 decode (Da Vinci) H. 264 encode --(USB 2)--> (tablet) H.264 soft decode
--> (rev. B) --(USB 3)--> (tablet) H.264 soft decode

but if so, what for the Da Vinci chip? If only for bitrate covert, it is too much for DJI to prepare app so that decode two kinds of stream from different controllers. Also even USB2 has max. 480Mbps bitrate, 100x faster enough than P2 video stream. Without re-encoding, tablet CPUs have enough ability to decode few-60 fps, as usually decoding Youtube footages. If DJI modifies I1 controller and sell it as P3 controller in initial revision, it can be explained as:

--+--> (I1 RC) H. 264 decode (Da Vinci) H. 264 encode -->(HDMI) display
+--> (USB 2)--> (tablet) H.264 soft decode

--+--> (rev. A) H. 264 decode (Da Vinci) H. 264 encode -->x
+-->(USB 2)--> (tablet) H.264 soft decode

P.S. If my estimation is right, the "HDMI adaptor" is for Rev. B owners... Rev. A can output HDMI directly, and adding "HDMI adaptor" onto Rev. A, there're two Da Vinci's... too many genius. :)
 
I bought mine 2 weeks ago on Amazon. Control rev. A. Doesn't make a lot of sense, since has just arrived. Interestingly, I've manage to make at round 30 flights without ANY issue with the control or the app (iPhone 6, ipad air 2). Today I made my first flight since the recent update (controller, aircraft and app) and for the FIRST time, the app crashes in my iPad, and the iPad reboot!!!! With the aircraft in the air! Luckily, I could handle the stress of the situation, and just waited the reboot process of the iPad, and open the app again, with no problem. Also, the aircraft only reached 200 mtrs high, until completely loses signal.. Pretty weird. Tomorrow I'll fly again and check those issues.
 
Without a tear down of A and B ver with a bit of reverse engineering these are only speculation. Many different solution can be used. And for sure there's lot of project borrowed from I1.
 
I checked my 3 RC and are all GL300A ... so no chance to check difference on my own :oops:..
 
Grazie mille per il tuo racconto interessante. :)

I have two P2P controller and both Rev. A - I thought my backup one could be P2A, but (now) it's good to obtain perfectly the same thing. ;-) One is very early lot (ordered on the next day of the DJI show, first few thousand) and another one is mid-May production.
My guess is, the "Da Vinci" (not "Leonard"? :) ) chip is "remains" or "caecum" from Inspire controller. Many guys estimates:

(camera) raw stream ->(P3) H.264 encode -> (transmitter)...(radio)...>(receiver) ->
--> (rev. A) H. 264 decode (Da Vinci) H. 264 encode --(USB 2)--> (tablet) H.264 soft decode
--> (rev. B) --(USB 3)--> (tablet) H.264 soft decode

but if so, what for the Da Vinci chip? If only for bitrate covert, it is too much for DJI to prepare app so that decode two kinds of stream from different controllers. Also even USB2 has max. 480Mbps bitrate, 100x faster enough than P2 video stream. Without re-encoding, tablet CPUs have enough ability to decode few-60 fps, as usually decoding Youtube footages. If DJI modifies I1 controller and sell it as P3 controller in initial revision, it can be explained as:

--+--> (I1 RC) H. 264 decode (Da Vinci) H. 264 encode -->(HDMI) display
+--> (USB 2)--> (tablet) H.264 soft decode

--+--> (rev. A) H. 264 decode (Da Vinci) H. 264 encode -->x
+-->(USB 2)--> (tablet) H.264 soft decode

P.S. If my estimation is right, the "HDMI adaptor" is for Rev. B owners... Rev. A can output HDMI directly, and adding "HDMI adaptor" onto Rev. A, there're two Da Vinci's... too many genius. :)
Hello there,
Thank`s for the input...so very helpful to the database...are you also in the codeX...development and test resources team...???...if so could you let me know which compiler you are using to test your theories...and to run your code....or are your findings hardware only via text reader...I see by your data the use hardware decoding switch is in the on position...is that how you fly..!!! ;-)
 

Members online

Forum statistics

Threads
143,054
Messages
1,467,297
Members
104,919
Latest member
BobDan