Drone Maker DJI Rolls Back Update that Blocked Flights in DC Airspace

Drone Maker DJI Rolls Back Update that Blocked Flights in DC Airspace e-Reading Hardware After being embarrassed when a customer crashed one of its drones on White House grounds, and then rushing out a firmware update to make sure it doesn't happen again, drone maker DJI is back in the news again today.

It seems that hastily released firmware wasn't quite as ready to be released as DJI thought. They're now advising customers to revert to an earlier firmware, and are reporting on their website that some users are having issues:

There have been a small number of reported issues with the latest Phantom firmware, v3.10. In response to these reports, DJI has proactively suspended this firmware update.

In addition to the unspecified bugs, this update was also supposed to add an automatic enforcement of the FAA-mandated no fly zone centered on Washington DC. The FRZ, or flight restricted zone, is an area where it is illegal to fly anything from a model airplane to a full size aircraft, a fact which DJL acknowledges on their website. This includes drones, although of course that never stopped drone owners from ignoring the rules.

DJI had already blocked flights in the flight restricted zone surrounding airports, and this update extended that block to include DC.

Only something went wrong, and DJI isn't talking. I first read about this story early this morning, and I've spent a few hours browsing the DJI forums. The worst I've found so far are a few posts that the drone misbehaved after the update.

For example, one user has reported that while running the new firmware, his drone had problems with the battery sensors, and kept declaring the batteries as invalid. A downgrade fixed the problem.

That might not strike you as being enough to go back to the old firmware, but we are talking about $1,000 drones here. If one developed that fault mid-flight it would soon become a very expensive piece of abstract performance art: Drone Descending a Staircase, as it were.

As always, testing for bugs simply can't be rushed.

Nate Hoffelder

View posts by Nate Hoffelder
Nate Hoffelder is the founder and editor of The Digital Reader: He's here to chew bubble gum and fix broken websites, and he is all out of bubble gum. He has been blogging about indie authors since 2010 while learning new tech skills at the drop of a hat. He fixes author sites, and shares what he learns on The Digital Reader's blog. In his spare time, he fosters dogs for A Forever Home, a local rescue group.

2 Comments

  1. Jim Self6 February, 2015

    Oh, the most insidious bugs take an enormous amount of time to uncover. That’s what non-coders don’t seem to realize: getting it written is step 1. Getting it working is steps 2 through 10.

    Reply
    1. The Commons6 February, 2015

      And then sometimes steps 6-8 repeatedly.

      “If you don’t know why it works—it doesn’t.”

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to top