Welcome Inspire Pilots!
Join our free DJI Inspire community today!
Sign up

Deep dive into Inspire 1 Firmwares... Trying to debunk the funk...

Joined
Jan 16, 2021
Messages
178
Reaction score
77
Age
53
First off, I want to start by making some observations in regards to the upgrades/downgrades. It would seem as if DJI *REALLY* doesn't want anyone downreving from v01.11.01.50. But, I do believe there is some confusion in regards to how they do it. I do NOT think the hardware in the drone itself has any ability to "lockup"/"freeze"/"brick" in any *real* sense. It is a controller with system modules and will do it's thing.

What I do think is they have engineered things to use the cameras as the "fault" point in doing upgrades/downgrades. If cameras are at certain revisions, I do believe the order in which they do the updates to the the various systems (which include the camera) ends up causing the "issues" people have, including bricking cameras and the Inspire craft itself.

They know the camera is the interface to the MicroSD card. If you screw with that you can prevent downgrades. Change the order of the downgrade and if you try going from say v01.11.01.50 to v01.08.01.00 you will create chaos because they have made multiple revisions to the camera system in the interim firmware updates. They elude to this in their release notes for various cameras by stipulating that with certain revisions you can only go back to certain other revisions (ie, safe revisions to downgrade to). Funny part is that v01.11.01.50 does not have any notes like this, thus they never intend a downgrade once installed at that revision.

I have found a "hack" to get around bricking my own cameras. I have a X3, Z3 and X5. I *DID* brick the X5, but it was a "half-brick" in that the camera starts but doesn't communicate with the aircraft (this happened well before I did more investigating early on). Now I was not willing to sacrifice my other cameras (X3, Z3) so I went the next step and used a FC350Z camera from my Osmo+. Since it identifies as a FC350Z the FC350Z firmware will load with it, but since they hamstrung that camera so the gimbal will not work with the Inspire 1 I figured it would not allow the same "fault" to happen that bricks others X3 and X5 cameras. Now, this assumption might be totally wrong and it might be the fact that it is the Z3 (FC350Z) and they are "immune" to the "fault" that they use to make downgrades difficult, but in any case, I am just letting everyone know what *I* know works.

The rest here will look at the firmwares themselves and try to determine exactly where the radio module changed to cause all the issues in range after the v01.10.01.40 firmware.

Another note is the earliest firmware for the Z3 is the v01.09.01.30 firmware. The next is v01.09.01.40 and then you jump to v01.10.01.40 which is where all the problems start. The only last revision for the Z3 is the v01.11.01.50 that is the latest for all cameras. So the z3 has only had 4 firmwares posted for it that I can find anywhere.

Can we "assume" that major system changes (radio, camera) or flight parameter systems (NFZ, height) changes would cause major firmware revisions (v01.10.x.x vs v01.09.x.x)???

Below is a listing of the various firmwares and the module revisions per the log using a Z3 camera for updates on a Inspire 1v1.

v01.11.0150 v01.10.0140 v01.09.0140 v01.09.0130 System
------------------------------------------------------------------------------
[01 00][00] v2.77.5657 -> v2.73.5514 -> v2.73.5514 -> v0.1.5346 Video Processing Loader ----------
[01 01][00] v2.77.5657 -> v2.73.5514 -> v2.73.5514 -> v0.1.5346 Video Processing App ----------
[01 04][00] v1.11.5658 -> v1.8.5460 -> v1.8.5460 -> v1.7.5327 Camera BCPU ----------
[03 05][00] v34.1.0.5 -> v34.1.0.5 -> v34.1.0.5 -> v34.1.0.5 Flight Controller Loader
[03 06][00] v2.4.20.50 -> v2.4.20.50 -> v2.4.20.18 -> v2.4.20.18 Flight Controller App **********
[04 00][00] v1.31.1.83 -> v1.30.1.47 -> v1.30.1.47 -> v1.30.1.21 Gimbal Master ----------
[04 01][00] v1.4.26.18 -> v1.4.23.18 -> v1.4.23.18 -> v1.4.15.18 Gimbal Module ----------
[04 02][00] v1.4.26.18 -> v1.4.23.18 -> v1.4.23.18 -> v1.4.15.18 Gimbal Module ----------
[04 03][00] v1.4.26.18 -> v1.4.23.18 -> v1.4.23.18 -> v1.4.15.18 Gimbal Module ----------
[05 00][00] v3.0.6.2 -> v3.0.6.2 -> v3.0.6.2 -> v3.0.6.2 Central Board
[09 00][00] v5.0.0.0 -> v5.0.0.0 -> v3.0.0.4 -> v3.0.0.4 Lightbridge Comms **********
[11 00][00] v3.10.0.0 -> v3.9.0.0 -> v3.9.0.0 -> v3.9.0.0 Battery Module
[12 00][00] v1.11.0.0 -> v1.11.0.0 -> v1.11.0.0 -> v1.11.0.0 ESC Module
[12 01][00] v1.11.0.0 -> v1.11.0.0 -> v1.11.0.0 -> v1.11.0.0 ESC Module
[12 02][00] v1.11.0.0 -> v1.11.0.0 -> v1.11.0.0 -> v1.11.0.0 ESC Module
[12 03][00] v1.11.0.0 -> v1.11.0.0 -> v1.11.0.0 -> v1.11.0.0 ESC Module
[17 00][00] v1.1.0.8 -> v1.1.0.8 -> v1.1.0.8 -> v1.1.0.8 VPS Camera Module
[17 01][00] v2.0.1.6 -> v2.0.1.6 -> v2.0.1.6 -> v2.0.1.6 VPS Sonar Module

---- Uprev in module from firmware to firmware
**** Different from v01.09.x.x to v01.10.x.x


This is a refresh on Inspire 1 V2 w/01.11.01.50
----------------------------------------------------------------------
[04 00][00] v1.31.1.77 -> v1.31.1.67 Gimbal Master ======== (no [04 01/02/03])
[08 00][00] v2.14.9.42 -> v2.14.9.42 FPV Feed ++++++++
[01 00][00] v1.22.5037 -> v1.29.5379 Video Processing Loader ========
[01 01][00] v1.22.5037 -> v1.29.5379 Video Processing App ========
[01 04][00] v0.2.4270 -> v0.5.5085 Camera BCPU ========
[03 05][00] v34.1.0.5 -> v34.1.0.5 Flight Controller Loader
[03 06][00] v2.4.20.50 -> v2.4.20.50 Flight Controller App
[05 00][00] v3.0.6.2 -> v3.0.6.2 Central Board
[09 00][00] v5.0.0.0 -> v5.0.0.0 Lightbridge Comms
[11 00][00] v3.9.0.0 -> v3.9.0.0 Battery Module
[12 00][00] v1.11.0.0 -> v1.11.0.0 ESC Module
[12 01][00] v1.11.0.0 -> v1.11.0.0 ESC Module
[12 02][00] v1.11.0.0 -> v1.11.0.0 ESC Module
[12 03][00] v1.11.0.0 -> v1.11.0.0 ESC Module
[15 00][00] v1.1.2.0 -> v1.1.2.0 USB Controller (Camera) ++++++++
[17 00][00] v1.1.0.8 -> v1.1.0.8 VPS Camera Module
[17 01][00] v2.0.1.6 -> v2.0.1.6 VPS Sonar Module
[19 00][00] v1.0.8.96 -> v1.0.8.96 ++++++++

==== Different between Cameras
++++ Additional with X5

Now if we can ascertain which system each item is, we could understand better which function is which. In my research I have come across the following:

[01 xx] Camera (Camera sensor? Camera MicroSD card interface? Gimbals?)
[11 xx] Battery
[12 xx] ESC

Based on the logfile differences between a FC550 (X5) and a FC350Z (Z3) we have major differences in [04 00] as well as [01 00/01/04], along with [08 00]/[15 00]/[19 00] all being present in the FC500 (X5) but not the FC350Z (Z3). Conversely why is [04 01/02/03] missing in the FC550 (X5) vs the FC350Z (Z3)?

Again, the only difference between the logs is one has the FC350Z (Z3) camera mounted vs the FC550 (X5) camera during the firmware load.

Now, it would seem logical that I would install the X3 and do a downgrade to v01.08.01.00 and finish off the listing here, but that is where I am asking if anyone has a v01.08.01.00 logfile available? (hopefully someone has one saved on thier system somewhere)

If so, if you can post the same block of revision chains like I did I can add the v01.08.01.00 revision to the listing above and we can get a complete view of the modules being changed per rev from v01.08.01.00 up to the latest.

I am of the mind that camera revisions only help the cameras do their job better with "fixes" and "enhancements" since they are not part of the rest of the subsystems, thus I want my cameras to all be running the latest (greatest?) revisions available for them, thus "downgrading" the firmware is not an option for me.

Now, there is a tool out there that allows for breaking down the firmware into individual modules. It is used to change flight parameters. I am wondering if it can also be used to "build" a custom firmware that would include, say, everything from the latest firmware (v01.11.01.50), but with the radio module that allows for the best distance while keeping video intact (ie, v01.08.01.00). NOTE: It is not needed, because if you update to v01.11.01.50 and then use a different camera (Osmo+ FC350Z for example) to downgrade the craft, the camera subsystems do not get downgraded. So ultimately a downgraded aircraft to v1.08/v1.09 with a latest-version camera is the same except for the radio/flight controller, which is all we are worried about.

I think if the module functions can be ascertained as to what subsystem each is responsible for, we can move forward in getting that accomplished.

I am still doing research and believe I came across a reference to the subsystem modules, so I will edit with those clarifications if I can find them again.
 
Last edited:
  • Like
Reactions: ImperiumAssertor
OK, so I found the reference I was looking for... looks like:

[01 00] Video Processing Loader (listed as Camera App)
[01 01] Video Processing App (listed as Camera Loader)
[01 04] Listed as Camera BCPU

[04 00/01/02/03] Gimbal Master (Gimbal Modules as 01/02/03)

[03 05] Flight Controller Loader
[03 06] Flight Controller App
[09 00) Lightbridge Transmission Control

[17 00] VPS Camera
[17 01] VPS Sonar

[08 00] FPV Feed (exists on X3 and X5 but not Z3???)
[15 00] USB Controller (for camera, exists on X3 and X5 but not Z3???)
[19 00] FPGA Bitstream (exists on X3 and X5 but not Z3???)


So, it would seem as if [09 00] is the winner for the module that affects the transmission signal for firmwares from v01.10.01.40 on up, or is that a foregone conclusion and [03 06] Flight Controller App is the culprit, or frankly is it both since they probably work hand-in-hand???

I will dig into the flight parameters and see if there is anything in regards to signal strength anywhere.
 
Last edited:
  • Like
Reactions: ImperiumAssertor
Fascinating stuff you’re delving into here! Not sure I understand some of it, like what these [xx xx] numbers in square brackets are representing, and how you’re getting them. Apologies for my ignorance...

I do have v01.08.10.00 installed on my Inspire 1 though, so if you’d like I could send you the .bin, or even the modules, or a log if I can figure out how to do so.

As an aside, not to derail the topic, but I had an issue with downgrading my I1V2 with X5 to 1.08, as during the maiden flight the status light was blinking green about 5 times along with a long red light between the green flashes... then the drone switched off in mid air, instantaneously, and rebooted (heard the startup noise) as it was falling. Not sure if that makes the FW log I could send you ‘ineligible’ (corrupted?) or not. Incidentally, I couldn’t find the proper firmware file with a Wm610_FC550 prefix when I was installing it, so I just renamed a generic file, maybe that was the issue. But the actual FW file (“WM610_FC550_V.01.08.10.00”) I found a copy of a few days ago is exactly the same size as the ‘generic’ one I found... weird huh? Anyway, once I install the ‘proper’ one I could send you a log file of that perhaps. But I digress, it’s a tangent... just still scratching my head about it.
 
The [xx xx] are the module identifiers that say what subsystem they are referring to.

So, [05 00] is the Central Board for example.

Definitely sounds like you had a VERY strange situation mid-flight. Sounds almost like a bad connection somewhere vs something to do with the firmware.

In regards to the "generic file" and the "actual file", I would check where oyu got the generic one from, it may have been labeled for the Inspire 1 Pro, which is the same file as a the WM610_FC550_FW_V01.08.10.00.bin file.

The "Pro" files are either for the FC350Z (Z3) or the FC550 (X5). And as far as I can verify, you cannot use a FC550 file on a Z3 camera setup and vice-versa, so if the firmware updated properly it means that it saw the configuration the firmware was built for, so you are OK.

Actually, there is a logfile in the LOG directory (it is hidden in the main directory of the MicroSD card, ie, normally you only see DCIM, but if you enable the option to see hidden files you can also see MISC, and under there is a LOG directory) and inside there is a WM610_FC550_FW_LOG_AB.txt file inside there. That is the file I would need just to be able to say which versions everything in v01.08.10.00 has.
 
  • Like
Reactions: ImperiumAssertor
To sum things up, the only two modules that make a difference in video range is [03 06] and [09 00]. Since everything I have looked at shows those both got updated at the same time, I would hazard a guess they talk to one another and are dependent on one another as well, so swapping out either one without the other isn't wise.

Basically the only other changes seen per the mapping I did was the firmware in regards to the cameras. Gimbal control and video processing are all on-camera modules, so it would just make sense.

That also reinforces my initial belief that you want the v01.08/v01.09 flight controller and lightbridge comms, but you are better off with the later camera firmware to provide for the best in-use camera experience.

Now, to clarify, this can be accomplished if you have access to a Osmo+ camera (FC350Z). In that case you can upgrade all your cameras and the aircraft to v01.11.01.50, then install the Osmo+ camera and downgrade to v01.08/v01.09 and you will essentially revert to the previous flight controller and lightbridge comms and will leave your cameras on the latest revision. (Note: if you do that, be sure to update your Osmo+ camera to the latest Osmo+ firmware when you are done on the Osmo+ itself with a DEBUG file for that firmware to make sure it updates everything to the latest for that device, since I can verify the Osmo+ camera will be in a bastardized state after you are done doing the Inspire updates.)

End result is (viewed as a set of incremental steps):

V01.08.01.00 - Good Flight Controller and Lightbridge Comms - Limited NFZ configuration
V01.09.01.xx - Updates for Camera/Gimbal/Video Processor/Configuration Data (Expanded Erroneous NFZ)
V01.10.01.40 - Bad Flight Controller and Lightbridge Comms - Updates for Camera/Gimbal/Video Processor/Configuration Data (Expanded Fixed NFZ)
V01.11.01.50 - Updates for Camera/Gimbal/Video Processor/Configuration Data (Expanded Fixed NFZ)
 
To sum things up, the only two modules that make a difference in video range is [03 06] and [09 00]. Since everything I have looked at shows those both got updated at the same time, I would hazard a guess they talk to one another and are dependent on one another as well, so swapping out either one without the other isn't wise.

Basically the only other changes seen per the mapping I did was the firmware in regards to the cameras. Gimbal control and video processing are all on-camera modules, so it would just make sense.

That also reinforces my initial belief that you want the v01.08/v01.09 flight controller and lightbridge comms, but you are better off with the later camera firmware to provide for the best in-use camera experience.

Now, to clarify, this can be accomplished if you have access to a Osmo+ camera (FC350Z). In that case you can upgrade all your cameras and the aircraft to v01.11.01.50, then install the Osmo+ camera and downgrade to v01.08/v01.09 and you will essentially revert to the previous flight controller and lightbridge comms and will leave your cameras on the latest revision. (Note: if you do that, be sure to update your Osmo+ camera to the latest Osmo+ firmware when you are done on the Osmo+ itself with a DEBUG file for that firmware to make sure it updates everything to the latest for that device, since I can verify the Osmo+ camera will be in a bastardized state after you are done doing the Inspire updates.)

End result is (viewed as a set of incremental steps):

V01.08.01.00 - Good Flight Controller and Lightbridge Comms - Limited NFZ configuration
V01.09.01.xx - Updates for Camera/Gimbal/Video Processor/Configuration Data (Expanded Erroneous NFZ)
V01.10.01.40 - Bad Flight Controller and Lightbridge Comms - Updates for Camera/Gimbal/Video Processor/Configuration Data (Expanded Fixed NFZ)
V01.11.01.50 - Updates for Camera/Gimbal/Video Processor/Configuration Data (Expanded Fixed NFZ)
You‘re forgetting another variable which has been proved many times to have an effect on video downlink integrity depending on Version.

The App!
 
You‘re forgetting another variable which has been proved many times to have an effect on video downlink integrity depending on Version.

The App!

Very true, but that is something the end user has 100% control over (both the device being used and the version of the app they are using on said device), and something that is well beyond the scope of simple analysis and development and squarely in the realm of regression testing and version logging (ie, it takes 1000x more time/effort with a serious requirement to develop a fixed methodology to a proper set of tests and evaluations), which is something that DJI themselves severely lacks doing (as evidenced by the end-users feeling like "beta testers" on more than a few occasions).

See, now, being an engineer and having written lots of low-level and apps stuff over the years, I have a real hard time grasping the connection on the app side of things anyways. As in it has to be a pretty poor set of development standards to have the app effect the video playback in a way that makes the feed from the aircraft seem faulty. I mean, I don't have a problem understanding timing, polling, scans, buffer management, even into the area of event management and multi-tasked overlay management, but you would have to imagine that once most of that is written, tested and working, they would basically "leave it the 'F***' alone" from that point on. It boggles my mind how many issues they keep reintroducing into their apps on a regular basis.

Now, if most of that is happening because of major OS revisions, then that just means it should be a matter of finding the fix from there forward until the next major OS revision is needing to be supported. And if that is the case, then everyone should be able to tell the "breakpoints" based on when they do releases for OS revisions.

Oh, and to sum up a direct response to your response, "I fixed the aircraft, you got the app"... :p:D;)
 
Oh, and in regards to "bricking" my X5... I did NOT brick it trying to downgrade.

Whatever happened to it happened because I was told by DJI to do the "DEBUG" file forced firmware upgrade on my craft with the latest (v01.11.01.50) firmware file.

Until I was told to do the DEBUG file forced update, I had another set of issues with the app and whatnot saying things needed to be updated (when in all actuality I think things were already where they needed to be, so was it a firmware mis-match somewhere, or was it an application error???)
 
  • Like
Reactions: ImperiumAssertor
The [xx xx] are the module identifiers that say what subsystem they are referring to.

So, [05 00] is the Central Board for example.

Definitely sounds like you had a VERY strange situation mid-flight. Sounds almost like a bad connection somewhere vs something to do with the firmware.

In regards to the "generic file" and the "actual file", I would check where oyu got the generic one from, it may have been labeled for the Inspire 1 Pro, which is the same file as a the WM610_FC550_FW_V01.08.10.00.bin file.

The "Pro" files are either for the FC350Z (Z3) or the FC550 (X5). And as far as I can verify, you cannot use a FC550 file on a Z3 camera setup and vice-versa, so if the firmware updated properly it means that it saw the configuration the firmware was built for, so you are OK.

Actually, there is a logfile in the LOG directory (it is hidden in the main directory of the MicroSD card, ie, normally you only see DCIM, but if you enable the option to see hidden files you can also see MISC, and under there is a LOG directory) and inside there is a WM610_FC550_FW_LOG_AB.txt file inside there. That is the file I would need just to be able to say which versions everything in v01.08.10.00 has.
Ah thanks for the clarification. Yes I could try looking for the log file for you although I may have formatted the SD card with it still on there. However I’ll be doing it again soon once I fix the camera ? so can post it here then.

re: the versions, I obtained the ‘generic’ from dank downloader, as it only has ‘aircraft firmware’ (it specifies AC in the drop-down menu) and the versions all lack the prefix. This one I found more recently was posted somewhere on these forums in a post asking for that file version. I’ll just have to trust it’s genuine. I just found it odd that they were exactly the same size.

As for the crash, that is a solid theory you have... it does seem too odd to be coincidence though; the FW update record stated “success” but only after claiming that the file was corrupted in an earlier attempt. Possibly because I changed the flight parameters; which is probably why the battery conked out - the parameters had been altered to allow for much higher ascent and descent speeds, and I got a few overload warnings on the way up... after a minute or two of hover, the screen just went black and I could no longer see the Inspire where it had been before! Miracle it survived. Luckily not a soul about; it was 3am lol.

Anyway good luck with your mission, I will help in whatever way I can with my limited knowledge :)
 
Yeah, after my own experiments it would seem as if doing speed mods and such is a worthless endeavor.

Plus the "battery warning" mods don't actually work. I too got a overload warning, it said it was going to land and it came down, I could keep it aloft with pushing the left stick up, but it was too difficult to try to maneuver and there was no way to gain altitude, so in reality the "battery" nanny system is still active regardless of what you choose in the parameters.

In regards to the firmwares you downloaded, yes that utility doesn't keep the right filenames, but you can tell what they are. The "Inspire 1" are the X3 versions, The "Inspire 1 Pro" is the X5 and Z3 versions. You just need to rename them appropriately. It is NOT a "newbie" utility, you are expected to know what you want and how you want it and deal with the filenames properly.
 
From what I know it's the RC who tells the inspire at what signal strength they should work. And the RC takes the gps info from the app, this is how the drone switches between FCC and CE. So probably you should alter the RC firmware as well. But the problem is that the RC can be upgraded or downgraded only by dji go app.
 
From what I know it's the RC who tells the inspire at what signal strength they should work. And the RC takes the gps info from the app, this is how the drone switches between FCC and CE. So probably you should alter the RC firmware as well. But the problem is that the RC can be upgraded or downgraded only by dji go app.
Actually, that is why we run older 1.6.0 firmware with the 1.08/1.09 firmwares.

I have looked into it, and there is no way to go back beyond 1.3 RC firmware and that is what would be required to do a USB-firmware update on the RC. Only if there were a way to "spoof" the ID information and backload a modified file onto the updating device (iOS or Android) before you did the update, it would work. I looked into it, but considering the lack of information on the RC firmwares and almost no interest from the people that have reverse-engineered other stuff in the DJI realm, it is a foregone conclusion to even worry about.

Fact of the matter is we know 1.6.0 works well on the RC and that 1.08/1.09 work well on the aircraft, so that seems to be the magic combination.
 
Actually, that is why we run older 1.6.0 firmware with the 1.08/1.09 firmwares.
A bit offtopic but I also went trough this downgrading because the radio connection was dropping even in VLOS, but after some use with the fw1.08 I've experienced the same problems I had when the drone was on the latest firmware. So I bought RF measuring device and measured the signal strength of every leg/antenna and found inconsistent results which practically could not be caused by any fw. So I simply resoldered all antennas and all problems ended. I'm flying now more than 6 months with the latest fw and never had a glitch in the reception (dual operator). So my conclusion is that the original solder in the antennas degraded, maybe from heavy use of the drone or simply it's matter of time.
 
A bit offtopic but I also went trough this downgrading because the radio connection was dropping even in VLOS, but after some use with the fw1.08 I've experienced the same problems I had when the drone was on the latest firmware. So I bought RF measuring device and measured the signal strength of every leg/antenna and found inconsistent results which practically could not be caused by any fw. So I simply resoldered all antennas and all problems ended. I'm flying now more than 6 months with the latest fw and never had a glitch in the reception (dual operator). So my conclusion is that the original solder in the antennas degraded, maybe from heavy use of the drone or simply it's matter of time.

That was a good catch in your case, but that does fall under "faulty hardware", and I would be shocked if that is a wide-spread issue, but it is good to bring it up none-the-less.

It is well known that the latest firmwares offer shoddy video transmission performance in some cases. At least with the GL658B controller. In almost all cases I have verified with owners, it was that controller paired with Inspire 1 v1 and v2 that are known to have issues on the latest firmwares (v01.11.01.50/v1.7.8).

Now, if you have a Inspire 1 v2 with the T601 specified model number on the aircraft and GL658C controllers, then things might just be 100% fine with the latest firmwares (v01.11.01.50/v1.7.8). But, that is due to the gross increase of radio power made to both the RC and the AC in the last version of the hardware offered.

And, again, I would find it hard to believe that a Inspire 1 v1 with a GL658A controller would be unaffected by the latest firmwares. I have someone else running tests on both his Inspire 1 aircraft, as both are v1 and he has both GL658A and GL658B controllers, so I will wait until he gets back to me on how things operate for him in both single and dual controller configurations. He is going to be testing with known good firmwares (v01.08.01.00/v1.6.0) and the latest firmwares (v01.11.01.50/v1.7.8) on all configurations when he gets a chance. So we will have some decent data to add to the mix at that time.
 
So what is it you are trying to do at this point? Downgrade the aircraft but keep the camera firmware up to date?

No, I was doing that before. This was a validation of how and why.

The whole point here was to figure out what changes are made to the various firmwares.

It was known before that the v01.08.01.00/v1.6.0 was a "fix" for video transmission issues. I had a Z3 camera so the oldest I could go back to was v01.09.01.30, but there was an almost immediate update to v01.09.01.40. I personally needed to know which version did what so I could decide what was best for my situation, which is the "rarest" of the three options, the others being an X3 firmware (most common), X5/Pro firmware (second most common) and of course the Z3/Pro (least common).

Plus it was a matter of trying to determine what changes were made between various firmware revisions. Now we know.
 
First off, I want to start by making some observations in regards to the upgrades/downgrades. It would seem as if DJI *REALLY* doesn't want anyone downreving from v01.11.01.50. But, I do believe there is some confusion in regards to how they do it. I do NOT think the hardware in the drone itself has any ability to "lockup"/"freeze"/"brick" in any *real* sense. It is a controller with system modules and will do it's thing.

What I do think is they have engineered things to use the cameras as the "fault" point in doing upgrades/downgrades. If cameras are at certain revisions, I do believe the order in which they do the updates to the the various systems (which include the camera) ends up causing the "issues" people have, including bricking cameras and the Inspire craft itself.

They know the camera is the interface to the MicroSD card. If you screw with that you can prevent downgrades. Change the order of the downgrade and if you try going from say v01.11.01.50 to v01.08.01.00 you will create chaos because they have made multiple revisions to the camera system in the interim firmware updates. They elude to this in their release notes for various cameras by stipulating that with certain revisions you can only go back to certain other revisions (ie, safe revisions to downgrade to). Funny part is that v01.11.01.50 does not have any notes like this, thus they never intend a downgrade once installed at that revision.

I have found a "hack" to get around bricking my own cameras. I have a X3, Z3 and X5. I *DID* brick the X5, but it was a "half-brick" in that the camera starts but doesn't communicate with the aircraft (this happened well before I did more investigating early on). Now I was not willing to sacrifice my other cameras (X3, Z3) so I went the next step and used a FC350Z camera from my Osmo+. Since it identifies as a FC350Z the FC350Z firmware will load with it, but since they hamstrung that camera so the gimbal will not work with the Inspire 1 I figured it would not allow the same "fault" to happen that bricks others X3 and X5 cameras. Now, this assumption might be totally wrong and it might be the fact that it is the Z3 (FC350Z) and they are "immune" to the "fault" that they use to make downgrades difficult, but in any case, I am just letting everyone know what *I* know works.

The rest here will look at the firmwares themselves and try to determine exactly where the radio module changed to cause all the issues in range after the v01.10.01.40 firmware.

Another note is the earliest firmware for the Z3 is the v01.09.01.30 firmware. The next is v01.09.01.40 and then you jump to v01.10.01.40 which is where all the problems start. The only last revision for the Z3 is the v01.11.01.50 that is the latest for all cameras. So the z3 has only had 4 firmwares posted for it that I can find anywhere.

Can we "assume" that major system changes (radio, camera) or flight parameter systems (NFZ, height) changes would cause major firmware revisions (v01.10.x.x vs v01.09.x.x)???

Below is a listing of the various firmwares and the module revisions per the log using a Z3 camera for updates on a Inspire 1v1.

v01.11.0150 v01.10.0140 v01.09.0140 v01.09.0130 System
------------------------------------------------------------------------------
[01 00][00] v2.77.5657 -> v2.73.5514 -> v2.73.5514 -> v0.1.5346 Video Processing Loader ----------
[01 01][00] v2.77.5657 -> v2.73.5514 -> v2.73.5514 -> v0.1.5346 Video Processing App ----------
[01 04][00] v1.11.5658 -> v1.8.5460 -> v1.8.5460 -> v1.7.5327 Camera BCPU ----------
[03 05][00] v34.1.0.5 -> v34.1.0.5 -> v34.1.0.5 -> v34.1.0.5 Flight Controller Loader
[03 06][00] v2.4.20.50 -> v2.4.20.50 -> v2.4.20.18 -> v2.4.20.18 Flight Controller App **********
[04 00][00] v1.31.1.83 -> v1.30.1.47 -> v1.30.1.47 -> v1.30.1.21 Gimbal Master ----------
[04 01][00] v1.4.26.18 -> v1.4.23.18 -> v1.4.23.18 -> v1.4.15.18 Gimbal Module ----------
[04 02][00] v1.4.26.18 -> v1.4.23.18 -> v1.4.23.18 -> v1.4.15.18 Gimbal Module ----------
[04 03][00] v1.4.26.18 -> v1.4.23.18 -> v1.4.23.18 -> v1.4.15.18 Gimbal Module ----------
[05 00][00] v3.0.6.2 -> v3.0.6.2 -> v3.0.6.2 -> v3.0.6.2 Central Board
[09 00][00] v5.0.0.0 -> v5.0.0.0 -> v3.0.0.4 -> v3.0.0.4 Lightbridge Comms **********
[11 00][00] v3.10.0.0 -> v3.9.0.0 -> v3.9.0.0 -> v3.9.0.0 Battery Module
[12 00][00] v1.11.0.0 -> v1.11.0.0 -> v1.11.0.0 -> v1.11.0.0 ESC Module
[12 01][00] v1.11.0.0 -> v1.11.0.0 -> v1.11.0.0 -> v1.11.0.0 ESC Module
[12 02][00] v1.11.0.0 -> v1.11.0.0 -> v1.11.0.0 -> v1.11.0.0 ESC Module
[12 03][00] v1.11.0.0 -> v1.11.0.0 -> v1.11.0.0 -> v1.11.0.0 ESC Module
[17 00][00] v1.1.0.8 -> v1.1.0.8 -> v1.1.0.8 -> v1.1.0.8 VPS Camera Module
[17 01][00] v2.0.1.6 -> v2.0.1.6 -> v2.0.1.6 -> v2.0.1.6 VPS Sonar Module

---- Uprev in module from firmware to firmware
**** Different from v01.09.x.x to v01.10.x.x


This is a refresh on Inspire 1 V2 w/01.11.01.50
----------------------------------------------------------------------
[04 00][00] v1.31.1.77 -> v1.31.1.67 Gimbal Master ======== (no [04 01/02/03])
[08 00][00] v2.14.9.42 -> v2.14.9.42 FPV Feed ++++++++
[01 00][00] v1.22.5037 -> v1.29.5379 Video Processing Loader ========
[01 01][00] v1.22.5037 -> v1.29.5379 Video Processing App ========
[01 04][00] v0.2.4270 -> v0.5.5085 Camera BCPU ========
[03 05][00] v34.1.0.5 -> v34.1.0.5 Flight Controller Loader
[03 06][00] v2.4.20.50 -> v2.4.20.50 Flight Controller App
[05 00][00] v3.0.6.2 -> v3.0.6.2 Central Board
[09 00][00] v5.0.0.0 -> v5.0.0.0 Lightbridge Comms
[11 00][00] v3.9.0.0 -> v3.9.0.0 Battery Module
[12 00][00] v1.11.0.0 -> v1.11.0.0 ESC Module
[12 01][00] v1.11.0.0 -> v1.11.0.0 ESC Module
[12 02][00] v1.11.0.0 -> v1.11.0.0 ESC Module
[12 03][00] v1.11.0.0 -> v1.11.0.0 ESC Module
[15 00][00] v1.1.2.0 -> v1.1.2.0 USB Controller (Camera) ++++++++
[17 00][00] v1.1.0.8 -> v1.1.0.8 VPS Camera Module
[17 01][00] v2.0.1.6 -> v2.0.1.6 VPS Sonar Module
[19 00][00] v1.0.8.96 -> v1.0.8.96 ++++++++

==== Different between Cameras
++++ Additional with X5

Now if we can ascertain which system each item is, we could understand better which function is which. In my research I have come across the following:

[01 xx] Camera (Camera sensor? Camera MicroSD card interface? Gimbals?)
[11 xx] Battery
[12 xx] ESC

Based on the logfile differences between a FC550 (X5) and a FC350Z (Z3) we have major differences in [04 00] as well as [01 00/01/04], along with [08 00]/[15 00]/[19 00] all being present in the FC500 (X5) but not the FC350Z (Z3). Conversely why is [04 01/02/03] missing in the FC550 (X5) vs the FC350Z (Z3)?

Again, the only difference between the logs is one has the FC350Z (Z3) camera mounted vs the FC550 (X5) camera during the firmware load.

Now, it would seem logical that I would install the X3 and do a downgrade to v01.08.01.00 and finish off the listing here, but that is where I am asking if anyone has a v01.08.01.00 logfile available? (hopefully someone has one saved on thier system somewhere)

If so, if you can post the same block of revision chains like I did I can add the v01.08.01.00 revision to the listing above and we can get a complete view of the modules being changed per rev from v01.08.01.00 up to the latest.
I have several. Some are failed attempts and some are successful. Here is one of the successful attempts. Unfortunately, I don't know which camera. More than likely the X3 on an Inspire 1, v2.

Sans the "Donnie separators," this is the log file verbatim:

=========== Start Donnie separator ==============


========== 2014.01.01 00:00:04 remo-con disconnect======
Packet: WM610_FW_V01.06.00.40_Fcam.bin
Upgrading ...
Result: Success.

========== 2014.01.01 00:00:06 remo-con disconnect======
Packet: WM610_FW_V01.08.01.00.bin
Upgrading ...
Result: Success.

========== 2014.01.01 00:00:07 remo-con disconnect======
Packet: WM610_FW_V01.08.01.00.bin
Result: Abort.
The firmware on the SD card is identical to or older than the current firmware on the device.

========== 2014.01.01 00:00:06 remo-con disconnect======
Packet: WM610_FW_V01.08.01.00.bin
Result: Abort.
The firmware on the SD card is identical to or older than the current firmware on the device.

========== 2016.07.02 15:38:13 =====================
Packet: WM610_FW_V01.08.01.00.bin
Result: Abort.
The firmware on the SD card is identical to or older than the current firmware on the device.

========== 2016.07.02 22:01:14 =====================
Packet: WM610_FW_V01.08.01.00.bin
Result: Abort.
The firmware on the SD card is identical to or older than the current firmware on the device.

========== 2014.01.01 00:00:06 remo-con disconnect======
Packet: WM610_FW_V01.09.01.10.bin
Upgrading ...
Result: Success.

========== 2016.07.05 20:25:25 =====================
Packet: WM610_FW_V01.09.01.10.bin
Result: Abort.
The firmware on the SD card is identical to or older than the current firmware on the device.

========== 2016.07.05 20:27:56 =====================
Packet: WM610_FW_V01.09.01.10.bin
Result: Abort.
The firmware on the SD card is identical to or older than the current firmware on the device.

========== 2014.01.01 00:00:06 remo-con disconnect======
Packet: WM610_FW_V01.08.01.00.bin
Upgrading ...
Result: Success.

========== 2014.01.01 00:00:10 remo-con disconnect======
Packet: WM610_FW_V01.08.01.00.bin
Upgrading ...
Result: Success.

========== 2014.01.01 00:00:06 remo-con disconnect======
Packet: WM610_FW_V01.08.01.00.bin
Upgrading ...
Result: Success.

========== 2014.01.01 00:00:06 remo-con disconnect======
Packet: WM610_FW_V01.09.01.10.bin
Result: Abort.
The firmware on the SD card is identical to or older than the current firmware on the device.

========== 2014.01.01 00:00:06 remo-con disconnect======
Packet: WM610_FW_V01.08.01.00.bin
Upgrading ...
Result: Success.

========== 2014.01.01 00:00:06 remo-con disconnect======
Packet: WM610_FW_V01.08.01.00.bin
Upgrading ...
Result: Success.

========== 2014.01.01 00:00:06 remo-con disconnect======
Packet: WM610_FW_V01.08.01.00.bin
Result: Abort.
The firmware on the SD card is identical to or older than the current firmware on the device.

========== 2014.01.01 00:00:06 remo-con disconnect======
Packet: WM610_FW_V01.08.01.00.bin
Result: Abort.
The firmware on the SD card is identical to or older than the current firmware on the device.

========== 2014.01.01 00:00:06 remo-con disconnect======
Packet: WM610_FW_V01.09.01.10.bin
Upgrading ...
Result: Success.

========== 2014.01.01 00:00:06 remo-con disconnect======
Packet: WM610_FW_V01.08.01.00.bin
Upgrading ...
Result: Success.

========== 2014.01.01 00:00:06 remo-con disconnect======
Packet: WM610_FW_V01.09.01.30.bin
Upgrading ...
Result: Success.

========== 2014.01.01 00:00:05 remo-con disconnect======
Packet: WM610_FW_V01.08.01.00.bin
Upgrading ...
Result: Success.

========== 2014.01.01 00:00:06 remo-con disconnect======
Packet: WM610_FW_V01.08.01.00.bin
Upgrading ...

========== 2014.01.01 00:00:06 remo-con disconnect======
Packet: WM610_FW_V01.08.01.00.bin
Upgrading ...


=========== End Donnie separator ==============

I am of the mind that camera revisions only help the cameras do their job better with "fixes" and "enhancements" since they are not part of the rest of the subsystems, thus I want my cameras to all be running the latest (greatest?) revisions available for them, thus "downgrading" the firmware is not an option for me.

Now, there is a tool out there that allows for breaking down the firmware into individual modules. It is used to change flight parameters. I am wondering if it can also be used to "build" a custom firmware that would include, say, everything from the latest firmware (v01.11.01.50), but with the radio module that allows for the best distance while keeping video intact (ie, v01.08.01.00). NOTE: It is not needed, because if you update to v01.11.01.50 and then use a different camera (Osmo+ FC350Z for example) to downgrade the craft, the camera subsystems do not get downgraded. So ultimately a downgraded aircraft to v1.08/v1.09 with a latest-version camera is the same except for the radio/flight controller, which is all we are worried about.
Interesting. I HAVE used 3 different X5 cameras, all running different firmwares, with great success on my Inspire 1 running v1.08.01.00.



I think if the module functions can be ascertained as to what subsystem each is responsible for, we can move forward in getting that accomplished.

I am still doing research and believe I came across a reference to the subsystem modules, so I will edit with those clarifications if I can find them again.
Good work.

Note: I used my X3 to roll back a friend's Inspire 1 firmware. His X5 camera was repaired by DJI and came back with the latest firmware. It would NOT pair with his Inspire 1. Only the latest firmware installed in the Inspire would allow it to connect to the X5. This was a couple years ago, so my memory is a bit fuzzy on the details. We were in a hurry so I didn't get to take good notes.

D
 
Well, look what I pulled off of one of the MicroSD cards I received with the Inspire 1 v1 I picked up a week ago:

[00010955]========== remo-con disconnect. boot(15) ============
[00011024]Packet [C:\WM610_FW_V01.10.01.40.bin] detected, card sn [0xda6b3dff].
[00011098]Packet upgrade start...

[00011179]Packet checking...
[00011247]Packet vlink 01.10.0140 <-> 01.09.0130.
[00011317]Record vlink 01.09.0130 <-> 01.08.0100 (flow = 0).
[00011386]Done.

[00011457]Version checking[1]...
[00011529][04 00][00] v1.29.0.92 -> v1.30.1.43 need upgrade.
[00011627][08 00][00] v2.14.9.42 -> v2.14.9.42
[00011697][01 00][00] v2.65.5033 -> v2.70.5440 need upgrade
[00011767][01 01][00] v2.65.5033 -> v2.70.5440 need upgrade
[00011858][03 05][00] v34.1.0.5 -> v34.1.0.5
[00011958][03 06][00] v2.4.20.18 -> v2.4.20.28 need upgrade.
[00012077][05 00][00] v3.0.6.2 -> v3.0.6.2
[00012154][09 00][00] v3.0.0.4 -> v3.1.0.0 need upgrade.
[00012277][11 00][00] v3.9.0.0 -> v3.9.0.0
[00012397][12 00][00] v1.11.0.0 -> v1.11.0.0
[00012517][12 01][00] v1.11.0.0 -> v1.11.0.0
[00012657][12 02][00] v1.11.0.0 -> v1.11.0.0
[00012777][12 03][00] v1.11.0.0 -> v1.11.0.0
[00012907][15 00][00] v1.1.2.0 -> v1.1.2.0
[00013017][17 00][00] v1.1.0.8 -> v1.1.0.8
[00013157][17 01][00] v2.0.1.6 -> v2.0.1.6
[00013237][19 00][00] v1.0.8.96 -> v1.0.8.96
[00013309]Done.

That right there PROVES that DJI messed around with the historical firmware images to include later revision subsystems.

If you look at the Lightbridge Comms ([09 00]), v01.10.01.40 originally came with v3.1.0.0, but any time it is downloaded now, it includes v5.0.0.0, same with the Flight Controller App ([03 06]), it came with v2.4.20.28, but was updated to v2.4.20.50.

So I would believe it is safe to say that DJI went back and modified the ORIGINAL release of the v01.10.01.40 to include the later revisions of Flight Controller and Lightbridge Comms.

I would say their motivation was because people would naturally try to go back a single revision, as all of their documentation states you usually can only go back 1 revision if you wish to downrev, which would eliminate people "fixing" their problems. Very very sneaky and not a good way to do business. You NEVER modify a historical firmware image. The most you do is REMOVE an image if you feel it is faulty and dangerous, but to modify it, no way.
 
Oh, I also just noticed, I still have that firmware file from the MicroSD if anyone wants to do any testing... ;)
 
Well, look what I pulled off of one of the MicroSD cards I received with the Inspire 1 v1 I picked up a week ago:

[00010955]========== remo-con disconnect. boot(15) ============
[00011024]Packet [C:\WM610_FW_V01.10.01.40.bin] detected, card sn [0xda6b3dff].
[00011098]Packet upgrade start...

[00011179]Packet checking...
[00011247]Packet vlink 01.10.0140 <-> 01.09.0130.
[00011317]Record vlink 01.09.0130 <-> 01.08.0100 (flow = 0).
[00011386]Done.

[00011457]Version checking[1]...
[00011529][04 00][00] v1.29.0.92 -> v1.30.1.43 need upgrade.
[00011627][08 00][00] v2.14.9.42 -> v2.14.9.42
[00011697][01 00][00] v2.65.5033 -> v2.70.5440 need upgrade
[00011767][01 01][00] v2.65.5033 -> v2.70.5440 need upgrade
[00011858][03 05][00] v34.1.0.5 -> v34.1.0.5
[00011958][03 06][00] v2.4.20.18 -> v2.4.20.28 need upgrade.
[00012077][05 00][00] v3.0.6.2 -> v3.0.6.2
[00012154][09 00][00] v3.0.0.4 -> v3.1.0.0 need upgrade.
[00012277][11 00][00] v3.9.0.0 -> v3.9.0.0
[00012397][12 00][00] v1.11.0.0 -> v1.11.0.0
[00012517][12 01][00] v1.11.0.0 -> v1.11.0.0
[00012657][12 02][00] v1.11.0.0 -> v1.11.0.0
[00012777][12 03][00] v1.11.0.0 -> v1.11.0.0
[00012907][15 00][00] v1.1.2.0 -> v1.1.2.0
[00013017][17 00][00] v1.1.0.8 -> v1.1.0.8
[00013157][17 01][00] v2.0.1.6 -> v2.0.1.6
[00013237][19 00][00] v1.0.8.96 -> v1.0.8.96
[00013309]Done.

That right there PROVES that DJI messed around with the historical firmware images to include later revision subsystems.

If you look at the Lightbridge Comms ([09 00]), v01.10.01.40 originally came with v3.1.0.0, but any time it is downloaded now, it includes v5.0.0.0, same with the Flight Controller App ([03 06]), it came with v2.4.20.28, but was updated to v2.4.20.50.

So I would believe it is safe to say that DJI went back and modified the ORIGINAL release of the v01.10.01.40 to include the later revisions of Flight Controller and Lightbridge Comms.

I would say their motivation was because people would naturally try to go back a single revision, as all of their documentation states you usually can only go back 1 revision if you wish to downrev, which would eliminate people "fixing" their problems. Very very sneaky and not a good way to do business. You NEVER modify a historical firmware image. The most you do is REMOVE an image if you feel it is faulty and dangerous, but to modify it, no way.
Which software are you using to unpack the .bin files in that manner?

D
 

Members online

Forum statistics

Threads
22,277
Messages
210,655
Members
34,326
Latest member
BobbyeriGop