Thanks for your follow-up, Gary.
I think this was answered elsewhere but the folks at quadrocopter.us (Jeff) tested this. While it starts out insanely fast between 10 and 20 meters it slows down. Holger posted something similar. The trouble is having the nerves of steel to allow your investment to truly enter the experimental zone all the way to a landing.
It still makes no sense to me that the Kopter would drop like a rock at all, by default! This is a German high tech device, not some cheap Chinese POS. Why wouldn't it just proceed slowly from signal-loss all the way to the ground? :dejection:
And those darn trees sure can spoil a good test of the emergency system. EC how did you have the emergency stuff setup? The new .88 software after signal loss (based on the altitude you have set) climb/descend to that altitude, come home and then enter emergency gas after the period set. So if the altitude is set less than your flight altitude (church steeple level) then it would descend first, in this case right into the tree.
To be honest, I don't think we've touched any of the emergency/failsafe settings. I think the CH altitude was set to 50m, and the signal loss occurred around 90-100m. So I guess that's why it came down first. What's so terribly frustrating is that if the Kopter had continued on its waypoint flight, it would soon have emerged from the radio-shadow of the tower. In fact, it was set to come back to a final waypoint 10m in front of me, at 5m altitude, facing away, so that I could slowly back it in for a manual landing, like we always do. And the LiPo had another 15 minutes of juice left in it.
Now that I've started researching the problem, we should have done some testing of the failsafe functions with both the receiver and the MK boards. Of course, hindsight is 20/20. It just never crossed our minds that a quick pass behind a tower would block our fancy Graupner MX-20's 2.4GHz signal, and even less that the MK controls would have such a crazy default setting.
I've been focusing on the reconstruction of the Oktokopter for the past two weeks. Hopefully, my (re-) soldering and all of the electronics will check out fine tomorrow, and I will be able to focus on firmware updates and studying all of the settings in MKTools, esp. emergency settings, in much more detail.
We were running .86 firmware at the time of the crash. Because I had read mixed reviews of the .88 firmware at the time of our build, we decided not to upgrade to the latest and greatest. At this point, it looks like any issues have been sorted out. So I am treating this re-build as a new build from scratch, and will make it a point to update firmware on all the MK boards as well as the TX and RX to the latest versions. And we will obviously calibrate and configure everything again from scratch.
Great to hear that the loss was only $100.
That is indeed the saving grace of this whole ordeal, which was a forceful reminder to RTFM (i.e. the whole damn Wiki, and the English- and German-language boards)! :nevreness:
Given the complexity of the MK systems and the flying we are doing, a serious crash was going to happen eventually. Even though everybody's nerves were shot, and I am still incredulous at MK's default emergency settings, no people or animals were harmed in the process, and no ambulances or fire trucks had to get involved. Hopefully, the next time I work on the Kopter's hardware it will be an upgrade, rather than a re-build.
Roland
