User Data Log

[b432291]

Just pulled the 1st user data log from the skyview. I believe I have the default user data rate of 4 lines per second. However, it seems that the GPS Date&Time and the System Time fields only resolve to seconds, which leads to multiple y values (4) per time value it you graph vs GPS Date/Time (as session time resets on each powercycle).
I will be changing to 1 line per second, but you may want to make that the default (maybe it is), as more than 1 line per second is hard(er) to deal with in Excel. Or add sub-second info to the GPS date&time field.

 

[dynonsupport]

The column you want to use is the first one. This is time accurate to millisconds. This will increment as expected at all speeds. You should really graph against this.

 

[b432291]

I understand about the first column, but that number starts at zero when the unit is powered on. So if you are graphing multiple flights you have to separate them in excel. Like I said, just a low level request to add more resolution to the GPS date/time column (after all GPS time should be pretty accurate - no?).

 

[dynonsupport]

Actually, GPS time is accurate, but not continuous.  If you have a 1Hz GPS, it only gets sent to us once a second. If you use a 5Hz GPS like our SV-GPS-250, it's 5 times a second. Either way, neither of those times are very helpful at 16Hz or 8Hz logging, and don't even line up nicely with 4Hz and 2Hz.

Sure, it's possible to take the time you get and then try and add your own clock to it, but that's a lot of work for little reward, and in fact is corrupting the purity of that data. Right now, the GPS time column is just the last time that was sent to us by the GPS. It's just text to us since the only time we ever use it in SkyView is at boot to set the internal clock, once. You'll notice that we don't even have GPS time when the datalog starts in a lot of cases because the GPS is not locked yet.

Then, if we did that, you'll run into another Excel annoyance. Excel doesn't have a built-in time format that understands HH:MM:SS.000. We tried it, and it imports very weird. Best case, it throws away the sub-seconds and you end up where you are now. This is why our session time is in SSSSS.SS not anything else broken up. Excel only understands SS.000 if it's relative to some 0 point, not if it's absolute.

Then, you still have a GPS time problem when you go to graph it. GPS time is UTC, so if you are in the USA, it rolls over in the middle of the day, which will throw off Excel's graph anyway. Trying to graph across dates would have all the issues session time already does.

So, if you really want to graph in excel against time, and you want that time to be absolute time, and you want that absolute time to have sub-seconds in it, then you will need to get creative. It's totally possible if you switch to a relative time format like UNIX seconds and then do a few IF statements.

If all you want to graph is each record as the next record, then just add a column that is "row number" and have it increment by one and graph against this. We can't do this ourselves since the datalog is a rolling log, and thus the row number for every row literally changes every time we add a record since the bottom one falls off as we add one to the top.

 

[jc2da]

Dynon,

This brings up another question i have had about user data logging. My typical scenario is that I save the user log data to the flash drive, then upload to savvyanalysis.com for flight A to B.

Then i do another 1 hour flight, save to flash drive, then upload to savvyanalysis.com for flight C to D. However, it seems that the user data still contains flight A to B as well.

Thus, when i upload to savvyanalysis, i now have
- flight A to B
- flight A to B
- flight C to D

thus A to B is repeated.

Just wondering what user model you are expecting here. Before my C to D flight, should i reset the uesr data?

Or is this something savvyanalysis should accommodate and detect those duplicate flights?

Thanks,
Jae

 

[Dynon]

The system keeps the log running until you clear it - then it's first in, first out. So if you want discrete chunks that don't overlap, you should reset your log after you save it off to the USB stick.

 

[b432291]

Dynon Avionics folks, thank you for the through explanation as to why the log file is-as-it-is. Fixing it on the dynon is the wrong approach as the code would be quite complicated. I think its time for some scripting on my end to massage the csv file before I give it to excel. If I come up with something useful I will post here. Again, thanks for the through answer.