Separate names with a comma.
Discussion in 'ALTA' started by Adam Varadi, Nov 26, 2015.
Vive la Revolution!
As far as I know this is a "fixed" ALTA.
Update: Freefly responded, just sent them this thread's link.
I forgot to respond to this.
I think what we are seeing is an artifact of the way that data is written to the microSD card: Each data row of the log file is "buffered" up in the microprocessor's RAM into chunks of data of (the size seems to vary considerably -- but it's quite large, eg. 4 megabytes). Those chunks are then written out to the microSD card.
That means that, at any given time there is quite a lot of data sitting in the microprocessor's RAM that has NOT yet been written out to the microSD card. If something suddenly removes power (or the microprocessor is reset), then a considerable amount of data (from the RAM) evaporates and will be lost.
That may well be what happened to the "Missing Minute" of data. It just never made it out on to the microSD card.
It's also feasible that the RAM-based buffer that was written out to the data part of the file, but the FAT (File Allocation Table) was not updated so the apparent "file length" was not extended to include that last chunk of data, even though it was out on the microSD card.
@Adam Varadi: If you have access to a Mac, you can use Disk Utility to make an "image backup" of your microSD card. (See "New Image" in the menu bar). If you could do that, I *might* be able to recover some of the missing data. Let me know if you would like me to try -- and send me the image of the microSD via Dropbox if you can -- it will be quite large as it is a bit-for-bit copy of the microSD card.
Thanks for the continous help! I'm uploading the dmg file right now to the same dropbox folder.
But here is a link to get it faster: https://www.dropbox.com/sh/e1y6v55gtq3v8sj/AADH7yLv0HvA4LL_iiysrb9Ta?dl=0
sounds like ALTA lost one motor.
but i wonder why you lost controll of the ALTA?
it would be nice to get some information how ALTA will behave after loosing a motor.
Adam, did Freefly give you any information? Are you going to send the copter to them?
I don't know if one motor stopped, it happened so fast. But I didn't have any control over the copter.
No info from freefly, I wold love to send the copter to them for a checkout, because I wouldn't fly it with confidence anymore. (And I still think this is the best copter (hexa) out there, love the flight characteristic)
Thanks. I'll see what I can find. This could turn out to be a several hour-long search, so don't hold your breath!
Thanks Andy! Curious to see what caused the crash.
Can you confirm the approximate Latitude and Longitude where you fly?
I know there is an issue with the Synapse log files in that it gets the Longitude wrong in earlier versions of the firmware.
For example, in file 2015-10-07, SYNLog-01-08-07.csv it shows a Longitude of 3073453003 (307 degrees?)
However in file 2015-11-26, SYNLog-08-55-15.csv it shows a Longitude of 183318608 (183 degrees?)
This does not relate to the crash -- I'm just want to understand the log file. (And yeah, Longitude should never be larger than +/- 180 degrees!)
Does the log file show the version of the firmware? I suspect the difference could be caused by the newer version of the firmware.
The position should be near to this point: 47°29'48" N 18°20'18" E
(1 miles different max)
Thanks, Adam: I figured that, given you're in .hu land, you'd be between 16 E and 22 E (because that's all you've got in .hu! )
Yes, it shows the version number (at least in the later versions of the log files), however, it still doesn't really help to figure out what the correction factor should be -- without having a log file from a takeoff/hover over take off and land.
My recent log files are fine --
which is spot on for where I fly, albeit the -122 has to be read as a longitude of 122 W. I seem to remember from my pilot's training (in the UK), we treated Eastings as -ve, not Westings, but that was from a long time ago in a country far, far away.
Aha. So the value of 183318432 is 18.3318432.
Ok. My previous logic is correct then.
In file 2015-10-07, SYNLog-01-08-07.csv it shows a Longitude of 3073453003 which might *just* be 30 E if you were flying just east of .hu land?
Adam: Attached is a forensic analysis of your microSD card. It shows the details of the files that are on the microSD card, but not the contents -- we're still working on that.
For the record you owe my colleague Robert Young a beer or two (or maybe some decent Pick salami from the Magyar Republic!)
You will see rows 114 and 115 are the particular files of interest. Robert is still having a look to see if we can recover additional data from "in between" these two files to try and understand what happened.
Let me know if you cannot open the attached file. You will need to unZip it first and then use Microsoft Excel, or equivalent to open it.
Bad news I'm afraid: Robert was unable to recover any additional data rows -- it looks like the Synapse firmware does not flush out the data from the microcontroller memory fast enough to recover the details of the malfunction.
You have the Graupner Air Module installed. Did you look at any recorded telemetry from that? Can you post any data you have, please?
I would be happy to do so, but don't have any idea how to get the data. :-(
Which Graupner transmitter are you using? I'm not sure all of them can record the telemetry.
Check out this page: http://www.rcgroups.com/forums/showthread.php?t=2036282
Scroll down to Telemetry Logging. It sounds like you have to set certain parameters on the transmitter to record and then use the Graupner software suite to play the telemetry back.
I believe the telemetry data is recorded in the transmitter's SD card so you need to access the files on the transmitter, move them to a PC and then run some software like this: http://www.nongnu.org/dataexplorer/index.html
There also appears to be this: http://www.appdownloader.net/Android/App/598930/com.graupner.hott.viewer
I have not use this software myself, though.
My colleague Robert managed to recover the data rows for time 8:57:41 to the time 8:58:45 for the "first" log file SYNLog-08-55-15.csv.
I had asked him to look for .csv data rows that had "8:57.42" in them (the next second after where the data stopped in first of the two log files, SYNLog-08-55-15.csv).
Using the forensic tools that we normally use in litigation he found another 1,569 data rows that take us to 8:58:45 -- that is within 3 seconds of where the log file SYNLog-08-58-50.csv starts recording.
Thus it seems highly likely that my working hypothesis is correct -- that the second log file, SYNLog-08-58-50.csv, is a "continuation" log file of n SYNLog-08-55-15.csv.
What I think might be the most interesting data is at the end of the first log file SYNLog-08-58-50.csv. See the image below in this posting -- you'll need to have that on screen to understand the following comments. Click on it to get a larger version.
The most significant thing is that Barometric altimeter concludes in data row 5250 at a height of 15.4 meters. Quite a number of things seem to have gone wrong -- I've highlighted them in yellow in the image
Row 5246: There is the first onset of I2C bus errors (column FI).
The Mag Bad column changes status (column EZ, row 5240). i've not got access to any material that tells me precisely what this means, but I infer that the magnetometer data is apparently bad.
Radio A -- which is your case is the Graupner receiver and the only receiver, appears to be dropping data packets. See column EX, row 5244.
Column EW, row 5244, shows Loss of Signal in the receiver from the transmitter.
Column ET, Status, changes from 4 to 5 in row 5244 -- again, I don't have any specific information about what this means, but I do have a very strong hunch that this means Something Bad Has Happened.
Conclusion: I suspect (but do not know for sure) that something in wiring or the electronics failed and what we're seeing is the start of a cascade failure. I do not have any information about what is likely to have failed, but the fact that there are I2C bus errors indicates that the failure appear serious. It is puzzling why the Mag Bad status changes to indicate a problem 200 milliseconds before the first reported I2C Timeout, but then I don't have access to any of the inner details of the Synapse/GPS unit.
Right now, I'm not sure I can do too much more to diagnose the problem without more information about the meaning of the various columns in the log file, but hopefully the attached recreated .csv file will help FF diagnose the root cause of the problem.
SYNLog-08-55-15.csv with the recovered data is attached so that FF and others can have a look at it.