Reverse Engineering Naza Firmware

[ArshadR]

Does anyone have any information on the type of processor used in the NAZA? Googling has not turned up much. Even better would be if someone has already started disassembling the firmware. I've got a lot of low level experience doing this type of thing and would love to help reverse engineer and document it if anyone has already started with IDA.

This could be invaluable in helping answer a lot of the questions around potential problems in the firmware linked to fly-aways, and things like "is the compass used in ATTI mode?" etc.

If anyone has any info or willing to help with this investigation, please let me know.

 

[marcus_canada]

I think one of the great things about the Nazza is how DJI have implemented developed it into a solid, polished, commercial package that works great out the box.
My mind shudders at the thought of people hacking into it and releasing random firmware's into the wild.

If people were still interested in unstable flight platforms which were flaky, unreliable and which randomly executed the flip-of-death I imagine DJI would be out of business and we'd all have open source KK boards and Ardu's.

 

[ArshadR]

I think one of the great things about the Nazza is how DJI have implemented developed it into a solid, polished, commercial package that works great out the box.
My mind shudders at the thought of people hacking into it and releasing random firmware's into the wild.

If people were still interested in unstable flight platforms which were flaky, unreliable and which randomly executed the flip-of-death I imagine DJI would be out of business and we'd all have open source KK boards and Ardu's.

Fully agree with your basic premise. If I wanted to experiment, it would be a lot easier for me to fool around with one of the open source projects which already have full documentation.

My concern is that it's not quite as polished as you suspect it is, and that this may be the reason for some of the fly-away's. At the very least, it would put my mind at ease if I could have a look at what they're doing. I'm not proposing releasing customized branches of firmware -- I certainly wouldn't want to take on the liability associated with that.

 

[DeweyAXD]

I certainly wouldn't want to take on the liability associated with that.

Not to mention the lawsuit from DJI if you published even a single line of code from their firmware (we may own pysical entity of the Naza but we don't own the software inside it).
If you have the programming skill set you could use Arduino and take information from signals output from the NAZA. Technically that is allowed as you are not modifying the NAZA (or more importantly its code) in any way. This is what FBOSD came from and that was sooo close to being a polished product.

Pretty sure Arduino could be used for finding out if the compass is sending out signals in Atti mode too. Could you hook it through an analogue pin and see what outputs happen in each mode? Not quite there with Arduino myself but the principle seems like that 'could' work?

 

[marcus_canada]

Fully agree with your basic premise. If I wanted to experiment, it would be a lot easier for me to fool around with one of the open source projects which already have full documentation.

My concern is that it's not quite as polished as you suspect it is, and that this may be the reason for some of the fly-away's. At the very least, it would put my mind at ease if I could have a look at what they're doing. I'm not proposing releasing customized branches of firmware -- I certainly wouldn't want to take on the liability associated with that.

I concede that some Phantoms have flown away (As have a great many other non-Nazza birds) but I do not blame the design and programming of the Nazza for that in any way.
- You can't program around equipment failure, poor installation, poor setup or pilot error (Extending to flying in poor conditions or in close proximity to built up areas/machinery/electrical cabling).

If there were an inherent error in the programming, ALL of our Phantoms would have flown away by now.

I really don't get why people don't see that :?:

 

[ArshadR]

I concede that some Phantoms have flown away (As have a great many other non-Nazza birds) but I do not blame the design and programming of the Nazza for that in any way.

Marcus, I'm not sure how you can make that statement without having intimate knowledge of the design/programming of the Naza and post-mortems on every fly-away. Don't assume that just because something comes from a commercial entity, it's fully polished and bug-free. DJI is tiny. There are very large corporations with thousands of programmers and much larger budgets and much tighter quality control that still release buggy firmware. Happens every day.

If there were an inherent error in the programming, ALL of our Phantoms would have flown away by now.
I really don't get why people don't see that :?:

I've been doing this for a long time, so I'm telling you from experience that there are many problems that only manifest themselves in rare conditions. I'll give you an example: A customer I work with demands that we run 20k reboot tests before they certify that it's working correctly. You would think that the exact same code doing the exact same thing would fail on the very first try if there was a problem -- but sometimes it takes 10,000 reboots or 5000 sleep/wake cycles or running the same 3D game looping for 48 hours before the problem shows up.

In the Naza case, it could be a buffer overflow issue that 99% of the time tramples over memory that doesn't impact the GPS coordinates. But that 1% of the time it does and the device is operating in a particular mode (eg. failsafe), it flies off into la-la land.

I'm not saying that there IS a problem, or that their code is buggy -- I'm just suggesting that there is a possibility.

 

[ArshadR]

If you have the programming skill set you could use Arduino and take information from signals output from the NAZA. Technically that is allowed as you are not modifying the NAZA (or more importantly its code) in any way. This is what FBOSD came from and that was sooo close to being a polished product.
:
Pretty sure Arduino could be used for finding out if the compass is sending out signals in Atti mode too. Could you hook it through an analogue pin and see what outputs happen in each mode? Not quite there with Arduino myself but the principle seems like that 'could' work?

It's easy enough to see outputs, whether it's from the IMU or the Compass, but what we really want to see is what is happening inside the IMU. If there's a problem, it's likely going to be in the firmware and how the device is interpreting the various signals/sensors.

 

[mikrob]

I don't think DJI thinks that the software is a problem. They are changing the transmitter frequency on the new Vision models. I don't know why they'd do this unless they believe that some flyaway problems have been caused by the 2.4 ghz on original Phantoms.

 

[DeweyAXD]

I don't think DJI thinks that the software is a problem. They are changing the transmitter frequency on the new Vision models. I don't know why they'd do this unless they believe that some flyaway problems have been caused by the 2.4 ghz on original Phantoms.

The frequency change is simply because they want to use Wifi via from phones to handle the FPV and telemetry (in the same way a Hero3 uses its wifi app). Most modern phones like the Iphone 5 can cope with 5.8ghz for wifi but it would alienate people that will use a second hand Droid or Iphone 3 or 4's for this. They have moved the flight to 5.8ghz which is a really brave move IMO. It makes upgrading your TX to a full range near on impossible (who makes a 5.8?) and if you have anyone using long range FPV antennas around your way there 'could' be a conflict. I really hope that DJI have tested this out REALLY well but I worry for the Beta buyers of the first batch will be the ones in the firing line.

So far as far as I can tell the Vision pins you down to a bespoke DJI battery (not sure stock Lipos will fit), DJI threaded props, DJI handed motors and no TX upgrade option.... is it for a better model or more after purchase sales I wonder? It'll be a great system for people who don't like to tinker though I am sure.

I also must agree in part with ArshadR.... I have dealt with plenty of issues on I.T. equipment in my job caused by poor firmware (usually poorly printed firmware roms). If you think of CPU ram for a moment... they print it all in mass at a certain spec, then they test it for speed... what speed each set tests at dictates what clock speed it is sold as. Personally I don't think this is the main problem for flyaways (just my opioin) but if they are selling 20000 Phantom units a month as they are right now (let alone standalone NAZA's), there is always going to be a percentage of bad eggs in the nest... just simple chaos theory! :mrgreen:

 

[marcus_canada]

I also must agree in part with ArshadR.... I have dealt with plenty of issues on I.T. equipment in my job caused by poor firmware (usually poorly printed firmware roms). If you think of CPU ram for a moment... they print it all in mass at a certain spec, then they test it for speed... what speed each set tests at dictates what clock speed it is sold as. Personally I don't think this is the main problem for flyaways (just my opioin) but if they are selling 20000 Phantom units a month as they are right now (let alone standalone NAZA's), there is always going to be a percentage of bad eggs in the nest... just simple chaos theory! :mrgreen:

That's actually my contention ArshadR is talking about chinks in the programming which he wants to take a look and fix.
I say that sometimes hardware freaks out, you can't program around that, how can you ?

 

[ArshadR]

If you think of CPU ram for a moment... they print it all in mass at a certain spec, then they test it for speed... what speed each set tests at dictates what clock speed it is sold as. Personally I don't think this is the main problem for flyaways (just my opioin) but if they are selling 20000 Phantom units a month as they are right now (let alone standalone NAZA's), there is always going to be a percentage of bad eggs in the nest... just simple chaos theory! :mrgreen:

Silicon chips may hit conditions that they weren't designed for, ie extreme thermals but clock speeds for chips like CPU's, GPU's, memory are all set with margin built-in. They test these things in special thermal clamps/chambers where they artificially force the temperature to maximum operating temp, eg. 95'C, then run the most intensive memory or other virus type apps to push the silicon to its limits and then sweep through the frequencies until it starts failing. They then build in some amount of margin and set that as the frequency for the silicon. There are also all types of other scans and sorting that happens on the wafers and on the chips to bin them based on leakage etc. Anyways.. none of this is relevant to the discussion other than to state that these things aren't arbitrarily set with the expectation that some percentage will fail in the field. Bad chips are discarded up-front. That's not to say that chips don't fail in the field, but if you get even 0.1% failure in the field, you have a big and costly problem. Hopefully we can all agree that it's HIGHLY unlikely that fly-aways are caused due to chip failure.

That's actually my contention ArshadR is talking about chinks in the programming which he wants to take a look and fix.
I say that sometimes hardware freaks out, you can't program around that, how can you ?

Hardware shouldn't ever randomly "freak out" . Not only can you design SW and FW to deal with all manner of failures, it's actually best practice to make sure you implement this type of failsafe in the code. When you encounter intermittent failures, it's not uncommon to trace this back to poorly written code that does not have the hooks to handle these unforeseen scenarios.

Anyhow, going back to my original point, there could certainly be bugs in the silicon or (more likely) in the firmware which could cause problems. These problems could also manifest themselves in very rare situations due to interference from external signals, spurious interrupts, race conditions, etc. I'm not claiming that there are indeed problems with the firmware or that I am qualified to find and fix them but I do have 30+ years experience in the field and might be able to provide some insight.

My contention is that it's plausible that fly-aways are caused because the NAZA thinks it's either getting an RF command when it's not or it's going to failsafe and heading off in a direction that is not the home point. Both can be due to bugs in the FW.

Anyhow, I think we've beaten this one to death. If I do make any headway on this, I'll update the thread.

 

[marcus_canada]

Yep, good luck with it Let us know how you get on although we should probably set up a code system in case DJI are listening in hehehehehe