We’re talking 314 and 315 … both hit the log file size limit (300MB).
This doesn’t alter conclusions … but I’m still curious and looking at other things.
Could you upload 316 to 320? I’m guessing these are all relatively small?
Also - as a comparison - could you upload one of the earliest ones you have, that’s large enough to be a flight, and not just a “check things are working OK” pre-flight brief switch on…
Again - you can make space on Dropbox and delete the others, all have been downloaded.
Got home from work and have had another read through.
I downloaded from the link Callum put up and all I can get when uploading the file is what I assume should be a map, all I see is a red line trace on a white background and then some box about getting a Google map key.
Now I know where I was going wrong with the files I can now see the logs on the link you posted.
This is what I have worked out.
310 is the previous flight to the crash.
313 is the flight up to the crash.
314/315 is after it going down and before I pick it up, Why so much movement and data?
316 is me picking it up and switching it off when I get it out of the brambles.
317 is me trying to see if it would turn on, lower the landing gear and if the motors would run.
318-322 no data, that will be me checking the camera is still working after plugging in the broken cables in the house.
293 is another flight as requested.
I couldn’t work out what 311 and 312 were but I remember something now that might be significant, I had an error which I have had in the past, it said " MC Connection to Center Board Failed, Please restart aircraft, if it still fails, please contact customer service", or something like that.
From what I found out before this is something to do with the camera connection, could this have been the problem?
Let me know if you can see the files in this folder or have I got to give permission for each one?
Silly question time, are the device and onboard both the aircraft? Or is the device the iPad/controller?
Is it worth asking some questions on Inspire Pilots or not?
Movement - poor/variable GPS location in amongst the trees.
So much because 100 logged data-points per second - over quite some time.
Yup - still something I’d like to check from logs that are post-crash and after you picked it up.
This could be more than just a camera issue … and might tie in with some other things I’ve seen in the logs … which is why I was wanting a clear “before” and “after”.
312 was a brief switch on in the car-park where you took off, I believe.
Correct. I’ve had all these files in my brain and totally forgot to feed that piece of info back to you.
I had so many things (windows/apps/multiple logs/spreadsheets) open whilst I sorted out what files were what and why, last evening, my head was spinning faster than a Mavic’s props at full throttle!
Now I know exactly what all the files are - and where in the sequence of events they are - I’ll do another (more logical) review. Might not be until tomorrow.
Have you managed to have a look at the files yet @OzoneVibe?
I went through a few batteries when I got home from work today, hovered the first two at around 6" in the garden, and flew another around the green at a couple of feet.
I’m thinking I might have a motor issue, on idle you can see it is spinning at a slower rate than the others, I also get an occasional motor overload warning, but at random times.
Is there a way of checking this? It spins and feels the same as the others.
The problem wasn’t a disconnect though. OK - there was a really brief one - 1.17 secs, but it continued to fly under control for another 20secs before the Inspire turned off completely and suddenly … hence no RTH or anything.
One second it was way up in the air, when it had completed the reboot it was wherever it was on the deck.
The switch off is not a Litchi issue. The inspire basically rebooted.
Even Litchi was recording excellent up/down link values in the log after the disconnection.
No idea.
I’m wading through all the data again, at the moment.
Hoping to determine how long the reboot took, too.
I’ve never heard of an in-flight reboot for any drone.
Indeed. From a flight some time before, too, to try and detect any different error messages.
My spreadsheet with all the data and error messages … and formula to find things in one log that aren’t in any of the others … is currently running at just over 250MB.
Well - “event logs” - damned right, there are. Some say “error”.
That’s what I’m comparing between all the DAT files …. trying to find something in that flight that’s not in the previous successful flight.
It’s brain mushing, I tell you!
So, what has an afternoon of trawling through logs discovered.
The boot sequence event-log entries on that flight seem little different to the flight some time before (FLY293.DAT).
Whilst I’ve little idea what the vast majority are about - those in the flight in question vary so little, and certainly not alarmingly, to Flight 293 (sounding like Flight Crash Investigators, there! ) that it’s not revealing anything helpful.
The last event log message is 13 seconds after t/o … and just to do with raising the landing gear - 11 seconds after assisted t/o. Absolutely nothing else after that.
Interestingly, the Inspire’s log reports that it was connected to the RC throughout the flight. The 1.7sec disconnection reported by the Litchi log must be erroneous … I’d rather believe the Inspire’s log on this one.
The “re-boot whilst falling out of the sky” log is totally different to any other log (I guess we can excuse it that fit of anger …. having just dropped 100m out of the sky and been bouncing through the trees/undergrowth).
The time after the initial flight ended suddenly, and logging recommencing on reboot was 3.2 secs. (Seems reasonable.)
Freefall time from 100m is appx 8 secs - so possibly still in the air and falling as It re-booted.
But times, and sensors, suggest it was on the deck before the GPS got a first (rough) fix.
The time after the initial flight ended suddenly (with 12 satellites), and a GPS fix being re-established (with 6 satellites) was 10.0 secs.
The on-board barometer doesn’t get logged until the GPS kicks in - so the possibility that it was still falling as it re-booted cannot be confirmed - but that’s what I’ve calculated.
In short … there’s nothing to indicate why it “re-booted” in mid-flight.
Worth noting that all DAT files had some “hardfault” event log entries …. but consistently the same 8 in all but FLY317.DAT and FLY322.DAT.
317 is excusable - the first time you turned it back on after retrieving. No obvious “reason” for so many in 322.
You’ve flown since - so, if you want to send me the latest DAT for an actual flight … however low/short … I can give that a quick comparative once-over.
Thank you @OzoneVibe, I don’t know how the heck you do it, it is way over my head
It sounds very much like it could have hit the floor before it had GPS lock on reboot but do you think it could have maybe started the props before GPS lock and it maybe slowed it down, or am I thinking a load of crap?
It did seem to find the only small clearing we could see in the wood.
Are these something I should be worried about?
I will try and find time to lift the files from it tomorrow while the wife is in work, It’s our wedding anniversary tomorrow so I’ll be taking her out after work.
Will the logs also tell you if there are problems with the motors?
I did notice on idle that the rear right prop is running slower on idle, once hovering it seems to run fine.
However, I would rather change it while it’s still in one piece rather than it packing in on me, I don’t think I would be so lucky next time
Meanwhile, after trawling eBay for what was supposed to be for Inspire 1 motors last night and this morning, well this kind of happened
) that it’s not revealing anything helpful.
